Subject: Re: [kitten] SASL OAuth: Next Steps

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 12 Mar 2012 08:46:38 +0100

Bill, that's certainly a good reason for staying with the current design. Do you by chance know the person(s) at Google who did their implementation.
 It might be useful to reach out to them and to get them involved in the work.

----- Ursprüngliche Nachricht -----
Von: William Mills
Gesendet: 12.03.12 02:36 Uhr
An: Hannes Tschofenig
Betreff: Re: [kitten] SASL OAuth: Next Steps

 Something else that may play in to this is the fact that this basically isn't that far from what Google has had running for quite a while no on their IMAP service. Updating those implementations to this would be a much smaller move than going to JSON. There's quite a bit of actually running code out there working against Google, so staying near that implementaiton probably has value.

 -bill

-----------------------------------------------------------------
From: Hannes Tschofenig <[email-masked]>
To: William Mills <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; Tim Showalter <[email-masked]>; Russ Allbery <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Sunday, March 11, 2012 3:13 AM
Subject: Re: [kitten] SASL OAuth: Next Steps
 Hi Bill,

 I agree with you. I would prefer to say with the currently described approach in the document absent strong objections.
 We may gain some more implementation experience in the next few months and could also reach out to the XMPP guys who had expressed interest in this work instead of changing the core design. 

 Ciao
 Hannes

 On Jan 24, 2012, at 9:10 AM, William Mills wrote:

 > 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 < [email-masked] >
 > To: Tim Showalter < [email-masked] >; Russ Allbery < [email-masked] >
 > Cc: " [email-masked] " < [email-masked] >
 > 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 < [email-masked] >
 > To: Russ Allbery < [email-masked] >
 > Cc: " [email-masked] " < [email-masked] >
 > 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< [email-masked] > 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
 >  [email-masked] 
 > https://www.ietf.org/mailman/listinfo/kitten 
 >
 >
 >
 > _______________________________________________
 > Kitten mailing list
 >  [email-masked] 
 > https://www.ietf.org/mailman/listinfo/kitten 
 >
 >
 > _______________________________________________
 > Kitten mailing list
 >  [email-masked] 
 > https://www.ietf.org/mailman/listinfo/kitten

---

From: William Mills <[email-masked]>
Date: Mon, 12 Mar 2012 08:45:02 -0700 (PDT)

I exchanged e-mail with them at the beginning of this process, but they were happy enough with what they had.  http://sites.google.com/site/oauthgoog/Home/oauthimap is the link to the definition.  We can see if they want in again, but I think we're close to what they originally had with much more capability/flexibility.

-bill

>________________________________
> From: Hannes Tschofenig <[email-masked]>
>Cc: Tim Showalter <[email-masked]>; Russ Allbery <[email-masked]>; [email-masked] 
>Sent: Monday, March 12, 2012 12:46 AM
>>________________________________
>>> From: William Mills <[email-masked]>
>>> To: Tim Showalter <[email-masked]>; Russ Allbery <[email-masked]>
>>> Cc: "[email-masked]" <[email-masked]>
>>> From: Tim Showalter <[email-masked]>
>>> To: Russ Allbery <[email-masked]>
>>> Cc: "[email-masked]" <[email-masked]>
>>> > Chris Newman<[email-masked]>  writes: