Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt

From: Simon Josefsson <[email-masked]>
Date: Wed, 22 Aug 2012 00:37:20 +0200

Thanks for the update!

   Client responses are a key/value pair sequence.  The initial client
   response includes a gs2-header as defined in GSS-API [RFC5801], which
                                                ^^^^^^^ <- should be GS2
   carries the authorization ID as a hint.  These key/value pairs carry
   the equivalent values from an HTTP context in order to be able to
   complete an OAuth style HTTP authorization.  The client MUST send an
                                                           ^^^^
   authorization ID in the gs2-header.  The server MAY use this as a
   routing or database lookup hint.  The server MUST NOT use this as
   authoritative, the user name MUST be asserted by the OAuth
   credential.

This MUST seems unusual -- the authorization identity in SASL is
typically not related to the authentication process, it is a server
application specific username like "admin" or "joe".  Most SASL clients
do not specify an authorization identity, but instead let the server map
the authentication identity to an authorization identity.  Wouldn't be
possible to support this here too?  Let the client leave the
authorization identity field empty, and let the server compare the OAuth
credential to see if it permits access as the authorization identity.
If you need to transfer an OAuth identity hint, I'm thinking that would
belong in a separate field rather than overloading the authorization
identity.  I don't think the OAuth 1.x "token" value is comparable to an
authorization identity.

Further, in section 4 you need to describe how the gs2-header is removed
from the initial context token when the protocol is used as a GSS-API
mechanism.  Compare text like this in RFC 6595:

   a)  the GS2 header on the client's first message and channel-binding
       data are excluded when SAML is used as a GSS-API mechanism, and

/Simon

---

From: William Mills <[email-masked]>
Date: Tue, 21 Aug 2012 15:55:13 -0700 (PDT)

Fixed the GSS-API ref to GS2.  The MUST is because we want the client to 

always send a user ID as a routing hint to the server.  We do specifically
say that the authZ ID must be derived form the credential itself.

We had put a "user" field back in, but dropped it in favor of the gs2-header
since it's duplicate info.  The gs2 header becomes part of the protocol at
all times.

-bill

>________________________________
> From: Simon Josefsson <[email-masked]>
>To: [email-masked] 
>Sent: Tuesday, August 21, 2012 3:37 PM
>Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt
> 
>Thanks for the update!
>
>_______________________________________________
>Kitten mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/kitten
>
>
>

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 22 Aug 2012 01:03:41 +0200

> say that the authZ ID must be derived form the credential itself.

I'm confused -- how does a SASL OAuth client specify that it wants to
logon as the "joe" user on an IMAP server?  Normally in SASL the client
would put "joe" in the authorization identity, and the server would
verify whether the authenticated user is permitted to access the "joe"
account.

> since it's duplicate info.  The gs2 header becomes part of the protocol at

Then the SASL OAuth mechanism is not wire-compatible with the GSS-API
OAuth mechanism.  I believe we want wire-compatibility.

/Simon

---

From: William Mills <[email-masked]>
Date: Tue, 21 Aug 2012 16:17:01 -0700 (PDT)

>verify whether the authenticated user is permitted to access the "joe"

The identity is carried in the token or derived by the server from the token.
The client will know what identity it got the token for.

>OAuth mechanism.  I believe we want wire-compatibility.

Why?

---

From: William Mills <[email-masked]>
Date: Tue, 21 Aug 2012 16:47:55 -0700 (PDT)

That still doesn't explain it to me.  In this case the Gs2 message and the SASL message are the same, no?

> From: Nico Williams <[email-masked]>
>To: William Mills <[email-masked]> 
>Cc: [email-masked]; Simon Josefsson <[email-masked]> 
>Sent: Tuesday, August 21, 2012 4:42 PM
>On Aug 21, 2012 6:17 PM, "William Mills" <[email-masked]> wrote:
>Because gs2 is a SASL encapsulation of GSS: it has to be possible to decapsulate a gs2 mechanism for it to be a gs2 mechanism :)
>Nico
>
>

---

From: Nico Williams <[email-masked]>
Date: Tue, 21 Aug 2012 18:50:07 -0500

On Aug 21, 2012 6:17 PM, "William Mills" <[email-masked]> wrote: > >>
We had put a "user" field back in, but dropped it in favor of the
gs2-header > >> since it's duplicate info. The gs2 header becomes part of
the protocol at > >> all times. > > > >Then the SASL OAuth mechanism is not
wire-compatible with the GSS-API > >OAuth mechanism. I believe we want
wire-compatibility. > > > Why?

Because gs2 is a SASL encapsulation of GSS: it has to be possible to
decapsulate a gs2 mechanism for it to be a gs2 mechanism :)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 21 Aug 2012 18:50:54 -0500

BTW, I'd be ok with (if a bit sad) a SASL mech that looks like gs2 but
isn't. It'd be better to try for a proper gs2 mech first.

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 22 Aug 2012 01:36:29 +0000

