Subject: [saag] On webauth and layering (Re: Reminder: Call for Proposals - HTTP/2.0 and HTTP)

From: Nico Williams <[email-masked]>
Date: Fri, 8 Jun 2012 18:16:44 -0500

Thanks Sam.

Let me take this chance to summarize my vision of how to layer webauth:

 - API-wise, authentication message exchanges should
   happen at the HTTP layer.  Rationale: one component
   can more easily take care of using TLS and webauth
   properly, including channel binding than two.

 - Network-layer-wise, that is, on the wire, authentication
   message exchanges should happen at the application
   layer.

   This works with HTTP/1.0, 1.1, and hopefully bis.  In
   particular this means that authentication mechanisms
   with three or more messages require no changes to HTTP.

 - Authentication should result in a session URI that can be
   referenced from headers (see below) and which can be
   DELETEd to logout.

 - Application message exchanges (i.e., normal HTTP requests
   and responses) should be bear headers identifying the login
   session that they are part of.  Optionally there should be a
   MAC to bind the request/response to its session, using
   session keys, of course.

Nico
--

---

From: Yutaka OIWA <[email-masked]>
Date: Sat, 9 Jun 2012 11:14:45 +0900

Dear Nico,

could you clarify the first two sentences without using
terms like "API-wise" and "network-layer-wise"?

The latter two sentences are clearer, although
(as you may know) I disagree with some of them.

It may be a good opportunity for my side, too.
My position regarding layering is "there will be a
REST-layer authentication framework which is really useful
and worth standardization (possibly GSS-REST?).
However, it should not be the only nor the default way of
authentication for all HTTP applications in the next generation.
Core authentication in HTTP should be in HTTP layer and
it should be greatly improved, and, importantly, *it will work*
(as we showed in the reference implementations),

# Now is IETF trac wiki down?

2012/6/9 Nico Williams <[email-masked]>:
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

-- 
Yutaka OIWA, Ph.D.              Leader, Software Reliability Research Group
                             Research Institute for Secure Systems (RISEC)
   National Institute of Advanced Industrial Science and Technology (AIST)
                     Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Jun 2012 14:37:03 -0500

> terms like "API-wise" and "network-layer-wise"?

Sure.  I want HTTP authentication to be at the application layer on
the wire for various reasons, but I want it to be provided by the same
APIs that provide HTTP and HTTPS support to the application.

The reasons for wanting HTTP authentication to be at the application
layer on the wire:

 - no leakage of information through the URL local part prior to
   completing authentication;
 - can be made to work with HTTP/1.0, HTTP/1.1, and HTTP/2.0;
 - can be implemented in the application when the HTTP APIs do
   not do so natively.

I care deeply about all of the above.

> (as you may know) I disagree with some of them.

OK.  Can you explain your disagreement?

> It may be a good opportunity for my side, too.

Indeed.

> authentication for all HTTP applications in the next generation.

I agree.  I'm not trying to forbid the use of authentication
mechanisms that already exist, for example.

But I'm interested in why you want new authentication mechanisms at
the HTTP layer (on the wire) that require more than one round trip.

> (as we showed in the reference implementations),

See my rationale given above for why authentication should be *above*
HTTP on the wire.

Nico
--

---

From: Yutaka OIWA <[email-masked]>
Date: Sat, 16 Jun 2012 09:38:17 +0900

Dear Nico,

> the HTTP layer (on the wire) that require more than one round trip.

In a simple answer, we found that putting it in payload layer is
unnatural for our solution.  It is not our design principle, but the result of
our design analysis.

Our foundational way of thinking is first to decide what problem will be solved,
what solution can be used, how the communication will occur, and finally,
how these things are put on the wire, considering all benefits and
deficits there.
I think that we should not put any protocol-implementation
restrictions on the first priority
(software implementation/deployment issue is important).

Our design considerations is now described in
http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HttpAuthProposals/MutualAuth/LayeringDesigns

As I described in the above document, HTTP payload and HTTP headers are
isomorphic (in other words, exchangeable in design).  However, if we think of
imaginary (non-existing) protocol which we move the key exchange messages
of our Mutual authentication to the payload layer, we immediately see that
it will not fit to real applications, will not fit our security
requirements, will introduce
unneeded complexities in both server and client sides,

I strongly believe that, under such situation, we should not stick to
specific layering philosophies but we should choose the best
layering choices for each solution.

I also like to mention that, we actually see several solutions for which
payload-header hyblid solutions are well suited.  The best example
on our table is OAuth, obviously.  I believe that you think your solution
also fit to that solution.  We will put one more document regarding
such analysis around Monday (currently under personal proofreading).
I think it will somewhat make clear why we see difference between
appropriate design of layering for each solution.

---

From: Nico Williams <[email-masked]>
Date: Mon, 25 Jun 2012 16:49:35 -0500

On Fri, Jun 15, 2012 at 7:38 PM, Yutaka OIWA <[email-masked]> wrote:

Please excuse the time it took me to respond.  I've been traveling.

> unnatural for our solution.  It is not our design principle, but the result of

I'm not sure what you mean by "unnatural".  It'd be useful to explore that.

If you mean that it's unnatural to require that applications implement
the authentication protocol, then I agree (though I also think it's
nice to have that option so that apps can do strong authentication
with older HTTP stacks).

If you mean that application-layer authentication is unnatural on the
wire then I disagree vehemently.  In fact, I think any HTTP-layer
authentication scheme will be unnatural on the wire: HTTP is a
one-round-trip, stateless protocol, but authentication protocols are
mostly NOT one round-trip (or less).

> http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HttpAuthProposals/MutualAuth/LayeringDesigns

That's quite lengthy, but it doesn't explain what's unnatural about my
proposal.  Or at least I'm not understanding it.

> unneeded complexities in both server and client sides,

I don't immediately see that.  You assert it, but you don't explain.

> layering choices for each solution.

I would agree, but you've not convinced me that we're in such a situation.

Nico
--