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. 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. And with the subject being the authenticated client cannot control what goes into the cwt as subject 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. Finally I think it is preferable if the server selects key identifier. Best regards //Samuel On Tue, 26 Jun 2018 at 18:57, Jim Schaad 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 > > Sent: Tuesday, June 26, 2018 6:09 PM > > To: Jim Schaad ; 'Benjamin Kaduk' > > ; 'Mike Jones' > > Cc: draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org > > 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:i...@augustcellars.com] > > Sent: 24 June 2018 10:15 > > To: 'Benjamin Kaduk'; 'Mike Jones' > > Cc: Hannes Tschofenig; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; > > ace@ietf.org > > 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
Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02
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 > Sent: Tuesday, June 26, 2018 6:09 PM > To: Jim Schaad ; 'Benjamin Kaduk' > ; 'Mike Jones' > Cc: draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org > 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:i...@augustcellars.com] > Sent: 24 June 2018 10:15 > To: 'Benjamin Kaduk'; 'Mike Jones' > Cc: Hannes Tschofenig; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; > ace@ietf.org > 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 > > Sent: Saturday, June 23, 2018 11:30 PM > > To: Mike Jones > > Cc: Hannes Tschofenig ; Jim Schaad > > ; > > draft-ietf-ace-cwt-proof-of-possess...@ietf.org; > > ace@ietf.org > > 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 +, 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 proba
Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02
No Ben, you are 100% correct. This is about identifiers and not session keys. > -Original Message- > From: Benjamin Kaduk > Sent: Tuesday, June 26, 2018 5:14 PM > To: Hannes Tschofenig > Cc: Mike Jones ; Jim Schaad > ; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; > ace@ietf.org > Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of- > possession-02 > > I thought we were worried about collision of key *identifiers*, which were > not necessarily raw keys or hashes thereof. But it's possible I was not paying > enough attention and got confused. > > -Ben > > On Tue, Jun 26, 2018 at 03:12:52PM +, Hannes Tschofenig wrote: > > It does answer my question, Ben. > > > > This begs the question why the collision of session keys is suddenly a > problem in the ACE context when it wasn't a problem so far. Something must > have changed. > > > > Ciao > > Hannes > > > > > > -Original Message- > > From: Benjamin Kaduk [mailto:ka...@mit.edu] > > Sent: 26 June 2018 17:00 > > To: Hannes Tschofenig > > Cc: Mike Jones; Jim Schaad; > > draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org > > Subject: Re: [Ace] Key IDs ... RE: WGLC on > > draft-ietf-ace-cwt-proof-of-possession-02 > > > > On Tue, Jun 26, 2018 at 08:53:57AM +, Hannes Tschofenig wrote: > > > Ben, > > > > > > I was wondering whether the situation is any different in Kerberos. If the > KDC creates tickets with a session key included then it needs to make sure > that it does not create the same symmetric key for different usages. > > > The key in the Kerberos ticket is similar to the PoP key in our discussion. > > > > > > Are we aware of key collision in Kerberos? > > > > I don't believe key collision is an issue in Kerberos. Long-term keys > > (which are not what we're talking about here) are identified by a > > principal name, encryption type, and version number. Session keys > > that are contained within tickets (and returned to the client in the > > KDC-REP) are random, so even if we are only using the birthday bound > > we're still in pretty good shape. The modern enctypes tend to use > > subsession keys generated by the client and/or server as well as the > > KDC-generated session key, which provides further binding to the current > session. > > > > Does that answer your question? > > > > -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 Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02
In Kerberos, the full principal name includes a realm name as well as the
name of the principal itself; this realm would be roughly analogous to an
OAuth Issuer. There are plenty of case where there are collisions between
the non-realm portion of the Kerberos principal; for example, I control all
of ka...@athena.mit.edu, ka...@zone.mit.edu, and ka...@grand.central.org
but apply different levels of trust and privilege to them. A more
poignant example would be the case of b...@freebsd.org and
b...@athena.mit.edu, of which I control the former but not the latter.
There is some potential for actual issues when the GSSAPI is involved,
since the standard way to pick a server ("GSS acceptor") to talk to is to
generate a host-based principal name, e.g., service="host" and
hostname="ssh.dialup.example.com", which does not include Kerberos realm
information (since the GSSAPI does not have such a concept). The Kerberos
library uses the hostname and some mapping rules/heuristics to pick a
Kerberos realm to use for ssh.dialup.example.com, but if the heuristic is
wrong for a particular case, an attacker could acquire that service
principal in the "wrong" realm, MITM, and appear to make the client connect
successfully. (Non-MITM'd connections would fail, though, so this is
likely to be detected quickly as a configuration error.)
Within a single realm (and database), there is equivalence between account
and principal name, though there are some occurrences of re-use of the same
principal name when users or machines leave the system and reenter. There
is usually a broad time separtation for that, though.
-Ben
On Tue, Jun 26, 2018 at 04:08:42PM +, Hannes Tschofenig wrote:
> Hi Ben,
>
> You are right. We were talking about the key identifiers.
>
> Let me still stick with the Kerberos example. In that context this would mean
> that the KDC stores multiple accounts in the database that point to the same
> principal name. Have you seen that happening?
> Re-using the same principle name over time as identifier get recycle when
> users get retired or otherwise leave the system might be an option. Is this a
> more likely?
>
> As you see I am trying to find some examples of vulnerabilities in existing
> systems and I am having a hard time.
>
> Ciao
> Hannes
>
> -Original Message-
> From: Benjamin Kaduk [mailto:ka...@mit.edu]
> Sent: 26 June 2018 17:14
> To: Hannes Tschofenig
> Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possess...@ietf.org;
> ace@ietf.org
> Subject: Re: [Ace] Key IDs ... RE: WGLC on
> draft-ietf-ace-cwt-proof-of-possession-02
>
> I thought we were worried about collision of key *identifiers*, which were
> not necessarily raw keys or hashes thereof. But it's possible I was not
> paying enough attention and got confused.
>
> -Ben
>
> On Tue, Jun 26, 2018 at 03:12:52PM +, Hannes Tschofenig wrote:
> > It does answer my question, Ben.
> >
> > This begs the question why the collision of session keys is suddenly a
> > problem in the ACE context when it wasn't a problem so far. Something must
> > have changed.
> >
> > Ciao
> > Hannes
> >
> >
> > -Original Message-
> > From: Benjamin Kaduk [mailto:ka...@mit.edu]
> > Sent: 26 June 2018 17:00
> > To: Hannes Tschofenig
> > Cc: Mike Jones; Jim Schaad;
> > draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org
> > Subject: Re: [Ace] Key IDs ... RE: WGLC on
> > draft-ietf-ace-cwt-proof-of-possession-02
> >
> > On Tue, Jun 26, 2018 at 08:53:57AM +, Hannes Tschofenig wrote:
> > > Ben,
> > >
> > > I was wondering whether the situation is any different in Kerberos. If
> > > the KDC creates tickets with a session key included then it needs to make
> > > sure that it does not create the same symmetric key for different usages.
> > > The key in the Kerberos ticket is similar to the PoP key in our
> > > discussion.
> > >
> > > Are we aware of key collision in Kerberos?
> >
> > I don't believe key collision is an issue in Kerberos. Long-term keys
> > (which are not what we're talking about here) are identified by a principal
> > name, encryption type, and version number. Session keys that are contained
> > within tickets (and returned to the client in the KDC-REP) are random, so
> > even if we are only using the birthday bound we're still in pretty good
> > shape. The modern enctypes tend to use subsession keys generated by the
> > client and/or server as well as the KDC-generated session key, which
> > provides further binding to the current session.
> >
> > Does that answer your question?
> >
> > -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.
> IMPORTANT NOTICE: The contents of this email and any attachmen
Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02
Hi Ben, You are right. We were talking about the key identifiers. Let me still stick with the Kerberos example. In that context this would mean that the KDC stores multiple accounts in the database that point to the same principal name. Have you seen that happening? Re-using the same principle name over time as identifier get recycle when users get retired or otherwise leave the system might be an option. Is this a more likely? As you see I am trying to find some examples of vulnerabilities in existing systems and I am having a hard time. Ciao Hannes -Original Message- From: Benjamin Kaduk [mailto:ka...@mit.edu] Sent: 26 June 2018 17:14 To: Hannes Tschofenig Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 I thought we were worried about collision of key *identifiers*, which were not necessarily raw keys or hashes thereof. But it's possible I was not paying enough attention and got confused. -Ben On Tue, Jun 26, 2018 at 03:12:52PM +, Hannes Tschofenig wrote: > It does answer my question, Ben. > > This begs the question why the collision of session keys is suddenly a > problem in the ACE context when it wasn't a problem so far. Something must > have changed. > > Ciao > Hannes > > > -Original Message- > From: Benjamin Kaduk [mailto:ka...@mit.edu] > Sent: 26 June 2018 17:00 > To: Hannes Tschofenig > Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; > ace@ietf.org > Subject: Re: [Ace] Key IDs ... RE: WGLC on > draft-ietf-ace-cwt-proof-of-possession-02 > > On Tue, Jun 26, 2018 at 08:53:57AM +, Hannes Tschofenig wrote: > > Ben, > > > > I was wondering whether the situation is any different in Kerberos. If the > > KDC creates tickets with a session key included then it needs to make sure > > that it does not create the same symmetric key for different usages. > > The key in the Kerberos ticket is similar to the PoP key in our discussion. > > > > Are we aware of key collision in Kerberos? > > I don't believe key collision is an issue in Kerberos. Long-term keys > (which are not what we're talking about here) are identified by a principal > name, encryption type, and version number. Session keys that are contained > within tickets (and returned to the client in the KDC-REP) are random, so > even if we are only using the birthday bound we're still in pretty good > shape. The modern enctypes tend to use subsession keys generated by the > client and/or server as well as the KDC-generated session key, which > provides further binding to the current session. > > Does that answer your question? > > -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. 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 Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
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:i...@augustcellars.com] Sent: 24 June 2018 10:15 To: 'Benjamin Kaduk'; 'Mike Jones' Cc: Hannes Tschofenig; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org 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 > Sent: Saturday, June 23, 2018 11:30 PM > To: Mike Jones > Cc: Hannes Tschofenig ; Jim Schaad > ; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; > ace@ietf.org > 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 +, 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 Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02
I thought we were worried about collision of key *identifiers*, which were not necessarily raw keys or hashes thereof. But it's possible I was not paying enough attention and got confused. -Ben On Tue, Jun 26, 2018 at 03:12:52PM +, Hannes Tschofenig wrote: > It does answer my question, Ben. > > This begs the question why the collision of session keys is suddenly a > problem in the ACE context when it wasn't a problem so far. Something must > have changed. > > Ciao > Hannes > > > -Original Message- > From: Benjamin Kaduk [mailto:ka...@mit.edu] > Sent: 26 June 2018 17:00 > To: Hannes Tschofenig > Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; > ace@ietf.org > Subject: Re: [Ace] Key IDs ... RE: WGLC on > draft-ietf-ace-cwt-proof-of-possession-02 > > On Tue, Jun 26, 2018 at 08:53:57AM +, Hannes Tschofenig wrote: > > Ben, > > > > I was wondering whether the situation is any different in Kerberos. If the > > KDC creates tickets with a session key included then it needs to make sure > > that it does not create the same symmetric key for different usages. > > The key in the Kerberos ticket is similar to the PoP key in our discussion. > > > > Are we aware of key collision in Kerberos? > > I don't believe key collision is an issue in Kerberos. Long-term keys > (which are not what we're talking about here) are identified by a principal > name, encryption type, and version number. Session keys that are contained > within tickets (and returned to the client in the KDC-REP) are random, so > even if we are only using the birthday bound we're still in pretty good > shape. The modern enctypes tend to use subsession keys generated by the > client and/or server as well as the KDC-generated session key, which > provides further binding to the current session. > > Does that answer your question? > > -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 Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02
It does answer my question, Ben. This begs the question why the collision of session keys is suddenly a problem in the ACE context when it wasn't a problem so far. Something must have changed. Ciao Hannes -Original Message- From: Benjamin Kaduk [mailto:ka...@mit.edu] Sent: 26 June 2018 17:00 To: Hannes Tschofenig Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 On Tue, Jun 26, 2018 at 08:53:57AM +, Hannes Tschofenig wrote: > Ben, > > I was wondering whether the situation is any different in Kerberos. If the > KDC creates tickets with a session key included then it needs to make sure > that it does not create the same symmetric key for different usages. > The key in the Kerberos ticket is similar to the PoP key in our discussion. > > Are we aware of key collision in Kerberos? I don't believe key collision is an issue in Kerberos. Long-term keys (which are not what we're talking about here) are identified by a principal name, encryption type, and version number. Session keys that are contained within tickets (and returned to the client in the KDC-REP) are random, so even if we are only using the birthday bound we're still in pretty good shape. The modern enctypes tend to use subsession keys generated by the client and/or server as well as the KDC-generated session key, which provides further binding to the current session. Does that answer your question? -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 Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02
On Tue, Jun 26, 2018 at 08:53:57AM +, Hannes Tschofenig wrote: > Ben, > > I was wondering whether the situation is any different in Kerberos. If the > KDC creates tickets with a session key included then it needs to make sure > that it does not create the same symmetric key for different usages. > The key in the Kerberos ticket is similar to the PoP key in our discussion. > > Are we aware of key collision in Kerberos? I don't believe key collision is an issue in Kerberos. Long-term keys (which are not what we're talking about here) are identified by a principal name, encryption type, and version number. Session keys that are contained within tickets (and returned to the client in the KDC-REP) are random, so even if we are only using the birthday bound we're still in pretty good shape. The modern enctypes tend to use subsession keys generated by the client and/or server as well as the KDC-generated session key, which provides further binding to the current session. Does that answer your question? -Ben ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02
Ben, I was wondering whether the situation is any different in Kerberos. If the KDC creates tickets with a session key included then it needs to make sure that it does not create the same symmetric key for different usages. The key in the Kerberos ticket is similar to the PoP key in our discussion. Are we aware of key collision in Kerberos? Ciao Hannes -Original Message- From: Benjamin Kaduk [mailto:ka...@mit.edu] Sent: 23 June 2018 23:30 To: Mike Jones Cc: Hannes Tschofenig; Jim Schaad; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org 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 +, 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 Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
