Subject: Re: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18

From: Alexey Melnikov <[email-masked]>
Date: Thu, 1 Jan 2015 17:46:15 +0000

> On 31 Dec 2014, at 19:27, Benjamin Kaduk <[email-masked]> wrote:
> 
> We've gotten some "looks good"s on the oauth list, for those only on
> kitten@.
> 
> Just under two weeks remain in the last call period.

I generally think that the document has improved recently and it is very close to being done. But I think examples in particular need to be fixed (and I am sorry if I sound like a broken record on this, but I believe that examples are very important, as some people will just code based on them).

In 3.1:

key = 1*(ALPHA / ",")

So the key can be a single comma character, right?
client_resp    = (gs2-header kvsep 0*kvpair kvsep) / kvsep

Did you mean that the whole client response can be just a single separator character? I think this is not compatible with GS2 framing. If you only meant to allow that for failed authentication, I suggest you add a comment and point to section 3.2.3.
In 3.2:

Nit:
 Note that the semantics of the authz-id is specified by
   the SASL framework [RFC4422].
If this is the same as "authzid" introduced in section 3.1, then you should remove dash. (I was wondering if this is something else). But I think expanding this to be "authorization identity" would be better.

In 3.2.2:
oauth-configuration (OPTIONAL):  The URL for for a document
         following the OpenID Provider Configuration Information schema
         as described in OpenID Connect Discovery
I think it would help to clarify that the returned value is always an https (or http?) URI. If that can be something else, saying that would be great too.

In 3.2.3:

I think you don't need to have an explicit message to cancel authentication, you can just use the SASL framework facility for this. In IMAP that would be emitted as "*\r\n".

In particular, I think Cyrus SASL based implementations can handle "here is some data from the server, but this step produces failure on the client side, so the client need to cancel the exchange" just fine.

In 4.1:

I think you need to explain that the example is only valid in the presence of SASL-IR capability (and add an Informative reference), because the initial client response parameter to AUTHENTICATE is only allowed when SASL-IR is advertised. Or you can just use an SMTP example here.

Examples in 4.1, 4.3 and 4.4 don't show negotiation of TLS, which is a MUST level requirement for AUTHBEARER SASL mechanism (as per section 5), so you should fix examples to advertise STARTTLS capability and show use of STARTTLS command.

If you would like me to provide full examples, let me know and I do that.

> 
> -Ben
> 
>> On Mon, 15 Dec 2014, Benjamin Kaduk wrote:
>> 
>> This message begins the fourth Working Group Last Call (WGLC) of "A set of
>> SASL Mechanisms for OAuth" <draft-ietf-kitten-sasl-oauth-18.txt>.  Due to
>> the overlap of the last call period with holidays, the duration of the
>> WGLC is extended to four weeks, so the WGLC will end on 12 January 2015.
>> The draft is available at:
>> 
>> https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18
>> 
>> Because the changes between -15 and -18 involve behavior changes,
>> including changes regarding discovery and dynamic registration, the Chairs
>> decided to issue an additional last call.
>> 
>> Please review the document and send comments to the Working Group
>> mailing list < kitten at itef.org > or the co-chairs < kitten-chairs
>> at tools.ietf.org > before the end of the WGLC.  Any and all comments
>> on the document are sought in order to access the strength of
>> consensus.  Even if you have read and commented on this or earlier
>> versions of the draft, please feel free to comment again.  This is
>> particularly important if you found issues with the previous version.
>> 
>> As a reminder, comments can be anything from "this looks fine" to
>> "this is a horrible idea"; they can include suggestions for minor
>> editorial corrections to significant editorial changes.
>> 
>> 
>> - Your Kitten Chairs
>> 
>> _______________________________________________
>> 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: Bill Mills <[email-masked]>
Date: Sat, 3 Jan 2015 00:56:47 +0000 (UTC)

"key = 1*(ALPHA / ",")" This was an ill advised hack to allow the GS2 header to appear as a key.  Removing the comma since this now explicitly uses the gs2-header..
re 3.2: changed to authorization identity. 
re SASL-IR: added a note in the top of the examples section and an informative reference to 4959.
re 3.2.2 and the OpendID configuration URL.  That spec requires "https" explicitly already.  Repeat that here?  Easy to cite that spec and say HTTPS is required but I usually try not to repeat things defined other places.
3.2.3 and an explicit message:  Long ago in the life of this doc I was told that some implementations may not support an empty message, so we put the single character message there to have an explicit payload.  I'm a bit leery of changing this now since there are implementations in play that use it this way.

