[Openid-specs-ab] Proposal for adding hash to id_token

[John Bradley]

I don't think that MAC tokens solve the problem Brenno is talking about.

If the MAC token and token secret get intercepted they can always be replayed to a different RP.  (one of the reasons MAC is not useful due to symmetric secrets)

What I think Breno is looking for is a way to tell that the access token was issued with the id_token without needing to do a call to the protected resource.

At the moment the RP needs to make a call to the user_info endpoint and check the issuer and user_id.

Brenno correctly points out that this will not work with other generic OAuth 2 endpoints that the token may be scoped for.

Mixing a data endpoint from one individual with a id_token from another is a possible attack against RP who are not diligent.

In general the problem is that the id_token is more secure than the access token, and we are trying to leverage up the security of the access token by tying the security context of the id_token to it.

John B.
On 2012-01-12, at 10:49 AM, Justin Richer wrote:

> These requirements sound more to me like a request for a signed-http-message (a-la OAuth1 or the MAC token) than something else crammed into id-token.
> 
> -- Justin
> 
> On 01/09/2012 07:59 PM, Breno de Medeiros wrote:
>> I forgot to describe the validation semantics. Consider that
>> Validate() is a boolean operation that accepts as input one or more
>> tokens of various types, one of which is an id_token.
>> 
>> Assume that a client has an id_token and access_token and calls
>> Validate() in various ways:
>> 
>> Validate(id_token) -- this will fail or succeed depending on whether
>> the standard id_token signature validates, where the field
>> 'access_token_hash' is taken at face value (i.e., access_token_hash
>> fields are dealt with no differently than if they referred to a user
>> id or other payload content).
>> 
>> Validate(id_token, access_token) -- this will succeed if:
>>  -- Validate(id_token) would succeed; and
>>  -- The embedded access_token_hash value in the id_token matches the
>> computed value of the access_token provided.
>> 
>> On Mon, Jan 9, 2012 at 16:43, Breno de Medeiros<breno at google.com>  wrote:
>>> The proposal is that, when id_token issued in combination with code
>>> and/or access token, it includes a hash of those values.
>>> 
>>> Rationale: An authentication protocol implements a security service.
>>> That means it must provide all the security semantics reasonably
>>> expected by clients. If clients receive multiple tokens as the result
>>> of an authorization flow, it's reasonable for the client to assume
>>> that they all belong to the same user. If the id_token does not
>>> include a hash it implies that an additional RPC must be part of the
>>> authentication protocol necessarily (we can't make assumptions about
>>> how the client will use the tokens later, the security semantics
>>> should be correct regardless). That's much more expensive than a hash
>>> check.
>>> 
>>> Proposed mechanism:
>>> 
>>> - When an id_token is issued in combination with a code or access_token
>>> 
>>> -- The code_hash and/or the access_token_hash are computed using the
>>> _same_ hash algorithm specified by the id_token Signature Algorithm.
>>> E.g., if RSA-SHA-256 is the signature algorithm for the id_token, then
>>> SHA-256 is the hashing algorithm for the the token hashes.
>>> -- The hash output is truncated in half by discarding the half
>>> rightmost bits (in accordance with
>>> http://csrc.nist.gov/publications/nistpubs/800-107/NIST-SP-800-107.pdf,
>>> section 5.1).
>>> -- The hash output is Base64 Url encoded and added to the id_token JSON payload.
>>> 
>>> e.g:
>>> 
>>> id_token's JWT payload: { ...., "access_token_hash" :
>>> "abcdefghi_012A-BCDEFGHI", "code_hash": "zwxy_987-ZWXY", ...} (we may
>>> want to define shorter names for these JWT fields)
>>> 
>>> --
>>> --Breno
>> 
>> 
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120112/b6171eb7/attachment.p7s>