Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00

[Nat Sakimura <[e-mail]>]

2013/11/5 Richer, Justin P. <[e-mail]>

>  Since the client isn't really supposed to be poking around inside of the
> client_id anyway, I think that JWS is a reasonable starting place, with JWE
> if you want to actively hide something inside of the client_id from the
> client (and browser and other parties that see the client_id). Most of the
> stuff that's tied to a client's configuration isn't that sensitive, in my
> opinion.
>

It may or may not. It depends, really. Switching between encrypted and just
signed depending on the cases seems to be a bit of overhead, though I agree
that signing is a bit easier.


>
>  Also, there are other ways to have a symmetric client secret that's
> stateless beyond packing it into the client_id here. For one, since
> client_secrets are also opaque to the client, you could just issue a
> client_secret that's a signed JWT in its own right (or some other signed
> blob), letting the AS check the signature but the client merely presenting
> it as a normal client_secret. Alternatively, you could issue a bearer
> assertion and accomplish the same thing. Both of these would still need to
> be communicated to the client along side its client_id, the trick is coming
> up with a mechanism whereby the AS can recognize it.
>

That's probably more reasonable. Linking two JWT with sub claim or
something like that.

>
>   -- Justin
>
>
>
>  On Nov 4, 2013, at 1:37 PM, Nat Sakimura <[e-mail]> wrote:
>
>  Since the client_id is supposed to be opaque, it would probably be
> better to JWE encrypt (note: all JWE encryption are integrity protected as
> well) by the authorization server upon issuing it to the client. This way,
> we have exactly one way of doing the things, and it works for both
> symmetric and asymmetric case.
>
>  I see this more useful in the case of symmetric client secret.
>
>  If the client were just using public key crypto to authenticate itself
> to the server, using the URI of the location of the client metadata as the
> client_id would suffice.
>
>  This has an advantage of smaller client_id.
>
>
> 2013/11/2 Hannes Tschofenig <[e-mail]>
>
>> Hi John,
>>
>> thanks for the super-quick response.
>>
>>
>> Am 01.11.13 19:18, schrieb John Bradley:
>>
>>  The client_id would continue to be opaque to the client as it is now.
>>> The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and
>>> provide integrity if it is using a symmetric key (probably the
>>> simplest thing if we are talking about a single registration endpoint
>>> paired with a single AS)  In more complicated scenarios where perhaps
>>> a group of AS share a single registration endpoint you probably want
>>> to use asymmetric signature  then asymmetric encryption + integrity.
>>> Those are deployment decisions that need to be documented but can be
>>> transparent to teh client.
>>>
>>
>>  Maybe it would be good to state that in the document that this is a
>> possible option without introducing further complications (other than the
>> verification procedure is different). If the AS signs the JWT then it just
>> needs to compare whether the issuer field matches what it had previously
>> put in there. If someone else signs the JWT then it needs to check with
>> some trust anchor store or something similar whether it trusts that
>> specific issuer.
>>
>>
>>
>>
>>> Sorry to my mind it is obvious that the JWT would be integrity
>>> protected/signed for all clients including clients using asymmetric
>>> authentication to the token endpoint, and and
>>> signed+encrypted+integrity for clients using symmetric
>>> authentication.   That can be made clearer.
>>>
>>
>>  It would be good to say that because the effort is rather low and there
>> are benefits in doing so.
>>
>>
>>
>>> It might make sense to assume the issuer is just the AS but the AS
>>> can do that without the benefit of a spec now, as there is no
>>> interoperability issue.
>>>
>>> The spec defining the JWT structure and signing and encryption
>>> methods has the most benefit when you don't have such a tight
>>> coupling between registration and AS.
>>>
>>> That is likely why Justin and I didn't think a spec was necessary for
>>> the simple case other than to show people this is possible with the
>>> existing registration spec.
>>>
>>
>>  I think there is value in providing that information for implementers
>> even though it does not require new extensions or so.
>>
>>
>>
>>> I am OK with strengthening the wording on signing/integrity
>>> protecting and encryption.  eg if a symmetric key is included the JWT
>>> MUST be encrypted.
>>>
>>
>>  Cool.
>>
>>
>>> I don't necessarily want to make any algorithm a must as that limits
>>> algorithm agility in the future.
>>>
>>  OK.
>>
>>
>>
>>> Thanks for giving it a read, see you Sunday I expect.
>>>
>>  Unfortunately not since I am unable to attend the upcoming IETF meeting.
>> Derek will run the show.
>>
>> Ciao
>> Hannes
>>
>>
>>
>>> John B.
>>>
>>>
>>> On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig
>>> <[e-mail]> wrote:
>>>
>>>  Hi John, Hi all,
>>>>
>>>> I read your document and here a few remarks.
>>>>
>>>> In the dynamic client registration conference calls the topic of
>>>> the stateless client was raised since there was the argument in the
>>>> air that the current OAuth 2.0 RFC requires clients to be stateless
>>>> due to the nature of the client identifier.
>>>>
>>>> It seems that you have found a way to make the client stateless
>>>> with regard to the client identifier (i.e., that the authorization
>>>> server does not need to store information about the client) by
>>>> dumping state information in the client identifier itself. In your
>>>> case you use a JWT, which is clever.
>>>>
>>>> Since RFC 6749 explicitly says that the client identifier string
>>>> size is left undefined  and that the client should avoid making
>>>> assumptions about the identifier size I don't see a problem with
>>>> the proposed approach.
>>>>
>>>> Now, there is one issue that I am wondering about. The client
>>>> identifier itself is not sufficient for authorizing the client (for
>>>> confidential clients). Instead, there is typically the need to have
>>>> a secret. Now, the secret is not conveyed in the JWT, at least not
>>>> in the way you have define it. You could of course do that and
>>>> there is a document that provides prior art, see
>>>> http://www.ietf.org/rfc/rfc5077 The story essentially is that the
>>>> structure (JWT in your case) includes the key but of course then
>>>> you have to encrypt the entire blob.
>>>>
>>>> In the case of public clients wouldn't you want to mandate at least
>>>> a digital signature or a keyed message digest for the JWT since
>>>> otherwise there is the risk that the client changes some of the
>>>> parameters to impersonate someone?
>>>>
>>>> A few other questions:
>>>>
>>>> * You write: "The issuer SHOULD sign the JWT with JWS in such a way
>>>> that the signature can be verified by the authorization server. "
>>>>
>>>> I believe what you want to say is the following: The authorization
>>>> creates the client identifier (using the JWT) and the client does
>>>> not parse the received content since it treats it as opaque.
>>>> However, the authorization server MUST be able to process and
>>>> verify received client identifiers it previously created, which
>>>> requires to apply cryptographic processing when a JWT is signed
>>>> (using a JWS) and when a JWT is encrypted (using a JWE).
>>>>
>>>> (I ignore the issue that I believe the JWT needs to be signed [for
>>>> public clients] and encrypted [for confidential clients].)
>>>>
>>>> * You should submit the document as draft-bradley-oauth; this makes
>>>> it easier to find the document.
>>>>
>>>> * You write: " The issuer MAY encrypt the JWT with JWE. "
>>>>
>>>> I think you want to be stronger by saying that JWE MUST be used
>>>> when the authorization server wants to apply confidentiality
>>>> protection of the JWT. While the authorization server could use
>>>> other techniques as well the purpose of the document is to describe
>>>> one way to accomplish the goal and therefore it makes sense to be
>>>> specific.
>>>>
>>>> I would even go as far as suggesting specific algorithms to use, as
>>>> an example.
>>>>
>>>> * Although not stated directly I believe you allow the client
>>>> identifier to be created by a party other than the authorization
>>>> server. While this would theoretically make sense wouldn't it be
>>>> useful to just assume that the issuer is the authorization server?
>>>>
>>>> Ciao Hannes _______________________________________________ OAuth
>>>> mailing list [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
>
>  --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>  _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en