Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Olaf Bergmann]

Jim, Ben,

Jim Schaad  writes:

[decrypted access_token as HKDF input]

>> Now you have lost me. The innermost COSE wrapping layer would be the one in
>> the contents of the cnf claim, given that we do not invent claims that also 
>> can
>> include COSE structures?
>
> Yes this is the binary string that holds the claims.  It would be
> possible to have multiple COSE layers - i.e. encrypt and signing
> layers, and you would want to make sure that you agree on where you
> are pulling the content.

I understand. I got a bit confused because when using key derivation,
the access token does not necessarily have to be encrypted.

> Using the token itself however is fine and you don't need to try and deal 
> with this.

Actually, I would prefer that. For some reason, I was under the
impression that the access token needs to be decrypted before key
derivation can be done. Maybe this was in the very first version where
only the kid was used as input.

Grüße
Olaf

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

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Jim Schaad]

> -Original Message-
> From: Olaf Bergmann 
> Sent: Wednesday, July 1, 2020 1:25 AM
> To: Jim Schaad 
> Cc: 'Benjamin Kaduk' ; 'Carsten Bormann' ;
> ace@ietf.org; draft-ietf-ace-dtls-authorize@ietf.org
> Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
> 
> Hi Jim,
> 
> Jim Schaad  writes:
> 
> > If you are not doing a re-encoding of the token, then I believe that
> > preferred serialization and deterministic serialization are going to
> > generate the same answer.  With the map being used then this is not
> > true, and it is also true that the change in map ordering will hit
> > this.
> 
> There seems to be agreement on this, and therefore I will change the text
> following Carsten's proposal (use bytes for the access_tocken and state that
> preferred serialization and deterministic serialization should be used for the
> CBOR serialization.
> 
> > This is a piece of the document that I have never implemented because
> > I just don't believe that this option is a reasonable thing to require
> > being done so I missed the fact that the original encoded token is not
> > being used.
> 
> You haven't missed anything—the intention always was to use the original
> encoded token as transferred on the wire. The issue was introduced in this 
> last
> unpublished change that should have clarified the serialization of the data
> structure that is used as input for the HKDF.
> 
> > There is a possible DOS attack by a MITM changing the encoding on the
> > token since it is not protected when posted to the RS.
> 
> Yes, this is inherent to the upload mechanism and unrelated to key derivation.
> My intention is to access-protect the token endpoint in my implementation such
> that only authorized clients can upload an access token.
> 
> > If this is going to be changed, I would say use the binary string
> > encoding from the bstr of the inner most COSE wrapping layer as the
> > input to minimize this.
> 
> Now you have lost me. The innermost COSE wrapping layer would be the one in
> the contents of the cnf claim, given that we do not invent claims that also 
> can
> include COSE structures?

Yes this is the binary string that holds the claims.  It would be possible to 
have multiple COSE layers - i.e. encrypt and signing layers, and you would want 
to make sure that you agree on where you are pulling the content.

Using the token itself however is fine and you don't need to try and deal with 
this.

Jim

> 
> Grüße
> Olaf

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

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Benjamin Kaduk]

On Wed, Jul 01, 2020 at 10:25:27AM +0200, Olaf Bergmann wrote:
> Hi Jim,
> 
> Jim Schaad  writes:
> 
> > If you are not doing a re-encoding of the token, then I believe that
> > preferred serialization and deterministic serialization are going to
> > generate the same answer.  With the map being used then this is not
> > true, and it is also true that the change in map ordering will hit
> > this.
> 
> There seems to be agreement on this, and therefore I will change the
> text following Carsten's proposal (use bytes for the access_tocken and
> state that preferred serialization and deterministic serialization
> should be used for the CBOR serialization.
> 
> > This is a piece of the document that I have never implemented
> > because I just don't believe that this option is a reasonable thing to
> > require being done so I missed the fact that the original encoded
> > token is not being used.
> 
> You haven't missed anything—the intention always was to use the original
> encoded token as transferred on the wire. The issue was introduced in
> this last unpublished change that should have clarified the
> serialization of the data structure that is used as input for the HKDF.
> 
> > There is a possible DOS attack by a MITM changing the encoding on the
> > token since it is not protected when posted to the RS.
> 
> Yes, this is inherent to the upload mechanism and unrelated to key
> derivation. My intention is to access-protect the token endpoint in my
> implementation such that only authorized clients can upload an access
> token.
> 
> > If this is going to be changed, I would say use the binary string
> > encoding from the bstr of the inner most COSE wrapping layer as the
> > input to minimize this.
> 
> Now you have lost me. The innermost COSE wrapping layer would be the one
> in the contents of the cnf claim, given that we do not invent claims
> that also can include COSE structures?

I think the intention is the "innermost COSE structure protecting the
[entire] access token", to accomodate the fact that the access token might
be COSE_Mac(), COSE_Encrypt(COSE_Mac()), etc., and not necessarily a fixed
number of layers of COSE protection between the access token ciphertext and
the CWT claim set.

-Ben

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

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Olaf Bergmann]

Hi Jim,

Jim Schaad  writes:

> If you are not doing a re-encoding of the token, then I believe that
> preferred serialization and deterministic serialization are going to
> generate the same answer.  With the map being used then this is not
> true, and it is also true that the change in map ordering will hit
> this.

There seems to be agreement on this, and therefore I will change the
text following Carsten's proposal (use bytes for the access_tocken and
state that preferred serialization and deterministic serialization
should be used for the CBOR serialization.

> This is a piece of the document that I have never implemented
> because I just don't believe that this option is a reasonable thing to
> require being done so I missed the fact that the original encoded
> token is not being used.

You haven't missed anything—the intention always was to use the original
encoded token as transferred on the wire. The issue was introduced in
this last unpublished change that should have clarified the
serialization of the data structure that is used as input for the HKDF.

> There is a possible DOS attack by a MITM changing the encoding on the
> token since it is not protected when posted to the RS.

Yes, this is inherent to the upload mechanism and unrelated to key
derivation. My intention is to access-protect the token endpoint in my
implementation such that only authorized clients can upload an access
token.

> If this is going to be changed, I would say use the binary string
> encoding from the bstr of the inner most COSE wrapping layer as the
> input to minimize this.

Now you have lost me. The innermost COSE wrapping layer would be the one
in the contents of the cnf claim, given that we do not invent claims
that also can include COSE structures?

Grüße
Olaf

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

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Benjamin Kaduk]

Hi Olaf,

On Tue, Jun 30, 2020 at 12:19:41PM +0200, Olaf Bergmann wrote:
> Hi Ben,
> 
> Thank you for the quick followup and another set of very useful
> comments. I have created a working copy with updates as listed
> inline. If you want me to, I can submit these as -12.

If it's easy for you, please go ahead.
Inline.

> Benjamin Kaduk  writes:
> 
> > Hi Olaf,
> >
> > Thanks for the updated -11!
> > Some minor replies below, though in general the proposals look good.
> >
> > On Thu, Jun 18, 2020 at 02:38:32PM +0200, Olaf Bergmann wrote:
> >> Hi Benjamin,
> >> 
> >> Benjamin Kaduk  writes:
> >> 
> >> > Thanks!  I think we will probably need an -11 fairly soon, though, given
> >> > the remaining comments I have.
> >> 
> >> We have just submitted -11 that addresses your comments. See below for
> >> detailed responses. I have trimmed-down the email thread context a bit
> >> to improved readability and focus on the recent comments.
> >> 
> >> > A couple general remarks looking at the -09-to-10 diff (not all new in
> >> > the -10, so I guess I missed it the first time around):
> >> >
> >> > In Section 3.2.1, I suggest applying:
> >> >
> >> > OLD:
> >> >   [...] If CBOR web tokens [RFC8392] are used as recommended in
> >> >   [I-D.ietf-ace-oauth-authz] [...]
> >> >
> >> > NEW:
> >> >   [...] If CBOR web tokens [RFC8392] are used (as recommended in
> >> >   [I-D.ietf-ace-oauth-authz]) [...]
> >> >
> >> > Making this a parenthetical statement makes it clear that the
> >> > conditional for "keys MUST be encoded" is "CWT are used" and separate
> >> > from the recommendation to do so.
> >> 
> >> Done
> >> 
> >> > Also in 3.2.1, we now have these two statements in fairly close
> >> > proximity:
> >> >
> >> >[RFC8747].  The resource server MUST use its own raw public key in
> >> >the DTLS handshake with the client.  If the resource server has
> >> >several raw public keys, it must already know which key it is
> >> >supposed to use with this client.  How this is achieved is not part
> >> >of this profile.
> >> >
> >> >The resource server MUST use the keying material that the
> >> >authorizations server has specified in the "cnf" parameter in the
> >> >access token for the DTLS handshake with the client.  Thus, the
> >> >
> >> > which seems a bit redundant and potentially in conflict.  Can we
> >> > consolidate this requirement a bit?
> >> 
> >> Yes, the wording is a bit confusing. The following proposal states
> >> the intention more clearly, I think:
> >> 
> >> NEW: 
> >> 
> >> The raw public key used in the DTLS handshake with the client MUST
> >> belong to the resource server. If the resource server has several
> >
> > (Someone might complain that this first sentence is tautological, but I
> > think we should leave it for now.)
> 
> Okay.
> 
> >> OLD:
> >>If a resource server receives a ClientKeyExchange message that
> >>contains a `psk_identity` with a length greater than zero, it MUST
> >>process the contents of the `psk_identity` field as access token
> >>that is stored with the authorization information endpoint, before
> >>continuing the DTLS handshake. If the contents of the
> >>`psk_identity` do not yield a valid access token for the requesting
> >>client, the resource server aborts the DTLS handshake with an
> >>`illegal_parameter` alert.
> >> 
> >> NEW:
> >> 
> >>If a resource server receives a ClientKeyExchange message that
> >>contains a `psk_identity` with a length greater than zero, it MUST
> >>parse the contents of the `psk_identity` field as CBOR data
> >>structure and process the contents as following:
> >> 
> >>   * If the data contains a `cnf` field with a `COSE_Key` structure
> >> with a `kid`, the resource server continues the DTLS handshake
> >> with the stored key associated with this kid.
> >
> > Maybe "corresponding" or "associated" stored key, since there is not
> > necessarily a unique kid/key relationship?

Rereading, my suggestion of "associated" doesn't make much sense, sorry.

