see inline On Fri, Jun 29, 2018 at 7:57 AM, Jim Schaad <[email protected]> wrote:
> > > > > *From:* Samuel Erdtman <[email protected]> > *Sent:* Thursday, June 28, 2018 5:40 PM > *To:* Jim Schaad <[email protected]> > *Cc:* Samuel Erdtman <[email protected]>; draft-ietf-ace-cwt-proof-of- > [email protected]; Mike Jones <[email protected]>; Hannes > Tschofenig <[email protected]>; Benjamin Kaduk <[email protected]>; > ace <[email protected]> > *Subject:* Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of- > possession-02 > > > > Thanks for the clarifying comments here comes a few replies since I will > not be able to join the IETF meeting :-( > > > > see inline > > > > On Wed, Jun 27, 2018 at 9:19 AM, Jim Schaad <[email protected]> > wrote: > > > > > > *From:* Samuel Erdtman <[email protected]> > *Sent:* Wednesday, June 27, 2018 8:18 AM > *To:* Jim Schaad <[email protected]> > *Cc:* Hannes Tschofenig <[email protected]>; Benjamin Kaduk < > [email protected]>; Mike Jones <[email protected]>; > [email protected]; [email protected] > *Subject:* Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of- > possession-02 > > > > Jim, are you saying that if the client can pick the key identifier and if > it has seen a key identifier of another client it could request a PoP token > with the observed key-id and the observed subject but with an new key. > I guess this is a potential scenario that could be worth mentioning in > security considerations. > > [JLS] No I am not assuming that the observed subject is also chosen by the > attacker, just the observed key-id. > > OK, see comments below on why I think the attacker would have to know the > subject too. > > > > > If we look at ACE-OAuth there are as far as I can tell a few things that > makes this a hard attack to do. > > When the client makes the token request it is authenticated. > > [JLS] Unclear why this is relevant. I am asking for this new token as > myself. > > In my opinion authentication of the client will significantly lessen the > number of attackers since they need to have some initial access. i.e. no > absolute protection but one layer. > > > > [JLS] I am already in the system and have full credentials. I am trying > to get the same permissions that you have. Not all attackers are external > to the system. > I agree, but the number of such attackers are fewer and you could revoke access to such users. It is not perfect but it is better than nothing. > > > > And with the subject being the authenticated client cannot control what > goes into the cwt as subject > > [JLS] You are making an assumption that a) the subject is actually going > to be populated rather than be left empty and thus be anonymous and 2) that > the resource server is going to make any enforcement based on the subject.. > I expect it to be done based on audience and scope only. > > My assumption is that RS will uniquely identify the key with Issuer, > Subject and Key-ID. If subject is omitted for an anonymous token I assume > that the AS (Issuer) makes sure the key-id is unique during the lifetime of > the token. If issuer is left out I assume it is identified by the CWT > signing key or that the RS only accept tokens from one AS. > > When the key is found and has been used to authenticate the user of the > token I too expect that the RS does the authorization based on audience and > scope. > > > > [JLS] I am not sure how this is going to work. As the CS I do a DTLS > connect to the RS and put the Key-ID into the PSK identifier field. The RS > now has the Key-ID, but does not have the Issuer or Subject information. > Are you using this triple value binding someplace else? > I would not send the key-id in the PSK identifier I would send the full token as described in draft-ietf-ace-dtls-authorize (4.1. DTLS Channel Setup Between C and RS). > > > > Since the cwt with the PoP key is signed there is no way for the attacking > client to retro-fit the token to suit its needs e.g. change subject or > key-id. > > [JLS] I am asking for a new token not trying to modify an existing token > so this is not especially relevant. > > Based on my previous statement you should not be able to impersonate the > observed key with a token issued for you. > > > > [JLS] Given two anonymous subject fields, the subject would not be a > differentiator > I agree so the AS (issuer) MUST keep key-id unique for the lifetime of the token. > > Finally I think it is preferable if the server selects key identifier. > > [JLS] I would agree, however if you have two AS that are operating in the > same authorization range and are not tightly linked then this is not easy > for doing an additional privilege token where the POP is identified by the > KID. This is even harder if an RS is going to allow two different AS from > different scopes to be authoritative as they would never coordinate > together. > > In the case of RS accepting tokens from multiple ASs I think the RS must > use the issuer (in the CWT) to do key lookup. > > > > [JLS] That may be true, however I have still not seen how to do the > processing of getting a supplementary CWT and thus don’t know how it > works. I was assuming that the Client would send a KID as part of it’s > request to the AS so one now has interesting questions of how the server > does the assignment. Also having a KID as part of an asymmetric key is > probably going to be normal operating procedure so this is another case > where the Client is providing one. > > > > Jim > > > > > > Best regards > //Samuel > > On Tue, 26 Jun 2018 at 18:57, Jim Schaad <[email protected]> wrote: > > Hannes, > > My worry is not about implementers getting this correct and picking random > key ids. My worry is about an attacker seeing the key id of somebody and > trying to use it either with the same or a different AS and getting a key > and then getting permissions associated with the initial key that they > should not be doing. > > This is about an attack not about getting things to generally work right. > > Jim > > > > -----Original Message----- > > From: Hannes Tschofenig <[email protected]> > > Sent: Tuesday, June 26, 2018 6:09 PM > > To: Jim Schaad <[email protected]>; 'Benjamin Kaduk' > > <[email protected]>; 'Mike Jones' <[email protected]> > > Cc: [email protected]; [email protected] > > > Subject: RE: [Ace] Key IDs .... RE: WGLC on draft-ietf-ace-cwt-proof-of- > > possession-02 > > > > Hi Jim, > > > > you are essentially proposing that we should not directly use the key id > that > > is in the CWT-PoP but rather use it as input in a key derivation > function. > The > > details of that key derivation function are specified outside the CWT-POP > > document and most likely in the context of the various profiles. > > Your proposals below suggest to use, among other things, the session key > as > > input to that function. That sounds pretty straight forward but raises > the > > question why we fail to trust the implementer to create random key ids > but > > then still trust them to create random keys. > > > > That's fine for me nevertheless. > > > > Ciao > > Hannes > > > > -----Original Message----- > > From: Jim Schaad [mailto:[email protected]] > > Sent: 24 June 2018 10:15 > > To: 'Benjamin Kaduk'; 'Mike Jones' > > Cc: Hannes Tschofenig; [email protected]; > > [email protected] > > > Subject: RE: [Ace] Key IDs .... RE: WGLC on draft-ietf-ace-cwt-proof-of- > > possession-02 > > > > Thinking things through, I would be more comfortable with something like > > the > > following: > > > > 1. Create a confirmation called 'computed key id'. This has two basic > > values: What is the computation method? What is the proof value? You > can > > optionally have an unprotected KID value used to filter the set of keys > on > the > > RS down to a reasonable set to enumerate (hopefully one). > > > > 2. For RPK and TLS: Define a method called hash of SPKI which has a > hash > > method as a parameter. Given that this can be computed independently by > > all entities based on a Public Key value and it will be unique then you > have a > > key identifier that will not have collisions independent of who issues > the > > CWT. > > > > 3. For PSK and TLS: Define a method which takes some parameters > including > > the key value, the CWT issuer identity and perhaps some random string and > > compute a proof of possession value on the PSK. > > > > 4. For PSK and OSCORE: Define a similar method the question would be > what > > the key value is to be used but that can be defined as part of OSCORE > > > > When using the keys for TLS > > > > For RPK the key is carried in the handshake and the server/client can > > generate the computed key id and compare it to what the AS distributed. > > > The server can identify which CWTs are applicable by either comparison of > > the RPKs or the computed key id. This means you have a high probability > > that you will not make a mistake and match to the wrong key. > > > > For PSK the identifier is carried in the handshake which is used to look > up a > > key value and the handshake is performed. By matching computed key ids > > with the secret value one can ensure to a high probably that only CWTs > that > > reference the same secret are going to be used for permissions even if > they > > come from different AS entities. > > > > For OSCORE it is similar, the identifier is used to look up a key value > and by > > decrypting the CWT the key value is proofed. You then match computed key > > ids in the same manner. > > > > If you really want to have something that is not cryptographically > computed > > and point to something else, then it makes more sense to me to reference > a > > CWT issued by the same entity and say "use the same conformation method > > as this CWT does". > > > > jim > > > > > -----Original Message----- > > > From: Benjamin Kaduk <[email protected]> > > > Sent: Saturday, June 23, 2018 11:30 PM > > > To: Mike Jones <[email protected]> > > > Cc: Hannes Tschofenig <[email protected]>; Jim Schaad > > > <[email protected]>; > > > [email protected]; > > > [email protected] > > > Subject: Re: [Ace] Key IDs ... RE: WGLC on > > > draft-ietf-ace-cwt-proof-of- > > > possession-02 > > > > > > On Fri, Jun 22, 2018 at 08:48:35PM +0000, Mike Jones wrote: > > > > See my note just now proposing this text to Jim: > > > > > > > > "Likewise, if PoP keys are used for multiple different kinds of CWTs > > > > in > > an > > > application and the PoP keys are identified by Key IDs, care must be > > > taken > > to > > > keep the keys for the different kinds of CWTs segregated so that an > > attacker > > > cannot cause the wrong PoP key to be used by using a valid Key ID for > > > the wrong kind of CWT." > > > > > > > > As long as the PoP keys for different contexts are kept segregated, > > > > Key > > ID > > > collisions or reuse cause no problems. > > > > > > If we trust everyone to implement things properly. We should probably > > only > > > take that risk if we get some other benefit from it, though. Jim > > mentioned > > > (off-list?) a scenario involving giving the same client additional > > privileges, and > > > of course we can gain some simplicity savings if we don't need to > > > enforce global key-id uniqueness (for appropriate values of "global").. > > > So this > > may > > > well be the right thing to do; I just don't think it's without > > > tradeoffs > > as your > > > text seems to imply. > > > > > > -Ben > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > > confidential and may also be privileged. If you are not the intended > recipient, > > please notify the sender immediately and do not disclose the contents to > any > > other person, use it for any purpose, or store or copy the information in > any > > medium. Thank you. > > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace > > >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
