Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

From: Ludwig Seitz <[email-masked]>
Date: Tue, 3 Jul 2018 11:31:49 +0200

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

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 3 Jul 2018 11:33:03 +0200

> 6. Client B gets 2 from AS bound via the cnf claim to KID="A"
This should of course read:

Client B gets T2 from AS ...

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

---

From: Mike Jones <[email-masked]>
Date: Tue, 3 Jul 2018 16:15:50 +0000

Thanks, Ludwig.  Note that last paragraph of the new Operational Considerations section at https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-03#section-6 addresses this issue.  In particular, the last sentence of the section talks about the need to keep keys used in different contexts separate if there is otherwise any chance of confusion.

I'll also note that for the constrained environments that ACE is addressing, I expect that deployments with exactly one PoP key to be predominant use case.  In this use case, such confusion is impossible in the first place.

				-- Mike

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Ludwig Seitz
Sent: Tuesday, July 3, 2018 2:33 AM
To: 'ace' <[email-masked]>
Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace