Subject: Comments on draft-mills-kitten-sasl-oauth-00.txt

From: Alexey Melnikov <[email-masked]>
Date: Mon, 26 Jul 2010 22:52:26 +0200

Hi William/Tim/Hannes,
Thanks for doing this draft.
I am CCing my comments to the Kitten Working Group, where the document was discussed today during the Kitten Working Group meeting.

3.2.  Server's Response

   The server validates the response as per the OAuth specification.  If
   the protected resource requires a signed request (using one of the
   available signature method), the URL for the resource being
   authenticated is reconstructed per the OAuth specification from the
   HTTP style request passed by the client.

I think the document needs more details about how resources for 
something like IMAP are described. An example would be helpful.

3.5.  Formal Syntax of Messages

       user = 'User:' SPACE field-value CRLF

       host = 'Host:' SPACE field-value CRLF

       authorization = 'Authorization:' SPACE field-value CRLF

You need to replace <'> with <"> above, or otherwise it is not a valid ABNF.

The document needs to describe character set used for usernames and 
passwords. I think you meant UTF-8, but this is not clear from the document.

5.1.  Successful Bearer Token Exchange

   This example shows a successful OAuth 2.0 bearer token exchange with
   an initial client response.  Note that line breaks are inserted for
   readability.

   S: * IMAP4rev1 Server Ready
   C: t0 CAPABILITY
   S: * CAPABILITY IMAP4rev1 AUTH=OAUTH
   S: t0 OK Completed
   C: t1 AUTHENTICATE OAUTH R0VUIC8gSFRUUC8xLjENClVzZXI6IHNjb290ZXJAYWx0
         YXZpc3RhLmNvbQ0KSG9zdDogaW1hcC55YWhvby5jb20NCkF1dGhvcml6YXRpb24
         6IFRva2VuIHRva2VuPSJ2RjlkZnQ0cW1UYzJOdmIzUmxja0JoYkhSaGRtbHpkR0
         V1WTI5dENnPT0iDQoNCg==

This is not a valid IMAP protocol, because in the base IMAP the AUTHENTICATE command doesn't have the second parameter, unless the SASL-IR IMAP capability is also advertised.
You also need to add the reference to the document that defines the SASL-IR capability as an Informative reference.
(I don't remember the RFC number of the top of my head, but if you can't find it, I can find it for you.)

   S: +
   S: t1 OK SASL authentication succeeded

5.2.  Failed Exchange

   This example shows a failed exchange because of the empty
   Authorization header, which is how a client can query for discovery
   information.  Note that line breaks are inserted for readability.

   S: * IMAP4rev1 Server Ready
   C: t0 CAPABILITY&nbsp;

&nbsp; should be removed :-).

   S: * CAPABILITY IMAP4rev1 AUTH=OAUTH SASL-IR
   S: t0 OK Completed
   C: t1 AUTHENTICATE OAUTH R0VUIC8gSFRUUC8xLjENClVzZXI6IHNjb290ZXJAYW
      x0YXZpc3RhLmNvbQ0KSG9zdDogaW1hcC55YWhvby5jb20NCkF1dGhlbnRpY2F0ZT
      ogDQoNCg==
   S: + V1dXLUF1dGhlbnRpY2F0ZTogcmVhbG09ImltYXAueWFob28uY29tIiwgYXV0aH
      otdXJpPSJodHRwczovL2xvZ2luLnlhaG9vLmNvbS9vYXV0aCIsIHRva2VuLXVyaT
      0iaHR0cHM6Ly9sb2dpbi55YWhvby5jb20vb2F1dGgiLCBhbGdvcml0aG09ImhtYW
      Mtc2hhMjU2Ig0KDQo=

This is not a valid IMAP either, as the client needs to respond to the server challenge with an empty response or an abort.
("*"). This can't be combined with the final server response containing the tagged NO.

   S: t1 NO SASL authentication failed

In the Security Considerations section you are missing a Normative 
reference to the document that specifies TLS 1.2.

This SASL mechanism doesn't seem to allow for SASL authorization 
identity, i.e. when the client authenticates as one user, but then 
requests authorization to act as another user. This is pretty much a 
required feature for all modern SASL authentication mechanisms.