> Hm, I was hoping that this is sufficiently expressed by "the stored
> key associated with this kid". My assumption is that we have a mapping
> from kids to keys where a kid is mapped to at most one key. (Usually,
> this would be a bijection but there might be cases where a kid is known
> and the key is not yet known or has expired.
> 
> How about this:
> 
> OLD:
> 
>  continues the DTLS handshake with the stored key associated with
>  this kid.
> 
> NEW:
> 
>  continues the DTLS handshake with the associated key that corresponds
>  to this kid.

I think this is better, thanks.

> >>   * If the data comprises additional CWT information, this
> >> information must be stored as access token for this DTLS
> >
> > nit: "as an"
> 
> Fixed, thanks!
> 
> >> >> > I think we need to give some guidance about what the semantics are 
> >> >> > if/when
> >> >> > it happens.  My inclination 

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Jim Schaad]

> -Original Message-
> From: Benjamin Kaduk 
> Sent: Tuesday, June 30, 2020 9:25 AM
> To: Carsten Bormann 
> Cc: Olaf Bergmann ; draft-ietf-ace-dtls-
> authorize@ietf.org; ace@ietf.org
> Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
> 
> On Tue, Jun 30, 2020 at 04:21:34PM +0200, Carsten Bormann wrote:
> > On 2020-06-30, at 12:19, Olaf Bergmann  wrote:
> > >
> > > NEW:
> > >
> > >   All CBOR data types are encoded in canonical CBOR as defined in
> > >   Section 3.9 of {{RFC7049}}. This implies in particular that the
> > >   `type` and `L` components use the minimum length encoding
> >
> > Note that 7049bis, which has been submitted to IESG already, all but
> deprecates this and replaces this with “deterministic encoding”.  There is 
> only
> one actual technical change, which is about map ordering.  Also, please check
> whether “preferred encoding” would actually be enough.
> >
> > I would generally prefer to avoid the need for deterministic/canonical
> encoding — is there really a need to re-encode the token?
> 
> My original comment was in the context of a novel data structure being used as
> HKDF input, which has 'type' and 'L' fields unrelated to any preexisting 
> token.
> Using the 'access_token' map as transmitted would be helpful, but is not
> sufficient.

If you are not doing a re-encoding of the token, then I believe that preferred 
serialization and deterministic serialization are going to generate the same 
answer.  With the map being used then this is not true, and it is also true 
that the change in map ordering will hit this.  This is a piece of the document 
that I have never implemented because I just don't believe that this option is 
a reasonable thing to require being done so I missed the fact that the original 
encoded token is not being used.  

There is a possible DOS attack by a MITM changing the encoding on the token 
since it is not protected when posted to the RS.  If this is going to be 
changed, I would say use the binary string encoding from the bstr of the inner 
most COSE wrapping layer as the input to minimize this.

Jim


> 
> -Ben

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

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Olaf Bergmann]

Carsten Bormann  writes:

>>> 
>>> I would generally prefer to avoid the need for deterministic/canonical
>>> encoding — is there really a need to re-encode the token?
>> 
>> There is no need to re-encode the token, and I do not expect that this
>> would happen if the authorization server has used a finite length.
>
> So would we be better off with:
>
>
>  info = [
>type : tstr,
>L : uint,
>access_token: bytes
>  ]
>
> Where access_token is the token in original encoding?  No need to re-encode 
> the token then.

That is what I wanted to hear.

>> I am more than happy to get rid of the ordering constraints on CBOR maps
>> but I am not sure about referencing the -bis. Can we do that at this
>> stage?
>
> Both documents are in IESG processing, specifically:
> dtls-authorize: AD Evaluation::External Party
> 7049bis: Publication Requested

Looking at the deterministic encoding (Section 4.2 of
draft-ietf-cbor-7049bis-14), I am happy referencing that instead of
canonical CBOR. Any objections?

Grüße
Olaf

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

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Carsten Bormann]

>> 
>> I would generally prefer to avoid the need for deterministic/canonical
>> encoding — is there really a need to re-encode the token?
> 
> There is no need to re-encode the token, and I do not expect that this
> would happen if the authorization server has used a finite length.

So would we be better off with:


 info = [
   type : tstr,
   L : uint,
   access_token: bytes
 ]

Where access_token is the token in original encoding?  No need to re-encode the 
token then.

> I am more than happy to get rid of the ordering constraints on CBOR maps
> but I am not sure about referencing the -bis. Can we do that at this
> stage?

Both documents are in IESG processing, specifically:
dtls-authorize: AD Evaluation::External Party
7049bis: Publication Requested

Potential emergency escape: reference Section 10 of rfc8152bis-struct (which is 
even further along at IESG Evaluation::Revised I-D Needed).

> Note: Up to now, we could even do without a normative reference to RFC 7049.

Yes, but that’s cheating (indirect normative reference through 8610).

Grüße, Carsten

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

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Olaf Bergmann]

Carsten Bormann  writes:

> On 2020-06-30, at 12:19, Olaf Bergmann  wrote:
>> 
>> NEW:
>> 
>>   All CBOR data types are encoded in canonical CBOR as defined in
>>   Section 3.9 of {{RFC7049}}. This implies in particular that the
>>   `type` and `L` components use the minimum length encoding
>
> Note that 7049bis, which has been submitted to IESG already, all but
> deprecates this and replaces this with “deterministic encoding”.
> There is only one actual technical change, which is about map
> ordering.  Also, please check whether “preferred encoding” would
> actually be enough.
>
> I would generally prefer to avoid the need for deterministic/canonical
> encoding — is there really a need to re-encode the token?

There is no need to re-encode the token, and I do not expect that this
would happen if the authorization server has used a finite length.

I am more than happy to get rid of the ordering constraints on CBOR maps
but I am not sure about referencing the -bis. Can we do that at this
stage?

Note: Up to now, we could even do without a normative reference to RFC 7049.

Grüße
Olaf

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

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Benjamin Kaduk]

On Tue, Jun 30, 2020 at 04:21:34PM +0200, Carsten Bormann wrote:
> On 2020-06-30, at 12:19, Olaf Bergmann  wrote:
> > 
> > NEW:
> > 
> >   All CBOR data types are encoded in canonical CBOR as defined in
> >   Section 3.9 of {{RFC7049}}. This implies in particular that the
> >   `type` and `L` components use the minimum length encoding
> 
> Note that 7049bis, which has been submitted to IESG already, all but 
> deprecates this and replaces this with “deterministic encoding”.  There is 
> only one actual technical change, which is about map ordering.  Also, please 
> check whether “preferred encoding” would actually be enough.
> 
> I would generally prefer to avoid the need for deterministic/canonical 
> encoding — is there really a need to re-encode the token?

My original comment was in the context of a novel data structure being used
as HKDF input, which has 'type' and 'L' fields unrelated to any preexisting
token.  Using the 'access_token' map as transmitted would be helpful, but
is not sufficient.

-Ben

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

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Carsten Bormann]

On 2020-06-30, at 12:19, Olaf Bergmann  wrote:
> 
> NEW:
> 
>   All CBOR data types are encoded in canonical CBOR as defined in
>   Section 3.9 of {{RFC7049}}. This implies in particular that the
>   `type` and `L` components use the minimum length encoding

Note that 7049bis, which has been submitted to IESG already, all but deprecates 
this and replaces this with “deterministic encoding”.  There is only one actual 
technical change, which is about map ordering.  Also, please check whether 
“preferred encoding” would actually be enough.

I would generally prefer to avoid the need for deterministic/canonical encoding 
— is there really a need to re-encode the token?

Grüße, Carsten

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

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Olaf Bergmann]

Hi Ben,

Thank you for the quick followup and another set of very useful
comments. I have created a working copy with updates as listed
inline. If you want me to, I can submit these as -12.

Benjamin Kaduk  writes:

> Hi Olaf,
>
> Thanks for the updated -11!
> Some minor replies below, though in general the proposals look good.
>
> On Thu, Jun 18, 2020 at 02:38:32PM +0200, Olaf Bergmann wrote:
>> Hi Benjamin,
>> 
>> Benjamin Kaduk  writes:
>> 
>> > Thanks!  I think we will probably need an -11 fairly soon, though, given
>> > the remaining comments I have.
>> 
>> We have just submitted -11 that addresses your comments. See below for
>> detailed responses. I have trimmed-down the email thread context a bit
>> to improved readability and focus on the recent comments.
>> 
>> > A couple general remarks looking at the -09-to-10 diff (not all new in
>> > the -10, so I guess I missed it the first time around):
>> >
>> > In Section 3.2.1, I suggest applying:
>> >
>> > OLD:
>> >   [...] If CBOR web tokens [RFC8392] are used as recommended in
>> >   [I-D.ietf-ace-oauth-authz] [...]
>> >
>> > NEW:
>> >   [...] If CBOR web tokens [RFC8392] are used (as recommended in
>> >   [I-D.ietf-ace-oauth-authz]) [...]
>> >
>> > Making this a parenthetical statement makes it clear that the
>> > conditional for "keys MUST be encoded" is "CWT are used" and separate
>> > from the recommendation to do so.
>> 
>> Done
>> 
>> > Also in 3.2.1, we now have these two statements in fairly close
>> > proximity:
>> >
>> >[RFC8747].  The resource server MUST use its own raw public key in
>> >the DTLS handshake with the client.  If the resource server has
>> >several raw public keys, it must already know which key it is
>> >supposed to use with this client.  How this is achieved is not part
>> >of this profile.
>> >
>> >The resource server MUST use the keying material that the
>> >authorizations server has specified in the "cnf" parameter in the
>> >access token for the DTLS handshake with the client.  Thus, the
>> >
>> > which seems a bit redundant and potentially in conflict.  Can we
>> > consolidate this requirement a bit?
>> 
>> Yes, the wording is a bit confusing. The following proposal states
>> the intention more clearly, I think:
>> 
>> NEW: 
>> 
>> The raw public key used in the DTLS handshake with the client MUST
>> belong to the resource server. If the resource server has several
>
> (Someone might complain that this first sentence is tautological, but I
> think we should leave it for now.)

Okay.

>> OLD:
>>If a resource server receives a ClientKeyExchange message that
>>contains a `psk_identity` with a length greater than zero, it MUST
>>process the contents of the `psk_identity` field as access token
>>that is stored with the authorization information endpoint, before
>>continuing the DTLS handshake. If the contents of the
>>`psk_identity` do not yield a valid access token for the requesting
>>client, the resource server aborts the DTLS handshake with an
>>`illegal_parameter` alert.
>> 
>> NEW:
>> 
>>If a resource server receives a ClientKeyExchange message that
>>contains a `psk_identity` with a length greater than zero, it MUST
>>parse the contents of the `psk_identity` field as CBOR data
>>structure and process the contents as following:
>> 
>>   * If the data contains a `cnf` field with a `COSE_Key` structure
>> with a `kid`, the resource server continues the DTLS handshake
>> with the stored key associated with this kid.
>
> Maybe "corresponding" or "associated" stored key, since there is not
> necessarily a unique kid/key relationship?