On requiring TLS and adding STARTTLS to the examples: your'e not happy with the current "Note that line  breaks are inserted for readability and the underlying TLS establishment is not shown either."?  I'd prefer to add text saying something like "These Bearer token examples assume encrypted transport, if the underlying connection is not already TLS then STARTTLS MUST be used as required in the Bearer Token specification.".  I can also easily specify that this is IMAP over 995 or SMTP over 465.

  On Thursday, January 1, 2015 9:41 AM, Alexey Melnikov <[email-masked]> wrote:

I generally think that the document has improved recently and it is very close to being done. But I think examples in particular need to be fixed (and I am sorry if I sound like a broken record on this, but I believe that examples are very important, as some people will just code based on them).
In 3.1:
key = 1*(ALPHA / ",")
So the key can be a single comma character, right?client_resp    = (gs2-header kvsep 0*kvpair kvsep) / kvsep

Did you mean that the whole client response can be just a single separator character? I think this is not compatible with GS2 framing. If you only meant to allow that for failed authentication, I suggest you add a comment and point to section 3.2.3.In 3.2:
Nit: Note that the semantics of the authz-id is specified by
   the SASL framework [RFC4422].
If this is the same as "authzid" introduced in section 3.1, then you should remove dash. (I was wondering if this is something else). But I think expanding this to be "authorization identity" would be better.
In 3.2.2:oauth-configuration (OPTIONAL):  The URL for for a document
         following the OpenID Provider Configuration Information schema
         as described in OpenID Connect Discovery
I think it would help to clarify that the returned value is always an https (or http?) URI. If that can be something else, saying that would be great too.
In 3.2.3:
I think you don't need to have an explicit message to cancel authentication, you can just use the SASL framework facility for this. In IMAP that would be emitted as "*\r\n".
In particular, I think Cyrus SASL based implementations can handle "here is some data from the server, but this step produces failure on the client side, so the client need to cancel the exchange" just fine.
In 4.1:
I think you need to explain that the example is only valid in the presence of SASL-IR capability (and add an Informative reference), because the initial client response parameter to AUTHENTICATE is only allowed when SASL-IR is advertised. Or you can just use an SMTP example here.

-Ben

- Your Kitten Chairs

Kitten mailing list

