Subject: [kitten] Feedback from IETF #83 on the OAUTH/SASL-KRB draft

From: William Mills <[email-masked]>
Date: Tue, 3 Apr 2012 17:10:39 -0700 (PDT)

I went to IETF #83 specifically to get feedback (and I though a tentative decision) on the question of whether the SASL message format currently there which uses HTTP was a good idea or not.  I did get a ton of good feedback in individual conversations, the conversation in the working group itself was a little less lively.

From the WG meeting:
-    several folks promised to read deeper and bring comments back to the list.
-    Hannes' comment at the mic (my summary) was that given the many successful integrations against Google's XOAUTH that staying close to those has great value for getting successful uptake, and that adapting the code those clients use to new endpoints 

From general feedback from random folks:
-    Many folks said HTTP is in fact very hard to parse correctly if you have to parse it fully.
-    Some folks felt existing implementations close to a proposed spec are likely to add to successful adoption.
-    a few folks felt that it's reasonable to limit the stuff that actually has to be parsed.

There are real difference between the complextity needed for XOAUTH and for the proposed OAUTH mechanism.  XOAUTH does everything in the URL, where the OAUTH proposal  I'll post here the Google XOAUTH SASL message format, and an example form the draft spec:

From http://sites.google.com/site/oauthgoog/Home/oauthimap for XOAUTH:

For example, before base64-encoding, the initial client request might look like this (with linebreaks added for clarity):

(2-legged OAuth)
GET https://mail.google.com/mail/b/[email-masked]/imap/?xoauth_requestor_id=someuser%40example.com
    oauth_consumer_key="example.com",
    oauth_nonce="4710307327925439451",
    oauth_signature="75%2BB63NbW2GdDMaOCEd%2Fy%2Fb%2B0Qk%3D",
    oauth_signature_method="HMAC-SHA1",
    oauth_timestamp="1260933683",
    oauth_version="1.0"

For the OAUTH mechanism a similar style signed request example is:
GET / HTTP/1.1
Host: server.example.com
User: [email-masked]
Authorization: MAC token="h480djs93hd8",timestamp="137131200", nonce="dj83hs9s",signature="YTVjyNSujYs1WsDurFnvFi4JK6o="

The OAUTH mechanism will require (as currently specified) parsing of a Host, User, and Authorization header.  The path and query is actually ignored at present.  Based on this message I'll be posing questions to the list.

Regards,

-bill

---

From: William Mills <[email-masked]>
Date: Tue, 3 Apr 2012 17:58:59 -0700 (PDT)

The major question remaining for my draft is HTTP(like) or not for the SASL message format?  Please select one of the following:

A)    The current message format is fine.
B)    HTTP-like is OK as long as we limit the insanity.
C)    HTTP in any form is a deal breaker for me.  Give me something simple.
D)    None of the above, and I have a possible solution of my own to propose.

For B above it's likely that we'd say something like "The server MUST parse the Host, User, and Authorization headers and the server MAY discard anything else.  The client MUST NOT use any HTTP extensions such as compression and pipelining, and SHOULD NOT use line continuations."

Thanks in advance for the input,

-bill

>________________________________
> From: William Mills <[email-masked]>
>To: "[email-masked]" <[email-masked]> 
>Sent: Tuesday, April 3, 2012 5:10 PM
>Subject: [kitten] Feedback from IETF #83 on the OAUTH/SASL-KRB draft
> 
>
>
>_______________________________________________
>Kitten mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/kitten
>
>
>

---

From: Nico Williams <[email-masked]>
Date: Tue, 3 Apr 2012 20:22:47 -0500

On Tue, Apr 3, 2012 at 7:58 PM, William Mills <[email-masked]> wrote:
> The major question remaining for my draft is HTTP(like) or not for the SASL
> message format?  Please select one of the following:
>

I'm not an implementor of this protocol.  Some day I might be.  I'm OK
with (B), but I'd prefer something saner than HTTP.  JSON is almost
perfectly sane (missing only a self-describing encoding of binary
data).  I want it to be simple, and I think HTTP-like-but-lite would
be OK, but there's so much off-the-shelf code and experience with
JSON...  If there's running code that has been deployed then I think
(B) is the best option.  HTTP-like with HTTP insanity is a deal
breaker though.

So count me as in favor of (B) if there's not enough support for (C).

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 04 Apr 2012 09:47:38 +0200

William Mills <[email-masked]> writes:

> The major question remaining for my draft is HTTP(like) or not for the
> SASL message format?  Please select one of the following:
>
>
> For B above it's likely that we'd say something like "The server MUST
> parse the Host, User, and Authorization headers and the server MAY
> discard anything else.  The client MUST NOT use any HTTP extensions
> such as compression and pipelining, and SHOULD NOT use line
> continuations."
>

To get informed answers, I think we need to understand the implications
of each answer.  Let's say we invent a new format for SASL OAUTH.  How
much of a problem would that really be?  Where would the complexity
related to HTTP have to be implemented?  Is it the server that would
need to parse HTTP and transform it to something simpler?  Is the client
completely shielded?

Looking at history, I believe one of the main reasons DIGEST-MD5 didn't
quickly replace CRAM-MD5 was that DIGEST-MD5 was so complicated to
implement interoperable, and that was primarily because it re-used HTTP
syntax.  So I don't think this is just a pet issue, it seems that if
SASL wire syntax is too complicated, things won't get implemented.

If I were to express a preference now I would lean towards B).  However,
if the implications of C) are not severe, I think it would make sense to
use a simpler format.  Then it becomes much easier to implement and
analyse what goes on over the SASL wire.  Without a good rationale, I
would be strongly opposed to free-form HTTP as the SASL syntax.

/Simon

---

From: William Mills <[email-masked]>
Date: Wed, 4 Apr 2012 07:44:35 -0700 (PDT)

One of the real takeaways for me from the IETF is that parsing HTTP is deep deep water with sharks in it.  Of the things we have to parse right now the hairiest would be the authorization header because it may have multiple authorization elements.  Everything else is comparatively simple.

The data elements we need are:
-    Host
-    port
-    Authorization header payload for the oauth profile
-    username -- used for auth(zn) endpoint discovery only
-    path+query string -- currently a stub of extensibility
-    HTTP body-- currently a stub of extensibility

The auth header payload is still going to have to be parsed by the server as is I think.  It's too complex to try to provide an arbitrary structured mapping for all cases and it's just an opportunity for error.

Extensibility can be done with an IANA registry of n/v fields for the purpose.  After that I'd probably choose a format like'Name ":" value CRLF' over JSON.

> From: Simon Josefsson <[email-masked]>
>To: William Mills <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]> 
>Sent: Wednesday, April 4, 2012 12:47 AM
>Subject: Re: OAUTH/SASL...  to HTTP or not to HTTP, that is the question...
>

---

From: Matt Peterson <[email-masked]>
Date: Mon, 9 Apr 2012 17:01:59 +0000

Ditto.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nico Williams
Sent: Tuesday, April 03, 2012 7:23 PM
To: William Mills
Cc: [email-masked]
Subject: Re: [kitten] OAUTH/SASL... to HTTP or not to HTTP, that is the question...

Nico