I've finally had the time to think about that Key ID issue for ACE.
Here is what I got:
The case Jim is worried about is the following:
* Client A has key K1 with KID = "A"
* RS also has key K1 with KID = "A"
* Client A has the right to token T1 on RS
* Client B has the right to token T2 on RS
1. Client A gets T1 from AS bound via the cnf claim to KID="A"
2. Client A transfers T1 to RS
3. Client A performs the proof-of-possession with key K1 and gets access
to RS according to T1
4. Malicious Client B learns of the KID = "A" for T1 (but not of K1).
5. Client B chooses K2 and assigns it KID = "A"
6. Client B gets 2 from AS bound via the cnf claim to KID="A"
7. Client B transfers T2 to RS
8. ?
9. Client B performs the proof-of-possession for K2 and gets access to
both T1 and T2
Now I'm claiming there is no step 8 that makes step 9 work, unless B can
get RS to accept a new key (K2) with a duplicate KID.
Thus I'd say, we need to Security Considerations about handling key Ids
at the recipient of a CWT containing a cnf claim. Something along the
lines of:
"If a recipient receives a CWT with the a confirmation claim, the
recipient MUST make sure that keys that may be contained in that claim
do not have a key identifier that duplicates one of a different key that
the recipient already recognizes."
Or shorter:
"Recipients MUST make sure that they do not accept identical key
identifiers for different keys"
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
