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

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 11 Mar 2012 12:13:31 +0200

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: Florian Zeitz <[email-masked]>
Date: Mon, 12 Mar 2012 01:01:15 +0100

>> Where do we go from here?
Nom, tasty TOFU.

Hi,

I have a question/suggestion concerning this.
I'm admittedly somewhat reluctant to ask at this point, because I have
not found time to read enough of the OAuth RFCs to get the full picture,
but please bear with me.

It seems we have a relatively well defined list of necessary
information. If this is put into JSON it appears to me that this JSON,
except for ordering of entries will not be particularly flexible.
Is there a compelling reason not to go back to a good old comma
separated key value pair list at that point?

The reason I ask is that having either a HTTP or a JSON parser (even a
limited one) just for a SASL mechanism seems like enormous over
engineering to me.
This particularly struck me when people were discussing token based
authentication at the last XMPP Summit. People were suggesting we might
be able to reuse SASL OAuth for this under the assumption that it would
just amount to sending a single token string over the wire.
I find it somewhat irritating that at this point in time it is very
significantly more complex than that.

Regards,
Florian Zeitz

---

From: William Mills <[email-masked]>
Date: Sun, 11 Mar 2012 17:36:01 -0700 (PDT)

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, 

Ciao
Hannes

---

From: William Mills <[email-masked]>
Date: Sun, 11 Mar 2012 18:02:02 -0700 (PDT)

First, lemme say I'm happy to have active discussion on this!  More inline...

> From: Florian Zeitz <[email-masked]>
>To: [email-masked] 
>Sent: Sunday, March 11, 2012 5:01 PM

<snip />

>separated key value pair list at that point?

It's well defined for the current token profiles, yes, but what about for
extensions and new auth profiles?  I wanted to avoid having to write in a
mapping per OAuth auth profile from the data in band to how it's used in
authentication.

>limited one) just for a SASL mechanism seems like enormous over

On the server side it's probably more work, but on the client you have to do 

HTTP and JSON anyway.

>significantly more complex than that.

The simplest token case, Bearer, could work this way.  I don't think anything 

else does.

We might be able to do it differently, but I was using this also as proposal 

for how to do OAuth 2 discovery.  Will XMPP want auth endpoint discovery?

-bill

---

From: Florian Zeitz <[email-masked]>
Date: Sat, 17 Mar 2012 00:54:58 +0100

> mapping per OAuth auth profile from the data in band to how it's used in
Agreed, I was hoping OAuth mechanisms would have enough in common to map
to a single representation. E.g. always provide data in the
Authorization header field. From a quick examination it seems to me that
this is currently at least one of the options for all mechanisms,
however is not guaranteed to remain that way.

> On the server side it's probably more work, but on the client you have to do 
I might just be overlooking something, but in particular the need to do
JSON in a client is not apparent to me...

> for how to do OAuth 2 discovery.  Will XMPP want auth endpoint discovery?
This was generally just an example of why the current approach strikes
me as quite complex. In this particular discussion using SASL OAuth was
sort of an afterthought. The idea was that (the equivalent to) the
authorization endpoint would always be the resource/login server and
tokens would be obtained via some XMPP based protocol.
By now it seems to me that this might just be too different from OAuth
to be reusing anything from it.

I would however imagine that in general auth endpoint discovery would be
very useful for some XMPP deployments that want to utilize "normal" OAuth.

---

From: William Mills <[email-masked]>
Date: Fri, 16 Mar 2012 18:14:36 -0700 (PDT)

>JSON in a client is not apparent to me...

Because the OAuth 2.0 core protocol returns JSON formatted results.

>very useful for some XMPP deployments that want to utilize "normal" OAuth.

Something that came up in a different conversation is that the Google IMAP
OAuth solution is using HTTP already.  

That said, discovery doesn't require the server to parse HTTP really, just 

return it.  The current proposal re-uses existing HTTP style LINK header
discovery, in the hope that this will become more generally useful.

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 26 Mar 2012 12:24:26 -0400

Just as a point of reference, OpenAFS's rxgk security class is designed
to support any GSS mechanism that supports the GSS PRF.  I would like to
see the ability to use OAuth as an authentication mechanism for OpenAFS.
 As a result, I would prefer a SASL implementation that relies on the
construction of a GSS mechanism instead of a direct SASL mechanism.

I would also prefer to avoid parsing HTTP header syntax.

Jeffrey Altman