[email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 4 Jan 2015 11:42:22 +0000

Hi Bill,

> On 3 Jan 2015, at 00:56, Bill Mills <[email-masked]> wrote:
> 

I didn't suggest you should be sending empty message. I said you should be using SASL cancellation token, which is a mandatory RFC 4422 feature.

Any implementation would have to support this mode of operation anyway, because a SASL client can cancel any exchange.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 4 Jan 2015 11:46:10 +0000

Hi Bill,

> On requiring TLS and adding STARTTLS to the examples: your'e not happy with the current "Note that line 	breaks are inserted for readability and the underlying TLS establishment is not shown either."?  I'd prefer to add text saying something like "These Bearer token examples assume encrypted transport, if the underlying connection is not already TLS then STARTTLS MUST be used as required in the Bearer Token specification.".

Yes, that would work and I think your expanded text is better.

>  I can also easily specify that this is IMAP over 995

993
> or SMTP over 465.

I suggest you don't do that, because neither port 993 nor 465 are registered with IANA. I know it is not your problem, but there is no point in potentially getting this document delayed by this.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 4 Jan 2015 11:49:34 +0000

Hi Bill,

> re 3.2.2 and the OpendID configuration URL.  That spec requires "https" explicitly already.  Repeat that here?  Easy to cite that spec and say HTTPS is required but I usually try not to repeat thin…

I would prefer if you add "as per XXX spec, this is always "https" URL". This might be obvious for somebody who knows OpenID specs in details, but I think this sort reminder would help implementors who don't have time to research this in details.

Best Regards,
Alexey

---

From: Bill Mills <[email-masked]>
Date: Mon, 5 Jan 2015 05:14:21 +0000 (UTC)

Ah OK.  This is a significant change.  Can we make using the cancellation token optional?  The extant implementations use the current sequence.
-bill

     On Sunday, January 4, 2015 3:37 AM, Alexey Melnikov <[email-masked]> wrote:

 Hi Bill,

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 05 Jan 2015 12:40:07 +0000

On 05/01/2015 05:14, Bill Mills wrote:
> Ah OK.  This is a significant change.  Can we make using the 
> cancellation token optional?
Not really. Any protocol needs to define the cancellation token 
(according to RFC 2244) and any mechanism implementation (or SASL 
framework library) that doesn't complete in 1 round trip need to be able 
to handle it.

I think it is Ok not to change the spec, but it would be a good idea to 
point out that standard SASL cancellation token can still be used. 
Adding an example would be even better.
> The extant implementations use the current sequence.
>
> -bill
>
> > On 3 Jan 2015, at 00:56, Bill Mills <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >
> > 3.2.3 and an explicit message:  Long ago in the life of this doc I 
> was told that some implementations may not support an empty message, 
> so we put the single character message there to have an explicit 
> payload. I'm a bit leery of changing this now since there are 
> implementations in play that use it this way.
>
>
> I didn't suggest you should be sending empty message. I said you 
> should be using SASL cancellation token, which is a mandatory RFC 4422 
> feature.
>
> Any implementation would have to support this mode of operation 
> anyway, because a SASL client can cancel any exchange.

---

From: Bill Mills <[email-masked]>
Date: Tue, 6 Jan 2015 19:06:45 +0000 (UTC)

Can you point me at an exampel of a cancellation token? 

     On Monday, January 5, 2015 4:41 AM, Alexey Melnikov <[email-masked]> wrote:

   Ah OK.  This is a significant change.  Can we make using the cancellation token optional?   
 Not really. Any protocol needs to define the cancellation token (according to RFC 2244) and any mechanism implementation (or SASL framework library) that doesn't complete in 1 round trip need to be able to handle it.
 
 I think it is Ok not to change the spec, but it would be a good idea to point out that standard SASL cancellation token can still be used. Adding an example would be even better.

 Hi Bill,

---

From: Bill Mills <[email-masked]>
Date: Tue, 6 Jan 2015 19:09:01 +0000 (UTC)

and you did mean 4422 not 2244 right? 

     On Tuesday, January 6, 2015 11:06 AM, Bill Mills <[email-masked]> wrote:

 

 

 Hi Bill,

---

From: Bill Mills <[email-masked]>
Date: Tue, 6 Jan 2015 19:11:17 +0000 (UTC)

never mind, you did mean 2244 

     On Tuesday, January 6, 2015 11:09 AM, Bill Mills <[email-masked]> wrote:

 

 

 Hi Bill,

---

From: Bill Mills <[email-masked]>
Date: Tue, 6 Jan 2015 21:36:35 +0000 (UTC)

" The client MUST then send either an additional client response consisting of a single %x01 (control A) character to the server in order to allow the server to finish the exchange or send a SASL cancellation token as defined in ACAP[RFC2244] section 6.3.1." 

 Hi Bill,

---

From: Bill Mills <[email-masked]>
Date: Tue, 6 Jan 2015 21:37:48 +0000 (UTC)

Added the proposed text. 

     On Sunday, January 4, 2015 3:41 AM, Alexey Melnikov <[email-masked]> wrote:

 Hi Bill,

993

or SMTP over 465.

---

From: Bill Mills <[email-masked]>
Date: Tue, 6 Jan 2015 21:39:18 +0000 (UTC)

Updated that section:
"The URL for a document following the OpenID Provider Configuration Information schema as described in OpenID Connect Discovery (OIDCD) [OpenID.Discovery] section 3 that is appropriate for the user. As specified in OIDCD this will have the "https" URL scheme. " 

     On Sunday, January 4, 2015 3:46 AM, Alexey Melnikov <[email-masked]> wrote:

 Hi Bill,

Best Regards,
Alexey

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 7 Jan 2015 12:57:53 -0500 (EST)

Bill, Alexey,

Thanks for working through these comments (I'm still catching up after the
holidays) -- I do agree with Alexey that having the examples right is very
important.

Looking through this thread, I don't see a response to one of Alexey's
comments, though:

% client_resp    = (gs2-header kvsep 0*kvpair kvsep) / kvsep
%
% Did you mean that the whole client response can be just a single separator
% character? I think this is not compatible with GS2 framing. If you only meant to
% allow that for failed authentication, I suggest you add a comment and point to
% section 3.2.3.

If I correctly remember how things work, I think that Alexey is right that
this is only allowed for failed authentication, so a comment is needed
here.

-Ben

---

From: Bill Mills <[email-masked]>
Date: Wed, 7 Jan 2015 18:12:00 +0000 (UTC)

Added 
"The client response consisting of only a single kvsep is used only when authentication fails, and is only valid in that context. If sent as the first message from the client the server MAY simply fail the authentication without returning discovery information since there is no user or server name indication."

     On Wednesday, January 7, 2015 9:57 AM, Benjamin Kaduk <[email-masked]> wrote:

 Bill, Alexey,

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 7 Jan 2015 20:59:16 -0500 (EST)

Seems reasonable here; let's see what it looks like in the next revision.
(Do you keep your working copy somewhere public?  I have forgotten.)

Thanks,

Ben

---

From: Bill Mills <[email-masked]>
Date: Thu, 8 Jan 2015 06:40:41 +0000 (UTC)

I didn't before.
http://htmlpreview.github.io/?https://github.com/sweetums/idrafts/blob/master/draft-ietf-kitten-sasl-oauth-19.html

     On Wednesday, January 7, 2015 5:59 PM, Benjamin Kaduk <[email-masked]> wrote:

Thanks,

Ben

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 8 Jan 2015 09:54:36 +0000

Hi Bill,

> On 6 Jan 2015, at 21:36, Bill Mills <[email-masked]> wrote:
> 

Actually I meant RFC 4422 (SASL). ACAP has cancellation token, but so does IMAP, SMTP, LDAP,...

If you like, I send you an IMAP example.

---

From: Bill Mills <[email-masked]>
Date: Thu, 8 Jan 2015 16:05:38 +0000 (UTC)

You're talking about 3.5 in 4422?  To me it looks like the single kvsep message looks exactly like the abort message that needs to be defined by the protocol? 

     On Thursday, January 8, 2015 1:49 AM, Alexey Melnikov <[email-masked]> wrote:

 Hi Bill,

 Hi Bill,

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 9 Jan 2015 12:23:14 +0000

Hi Bill,

> On 8 Jan 2015, at 16:05, Bill Mills <[email-masked]> wrote:
> 
> You're talking about 3.5 in 4422?

Yes.

> To me it looks like the single kvsep message looks exactly like the abort message that needs to be defined by the protocol?

No, it is a SASL protocol mapping construct (defined once for all mechanisms), you defined a SASL mechanism construct.

---

From: Bill Mills <[email-masked]>
Date: Fri, 9 Jan 2015 23:09:29 +0000 (UTC)

OK, understanding this better.  See the current changes in 3.2.3 and 4.3 with an example for IMAP in http://htmlpreview.github.io/?https://github.com/sweetums/idrafts/blob/master/draft-ietf-kitten-sasl-oauth-19.html
-bill 

     On Friday, January 9, 2015 4:19 AM, Alexey Melnikov <[email-masked]> wrote:

 Hi Bill,

Yes.

 Hi Bill,

 Hi Bill,

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 14 Jan 2015 17:07:02 -0500 (EST)

On Fri, 9 Jan 2015, Bill Mills wrote:

> OK, understanding this better.  See the current changes in 3.2.3 and 4.3
> with an example for IMAP
> in http://htmlpreview.github.io/?https://github.com/sweetums/idrafts/blob/master/draft-ietf-kitten-sasl-oauth-19.html

Hmm, I think the text "or send a SASL cancellation token as generally
defined in section 6.3.1" in section 3.2.3 of the linked document needs to
specify what document's section 6.3.1 it is referring to.  (This document
has no such section, and neither does RFC 4422; RFC 3501 has such a
section but it doesn't seem like what was intended.)

Alexey, are you satisfied by text that gives these two options?  Do you
think any of your comments remain unaddressed?

Thanks,

Ben

---

From: Bill Mills <[email-masked]>
Date: Wed, 14 Jan 2015 22:28:41 +0000 (UTC)

Corrected this to "3.5 of SASL", 6.3.1 related to a previously wrongly cited spec.  Link updated. 

     On Wednesday, January 14, 2015 2:07 PM, Benjamin Kaduk <[email-masked]> wrote:

Thanks,

Ben

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 16 Jan 2015 19:18:39 +0000

Hi Ben,

> think any of your comments remain unaddressed?
I am happy with the latest version that Bill produced (see his other email).

---

From: Bill Mills <[email-masked]>
Date: Fri, 16 Jan 2015 19:48:55 +0000 (UTC)

Thanks for the good feedback Alexey.  I'm much happier with it now. 

     On Friday, January 16, 2015 11:21 AM, Alexey Melnikov <[email-masked]> wrote:

 Hi Ben,

---

From: Bill Mills <[email-masked]>
Date: Tue, 20 Jan 2015 21:50:00 +0000 (UTC)

So is this one ready now for -19 to be published?  WGLC done? 

     On Friday, January 16, 2015 5:19 PM, Bill Mills <[email-masked]> wrote:

 Hi Ben,

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 20 Jan 2015 16:54:54 -0500 (EST)

> I am happy with the latest version that Bill produced (see his other email).

Thanks for the confirmation.  I will go ahead and start on the shepherd
writeup to send this to Stephen.

-Ben

---

From: Bill Mills <[email-masked]>
Date: Tue, 20 Jan 2015 21:59:14 +0000 (UTC)

SO you need a -19 now correct? 

     On Tuesday, January 20, 2015 1:54 PM, Benjamin Kaduk <[email-masked]> wrote:

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 20 Jan 2015 16:59:51 -0500 (EST)

Yes, please submit the -19 to the datatracker.

-Ben