Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-01.txt

From: [email-masked]
Date: Wed, 30 May 2012 12:02:26 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF.

	Title           : A SASL and GSS-API Mechanism for OAuth
	Author(s)       : William Mills
                          Tim Showalter
                          Hannes Tschofenig
	Filename        : draft-ietf-kitten-sasl-oauth-01.txt
	Pages           : 21
	Date            : 2012-05-30

   OAuth enables a third-party application to obtain limited access to a
   protected resource, either on behalf of a resource owner by
   orchestrating an approval interaction, or by allowing the third-party
   application to obtain access on its own behalf.

   This document defines how an application client uses OAuth over the
   Simple Authentication and Security Layer (SASL) or the Generic
   Security Service Application Program Interface (GSS-API) to access a
   protected resource at a resource serve.  Thereby, it enables schemes
   defined within the OAuth framework for non-HTTP-based application
   protocols.

   Clients typically store the user's long term credential.  This does,
   however, lead to significant security vulnerabilities, for example,
   when such a credential leaks.  A significant benefit of OAuth for
   usage in those clients is that the password is replaced by a token.
   Tokens typically provided limited access rights and can be managed
   and revoked separately from the user's long-term credential
   (password).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-oauth-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-sasl-oauth-01.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/

---

From: William Mills <[email-masked]>
Date: Wed, 30 May 2012 14:57:08 -0700 (PDT)

This draft rips out the HTTP style format and in band discovery.  Feedback would be very welcome.

Many thanks to Alexey for helping me get this posted.

-bill

>________________________________
> From: "[email-masked]" <[email-masked]>
>To: [email-masked] 
>Cc: [email-masked] 
>Sent: Wednesday, May 30, 2012 12:02 PM
>Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-01.txt
> 
>
>_______________________________________________
>Kitten mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/kitten
>
>
>

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 31 May 2012 09:07:45 +0200

This version looks much better to me -- thanks!

As we discovered for RFC 6595, you may want to expand the TLS
certificate verification text with some RFC 6125 wording.  See fifth
paragraph of section 4 of RFC 6595.  It should also explain which
identity string is compared to what's in the certificate.

Also, it seems this variant supports the PLUS channel-binding enabled
variant (I have not read the draft in detail there, but it is
mentioned), so shouldn't it then also be able to support per-message
tokens and GSS_Pseudo_random?  This could be done similar to SAML20EC
(which is work in progress, but the mechanism it eventually uses could
be the same).

/Simon

---

From: William Mills <[email-masked]>
Date: Thu, 31 May 2012 07:56:45 -0700 (PDT)

> From: Simon Josefsson <[email-masked]>
>To: William Mills <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]> 
>Sent: Thursday, May 31, 2012 12:07 AM
>Subject: Re: I-D Action: draft-ietf-kitten-sasl-oauth-01.txt
> 

I'll take a look, thanks.

>(which is work in progress, but the mechanism it eventually uses could

Yes, it's -PLUS instead of doing CB in a single profile.  In the draft it
discusses the fact that some auth profiles have secrets that can be used
for per message signing, so I think it COULD support per message tokens. If
there is no shared secret to use I don't think there's a way to bootstrap 

this in channel that increases the security properties.

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 31 May 2012 15:00:40 +0000

>this in channel that increases the security properties.

I have the same issue, but I'm told that some application usage of GSS
require this, even if it's not secure. I've basically settled on passing a
nonce up from the client as the simplest option and one that makes the
lack of security self-evident.

The other point is that when there is a key, deriving the session key is
going to require some algorithm-specific language somewhere, and it would
be nice if the SAML mechanism and the OAuth mechanism used the same key
derivations.

-- Scott