>the SASL message are the same, no?

No, because in the SASL case, the SASL layer strips the GS2 header and
passes the rest into the GSS mech layer. I believe that's the idea anyway.

-- Scott

---

From: William Mills <[email-masked]>
Date: Wed, 22 Aug 2012 21:53:28 -0700 (PDT)

OK, I now have the following language, which I think does what is being asked for.

    3.1.2. Use of the gs2-header

    The OAuth scheme related mechanisms are also GSS-API mechanisms, see Section 4 for 

    further detail. The gs2-header is used as follows:
        * The "gs2-nonstd-flag" MUST NOT be present.
        * The "gs2-authzid" carries the authorization identity as specified in [RFC5801].
    In the non "-PLUS" mechanisms the "gs2-cb-flag" MUST be set to "n" because channel-binding 

    [RFC5056] data is not expected. In the OAUTH10A-PLUS mechanism (or other -PLUS variants 

    based on this specification) the "gs2-cb-flag" MUST be set appropriately by the client.

and then...

    4. GSS-API OAuth Mechanism Specification

    Note: The normative references in this section are informational for SASL implementers, but 

    they are normative for GSS-API implementers.  The SASL OAuth mechanism is also a GSS-API 

    mechanism and the messages described in Section 3 are the same, but

    1. the GS2 header on the client's first message and the following %x01 (control A) are excluded when used as a GSS-API    mechanism.
    2. the initial context token header is prefixed to the client's first authentication message (context token), as described in Section 3.1 of RFC 2743,

<section 4 continues>

Does this do what is needed?

Thanks,

-bill

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 23 Aug 2012 07:40:44 +0200

> OK, I now have the following language, which I think does what is

Thank you!

>     1. the GS2 header on the client's first message and the following
> %x01 (control A) are excluded when used as a GSS-API    mechanism.

I don't think the %x01 should be excluded -- only the gs2-header.  The
property that we want is that when the OAuth GSS-API mechanism is used
through GS2, the messages on the wire should be identical.  If the %x01
is removed from the initial GSS-API token, there is nothing that would
add it back, is there?

/Simon

---

From: William Mills <[email-masked]>
Date: Wed, 22 Aug 2012 23:17:07 -0700 (PDT)

The %x01 after the gs2 header could stay, but it would be better if it could go away.  It's only there to provide an easy terminator to the gs2-header.  A leading %x01 here might confuse some implementers.

Is it a problem?  Nothing should add it back.

>Cc: Scott Cantor <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Wednesday, August 22, 2012 10:40 PM
>Subject: Re: gs2-header language Re: I-D Action: draft-ietf-kitten-sasl-oauth-04.txt
>

---

From: William Mills <[email-masked]>
Date: Thu, 23 Aug 2012 00:04:52 -0700 (PDT)

I think the outstanding questions at this time are:

1)    does the error message form the server serve a useful enough purpose to keep?

2)    is it a problem to be pulling out the gs2-header AND the %x01 after it?

3)    are the examples right, specifically do I have the gs2-headers correct in the examples?  or should they not be there in regular SASL?

4)    what have I messed up due to lack of sleep?

-bill

> From: William Mills <[email-masked]>
>To: Simon Josefsson <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]> 
>Sent: Wednesday, August 22, 2012 11:17 PM
>Subject: Re: [kitten] gs2-header language Re: I-D Action: draft-ietf-kitten-sasl-oauth-04.txt
> 
>

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 23 Aug 2012 09:47:42 +0200

William Mills <[email-masked]> writes:

> The %x01 after the gs2 header could stay, but it would be better if it
> could go away.  It's only there to provide an easy terminator to the
> gs2-header.  A leading %x01 here might confuse some implementers.
>

I'd say remove it -- the gs2-header is self-contained and there is no
ambiguity in when it ends.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 23 Aug 2012 10:05:07 +0200

Thanks for update, I think we are getting there...

On error messages, the section reads:

   In the case where authorization fails the server sends an error
   result, then client MUST then send an additional message to the
   server in order to allow the server to finish the exchange.  Some
   protocols and common SASL implementations do not support both sending
   a SASL message and finalizing a SASL negotiation, the additional
   client message in the error case deals with this problem.

The reason is not lack of support in protocols/implementations, it is
RFC 4422 that requires that behaviour, quoting it:

   The protocol may include an optional additional data field in this
   outcome message.  This field can only include additional data when
   the outcome is successful.

So I would rewrite the above paragraph into:

   Section 3.6 of [RFC4422] explicitly prohibits additional information
   in an unsuccessful authentication outcome.  Therefor, the error
   message is sent in a normal message.  The client MUST then send an
   additional empty message to the server in order to allow the server
   to finish the exchange.