Hm, I was hoping that this is sufficiently expressed by "the stored
key associated with this kid". My assumption is that we have a mapping
from kids to keys where a kid is mapped to at most one key. (Usually,
this would be a bijection but there might be cases where a kid is known
and the key is not yet known or has expired.

How about this:

OLD:

 continues the DTLS handshake with the stored key associated with
 this kid.

NEW:

 continues the DTLS handshake with the associated key that corresponds
 to this kid.

>>   * If the data comprises additional CWT information, this
>> information must be stored as access token for this DTLS
>
> nit: "as an"

Fixed, thanks!

>> >> > I think we need to give some guidance about what the semantics are 
>> >> > if/when
>> >> > it happens.  My inclination would be to say that DTLS resumption can be
>> >> > used to amortize the cost of a handshake, but DTLS 1.2 resumption does 
>> >> > not
>> >> > provide forward secrecy and also does not provide an opportunity for the
>> >> > client to prove possession of the PoP key, so servers will want to
>> >> > periodically force a full handshake according to their authentication
>> >> > requirements.  I'd also be inclined to forbid renegotiation entirely.
>> >> 
>> >> True, 

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Benjamin Kaduk]

Hi Olaf,

Thanks for the updated -11!
Some minor replies below, though in general the proposals look good.

On Thu, Jun 18, 2020 at 02:38:32PM +0200, Olaf Bergmann wrote:
> Hi Benjamin,
> 
> Benjamin Kaduk  writes:
> 
> > Thanks!  I think we will probably need an -11 fairly soon, though, given
> > the remaining comments I have.
> 
> We have just submitted -11 that addresses your comments. See below for
> detailed responses. I have trimmed-down the email thread context a bit
> to improved readability and focus on the recent comments.
> 
> > A couple general remarks looking at the -09-to-10 diff (not all new in
> > the -10, so I guess I missed it the first time around):
> >
> > In Section 3.2.1, I suggest applying:
> >
> > OLD:
> >   [...] If CBOR web tokens [RFC8392] are used as recommended in
> >   [I-D.ietf-ace-oauth-authz] [...]
> >
> > NEW:
> >   [...] If CBOR web tokens [RFC8392] are used (as recommended in
> >   [I-D.ietf-ace-oauth-authz]) [...]
> >
> > Making this a parenthetical statement makes it clear that the
> > conditional for "keys MUST be encoded" is "CWT are used" and separate
> > from the recommendation to do so.
> 
> Done
> 
> > Also in 3.2.1, we now have these two statements in fairly close
> > proximity:
> >
> >[RFC8747].  The resource server MUST use its own raw public key in
> >the DTLS handshake with the client.  If the resource server has
> >several raw public keys, it must already know which key it is
> >supposed to use with this client.  How this is achieved is not part
> >of this profile.
> >
> >The resource server MUST use the keying material that the
> >authorizations server has specified in the "cnf" parameter in the
> >access token for the DTLS handshake with the client.  Thus, the
> >
> > which seems a bit redundant and potentially in conflict.  Can we
> > consolidate this requirement a bit?
> 
> Yes, the wording is a bit confusing. The following proposal states
> the intention more clearly, I think:
> 
> NEW: 
> 
> The raw public key used in the DTLS handshake with the client MUST
> belong to the resource server. If the resource server has several

(Someone might complain that this first sentence is tautological, but I
think we should leave it for now.)

> raw public keys, it needs to determine which key to use. The
> authorization server can help with this decision by including a
> `cnf` parameter in the access token that is associated with this
> communication.  In this case, the resource server MUST use the
> information from the `cnf` field to select the proper keying
> material.
> 
> > In Section 3.3:
> >
> >To convey the same secret to the resource server, the authorization
> >server either includes it directly in the access token by means of
> >the "cnf" claim or it provides sufficient information to enable the
> >resource server to derive the key from the access token using key
> >derivation.
> >
> > This text could be read as prohibiting using token introspection to
> > obtain the C/RS shared key (if I remember correctly about "claim" being
> > a CWT thing and not a more generic term for a parameter associated with
> > a token).  I don't think that's the intent, so perhaps a wording tweak
> > is in order.
> 
> This now has been changed to:
> 
> NEW:
> 
> To convey the same secret to the resource server, the
> authorization server can include it directly in the access token
> by means of the `cnf` claim or provide sufficient information to
> enable the resource server to derive the shared secret from the
> access token. As an alternative, the resource server MAY use token
> introspection to retrieve the keying material for this access
> token directly from the authorization server.
> 
> > In Section 3.3.1:
> >
> >If a resource server receives a ClientKeyExchange message that
> >contains a "psk_identity" with a length greater than zero, it MUST
> >process the contents of the "psk_identity" field as access token that
> >is stored with the authorization information endpoint, before
> >continuing the DTLS handshake.  If the contents of the "psk_identity"
> >do not yield a valid access token for the requesting client, the
> >resource server aborts the DTLS handshake with an "illegal_parameter"
> >alert.
> >
> > The way this was reworded seems to imply that any "psk_identity" with
> > positive length is a full access token (as would have been uploaded to
> > the authz-info endpoint), which prevents the case previously described
> > where the identity is just a COSE_Key with the 'kid' from "rs_cnf".  So
> > I think we still need some kind of description of two potential
> > interpretations of the "psk_identity".
> 
> Yes, this is misleading. We have changed it as follows to indicate the
> two (non-exclusive) processing steps:
> 
> OLD:
>If a resource server receives a ClientKeyExchange message that
>contains a 

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Olaf Bergmann]

Hi Benjamin,

Benjamin Kaduk  writes:

> Thanks!  I think we will probably need an -11 fairly soon, though, given
> the remaining comments I have.

We have just submitted -11 that addresses your comments. See below for
detailed responses. I have trimmed-down the email thread context a bit
to improved readability and focus on the recent comments.

> A couple general remarks looking at the -09-to-10 diff (not all new in
> the -10, so I guess I missed it the first time around):
>
> In Section 3.2.1, I suggest applying:
>
> OLD:
>   [...] If CBOR web tokens [RFC8392] are used as recommended in
>   [I-D.ietf-ace-oauth-authz] [...]
>
> NEW:
>   [...] If CBOR web tokens [RFC8392] are used (as recommended in
>   [I-D.ietf-ace-oauth-authz]) [...]
>
> Making this a parenthetical statement makes it clear that the
> conditional for "keys MUST be encoded" is "CWT are used" and separate
> from the recommendation to do so.

Done

> Also in 3.2.1, we now have these two statements in fairly close
> proximity:
>
>[RFC8747].  The resource server MUST use its own raw public key in
>the DTLS handshake with the client.  If the resource server has
>several raw public keys, it must already know which key it is
>supposed to use with this client.  How this is achieved is not part
>of this profile.
>
>The resource server MUST use the keying material that the
>authorizations server has specified in the "cnf" parameter in the
>access token for the DTLS handshake with the client.  Thus, the
>
> which seems a bit redundant and potentially in conflict.  Can we
> consolidate this requirement a bit?

Yes, the wording is a bit confusing. The following proposal states
the intention more clearly, I think:

NEW: 

The raw public key used in the DTLS handshake with the client MUST
belong to the resource server. If the resource server has several
raw public keys, it needs to determine which key to use. The
authorization server can help with this decision by including a
`cnf` parameter in the access token that is associated with this
communication.  In this case, the resource server MUST use the
information from the `cnf` field to select the proper keying
material.

> In Section 3.3:
>
>To convey the same secret to the resource server, the authorization
>server either includes it directly in the access token by means of
>the "cnf" claim or it provides sufficient information to enable the
>resource server to derive the key from the access token using key
>derivation.
>
> This text could be read as prohibiting using token introspection to
> obtain the C/RS shared key (if I remember correctly about "claim" being
> a CWT thing and not a more generic term for a parameter associated with
> a token).  I don't think that's the intent, so perhaps a wording tweak
> is in order.

This now has been changed to:

NEW:

To convey the same secret to the resource server, the
authorization server can include it directly in the access token
by means of the `cnf` claim or provide sufficient information to
enable the resource server to derive the shared secret from the
access token. As an alternative, the resource server MAY use token
introspection to retrieve the keying material for this access
token directly from the authorization server.

> In Section 3.3.1:
>
>If a resource server receives a ClientKeyExchange message that
>contains a "psk_identity" with a length greater than zero, it MUST
>process the contents of the "psk_identity" field as access token that
>is stored with the authorization information endpoint, before
>continuing the DTLS handshake.  If the contents of the "psk_identity"
>do not yield a valid access token for the requesting client, the
>resource server aborts the DTLS handshake with an "illegal_parameter"
>alert.
>
> The way this was reworded seems to imply that any "psk_identity" with
> positive length is a full access token (as would have been uploaded to
> the authz-info endpoint), which prevents the case previously described
> where the identity is just a COSE_Key with the 'kid' from "rs_cnf".  So
> I think we still need some kind of description of two potential
> interpretations of the "psk_identity".

Yes, this is misleading. We have changed it as follows to indicate the
two (non-exclusive) processing steps:

OLD:
   If a resource server receives a ClientKeyExchange message that
   contains a `psk_identity` with a length greater than zero, it MUST
   process the contents of the `psk_identity` field as access token
   that is stored with the authorization information endpoint, before
   continuing the DTLS handshake. If the contents of the
   `psk_identity` do not yield a valid access token for the requesting
   client, the resource server aborts the DTLS handshake with an
   `illegal_parameter` alert.

NEW:

   If a resource server receives a ClientKeyExchange message that
   contains a 

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Benjamin Kaduk]

On Wed, May 13, 2020 at 06:18:25PM +0200, Olaf Bergmann wrote:
> Hi Ben,
> 
> Benjamin Kaduk  writes:
> 
> > Please go ahead and upload a new version to the datatracker when you get a
> > chance; I do have some further comments below.
> 
> Thanks again for the detailed response. I have just submitted version
> -10 that includes changes to your previous comments as well as the
> suggestions below:

Thanks!  I think we will probably need an -11 fairly soon, though, given
the remaining comments I have.

