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

From: Simon Josefsson <[email-masked]>
Date: Thu, 13 Sep 2012 09:14:24 +0200

Thanks for update,

Quick review of the text that have changed since -07 below.

Section 3.2:

   The authenticated identity reported
   by the mechanism is the identity which the mechanism has securely
   established for the client with the OAuth credential.

This confuses me, I believe the two uses of the word 'mechanism' refer
to different things.  Should it be:

   The authenticated identity reported by the SASL mechanism shall be
   the identity which the OAuth mechanism has securely established for
   the client with the OAuth credential.

?

I'm still not sure this is unambigious since OAuth may establish two
identities, of the user and the proxy.  I suspect "the identity" could
be qualified to be the user (and OAuth 1.x and 2.x uses different terms
here if I recall correctly).

Section 3.2.1:

   Note that the semantics of the authz-id are specified by the SASL
   framework [RFC4422].  A SASL application is, of course, free to apply
   mappings of the OAuth authcid to authz-ids as per-SASL, and it is
   free to apply mappings common to non-SASL OAuth applications.

The first sentence is great, but the term 'authz-id' should be
explained.

The second sentence is confusing.  First, there is no such thing as a
per-SASL authcid to authzid mapping: those mappings are by definition
always mechanism dependent, since the authcid form is mechanism
dependent.  Second, "authz-id" refer to the authorization identity
field, which can be empty, so what you want to map to is not the
authz-id but the general concept of the identity to act as.

I encourage you to re-read this part from RFC 4422:

   The client provides its credentials (which include or imply an
   authentication identity) and, optionally, a character string
   representing the requested authorization identity as part of the SASL
   exchange.  When this character string is omitted or empty, the client
   is requesting to act as the identity associated with the credentials
   (e.g., the user is requesting to act as the authentication identity).

So, I don't think your second sentence above adds any value, at least
the current text doesn't do it for me right now.  I would simply leave
it as:

   Note that the semantics of the authorization identity is specified by
   the SASL framework [RFC4422].

You don't have to say anything further than that.

Section 3.2.1:

   If both identities
   are needed by an application the developer will need to provide a way
   to communicate that from the SASL mechanism back to the application
   such as a GS2 [RFC2473] named type like GSS_C_NT_USER_NAME or a
   comparable newly defined GS2 attribute.

RFC 2743 (sic) is called GSS-API not GS2.  The final "GS2 attribute"
should be "GSS-API name type or name attribute [RFC 6680]".

Section 5.2:

   p,a=[email-masked]^A

This is wrong, you changed 'y' to 'p' which doesn't conform to the ABNF.
Please see my review comment of -06 on this.

/Simon

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 13 Sep 2012 10:23:58 +0300

Very quick response only. 

The term 'identity' is confusing here since we are really only talking about an identifier instead. 

OAuth 2.0 has the client authentication as part of the specification. There is a client identifier that is conveyed as part of that exchange. The Resource Owner authentication is not part of the specification itself and also the information about the authenticated Resource Owner, which would go into the Access Token, is not standardized either. 

