Re: [kitten] SASL OAuth: Next Steps

[William Mills <[e-mail]>]

I've been thinking about this quite a bit, and Tim's rebuke to me privately that I really should think about JSON seriously before dismissing the idea because HTTP really is harder to parse than I think it is struck home.

I'm still stuck on the fact that I think the HTTP we have to parse in the client for the mechanism to work is all OAuth 2 protocol 
or defined in the mechanims (discovery) so it's more limited.  On the server side it's very limited, only enough to figure out the discovery.  So I don't think the HTTP here is that scary. The actual HTTP we have to parse for the mechanism to work on the server side is mimimal, and well defined.  Am I wrong?


SO.... I'm trying to figure out how this would work and what we'd need to do in order to make JSON work instead of HTTP as the authentication message format.  My assumptions are:
  

-    We're passing the Auth header in to a library, the SASL mechanism itself doesn't need to parse it.


We need to support right now for the profiles I know about:

-    The user name and host name for discovery
-    The port number for things like MAC authentication
-    the Authorization header payload
-    discovery information for return to the client


It's possible we'll also need to pass in:

-    The HTTP POST payload for profiles that require it (though I was assuming GET only initially)
-    Something else I'm forgetting about... or for extension flexibility?


In the end I'm presuming we're passing all the real HTTP into a library that will understand it anyway (which is how my initial implementation is working) so we don't need to dive down into the header and POST body payload in the JSON. If this is right then the JSON doesn't look that hard, but then again if what I have above is correct then we're not talking about a general use HTTP parser either.


The OAuth 1.0a library I was playing with for this consumes and gives back the entire Auth header, but I don't know if that design pattern is common.

Where do we go from here?

-bill







________________________________
 From: William Mills <[e-mail]>
To: Tim Showalter <[e-mail]>; Russ Allbery <[e-mail]> 
Cc: "[e-mail]" <[e-mail]> 
Sent: Thursday, January 5, 2012 4:01 PM
Subject: Re: [kitten] SASL OAuth: Next Steps
 

Yeah, I really hate this.

There's stuff in the MAC token spec for example that requires knowing the URL path, fragments, hostname, etc., and so we have to include every element form HTTP that might be required for any OAuth (HTTP based itself) authorization scheme.  This means we have to write an entire mapping grammar for an entire HTTP payload into JSON.

While I agree that HTTP is non-trivial to parse, I don't think it's compelling enough for me to like the change to JSON because there are enough HTTP parsing libraries out there that an implementer should not have to do their own, they should pull one in.
As I said before, designing this in a vacuum HTTP is far down the list, but I think in light of the fact that we're bridging from something that *is* HTTP it is less complex overall to stay consistent.



-bill



________________________________
 From: Tim Showalter <[e-mail]>
To: Russ Allbery <[e-mail]> 
Cc: "[e-mail]" <[e-mail]> 
Sent: Thursday, January 5, 2012 1:38 PM
Subject: Re: [kitten] SASL OAuth: Next Steps
 
On 1/4/12 6:34 PM, Russ Allbery wrote:
> Chris Newman<[e-mail]>  writes:
>> Having a SASL parser call out to a header parser would be poor security
>> design, because every line of code is an additional potential security
>> vulnerability (especially prior to authentication) and a lot of code is
>> needed for a 100% correct header parser. So I think it's actually
>> important for a SASL mechanism to not accept arbitrary header syntax.
> 
> Based on my experience writing netnews implementations, which use RFC 5322
> header field syntax very akin to the HTTP header field syntax, I
> completely concur with Chris's reaction.  The header field syntax is
> surprisingly complex, particularly in the presence of encoding and
> character set issues, and most
 implementors do not implement it properly.

I'm really sorry to hear that -- I suspect you're right, and I don't like it.  I think trying to constrain JSON and define the mappings is going to be a lot of work.

Is there a simple way to specify a general mapping?  Or are we going to have to do this on a per-header basis?

Tim
_______________________________________________
Kitten mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/kitten



_______________________________________________
Kitten mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/kitten