A couple general remarks looking at the -09-to-10 diff (not all new in
the -10, so I guess I missed it the first time around):

In Section 3.2.1, I suggest applying:

OLD:
  [...] If CBOR web tokens [RFC8392] are used as recommended in
  [I-D.ietf-ace-oauth-authz] [...]

NEW:
  [...] If CBOR web tokens [RFC8392] are used (as recommended in
  [I-D.ietf-ace-oauth-authz]) [...]

Making this a parenthetical statement makes it clear that the
conditional for "keys MUST be encoded" is "CWT are used" and separate
from the recommendation to do so.

Also in 3.2.1, we now have these two statements in fairly close
proximity:

   [RFC8747].  The resource server MUST use its own raw public key in
   the DTLS handshake with the client.  If the resource server has
   several raw public keys, it must already know which key it is
   supposed to use with this client.  How this is achieved is not part
   of this profile.

   The resource server MUST use the keying material that the
   authorizations server has specified in the "cnf" parameter in the
   access token for the DTLS handshake with the client.  Thus, the

which seems a bit redundant and potentially in conflict.  Can we
consolidate this requirement a bit?

In Section 3.3:

   To convey the same secret to the resource server, the authorization
   server either includes it directly in the access token by means of
   the "cnf" claim or it provides sufficient information to enable the
   resource server to derive the key from the access token using key
   derivation.

This text could be read as prohibiting using token introspection to
obtain the C/RS shared key (if I remember correctly about "claim" being
a CWT thing and not a more generic term for a parameter associated with
a token).  I don't think that's the intent, so perhaps a wording tweak
is in order.

In Section 3.3.1:

   If a resource server receives a ClientKeyExchange message that
   contains a "psk_identity" with a length greater than zero, it MUST
   process the contents of the "psk_identity" field as access token that
   is stored with the authorization information endpoint, before
   continuing the DTLS handshake.  If the contents of the "psk_identity"
   do not yield a valid access token for the requesting client, the
   resource server aborts the DTLS handshake with an "illegal_parameter"
   alert.

The way this was reworded seems to imply that any "psk_identity" with
positive length is a full access token (as would have been uploaded to
the authz-info endpoint), which prevents the case previously described
where the identity is just a COSE_Key with the 'kid' from "rs_cnf".  So
I think we still need some kind of description of two potential
interpretations of the "psk_identity".

In section 3.4, we updated the text about "a common understanding"
between RS and AS about how access tokens are ordered, and reworded the
text about checking authorization on every request.  I think we could
say a little bit more about how there is not a strict guarantee of
processing order for requests and authorization updates, so requests
that occur around the time of an authorization update might be processed
using either the old or new authorization rules.  Even just referencing
Section 7.2 would be enough.

(more inline)

> > On Tue, Apr 14, 2020 at 06:20:38PM +0200, Olaf Bergmann wrote:
> >> Ben,
> >> 
> >> Thanks again for the thorough review of the ACE DTLS profile and my
> >> sincere apologies for the long time it took to process. Please find our
> >> comments inline. As this comprises a lot of changes, the proposed text
> >> already has been included in the Editor's copy [1].  Our proposals for
> >> new text are in the section-by-section comments.
> >> 
> >> [1] https://ace-wg.github.io/ace-dtls-profile/
> >> 
> >> Benjamin Kaduk  writes:
> >> 
> >> > Hi all,
> >> >
> >> > Some high-level remarks before delving into the section-by-section
> >> > comments:
> >> >
> >> > This document is pretty clearly DTLS 1.2-specific -- it talks about
> >> > particular protocol messages, message fields, and cipher suites that
> >> > simply do not apply to DTLS 1.3.  In order to use this profile with DTLS
> >> > 1.3, we'd need to specify the analogous behavior/requirements to these
> >> > (including standalone signature schemes and key-exchange groups, which
> >> > are now both separately negotiated from the cipher suite).
> >> > Given that DTLS 1.3 is past WGLC and only a few documents behind this
> >> > one in my review queue, it 

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Olaf Bergmann]

Hi Ben,

Benjamin Kaduk  writes:

> Please go ahead and upload a new version to the datatracker when you get a
> chance; I do have some further comments below.

Thanks again for the detailed response. I have just submitted version
-10 that includes changes to your previous comments as well as the
suggestions below:

> On Tue, Apr 14, 2020 at 06:20:38PM +0200, Olaf Bergmann wrote:
>> Ben,
>> 
>> Thanks again for the thorough review of the ACE DTLS profile and my
>> sincere apologies for the long time it took to process. Please find our
>> comments inline. As this comprises a lot of changes, the proposed text
>> already has been included in the Editor's copy [1].  Our proposals for
>> new text are in the section-by-section comments.
>> 
>> [1] https://ace-wg.github.io/ace-dtls-profile/
>> 
>> Benjamin Kaduk  writes:
>> 
>> > Hi all,
>> >
>> > Some high-level remarks before delving into the section-by-section
>> > comments:
>> >
>> > This document is pretty clearly DTLS 1.2-specific -- it talks about
>> > particular protocol messages, message fields, and cipher suites that
>> > simply do not apply to DTLS 1.3.  In order to use this profile with DTLS
>> > 1.3, we'd need to specify the analogous behavior/requirements to these
>> > (including standalone signature schemes and key-exchange groups, which
>> > are now both separately negotiated from the cipher suite).
>> > Given that DTLS 1.3 is past WGLC and only a few documents behind this
>> > one in my review queue, it seems fairly prudent to spend some time and
>> > cover how DTLS 1.3 would work here, since otherwise this document will
>> > become stale shortly after (or even before!) its publication as an RFC.
>> >
>> > There's probably some additional discussion to include about the usage of
>> > key identifiers in this document versus the potential uses described in
>> > the core framework.  Specifically, the framework reminds us that "no
>> > assumptions should be made that it is unique in the domains of either
>> > the client or the RS" yet this document is using the kid as input to a
>> > KDF that produces keys that must be unique across all clients, and
>> > allowing live/instant authorization updates based on matching "kid".
>> > How shall we resolve this apparent conflict?
>> >
>> > We also are potentially in violation of the framework's requirements
>> > with respect to the independent selection of profiles for client/AS and
>> > client/RS interactions -- at present, when DTLS+RPK is used for
>> > client/RS, we require that DTLS+RPK is also used for client/AS, in order
>> > to prove possession of the key.  We could perhaps weasel our way out by
>> > saying that the framework's requirement applies at the profile
>> > granularity, and with symmetric PSK we can be fully independent, but we
>> > still need to say something about this property and the interaction with
>> > the framework's requirements.
>> >
>> > This profile is mostly applicable to the client/RS communications and
>> > feels like it only provides some of the picture for use with client/AS
>> > interactions.  (It doesn't really say much of anything about RS/AS
>> > interactions.) The introductory discussion does not do a great job of
>> > painting that picture, and I'd like to see it more clearly introduced
>> > that the bulk of our coverage is for the client/RS interaction.  We also
>> > lean heavily on the existing out-of-band configuration and key material
>> > shared between client and AS to secure the client/AS communications; we
>> > could probably tighten up the discussion about exactly what parameters
>> > of client/AS communication are specified by this profile.
>> 
>> The introduction has been revised according to your suggested text, see
>> below. We also have included some text on the out-of-band configuration
>> in a new subsection in the security considerations. The important thing
>> here really are the client/RS and client/AS interactions. Regarding
>> client/AS, much of this is out of scope as there are certain
>> OAuth-related assumptions on how these entities get in touch with each
>> other; neither the framework nor the profile can do much about it
>> without creating a new enrollment protocol. Regarding the RS/AS
>> interaction, there is normative language that describes what each of
>> these entities needs to do in each protocol step covered by the
>> document. The necessary out-of-band configuration again is described in
>> the new subsection in the security considerations as well as some
>> clarifications in the text, see below.
>> 
>> > We do not say anything about DTLS session resumption (or renegotiation,
>> > though not talking about that one is perfectly fine); that's a fairly
>> > core DTLS concept that we should give some guidance on.
>> 
>> Not sure if we really need to but if you think this is necessary, we can
>> comment on this, of course.
>
> I think we need to give some guidance about what the semantics are if/when
> it happens.  My inclination would be 

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Olaf Bergmann]

Hi Benjamin,

Benjamin Kaduk  writes:

> Please go ahead and upload a new version to the datatracker when you get a
> chance; I do have some further comments below.

Thank you very much for the quick reply. I will submit -10 based on
your comments shortly.

Grüße
Olaf

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

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Benjamin Kaduk]

Hi Olaf,

Please go ahead and upload a new version to the datatracker when you get a
chance; I do have some further comments below.