There may be some considerations for the GSS-API mechanism side here,
I'm not sure if the client should return GSS_S_COMPLETE or
GSS_S_CONTINUE_NEEDED on the first gss_init_sec_context call.  Is it
permitted for applications to call gss_init_sec_context again, with a
new token from the server, if it has already returned GSS_S_COMPLETE?  I
suspect so, but I can't find the text in RFC 2743 now.  In this case,
gss_init_sec_context would then return GSS_S_FAILURE afterwards which is
a bit odd but maybe fine.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 23 Aug 2012 10:07:46 +0200

Another minor nit:

   If the client gets an error message from the server it MUST send an
   empty client response consisting of a single %x01 (control A)
   ^^^^^
   character, which is a correctly formatted client response with no
   key/value pairs.  The server then completes the SASL negotiation with
   a failure result.

A message with a single %x01 in it is not an empty message.  I suggest
to remove the word "empty" from this paragraph (and, from the text I
suggested in the last email).

/Simon

---

From: William Mills <[email-masked]>
Date: Thu, 23 Aug 2012 08:18:45 -0700 (PDT)

To be honest, the gs2-header looks really annoying to parse.  It's 2 or 3 fields and the termination of the second field is either the comma or just the end of an authz ID.  It needs some boundary between that and the first key name.

>Sent: Thursday, August 23, 2012 12:47 AM

---

From: William Mills <[email-masked]>
Date: Thu, 23 Aug 2012 08:26:02 -0700 (PDT)

Fixed the error sequence language, thank you.

>Sent: Thursday, August 23, 2012 1:05 AM
>Subject: Re: OAuth SASL new version -05
>

---

From: William Mills <[email-masked]>
Date: Thu, 23 Aug 2012 08:26:55 -0700 (PDT)

OK

>Sent: Thursday, August 23, 2012 1:07 AM

---

From: William Mills <[email-masked]>
Date: Thu, 23 Aug 2012 16:00:10 -0700 (PDT)

I've decided I don't care whether the control A following the gs2-eader is removed or not.  I'm going to strike that text in the GS2 section.

>Sent: Thursday, August 23, 2012 8:18 AM

---

From: Nico Williams <[email-masked]>
Date: Thu, 23 Aug 2012 18:19:08 -0500

On Thu, Aug 23, 2012 at 6:00 PM, William Mills <[email-masked]> wrote:
> I've decided I don't care whether the control A following the gs2-eader is
> removed or not.  I'm going to strike that text in the GS2 section.

Only the gs2 header needs to be removed.  The rest needs to stay.
That's because that's how a SASL/GS2 w/ GSS implementation will work:
strip out the gs2 header from the message, prefix the gs2 header to
the CB data, pass to GSS.

Nico
--

---

From: William Mills <[email-masked]>
Date: Thu, 23 Aug 2012 16:22:50 -0700 (PDT)

Thanks.

Now my only remaining question for the moment is "did I do anything silly in the examples?"

> From: Nico Williams <[email-masked]>
>Cc: Simon Josefsson <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Thursday, August 23, 2012 4:19 PM

---

From: Luke Howard <[email-masked]>
Date: Fri, 24 Aug 2012 16:41:25 +1000

If it helps, look at the GS2 plugin in Cyrus SASL.

-- Luke

--
Luke Howard / [email-masked]
www.padl.com / www.lukehoward.com

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 24 Aug 2012 09:18:48 +0200

William Mills <[email-masked]> writes:

> To be honest, the gs2-header looks really annoying to parse.  It's 2
> or 3 fields and the termination of the second field is either the
> comma or just the end of an authz ID.  It needs some boundary between
> that and the first key name.

I don't think it is difficult to parse.  There is no ambiguity wheter 2
or 3 fields are present: just check whether the first character is F or
p/n/y and you know.

Btw, the gs2-nonstd-flag part is not relevant here, as it would never be
used by this SASL/GSSAPI mechanism.  I suggest using a simpler
gs2-header like this:

    simple-gs2-header = gs2-cb-flag "," [gs2-authzid] ","

Btw, you could consider using "," instead of %x01 as the separator for
other fields, then you could reuse the parser for the gs2-header part
for the rest of the fields.  Compare how SCRAM looks:

C: n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL
S: r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096
C: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=
S: v=rmF9pqV8S7suAoZWja4dJRkFsKQ=

Here the gs2-header part is "n,," and the rest of the fields are SCRAM
fields.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 24 Aug 2012 09:20:33 +0200

> If it helps, look at the GS2 plugin in Cyrus SASL.

Or for those allergic to GSS-API, presumably, the SCRAM plugin in Cyrus
SASL.  Or the GS2/SCRAM mechanisms in GNU SASL for that matter. :-)

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 24 Aug 2012 10:36:05 +0100

(Speaking as a potential implementor.)

> or 3 fields are present: just check whether the first character is F or
Right.
>      simple-gs2-header = gs2-cb-flag "," [gs2-authzid] ","
If this is used, I would like to see a comment saying that this still 
complies with the more generic syntax specified for GS2.
> for the rest of the fields.
I like that!
> Compare how SCRAM looks: