[Ace] draft-ietf-ace-dtls-authorize
Apparently, the change on the DTLS profile has not been noticed by everyone in the WG, so I am bringing the discussion here. The change has been made as a response to a comment from the security directorate. Please provide your feed backs by Feb 4 (but preferably before)- and potentially propose the text you would like to see if you disagree with the change. This is how has just been updated. The use of CoAP and DTLS for this communication is RECOMMENDED REQUIRED in this profile, other profile. Other protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]) MAY be used instead. will require specification of additional profile(s). Yours, Daniel ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] draft-ietf-ace-dtls-authorize-01
[chair hat off] Hi all, I took a look at the draft and noticed a few minor things: - The document should talk about "profiles" rather than "profile" since it specifies at least two profiles, namely the RPK and the PSK profiles with DTLS. I suspect an implementation is only expected to implement one of them rather than both. - Editorial comment: most of the articles are missing, which makes the document harder to read. - AS discovery: Wouldn't the client need to know the AS upfront when using RPK and PSK (since it has to share a PSK with the AS or, in case of the RPK, has to have the RPK with the server exchanged out of band)? - There are two options provided for conveying the access token to the RS, either either a dedicated endpoint or inband within the DTLS exchange. There are pros and cons regarding the usage of both; is the idea to settle with one approach in the end or do you envision both options to be available in the final version of the specification. - Regarding the dynamic update of authorization information. Since the access token is a PoP token I believe you will have to demonstrate the possession of the key every time you change the access token. (Section 2.4 gives me a different impression.) - When the access token is conveyed inband in DTLS as part of the PSK_identity then the text on page 12 is applicable. The description in CDDL format confuses me. Normally, it should be quite simple: either you transmit a psk_identity field or you convey the access token. The server would figure it out. Is this just a complicated way to express this semantic or do you have something else in mind? (Btw, my understanding is that the server does not need to send a illegal_parameter alert when it the psk_identity does not lead to a successful authentication. Is this your suggestion or is this taken from TLS PSK?) - What is the reasoning behind this statement: "This specification mandates that at least the key derivation algorithm "HKDF SHA-256" as defined in [I-D.ietf-cose-msg] MUST be supported." I would have assumed at the session key provided by the AS to the client and the key embedded in the access token is used directly within TLS as a PSK. - Could you explain this statement: " If the security association with RS still exists and RS has indicated support for session renegotiation according to [RFC5746], the new Access Token MAY be used to renegotiate the existing DTLS session. In this case, the Access Token is used as "psk_identity" as defined in Section 4.1. The Client MAY also perform a new DTLS handshake according to Section 4.1 that replaces the existing DTLS session. " What are you trying to accomplish? Do you expect authorization information to change frequently? What security association are you talking about in the paragraph above? Ciao Hannes ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-dtls-authorize
Hi Daniel, On 2021-01-28, Daniel Migault wrote: > Apparently, the change on the DTLS profile has not been noticed by > everyone in the WG, so I am bringing the discussion here. > > The change has been made as a response to a comment from the security > directorate. Please provide your feed backs by Feb 4 (but preferably > before)- and potentially propose the text you would like to see if you > disagree with the change. I agree with the change (although I do not care very much but the new text makes more sense than the old) because the change suggested in the secdir review is not about mandating one protocol or the other. It is about which protocol you need to implement if you want to use that protocol between C and AS. In short: * the OSCORE profile mandates that "if you want to use CoAP over OSCORE between the C and the AS, you need to follow the steps in the OSCORE specification and look somewhere else if you want to use another protocol", and * the DTLS profile mandates that "if you want to use CoAP over DTLS between the C and the AS, you need to follow the steps in the DTLS specification and look somewhere else if you want to use another protocol" Grüße Olaf ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-dtls-authorize
Hi Olaf, When I read the draft I don't see how the change is reflected in your summary, actually your summary shows no difference between OSCORE and DTLS profile, while actually there is one. This is the difference we are discussing in the DTLS profile, about secure communication between Client and Authorization Server: 1. DTLS OLD: The use of CoAP and DTLS for this communication is RECOMMENDED in this profile, other protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]) MAY be used instead. 2. DTLS CURRENT: The use of CoAP and DTLS for this communication is REQUIRED in this profile. Other protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]) will require specification of additional profile(s). 3. OSCORE CURRENT: The use of CoAP and OSCORE ([RFC8613]) for this communication is RECOMMENDED in this profile; other protocols fulfilling the security requirements defined in section 5 of [I-D.ietf-ace-oauth-authz] (such as HTTP and DTLS or TLS) MAY be used instead. 3. allows for applications to use this OSCORE profile "coap_oscore" and OSCORE between C and AS, but also if they prefer, DTLS between C and AS, or other security protocols that fulfil the security requirements of the framework. 1. also allows for the same for the DTLS profile (although it might be good to clarify that other protocols are only allowed if they fulfil the sec requirements). 2. does NOT allow for "coap_dtls" to use anything else than DTLS between C and AS. If C and AS want to use e.g. TLS, a new profile needs to be defined. This doesn't seem like a good idea. About the "need to look somewhere else" : the only thing we say in the profiles is that C and AS have to have set up a secure communication channel. That is not really protocol specific, how that is established is out of scope of the profiles. The question is: do we really need to specify one different profile for each security protocol used between C and AS? I hope not. So my preference would update the text in the DTLS profile: NEW: The use of CoAP and DTLS for this communication is RECOMMENDED in this profile, other protocols fulfilling the security requirements defined in section 5 of [I-D.ietf-ace-oauth-authz] MAY be used instead. Francesca On 28/01/2021, 18:11, "Ace on behalf of Olaf Bergmann" wrote: Hi Daniel, On 2021-01-28, Daniel Migault wrote: > Apparently, the change on the DTLS profile has not been noticed by > everyone in the WG, so I am bringing the discussion here. > > The change has been made as a response to a comment from the security > directorate. Please provide your feed backs by Feb 4 (but preferably > before)- and potentially propose the text you would like to see if you > disagree with the change. I agree with the change (although I do not care very much but the new text makes more sense than the old) because the change suggested in the secdir review is not about mandating one protocol or the other. It is about which protocol you need to implement if you want to use that protocol between C and AS. In short: * the OSCORE profile mandates that "if you want to use CoAP over OSCORE between the C and the AS, you need to follow the steps in the OSCORE specification and look somewhere else if you want to use another protocol", and * the DTLS profile mandates that "if you want to use CoAP over DTLS between the C and the AS, you need to follow the steps in the DTLS specification and look somewhere else if you want to use another protocol" Grüße Olaf ___ 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
Re: [Ace] draft-ietf-ace-dtls-authorize
I agree with Francesca that we should only RECOMMEND CoAP+DTLS for "both legs" of communication with the AS -- the intent of the framework is that we can decouple the protocol used in the different interactions if needed. -Ben P.S. The sentence prior to the quoted ones refers to Sections 5.6 and 5.6 of the framework for the token and introspection endpoint descriptions; these seem to be 5.8 and 5.9, respectively, in draft-ietf-ace-oauth-authz-36. On Fri, Jan 29, 2021 at 01:15:14PM +, Francesca Palombini wrote: > Hi Olaf, > > When I read the draft I don't see how the change is reflected in your > summary, actually your summary shows no difference between OSCORE and DTLS > profile, while actually there is one. This is the difference we are > discussing in the DTLS profile, about secure communication between Client and > Authorization Server: > > 1. DTLS OLD: >The use of CoAP >and DTLS for this communication is RECOMMENDED in this profile, other >protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]) MAY be >used instead. > > 2. DTLS CURRENT: > The use of CoAP >and DTLS for this communication is REQUIRED in this profile. Other >protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]) will >require specification of additional profile(s). > > 3. OSCORE CURRENT: > The >use of CoAP and OSCORE ([RFC8613]) for this communication is >RECOMMENDED in this profile; other protocols fulfilling the security >requirements defined in section 5 of [I-D.ietf-ace-oauth-authz] (such >as HTTP and DTLS or TLS) MAY be used instead. > > 3. allows for applications to use this OSCORE profile "coap_oscore" and > OSCORE between C and AS, but also if they prefer, DTLS between C and AS, or > other security protocols that fulfil the security requirements of the > framework. > 1. also allows for the same for the DTLS profile (although it might be good > to clarify that other protocols are only allowed if they fulfil the sec > requirements). > 2. does NOT allow for "coap_dtls" to use anything else than DTLS between C > and AS. If C and AS want to use e.g. TLS, a new profile needs to be defined. > This doesn't seem like a good idea. > > About the "need to look somewhere else" : the only thing we say in the > profiles is that C and AS have to have set up a secure communication channel. > That is not really protocol specific, how that is established is out of scope > of the profiles. > > The question is: do we really need to specify one different profile for each > security protocol used between C and AS? I hope not. > > So my preference would update the text in the DTLS profile: > > NEW: >The use of CoAP >and DTLS for this communication is RECOMMENDED in this profile, other >protocols fulfilling the security >requirements defined in section 5 of [I-D.ietf-ace-oauth-authz] MAY be >used instead. > > Francesca > > On 28/01/2021, 18:11, "Ace on behalf of Olaf Bergmann" on behalf of bergm...@tzi.org> wrote: > > Hi Daniel, > > On 2021-01-28, Daniel Migault > wrote: > > > Apparently, the change on the DTLS profile has not been noticed by > > everyone in the WG, so I am bringing the discussion here. > > > > The change has been made as a response to a comment from the security > > directorate. Please provide your feed backs by Feb 4 (but preferably > > before)- and potentially propose the text you would like to see if you > > disagree with the change. > > I agree with the change (although I do not care very much but the new > text makes more sense than the old) because the change suggested in the > secdir review is not about mandating one protocol or the other. It is > about which protocol you need to implement if you want to use that > protocol between C and AS. In short: > > * the OSCORE profile mandates that "if you want to use CoAP over OSCORE > between the C and the AS, you need to follow the steps in the > OSCORE specification and look somewhere else if you want to use > another protocol", and > * the DTLS profile mandates that "if you want to use CoAP over DTLS > between the C and the AS, you need to follow the steps in the > DTLS specification and look somewhere else if you want to use > another protocol" > > Grüße > Olaf > > ___ > 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
Re: [Ace] draft-ietf-ace-dtls-authorize
On 2021-01-29, Francesca Palombini wrote: > So my preference would update the text in the DTLS profile: > > NEW: >The use of CoAP >and DTLS for this communication is RECOMMENDED in this profile, other >protocols fulfilling the security >requirements defined in section 5 of [I-D.ietf-ace-oauth-authz] MAY be >used instead. I can live with that. Grüße Olaf ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-dtls-authorize
great, so I suggest we publish the update before next interim meeting. Yours, Daniel From: Olaf Bergmann Sent: Wednesday, February 3, 2021 12:58 PM To: Francesca Palombini Cc: ace@ietf.org ; Benjamin Kaduk ; Daniel Migault Subject: Re: [Ace] draft-ietf-ace-dtls-authorize On 2021-01-29, Francesca Palombini wrote: > So my preference would update the text in the DTLS profile: > > NEW: >The use of CoAP >and DTLS for this communication is RECOMMENDED in this profile, other >protocols fulfilling the security >requirements defined in section 5 of [I-D.ietf-ace-oauth-authz] MAY be >used instead. I can live with that. Grüße Olaf ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-dtls-authorize-01
On 2017-10-01 11:35, Hannes Tschofenig wrote:
[chair hat off]
Hi all,
Hello Hannes,
thank you for your comments. Replies inline.
/Ludwig
I took a look at the draft and noticed a few minor things:
- The document should talk about "profiles" rather than "profile" since
it specifies at least two profiles, namely the RPK and the PSK profiles
with DTLS. I suspect an implementation is only expected to implement one
of them rather than both.
I would have said that PSK vs RPK are just options within the DTLS
profile, but I have no strong opinion about this.
You have a point that constrained implementations are likely to only
support one option.
- Editorial comment: most of the articles are missing, which makes the
document harder to read.
Will fix.
- AS discovery: Wouldn't the client need to know the AS upfront when
using RPK and PSK (since it has to share a PSK with the AS or, in case
of the RPK, has to have the RPK with the server exchanged out of band)?
There are two scenarios how this could work:
1.) The client doesn't know the AS upfront, but after getting the
discovery message it can register at the AS through some out-of-scope
method in order to establish the PSK or RPK needed for communication
with the token endpoint.
2.) The discovery hint just helps the client to select an AS from a set
of previously known ASs.
- There are two options provided for conveying the access token to the
RS, either either a dedicated endpoint or inband within the DTLS
exchange. There are pros and cons regarding the usage of both; is the
idea to settle with one approach in the end or do you envision both
options to be available in the final version of the specification.
Note that the inband version only works for PSK, so the authz-info
endpoint is at least needed for RPK. I would guess that constrained
implementations would settle for just one option. Maybe we should
specify some signaling for that.
- Regarding the dynamic update of authorization information. Since the
access token is a PoP token I believe you will have to demonstrate the
possession of the key every time you change the access token. (Section
2.4 gives me a different impression.)
Not necessarily. Since you still have the session open, you only need to
have the AS to link the new token to the same pop key (for which you
already proved possession). The framework (in conjunction with the cnf
draft) have mechanisms for this).
- When the access token is conveyed inband in DTLS as part of the
PSK_identity then the text on page 12 is applicable. The description in
CDDL format confuses me. Normally, it should be quite simple: either you
transmit a psk_identity field or you convey the access token. The server
would figure it out. Is this just a complicated way to express this
semantic or do you have something else in mind?
The actual functionality that is specified is this:
psk_identity = {kid : } | {access_token : }
does that make more sense to you?
I'm not entirely happy with that solution, since we now have the weird
situation where a client oblivious of the profile might use the
psk_identity as intended, thus we actually have:
psk_identity = {kid : } | {access_token : } | kid
and my code needs to handle all 3 cases. I agree this needs to be discussed.
(Btw, my understanding is that the server does not need to send a
illegal_parameter alert when it the psk_identity does not lead to a
successful authentication. Is this your suggestion or is this taken from
TLS PSK?)
- What is the reasoning behind this statement:
"This specification mandates that at least the key derivation
algorithm "HKDF SHA-256" as defined in [I-D.ietf-cose-msg] MUST be
supported."
I would have assumed at the session key provided by the AS to the client
and the key embedded in the access token is used directly within TLS as
a PSK.
I'm not sure about this, Olaf, Steffi?
- Could you explain this statement:
"
If the security association with RS still exists and RS has indicated
support for session renegotiation according to [RFC5746], the new
Access Token MAY be used to renegotiate the existing DTLS session.
In this case, the Access Token is used as "psk_identity" as defined
in Section 4.1. The Client MAY also perform a new DTLS handshake
according to Section 4.1 that replaces the existing DTLS session.
"
What are you trying to accomplish? Do you expect authorization
information to change frequently? What security association are you
talking about in the paragraph above?
The idea is to be able to handle changing authorization information,
without having to redo the full DTLS handshake. The scenario would be
that a client gains access to a resource, starts performing a series of
operations, and at some point gets a "permission denied". The client
would then go back to the token endpoint at the AS and request a new
access token with a wider scope, that it would submit to the RS.
The
Re: [Ace] draft-ietf-ace-dtls-authorize-01
Hello Hannes, Thank you very much for your comments. I am replying to the comment that Ludwig did not yet address: Ludwig Seitz writes: > On 2017-10-01 11:35, Hannes Tschofenig wrote: >> - What is the reasoning behind this statement: >> >> "This specification mandates that at least the key derivation >> algorithm "HKDF SHA-256" as defined in [I-D.ietf-cose-msg] MUST be >> supported." >> >> I would have assumed at the session key provided by the AS to the client >> and the key embedded in the access token is used directly within TLS as >> a PSK. Yes, you could embed the session key in the access token. But then, you would always have to encrypt the access token and ensure that is never decrypted by unauthorized parties. Key derivation allows you to transfer the access token unencrypted (as long as the privacy objectives are met, of course). This could even save some bytes in the token as the encrypted session key does not have to be transferred. This mechanism has previously been discussed in section 6 of [1] but now has been adjusted from the simple ad-hoc syntax in DCAF to the more flexible COSE method. [1] https://tools.ietf.org/html/draft-gerdes-ace-dcaf-authorize-04#section-6 Grüße Olaf ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