What Bill tries to say in the draft is that there has to be a link between the identifier used in SASL and the identifier used for authentication of the Resource Owner in OAuth. (I don't think the client identifier matters here with respect to the SASL interaction as such.)

I don't think it makes sense to require the identifier used for authentication of the resource owner to be the same as the one in SASL but I believe we want to make sure that the Access Token contains information about what the matching identifier in SASL is. 

Does this make sense?

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 13 Sep 2012 09:49:04 +0200

Hannes Tschofenig <[email-masked]> writes:

> OAuth 2.0 has the client authentication as part of the
> specification. There is a client identifier that is conveyed as part
> of that exchange. The Resource Owner authentication is not part of the
> specification itself and also the information about the authenticated
> Resource Owner, which would go into the Access Token, is not
> standardized either.

This appears to reinforce our earlier agreement that the SASL authcid
for the OAuth mechanism should be the OAuth client identifier.

> What Bill tries to say in the draft is that there has to be a link
> between the identifier used in SASL and the identifier used for
> authentication of the Resource Owner in OAuth. (I don't think the
> client identifier matters here with respect to the SASL interaction as
> such.)

Right.  This can be achieved by saying:

   The OAuth client identifier is used as the SASL authentication
   identity in the OAuth SASL mechanism.

> I don't think it makes sense to require the identifier used for
> authentication of the resource owner to be the same as the one in SASL
> but I believe we want to make sure that the Access Token contains
> information about what the matching identifier in SASL is.

I'm losing you here...  what is the "matching identifier"?  Why would
you want to include any SASL identity in the OAuth access token?  It
works the other way around: SASL takes the mechanism identifiers and use
that as authcid.  The authzid is a SASL thing that mechanisms should
integrity protect but not parse.

Perhaps Kerberos can work as an analogy.  There clients requests a
ticket for the service before starting the SASL handshake.  However the
identity to get the ticket for is determined by things outside of SASL
(the server hostname).  For good or bad, SASL doesn't do naming.

> Does this make sense?  

Getting there..

/Simon

---

From: William Mills <[email-masked]>
Date: Thu, 13 Sep 2012 08:31:35 -0700 (PDT)

comment inline...  Thanks for the reading.

>________________________________
> From: Simon Josefsson <[email-masked]>
>To: [email-masked] 
>Sent: Thursday, September 13, 2012 12:14 AM
>Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-07.txt
> 
>Thanks for update,
>

Not my language here, but your language doesn't do it for me.  How about

   The authenticated identity reported by the mechanism is the user 

   identity securely established for the client with the OAuth credential.

>authz-id but the general concept of the identity to act as.

Not my language, please propose text.

>should be "GSS-API name type or name attribute [RFC 6680]".

fixed, thank you

>Please see my review comment of -06 on this.

I'll change it back, I changed it by request.

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

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 13 Sep 2012 21:44:48 +0200

>    The authenticated identity reported by the mechanism is the user 
                                                ^^^^^^^^^

Is this the SASL mechanism?

>    identity securely established for the client with the OAuth

Works for me, although Hannes indicated that "identity" is the wrong
term and "client identifier" would be more correct.

> Not my language, please propose text.

I did propose text further down in my reply:

And drop the second sentence.

> I'll change it back, I changed it by request.

Huh?  Please read my review comment of -06.  The 'y' was even more
incorrect.  You want 'p', but you must follow the ABNF and describe the
cbtype.  It could be:

p=tls-unique,a=[email-masked]

but it depends on what you want.

/Simon

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 13 Sep 2012 19:54:05 +0000

>term and "client identifier" would be more correct.

Hannes can correct me, but I thought (from memory) the client identifier
term referred not to the identity of the user as contained in the OAuth
token but to the identity presenting the token to the resource service.

In a user -> web site -> service flow, for example, I think you'd be
identifying the web site as the identity instead of the user, which is not
really the best one of the two to pick I wouldn't think.

Or I'm just wrong about the term's meaning.

-- Scott

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 13 Sep 2012 22:11:16 +0200

> token but to the identity presenting the token to the resource service.

Right.  Sorry, that's clearly not what I intended and I must have
misunderstood Hannes.  I'm fine with "identity".  Possibly "resource
owner's identity" is more exact.

> really the best one of the two to pick I wouldn't think.

Agreed.

/Simon

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 13 Sep 2012 20:14:29 +0000

>owner's identity" is more exact.

I think so too, but I think Hannes did say he thought the client
identifier should be used, so I was seeking clarification myself. Your
term would be what I would expect.

-- Scott

---

From: William Mills <[email-masked]>
Date: Thu, 13 Sep 2012 14:07:42 -0700 (PDT)

So is this now:

   The authenticated identity reported by the SASL mechanism is the 
   resource owner identity securely established for the client with 
   the OAuth credential.

?

----- Original Message -----
> From: "Cantor, Scott" <[email-masked]>
> To: Simon Josefsson <[email-masked]>
> Cc: William Mills <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Thursday, September 13, 2012 1:14 PM

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 14 Sep 2012 00:04:41 +0200

>    resource owner identity securely established for the client with 

This works for me, thank you!

/Simon

---

From: John Bradley <[email-masked]>
Date: Thu, 13 Sep 2012 19:30:33 -0300

The client identifier (client_id) is like a SAML entityID. The meta data the Authorization server knows about the client is keyed to that identifier.  
Things like the registered redirect URI , client secret and client type are keyed to it.

It is in no way a identifier for the user.  
OAuth 2 has no Identifier for the user, other than a parameter (username) it can pass to the token endpoint as a form encoded parameter in the "Resource Owner Password Grant" request.
It is only used for that and otherwise OAuth has no notion of user identity other than what might be implied by the access token in some protocols.

We extended OAuth in OpenID Connect to add a user_id to the response in the id_token.

Care needs to be taken in that just because you get a access token by passing in a username and password to the token endpoint that is not a guarantee that the username input is not a pseudonym or in any other way useful.   Information about the user is typically implicit in the access token.  

If I had to pass user info from the Authorization server to a protected resource (IMAP via sasl) I would send a signed JWT with the user_id to be used in the token.

That may not be what you are looking for however.

John B.

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 13 Sep 2012 23:32:48 +0000

On 9/13/12 6:30 PM, "John Bradley" <[email-masked]> wrote:

>The client identifier (client_id) is like a SAML entityID. The meta data
>the Authorization server knows about the client is keyed to that
>identifier.  

Right, thus my opinion about (not) using it as the SASL authcid.

>OAuth 2 has no Identifier for the user, other than a parameter (username)
>it can pass to the token endpoint as a form encoded parameter in the
>"Resource Owner Password Grant" request.
>It is only used for that and otherwise OAuth has no notion of user
>identity other than what might be implied by the access token in some
>protocols.

Right, which is up to the SASL mech to deal with and turn into a user
identity.

>Care needs to be taken in that just because you get a access token by
>passing in a username and password to the token endpoint that is not a
>guarantee that the username input is not a pseudonym or in any other way
>useful.   Information about the user is typically implicit in the access
>token.

That would be up to the mech to address by mapping the token to the state
associated with it on the server side.

>If I had to pass user info from the Authorization server to a protected
>resource (IMAP via sasl) I would send a signed JWT with the user_id to be
>used in the token.
>

As a generic framework, all of that is really beyond the scope of an OAuth
mechanism to define. All it can do is make it clear that the mech is
responsible in some way to get from the token to an identity.

-- Scott

---

From: William Mills <[email-masked]>
Date: Fri, 14 Sep 2012 15:50:10 -0700 (PDT)

OK, I've changed the main paragraphs in question a bit and renamed 3.2.1  the new text is: 

    The server responds to a successfully verified client message by completing 

    the SASL negotiation. The authenticated identity reported by the SASL mechanism 

    is the resource owner identity securely established for the client with the 

    OAuth credential. The application, not the SASL mechanism, based on local access 

    policy determines whether the identity reported by the mechanism is allowed 

    access to the requested resource. Note that the semantics of the authz-id is 

    specified by the SASL framework [RFC4422].

    3.2.1. OAuth Identities in the SASL Context

    Some OAuth schemes can carry both a resource owner identity and a "proxy" 

    identity, for example an OAuth 1.0a [RFC5849] mechanism where the consumer key 

    (oauth_consumer_key) identifies the entity using the token and the token itself 

    identifies the user. If both identities are needed by an application the 

    developer will need to provide a way to communicate that from the SASL mechanism 

    back to the application such as a GSS-API [RFC2473] named type like 

    GSS_C_NT_USER_NAME or a comparable newly defined GSS-API name type or name 

    attribute [RFC6680].

and I fixed the channel binding to include the cbtype.

-bill

>To: William Mills <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]> 
>Sent: Thursday, September 13, 2012 12:44 PM

