Re: [Ace] PoP Key Distribution

[Mike Jones]

I've replied on the OAuth mailing list.  You can join it at 
https://www.ietf.org/mailman/listinfo/oauth to participate in the discussion.

From: Ace  On Behalf Of Hannes Tschofenig
Sent: Tuesday, July 3, 2018 12:47 PM
To: ace@ietf.org
Subject: [Ace] FW: PoP Key Distribution

Note that I posted a mail to the OAuth list about the PoP key distribution, 
which also relates to the work on ACE-OAuth.
If you are interested in this topic please feel free to join the discussion on 
the OAuth mailing list.

From: Hannes Tschofenig
Sent: 03 July 2018 21:46
To: oa...@ietf.org
Subject: PoP Key Distribution

Hi all,

we have been working on an update for the draft-ietf-oauth-pop-key-distribution 
document in time for the deadline but we noticed several issues that are 
worthwhile to bring to your attention.

draft-ietf-oauth-pop-key-distribution defines a mechanism that allows the 
client to talk to the AS to request a PoP access token and associated keying 
material.

There are two other groups in the IETF where this concept is used.


  *   The guys working on RTCWEB is the first. Misi (Mészáros Mihály) has been 
helping us to understand their needs. They have defined their own token format, 
which has been posted on the OAuth group a while ago for review.


  *   The other group is ACE with their work on an OAuth-based profile for IoT.

Where should the parameters needed for PoP key distribution should be defined? 
Currently, they are defined in two places -- in 
https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-13 and also in 
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03. In 
particular, the audience and the token_type parameters are defined in both 
specs.

IMHO it appears that OAuth would be the best place to define the HTTP-based 
parameters. ACE could define the IoT-based protocols, such as CoAP, MQTT, and 
alike. Of course, this is subject for discussion, particularly if there is no 
interest in doing so in the OAuth working group.

There is also a misalignment in terms of the content.. 
draft-ietf-oauth-pop-key-distribution defined an 'alg' parameter, which does 
not exist in the draft-ietf-ace-oauth-authz document. The 
draft-ietf-ace-oauth-authz document does, however, have a profile parameter, 
which does not exist in draft-ietf-oauth-pop-key-distribution. Some alignment 
is therefore needed. In the meanwhile the work on OAuth meta has been finalized 
and could potentially be re-used.

When the work on draft-ietf-oauth-pop-key-distribution was initially started 
there was only a single, standardized token format, namely the JWT. Hence, it 
appeared reasonable to use the JWT keying structure for delivering keying 
material from the AS to the client.

In the meanwhile two other formats have been standardized, namely RFC 7635 and 
the CWT. For use with those specs it appears less ideal to transport keys from 
the AS to the client using the JSON/JOSE-based format. It would be more 
appropriate to use whatever PoP token format is used instead. Currently, this 
hasn't been considered yet.

Ciao
Hannes

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

[Ace] FW: PoP Key Distribution

[Hannes Tschofenig]

Note that I posted a mail to the OAuth list about the PoP key distribution, 
which also relates to the work on ACE-OAuth.
If you are interested in this topic please feel free to join the discussion on 
the OAuth mailing list.

From: Hannes Tschofenig
Sent: 03 July 2018 21:46
To: oa...@ietf.org
Subject: PoP Key Distribution

Hi all,

we have been working on an update for the draft-ietf-oauth-pop-key-distribution 
document in time for the deadline but we noticed several issues that are 
worthwhile to bring to your attention.

draft-ietf-oauth-pop-key-distribution defines a mechanism that allows the 
client to talk to the AS to request a PoP access token and associated keying 
material.

There are two other groups in the IETF where this concept is used.


· The guys working on RTCWEB is the first. Misi (Mészáros Mihály) has 
been helping us to understand their needs. They have defined their own token 
format, which has been posted on the OAuth group a while ago for review.


· The other group is ACE with their work on an OAuth-based profile for 
IoT.

Where should the parameters needed for PoP key distribution should be defined? 
Currently, they are defined in two places -- in 
https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-13 and also in 
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03. In 
particular, the audience and the token_type parameters are defined in both 
specs.

IMHO it appears that OAuth would be the best place to define the HTTP-based 
parameters. ACE could define the IoT-based protocols, such as CoAP, MQTT, and 
alike. Of course, this is subject for discussion, particularly if there is no 
interest in doing so in the OAuth working group.

There is also a misalignment in terms of the content. 
draft-ietf-oauth-pop-key-distribution defined an 'alg' parameter, which does 
not exist in the draft-ietf-ace-oauth-authz document. The 
draft-ietf-ace-oauth-authz document does, however, have a profile parameter, 
which does not exist in draft-ietf-oauth-pop-key-distribution. Some alignment 
is therefore needed. In the meanwhile the work on OAuth meta has been finalized 
and could potentially be re-used.

When the work on draft-ietf-oauth-pop-key-distribution was initially started 
there was only a single, standardized token format, namely the JWT. Hence, it 
appeared reasonable to use the JWT keying structure for delivering keying 
material from the AS to the client.

In the meanwhile two other formats have been standardized, namely RFC 7635 and 
the CWT. For use with those specs it appears less ideal to transport keys from 
the AS to the client using the JSON/JOSE-based format. It would be more 
appropriate to use whatever PoP token format is used instead. Currently, this 
hasn't been considered yet.

Ciao
Hannes

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

[Mike Jones]

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  On Behalf Of Ludwig Seitz
Sent: Tuesday, July 3, 2018 2:33 AM
To: 'ace' 
Subject: Re: [Ace] Key IDs ... RE: WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

On 2018-07-03 11:31, Ludwig Seitz wrote:

> 
> 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

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] ace - Requested session has been scheduled for IETF 102

["IETF Secretariat"]

Dear Roman Danyliw,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 


ace Session 1 (2:00 requested)
Monday, 16 July 2018, Morning Session I 0930-1200
Room Name: Viger size: 200
-


iCalendar: https://datatracker.ietf.org/meeting/102/sessions/ace.ics

Request Information:


-
Working Group Name: Authentication and Authorization for Constrained 
Environments
Area Name: Security Area
Session Requester: Roman Danyliw

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 100
Conflicts to Avoid: 
 First Priority: saag cbor core tls lamps cfrg secdispatch ace emu dots
 Second Priority: quic oauth secevent tokbind t2trg lwig anima suit teep mile
 Third Priority: doh httpbis uta 6tisch homenet curdle


People who must be present:
  Roman Danyliw
  Jim Schaad
  Benjamin Kaduk

Resources Requested:

Special Requests:
  A session in the first half of the week (Mon-Wed) would be preferred.
-

___
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

[Ludwig Seitz]

On 2018-07-03 11:31, Ludwig Seitz wrote:



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

___
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

[Ludwig Seitz]

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