[kitten] Alexey's comments Re: WGLC of draft-ietf-kitten-sasl-oauth-18

[Bill Mills <[e-mail]>]

"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 <[e-mail]> wrote:
   

 
On 31 Dec 2014, at 19:27, Benjamin Kaduk <[e-mail]> 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


[e-mail]


https://www.ietf.org/mailman/listinfo/kitten





_______________________________________________
Kitten mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/kitten


_______________________________________________
Kitten mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/kitten