I see. It was buried under "reg". Phil
@independentid www.independentid.com [email protected] On 2013-11-04, at 2:22 PM, John Bradley <[email protected]> wrote: > If you read the draft the redirect URI and other parameters are encoded into > the JWT assertion. > > What we are proposing is using an assertion/token as the client_id that > assertion cannot be a bearer assertion for confidential clients, that would > be inssecure. > IT needs to be some sort of proof of possession assertion/token. There are > several ways to do proof of possession one is including a public key and the > other is encrypting a symmetric key. > > The option I didn't include is using some sort of key derivation mechanism, > DH etc so that you don't need to encrypt if using a symmetric password. > > Symmetric passwords have all sorts of problems. A static assertion without > PoP has similar problems with securing it in the client. > > For reference the sort of compromises I am concerned about are already > starting to happen. > http://blog.programmableweb.com/2013/11/04/why-the-attack-on-buffer-was-a-serious-wake-up-call-for-the-web/ > > John B. > > On Nov 4, 2013, at 2:06 PM, Phil Hunt <[email protected]> wrote: > >> So how is a stateless client able to do the authorize flow? How does the >> server know about the redirect_url? Is it wide open? >> >> Still would like to hear more about this. Sometimes attacking the problem >> from a different direction leads to an innovative conclusion. >> >> Still I share the concerns of Tony and binding authentication into client_id. >> >> Phil >> >> @independentid >> www.independentid.com >> [email protected] >> >> On 2013-11-04, at 1:58 PM, Nat Sakimura <[email protected]> wrote: >> >>> I was assuming that the AS uses symmetric encryption as it is faster and it >>> just needs to be encrypted and decoded by itself. >>> >>> >>> 2013/11/5 John Bradley <[email protected]> >>> If the AS is using asymmetric encryption you need to both sign and then >>> encrypt as anyone can encrypt. >>> >>> Yes if the client has a TLS cert you could use a jwk_uri to keep the size >>> down. >>> >>> John B. >>> >>> On Nov 4, 2013, at 1:37 PM, Nat Sakimura <[email protected]> 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 <[email protected]> >>>> 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 >>>> <[email protected]> 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 [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> -- >>>> Nat Sakimura (=nat) >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>> >>> >>> >>> >>> -- >>> Nat Sakimura (=nat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >> >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
