Subject: Re: [kitten] OAuth SASL Draft Update

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 10 Feb 2013 12:17:46 -0000

Hi Jeff,

thanks for your review comments.

I guess you are right that we got the description of the GSS flags wrong. I 
can just speculate why we made that mistake but it could be rooted in the 
complex relationship between SASL and the GSS-API. Maybe that's just an 
excuse from my side. Unfortunately, it seems that this is also the case for 
some previously published specifications (such as the SASL SAML document).
In any case, your comments came at the right time and I will provide a text 
proposal with the correct description in a separate mail.

Regarding the security consideration section you are right that we could 
have provided more text. However, that text already exists with RFC 6819 and 
we didn't want to repeat everything here again.
The difference between the the SASL / GSS usage of OAuth and the HTTP usage 
is fairly small (intentionally); we are actually only talking about a 
different layer of encapsulation for the communication between the client 
and the resource server (speaking in OAuth terms).

So, I could instead just reference the respective documents that explain 
security characteristics of OAuth.
I will also post a text proposal to the list and then we can see which 
approach you like better.

Ciao
Hannes

-----Original Message----- 
From: Jeffrey Hutzelman
Sent: Monday, December 17, 2012 9:55 PM
To: Hannes Tschofenig
Cc: [email-masked] ; [email-masked]
Subject: Re: [kitten] OAuth SASL Draft Update

On Mon, 2012-12-17 at 19:51 +0200, Hannes Tschofenig wrote:
> 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

> 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

---

From: Bill Mills <[email-masked]>
Date: Sun, 10 Feb 2013 08:55:00 -0800

On the security considerations section stuff...  One of the nuances here is that we're mapping an authorization mechanism (OAuth token usage at a protected resource) onto an authentication framework (SASL).  That might be worth calling out.

I'm with Hannes here in that we want to reference the extensive security discussion that's been done around OAuth and the different possible token types, we don't want to include it directly, especially as some are as yet to be written.  I short we can't cover the entire range of security considerations.  Is it sufficient to add to the fist paragraph (or modify the last sentence) to explicitly say "This SASL mechanism is extensible to support OAuth token types that are not yet defined, implementers MUSTtake into account the security considerations for the specific token types they implement and apply those to the context the SASL mechanism is being implemented for."

________________________________
 From: Hannes Tschofenig <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]> 
Cc: [email-masked]; [email-masked] 
Sent: Sunday, February 10, 2013 4:17 AM
Subject: Re: [kitten] OAuth SASL Draft Update
 
Hi Jeff,

I guess you are right that we got the description of the GSS flags wrong. I can just speculate why we made that mistake but it could be rooted in the complex relationship between SASL and the GSS-API. Maybe that's just an excuse from my side. Unfortunately, it seems that this is also the case for some previously published specifications (such as the SASL SAML document).
In any case, your comments came at the right time and I will provide a text proposal with the correct description in a separate mail.

Regarding the security consideration section you are right that we could have provided more text. However, that text already exists with RFC 6819 and we didn't want to repeat everything here again.
The difference between the the SASL / GSS usage of OAuth and the HTTP usage is fairly small (intentionally); we are actually only talking about a different layer of encapsulation for the communication between the client and the resource server (speaking in OAuth terms).

So, I could instead just reference the respective documents that explain security characteristics of OAuth.
I will also post a text proposal to the list and then we can see which approach you like better.

Ciao
Hannes

-----Original Message----- From: Jeffrey Hutzelman
Sent: Monday, December 17, 2012 9:55 PM
To: Hannes Tschofenig
Cc: [email-masked] ; [email-masked]
Subject: Re: [kitten] OAuth SASL Draft Update

On Mon, 2012-12-17 at 19:51 +0200, Hannes Tschofenig wrote:
> Hi all,
> 
> I thought I should submit the current draft snapshot. Here is the current version:

-- Jeff

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

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 22 Feb 2013 11:19:28 +0100

Hi Jeff, 

it's me again on the same review comments. 

Given the approaching draft submission deadline I tried to come up with a way to address your comments. 

So, I took a look at other published SASL mechanisms to sort of use an existing writeup as a template to meet the expectations from the working group. Here is the list of standardized mechanisms:
http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xml

To my surprise I had to notice that my text is not any worse that what others had written in their documents. In fact, I would even argue that the OAuth SASL writeup (if you consider the companion threat analysis from RFC 6819  http://tools.ietf.org/html/rfc6819) far exceeds any of the published mechanisms so far. 

What are the expectations regarding SASL methods when it comes to the security consideration section writeup and to the design of the mechanisms in general? In EAP, for example, the requirements are outlined in RFC 4017 http://www.ietf.org/rfc/rfc4017.txt. Many EAP method documents describe what properties their method offers based on the content of RFC 4017. 

I don't think RFC 4017 is directly applicable to SASL/GSS-API methods since the architecture is different. Is there something similar available? 

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Mon, 17 Dec 2012 16:55:48 -0500
> Von: Jeffrey Hutzelman <[email-masked]>
> An: Hannes Tschofenig <[email-masked]>
> CC: [email-masked], [email-masked]
> Betreff: Re: [kitten] OAuth SASL Draft Update