Subject: [kitten] OAuth SASL Draft Update

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 17 Dec 2012 19:51:47 +0200

Hi all, 

I thought I should submit the current draft snapshot. Here is the current version: 
http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-09

Version -09 of the draft contains: 
o Incorporated review comments from Alexey and myself.	
o Clarified the three OAuth SASL mechanisms.	
o Updated references.	
o Extended acknowledgements.

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-sasl-oauth-09

I am not sure it completely addresses the remarks from Alexey regarding 'Canonicalization', see  
http://www.ietf.org/mail-archive/web/kitten/current/msg03670.html

I have replaced the sub-section about Canonicalization with a separate internationalization section. 

Ciao
Hannes

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 17 Dec 2012 16:55:48 -0500

> OAuth mechanims security contexts always have the mutual_state flag
>    (GSS_C_MUTUAL_FLAG) set to TRUE.  OAuth supports credential
>    delegation, therefore security contexts may have the deleg_state flag
>    (GSS_C_DELEG_FLAG) set to either TRUE or FALSE.
> 
>    The mutual authentication property of this mechanism relies on
>    successfully comparing the TLS server identity with the negotiated
>    target name.  Since the TLS channel is managed by the application
>    outside of the GSS-API mechanism, the mechanism itself is unable to
>    confirm the name while the application is able to perform this
>    comparison for the mechanism.  For this reason, applications MUST
>    match the TLS server identity with the target name using the
>    appropriate application profile, as discussed in [RFC6125].  For
>    example, when SASL OAuth is run over IMAP then the IMAP profile of
>    RFC 6125 is used.

So in other words, this mechanism does _not_ provide mutual auth.  The
mutual_state flag indicates that the _mechanism_ has authenticated the
server.  Here, you are saying that the mechanism cannot do so, and so it
is up to the application to do so.  That's fine, but then you cannot set
mutual_auth, because that amounts to lying to the GSS-API application.

This is important, because GSS applications depend on this flag to know
whether they can depend on GSS-API channel bindings to bind the
enclosing channel to the server's identity.  That is, they use it to
know whether it is OK that they are _not_ checking the TLS server cert
(or whatever other channel is in use).

You're basically saying that when using this mechanism, the application
has to ignore mutual_state and assume the server is not authenticated
(and so, neither is the enclosing channel).  But you don't get to do
that; it violates the API abstraction.

Separately, I find the security considerations section in this document
to be wholly inadequate.  It basically says "there might be issues", but
with a couple of specific exceptions does not explore what they are,
whether or how the mechanism addresses them, or what steps should be
taken to mitigate them.  Please see RFC3552 for more information on what
should be in the Security Considerations section of an RFC.  Please pay
particular attention to the discussion in section 5, and especially to
the comments on what must be covered in the specific case of
authentication mechanisms.  IMHO the current document falls short in
this regard.

-- Jeff