On Tue, Apr 14, 2020 at 06:20:38PM +0200, Olaf Bergmann wrote:
> Ben,
> 
> Thanks again for the thorough review of the ACE DTLS profile and my
> sincere apologies for the long time it took to process. Please find our
> comments inline. As this comprises a lot of changes, the proposed text
> already has been included in the Editor's copy [1].  Our proposals for
> new text are in the section-by-section comments.
> 
> [1] https://ace-wg.github.io/ace-dtls-profile/
> 
> Benjamin Kaduk  writes:
> 
> > Hi all,
> >
> > Some high-level remarks before delving into the section-by-section
> > comments:
> >
> > This document is pretty clearly DTLS 1.2-specific -- it talks about
> > particular protocol messages, message fields, and cipher suites that
> > simply do not apply to DTLS 1.3.  In order to use this profile with DTLS
> > 1.3, we'd need to specify the analogous behavior/requirements to these
> > (including standalone signature schemes and key-exchange groups, which
> > are now both separately negotiated from the cipher suite).
> > Given that DTLS 1.3 is past WGLC and only a few documents behind this
> > one in my review queue, it seems fairly prudent to spend some time and
> > cover how DTLS 1.3 would work here, since otherwise this document will
> > become stale shortly after (or even before!) its publication as an RFC.
> >
> > There's probably some additional discussion to include about the usage of
> > key identifiers in this document versus the potential uses described in
> > the core framework.  Specifically, the framework reminds us that "no
> > assumptions should be made that it is unique in the domains of either
> > the client or the RS" yet this document is using the kid as input to a
> > KDF that produces keys that must be unique across all clients, and
> > allowing live/instant authorization updates based on matching "kid".
> > How shall we resolve this apparent conflict?
> >
> > We also are potentially in violation of the framework's requirements
> > with respect to the independent selection of profiles for client/AS and
> > client/RS interactions -- at present, when DTLS+RPK is used for
> > client/RS, we require that DTLS+RPK is also used for client/AS, in order
> > to prove possession of the key.  We could perhaps weasel our way out by
> > saying that the framework's requirement applies at the profile
> > granularity, and with symmetric PSK we can be fully independent, but we
> > still need to say something about this property and the interaction with
> > the framework's requirements.
> >
> > This profile is mostly applicable to the client/RS communications and
> > feels like it only provides some of the picture for use with client/AS
> > interactions.  (It doesn't really say much of anything about RS/AS
> > interactions.) The introductory discussion does not do a great job of
> > painting that picture, and I'd like to see it more clearly introduced
> > that the bulk of our coverage is for the client/RS interaction.  We also
> > lean heavily on the existing out-of-band configuration and key material
> > shared between client and AS to secure the client/AS communications; we
> > could probably tighten up the discussion about exactly what parameters
> > of client/AS communication are specified by this profile.
> 
> The introduction has been revised according to your suggested text, see
> below. We also have included some text on the out-of-band configuration
> in a new subsection in the security considerations. The important thing
> here really are the client/RS and client/AS interactions. Regarding
> client/AS, much of this is out of scope as there are certain
> OAuth-related assumptions on how these entities get in touch with each
> other; neither the framework nor the profile can do much about it
> without creating a new enrollment protocol. Regarding the RS/AS
> interaction, there is normative language that describes what each of
> these entities needs to do in each protocol step covered by the
> document. The necessary out-of-band configuration again is described in
> the new subsection in the security considerations as well as some
> clarifications in the text, see below.
> 
> > We do not say anything about DTLS session resumption (or renegotiation,
> > though not talking about that one is perfectly fine); that's a fairly
> > core DTLS concept that we should give some guidance on.
> 
> Not sure if we really need to but if you think this is necessary, we can
> comment on this, of course.

I think we need to give some guidance about what the semantics are if/when
it happens.  My inclination would be to say that DTLS resumption can be
used to amortize the cost of a handshake, but DTLS 1.2 resumption does not
provide forward secrecy and also does not provide an opportunity for the
client to prove possession of the PoP key, so servers will want to
periodically force 

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Olaf Bergmann]

Ben,

Thanks again for the thorough review of the ACE DTLS profile and my
sincere apologies for the long time it took to process. Please find our
comments inline. As this comprises a lot of changes, the proposed text
already has been included in the Editor's copy [1].  Our proposals for
new text are in the section-by-section comments.

[1] https://ace-wg.github.io/ace-dtls-profile/

Benjamin Kaduk  writes:

> Hi all,
>
> Some high-level remarks before delving into the section-by-section
> comments:
>
> This document is pretty clearly DTLS 1.2-specific -- it talks about
> particular protocol messages, message fields, and cipher suites that
> simply do not apply to DTLS 1.3.  In order to use this profile with DTLS
> 1.3, we'd need to specify the analogous behavior/requirements to these
> (including standalone signature schemes and key-exchange groups, which
> are now both separately negotiated from the cipher suite).
> Given that DTLS 1.3 is past WGLC and only a few documents behind this
> one in my review queue, it seems fairly prudent to spend some time and
> cover how DTLS 1.3 would work here, since otherwise this document will
> become stale shortly after (or even before!) its publication as an RFC.
>
> There's probably some additional discussion to include about the usage of
> key identifiers in this document versus the potential uses described in
> the core framework.  Specifically, the framework reminds us that "no
> assumptions should be made that it is unique in the domains of either
> the client or the RS" yet this document is using the kid as input to a
> KDF that produces keys that must be unique across all clients, and
> allowing live/instant authorization updates based on matching "kid".
> How shall we resolve this apparent conflict?
>
> We also are potentially in violation of the framework's requirements
> with respect to the independent selection of profiles for client/AS and
> client/RS interactions -- at present, when DTLS+RPK is used for
> client/RS, we require that DTLS+RPK is also used for client/AS, in order
> to prove possession of the key.  We could perhaps weasel our way out by
> saying that the framework's requirement applies at the profile
> granularity, and with symmetric PSK we can be fully independent, but we
> still need to say something about this property and the interaction with
> the framework's requirements.
>
> This profile is mostly applicable to the client/RS communications and
> feels like it only provides some of the picture for use with client/AS
> interactions.  (It doesn't really say much of anything about RS/AS
> interactions.) The introductory discussion does not do a great job of
> painting that picture, and I'd like to see it more clearly introduced
> that the bulk of our coverage is for the client/RS interaction.  We also
> lean heavily on the existing out-of-band configuration and key material
> shared between client and AS to secure the client/AS communications; we
> could probably tighten up the discussion about exactly what parameters
> of client/AS communication are specified by this profile.

The introduction has been revised according to your suggested text, see
below. We also have included some text on the out-of-band configuration
in a new subsection in the security considerations. The important thing
here really are the client/RS and client/AS interactions. Regarding
client/AS, much of this is out of scope as there are certain
OAuth-related assumptions on how these entities get in touch with each
other; neither the framework nor the profile can do much about it
without creating a new enrollment protocol. Regarding the RS/AS
interaction, there is normative language that describes what each of
these entities needs to do in each protocol step covered by the
document. The necessary out-of-band configuration again is described in
the new subsection in the security considerations as well as some
clarifications in the text, see below.

> We do not say anything about DTLS session resumption (or renegotiation,
> though not talking about that one is perfectly fine); that's a fairly
> core DTLS concept that we should give some guidance on.

Not sure if we really need to but if you think this is necessary, we can
comment on this, of course.

> Looking through Appendix C ("Requirements on Profiles") of the
> framework, do we want to say anything about:
>
> - using the client credentials grant with this profile, as that's IIRC
>   the only example we show

Do you think we need to say anything here? The actual grant used to
make the client known to the AS is out of scope for the profile as
long as the requirements given here are met.

> - require that DTLS be used in a mode that provides replay protection

Added as a requirement in Section 2.

> - when the client uses the authz-info endpoint instead of the
>   "psk_identity" field to convey the token to the RS, how does the RS
>   know which client is connecting (and thus what PSK to use), and what
>   does the 

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Jim Schaad]

-Original Message-
From: Benjamin Kaduk  
Sent: Thursday, January 9, 2020 1:22 PM
To: Jim Schaad 
Cc: 'Olaf Bergmann' ;
draft-ietf-ace-dtls-authorize@ietf.org; ace@ietf.org
Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

On Thu, Jan 09, 2020 at 12:52:56PM -0800, Jim Schaad wrote:
> 
> 
> -Original Message-
> From: Benjamin Kaduk 
> Sent: Thursday, January 9, 2020 12:17 PM
> To: Olaf Bergmann 
> Cc: Jim Schaad ; ace@ietf.org; 
> draft-ietf-ace-dtls-authorize....@ietf.org
> Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
> 
> On Thu, Jan 09, 2020 at 12:32:40PM +0100, Olaf Bergmann wrote:
> > Hi Jim,
> > 
> > Jim Schaad  writes:
> > 
> > > -Original Message-
> > > From: Ace  On Behalf Of Olaf Bergmann
> > > Sent: Monday, January 6, 2020 2:03 AM
> > > To: Jim Schaad 
> > > Cc: ace@ietf.org; 'Benjamin Kaduk' ; 
> > > draft-ietf-ace-dtls-authorize@ietf.org
> > > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
> > >
> > > Jim,
> > >
> > > Jim Schaad  writes:
> > >
> > > [Ben's review]
> > >> We also are potentially in violation of the framework's 
> > >> requirements
> with respect to the independent selection of profiles for client/AS 
> and client/RS interactions -- at present, when DTLS+RPK is used for 
> client/RS, we require that DTLS+RPK is also used for client/AS, in 
> order to prove possession of the key.  We could perhaps weasel our way 
> out by saying that the framework's requirement applies at the profile 
> granularity, and with symmetric PSK we can be fully independent, but 
> we still need to say something about this property and the interaction 
> with the framework's requirements.
> > >>
> > >> [JLS] I am missing where it is saying this.   Can you give a pointer?
> I don't believe that the POP of the RPK is required at the time that 
> the token is obtained.
> > >
> > > The problem is that AS must bind the Access Token to the RPK that 
> > > the
> Client has presented, and the Client must use the very same RPK to 
> establish the DTLS channel with RS. Otherwise, RS cannot be sure that 
> AS has issued the Token to the same entity that is currently communicating
with RS.
> > >
> > > [JLS]  What if I do the following sequence of events:
> > > 1.  The AS is configured with RPK1 for the client and the client 
> > > is
> configured with RPK2 for the AS.
> > > 2.  The client and the AS run some type of POP algorithm, not 
> > > currently
> specified, to configure RPK3 into the AS for a second RPK to work with 
> some set of audiences (AUD1).
> > > 3.  The client then uses RPK1 to authenticate to the AS and asks 
> > > for a
> new token for AUD1 and provides (explicitly or implicitly RPK3).  The 
> AS knows that it is tied to the client due to what happened in step 2.  
> The AS then creates a new token for AUD1 which contains RPK3 for the 
> client (and
> RPK4 for the RS) and returns it.
> > >
> > > The AS does a current POP for RPK1 when the token is being asked for.
> > > The AS did a POP for RPK3 when it was placed into the system.
> > > The AS has not done a POP for RPK4 - that was simply configured 
> > > without
> that step ever being done.  The ACE framework has no ability for the 
> AS to do the POP on RPK4 and ensure that it current.  The client would 
> do a POP when the TLS session is created but has to rely on the AS 
> that it is for the correct RS.
> > >
> > > Note that the client can never generate a brand new RPK9 and send 
> > > it to
> the AS in the token request because the AS will never have seen this 
> before and would need to run the POP algorithm of step 2 in order to 
> assure that it is bound to the correct client and not pulled out of 
> thin air.  RPK9 could not be used to authenticate the token request 
> because the AS has no idea what client it is tied to.
> > 
> > okay, I see you have a valid point here. I will try to come up with 
> > some text that says that the AS must ensure that (in your scenario)
> > RPK1 and
> > RPK3 are bound to the same entity.
> 
> Jim's proposal seems broadly reasonable (though I think in general 
> there needs to be some AS contributory nature in order to get proof of 
> current possession of RPK3 at the time of (2).  I think I would phrase 
> it as "in possession of the same entity" rather than "bound to the 
> same entity", though.
> 
> [JLS] If I was to write this out as a real protocol, it wo

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Benjamin Kaduk]

