Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
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
> -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] Extended REST model comment
> -Original Message- > From: Carsten Bormann > Sent: Tuesday, June 30, 2020 8:35 AM > To: Jim Schaad > Cc: draft-bormann-core-ace-...@ietf.org; ace@ietf.org > Subject: Re: [Ace] Extended REST model comment > > On 2020-06-30, at 16:43, Jim Schaad wrote: > > > > In trying to formalize a policy for the RD testing, I ended up with > > something that I think needs to be noted in this section. There is a > > difference between the following statements: > > > > Access is granted to resources created by the client. > > Access is granted to resources that could have been created by the client. > > > > The first is what the text seems to cover. This make sense in for the > > coffeepot where only the person who created the order should be able > > to cancel it. (Well maybe an administrator might need to as well.) > > However it does not cover the case where an installer created a number > > of entries in the RD. A QA person then comes through to make sure the > > installation was done correctly. When he finds a problem, the first > > statement requires that the original installer come out to fix it > > while the second statement allows the QA person to make the fix. > > Hi Jim, > > interesting. I was thinking about #1 — I can make a coffee, I can cancel > making it, you can make a coffee, but you can’t cancel my coffee. > Or delete my RD entry, etc. So making the resource confers ownership (really: > a separate set of permission bits) that is bound to the subject. > > In my view of how permission systems usually work, the other alternative > requires creating a group. The inherited permission would then be attached to > the group. > Since AIF is about capability lists, not about subject identities, I think we > are > covered — just have the capability list on the group. [JLS] I would agree that there is no need to make any changes in the AIF structure. I would just like to see some text discussing that policy can enforce this in either way. Jim > > NFSv4 permissions probably also have a way to handle this kind of inheritance, > but I’ll not have time to look that up today... > > 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
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
>> >> 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
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
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] Extended REST model comment
On 2020-06-30, at 16:43, Jim Schaad wrote: > > In trying to formalize a policy for the RD testing, I ended up with > something that I think needs to be noted in this section. There is a > difference between the following statements: > > Access is granted to resources created by the client. > Access is granted to resources that could have been created by the client. > > The first is what the text seems to cover. This make sense in for the > coffeepot where only the person who created the order should be able to > cancel it. (Well maybe an administrator might need to as well.) However it > does not cover the case where an installer created a number of entries in > the RD. A QA person then comes through to make sure the installation was > done correctly. When he finds a problem, the first statement requires that > the original installer come out to fix it while the second statement allows > the QA person to make the fix. Hi Jim, interesting. I was thinking about #1 — I can make a coffee, I can cancel making it, you can make a coffee, but you can’t cancel my coffee. Or delete my RD entry, etc. So making the resource confers ownership (really: a separate set of permission bits) that is bound to the subject. In my view of how permission systems usually work, the other alternative requires creating a group. The inherited permission would then be attached to the group. Since AIF is about capability lists, not about subject identities, I think we are covered — just have the capability list on the group. NFSv4 permissions probably also have a way to handle this kind of inheritance, but I’ll not have time to look that up today... Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] Extended REST model comment
In trying to formalize a policy for the RD testing, I ended up with something that I think needs to be noted in this section. There is a difference between the following statements: Access is granted to resources created by the client. Access is granted to resources that could have been created by the client. The first is what the text seems to cover. This make sense in for the coffeepot where only the person who created the order should be able to cancel it. (Well maybe an administrator might need to as well.) However it does not cover the case where an installer created a number of entries in the RD. A QA person then comes through to make sure the installation was done correctly. When he finds a problem, the first statement requires that the original installer come out to fix it while the second statement allows the QA person to make the fix. Jim ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
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
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,