---

From: John Bradley <[email-masked]>
Date: Sat, 15 Sep 2012 10:52:07 -0300

I appreciate what thou are trying too get at.

However the access_token doesn't identify the user itself.  

It conveys  a access permission for a specific client to a resource owned by a user.

The resource is the thing that may identify the user by inference OAuth.

The oauth_consumer_key also doesn't necessarily identify a single instance of a client, it may only be identifying a software client that has many instances used by many different users.

This may not be a meaning full distinction in the context of SASL, however I have seen people create security holes by making unwarranted assumptions about the semantics of those.

John B.

---

From: William Mills <[email-masked]>
Date: Sat, 15 Sep 2012 08:11:30 -0700 (PDT)

What the token identifies may indeed be implementation dependent.  I'll strike "resource owner", which leaves it up to the app to understand what the id is and how to use it.

Yep, the client ID might be the equivalent of a user agent string.  It's up to the app to decide if it's interesting, I thought that was adequatley captured by "If both identities are needed by an application ...", no?

Regards,

-bill

> From: John Bradley <[email-masked]>
>Cc: Simon Josefsson <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Saturday, September 15, 2012 6:52 AM
>Subject: Re: [kitten] Updated text Re: I-D Action: draft-ietf-kitten-sasl-oauth-07.txt
>

---

From: John Bradley <[email-masked]>
Date: Sat, 15 Sep 2012 14:24:13 -0300

Unless it is a real confidential client, and not just one using the code flow with a password that can be extracted, then client_id is a hint about the client software and not much more meaningful than that.

That hint is also something that is consumed by the Authorization server not other things.

In OAuth 2 at least the client_id is not explicitly passed to the Resource server it is just the access_token in bearer or the MAC key Identifier (id) .  The oauth_consumer_key is passed to the resource server in 1.0a though it should is not typically used for anything other than calculating the signature.

So you have two situations depending on if you are using OAuth 1 or 2.
OAuth 1:  The oauth_consumer_key might be trivially faked in the message to the resource owner unless it is checked out of band.
OAuth 2:  The client_id is not sent as it is assumed that any meaningful information about the client is in the access_token/id or retrieved out of band by lookup.

In OAuth 1 the protected resource could conceivably be set up to look up the oauth_token_secret based on the combination of oauth_consumer_key and oauth_token but that would be implementation specific.

I think all you can really say is that what you send for client_id/oauth_token_secret is a hint and might not be trust worthy and needs to be confirmed by the resource out of band.

In principal you just need oauth_consumer_key in OAuth 1 to verify the signature.  Though I suspect that at the end of the day the client and protected resource communication over SASL are so different that the OAuth 1.0a signature mechanism is only similar so you could drop it if the oauth_token is globally scoped and not per client scoped.   I think that is probably OK though it is really the Authorization part that needs to be compatible with the spec.

John B.

---

From: William Mills <[email-masked]>
Date: Sat, 15 Sep 2012 10:44:46 -0700 (PDT)

I don't think the language that I have is at odds which what you are saying.  Yes, the client_id might just be a user agent string that can be faked, etc.  It's up to the app to decide whether it needs it and what to do with it.

>Sent: Saturday, September 15, 2012 10:24 AM
>>>The oauth_consumer_key also doesn't necessarily identify a single
 instance of a client, it may only be identifying a software client that has many instances used by many different users.
>>>>     developer will need to provide
 a way to communicate that from the SASL mechanism 
>>>>>>> Quick review
 of the text that have changed since -07 below.