On Thu, Jan 09, 2020 at 12:52:56PM -0800, Jim Schaad wrote:
> 
> 
> -Original Message-
> From: Benjamin Kaduk  
> Sent: Thursday, January 9, 2020 12:17 PM
> To: Olaf Bergmann 
> Cc: Jim Schaad ; ace@ietf.org;
> draft-ietf-ace-dtls-authorize....@ietf.org
> Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
> 
> On Thu, Jan 09, 2020 at 12:32:40PM +0100, Olaf Bergmann wrote:
> > Hi Jim,
> > 
> > Jim Schaad  writes:
> > 
> > > -Original Message-
> > > From: Ace  On Behalf Of Olaf Bergmann
> > > Sent: Monday, January 6, 2020 2:03 AM
> > > To: Jim Schaad 
> > > Cc: ace@ietf.org; 'Benjamin Kaduk' ; 
> > > draft-ietf-ace-dtls-authorize@ietf.org
> > > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
> > >
> > > Jim,
> > >
> > > Jim Schaad  writes:
> > >
> > > [Ben's review]
> > >> We also are potentially in violation of the framework's requirements
> with respect to the independent selection of profiles for client/AS and
> client/RS interactions -- at present, when DTLS+RPK is used for client/RS,
> we require that DTLS+RPK is also used for client/AS, in order to prove
> possession of the key.  We could perhaps weasel our way out by saying that
> the framework's requirement applies at the profile granularity, and with
> symmetric PSK we can be fully independent, but we still need to say
> something about this property and the interaction with the framework's
> requirements.
> > >>
> > >> [JLS] I am missing where it is saying this.   Can you give a pointer?
> I don't believe that the POP of the RPK is required at the time that the
> token is obtained.
> > >
> > > The problem is that AS must bind the Access Token to the RPK that the
> Client has presented, and the Client must use the very same RPK to establish
> the DTLS channel with RS. Otherwise, RS cannot be sure that AS has issued
> the Token to the same entity that is currently communicating with RS.
> > >
> > > [JLS]  What if I do the following sequence of events:
> > > 1.  The AS is configured with RPK1 for the client and the client is
> configured with RPK2 for the AS.
> > > 2.  The client and the AS run some type of POP algorithm, not currently
> specified, to configure RPK3 into the AS for a second RPK to work with some
> set of audiences (AUD1).
> > > 3.  The client then uses RPK1 to authenticate to the AS and asks for a
> new token for AUD1 and provides (explicitly or implicitly RPK3).  The AS
> knows that it is tied to the client due to what happened in step 2.  The AS
> then creates a new token for AUD1 which contains RPK3 for the client (and
> RPK4 for the RS) and returns it.
> > >
> > > The AS does a current POP for RPK1 when the token is being asked for.
> > > The AS did a POP for RPK3 when it was placed into the system.
> > > The AS has not done a POP for RPK4 - that was simply configured without
> that step ever being done.  The ACE framework has no ability for the AS to
> do the POP on RPK4 and ensure that it current.  The client would do a POP
> when the TLS session is created but has to rely on the AS that it is for the
> correct RS.
> > >
> > > Note that the client can never generate a brand new RPK9 and send it to
> the AS in the token request because the AS will never have seen this before
> and would need to run the POP algorithm of step 2 in order to assure that it
> is bound to the correct client and not pulled out of thin air.  RPK9 could
> not be used to authenticate the token request because the AS has no idea
> what client it is tied to.
> > 
> > okay, I see you have a valid point here. I will try to come up with 
> > some text that says that the AS must ensure that (in your scenario) 
> > RPK1 and
> > RPK3 are bound to the same entity.
> 
> Jim's proposal seems broadly reasonable (though I think in general there
> needs to be some AS contributory nature in order to get proof of current
> possession of RPK3 at the time of (2).  I think I would phrase it as "in
> possession of the same entity" rather than "bound to the same entity",
> though.
> 
> [JLS] If I was to write this out as a real protocol, it would end up
> something along the lines of  Sign(RPK1, Sign(RPK3,  RPK1 || RPK3 || AS
> Nonce || Client Nonce ))  so that we know that both keys are in the
> possession of a single entity (or a cabal collaborating) and it is current
> to the run of the POP protocol.

With a fixed protocol/context string to indicate the intent of what's being
signed, of course :)

I am too distracted to do a proper analysis right now but seem to recall
that usually an indication of "both parties/keys agree to " involves
three signatures, so that each party certifies the signature of the other
over the operation (in addition to the operation itself).

-Ben

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

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Jim Schaad]

-Original Message-
From: Benjamin Kaduk  
Sent: Thursday, January 9, 2020 12:27 PM
To: Jim Schaad 
Cc: draft-ietf-ace-dtls-authorize@ietf.org; ace@ietf.org
Subject: Re: AD review of draft-ietf-ace-dtls-authorize-09

On Fri, Jan 03, 2020 at 08:36:54PM -0800, Jim Schaad wrote:
> 
> 
> -Original Message-
> From: Benjamin Kaduk 
> Sent: Thursday, January 2, 2020 3:40 PM
> To: draft-ietf-ace-dtls-authorize@ietf.org
> Cc: ace@ietf.org
> Subject: AD review of draft-ietf-ace-dtls-authorize-09
> 
> Hi all,
> 
> Some high-level remarks before delving into the section-by-section
> comments:
> 
> This document is pretty clearly DTLS 1.2-specific -- it talks about 
> particular protocol messages, message fields, and cipher suites that simply 
> do not apply to DTLS 1.3.  In order to use this profile with DTLS 1.3, we'd 
> need to specify the analogous behavior/requirements to these (including 
> standalone signature schemes and key-exchange groups, which are now both 
> separately negotiated from the cipher suite).
> Given that DTLS 1.3 is past WGLC and only a few documents behind this one in 
> my review queue, it seems fairly prudent to spend some time and cover how 
> DTLS 1.3 would work here, since otherwise this document will become stale 
> shortly after (or even before!) its publication as an RFC.
> 
> [JLS] Yes we need to look at this, but we also know who's fault this is   
> Part of me wants to punt this off to the CoRE working group because the way 
> they are currently using DTLS 1.2 is quite restrictive and they really need 
> to do a DTLS 1.3 document.

I hadn't realized that the CoRE usage of DTLS was so restrictive; in that case 
we may have to wait for them, yes.

[JLS] Yeah, I really ought to start writing this document.   The first time I 
read the DTLS section and realized that when a re-key operation occurred that 
all of the current state on the server is to be cleared as if a new session had 
just been negotiated I just about went crazy.  They were worried about the 
security implications on the key roll over which made no sense to me, but then 
I am much more versed in TLS than they were.

> 
> There's probably some additional discussion to include about the usage of key 
> identifiers in this document versus the potential uses described in the core 
> framework.  Specifically, the framework reminds us that "no assumptions 
> should be made that it is unique in the domains of either the client or the 
> RS" yet this document is using the kid as input to a KDF that produces keys 
> that must be unique across all clients, and allowing live/instant 
> authorization updates based on matching "kid".
> How shall we resolve this apparent conflict?
> 
> [JLS] I am having a problem seeing what the conflict is here.  The "kid" is a 
> publicly known value so that fact that it is included in the KDF is not what 
> is going to produce unique keys for all clients no matter what.  It is the 
> secret that is going to make things unique.  There is a potential problem 
> with the fact that the RS may get two different entities that register a 
> token which has the same kid value, but that is a known issue for (D)TLS.  
> This is one of the reasons that the token itself can be used as the "kid" for 
> DTLS.

I think I'm just thinking about what you note as the "potential problem"
where an RS receives two tokens with the same kid value but that are for 
different clients.  For asymmetric PoP we require POST to authz-info, and since 
"POST a new token with the same kid" is the way we update permissions without 
changing DTLS keys, the RS needs to know to scope its lookup/storage based on 
(client,kid) (or more?) and not just 'kid'.  Maybe this is obvious, but I 
wasn't sure.

[JLS] No, "POST a new token with the same KEY" is the way that we update 
permissions without changing the DTLS keys.  For RPK this is easy.  For 
symmetric keys this is a harder sell and you really need to add some additional 
checks to make it something along the lines of same .  There may not 
be a key id if one is using the token as the user identifier when doing the 
DTLS protocol so matching on kid would seem to be difficult there.  What I was 
referring to as the potential problem is that if client 1 posts a token with a 
symmetric key and KID1 and uses KID1 as the user name things are fine.  Now if 
client 2 posts a token with a different symmetric key and KID1.  Client 2 can 
use KID1 as the user name to connect to the server but if client 1 attempts to 
connect with KID1 as the user name it will fail doing the connection.  This is 
a (D)TLS issue as you cannot do  a "retry" easily in TLS 1.2.  (Ding, ding, 
ding, ding.   Jim just realizes that TLS 1.3 might have solved this 

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Jim Schaad]

-Original Message-
From: Benjamin Kaduk  
Sent: Thursday, January 9, 2020 12:17 PM
To: Olaf Bergmann 
Cc: Jim Schaad ; ace@ietf.org;
draft-ietf-ace-dtls-authorize@ietf.org
Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

