Re: [kitten] SASL OAuth: Next Steps

[Chris Newman <[e-mail]>]

We attempted to use HTTP syntax for the DIGEST-MD5 SASL mechanism. I 
believe it was one of the reasons that mechanism was a failure. While 
there's nothing apparently wrong with HTTP headers as normally used, the 
legal syntactic variations for semantically identical headers are 
unbounded. Not only is white-space variable, but line folding can get 
complex, especially when combined with 2047 encoding. Also, charsets are a 
mess (iso8859-1 or UTF-8 or RFC 2047?). And then there's the hidden 
side-effects of the legacy ABNF "#" operator used by HTTP syntax.

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.

It's probably easier to specify a constrained JSON syntax than a 
constrained subset of header syntax (disallowing all the unnecessary syntax 
variations so a strict parser is very simple), but either of those options 
would address the syntax problems encountered by the DIGEST-MD5 SASL 
mechanism.

I concur with Tim's point that if we do a JSON syntax it ought to be 
algorithmically mapped from HTTP header fields.

		- Chris

--On January 4, 2012 15:44:02 -0800 Tim Showalter <[e-mail]> 
wrote:

> On 12/20/11 1:36 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>> I would need your feedback on the following important design decision.
>> Currently, the OAuth messages are encoded as HTTP headers and Leif had
>> suggested to instead use a JSON encoding.
>
>> ---------------
>>     GET / HTTP/1.1
>>     Host: imap.example.com
>>     Authorization: BEARER "vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=="
>> ---------------
>>
>> A possible JSON based representation would be:
>> ---------------
>>     {"token-type":" BEARER",
>>      "token":" vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=="}
>> ---------------
>> In my made-up example I define two attributes: a token container and a
>> token type attribute. The accessed resource is most likely in the
>> protected token itself and is additionally carried in the underlying
>> transport mechanism and therefore not needed again.
>
> I much prefer to leverage the HTTP headers as the format is already
> defined and additional fields map naturally into the SASL profile.  But
> if we're going down that route, I would suggest that the JSON fields be
> mapped identically to the header fields, like this:
>
> {"authorization":["BEARER" "vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=="]}
>
> The "user" and "host" arguments are omitted from your JSON examples, but
> are helpful for discovery cases, like the IMAP server that is speaking to
> unconfigured clients, where the authentication credentials can come from
> multiple "realms" depending on the user involved.  In your JSON notation,
> the equivalent thing might be
>
> {"user":"[e-mail]",
>   "host":"imap.example.com",
>   "authorization":{"token-type":"BEARER"
>                    "token":"........."}}
>
> Anyway, I still like just putting an HTTP thing in there.  The parser
> isn't that hard to write, and it means one fewer mapping in the world.
> It's not as pretty, but I think it's much less work to specify it, and to
> maintain the links between the specs.
>
> I'm afraid that I have not followed discussions on discovery.  I would
> prefer to not make SASL any more different from HTTP OAuth 2 than is
> required to get the job done.  If we can steal others' discovery work,
> great!
>
> Tim
> _______________________________________________
> Kitten mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/kitten
>