On Thu, Jan 09, 2020 at 12:32:40PM +0100, Olaf Bergmann wrote:
> Hi Jim,
> 
> Jim Schaad  writes:
> 
> > -Original Message-
> > From: Ace  On Behalf Of Olaf Bergmann
> > Sent: Monday, January 6, 2020 2:03 AM
> > To: Jim Schaad 
> > Cc: ace@ietf.org; 'Benjamin Kaduk' ; 
> > draft-ietf-ace-dtls-authorize....@ietf.org
> > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
> >
> > Jim,
> >
> > Jim Schaad  writes:
> >
> > [Ben's review]
> >> We also are potentially in violation of the framework's requirements
with respect to the independent selection of profiles for client/AS and
client/RS interactions -- at present, when DTLS+RPK is used for client/RS,
we require that DTLS+RPK is also used for client/AS, in order to prove
possession of the key.  We could perhaps weasel our way out by saying that
the framework's requirement applies at the profile granularity, and with
symmetric PSK we can be fully independent, but we still need to say
something about this property and the interaction with the framework's
requirements.
> >>
> >> [JLS] I am missing where it is saying this.   Can you give a pointer?
I don't believe that the POP of the RPK is required at the time that the
token is obtained.
> >
> > The problem is that AS must bind the Access Token to the RPK that the
Client has presented, and the Client must use the very same RPK to establish
the DTLS channel with RS. Otherwise, RS cannot be sure that AS has issued
the Token to the same entity that is currently communicating with RS.
> >
> > [JLS]  What if I do the following sequence of events:
> > 1.  The AS is configured with RPK1 for the client and the client is
configured with RPK2 for the AS.
> > 2.  The client and the AS run some type of POP algorithm, not currently
specified, to configure RPK3 into the AS for a second RPK to work with some
set of audiences (AUD1).
> > 3.  The client then uses RPK1 to authenticate to the AS and asks for a
new token for AUD1 and provides (explicitly or implicitly RPK3).  The AS
knows that it is tied to the client due to what happened in step 2.  The AS
then creates a new token for AUD1 which contains RPK3 for the client (and
RPK4 for the RS) and returns it.
> >
> > The AS does a current POP for RPK1 when the token is being asked for.
> > The AS did a POP for RPK3 when it was placed into the system.
> > The AS has not done a POP for RPK4 - that was simply configured without
that step ever being done.  The ACE framework has no ability for the AS to
do the POP on RPK4 and ensure that it current.  The client would do a POP
when the TLS session is created but has to rely on the AS that it is for the
correct RS.
> >
> > Note that the client can never generate a brand new RPK9 and send it to
the AS in the token request because the AS will never have seen this before
and would need to run the POP algorithm of step 2 in order to assure that it
is bound to the correct client and not pulled out of thin air.  RPK9 could
not be used to authenticate the token request because the AS has no idea
what client it is tied to.
> 
> okay, I see you have a valid point here. I will try to come up with 
> some text that says that the AS must ensure that (in your scenario) 
> RPK1 and
> RPK3 are bound to the same entity.

Jim's proposal seems broadly reasonable (though I think in general there
needs to be some AS contributory nature in order to get proof of current
possession of RPK3 at the time of (2).  I think I would phrase it as "in
possession of the same entity" rather than "bound to the same entity",
though.

[JLS] If I was to write this out as a real protocol, it would end up
something along the lines of  Sign(RPK1, Sign(RPK3,  RPK1 || RPK3 || AS
Nonce || Client Nonce ))  so that we know that both keys are in the
possession of a single entity (or a cabal collaborating) and it is current
to the run of the POP protocol.

Jim


-Ben

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

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Benjamin Kaduk]

On Fri, Jan 03, 2020 at 08:36:54PM -0800, Jim Schaad wrote:
> 
> 
> -Original Message-
> From: Benjamin Kaduk  
> Sent: Thursday, January 2, 2020 3:40 PM
> To: draft-ietf-ace-dtls-authorize@ietf.org
> Cc: ace@ietf.org
> Subject: AD review of draft-ietf-ace-dtls-authorize-09
> 
> Hi all,
> 
> Some high-level remarks before delving into the section-by-section
> comments:
> 
> This document is pretty clearly DTLS 1.2-specific -- it talks about 
> particular protocol messages, message fields, and cipher suites that simply 
> do not apply to DTLS 1.3.  In order to use this profile with DTLS 1.3, we'd 
> need to specify the analogous behavior/requirements to these (including 
> standalone signature schemes and key-exchange groups, which are now both 
> separately negotiated from the cipher suite).
> Given that DTLS 1.3 is past WGLC and only a few documents behind this one in 
> my review queue, it seems fairly prudent to spend some time and cover how 
> DTLS 1.3 would work here, since otherwise this document will become stale 
> shortly after (or even before!) its publication as an RFC.
> 
> [JLS] Yes we need to look at this, but we also know who's fault this is   
> Part of me wants to punt this off to the CoRE working group because the way 
> they are currently using DTLS 1.2 is quite restrictive and they really need 
> to do a DTLS 1.3 document.

I hadn't realized that the CoRE usage of DTLS was so restrictive; in that
case we may have to wait for them, yes.

> 
> There's probably some additional discussion to include about the usage of key 
> identifiers in this document versus the potential uses described in the core 
> framework.  Specifically, the framework reminds us that "no assumptions 
> should be made that it is unique in the domains of either the client or the 
> RS" yet this document is using the kid as input to a KDF that produces keys 
> that must be unique across all clients, and allowing live/instant 
> authorization updates based on matching "kid".
> How shall we resolve this apparent conflict?
> 
> [JLS] I am having a problem seeing what the conflict is here.  The "kid" is a 
> publicly known value so that fact that it is included in the KDF is not what 
> is going to produce unique keys for all clients no matter what.  It is the 
> secret that is going to make things unique.  There is a potential problem 
> with the fact that the RS may get two different entities that register a 
> token which has the same kid value, but that is a known issue for (D)TLS.  
> This is one of the reasons that the token itself can be used as the "kid" for 
> DTLS.

I think I'm just thinking about what you note as the "potential problem"
where an RS receives two tokens with the same kid value but that are for
different clients.  For asymmetric PoP we require POST to authz-info, and
since "POST a new token with the same kid" is the way we update permissions
without changing DTLS keys, the RS needs to know to scope its
lookup/storage based on (client,kid) (or more?) and not just 'kid'.  Maybe
this is obvious, but I wasn't sure.

> We also are potentially in violation of the framework's requirements with 
> respect to the independent selection of profiles for client/AS and client/RS 
> interactions -- at present, when DTLS+RPK is used for client/RS, we require 
> that DTLS+RPK is also used for client/AS, in order to prove possession of the 
> key.  We could perhaps weasel our way out by saying that the framework's 
> requirement applies at the profile granularity, and with symmetric PSK we can 
> be fully independent, but we still need to say something about this property 
> and the interaction with the framework's requirements.
> 
> [JLS] I am missing where it is saying this.   Can you give a pointer?  I 
> don't believe that the POP of the RPK is required at the time that the token 
> is obtained.

[Olaf got this; thanks Olaf!]

> This profile is mostly applicable to the client/RS communications and feels 
> like it only provides some of the picture for use with client/AS 
> interactions.  (It doesn't really say much of anything about RS/AS
> interactions.) The introductory discussion does not do a great job of 
> painting that picture, and I'd like to see it more clearly introduced that 
> the bulk of our coverage is for the client/RS interaction.  We also lean 
> heavily on the existing out-of-band configuration and key material shared 
> between client and AS to secure the client/AS communications; we could 
> probably tighten up the discussion about exactly what parameters of client/AS 
> communication are specified by this profile.
> 
> [JLS] I think this makes sense.
> 
> We do not say anything about DTLS session resumption (or renegotiation, 
> though not talking about that one is perfectly fine); that's a fairly core 
> DTLS concept that we should give some guidance on.
> 
> [JLS] I don't see any reason to talk about renegotiation, either it is done 
> or it isn't and a new connection would 

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Benjamin Kaduk]

On Thu, Jan 09, 2020 at 12:32:40PM +0100, Olaf Bergmann wrote:
> Hi Jim,
> 
> Jim Schaad  writes:
> 
> > -Original Message-
> > From: Ace  On Behalf Of Olaf Bergmann
> > Sent: Monday, January 6, 2020 2:03 AM
> > To: Jim Schaad 
> > Cc: ace@ietf.org; 'Benjamin Kaduk' ;
> > draft-ietf-ace-dtls-authorize....@ietf.org
> > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
> >
> > Jim,
> >
> > Jim Schaad  writes:
> >
> > [Ben's review]
> >> We also are potentially in violation of the framework's requirements with 
> >> respect to the independent selection of profiles for client/AS and 
> >> client/RS interactions -- at present, when DTLS+RPK is used for client/RS, 
> >> we require that DTLS+RPK is also used for client/AS, in order to prove 
> >> possession of the key.  We could perhaps weasel our way out by saying that 
> >> the framework's requirement applies at the profile granularity, and with 
> >> symmetric PSK we can be fully independent, but we still need to say 
> >> something about this property and the interaction with the framework's 
> >> requirements.
> >>
> >> [JLS] I am missing where it is saying this.   Can you give a pointer?  I 
> >> don't believe that the POP of the RPK is required at the time that the 
> >> token is obtained.
> >
> > The problem is that AS must bind the Access Token to the RPK that the 
> > Client has presented, and the Client must use the very same RPK to 
> > establish the DTLS channel with RS. Otherwise, RS cannot be sure that AS 
> > has issued the Token to the same entity that is currently communicating 
> > with RS.
> >
> > [JLS]  What if I do the following sequence of events:
> > 1.  The AS is configured with RPK1 for the client and the client is 
> > configured with RPK2 for the AS.
> > 2.  The client and the AS run some type of POP algorithm, not currently 
> > specified, to configure RPK3 into the AS for a second RPK to work with some 
> > set of audiences (AUD1).
> > 3.  The client then uses RPK1 to authenticate to the AS and asks for a new 
> > token for AUD1 and provides (explicitly or implicitly RPK3).  The AS knows 
> > that it is tied to the client due to what happened in step 2.  The AS then 
> > creates a new token for AUD1 which contains RPK3 for the client (and RPK4 
> > for the RS) and returns it.
> >
> > The AS does a current POP for RPK1 when the token is being asked for.
> > The AS did a POP for RPK3 when it was placed into the system.
> > The AS has not done a POP for RPK4 - that was simply configured without 
> > that step ever being done.  The ACE framework has no ability for the AS to 
> > do the POP on RPK4 and ensure that it current.  The client would do a POP 
> > when the TLS session is created but has to rely on the AS that it is for 
> > the correct RS.
> >
> > Note that the client can never generate a brand new RPK9 and send it to the 
> > AS in the token request because the AS will never have seen this before and 
> > would need to run the POP algorithm of step 2 in order to assure that it is 
> > bound to the correct client and not pulled out of thin air.  RPK9 could not 
> > be used to authenticate the token request because the AS has no idea what 
> > client it is tied to.
> 
> okay, I see you have a valid point here. I will try to come up with some
> text that says that the AS must ensure that (in your scenario) RPK1 and
> RPK3 are bound to the same entity.

Jim's proposal seems broadly reasonable (though I think in general there
needs to be some AS contributory nature in order to get proof of current
possession of RPK3 at the time of (2).  I think I would phrase it as "in
possession of the same entity" rather than "bound to the same entity",
though.

-Ben

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

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Olaf Bergmann]

Hi Jim,

Jim Schaad  writes:

> -Original Message-
> From: Ace  On Behalf Of Olaf Bergmann
> Sent: Monday, January 6, 2020 2:03 AM
> To: Jim Schaad 
> Cc: ace@ietf.org; 'Benjamin Kaduk' ;
> draft-ietf-ace-dtls-authorize@ietf.org
> Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
>
> Jim,
>
> Jim Schaad  writes:
>
> [Ben's review]
>> We also are potentially in violation of the framework's requirements with 
>> respect to the independent selection of profiles for client/AS and client/RS 
>> interactions -- at present, when DTLS+RPK is used for client/RS, we require 
>> that DTLS+RPK is also used for client/AS, in order to prove possession of 
>> the key.  We could perhaps weasel our way out by saying that the framework's 
>> requirement applies at the profile granularity, and with symmetric PSK we 
>> can be fully independent, but we still need to say something about this 
>> property and the interaction with the framework's requirements.
>>
>> [JLS] I am missing where it is saying this.   Can you give a pointer?  I 
>> don't believe that the POP of the RPK is required at the time that the token 
>> is obtained.
>
> The problem is that AS must bind the Access Token to the RPK that the Client 
> has presented, and the Client must use the very same RPK to establish the 
> DTLS channel with RS. Otherwise, RS cannot be sure that AS has issued the 
> Token to the same entity that is currently communicating with RS.
>
> [JLS]  What if I do the following sequence of events:
> 1.  The AS is configured with RPK1 for the client and the client is 
> configured with RPK2 for the AS.
> 2.  The client and the AS run some type of POP algorithm, not currently 
> specified, to configure RPK3 into the AS for a second RPK to work with some 
> set of audiences (AUD1).
> 3.  The client then uses RPK1 to authenticate to the AS and asks for a new 
> token for AUD1 and provides (explicitly or implicitly RPK3).  The AS knows 
> that it is tied to the client due to what happened in step 2.  The AS then 
> creates a new token for AUD1 which contains RPK3 for the client (and RPK4 for 
> the RS) and returns it.
>
> The AS does a current POP for RPK1 when the token is being asked for.
> The AS did a POP for RPK3 when it was placed into the system.
> The AS has not done a POP for RPK4 - that was simply configured without that 
> step ever being done.  The ACE framework has no ability for the AS to do the 
> POP on RPK4 and ensure that it current.  The client would do a POP when the 
> TLS session is created but has to rely on the AS that it is for the correct 
> RS.
>
> Note that the client can never generate a brand new RPK9 and send it to the 
> AS in the token request because the AS will never have seen this before and 
> would need to run the POP algorithm of step 2 in order to assure that it is 
> bound to the correct client and not pulled out of thin air.  RPK9 could not 
> be used to authenticate the token request because the AS has no idea what 
> client it is tied to.

okay, I see you have a valid point here. I will try to come up with some
text that says that the AS must ensure that (in your scenario) RPK1 and
RPK3 are bound to the same entity.

Grüße
Olaf

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

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Jim Schaad]

-Original Message-
From: Ace  On Behalf Of Olaf Bergmann
Sent: Monday, January 6, 2020 2:03 AM
To: Jim Schaad 
Cc: ace@ietf.org; 'Benjamin Kaduk' ; 
draft-ietf-ace-dtls-authorize@ietf.org
Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

Jim,

Jim Schaad  writes:

[Ben's review]
> We also are potentially in violation of the framework's requirements with 
> respect to the independent selection of profiles for client/AS and client/RS 
> interactions -- at present, when DTLS+RPK is used for client/RS, we require 
> that DTLS+RPK is also used for client/AS, in order to prove possession of the 
> key.  We could perhaps weasel our way out by saying that the framework's 
> requirement applies at the profile granularity, and with symmetric PSK we can 
> be fully independent, but we still need to say something about this property 
> and the interaction with the framework's requirements.
>
> [JLS] I am missing where it is saying this.   Can you give a pointer?  I 
> don't believe that the POP of the RPK is required at the time that the token 
> is obtained.

The problem is that AS must bind the Access Token to the RPK that the Client 
has presented, and the Client must use the very same RPK to establish the DTLS 
channel with RS. Otherwise, RS cannot be sure that AS has issued the Token to 
the same entity that is currently communicating with RS.

[JLS]  What if I do the following sequence of events:
1.  The AS is configured with RPK1 for the client and the client is configured 
with RPK2 for the AS.
2.  The client and the AS run some type of POP algorithm, not currently 
specified, to configure RPK3 into the AS for a second RPK to work with some set 
of audiences (AUD1).
3.  The client then uses RPK1 to authenticate to the AS and asks for a new 
token for AUD1 and provides (explicitly or implicitly RPK3).  The AS knows that 
it is tied to the client due to what happened in step 2.  The AS then creates a 
new token for AUD1 which contains RPK3 for the client (and RPK4 for the RS) and 
returns it.

The AS does a current POP for RPK1 when the token is being asked for.
The AS did a POP for RPK3 when it was placed into the system.
The AS has not done a POP for RPK4 - that was simply configured without that 
step ever being done.  The ACE framework has no ability for the AS to do the 
POP on RPK4 and ensure that it current.  The client would do a POP when the TLS 
session is created but has to rely on the AS that it is for the correct RS.

Note that the client can never generate a brand new RPK9 and send it to the AS 
in the token request because the AS will never have seen this before and would 
need to run the POP algorithm of step 2 in order to assure that it is bound to 
the correct client and not pulled out of thin air.  RPK9 could not be used to 
authenticate the token request because the AS has no idea what client it is 
tied to.

Jim


Jim
 

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] AD review of draft-ietf-ace-dtls-authorize-09

[Olaf Bergmann]

Jim,

Jim Schaad  writes:

[Ben's review]
> We also are potentially in violation of the framework's requirements with 
> respect to the independent selection of profiles for client/AS and client/RS 
> interactions -- at present, when DTLS+RPK is used for client/RS, we require 
> that DTLS+RPK is also used for client/AS, in order to prove possession of the 
> key.  We could perhaps weasel our way out by saying that the framework's 
> requirement applies at the profile granularity, and with symmetric PSK we can 
> be fully independent, but we still need to say something about this property 
> and the interaction with the framework's requirements.
>
> [JLS] I am missing where it is saying this.   Can you give a pointer?  I 
> don't believe that the POP of the RPK is required at the time that the token 
> is obtained.

The problem is that AS must bind the Access Token to the RPK that the
Client has presented, and the Client must use the very same RPK to
establish the DTLS channel with RS. Otherwise, RS cannot be sure that AS
has issued the Token to the same entity that is currently communicating
with RS.

Grüße
Olaf

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

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Jim Schaad]

-Original Message-
From: Benjamin Kaduk  
Sent: Thursday, January 2, 2020 3:40 PM
To: draft-ietf-ace-dtls-authorize@ietf.org
Cc: ace@ietf.org
Subject: AD review of draft-ietf-ace-dtls-authorize-09

Hi all,

Some high-level remarks before delving into the section-by-section
comments:

This document is pretty clearly DTLS 1.2-specific -- it talks about particular 
protocol messages, message fields, and cipher suites that simply do not apply 
to DTLS 1.3.  In order to use this profile with DTLS 1.3, we'd need to specify 
the analogous behavior/requirements to these (including standalone signature 
schemes and key-exchange groups, which are now both separately negotiated from 
the cipher suite).
Given that DTLS 1.3 is past WGLC and only a few documents behind this one in my 
review queue, it seems fairly prudent to spend some time and cover how DTLS 1.3 
would work here, since otherwise this document will become stale shortly after 
(or even before!) its publication as an RFC.

[JLS] Yes we need to look at this, but we also know who's fault this is   Part 
of me wants to punt this off to the CoRE working group because the way they are 
currently using DTLS 1.2 is quite restrictive and they really need to do a DTLS 
1.3 document.

There's probably some additional discussion to include about the usage of key 
identifiers in this document versus the potential uses described in the core 
framework.  Specifically, the framework reminds us that "no assumptions should 
be made that it is unique in the domains of either the client or the RS" yet 
this document is using the kid as input to a KDF that produces keys that must 
be unique across all clients, and allowing live/instant authorization updates 
based on matching "kid".
How shall we resolve this apparent conflict?

[JLS] I am having a problem seeing what the conflict is here.  The "kid" is a 
publicly known value so that fact that it is included in the KDF is not what is 
going to produce unique keys for all clients no matter what.  It is the secret 
that is going to make things unique.  There is a potential problem with the 
fact that the RS may get two different entities that register a token which has 
the same kid value, but that is a known issue for (D)TLS.  This is one of the 
reasons that the token itself can be used as the "kid" for DTLS.

We also are potentially in violation of the framework's requirements with 
respect to the independent selection of profiles for client/AS and client/RS 
interactions -- at present, when DTLS+RPK is used for client/RS, we require 
that DTLS+RPK is also used for client/AS, in order to prove possession of the 
key.  We could perhaps weasel our way out by saying that the framework's 
requirement applies at the profile granularity, and with symmetric PSK we can 
be fully independent, but we still need to say something about this property 
and the interaction with the framework's requirements.

[JLS] I am missing where it is saying this.   Can you give a pointer?  I don't 
believe that the POP of the RPK is required at the time that the token is 
obtained.

This profile is mostly applicable to the client/RS communications and feels 
like it only provides some of the picture for use with client/AS interactions.  
(It doesn't really say much of anything about RS/AS
interactions.) The introductory discussion does not do a great job of painting 
that picture, and I'd like to see it more clearly introduced that the bulk of 
our coverage is for the client/RS interaction.  We also lean heavily on the 
existing out-of-band configuration and key material shared between client and 
AS to secure the client/AS communications; we could probably tighten up the 
discussion about exactly what parameters of client/AS communication are 
specified by this profile.

[JLS] I think this makes sense.

We do not say anything about DTLS session resumption (or renegotiation, though 
not talking about that one is perfectly fine); that's a fairly core DTLS 
concept that we should give some guidance on.

[JLS] I don't see any reason to talk about renegotiation, either it is done or 
it isn't and a new connection would need to be created.  I am not sure what to 
say about session resumption.   This is something that really needs to be dealt 
with in the CoRE working group before anything can be said here.  Session 
resumption would only resume the TLS session, but any CoRE state above it is 
not going to be restored because it is defined as going away in RFC 7252.  This 
is currently also true for doing a renegotiation.

Looking through Appendix C ("Requirements on Profiles") of the framework, do we 
want to say anything about:

- using the client credentials grant with this profile, as that's IIRC
  the only example we show
- require that DTLS be used in a mode that provides replay protection
- when the client uses the authz-info endpoint instead of the
  "psk_identity" field to convey the token to the RS, how does the RS
  know which