Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

[Benjamin Kaduk]

On Thu, Nov 23, 2017 at 11:55:46AM +0100, Carsten Bormann wrote:
> Hi Ludwig,
> 
> > I'm not sure what the RFC editors prefer as affiliation
> > (I've seen both):
> > 
> > --
> > E. Wahlstroem
> > 
> > --  OR
> > E. Wahlstroem
> > (no affiliation)
> > —
> 
> I don’t know what the RFC editor prefers her, but I find “no affiliation” 
> jarring — leaving the space open is much better.

I also sometimes see "Unaffliated".

> > ===
> > 2. Terminology
> > 
> > In the RFC 2119 boilerplate I noticed that only MUST, MUST NOT and NOT 
> > RECOMMENDED is used in the draft. What is the recommended procedure here? 
> > It feels like we could remove the other ones.
> 
> It is usual to include the whole boilerplate (obviously the corrected one, 
> with NOT RECOMMENDED included, in this case).

Right, at this point people should be citing BCP 14/RFC 8174.

-Ben

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

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

[Benjamin Kaduk]

Reminder: there is only one week left in this WGLC.

-Ben

On Wed, Nov 01, 2017 at 12:24:56PM -0500, Benjamin Kaduk wrote:
> This message begins a working group last call for
> draft-ietf-ace-cbor-web-token for submission as a Standards-Track RFC,
> ending at 23:59 PST on Wednesday 29 November, 2017.
> 
> The current (-09) version of the document is available at:
> https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-09 .
> 
> Thanks,
> 
> Ben and Jim
> 
> ___
> 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] IETF 100 draft agenda posted

[Benjamin Kaduk]

Hi Hannes,

I wouldn't say that; it's more of a race condition as I prepared the
agenda last night and did not see your request this morning before I
submitted the draft agenda.  So, you should expect a separate response
to that request (and could note that the current agenda does not fill
the allocated timeslot),

-Ben

On Tue, Nov 07, 2017 at 05:05:09PM +, Hannes Tschofenig wrote:
> Hi Ben,
> 
> I suspect my question about agenda time for the group communication security 
> topic was thereby (indirectly) answered with "no".
> 
> Ciao
> Hannes
> 
> 
> -Original Message-
> From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Benjamin Kaduk
> Sent: 07 November 2017 16:49
> To: ace@ietf.org
> Subject: [Ace] IETF 100 draft agenda posted
> 
> Hi all,
> 
> I just posted a draft agenda to the datatracker for our sesion in Singapore, 
> included below for your convenience.  Note that it is still draft, i.e., 
> might change some more.
> 
> Presenters, please send your slides to the chairs by Sunday the 12th so that 
> we can get them uploaded and confirm that we can display them, etc.  We also 
> would like to ask the presenters to focus their presentations on open issues 
> that require WG input -- all of the documents on the agenda have been 
> presented previously, and there is not much need for a tutorial/content 
> section as an introduction.
> 
> -Ben
> for the chairs
> 
> 
> ==
> 
> ACE WG Meeting
> IETF 100 - Singapore
> 
> Agenda Bashing and Administrivia (Chairs, 5 mins)
> 
> Status Update (Chairs, 5 mins)
> 
> Current Working Group Documents:
>   * draft-ietf-ace-cbor-web-token (5 mins) - Mike Jones
>   * draft-ietf-ace-cwt-proof-of-possession (10 mins) - Mike Jones
>   * draft-seitz-ace-oscoap-profile (10 mins) - Francesca Palombini
>   * draft-ietf-ace-oauth-authz (15 mins) - Ludwig Seitz
>   * draft-ietf-ace-dtls-authorize (10 mins) - Olaf Bergmann/Göran
> 
> Non-Working Group Documents:
>   * draft-tiloca-ace-oscoap-joining (15 mins) - Marco Tiloa
>   * draft-aragon-ace-ipsec-profile (5 mins) - Marco Tiloa
> 
>   * draft-vanderstok-ace-coap-est (15 mins) - Peter van der Stok
> 
> Wrap up - (Chairs, 15 mins)
>   * Steps before next meeting
> 
> ___
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
> 
> ___
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

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

[Ace] WGLC on draft-ietf-ace-cbor-web-token

[Benjamin Kaduk]

This message begins a working group last call for
draft-ietf-ace-cbor-web-token for submission as a Standards-Track RFC,
ending at 23:59 PST on Wednesday 29 November, 2017.

The current (-09) version of the document is available at:
https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-09 .

Thanks,

Ben and Jim

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

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

[Benjamin Kaduk]

On Wed, Nov 01, 2017 at 06:33:59PM +0100, Carsten Bormann wrote:
> Just wondering:
> 
> Are you aware that this is a second WGLC?  You didn’t mention that.

I was aware, sorry for not mentioning it.  (The first WGLC was on the -04.)

> (And do we really need four weeks for a second WGLC?  Even factoring in the 
> IETF week?)

It spans a US holiday and an IETF meeting, so the extra time seemed warranted
given how many other distractions people may have.

-Ben

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

[Ace] IETF 100 draft agenda posted

[Benjamin Kaduk]

Hi all,

I just posted a draft agenda to the datatracker for our sesion in
Singapore, included below for your convenience.  Note that it is
still draft, i.e., might change some more.

Presenters, please send your slides to the chairs by Sunday the 12th
so that we can get them uploaded and confirm that we can display them,
etc.  We also would like to ask the presenters to focus their presentations
on open issues that require WG input -- all of the documents on the agenda
have been presented previously, and there is not much need for a
tutorial/content section as an introduction.

-Ben
for the chairs


==

ACE WG Meeting
IETF 100 - Singapore

Agenda Bashing and Administrivia (Chairs, 5 mins)

Status Update (Chairs, 5 mins)

Current Working Group Documents:
  * draft-ietf-ace-cbor-web-token (5 mins) - Mike Jones
  * draft-ietf-ace-cwt-proof-of-possession (10 mins) - Mike Jones
  * draft-seitz-ace-oscoap-profile (10 mins) - Francesca Palombini
  * draft-ietf-ace-oauth-authz (15 mins) - Ludwig Seitz
  * draft-ietf-ace-dtls-authorize (10 mins) - Olaf Bergmann/Göran

Non-Working Group Documents:
  * draft-tiloca-ace-oscoap-joining (15 mins) - Marco Tiloa
  * draft-aragon-ace-ipsec-profile (5 mins) - Marco Tiloa

  * draft-vanderstok-ace-coap-est (15 mins) - Peter van der Stok

Wrap up - (Chairs, 15 mins)
  * Steps before next meeting

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

Re: [Ace] timeslot for draft-ietf-ace-dtls-authorize @IETF 100

[Benjamin Kaduk]

Hi Olaf,

On Mon, Nov 06, 2017 at 05:11:43PM +0100, Olaf Bergmann wrote:
> Dear chairs,
> 
> we would like to request a 10 min timeslot for the ACE session at IETF
> 100 to present the current status of draft-ietf-ace-dtls-authorize. We
> have not yet decided on a presenter but at least one of the authors,
> Göran, will be on-site.

It looks like we will have time for a 10-minute slot.

Since we need to coordinate with Meetecho for remote presenters, please
let us know by this Wednesday (8 November) if the presenter is likely
to be remote.

Thanks,

Ben

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

Re: [Ace] How to specify DTLS MTI in COAP-EST

[Benjamin Kaduk]

On Wed, Jun 06, 2018 at 07:32:13PM -0400, Michael Richardson wrote:
> 
> In draft-ietf-ace-coap-est, we would like to specify some mandatory to
> implement algorithms for DTLS.
> 
> We write:
>The mandatory cipher suite for DTLS in EST-coaps is
>TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 defined in [RFC7251] which is the
>mandatory-to-implement cipher suite in CoAP.
> 
>Additionally, the curve secp256r1 MUST be supported [RFC4492]; this curve
>is equivalent to the NIST P-256 curve.
> 
> And this is fine for now, but we'd like to signal that Curve25519 should be
> considered as an alternative, but we don't want to make it a MUST *today*,
> and we don't want to force implementations 15 years down the road that have
> it to include secp256r1.
> 
> IPsec(ME) has published things like: https://datatracker.ietf.org/doc/rfc8247/
> which include language like:
> 
>SHOULD+   This term means the same as SHOULD.  However, it is likely
>  that an algorithm marked as SHOULD+ will be promoted at
>  some future time to be a MUST.
> 
>SHOULD-   This term means the same as SHOULD.  However, an algorithm
>  marked as SHOULD- may be deprecated to a MAY in a future
>  version of this document.
> 
>MUST- This term means the same as MUST.  However, it is expected
>  at some point that this algorithm will no longer be a MUST
>  in a future document.  Although its status will be
>  determined at a later time, it is reasonable to expect that
>  if a future revision of a document alters the status of a
>  MUST- algorithm, it will remain at least a SHOULD or a
>  SHOULD- level.

Unfortunately, I'm not a big fan of the "+/-" variants of RFC 2119
keywords.  It seems more clear to me to actually write out in prose
the current situation and future expectations.  So, if you do end up
going this route, please ensure that the shepherd writeup includes a
justification of why it was chosen.

-Ben


signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Benjamin Kaduk]

On Tue, Jun 26, 2018 at 08:53:57AM +, Hannes Tschofenig wrote:
> Ben,
> 
> I was wondering whether the situation is any different in Kerberos. If the 
> KDC creates tickets with a session key included then it needs to make sure 
> that it does not create the same symmetric key for different usages.
> The key in the Kerberos ticket is similar to the PoP key in our discussion.
> 
> Are we aware of key collision in Kerberos?

I don't believe key collision is an issue in Kerberos.  Long-term keys
(which are not what we're talking about here) are identified by a principal
name, encryption type, and version number.  Session keys that are contained
within tickets (and returned to the client in the KDC-REP) are random, so
even if we are only using the birthday bound we're still in pretty good
shape.  The modern enctypes tend to use subsession keys generated by the
client and/or server as well as the KDC-generated session key, which
provides further binding to the current session.

Does that answer your question?

-Ben

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

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

[Benjamin Kaduk]

I thought we were worried about collision of key *identifiers*, which were
not necessarily raw keys or hashes thereof.  But it's possible I was not
paying enough attention and got confused.

-Ben

On Tue, Jun 26, 2018 at 03:12:52PM +, Hannes Tschofenig wrote:
> It does answer my question, Ben.
> 
> This begs the question why the collision of session keys is suddenly a 
> problem in the ACE context when it wasn't a problem so far. Something must 
> have changed.
> 
> Ciao
> Hannes
> 
> 
> -----Original Message-
> From: Benjamin Kaduk [mailto:ka...@mit.edu]
> Sent: 26 June 2018 17:00
> To: Hannes Tschofenig
> Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; 
> ace@ietf.org
> Subject: Re: [Ace] Key IDs ... RE: WGLC on 
> draft-ietf-ace-cwt-proof-of-possession-02
> 
> On Tue, Jun 26, 2018 at 08:53:57AM +, Hannes Tschofenig wrote:
> > Ben,
> >
> > I was wondering whether the situation is any different in Kerberos. If the 
> > KDC creates tickets with a session key included then it needs to make sure 
> > that it does not create the same symmetric key for different usages.
> > The key in the Kerberos ticket is similar to the PoP key in our discussion.
> >
> > Are we aware of key collision in Kerberos?
> 
> I don't believe key collision is an issue in Kerberos.  Long-term keys
> (which are not what we're talking about here) are identified by a principal
> name, encryption type, and version number.  Session keys that are contained
> within tickets (and returned to the client in the KDC-REP) are random, so
> even if we are only using the birthday bound we're still in pretty good
> shape.  The modern enctypes tend to use subsession keys generated by the
> client and/or server as well as the KDC-generated session key, which
> provides further binding to the current session.
> 
> Does that answer your question?
> 
> -Ben
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.

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

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

[Benjamin Kaduk]

On Fri, Jun 22, 2018 at 01:36:16PM +, Hannes Tschofenig wrote:
> Hi Jim,
> 
> 
> > My problem is that if there are two different people with the same Key ID,
> either intentionally or unintentionally, then using the key ID to identify
> the key may allow the other person to masquerade as the first person.  I am
> unworried about the instance of a failure to get a key based on a key id.
> That is not the problem you are proposing to address.
> 
> -
> 
> I think we should document this issue. Here is some text proposal that could 
> go into a
> separate operational consideration section (or into the security 
> consideration section instead).
> 
> "
> - Operational Considerations
> 
> The use of CWTs with proof-of-possession keys requires additional information 
> to be shared
> between the involved parties in order to ensure correct processing. The 
> recipient needs to be
> able to use credentials to verify the authenticity, integrity and potentially 
> the confidentiality of
> the CWT and its content. This requires the recipient to know information 
> about the issuer.
> Like-wise there needs to be an upfront agreement between the issuer and the 
> recipient about
> the claims that need to be present and what degree of trust can be put into 
> those.
> 
> When an issuer creates a CWT containing a key id claim, it needs to make sure 
> that it does not
> issue another CWT containing the same key id with a different content, or for 
> a different subject,
> within the lifetime of the CWTs, unless intentionally desired. Failure to do 
> so may allow one party
> to impersonate another party with the potential to gain additional privileges.
> "

When would this be "intentionally desired"?  It seems like there would be
better ways to share authorization between parties than to issue such
duplicate CWTs.

-Ben

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

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

[Benjamin Kaduk]

On Fri, Jun 22, 2018 at 08:48:35PM +, Mike Jones wrote:
> See my note just now proposing this text to Jim:
> 
> "Likewise, if PoP keys are used for multiple different kinds of CWTs in an 
> application and the PoP keys are identified by Key IDs, care must be taken to 
> keep the keys for the different kinds of CWTs segregated so that an attacker 
> cannot cause the wrong PoP key to be used by using a valid Key ID for the 
> wrong kind of CWT."
> 
> As long as the PoP keys for different contexts are kept segregated, Key ID 
> collisions or reuse cause no problems.

If we trust everyone to implement things properly.  We should probably only
take that risk if we get some other benefit from it, though.  Jim mentioned
(off-list?) a scenario involving giving the same client additional
privileges, and of course we can gain some simplicity savings if we don't
need to enforce global key-id uniqueness (for appropriate values of
"global").  So this may well be the right thing to do; I just don't think
it's without tradeoffs as your text seems to imply.

-Ben

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

[Ace] shepherd review of draft-ietf-ace-cbor-web-token-11

[Benjamin Kaduk]

Hi all,

We're getting ready to send this to Kathleen for processing
(hopefully to finish before her term as AD does!), but there are a
few nits that should be fixed with a new rev before we actually push
the button.

We currently have an informational reference to RFC 5226, which has
since been replaced by RFC 8126; we should update our citation to
the newer document with guidelines for writing IANA considerations.

In section 9.1 the second pargaraph says that the values are
registerd on a "Specification Required" basis, but we have some
ranges that are just "Expert Review".  So I think this text should
say "Expert Review" instead (with some of the guidance to the
experts being that certain subranges have additional requirements).

We also note that the Experts should consider "whether it is useful
only for a single application", and it's not entirely clear to me
what the reuslt of that consideration should be.  Is only being
useful for a single application supposed to be grounds for rejecting
a registration?  (That doesn't seem necessarily true, for the Expert
Review range.)  Or is that just a factor for whether "nice-looking"
names should be allowed for them?  Or something else?

In section 9.4, we attempt to register a value from the CBOR Tag
registry; however, the template in RFC 7049 includes a "description
of semantics" field, and not the "reference" field that we provide.

Finally, in the acknowledgments, we can ask the RFC Editor to use
the non-ASCII "Gőran" if he so desires.  (Last I heard the tooling
isn't there to use non-ASCII for internet drafts yet, though.)

Authors, will you be able to prepare a new version with these
changes?

Thanks,

Ben

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

Re: [Ace] Removal of the Client Token from ACE-OAuth draft

[Benjamin Kaduk]

On Thu, Feb 01, 2018 at 01:59:48PM +, Hannes Tschofenig wrote:
> Hi all,
> 
> the Client Token is a new mechanism in the ACE-OAuth that aims to solve a 
> scenario where the Client does not have connectivity to the Authorization 
> Server to obtain an access token while the Resource Server does.

This sounds eerily reminiscent of the IAKERB GSS-API mechanism,
where the initiator uses the acceptor as a proxy to contact the
Kerberos KDC, obtain an initial ticket, and obtain the credentials
needed to complete the "normal" Kerberos exchange with the acceptor.
(An early draft of) it got implemented, but the spec kind of died
and we don't know of anyone actually using it.

So, I support not including it unless we have some actual use cases
in mind.

-Ben

> The solution is therefore for the Client to use the Resource Server to relay 
> messages to the Authorization Server.
> 
> While this sounds nice it does not follow the OAuth model and we, at ARM, 
> have not seen anyone requesting this feature. It is also not fully specified 
> in the spec: since I have been doing a formal analysis of this protocol 
> variant for the OAuth Security Workshop I had to notice that it is not 
> secure. (I will post the paper to the list asap.)
> 
> Note that I am not saying that we should never do this work but I prefer that 
> someone who really cares about this use case describes it in an independent 
> document.
> 
> In summary, I am again requesting that the Client Token functionality is 
> removed from the ACE-OAuth draft.
> 
> Ciao
> Hannes
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.

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

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

Re: [Ace] ACE - OAuth Synchronization

[Benjamin Kaduk]

Hi Hannes,

Can you remind me which parameters are being problematic in this regard?  I
mostly only remember the ace discussions of keyid, recently, so I probably
lost track of some relevant bits.

Thanks,

Ben

On Thu, Jul 19, 2018 at 02:34:26PM +, Hannes Tschofenig wrote:
> Hi Ben, Hi Ekr,
> 
> We tried to find an agreement of which group defines parameters needed for 
> ACE to support the PoP token functionality.
> Unfortunately, we didn't manage to find an agreement in which group the work 
> should be done.
> 
> The ACE working group wants to start a working group last call on 
> draft-ietf-ace-oauth-authz in September. Hence, there is some urgency in 
> making a decision.
> 
> We need your guidance to avoid having the topic bounce back and forth between 
> the two groups.
> 
> Ciao
> Hannes
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.

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

[Ace] Draft agenda for London

[Benjamin Kaduk]

Hi all,

I just (belatedly) posted a draft agenda to the datatracker
(https://datatracker.ietf.org/doc/agenda-101-ace/), also copied
below.  Please holler if there are obvious bugs, you requested time
but didn't get a response, etc.

I know it's a little bit of short notice, but to the speakers:
please get some form of slides to the chairs this week (before
Saturday) so that we can look over them in advance.  We should not
be scrambling on Monday morning!

Thanks,

Ben
for the chairs

%%

ACE WG IETF 101, Monday March 19, 2018 0930h-1200h (2.5h)

Chairs -- Note Well and agenda bashing, 5min
Chairs -- document status update, 5min

Mike -- draft-ietf-ace-cwt-proof-of-possession, 10min

Peter -- draft-ietf-ace-coap-est, 10min
Gőran -- draft-selander-ace-coap-est-oscore, 5min

Ludwig -- draft-ietf-ace-oauth-authz, 10min
Ludwig -- draft-ietf-ace-dtls-authorize, 5min 
Ludwig -- draft-ietf-ace-oscore-profile, 5min

Marco -- draft-tiloca-ace-oscoap-joining, 10min
Francesca -- draft-palombini-ace-key-groupcomm, 10min

Gőran -- key exchange for OSCORE (EDHOC vs. TLS-OSCORE), 15min
Gőran -- scope of authorization work, 30min

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

Re: [Ace] draft-ietf-ace-coap-est-00

[Benjamin Kaduk]

On Mon, Mar 12, 2018 at 09:08:05AM +0100, peter van der Stok wrote:
> Hi Jim,
> 
> thanks for the comments. See my reactions below.
> Jim Schaad schreef op 2018-03-10 22:15:
> > I agree with Hannes, this version of the document is much cleaner and 
> > much
> > clearer.  I think that it has solved most of the problems that I 
> > initially
> > had with the draft.  It is not ready to progress as there are still 
> > sections
> > that are marked as TODO.  But it is much closer to finishing that it 
> > was.
> 
> That sounds hopeful. Agree about the TODOs
> > 
> > I still have a couple of comments from a quick read through of the 
> > document.
> > 
> > In section 2 - There will be a problem in that the port format 
> > extension is
> > being eliminated in TLS 1.3 - We may want to divide this into a 1.2 and 
> > 1.3
> > section for clarity.
> 
> You mean for backward compatibility?

For forwards compatibility, mostly, so we don't claim to require
something that does not exist in TLS 1.3.

-Ben

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

Re: [Ace] draft-ietf-ace-coap-est-00

[Benjamin Kaduk]

On Tue, Mar 13, 2018 at 09:44:37PM -0400, Michael Richardson wrote:
> 
> Jim Schaad  wrote:
> > In section 2 - There will be a problem in that the port format 
> extension is
> > being eliminated in TLS 1.3 - We may want to divide this into a 1.2 and 
> 1.3
> > section for clarity.
> 
> I don't understand what you are referring to.
> 
> What is the "port format extension" you are referring to, and where in
> section 2 do you think we are depending upon it?

   [...] DTLS
   implementations MUST use the Supported Elliptic Curves and Supported
   Point Formats Extensions [RFC4492]; the uncompressed point format
   MUST be supported; [RFC6090] can be used as an implementation method.

The uncompressed point format only exists in (D)TLS 1.2 and lower.
(TLS 1.3 does not separately negotiate point format, rather, the
point format is determined by the group/curve to be used.)

I think the fix would just be something like "the uncompressed point
format MUST be supported for DTLS versions prior to 1.3".

-Ben


signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12

[Benjamin Kaduk]

On Mon, Feb 26, 2018 at 11:03:07AM -0800, Dan Romascanu wrote:
> 
> 1. CWT is derived from JWT (RFC 7519) using CBOR rather than JSON for 
> encoding.
> The rationale as explained in the document is related to efficiency for some
> IoT systems. The initial claims registry defined in Section 9.1 is identical
> (semantically) with the initial claims registry defined in Section 10.1 of RFC
> 7519. Is this parallelism supposed to continue? If the two registries will
> continue to evolve in parallel, maybe there should be a mechanism at IANA to
> make this happen. Was this discussed by the WG? Maybe there is a need to
> include some text about the relationship between the two registries.

The shepherd writeup includes a note to the IESG recommending that
there be overlap between the experts for the CWT and JWT registries:

  Since near-total overlap is expected between the CWT and JWT
  registry contents, overlap in the corresponding pools of Experts
  would be useful, to help ensure that the appropriate amount of
  overlap between the registries is maintained.

So I expect that the right thing will happen in practice, though
you're probably right that having some text in the document itself
(and the registry template as well) would be a good safety net.

-Benjamin

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

Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12

[Benjamin Kaduk]

On Mon, Feb 26, 2018 at 11:19:04PM +0200, Dan Romascanu wrote:
> Hi Jim,
> 
> Thank you for your answer and for addressing my comments.
> 
> On item #2:
> 
> 
> 
> On Mon, Feb 26, 2018 at 10:12 PM, Jim Schaad  wrote:
> 
> >
> >
> > > -Original Message-
> > > From: Dan Romascanu [mailto:droma...@gmail.com]
> > >
> >
> > ...
> 
> > >
> > > 2. I am a little confused by the definition of policies in Section 9.1:
> > >
> > >Depending upon the values being requested, registration requests are
> > >evaluated on a Standards Track Required, Specification Required,
> > >Expert Review, or Private Use basis [RFC8126] after a three-week
> > >review period on the cwt-reg-rev...@ietf.org mailing list, on the
> > >advice of one or more Designated Experts.
> > >
> > > How does this work? The request is forwarded to the designated expert,
> > > he/she make a recommendation concerning the policy on the mail list, and
> > > depending on the feedback received a policy is selected? Who establishes
> > > consensus?
> > >
> > > Frankly, I wonder if this can work at all. Are there other examples of
> > four
> > > different policies for the same registry, applied on a case-to-case
> > basis?
> >
> > This is the same approach that is being used for the COSE registries.  As
> > an example, you can look at https://www.iana.org/
> > assignments/cose/cose.xhtml#algorithms.
> >
> > Part of the issue about this is that the JOSE/JWT registries do have the
> > same different policies, but that differences are hidden from the IANA
> > registry.  Since they allow for a URI to be used as the identifier of a
> > field, only the plain text versions are registered.  Thus I can use "
> > http://augustcellars.com/JWT/My_Tag; as an identifier.  Since for CBOR
> > the set of tag values is closed and does not have this escape (nor would
> > one want the length of the tag) it is necessary to have this break down of
> > tag fields.
> >
> >
> >
> >
> This does not seem to be exactly the same approach. The COSE RFC 8152
> defines the registry policy in a different manner. There is only one policy
> that is proposed 'Expert Review' and than the Expert Review Instructions
> are used to define the cases when a Standards Track specification is
> required. No such text exists in the current I-D. There is no separation of
> the values space in the registry according to the type of assignment here,
> as  in RFC 8152.

The template in section 9.1.1 has the different policies for the
different integer ranges, under the 'Claim Key' section.  Kathleen
(IIRC) already noted that this should probably be repeated in the
introductory part of section 9.1 as well, and that will be done
before the document is sent to the IESG.

-Benjamin

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

Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12

[Benjamin Kaduk]

On Tue, Feb 27, 2018 at 11:59:50AM +0200, Dan Romascanu wrote:
> Hi,
> 
> See also my other notes.
> 
> I believe that what the document tries to say is:
> 
> Register R is divided into four different ranges R1, R2, R3, R4 (defining
> the value limits may be useful)
> 
> Values in range R1 are allocated according to policy P1 in the case that ...
> Values in range R2 are allocated according to policy P2 in the case that ...
> Values in range R3 are allocated according to policy P3 in the case that ...
> Values in range R4 are allocated according to policy P4 in the case that ...
> 
> But it doesn't say it. Mentioning four concurrent policies for the same
> registry without separation of values range, and without providing clear
> instructions when each policy is recommended to be used, seems confusing to
> me, and may be confusing for users of this document in the future.

I agree, and such a change is slated to be in the next rev of the
document.  Sorry for spending so much text to be in violent
agreement...

-Ben

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

Re: [Ace] CBOR Web Token (CWT) draft addressing IETF last call comments

[Benjamin Kaduk]

Hi Mike,

Thanks for these updates!

-Ben

On Mon, Mar 05, 2018 at 09:33:51PM +, Mike Jones wrote:
> The CBOR Web Token (CWT) specification has been updated to address IETF last 
> call comments received to date, including GenArt, SecDir, Area Director, and 
> additional shepherd comments.  Changes were:
> 
>   *   Clarified the registration criteria applied to different ranges of 
> Claim Key values, as suggested by Kathleen Moriarty and Dan Romascanu.
>   *   No longer describe the syntax of CWT claims as being the same as that 
> of the corresponding JWT claims, as suggested by Kyle Rose.
>   *   Added guidance about the selection of the Designated Experts, as 
> suggested by Benjamin Kaduk.
>   *   Acknowledged additional reviewers.
> 
> The specification is available at:
> 
>   *   https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-13
> 
> An HTML-formatted version is also available at:
> 
>   *   http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-13.html
> 
> -- Mike
> 
> P.S.  This notice was also posted at http://self-issued.info/?p=1789 and as 
> @selfissued<https://twitter.com/selfissued>.
> 

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

Re: [Ace] EDHOC standardization

[Benjamin Kaduk]

Hi Salvador,

On Wed, Oct 31, 2018 at 10:12:54AM +0100, Salvador Pérez wrote:
> Hello authors of EDHOC,
>  
>   we have implemented a previous version of EDHOC 
> (draft-selander-ace-cose-ecdhe) and want to share some experiences.
>  
> Our work so far has focused on implementation and evaluation of version -08 
> of EDHOC over CoAP using real IoT hardware. The obtained results show a 
> significant performance improvement compared to other key establishment 
> protocols, such as DTLS handshake (version 1.2), especially with respect to 
> length and number of exchanged messages.

Are your results written up anywhere?  It would be great to see more
details of the comparison and the actual numbers.
Unfortunately, I don't think that DTLS 1.2 is the best comparison -- DTLS
1.3 should be seen as the current "state of the art" for DTLS, and is
expected to itself be leaner than DTLS 1.2, which might wash out some of
the results you've seen here.

Thanks,

Ben

> We have reviewed version -10 and noted the reduction of message length. Based 
> on our experience, we propose that also removing the overhead due to security 
> parameter negotiation could be an important optimization, and relevant in 
> many use cases where these parameters are available through an out-of-band 
> process.
>  
> Accordingly and taking into account that EDHOC provides a basic security 
> functionality for any context where security needs to be enabled, we are 
> currently considering the application of this protocol in different IoT 
> deployments, such as LoRaWAN networks, OSCORE-enabled scenarios or its 
> integration with capabilities. We therefore would like to see the progress of 
> EDHOC in standardization.
> 
> Kind regards,
> 
> 
> Salvador Pérez
> PhD student in "Future Internet Networks: Infrastructure and Security”
> Faculty of Computer Science - University of Murcia
> Email: salvador@um.es
> Skype: salva.pf
> 

> ___
> 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] Minimizing overhead of certificates in constrained IoT

[Benjamin Kaduk]

On Fri, Nov 02, 2018 at 11:31:16AM +, John Mattsson wrote:
> Hi,
> 
> We recently submitted 
> https://tools.ietf.org/html/draft-raza-ace-cbor-certificates-00, which build 
> on research done by Research Institutes of Sweden, Royal Institute of 
> Technology in Stockholm, and Nexus:
> 
> https://kth.diva-portal.org/smash/get/diva2:1153958/FULLTEXT01.pdf
> https://doi.org/10.1007/978-3-319-93797-7_14
> 
> The mechanism in the draft aims to reduce message overhead with the approach 
> to start with a heavily profiled X.509 certificate and encode it to CBOR, 
> resulting in around 50% savings in message overhead and storage. A major 
> reason for submitting this early draft is to start a discussion on how to 
> minimize the overhead (message size, code size, memory, storage, processing, 
> etc.) caused by certificates in IoT deployments.
> 
> Current X.509 certificates are demanding in several ways (message, code size, 
> memory, processing, etc. and are not designed for constrained IoT 
> environments. The quite large sizes of even well profiled X.509 certificates 
> mean that they take up a large part of the total number of bytes when used in 
> protocols. Transmitting, receiving, or even listening for radio is relatively 
> expensive in terms of power consumption and as the radio resources are often 
> constrained, large messages lead to interference and therefore more latency 
> than just the message sizes would infer.
> 
> That fact that certificates are sent encrypted in new protocols (TLS 1.3, 
> DTLS 1.3, EDHOC) means that compression in intermediaries will not work in 
> the future. TLS 1.3 and DTLS 1.3 are currently looking at certificate 
> compression, but these mechanisms are not optimal for constrained IoT. The 
> use of general lossless compression algorithms are quite heavy, and they do 
> not compress things optimally.

I assume you are not considering lossy compression algorithms, and thus are
indicating that this effort could be considered a domain-specific lossless
compression algorithm.  (Or perhaps you would consider the X.509 profile
that removes many things to be "lossy"?)

Regardless, the codepoint space for CertificateCompressionAlgorithm (in
https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-04)
seems large enough to allow for a domain-specific compression algorithm,
e.g., one incorporating a custom dictionary that would improve compression
efficiency at the cost of storage space on the implementation.  Is this an
avenue that you have investigated?

> With the submission of raft-raza-ace-cbor-certificates we would like to start 
> a discussion on how to minimize the overhead caused by certificates.
> 
> - Which aspects do the community prioritise the most? i.e. message size, code 
> size, memory, processing, etc. And how should trade-offs between these 
> aspects look like?
> 
> - For how long time is people planning to use older protocols that do not 
> encrypt certificates? Is it worth specifying gateway type of compression for 
> these protocols?
> 
> draft-raza-ace-cbor-certificates does currently take the approached to start 
> with a heavily profiled X.509 certificate and encode it to CBOR. Another 
> approach is to not start with X.509 and do certificates in CBOR directly. 
> This can be even more optimal from a theoretical point of view but may never 
> deployed. Previous attempts to introduce new certificate types seem to have 
> failed. On the other hand the current mechanism increases code size and 
> processing for the part verifying the certificate.
> 
> - How should new IoT CBOR certificates be introduced in protocols? As a new 
> type of certificate or a new compression/encoding algorithm for certificates? 
> Is compression/encoding done inside the protocol or outside of the protocol?
> 
> - Is CBOR the correct choice if a new encoding is specified? We certainly 
> think so.
> 
> - What are peoples’ opinions on general lossless compression algorithms?
> 
> - Which protocols would the IoT community want to use with new 
> certificates/encoding/compression?
> 
> I think that a good place to start a discussion about these topics would be 
> in T2TRG. If people find this interesting, I suggest having a quick 
> introduction on the Friday plenary session and then further discussions in 
> the security breakout.

There are some good questions here (and I certainly don't have the
answers!); it will be interesting to read the rest of this thread.

-Ben

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

Re: [Ace] EDHOC standardization

[Benjamin Kaduk]

On Fri, Nov 02, 2018 at 02:55:54PM +, John Mattsson wrote:
> Hi Benjamin, Salvador
> 
> While DTLS 1.3 have done a very good job of lowering the overhead of the 
> record layer when application data is sent (see e.g. 
> https://tools.ietf.org/html/draft-ietf-lwig-security-protocol-comparison-01 
> for a comparison between different protocols), I do not think the handshake 
> protocol is much leaner (is it leaner at all?).

(There are some handshake messages that are removed entirely.)

> We tried to make an fair comparison between EDHOC and TLS 1.3 in the 
> presentation at IETF 101 (see 
> https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-key-exchange-w-oscore-00).
>  Since then, we have significantly optimized the encoding in EDHOC and the 
> upcoming version (-11) is expected to have the following message sizes.
> 
>Auth.   PSK   RPK   x5t x5chain
>
>EDHOC message_1  43383838
>EDHOC message_2  47   121   127   117 + Certificate chain
>EDHOC message_3  12869282 + Certificate chain
>
>Total   102   245   257   237 + Certificate chains
> 
> As Salvador writes, the handshakes in TLS 1.3 and DTLS 1.3 are basically the 
> same, so the numbers presented at IETF 101 should be a good estimate also for 
> DTLS 1.3.
> 
>Auth.PSK   RPK
>
>(D)TLS message_1 142   107
>(D)TLS message_2 135   264
>(D)TLS message_3  51   167
>
>Total328   538

Thanks for the numbers!

> The numbers above include ECDHE. For handshake messages, my understanding is 
> that the DTLS 1.3 and TLS 1.3 record layer have exactly the same size.

The DTLS 1.3 ones will be worse, due to the epoch and sequence number
fields.

-Ben

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

Re: [Ace] EDHOC standardization

[Benjamin Kaduk]

On Mon, Nov 05, 2018 at 09:16:54AM +0700, Michael Richardson wrote:
> 
> Benjamin Kaduk  wrote:
> >> John Mattsson  wrote: > of negotiation is
> >> still needed. The current plan for the next version > is to introduce
> >> cipher suites and to let the cipher suite with value 0 > indicate that
> >> algorithms have been negotiated out-of-band.
> >>
> >> I agree with the idea that some common default should be very easy to
> >> refer to, but I don't like the idea that the gateway has to remember
> >> what the out-of-band "default" is on a per-device basis.  I would say
> >> that we need at least 0/1, so that we can say that it's the current vs
> >> the "new" default.
> >>
> >> If you consider the case where the sensor is on very low bandwidth
> >> connection (I would say LoRaWAN, but I am not well qualified in that
> >> space).  The sensor gets visited every two or three years by a
> >> technician (if only to make sure that the sensor is still where it is
> >> supposed to be).  While there new firmware updates are applied, and as
> >> a result the algorithm defaults are updated.  During the cycle, some
> >> devices are updated and some are still old.
> 
> > Are you proposing that the management of the 0/1-to-algorithm mapping
> > be managed on a per-deployment basis or by the IETF?
> 
> I think that the existing proposal was that 0 means "negotiated out-of-band",
> which implies that it's a per-deployment basis.
> 
> I'm proposing that instead of having 0 mean "some local default",
> I'm suggesting that 0 mean, "some local default 0" and 1 mean, "some other
> local default 1", which lets the default be updated without a flag day.

That feels like a potentially awkward provisioning problem.  I guess the
idea is that any given node is only going to do 1 or 0 and not both?  Maybe
that helps.

Thanks,

Ben

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

Re: [Ace] WGLC for draft-ietf-ace-authz

[Benjamin Kaduk]

Just one minor note -- this is a great discussion to see happening!

On Tue, Oct 23, 2018 at 04:43:14PM +0200, Ludwig Seitz wrote:
> 
> On 22/10/2018 21:09, Jim Schaad wrote:
> > * Section 5.8.2 - If the RS is going to do introspection, can it send some
> > type of "Server Busy - try again in xxx" while it does the introspection
> > rather than just doing an ack of the request and possibly waiting a long
> > time?
> 
> This is probably transport protocol specific, and we were asked not to 
> link the framework to a specific protocol, thus I don't know if we can 
> provide guidance here.

I think it would be okay to say something like "some transport protocols
may provide a way to indicate that the server is busy and the client should
retry after an interval; this type of status update would be appropriate
while the server is waiting for an introspection response".  Which does
provide guidance, but in a non-normative fashion that does not require or
prohibit any given transport protocol.

-Ben

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

Re: [Ace] Resume of discussion at IETF 103 meeting on draft-ietf-ace-oauth-authz

[Benjamin Kaduk]

[with no hats]

On Mon, Nov 12, 2018 at 04:21:55PM +0100, Ludwig Seitz wrote:
> Hello ACE,
> 
> I wanted to post a resume of the in room discussions from the IETF 103 
> meeting, related to draft-ietf-ace-oauth-authz, for those who missed 
> them and those who want to further comment (sorry for the verbose 
> summary below):
> 
> 
> During my presentation I put up a 7 issues for discussion as follows:
> 
> 
> 1. Use of one-byte CBOR abbreviations for parameters and CWT claims.
> 
> So far there is a consensus between me and Mike Jones on what we think 
> is reasonable.
> 
> This would be summarized here: 
> https://www.ietf.org/mail-archive/web/ace/current/msg03053.html
> 
> I was wondering if anyone else wants to weight in on what they consider 
> important parameters & claims for constrained applications that need 
> compact (one-byte) abbreviations in CBOR?
> 
> 
> 2. Unified registry for CWT claims and token/introspection parameter 
> abbreviations
> 
> Currently the draft(s) have aligned the CBOR abbreviations for both CWT 
> claims and token/introspection parameters under one singe number space.
> 
> There were arguments for splitting this up so that we can re-use the 
> same compact one-byte abbreviations in those different "namespaces" i.e. 
> there would be a number range just for CWT claims, and a separate one 
> for introspection and token endpoint parameters.
> 
> Even here I'm interested in additional input.

I have no real data (or argument) here, but my gut feeling is that
eventually there would be desire for them to diverge, which would indicate
cleanly separating them from the start.

> 3. CWT as format for signed protocol messages
> 
> As OAuth is currently working on a number of drafts specifying JWT as a 
> format for encoding request (and response?) parameters wrt. the token 
> and the introspection endpoint, the question was raised whether this 
> should also be done for ACE and CWT.
> 
> My stance here (and I got the impression that the room agreed or at 
> least had no strong opinion against) is that this is absolutely 
> possible, but would best be done in an additional draft in order to not 
> increase the already significant delay of draft-ietf-ace-oauth-authz.

I agree.

> 
> 4. Alignment between "req_aud" and "resource" parameters
> 
> draft-ietf-oauth-resource-indicators proposes a new parameter for the 
> token request called "resource" which specifies the location of the 
> resource or service for which the token is requested. This is supposed 
> to map to the audience claim in the token.
> 
> draft-ietf-ace-oauth-params has in parallel defined the "req_aud" 
> parameter (for "requested audience") which has a somewhat broader 
> definition, roughly speaking "a value that the RS identifies with". This 
> could be a public key, a group identifier or something else, so the key 
> difference is that it is not specifically bound to the location of the RS.
> 
> I would argue to keep the "req_aud" as it is currently (since it covers 
> a broader set of use cases than "resource"), but I would be curious to 
> hear additional arguments for or against.
> 
> 
> 5. Handling of multiple tokens for one pair of client-RS
> 
> The question was whether an additional token issued for the same 
> client-RS pair would
> 
> a.) Amend the permissions (i.e. scope) of the older token(s)
> 
> b.) Replace all older tokens for that client-RS pair
> 
> My implementation and my current understanding of the draft was a.) but 
> apparently OAuth mostly does b.).
> I would be strongly in favor of doing b.) (and clarifying the specs to 
> this end) since it greatly simplifies the code on the RS side. Unless 
> someone has a strong argument for approach a. I will implement that 
> change in the next document update.
> 
> 
> 6. Do we need the expiration mechanism based on sequence numbers?
> 
> Section 5.8.3 of the draft currently proposes a sequence-number-based 
> mechanism for expiration of access tokens on devices that do not have an 
> internal clock. Since this mechanisms has pretty severe limitations and 
> thus very weak security properties, and since we haven't yet seen a use 
> case involving devices without at least an internal "wall-clock time" I 
> propose to remove that mechanism from the draft, which seemed to be the 
> in-room consensus as well.

Some idea of wall-clock time is common, yes, but it is frequently easy for
an attacker to cause it to be wrong.  See, e.g.,
https://www.ietf.org/mail-archive/web/ietf/current/msg110144.html and the
document reviewed therein.

> 
> 7. Symmetric proof-of-possession keys and multi RS audiences
> 
> Currently the draft does NOT RECOMMEND this, since it allows one RS to 
> impersonate the client towards other RSs that are part of the audience.
> The in-room consensus seemed to be that this should be a MUST NOT 
> instead and I agree.

No objection here :)

-Ben

___
Ace mailing list
Ace@ietf.org

Re: [Ace] [Secdispatch] EDHOC

[Benjamin Kaduk]

On Fri, Jan 18, 2019 at 11:54:58AM -0500, Richard Barnes wrote:
> Let me provide some additional context.  When the chairs and ADs discussed 
> this in BKK, it seemed pretty clear that EDHOC is not within the current 
> charter of ACE — after all, ACE is targeted at authentication and 
> authorization, not key exchange.  Since ACE would need to recharter to accept 
> this work in any case, and because EDHOC overlapped with the interests of 
> other working groups, it seemed to make sense to have the conversation in a 
> broader venue.

ACE's charter is ... messy.  More below.

> Göran: Your email starting this thread seems like an abbreviated summary of 
> the past discussion of this draft.  Since this is a new audience, it would be 
> helpful if you could start from the underlying requirements (“we need an AKE 
> with certain constraints”) and lay out why new protocol work is needed, vs. 
> profiling existing protocols (as has been done, e.g., in DICE).


There seem to be several interleaved issues at play, here, and I agree that
some clear/consolidated background would be helpful.  I particularly call
out the security proof that has been presented elsewhere, which I think
would be interesting to several readers (but I don't have the link handy).

Some thoughts of my own...

There is clear demand for a lightweight key-exchange protocol for use in
IoT protocols, especially OSCORE.  EDHOC has been around for a while, and
even discussed in ACE with some frequency.  That said, there are several
reasons to prefer asking secdispatch to just calling for adoption in ACE
directly, including but not limited to:

(a) designing secure authenticated key exchange protocols is hard!  It takes
a lot of energy from smart people to design and analyze a protocol to have
confidence that it is secure and fulfils the advertised functions.
Starting from well-known/well-analyzed foundations like SIGMA is a great
start, but hardly a guarantee of success.  Secdispatch gets us some better
visibility, and insight into where work can be done that will have
sufficient expertise (both within and outside the IETF, as well as what has
been done already vs. what remains to be done) to be confident in the
result.

(b) ACE has a pretty complicated charter, that seems to place restrictions
on how it can adopt new protocol work without rechartering.  We find things
in the charter like "existing authentication and authorization protocols
will be evaluated and used where applicable [...].  Some functionality,
however, may not be available in existing protocols, in which case the
solution may involve new protocol work."  This would seem to require a
clear criteria for how to determine whether or not existing technology is
applicable, plus evidence that existing protocols do not meet the bar.  In
particular, "make the key exchange messages as small as possible" is not a
clear criterion, as that would always argue for a new protocol over an
existing one, as we come up with new ways to eke out space.

(c) A clear and substantial difference between key exchange/handshake size
between EDHOC and even minimized DLTS could be compelling enough for
secdispatch to decide that the work is usable, and find an appropriate
home, independently of the question of rechartering ACE and meeting the
additional barrier described in the previous point.


Jim and several others have done some good work looking into tabulating
message overheads in various scenarios (e.g.,
https://www.diva-portal.org/smash/get/diva2:1156483/FULLTEXT01.pdf,
https://jimsch.github.io/randomDrafts/draft-schaad-ace-tls-cbor-handshake.html)
that will be helpful as we consider this topic.

In addition to just comparing the byte count for handshake/key exhchange
messages in various methods, it would probably also be good to think about
things in terms of the constraints in the current ACE charter.  That is,
someone could (1) pick a (class of) device(s), (2) show that it has wide
deployment/potential thereof, (3) give hard numbers about what it's (not)
capable of, and (4) show that DTLS falls on the wrong side of that cutoff,
using the handshake numbers we already have.  In particular, I don't
remember seeing anything touching on (3), previously.  An analysis like
this would not only give some context for interpreting the gap between
EDHOC and DLTS, but could also be compelling in support of the need for the
more lightweight solution.

> If it would be helpful to keep this moving, we could certainly arrange a 
> virtual
> interim on this topic.

That seems likely to be useful, though I suppose we should wait to see more
indication that people would show up and have a productive discussion.

-Ben

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

Re: [Ace] Call for adoption of draft-palombini-ace-key-groupcomm

[Benjamin Kaduk]

On Thu, Dec 06, 2018 at 03:12:04PM -0800, Jim Schaad wrote:
> I have not looked in detail at the mls protocol documents, but from what I 
> remember they have more or less skipped the entire AAA question of having a 
> central authorizer and made it so that any entity which is currently active 
> has the ability to add or remove anybody else.
> 
>  
> 
> That is not currently an authorization model that I think is currently in 
> scope for ACE.  If I am wrong about my assumptions it would be interesting to 
> know.

My understanding agrees that the MLS design is not a good fit for the
constraints here.

-Ben

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

Re: [Ace] Security of the Communication Between C and RS

[Benjamin Kaduk]

On Thu, Dec 20, 2018 at 09:11:24AM +, Hannes Tschofenig wrote:
> 
> -Original Message-
> From: Ludwig Seitz 
> Sent: Donnerstag, 20. Dezember 2018 08:40
> To: Jim Schaad ; Hannes Tschofenig 
> ; 'Stefanie Gerdes' ; ace@ietf.org
> Subject: Re: [Ace] Security of the Communication Between C and RS
> 
> On 19/12/2018 21:22, Jim Schaad wrote:
> >
> > It would be more reasonable to say that if you are doing a physical
> > attack, then it would be easy to get an RPK and then you are the RS
> > until such a time as the AS is told that the key is no longer trusted.
> > In this case you will just continue getting tokens as a client which
> > are still valid and none of this is helpful in any event.
> 
> Ok my example was perhaps not ideal, since it has an even bigger breach as 
> precondition. So under what conditions would an attacker get access to a 
> pop-key of an expired token? Steffi any ideas?
> 
> [Hannes] We definitely need some more details about the type of attack we 
> would like to prevent. Maybe it is worthwhile to think about what information 
> the attacker steals from whom at what point in time could be a way to 
> progress the topic.

It is perhaps contrived, but one scenario in which the PoP key could be
exposed to an attacker or third party is if some sort of post-facto
auditing service is in play, where the "previous generation" of key
material is released to an auditing service, after expiration or key
rollover has occurred.  This third party would then be able to audit
network traffic (whether for intrusion detection or other purposes) but not
modify any live traffic.

Such a scheme has been proposed in the context of TLS (though I'm not
finding a good reference in the archive; maybe it was just at a mic line?),
though not with any great degree of seriousness AFAIK.

-Ben

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

Re: [Ace] [OAUTH-WG] Resource, Audience, and req_aud

[Benjamin Kaduk]

On Thu, Feb 07, 2019 at 02:28:02PM -0700, Brian Campbell wrote:
> 
> The token-exchange draft defines both the "resource" and "audience"
> parameters for use in the context of a
> "urn:ietf:params:oauth:grant-type:token-exchange" grant type request to the
> token endpoint. There is a lot of overlap between "resource" and "audience"
> and I'm not sure there was necessarily a good reason to have the two but it
> just kind of unfolded that way (the use of a client ID as an audience is
> one case that's mentioned that isn't a URI).  That document is in IESG
> evaluation (which is towards the end of the RFC process) and had a few
> DISCUSS ballot positions raised against it. Resulting from one of those
> DISCUSSes, which was unrelated to "resource"/"audience" but rather because
> of the OAuth URIs as far as I understand, one of the IESG members steered
> us in the direction of, and facilitated, the early registration requests.

That was me.  The conclusion to go for early registration was not (AFAICT)
out of a desire to get the actual value registered more quickly than it
would have been otherwise (which should be pretty fast, since IANA
generally makes the live registries reflect changes shortly after IESG
approval, not even waiting for AUTH48 or final RFC publication), but just
from it seeming to be the least-effort way to approve and publish the
document while still following the required process.  (Basically, the I-D
sent to the IESG was "codepoint squatting", having text in the document
that claims that a specific URI value will be used, but with no guarantee
from IANA that that specific value will end up being the one registered.
I didn't think the IESG should grant its seal of approval to a document
that was jumping the process in that way, and the other options we could
think of would require fairly invasive changes to the text that would
just have to be undone by the RFC Editor.)

-Ben

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

Re: [Ace] Shepard review for draft-ietf-ace-oauth-authz

[Benjamin Kaduk]

On Wed, Jan 30, 2019 at 09:37:45AM +0100, Ludwig Seitz wrote:
> 
> On 30/01/2019 07:01, Jim Schaad wrote:
> > ** IANA Section Issues
> > 
> > 1.  None of the new registries appear to have any guidance for the DEs to
> > use when approving items.
> 
> Is it acceptable to add a single guidance section for all of the new 
> registries, or does it need to be separate for each of them?

That's fine.

-Ben

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

Re: [Ace] [Technical Errata Reported] RFC8392 (5710)

[Benjamin Kaduk]

On Mon, Apr 29, 2019 at 09:53:01AM -0700, Jim Schaad wrote:
> 
> 
> > -Original Message-
> > From: Carsten Bormann 
> > Sent: Monday, April 29, 2019 9:41 AM
> > To: Felipe Gasper 
> > Cc: Benjamin Kaduk ; Roman Danyliw ;
> > Daniel Migault ; erdt...@spotify.com;
> > i...@augustcellars.com; ace@ietf.org; m...@microsoft.com;
> > e...@wahlstromstekniska.se; hannes.tschofe...@arm.com
> > Subject: Re: [Ace] [Technical Errata Reported] RFC8392 (5710)
> > 
> > On Apr 29, 2019, at 18:15, Felipe Gasper  wrote:
> > >
> > > In JSON, maps are called objects and only have one kind of key:
> > > a UTF-8 string. In CBOR, any valid CBOR item can be a map key.
> > > CWT uses signed and unsigned integers, in addition to UTF-8 strings,
> > > as map keys.
> > 
> > s/CBOR item/CBOR data item/ (this is the term we use in 7049)
> > 
> > Also, I think
> > s/UTF-8 string/text string/g
> > The fact that this is encoded in UTF-8 is somewhat on a different level of
> > detail.
> 
> +1 on this.  There is not really a restriction that UTF-8 strings be the key 
> in JSON.  If you encoded the JSON as UTF-16 then it would be a UTF-16 string.

I think I'm also +1 on that, but do recall that RFC 8529 mandates UTF-8 for
exchange among a non-closed ecosystem (i.e., all internet usage).

-Ben

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

Re: [Ace] [Technical Errata Reported] RFC8392 (5710)

[Benjamin Kaduk]

On Mon, Apr 29, 2019 at 12:03:57PM -0400, Felipe Gasper wrote:
> 
> > On Apr 29, 2019, at 12:00 PM, Benjamin Kaduk  wrote:
> > 
> > On Mon, Apr 29, 2019 at 08:55:53AM -0700, RFC Errata System wrote:
> >> The following errata report has been submitted for RFC8392,
> >> "CBOR Web Token (CWT)".
> >> 
> >> --
> >> You may review the report below and at:
> >> http://www.rfc-editor.org/errata/eid5710
> >> 
> >> --
> >> Type: Technical
> >> Reported by: Felipe Gasper 
> >> 
> >> Section: 1.1
> >> 
> >> Original Text
> >> -
> >> In JSON, maps are called objects and only have one kind of map key: a
> >>   string.  CBOR uses strings, negative integers, and unsigned integers
> >>   as map keys.
> >> 
> >> Corrected Text
> >> --
> >> In JSON, maps are called objects and only have one kind of map key:
> >> a string.  CBOR allows other data types, such as strings, negative
> >> integers, and unsigned integers, as map keys.
> >> 
> >> Notes
> >> -
> >> The text as it stands risks an interpretation that CBOR limits map keys to 
> >> integers and strings; per discussion on the CBOR mailing list, this is not 
> >> the case.
> > 
> > I see the CBOR list traffic in the archive (e.g.,
> > https://mailarchive.ietf.org/arch/msg/cbor/LyndIfQipxUfx0cu6nlOwi6ceOY) and
> > agree with the sentiment that the CWT spec should not inadvertently
> > over-specify the behavior of CBOR
> > 
> > The proposed new text is itself flawed, though, as it claims that strings
> > are an "other data type" with respect to strings.
> 
> Ah, agreed. Is there a way I can update my proposed phrase? The editor only 
> seems to allow submission of a new erratum.

I can edit the "corrected text" field during the verification process...

> It may be worth disambiguating between binary and UTF-8 strings, too; JSON 
> only allows UTF-8 strings, while CBOR also allows binary.

so we can figure out the right phrasing here on the list, and then I'll
fix things up in the system.

-Ben

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

Re: [Ace] [Technical Errata Reported] RFC8392 (5710)

[Benjamin Kaduk]

On Mon, Apr 29, 2019 at 08:55:53AM -0700, RFC Errata System wrote:
> The following errata report has been submitted for RFC8392,
> "CBOR Web Token (CWT)".
> 
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5710
> 
> --
> Type: Technical
> Reported by: Felipe Gasper 
> 
> Section: 1.1
> 
> Original Text
> -
> In JSON, maps are called objects and only have one kind of map key: a
>string.  CBOR uses strings, negative integers, and unsigned integers
>as map keys.
> 
> Corrected Text
> --
> In JSON, maps are called objects and only have one kind of map key:
> a string.  CBOR allows other data types, such as strings, negative
> integers, and unsigned integers, as map keys.
> 
> Notes
> -
> The text as it stands risks an interpretation that CBOR limits map keys to 
> integers and strings; per discussion on the CBOR mailing list, this is not 
> the case.

I see the CBOR list traffic in the archive (e.g.,
https://mailarchive.ietf.org/arch/msg/cbor/LyndIfQipxUfx0cu6nlOwi6ceOY) and
agree with the sentiment that the CWT spec should not inadvertently
over-specify the behavior of CBOR

The proposed new text is itself flawed, though, as it claims that strings
are an "other data type" with respect to strings.

-Ben

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

Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06

[Benjamin Kaduk]

On Mon, Aug 12, 2019 at 02:08:12PM +0200, Ludwig Seitz wrote:
> Hello Ben,
> 
> thank you for your review. Comments inline.
> 
> @co-authors: Please check if you agree with my proposed resolutions.
> 
> /Ludwig
> 
> On 30/07/2019 17:56, Benjamin Kaduk wrote:
> > We should be consistent across examples about whether the use of CBOR
> > diagnostic notation also requires a disclaimer about "with linebreaks
> > for readability".
> 
> As far as I gather from the comments (especially from Carsten), we'd 
> solve this by referencing section 6 of RFC 7049. I will consult with my 
> co-authors, but I think this is the right solution.

I think Carsten's followup refers to
https://mailarchive.ietf.org/arch/msg/ace/y_fPgWe-m8B2OpJChQ1qhoURuPU which
says to refer to RFC 8610 (or Appendix G thereof).  And to be clear, my
original point was just that we cannot have some examples say "with
linebreaks for readability" and some not, within the same document, but I
did not attempt to propose which variant to unify to.

> > 
> > Section 2
> > 
> > Presenter
> >Party that proves possession of a private key (for asymmetric key
> >cryptography) or secret key (for symmetric key cryptography) to a
> >recipient.
> > 
> > nit: it might be worth either capitalizing Recipient to point to the
> > following item more clearly, or specifying "recipient of a CWT" for
> > parallelism with Recipient.
> > (If we do the former we should capitalize Presenter in the following
> > definition.  But since we don't use the capitalized terms throughout the
> > text, it wouldn't be my own preference.)
> > 
> Ok I'll go for "recipient of a CWT"
> 
> > Section 3.2
> > 
> > This example key expired in 2013.  While the example will "always" be
> > expired for an archival document, it might be worth making it more
> > timely with respect to the publication date.  (This holds for basically
> > all time values in the document's examples.)
> > 
> > Value 2 for 'kty' should have diagnostic notation /EC2/, not /EC/.
> > 
> > [I did not check that the example x and y coordinates are in fact points
> > on P256.]
> 
> I agree this should be updated.
> 
> 
> > 
> > The "COSE_Key" member MAY also be used for a COSE_Key representing a
> > symmetric key, provided that the CWT is encrypted so that the key is
> > not revealed to unintended parties.  The means of encrypting a CWT is
> > explained in [RFC8392].  If the CWT is not encrypted, the symmetric
> > key MUST be encrypted as described in Section 3.3.
> > 
> > It's hard for me to escape the conclusion that this paragraph needs to
> > be a dedicated section with a bit more discussion about how exactly this
> > usage is performed and encoded.
> > 
> 
> This mirrors the corresponding procedure in RFC 7800. Would it be OK to 
> just refer to that document 
> (https://tools.ietf.org/html/rfc7800#section-3 or actually 3.3)?

(Section 3.2, it seems -- JWT and CWT cover aysmmetric and symmetric in
the opposite order.)
Well, I still wouldn't like it.  But I don't think I have grounds to block
the document from advancing if you just refer back to JWT.

> 
> > Section 3.3
> > 
> > Is the /HMAC256/ the conventional diagnostic notation for alg value 5
> > (noting that RFC 8152 calls it both "HMAC256/256" and "HMAC w/ SHA-256")?
> > 
> 
> I agree with Jim's suggestion to use HMAC256/256

Works for me.  (This was an honest question, as opposed to those other
times when I think I know the answer already but want to leave open the
possibility of being wrong.)

> 
> > The following example CWT Claims Set of a CWT (using CBOR diagnostic
> > notation, with linebreaks for readability) illustrates the use of an
> > encrypted symmetric key as the "Encrypted_COSE_Key" member value:
> > 
> >{
> > /iss/ 1 : "coaps://server.example.com",
> > /sub/ 2 : "24400320",
> > /aud/ 3: "s6BhdRkqt3",
> > /exp/ 4 : 1311281970,
> > /iat/ 5 : 1311280970,
> > /cnf/ 8 : {
> > /COSE_Encrypt0/ 2 : [
> > 
> > Should this be "/Encrypted_COSE_Key/" and not "/COSE_Enrypt0/"?
> > 
> > [I did not validate the COSE_Encrypt0 output]
> >
> 
> COSE_Encrypt0 is a defined construct of COSE, while Encrypted_COSE_Key 
> is not. We'd have to define it or write an explanatory comment.

Maybe I'm confused about how the diagnostic notation works, but the
top-level CWT map 

Re: [Ace] AD review of draft-ietf-ace-coap-est-12

[Benjamin Kaduk]

I'll try to respond to Peter and Jim in one go.

On Fri, Aug 30, 2019 at 01:12:46PM +0200, Peter van der Stok wrote:
> HI Jim and Ben,
> 
> Ben, many thanks for a nice and elaborate  review of the draft.
> 
> beginning next week I will provide partial answers to the review.
> Some small remarks below to the much appreciated explanations by Jim.
> 
> An initial answer to the first point precedes the answers by Jim.
> 
> cheerio,
> 
> Peter
> _
> 
> Section 2
> 
>This document also profiles the use of EST to only support
>certificate-based client authentication.  HTTP Basic or Digest
>authentication (as described in Section 3.2.3 of [RFC7030]) are not
>supported.
> 
> Is the intent just to exclude HTTP-layer authentication, or to
> specifically prefer client certificate authentication?  7030 does allow
> for non-certificate TLS-layer authentication (e.g., TLS-SRP), which
> would be compatible with DTLS just fine.  There's also recurrent talk of
> getting modern PAKE(s) integrated with TLS, which might also be an
> option in the constrained space.
> [There are subsequent parts of the document that continue to assume
> only-certificates, so I'm mostly assuming that the intent is
> specifically to prefer client certificates, and have not made specific
> notes at those other places in the document.]
> 
> 
> client certificate authentication is preferred based on the following
> history:
> est_coaps was initially written as extension to anima BRSKI for small
> devices.
> In that context the only reasonable use case is client certificate
> authentication.
> In a later stage a wider audience of the document was identified beyond
> BRSKI also with a certificate authentication use case.
> The draft is limited to the certificate authentication, other
> authentications are not considered.
> I am not sure if this falls under preference of certificate
> authentication or exclusion of http layer authentication.
> If http layer authentication is wanted, my suggestion is that another
> document specifies this. This draft does not forbid the use of http
> layer authentication.
> Did I interpret your remark as you intended?
> 

Thanks for the extra background; it seems that there's reasonable
justification for the preference for certificate authentication; if a
TLS-layer password-based use case does arise, it should be possible to
write a companion document.

> Jim Schaad schreef op 2019-08-30 01:15:
> 
> > A couple of answers from my own perspective
> > 
> > -Original Message-
> > From: Ace  On Behalf Of Benjamin Kaduk
> > Sent: Wednesday, August 28, 2019 4:37 PM
> > To: draft-ietf-ace-coap-est@ietf.org
> > Cc: ace@ietf.org
> > Subject: [Ace] AD review of draft-ietf-ace-coap-est-12
> > 
> > Hi all,
> > 
> > A good number of comments here, though many are just nits.  We may need some
> > more in-depth discussion about only using certificates for client
> > authentication (immediately below) and how we discuss server-keygen.
> > 
> > Thanks,
> > 
> > Ben
> > 
> > 
> > 
> > When proof-of-possession is desired, a set of actions are required
> > regarding the use of tls-unique, described in Section 3.5 in
> > [RFC7030].  The tls-unique information consists of the contents of
> > 
> > I see the note in the shepherd writeup about converting EST to use TLS
> > exporters rather than tls-unique in a separate update document.  Where is
> > that work happening?  The discussion in Section 10.1 is helpful (and we
> > could do well to reference it from here) but does not inspire great
> > confidence in the reader that such work will come to fruition.
> > I think we also need to at least mandate extended-master-secret to be used
> > on the underlying DTLS connection.  (That is, assuming that we don't want to
> > lock down to specific, non-vulnerable, ciphersuites -- RFC 7925 only has
> > TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as MTI, not MTU.)
> > 
> > [JLS]  If this work is going to happen it needs to be done as an update to
> > the EST RFC.  I don't know if it would be better to do that in LAMPS rather
> > than here.  Currently I do not know of anybody who is going to do this.
> > This is my issue and I am willing to let it slide for the time being.
> > 
> >  I am happy with an update to LAMPS 

I don't think we'd want to do it in ACE, so LAMPS is a likely home (note
that I haven't checked with Roman).

> > In the context of CoAP, the presence and location of (path to) the
&

[Ace] AD review of draft-ietf-ace-coap-est-12

[Benjamin Kaduk]

Hi all,

A good number of comments here, though many are just nits.  We may need
some more in-depth discussion about only using certificates for client
authentication (immediately below) and how we discuss server-keygen.

Thanks,

Ben



Section 2

   This document also profiles the use of EST to only support
   certificate-based client authentication.  HTTP Basic or Digest
   authentication (as described in Section 3.2.3 of [RFC7030]) are not
   supported.

Is the intent just to exclude HTTP-layer authentication, or to
specifically prefer client certificate authentication?  7030 does allow
for non-certificate TLS-layer authentication (e.g., TLS-SRP), which
would be compatible with DTLS just fine.  There's also recurrent talk of
getting modern PAKE(s) integrated with TLS, which might also be an
option in the constrained space.
[There are subsequent parts of the document that continue to assume
only-certificates, so I'm mostly assuming that the intent is
specifically to prefer client certificates, and have not made specific
notes at those other places in the document.]

Section 4

   As per sections 3.3 and 4.4 of [RFC7925], the mandatory cipher suite

nit: I do see RFC 7925 in the subject heading, but the lead-in here is
still a bit jarring.  Without some statement in this document to that
effect, RFC 7925 is not binding on the protocol specified in this
document, so I think it's better to say something like "In accordance
with", or even to flat out state that "this document conforms to the
DTLS 1.2 profile specified in RFC 7925".

   DTLS 1.2 implementations must use the Supported Elliptic Curves and
   Supported Point Formats Extensions in [RFC8422].  Uncompressed point
   format must also be supported.  DTLS 1.3 [I-D.ietf-tls-dtls13]
   implementations differ from DTLS 1.2 because they do not support
   point format negotiation in favor of a single point format for each
   curve.  Thus, support for DTLS 1.3 does not mandate point format
   extensions and negotiation.

DTLS 1.3 uses the "supported_groups" extension in contrast to Supported
Elliptic Curves for 1.2; we should mention that disparity as well.

   o  a previously issued client certificate (e.g., an existing
  certificate issued by the EST CA); this could be a common case for
  simple re-enrollment of clients.

Is "re-enrollment" intended to cover renewal operations?

   o  a previously installed certificate (e.g., manufacturer IDevID
  [ieee802.1ar] or a certificate issued by some other party); the
  server is expected to trust that certificate.  IDevID's are

"trust" can cover a lot of things, many of which we don't really need
here; would "expected to be able to validate" suffice?

   As described in Section 2.1 of [RFC5272] proof-of-identity refers to
   a value that can be used to prove that the private key corresponding
   to the public key is in the possession of and can be used by an end-
   entity or client.  Additionally, channel-binding information can link

nit: "the certified public key", I think, since the certificate is what
binds the identity to the public key.
Also, this sentence is a bit awkward, though I don't have any concrete
rewording suggestions at present.

   When proof-of-possession is desired, a set of actions are required
   regarding the use of tls-unique, described in Section 3.5 in
   [RFC7030].  The tls-unique information consists of the contents of

I see the note in the shepherd writeup about converting EST to use TLS
exporters rather than tls-unique in a separate update document.  Where
is that work happening?  The discussion in Section 10.1 is helpful (and
we could do well to reference it from here) but does not inspire great
confidence in the reader that such work will come to fruition.
I think we also need to at least mandate extended-master-secret to be
used on the underlying DTLS connection.  (That
is, assuming that we don't want to lock down to specific,
non-vulnerable, ciphersuites -- RFC 7925 only has
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as MTI, not MTU.)

   Given that after a successful enrollment, it is more likely that a
   new EST transaction will take place after a significant amount of
   time, the DTLS connections SHOULD only be kept alive for EST messages
   that are relatively close to each other.  In some cases, like NAT
   rebinding, keeping the state of a connection is not possible when
   devices sleep for extended periods of time.  In such occasions,
   [I-D.ietf-tls-dtls-connection-id] negotiates a connection ID that can
   eliminate the need for new handshake and its additional cost.

Do we also want to mention DTLS 1.3 session resumption here as less
expensive than a full handshake?  It's not as cheap as "just keep using
the same connection ID", of course, but has somewhat different other
properties.

Section 5

   o  Simple enroll and re-enroll for a CA to sign public client
  identity key.

Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

[Benjamin Kaduk]

On Wed, Sep 04, 2019 at 09:02:06AM +0200, Peter van der Stok wrote:
> I concluded on the pruned .
> 
> Peter
> Jim Schaad schreef op 2019-09-03 20:48:
> 
> > I have pruned and tossed in  a few [JLS] comments. 
> > 
> > Jim 
> > 
> > FROM: Peter van der Stok  
> > SENT: Tuesday, September 3, 2019 5:18 AM
> > TO: Benjamin Kaduk 
> > CC: Jim Schaad ; 
> > draft-ietf-ace-coap-est@ietf.org; consulta...@vanderstok.org; 
> > ace@ietf.org
> > SUBJECT: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 
> > 
> > Hi Ben,
> > 
> > the last part of the responses to your thorough review.
> > Apart from nits you found some "nice" mistakes.
> > 
> > the openssl example make me worry a bit.
> > 
> > See below.
> > 
> > Peter
> > ___ 
> > 
> > SignedData is signed by the party that generated the private key,
> > which may be the EST server or the EST CA.  The SignedData is further
> > protected by placing it inside of a CMS EnvelopedData as explained in
> > Section 4.4.2 of [RFC7030].  In summary, the symmetrically encrypted
> > 
> >  if the SignedData is not the outermost container, then we don't care
> > what the relevant Content-Format for it is; we only care about the
> > Content-Format for the EnvelopedData. 
> > 
> >  
> > 
> > s/ SignedData is signed/SignedData, placed in the outermost container, is 
> > signed/ 
> > 
> > s/ The SignedData is further protected by placing it inside of a CMS 
> > EnvelopedData/ 
> > 
> > SignedData placed within the Enveloped Data does not need additional 
> > signing/ 
> > 
> > 
> > 
> > Also, did we explicitly consider and reject AuthEnvelopedData? 
> > 
> >  
> > 
> > Not sure about this 
> > 
> > [JLS] As a CMS person, I would consider the use of EnvelopedData and 
> > AuthEnvelopedData to be equivalent.  Which of these is used is totally 
> > dependent on what algorithm is used for encryption.  If one requires the 
> > use of AES-GCM or AES-CCM then one has no choice but to use 
> > AuthEnvelopedData.  If one wants to use AES-CCM ten one has no choice but 
> > to use EnvelopedData.  Everybody is slowly moving from EnvelopedData to 
> > AuthEnvelopedData just because everybody is changing algorithms.  I do not 
> > remember any discussions about this, but AuthEnvelopeData is generally 
> > going to be the more correct value here.   I will also note that there is a 
> > space between Enveloped and Data which is not CMS.
> > 
> > 
> > I don't do anything here
> >  

I was reading Jim as suggesting to make a change here (though exactly what
change, I'm not sure).

> > 
> > 
> > encryptedKey attribute in a KeyTransRecipientInfo structure.
> > Finally, if the asymmetric encryption key is suitable for key
> > agreement, the generated private key is encrypted with a symmetric
> > key which is encrypted by the client defined (in the CSR) asymmetric
> > 
> > In the key-agreement case, the symmetric key-encryption key is the
> > result of the key-agreement operation, no?  In which case it is not
> > itself encrypted, but rather the server's ephemeral public value is
> > sent. 
> > 
> >  
> > 
> > In RFC7030 the text says: the EnvelopedData content is encrypted using a 
> > randomly 
> > 
> > generated symmetric encryption key (that means ephemeral I assume). The 
> > cryptographic strength of 
> > 
> > the symmetric encryption key SHOULD be equivalent to the clientspecified 
> > 
> > asymmetric key. 
> > 
> > However, I see no explicit relation with the ephemeral public value. 
> > 
> > I don't know what to do here; probably insert the 7030 text. 
> > 
> > [JLS] Ben, you do not have the correct view of the key-agreement case.  It 
> > does a key agreement -> KDF -> KeyWrap -> Content.  There is always a key 
> > wrap step between the key agreement and the content encryption key.
> > 
> > Also here I see no room for improvement then.
> >  
> > 
> > 
> > 
> > public key and is carried in an recipientEncryptedKeys attribute in a
> > KeyAgreeRecipientInfo.
> > 
> > [RFC7030] recommends the use of additional encryption of the returned
> > private key.  For the context of this specification, clients and
> > servers that choose to support server-side key generation MUST
> > support unprotected (PKCS#8) private keys (Content-Format 28

Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

[Benjamin Kaduk]

Hi Jim,

Thanks for taking a closer look.  It's been a long week, so I'm not sure if
you're saying that I was doing the decoding wrong, expecting the wrong
structure, or both.

-Ben

On Wed, Sep 04, 2019 at 11:02:31AM -0700, Jim Schaad wrote:
> Let me draw back and re-address the comment from Ben about the private key in 
> appendix A.3
> 
>  
> 
> If I take 
> 
>  
> 
> 308187020100301306072a8648ce3d020106082a8648ce3d030107046d30
> 
> 6b02010104200b9a67785b65e07360b6d28cfc1d3f3925c0755799deeca7
> 
> 45372b01697bd8a6a144034200041bb8c1117896f98e4506c03d70efbe82
> 
> 0d8e38ea97e9d65d52c8460c5852c51dd89a61370a2843760fc859799d78
> 
> cd33f3c1846e304f1717f8123f1a284cc99f
> 
>  
> 
> and decode it I get (with comments from me)
> 
>  
> 
> SEQUENCE (3 elem)-- OneAsymmetricKey (replacement of PKCS #8)
> 
>   INTEGER 0   -- Version = v1
> 
>   SEQUENCE (2 elem)  -- privateKeyAlgorithm
> 
> OBJECT IDENTIFIER 1.2.840.10045.2.1 ecPublicKey (ANSI X9.62 public key 
> type)  -- Alg ID
> 
> OBJECT IDENTIFIER 1.2.840.10045.3.1.7 prime256v1 (ANSI X9.62 named 
> elliptic curve) – Parameters == P256
> 
>   OCTET STRING (1 elem) – Private Key
> 
> SEQUENCE (3 elem) – ECPrivate Key  [RFC 5915]
> 
>   INTEGER 1 – Version – ecPrivkeyVer1
> 
>   OCTET STRING (32 byte) 
> 0B9A67785B65E07360B6D28CFC1D3F3925C0755799DEECA745372B01697BD8A6 – Private 
> Key value
> 
>   [1] (1 elem) – Public key value
> 
> BIT STRING (520 bit) 
> 01011011101110001101000100010000100101101001100011…
> 
>  
> 
>  
> 
> This looks correct to me.
> 
>  
> 
> Jim
> 
>  
> 
>  
> 
>  
> 
>  
> 
> From: Peter van der Stok  
> Sent: Wednesday, September 4, 2019 12:02 AM
> To: Jim Schaad 
> Cc: consulta...@vanderstok.org; 'Benjamin Kaduk' ; 
> draft-ietf-ace-coap-est@ietf.org; ace@ietf.org
> Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
> 
>  
> 
> I concluded on the pruned .
> 
> Peter
> 
> Jim Schaad schreef op 2019-09-03 20:48:
> 
> I have pruned and tossed in  a few [JLS] comments.
> 
>  
> 
> Jim
> 
>  
> 
>  
> 
> From: Peter van der Stok mailto:stokc...@bbhmail.nl> > 
> Sent: Tuesday, September 3, 2019 5:18 AM
> To: Benjamin Kaduk mailto:ka...@mit.edu> >
> Cc: Jim Schaad mailto:i...@augustcellars.com> >; 
> draft-ietf-ace-coap-est@ietf.org 
> <mailto:draft-ietf-ace-coap-est@ietf.org> ; consulta...@vanderstok.org 
> <mailto:consulta...@vanderstok.org> ; ace@ietf.org <mailto:ace@ietf.org> 
> Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
> 
>  
> 
> Hi Ben,
> 
> the last part of the responses to your thorough review.
> Apart from nits you found some "nice" mistakes.
> 
> the openssl example make me worry a bit.
> 
> See below.
> 
> Peter
> ___
> 
> 
>SignedData is signed by the party that generated the private key,
>which may be the EST server or the EST CA.  The SignedData is further
>protected by placing it inside of a CMS EnvelopedData as explained in
>Section 4.4.2 of [RFC7030].  In summary, the symmetrically encrypted
> 
>  if the SignedData is not the outermost container, then we don't care
> what the relevant Content-Format for it is; we only care about the
> Content-Format for the EnvelopedData.
> 
> 
> 
> s/ SignedData is signed/SignedData, placed in the outermost container, is 
> signed/
> 
> s/ The SignedData is further protected by placing it inside of a CMS 
> EnvelopedData/
> 
> SignedData placed within the Enveloped Data does not need additional signing/
> 
> 
> 
> Also, did we explicitly consider and reject AuthEnvelopedData?
> 
> 
> 
> Not sure about this
> 
> [JLS] As a CMS person, I would consider the use of EnvelopedData and 
> AuthEnvelopedData to be equivalent.  Which of these is used is totally 
> dependent on what algorithm is used for encryption.  If one requires the use 
> of AES-GCM or AES-CCM then one has no choice but to use AuthEnvelopedData.  
> If one wants to use AES-CCM ten one has no choice but to use EnvelopedData.  
> Everybody is slowly moving from EnvelopedData to AuthEnvelopedData just 
> because everybody is changing algorithms.  I do not remember any discussions 
> about this, but AuthEnvelopeData is generally going to be the more correct 
> value here.   I will also note that there is a space between Enveloped and 
> Data which is not CMS.
> 
> 
> I don't do anything here
> 
> 
> 
> 
> 
> 
&g

Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

[Benjamin Kaduk]

On Mon, Sep 09, 2019 at 05:38:23PM +0100, Michael Richardson wrote:
> 
> Benjamin Kaduk  wrote:
> >> I think that we could go to TLS Exporter right now, but it would take
> >> some work.
> 
> > I'd rather have both classic-EST and coap-EST benefit than just
> > coap-EST.
> 
> So you'd agree to deferring this to a document (maybe in LAMPS?) that would
> Updates: 7030 and this document.

Right.

-Ben

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

Re: [Ace] AD review of draft-ietf-ace-coap-est-12

[Benjamin Kaduk]

On Mon, Sep 02, 2019 at 02:47:10PM +0200, Peter van der Stok wrote:
> Hi Ben,
> 
> Below some additional reactions to your review.
> In some parts the term "suggest" is used, meaning that I am not sure of
> the correctness of my reaction.
> A confirmation/denial would be appreciated in those cases.

Okay, I'll try to remark at those locations, and sorry for not trimming
stuff without comments.

> My co-authors can always improve my changes.
> 
> To-morrow I hope to do the follow-up.
> 
> many thanks,
> 
> peter
> 
> 
> 
> Section 4
> 
>As per sections 3.3 and 4.4 of [RFC7925], the mandatory cipher suite
> 
> nit: I do see RFC 7925 in the subject heading, but the lead-in here is
> still a bit jarring.  Without some statement in this document to that
> effect, RFC 7925 is not binding on the protocol specified in this
> document, so I think it's better to say something like "In accordance
> with", or even to flat out state that "this document conforms to the
> DTLS 1.2 profile specified in RFC 7925". 
> 
>  done, used: In accordance with sections …  
> 
>DTLS 1.2 implementations must use the Supported Elliptic Curves and
>Supported Point Formats Extensions in [RFC8422].  Uncompressed point
>format must also be supported.  DTLS 1.3 [I-D.ietf-tls-dtls13]
>implementations differ from DTLS 1.2 because they do not support
>point format negotiation in favor of a single point format for each
>curve.  Thus, support for DTLS 1.3 does not mandate point format
>extensions and negotiation.
> 
> DTLS 1.3 uses the "supported_groups" extension in contrast to Supported
> Elliptic Curves for 1.2; we should mention that disparity as well. 
> 
>  added at the end of the paragraph  
> 
>o  a previously issued client certificate (e.g., an existing
>   certificate issued by the EST CA); this could be a common case for
>   simple re-enrollment of clients.
> 
> Is "re-enrollment" intended to cover renewal operations? 
> 
> RFC7030 states: "An EST client can renew/rekey its existing client
> certificate by 
> 
> submitting a re-enrollment request to an EST server."
> 
> Do you want that emphasized more in the draft?

I don't think it's necessary; thanks for finding the right 7030 quote to
quiet me up.

> 
> 
>o  a previously installed certificate (e.g., manufacturer IDevID
>   [ieee802.1ar] or a certificate issued by some other party); the
>   server is expected to trust that certificate.  IDevID's are
> 
> "trust" can cover a lot of things, many of which we don't really need
> here; would "expected to be able to validate" suffice? 
> 
>  s/is expected to trust that certificate/ can use the certificate
> for DTLS client Authentication/
> 
> 
>As described in Section 2.1 of [RFC5272] proof-of-identity refers to
>a value that can be used to prove that the private key corresponding
>to the public key is in the possession of and can be used by an end-
>entity or client.  Additionally, channel-binding information can link
> 
> nit: "the certified public key", I think, since the certificate is what
> binds the identity to the public key.
> Also, this sentence is a bit awkward, though I don't have any concrete
> rewording suggestions at present. 
> 
> s/public key/certified public key/ 
> 
> Suggestion, is this better?: "a client provides proof of identity by
> proving that it possesses the private key corresponding with the
> certified public key" 
> 
>Given that after a successful enrollment, it is more likely that a
>new EST transaction will take place after a significant amount of
>time, the DTLS connections SHOULD only be kept alive for EST messages
>that are relatively close to each other.  In some cases, like NAT
>rebinding, keeping the state of a connection is not possible when
>devices sleep for extended periods of time.  In such occasions,
>[I-D.ietf-tls-dtls-connection-id] negotiates a connection ID that can
>eliminate the need for new handshake and its additional cost.
> 
> Do we also want to mention DTLS 1.3 session resumption here as less
> expensive than a full handshake?  It's not as cheap as "just keep using
> the same connection ID", of course, but has somewhat different other
> properties. 
> 
>  thanks, added: 
> 
> "additional cost; or DTLS 1.3 session resumption provides a less costly
> alternative than re-doing a full DTLS handshake."
> 
> 
> Section 5
> 
>o  Simple enroll and re-enroll for a CA to sign public client
>   identity key.
> 
> nit(?): is this "public client identity key" or "client identity public
> key" or something else? 
> 
> by reducing the txt's target, I suggest: 
> 
> s/public client identity key/client certificate/ 

That seems to work.

> 
> 
>o  Certificate Signing Request (CSR) attribute messages that inform
>   the client of the fields to include in a CSR.
> 
> nit: "informs" 
> 
>  yep, thanks 
> 
>o  

Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

[Benjamin Kaduk]

[trimming]
On Tue, Sep 03, 2019 at 02:18:22PM +0200, Peter van der Stok wrote:
> 
>[RFC7030] recommends the use of additional encryption of the returned
>private key.  For the context of this specification, clients and
>servers that choose to support server-side key generation MUST
>support unprotected (PKCS#8) private keys (Content-Format 284).
>Symmetric or asymmetric encryption of the private key (CMS
>EnvelopedData, Content-Format 280) SHOULD be supported for
>deployments where end-to-end encryption needs to be provided between
>the client and a server.  Such cases could include architectures
>where an entity between the client and the CA terminates the DTLS
>connection (Registrar in Figure 4).
> 
> This carefully says nothing about recommendations for use, only for
> software support.  Are we letting 7030's recommendation for use of
> encryption stand?  It's probably worth being explicit, either way. 
> 
>  I did not find any recommendation for use in RFC7030 apart the
> responsibility of the server for generating random numbers. The
> recommendations at the top of section 5.8 of the draft seem adequate in
> my opinion. The alternative is classifying the applications; unless you
> see a better way to do this. 

I think the 7030 text I was thinking of is this:

   It is strongly RECOMMENDED that the clients request that the returned
   private key be afforded the additional security of the Cryptographic
   Message Syntax (CMS) EnvelopedData in addition to the TLS-provided
   security to protect against unauthorized disclosure.

> 
> 
> 
[...]
> 
>It is recommended, based on experiments, to follow the default CoAP
>configuration parameters ([RFC7252]).  However, depending on the
>implementation scenario, retransmissions and timeouts can also occur
>on other networking layers, governed by other configuration
>parameters.  A change in a server parameter MUST ensure the adjusted
>value is also available to all the endpoints with which these
>adjusted values are to be used to communicate.
> 
> I don't understand who this is a normative requirement upon.  Is it the
> network operator's, to propagate configuration changes?  Or is there
> supposed to be some automated protocol that makes adjusted values
> available? 
> 
>  
> 
> It is meant as reminder to anyone doing the configuration of a given
> installation; you want to suppress the text? 

I don't want to suppress it, no.

Maybe "A configuration change in a server parameter MUST be coordinated
with all the endpoints with which these adjusted values are to be used to
communicate"?  Though I guess "coordinate" does not necessarily force the
other endpoint to be using the identical value, just to know about it.

> 
> 
[...]
> 
> Appendix A.1
> 
>  Option (Uri-Port)
> Option Delta = 0x4  (option# 3+4=7)
> Option Length = 0x4
> Option Value = 9085
>   Option (Uri-Path)
> Option Delta = 0x4   (option# 7+4=11)
> Option Length = 0x5
> Option Value = "est"
> 
> This is more for my own edification than the document's sake, so thank
> you for your time, but what accounts for the "extra" length here?  The
> "est" is three bytes, and what makes up for the other two?  Also, I
> assume that the port value of 9805 is the decimal value, which gets
> CBOR encoded into two bytes  of integer encoding plus the byte with
> additional information 25 to indicate the two-byte integer, and another
> byte that I need help accounting for. 
> 
>  
> 
> Many thanks; an old misreading of an example in 7252. 
> 
> For the option length of URI-Path we included the quotations as well;
> That is WRONG. 
> 
> Repaired it everywhere. 
> 
> Options are not CBOR encoded. 

Well, now I'm glad I asked -- thanks!

> 
> 
> Appendix A.2
> 
> Do we want to say anything about the IDevID in the CSR/cert?
> I note that the breakdown in Appendix C.2 (looks like openssl output)
> does not decode the otherName (though asn1parse can be convinced to do
> so). 
> 
>  
> 
> What do you suggest for IDevID? 

If we were going to add something (which remains unclear to me), it could
be after the sentence "[...] the CSR contains a ChallengePassword which is
used for POP linking (Section 4).", and be something like "This CSR also
contains an RFC 7299 id-on-hardwareModuleName hardware identifier to
customize the returned certificate to the requesting device."
(The actual identifier here is the same one mentioned in
https://www.mail-archive.com/anima@ietf.org/msg00938.html, from Bob
Moskowitz's OID arc.)

> Actually openssl was used extensively for generating the examples. 
> 
> Will be happy to learn about otherName 

otherName is an OID-indexed generic name container for the cert; it's a
form of subjectAltName.  What I did here was:

~$ unhex|openssl asn1parse -inform der
   3082018b30820131020100305c310b3009060355040613025553310b3009
   

Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

[Benjamin Kaduk]

On Mon, Sep 09, 2019 at 12:54:12PM +0100, Michael Richardson wrote:
> 
> Peter van der Stok  wrote:
> > . if the SignedData is not the outermost container, then we don't
> > care what the relevant Content-Format for it is; we only care about the
> > Content-Format for the EnvelopedData.
> 
> > 
> 
> > s/ SignedData is signed/SignedData, placed in the outermost container,
> > is signed/
> 
> > s/ The SignedData is further protected by placing it inside of a CMS
> > EnvelopedData/
> 
> > SignedData placed within the Enveloped Data does not need additional
> > signing/
> 
> > 
> 
> > Also, did we explicitly consider and reject AuthEnvelopedData?
> 
> > 
> 
> > Not sure about this
> 
> Jim Schaad  wrote:
> > [JLS] As a CMS person, I would consider the use of EnvelopedData and
> > AuthEnvelopedData to be equivalent.  Which of these is used is totally
> > dependent on what algorithm is used for encryption.  If one requires
> > the use of AES-GCM or AES-CCM then one has no choice but to use
> > AuthEnvelopedData.  If one wants to use AES-CCM ten one has no choice
> > but to use EnvelopedData.  Everybody is slowly moving from
> > EnvelopedData to AuthEnvelopedData just because everybody is changing
> > algorithms.  I do not remember any discussions about this, but
> > AuthEnvelopeData is generally going to be the more correct value here.
> > I will also note that there is a space between Enveloped and Data which
> > is not CMS.
> > 
> 
> So, on a constrained device, I'd like to know what to expect (what to code
> for).  While I do'nt particularly care for server-generated keys, it should
> probably be specified correctly.  I see that the complexity of sorting this
> means that I think that Content-Format 284 (unprotected) will get used most
> often.

Your constrained device is probably only going to implement one cipher
[mode], too, right?  If it's an AEAD mode, you use AuthEnvelopedData;
otherwise, classic EnvelopedData.

> Is there a good reference that would let us rip out more of this paragraph?

We seem to have dropped enough quoting that there's not any paragraph here
that's in the current document :)

> > This carefully says nothing about recommendations for use, only for
> > software support.  Are we letting 7030's recommendation for use of
> > encryption stand?  It's probably worth being explicit, either way.
> 
> Server-side key generation is optional, but when used, I agree that the
> question of which mechanism the server should use to return the key is
> completely open.   The client can indicate what it supports via CoAP Accept
> "header".  https://datatracker.ietf.org/doc/draft-amsuess-core-accept-any/
> might be useful here.

That seems like a good point.

> >  I did not find any recommendation for use in RFC7030 apart the
> > responsibility of the server for generating random numbers. The
> > recommendations at the top of section 5.8 of the draft seem adequate in
> > my opinion. The alternative is classifying the applications; unless you
> > see a better way to do this.
> 
> > 
> 
> > Why OPTIONAL?  (Also, nit: OPTIONALLY isn't a 2119 keyword; only
> > OPTIONAL.)
> 
> >client.  For example, it could be configured to accept POP linking
> > information that does not match the current TLS session because the
> > authenticated EST client Registrar has verified this information when
> > acting as an EST server.
> 
> > This is close enough to a literal quote that we might think about
> > actually quoting and using quotation marks.  nit: s/POP/PoP/ if we
> > don't do the literal quote.
> 
> > 
> 
> > Hope my co-authors will react to this
> 
> > [JLS] I would disagree with the nit.
> 
> > [JLS] I would agree with the nit on OPTIONALLY being wrong, but I think
> > that it ought to be at least a SHOULD if not a MUST for the use of
> > COAPS as it is terminating the connection.  The only exception would be
> > in there is internal authentication for the EST request.
> 
> > 
> 
> 
> Okay, I'm seeing three things here.
> 1) tls-unique can't be used across the proxy, and we need additional
>configuration.  I don't think we should quote literally, I think the
>point is to hammer the point home.
> 
> 2) You are saying that we should replace tls-unique (RFC5929) with a TLS
>Exporter. But RFC7030 didn't reference RFC5705.
>You are suggesting that we update ourselves to use RFC5705.
>That would seem to require that we change some PKIX things in CSR.

>From a crypto perspective, we should do that.  From a
protocol-specification perspective, we should retain parity with classic
EST and only update when it does.  So we should probably mostly ignore this
other than trying to kick off work on classic EST, and mandating
extended-master-secret.

> 3) I'm wondering if we need to have a clear 

Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06

[Benjamin Kaduk]

Noting that there are several points that Jim left to the authors to reply
to, also inline...

On Tue, Jul 30, 2019 at 10:10:12AM -0700, Jim Schaad wrote:
> Comments inline.
> 
> -Original Message-
> From: Benjamin Kaduk  
> Sent: Tuesday, July 30, 2019 8:56 AM
> To: draft-ietf-ace-cwt-proof-of-possession@ietf.org
> Cc: ace@ietf.org
> Subject: AD review of draft-ietf-ace-cwt-proof-of-possession-06
> 
> We should be consistent across examples about whether the use of CBOR
> diagnostic notation also requires a disclaimer about "with linebreaks for
> readability".
> 
> [JLS] I don't believe that this disclaimer needs to be present.  Unlike the
> JSON document where what is being presented is in fact JSON, what is being
> presented here is simply a more user friendly readable version of the binary
> data.  (A different question would be if the hex should be presented but
> that is not what the ACE group is doing in general.)

Taking it out is fine by me; I just want us to be internally consistent :)

> Section 2
> 
>Presenter
>   Party that proves possession of a private key (for asymmetric key
>   cryptography) or secret key (for symmetric key cryptography) to a
>   recipient.
> 
> nit: it might be worth either capitalizing Recipient to point to the
> following item more clearly, or specifying "recipient of a CWT" for
> parallelism with Recipient.
> (If we do the former we should capitalize Presenter in the following
> definition.  But since we don't use the capitalized terms throughout the
> text, it wouldn't be my own preference.)
> 
> Section 3.2
> 
> This example key expired in 2013.  While the example will "always" be
> expired for an archival document, it might be worth making it more timely
> with respect to the publication date.  (This holds for basically all time
> values in the document's examples.)
> 
> Value 2 for 'kty' should have diagnostic notation /EC2/, not /EC/.
> 
> [I did not check that the example x and y coordinates are in fact points on
> P256.]
> 
>The "COSE_Key" member MAY also be used for a COSE_Key representing a
>symmetric key, provided that the CWT is encrypted so that the key is
>not revealed to unintended parties.  The means of encrypting a CWT is
>explained in [RFC8392].  If the CWT is not encrypted, the symmetric
>key MUST be encrypted as described in Section 3.3.
> 
> It's hard for me to escape the conclusion that this paragraph needs to be a
> dedicated section with a bit more discussion about how exactly this usage is
> performed and encoded.
> 
> Section 3.3
> 
> Is the /HMAC256/ the conventional diagnostic notation for alg value 5
> (noting that RFC 8152 calls it both "HMAC256/256" and "HMAC w/ SHA-256")?
> 
> [JLS] HMAC 256/256 is the algorithm name while HMAC w/ SHA-256 is
> descriptive.  I believe that this is completely consistent in RFC 8152.

Er, I'm not sure what you're saying is best to use in the diagnostic
notation.

>The following example CWT Claims Set of a CWT (using CBOR diagnostic
>notation, with linebreaks for readability) illustrates the use of an
>encrypted symmetric key as the "Encrypted_COSE_Key" member value:
> 
>   {
>/iss/ 1 : "coaps://server.example.com",
>/sub/ 2 : "24400320",
>/aud/ 3: "s6BhdRkqt3",
>/exp/ 4 : 1311281970,
>/iat/ 5 : 1311280970,
>/cnf/ 8 : {
>/COSE_Encrypt0/ 2 : [
> 
> Should this be "/Encrypted_COSE_Key/" and not "/COSE_Enrypt0/"?
> 
> [I did not validate the COSE_Encrypt0 output]
> 
> Section 3.4
> 
>  {
>   /iss/ 1 : "coaps://server.example.com",
>   /aud/ 3 : "coaps://client.example.org",
> 
> Is it in any way confusing to use client.example.org as opposed to, say,
> resource.example.org as the audience?
> 
>   /exp/ 4 : 1361398824,
>   /cnf/ 8 : {
> /kid/ 2 : h'dfd1aa976d8d4575a0fe34b96de2bfad'
> 
> /kid/ in the 'cnf' map has key 3, not 2.
> 
>Note that the use of a Key ID to identify a proof-of-possesion key
>needs to be carefully circumscribed, as described below and in
>Section 6.  Where the Key ID is not a cryptographic value derived
>from the key or where all of the parties involved are not validating
>the cryptographic derivation, it is possible to get into situations
>where the same Key ID is being used for multiple keys.  The
> 
> I don't think this quite covers the needed properties, since we also need
> some assurance that all parties are interpreting the kid value in the same
> way. It may be possible to construct such a scenario via a

[Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06

[Benjamin Kaduk]

We should be consistent across examples about whether the use of CBOR
diagnostic notation also requires a disclaimer about "with linebreaks
for readability".

Section 2

   Presenter
  Party that proves possession of a private key (for asymmetric key
  cryptography) or secret key (for symmetric key cryptography) to a
  recipient.

nit: it might be worth either capitalizing Recipient to point to the
following item more clearly, or specifying "recipient of a CWT" for
parallelism with Recipient.
(If we do the former we should capitalize Presenter in the following
definition.  But since we don't use the capitalized terms throughout the
text, it wouldn't be my own preference.)

Section 3.2

This example key expired in 2013.  While the example will "always" be
expired for an archival document, it might be worth making it more
timely with respect to the publication date.  (This holds for basically
all time values in the document's examples.)

Value 2 for 'kty' should have diagnostic notation /EC2/, not /EC/.

[I did not check that the example x and y coordinates are in fact points
on P256.]

   The "COSE_Key" member MAY also be used for a COSE_Key representing a
   symmetric key, provided that the CWT is encrypted so that the key is
   not revealed to unintended parties.  The means of encrypting a CWT is
   explained in [RFC8392].  If the CWT is not encrypted, the symmetric
   key MUST be encrypted as described in Section 3.3.

It's hard for me to escape the conclusion that this paragraph needs to
be a dedicated section with a bit more discussion about how exactly this
usage is performed and encoded.

Section 3.3

Is the /HMAC256/ the conventional diagnostic notation for alg value 5
(noting that RFC 8152 calls it both "HMAC256/256" and "HMAC w/ SHA-256")?

   The following example CWT Claims Set of a CWT (using CBOR diagnostic
   notation, with linebreaks for readability) illustrates the use of an
   encrypted symmetric key as the "Encrypted_COSE_Key" member value:

  {
   /iss/ 1 : "coaps://server.example.com",
   /sub/ 2 : "24400320",
   /aud/ 3: "s6BhdRkqt3",
   /exp/ 4 : 1311281970,
   /iat/ 5 : 1311280970,
   /cnf/ 8 : {
   /COSE_Encrypt0/ 2 : [

Should this be "/Encrypted_COSE_Key/" and not "/COSE_Enrypt0/"?

[I did not validate the COSE_Encrypt0 output]

Section 3.4

 {
  /iss/ 1 : "coaps://server.example.com",
  /aud/ 3 : "coaps://client.example.org",

Is it in any way confusing to use client.example.org as opposed to, say,
resource.example.org as the audience?

  /exp/ 4 : 1361398824,
  /cnf/ 8 : {
/kid/ 2 : h'dfd1aa976d8d4575a0fe34b96de2bfad'

/kid/ in the 'cnf' map has key 3, not 2.

   Note that the use of a Key ID to identify a proof-of-possesion key
   needs to be carefully circumscribed, as described below and in
   Section 6.  Where the Key ID is not a cryptographic value derived
   from the key or where all of the parties involved are not validating
   the cryptographic derivation, it is possible to get into situations
   where the same Key ID is being used for multiple keys.  The

I don't think this quite covers the needed properties, since we also
need some assurance that all parties are interpreting the kid value in
the same way. It may be possible to construct such a scenario via an
attacker replaying a stolen token or even just inadvertent confusion by
some party (quite plausible when we consider scenarios that involve the
same key being described by different 'kid' values in messages with
different recipients).  In particular, if the situation arises where an
attacker is able to choose the 'kid' value that will be used, they could
deliberately cause a collision with a legitimate value used by some
other party.

   In the world of constrained Internet of Things (IoT) devices, there
   is frequently a restriction on the size of Key IDs, either because of
   table constraints or a desire to keep message sizes small.  These
   restrictions are going to protocol dependent.  For example, DTLS can

nit: "going to be" or maybe even just "are protocol dependent".

   use a Key ID of any size.  However, if the key is being used with
   COSE encrypted message, then the length of the key needs to be
   minimized and may have a limit as small as one byte.

nit: is this "length of the key" or "length of the key ID"?

   Note that the value of a Key ID is not always the same for different
   parties.  When sending a COSE encrypted message with a shared key,
   the Key ID may be different on both sides of the conversation, with
   the appropriate one being included in the message based on the
   recipient of the message.

While this recipient-dependence is probably unavoidable (as the
requisite namespacing would use more space on the wire than is
reasonable for many applications), it does merit some security
considerations text, noting that such messages are context-dependant and
could be misinterpreted if presented in a different context.
Audience restrictions, as 

Re: [Ace] AD review of draft-ietf-ace-oauth-authz-24

[Benjamin Kaduk]

On Fri, Sep 27, 2019 at 03:22:45AM -0700, Jim Schaad wrote:
> 
> 
> -Original Message-
> From: Ludwig Seitz  
> Sent: Friday, September 27, 2019 12:03 AM
> To: Benjamin Kaduk ; draft-ietf-ace-oauth-authz@ietf.org
> Cc: ace@ietf.org
> Subject: Re: AD review of draft-ietf-ace-oauth-authz-24
> 
> On 27/09/2019 03:51, Benjamin Kaduk wrote:
> > Hi all,
> > 
> > The length of this review notwithstanding, this document is generally in
> > good shape -- there's a bunch of localized items to tighten up, and we
> > can flesh out the security considerations some more, but nothing too
> > drastic should be needed.  Perhaps the most far-reaching changes needed
> > will be to rename the "profile" claim, since that has already been
> > allocated to OIDC Core for a very different usage.  I also made a pull
> > request with a bunch of trivial editorial stuff that's easier to fix
> > than describe how to fix, up at
> > https://github.com/ace-wg/ace-oauth/pull/175 .
> > 
> 
> I have a non-trivial comment on your pull request: In appendix B we 
> summarize the steps taken by an RS to process a freshly received access 
> token. You changed the suggested sequence from:

First off, thank you for spotting it and bringing the discussion here!  I'm
sorry that you had to do so; I wasn't trying to sneak it in :)

> * Verify the token is from a recognized AS.
> * Verify that the token applies to this RS.
> * Check that the token has not expired (if the token provides expiration 
> information).
> * Check the token's integrity.
> * Store the token so that it can be retrieved in the context of a 
> matching request.
> 
> To
> 
> * Verify the token is from a recognized AS.
> * Check the token's integrity.
> * Verify that the token applies to this RS.
> * Check that the token has not expired (if the token provides expiration 
> information).
> * Store the token so that it can be retrieved in the context of a 
> matching request.
> 
> 
> I don't think this is a big deal, but I put the integrity check later 
> for a good reason (or so I believe): The integrity check is a 
> potentially expensive cryptographic operation. Checking that the token 
> applies to the RS is a matter of checking the audience claim, and 
> checking that the token is not expired is a matter of comparing two 
> timestamps, I consider both to be computationally much lighter and 
> therefore quicker to execute. A failure of any of those two may make it 
> unnecessary to verify the token integrity.
> 
> BUT! My suggested sequence only works if the token is signed or MACed 
> and not if it is encrypted. If the token is encrypted the AEAD integrity 
> check (and decryption) is necessarily the first processing step.
> 
> Any ideas how to resolve this gracefully (i.e. without adding a large 
> amount of text) are most welcome.
> 
> [JLS] I normally get out of this type of problem by saying "The order of the 
> steps is not normative, any process which produces an equivalent result can 
> be used."  And then you can add a comment about switching the two steps for 
> signed items.

That seems like a reasonable approach.  FWIW, my thinking was that
signature validation is a great way to toss out a bunch of malformed input,
and we tend to do it first in non-constrained environments, but I can see
the tradeoff running the other way in some cases.

-Ben

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

[Ace] AD review of draft-ietf-ace-oauth-authz-24

[Benjamin Kaduk]

Hi all,

The length of this review notwithstanding, this document is generally in
good shape -- there's a bunch of localized items to tighten up, and we
can flesh out the security considerations some more, but nothing too
drastic should be needed.  Perhaps the most far-reaching changes needed
will be to rename the "profile" claim, since that has already been
allocated to OIDC Core for a very different usage.  I also made a pull
request with a bunch of trivial editorial stuff that's easier to fix
than describe how to fix, up at
https://github.com/ace-wg/ace-oauth/pull/175 .

One general note before getting into the section-by-section comments:

There's a bunch of places where we talk about parameters that "MUST be
mapped to CBOR types as specified in Figure N"; we may want to point to
the IANA registry as authoritative and just give the figure reference
for description.

Abstract

   OAuth.  The framework is based on a set of building blocks including
   OAuth 2.0 and CoAP, thus making a well-known and widely used
   authorization solution suitable for IoT devices.  Existing

nit: It's easy to (mis)read this text as saying that just amalgamating
OAuth 2.0 and CoAP magically makes for a solution that is well-known and
widely used.  I'd suggest rewording slightly, perhaps "thus transforming
a well-known and widely used authorization solution into a form suitable
for IoT devices".

   specifications are used where possible, but where the constraints of
   IoT devices require it, extensions are added and profiles are
   defined.

nit: from a rhetorical point of view, it's probably better to reiterate
why the extensions are added and profiles defined ("to better serve the
IoT case") than to just stop with a flat declaration of what is done.

Section 1

   Authorization is the process for granting approval to an entity to
   access a resource [RFC4949].  The authorization task itself can best
   be described as granting access to a requesting client, for a
   resource hosted on a device, the resource server (RS).  This exchange

I had to pause for a while after reading this and ponder whether I
agreed with it.  I think that my reticence stems from some friction
between the most generic abstract definition of "resource" and a more
specific one used in the web/HTTP world and, to a lesser extent, the
world of URIs and URNs in general.  The resources we are discussing here
are not always specific named resources, but can also refer to
attributes or capabilities mediated by a RS; similarly, we may be
creating/modifying named resources as part of the resource access
performed by a client in the OAuth model.  I don't think it's wise to
diverge from the RFC 4949 definition just yet, but am still considering
whether adding some additional clarifying text here is worthwhile.

Section 3

It's probably worth adding (informative) references for HTTP/2, MQTT,
BLE, and QUIC.

   A fourth building block is the compact CBOR-based secure message

"compact CBOR" has the "PIN number" nature and is probably redundant.

   format COSE [RFC8152], which enables application layer security as an
   alternative or complement to transport layer security (DTLS [RFC6347]

I'm undecided whether it's better to think of this as "application layer
security" or "object-level security".

   or TLS [RFC8446]).  COSE is used to secure self-contained tokens such
   as proof-of-possession (PoP) tokens, which is an extension to the
   OAuth tokens.  The default token format is defined in CBOR web token

nit: I think there's a singular/plural mismatch in "is an extension",
which currently seems to be talking about the PoP tokens themselves.

Section 3.1

   Refresh Tokens:
  Refresh tokens are credentials used to obtain access tokens.
  Refresh tokens are issued to the client by the authorization
  server and are used to obtain a new access token when the current
  access token becomes invalid or expires, or to obtain additional
  access tokens with identical or narrower scope (access tokens may
  have a shorter lifetime and fewer permissions than authorized by
  the resource owner).  Issuing a refresh token is optional at the

nit: I'd suggest "such access tokens" in the parenthetical.

  A refresh token in OAuth 2.0 is a string representing the
  authorization granted to the client by the resource owner.  The
  string is usually opaque to the client.  The token denotes an

Apparently I'd forgotten that this couldn't be binary.

   Proof of Possession Tokens:
  An access token may be bound to a cryptographic key, which is then

Can refresh tokens not be PoP?

  The proof-of-possession (PoP) security concept assumes that the AS
  acts as a trusted third party that binds keys to access tokens.

nit: I think we're describing the PoP model used by ace, not the generic
PoP concept.

   Scopes and Permissions:
  In OAuth 2.0, the client specifies the type of permissions it is
  seeking to obtain 

Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

[Benjamin Kaduk]

Hi Panos,

Sorry for the slow response here -- I was in telechat-prep mode last week.

This is in pretty good shape, and I wanted to especially thank you for the
presentation in the github issue -- that format was extremely helpful for
me.

I think we will probably need to upload one more minor revision before I
initiate the IETF LC; please seem my comments below.


In Section 4, I think we need to put the "for" back in "requests for a
trusted certificate list".

Also, refresh my memory: did we decide that there's no need to
explicitly mandate the use of the "extended_master_secret" TLS
extension?

I'd also change the note about supported_groups vs. Supported Elliptic
Curves to read "In addition, in DTLS 1.3 the Supported Elliptic Curves
extension has been renamed to Supported Groups."

I think we can move /csrattrs to the bottom of Table 2 (thank you for
changing Table 1!).

With the changes to the example in Figure 3, can you walk me through the
block-size negotiation?  Quoting:

POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}-->
  |
   ... Immediate response when certificate is ready ...
  |
  <-- (ACK) (1:N1/0/256) (2:0/1/256) (2.04 Changed){Cert resp (frag# 1)}
POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/128)   -->
  <-- (ACK) (2:1/1/128) (2.04 Changed) {Cert resp (frag# 2)}

So the ACK to the final fragment of the POST includes (2:0/1/256), or
the first fragment of a 256-byte-fragmented version of the response.
The client then goes and asks for (2:1/0/128), which is the second
fragment of a 128-byte-fragmented version of the response.  Is that just
going to be the last 128 bytes of the thing it already got from the
server?  If so, is that something it would actually do (e.g., if it had
to drop part of the server's response due to a buffer-size limitation)
or is it not possible to only have part of a fragment (so it would need
to either ask for (2:0/0/128) or (2:2/0/128)?

It looks like you removed the text about "[the two representations] do
not have to be in a particular order since each representation is
preceded by its Content-Format ID" based on my remark about
core-multipart-ct; that document has since been approved by the IESG and
is explicitly confirming that there is no specific ordering requirement
(in contrast to multipart/mixed), so we could put that clause back in
this document if desired.

I consider it more likely than not that a directorate reviewer will want
to tweak the added language at the end of Section 5.8 explaining our
divergence from RFC 7030; if you want to preemptively reword, my
suggestion would be "Although [RFC7030] strongly recommends that clients
request the use of CMS encryption on top of the TLS channel's
protection, this document does not make such a recommendation; CMS
encryption can still be used when mandated by the use case."

Thanks!

-Ben


On Mon, Sep 16, 2019 at 05:38:59PM +, Panos Kampanakis (pkampana) wrote:
> Hi Ben,
> 
> I think we have now addressed all your feedback from the AD review. A big 
> chunk of the changes were agreed upon in the list emails threads. 
> 
> The iteration that we are planning to upload that includes all the changes is 
> at 
> https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-coap-est.txt
>  
> 
> The summary of all your comments and what went into the text is in the git 
> issue https://github.com/SanKumar2015/EST-coaps/issues/150 To break it down 
> - https://github.com/SanKumar2015/EST-coaps/issues/150#issue-489289217 has 
> most of the changes agreed on the list.
> -  
> https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-528001807 
> has an answer to your question about addressing the tls-unique issue in a new 
> draft. 
> - https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-531853281 
> has the last changes in response to your feedback that went into the draft 
> after Peter uploade the -13 iteration. 
> 
> Two places to pay attention to is that I removed the 
> >   It is strongly RECOMMENDED that the clients request that the returned
> >   private key be afforded the additional security of the Cryptographic
> >   Message Syntax (CMS) EnvelopedData in addition to the TLS-provided
> >   security to protect against unauthorized disclosure."
> and the 
> >   The corresponding longer URIs from [RFC7030] MAY be supported."
> The rationale behind that is in the git issue. 
> 
> Please have a look and let us know if there is anything missing. Otherwise we 
> will upload at the end of the week. 
> 
> Rgs,
> Panos
> 
> 
> -Original Message-
> From: Ace  On Behalf Of Panos Kampanakis (pkampana)
> Sent: Tuesday, September 10, 2019 12:18 AM
> To: Jim Schaad ; 'Mic

Re: [Ace] Mirja Kühlewind's No Objection on draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

[Benjamin Kaduk]

Just to be clear, IANA raising the issue to the IESG is described in
Section 5.3 of RFC 8126, which would be the default expectations if an
individual document/registry did not give other instructions.

-Ben

On Thu, Oct 31, 2019 at 12:13:58AM +, Mike Jones wrote:
> I'm in the process of creating -10, which addresses the IESG comments other 
> than Mirja's.  I'm reluctant to change the registration instructions, as they 
> are currently identical to those for CWTs (and many other specifications 
> going back to at least RFC 6749, modulo the name of the mailing list).  That 
> said, if the IESG *really* wants to change the party to appeal to in the case 
> of non-action from the Designated Experts from the IESG to IANA, I'm amenable 
> to also making that change tomorrow, immediately following the telechat, so 
> we can send the spec on to the RFC Editor.  Let me know what you decide.
> 
>   Thanks again,
>   -- Mike
> 
> -Original Message-
> From: Barry Leiba  
> Sent: Monday, October 28, 2019 2:00 PM
> To: Mike Jones 
> Cc: Mirja Kuehlewind ; Benjamin Kaduk ; 
> Roman D. Danyliw ; ace-cha...@ietf.org; The IESG 
> ; ace@ietf.org; draft-ietf-ace-cwt-proof-of-possess...@ietf.org
> Subject: Re: [Ace] Mirja Kühlewind's No Objection on 
> draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)
> 
> The issue isn't using a mailing list.  The issue is the instructions to IANA 
> about how to do management and tracking, stuff that they do just fine without 
> working groups trying -- will all good intentions -- to tell them how.
> 
> The fact that there are a lot of RFCs that do it just says that working 
> groups do this frequently, and most ADs don't notice or don't care.  And the 
> reality is that IANA will manage the registration process how they do it, 
> accommodating reasonable special instructions when they can.  The point is 
> that documents shouldn't be giving special instructions unless there really 
> is something special needed for a particular reason.
> 
> Barry
> 
> On Mon, Oct 28, 2019 at 12:19 PM Mike Jones  
> wrote:
> >
> > The practice of using a mailing list for registration requests to enable 
> > public visibility of them goes back at least to .well-known URI 
> > registrations 
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5785data=02%7C01%7CMichael.Jones%40microsoft.com%7C085270914a0b42e5007908d75be9e2ea%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637078932422930532sdata=bwglng9A7A8OGaV4vicvLAAcd%2FqcK7Q%2Fv9cnywn8fDo%3Dreserved=0
> >  by Mark Nottingham in April 2010.  OAuth 2.0 followed this practice in RFC 
> > 6749, as did the JOSE specs and JWT in RFCs 7515-19.  The rest is history, 
> > as they say.
> >
> > -- Mike
> >
> > -Original Message-
> > From: Mirja Kuehlewind 
> > Sent: Monday, October 28, 2019 8:54 AM
> > To: Benjamin Kaduk 
> > Cc: Barry Leiba ; Roman D. Danyliw 
> > ; ace-cha...@ietf.org; The IESG ; 
> > ace@ietf.org; draft-ietf-ace-cwt-proof-of-possess...@ietf.org
> > Subject: Re: [Ace] Mirja Kühlewind's No Objection on 
> > draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)
> >
> > These are all quite recents examples, so maybe the procedures are changing 
> > at the moment. I guess we as the IESG should be aware and figure out what 
> > the right procedure actually should be here.
> >
> > > On 28. Oct 2019, at 16:31, Benjamin Kaduk  wrote:
> > >
> > > On Fri, Oct 25, 2019 at 12:31:42PM -0400, Barry Leiba wrote:
> > >> Yeh, it's very common for authors to try to tell IANA how to handle 
> > >> registrations, and I often push back on that as inappropriate.  
> > >> There are certainly special conditions that IANA should be told 
> > >> about, but this is standard work-flow management stuff that ought 
> > >> to be left to IANA.  I do think it should be changed before this is 
> > >> published, probably just removing that last sentence.
> > >
> > > While I'm not opposed to normalizing on a default procedure, I think 
> > > the authors were just trying to follow existing examples.
> > >
> > > RFC 7519:
> > >
> > >   Values are registered on a Specification Required [RFC5226] basis
> > >   after a three-week review period on the jwt-reg-rev...@ietf.org
> > >   mailing list, on the advice of one or more Designated Experts.
> > >   However, to allow for the allocation of values prior to publication,
> > >   the Designated Experts may approve regi

Re: [Ace] AD review of draft-ietf-ace-oauth-authz-24

[Benjamin Kaduk]

On Wed, Nov 13, 2019 at 01:55:44PM +0100, Ludwig Seitz wrote:
> On 10/11/2019 04:28, Benjamin Kaduk wrote:
> 
> >>> 1.)
> >>> Perhaps the most far-reaching changes needed
> >>> will be to rename the "profile" claim, since that has already been
> >>> allocated to OIDC Core for a very different usage.
> >>
> >> [LS] FIXED. I renamed the "profile" claim and parameters to "ace_profile"
> >> Note that this will require changes in all of the profile drafts as well.
> > 
> > Indeed.  It would be great if someone (the chairs? Other volunteers are
> > surely welcome) could make a list of changes that affect the profile
> > documents, and make a pass over each in turn to find the affected areas.
> > 
> 
> Mostly a search and replace of "profile" with "ace_profile" would be in 
> order, perhaps with a subsequent proof reading that nothing was borked 
> up in the process.
> 
> I can do this, but sadly not before IETF.
> 
> 
> >>> 6.)
> >>> Section 1
> >>>
> >>> Authorization is the process for granting approval to an entity to
> >>> access a resource [RFC4949].  The authorization task itself can best
> >>> be described as granting access to a requesting client, for a
> >>> resource hosted on a device, the resource server (RS).  This exchange
> >>>
> >>> I had to pause for a while after reading this and ponder whether I
> >>> agreed with it.  I think that my reticence stems from some friction
> >>> between the most generic abstract definition of "resource" and a more
> >>> specific one used in the web/HTTP world and, to a lesser extent, the
> >>> world of URIs and URNs in general.  The resources we are discussing here
> >>> are not always specific named resources, but can also refer to
> >>> attributes or capabilities mediated by a RS; similarly, we may be
> >>> creating/modifying named resources as part of the resource access
> >>> performed by a client in the OAuth model.  I don't think it's wise to
> >>> diverge from the RFC 4949 definition just yet, but am still considering
> >>> whether adding some additional clarifying text here is worthwhile.
> >>
> >> [LS] I would argue that this specification is applicable even to the wider
> >> definition of "resource" that you are thinking of. Since OAuth 2.0 leaves
> > 
> > Oh, I agree, and was not intending to say otherwise with my comments above.
> > Rather, I was considering that some [other] readers might see the word
> > "resource" and go straight to "web resource named by URI", and wondering if
> > we could reword slightly to avoid that.
> >  >> the definition of "scope" up to the specific applications, and the ACE
> >> framework does not change this, we can deal with both web/HTTP/CoAP
> >> resources
> >> (named by URIs or URNs) and any other type of resources where the
> >> application
> >> can map the resource in question to a set of scopes.
> >> I am therefore inclined to say that this section is fine, but I'd be glad 
> >> to
> >> hear the result of your considerations on that matter.
> > 
> > I see three potential options so far:
> > 
> > (1) no change
> > (2) in the first sentence, s/resource/generic resource/
> > (3) add a new sentence as the third sentence, similar to "This resource
> > might be a Web or similar resource addressed by URI, but in general can be
> > a more generic or abstract resource provided by the RS".
> > 
> > I'm happy to advance the document with any of those three (and probably
> > with other versions, if any arise).
> >
> 
> I'll go with option 2 which seems to be a fine compromise with minimal 
> text breakage.
> 
> > 
> >>> 16.)
> >>> Section 3.2
> >>>
> >>> One application of COSE is OSCORE [I-D.ietf-core-object-security],
> >>> which provides end-to-end confidentiality, integrity and replay
> >>> protection, and a secure binding between CoAP request and response
> >>> messages.  In OSCORE, the CoAP messages are wrapped in COSE objects
> >>> and sent using CoAP.
> >>>
> >>> This framework RECOMMENDS the use of CoAP as replacement for HTTP for
> >>> use in constrained environments.
> >>>
> >>> Do we have a reason to mention OSCORE if we're no

Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15

[Benjamin Kaduk]

Hi Panos,

On Wed, Oct 16, 2019 at 03:06:01PM +, Panos Kampanakis (pkampana) wrote:
> Hi Yaron,
> 
> Thank you for the thorough review and feedback. 
> 
> To make sure I don't miss any of your comments over an email thread, I track 
> all your feedback in git issue 152 
> https://github.com/SanKumar2015/EST-coaps/issues/152 There I tried to address 
> all your comments and question and clarify some points. 
> 
> I also pushed minor changes to fix a few of the issues you brought up. The 
> diff of the changes pushed is here 
> https://github.com/SanKumar2015/EST-coaps/commit/86d785f2122596f28674fe8e403d30467c98abfb
>  
> 
> Please review the git issue and let us know if there are pending concerns. 
> Otherwise I am planning to reupload a new iteration next week. 

Thanks for uploading the -16, and thanks again to Yaron for the very
thoughtful review.

Sadly, I seem to have not looked at the github diff closely enough/in a
timely fashion, so I think we'll need to publish a -17 before I can move
this into IESG evaluation.  Here's my remaining notes:

Section 4

   Private keys can be transported as responses to a server-side key
   generation request as described in Section 4.4 of [RFC7030] and
   discussed in Section 5.8 of this document.

I think that, since Yaron brought it up, we should say "Section 4.4 of
[RFC7030] (and subsections)".

   curve.  After the standardization of [RFC7748], support for
   Curve25519 will likely be required in the future by (D)TLS Profiles
   for the Internet of Things [RFC7925].

Sorry I missed this before -- "standardization" is a bit of a bugbear (7748
is Informational, not even Standards-Track, let alone full Internet
Standard).

   In a constrained CoAP environment, endpoints can't always afford to
   establish a DTLS connection for every EST transaction.
   Authenticating and negotiating DTLS keys requires resources on low-
   end endpoints and consumes valuable bandwidth.  To alleviate this
   situation, an EST-coaps DTLS connection MAY remain open for
   sequential EST transactions.  For example, an EST csrattrs request
   that is followed by a simpleenroll request can use the same
   authenticated DTLS connection.  However, when a cacerts request is

I think we can also clarify that this "MAY remain open" is changing
expectations from RFC 7030, where the expectation was that the TLS
connection did not remain open.


Section 10.1

   the first DTLS exchange.  Alternatively, in a case where a /sen
   request immediately follows a /crts, a client MAY choose to keep the
   connection authenticated by the Implicit TA open for efficiency
   reasons (Section 4).  A client that interleaves EST-coaps /crts
   request with other requests in the same DTLS connection SHOULD
   revalidate the server certificate chain against the updated Explicit
   TA from the /crts response before proceeding with the subsequent
   requests.  If the server certificate chain does not authenticate
   against the database, the client SHOULD close the connection without
   completing the rest of the requests.  The updated Explicit TA MUST
   continue to be used in new DTLS connections.

I think Yaron was saying that "even if the optimization of keeping the DTLS
connection open is useful in the general case, it is very risky and prone
to misimplementation when combined with /crts".  So, if I can rephrase the
propsal to be that we say something more like "even though in general the
DTLS connection can remain open for efficiency (Section 4), after a /crts
response, the client MUST close the DTLS connection and establish a new
DTLS connection for subsequent EST exchanges", are there reasons that we
shouldn't use that behavior?

Thanks,

Ben

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

Re: [Ace] AD review of draft-ietf-ace-oauth-authz-24

[Benjamin Kaduk]

(This is still "in backwards order" (per
https://mailarchive.ietf.org/arch/msg/ace/qy9wQX04zkLS3n4BHS0GxKKi1XM)
albeit with a much-longer-than-planned delay...)

On Tue, Oct 15, 2019 at 04:07:48PM +0200, Ludwig Seitz wrote:
> Hello Ben,
> 
> thank you for your thorough review.
> 
> I have taken the liberty to add numbers to your comments in order to 
> refer to them in a easier way.
> 
> I have fixed 93 your 113 and there are 20 left where I am asking for 
> clarifications. These are:
> 
>   6.), 12.), 16.), 19.), 34.), 39.), 41.), 45.), 52.), 57.), 58.), 65.), 
> 66.), 68.), 76.), 78.), 79.), 88.), 99.), 111.)

Thank you for the numbering; that should help with keeping track of things.
I will try to trim the no-clarification-needed ones from this note.
> 
> Note that 39.) Requires input from OAuth experts. Hannes?
> 
> If you whish to inspect the changes made on other review issues, please 
> consult the commits here:
> https://github.com/ace-wg/ace-oauth/commits/master
> 
> 
> Detailed comments below.
> 
> /Ludwig
> 
> > 
> > Hi all,
> > 
> > The length of this review notwithstanding, this document is generally in
> > good shape -- there's a bunch of localized items to tighten up, and we
> > can flesh out the security considerations some more, but nothing too
> > drastic should be needed.
> > 
> > 1.)
> > Perhaps the most far-reaching changes needed
> > will be to rename the "profile" claim, since that has already been
> > allocated to OIDC Core for a very different usage.
> 
> [LS] FIXED. I renamed the "profile" claim and parameters to "ace_profile"
> Note that this will require changes in all of the profile drafts as well.

Indeed.  It would be great if someone (the chairs? Other volunteers are
surely welcome) could make a list of changes that affect the profile
documents, and make a pass over each in turn to find the affected areas.

> > 6.)
> > Section 1
> > 
> >Authorization is the process for granting approval to an entity to
> >access a resource [RFC4949].  The authorization task itself can best
> >be described as granting access to a requesting client, for a
> >resource hosted on a device, the resource server (RS).  This exchange
> > 
> > I had to pause for a while after reading this and ponder whether I
> > agreed with it.  I think that my reticence stems from some friction
> > between the most generic abstract definition of "resource" and a more
> > specific one used in the web/HTTP world and, to a lesser extent, the
> > world of URIs and URNs in general.  The resources we are discussing here
> > are not always specific named resources, but can also refer to
> > attributes or capabilities mediated by a RS; similarly, we may be
> > creating/modifying named resources as part of the resource access
> > performed by a client in the OAuth model.  I don't think it's wise to
> > diverge from the RFC 4949 definition just yet, but am still considering
> > whether adding some additional clarifying text here is worthwhile.
> 
> [LS] I would argue that this specification is applicable even to the wider
> definition of "resource" that you are thinking of. Since OAuth 2.0 leaves

Oh, I agree, and was not intending to say otherwise with my comments above.
Rather, I was considering that some [other] readers might see the word
"resource" and go straight to "web resource named by URI", and wondering if
we could reword slightly to avoid that.

> the definition of "scope" up to the specific applications, and the ACE
> framework does not change this, we can deal with both web/HTTP/CoAP 
> resources
> (named by URIs or URNs) and any other type of resources where the 
> application
> can map the resource in question to a set of scopes.
> I am therefore inclined to say that this section is fine, but I'd be glad to
> hear the result of your considerations on that matter.

I see three potential options so far:

(1) no change
(2) in the first sentence, s/resource/generic resource/
(3) add a new sentence as the third sentence, similar to "This resource
might be a Web or similar resource addressed by URI, but in general can be
a more generic or abstract resource provided by the RS".

I'm happy to advance the document with any of those three (and probably
with other versions, if any arise).

> > 12.)
> >   A refresh token in OAuth 2.0 is a string representing the
> >   authorization granted to the client by the resource owner.  The
> >   string is usually opaque to the client.  The token denotes an
> > 
> > Apparently I'd forgotten that this couldn't be binary.
> 
> [LS] From RFC 6749, section 1.5: "A refresh token is a string ..."
> No qualifiers such as "binary" so I interpret this to mean a text-string.
> Do you want us to add some clarification?

[this is handled in the other thread]

> > 16.)
> > Section 3.2
> > 
> >One application of COSE is OSCORE [I-D.ietf-core-object-security],
> >which provides end-to-end confidentiality, integrity and replay
> >protection, and a secure 

Re: [Ace] Secdir last call review of draft-ietf-ace-oauth-authz-27

[Benjamin Kaduk]

Hi Steve,

Thanks for the thoughtful and in-depth commentary; I look forward to seeing
the authors' response.  I'll make a few notes inline in the interim...

On Sun, Dec 08, 2019 at 10:18:53AM -0800, Stephen Kent via Datatracker wrote:
> Reviewer: Stephen Kent
> Review result: Has Issues
> 
> SECDIR review of draft-ietf-ace-oauth-authz-27
> 
> The summary of the review is almost ready, but needs some revisions.
> 
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written with the intent of improving security requirements and
> considerations in IETF drafts.  Comments not addressed in last call may be
> included in AD reviews during the IESG review.  Document editors and WG chairs
> should treat these comments just like any other last call comments.
> 
> This is a long document- 86 pages! It is a proposal for how to use OAuth 2.0
> and CoAP to provide authorization security for Internet of Things (IoT)
> devices. IoT devices are often criticized as not being very secure, so this
> seems like a useful initiative. RFC 7228 (Technology for Constrained-Node
> Networks, and Informational document) is cited as inspiration and reference 
> for
> this work. CoAP (RFC 7252) is expressly designed for the sort of environment
> that characterizes many IoT devices, hence is seems a natural choice for this
> authorization-focused framework. OAuth is not as obvious a candidate building
> block in this context, e.g., it is expressly designed for the HTTP context, 
> yet
> CoAP is cited as the replacement for HTTP. This document adapts OAuth for the
> CoAp context.

The WG did consider a variety of options before settling on the OAuth
architecture, so we can probably say that "the other extant options were
worse".

> This document has an extensive, 6-page Security Considerations section,
> appropriate for a document specifying an authorization framework. It begins by
> citing the OAuth 2.0 specification, the OAuth 2.0 threat model (RFC 6819), and
> OAuth 2.0 Token Introspection (RFC 7662).  All three of these documents are
> relevant, and they contain substantial Security Consideration sections.
> 
> Section 6.1 deals with security for the tokens that are transmitted to convey
> authorization information. In general the requirements and advice provided 
> here
> are good; I would prefer to see the admonition against use of a shared secret
> key for a group of serves to be a MUST NOT, as opposed to just NOT 
> RECOMMENDED.
> I am not convinced that the suggestion for short lifetime tokens is necessary;
> we have seen how short duration certificate lifetimes and frequent CRL 
> issuance
> in PKI contexts often is neither required nor advisable. This section ends by
> noting that only client-initiated revocation of tokens is addressed by RFC
> 7009. The authors note that revocation of long lifetime token remains an open
> issue. If this is likely to be a common case for IoT devices, leaving this as 
> a
> TBD is not great.

I think that there's a significant difference between the PKIX and OAuth
workflows as deployed here, that's relevant -- in PKIX the CA has the
"one-time" certification decision with some follow-on revocation status
information that many things don't make use of or don't put in the critical
path; in the OAuth world most deployments have the AS regularly involved in
authentication decisions, whether that's the RS querying "is this token
still valid?" or having a refresh token periodically refreshed into a new
access token on a timescale of hours.  There's more of an expectation that
the AS can actively break these ongoing/recurring authorization flows when
something goes wrong, whereas when the CA issues a CRL it sometimes feels
more like "toss it over the wall and hope that the relying party bothers to
check".  That's not to say that the OAuth way is perfect, of course, but
hopefully gives some sense of why it feels more natural to the authors/WG.

> Section 6.2 addresses communication security issues. The section opens by
> requiring an authorization server to offer confidentiality for client
> interactions, but the wording implies that a client need not make use of such
> protection. The reader is reminded that security requirements expressed in
> Section 5 of this document (a 25-page long section) MUST be addressed by a
> profile. I’d prefer to see references to specific parts of Section 5 that
> expressly addresses confidentiality, so that a reader can better understand
> when it is safe to reject the offer of confidentiality by a server. Encryption
> of CWTs is used as an example, which is appropriate because CBOR CWT is the
> default token format. The final paragraph of this section says that 
> “developers

(I'll reiterate for everyone that CWTs are not necessarily encrypted,
though they can be.  In the Web/OAuth world, encrypted JWTs are hardly the
norm.)

> MUST ensure that … 

Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15

[Benjamin Kaduk]

Hi Panos,

Sorry for the slow reply -- it was a busy telechat week for the IESG.
These changes look good; please go ahead and re-upload.

Thanks,

Ben

On Mon, Dec 02, 2019 at 05:37:07AM +, Panos Kampanakis (pkampana) wrote:
> Hi Ben,
> 
> Can you confirm if the diff 
> https://github.com/SanKumar2015/EST-coaps/commit/53933bb9f9365795f2302baef2e39709ae05
>  addresses your feedback? I will then re-upload it.  
> 
> Thanks,
> Panos
> 
> -Original Message-
> From: Ace  On Behalf Of Panos Kampanakis (pkampana)
> Sent: Monday, November 18, 2019 2:07 PM
> To: Benjamin Kaduk 
> Cc: Yaron Sheffer ; 
> draft-ietf-ace-coap-est@ietf.org; ace@ietf.org
> Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15
> 
> Hi Ben,
> 
> All addressed, except for the last one. The diff is here 
> https://github.com/SanKumar2015/EST-coaps/commit/53933bb9f9365795f2302baef2e39709ae05
>  
> 
> My responses below in Pk> 
> 
> I will wait for your confirmation before I upload version 17.
> 
> Panos
> 
> 
> -Original Message-
> From: Benjamin Kaduk 
> Sent: Tuesday, November 12, 2019 6:06 PM
> To: Panos Kampanakis (pkampana) 
> Cc: Yaron Sheffer ; 
> draft-ietf-ace-coap-est@ietf.org; ace@ietf.org
> Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15
> 
> Hi Panos,
> 
> On Wed, Oct 16, 2019 at 03:06:01PM +, Panos Kampanakis (pkampana) wrote:
> > Hi Yaron,
> > 
> > Thank you for the thorough review and feedback. 
> > 
> > To make sure I don't miss any of your comments over an email thread, I 
> > track all your feedback in git issue 152 
> > https://github.com/SanKumar2015/EST-coaps/issues/152 There I tried to 
> > address all your comments and question and clarify some points. 
> > 
> > I also pushed minor changes to fix a few of the issues you brought up. 
> > The diff of the changes pushed is here 
> > https://github.com/SanKumar2015/EST-coaps/commit/86d785f2122596f28674f
> > e8e403d30467c98abfb
> > 
> > Please review the git issue and let us know if there are pending concerns. 
> > Otherwise I am planning to reupload a new iteration next week. 
> 
> Thanks for uploading the -16, and thanks again to Yaron for the very 
> thoughtful review.
> 
> Sadly, I seem to have not looked at the github diff closely enough/in a 
> timely fashion, so I think we'll need to publish a -17 before I can move this 
> into IESG evaluation.  Here's my remaining notes:
> 
> Section 4
> 
>Private keys can be transported as responses to a server-side key
>generation request as described in Section 4.4 of [RFC7030] and
>discussed in Section 5.8 of this document.
> 
> I think that, since Yaron brought it up, we should say "Section 4.4 of 
> [RFC7030] (and subsections)".
> 
> PK> Fixed. 
> 
>curve.  After the standardization of [RFC7748], support for
>Curve25519 will likely be required in the future by (D)TLS Profiles
>for the Internet of Things [RFC7925].
> 
> Sorry I missed this before -- "standardization" is a bit of a bugbear (7748 
> is Informational, not even Standards-Track, let alone full Internet Standard).
> 
> Pk> Replaced "standardization" with "publication". 
> 
>In a constrained CoAP environment, endpoints can't always afford to
>establish a DTLS connection for every EST transaction.
>Authenticating and negotiating DTLS keys requires resources on low-
>end endpoints and consumes valuable bandwidth.  To alleviate this
>situation, an EST-coaps DTLS connection MAY remain open for
>sequential EST transactions.  For example, an EST csrattrs request
>that is followed by a simpleenroll request can use the same
>authenticated DTLS connection.  However, when a cacerts request is
> 
> I think we can also clarify that this "MAY remain open" is changing 
> expectations from RFC 7030, where the expectation was that the TLS connection 
> did not remain open.
> 
> Pk> I added " which was not the case in [RFC7030]"
> 
> Section 10.1
> 
>the first DTLS exchange.  Alternatively, in a case where a /sen
>request immediately follows a /crts, a client MAY choose to keep the
>connection authenticated by the Implicit TA open for efficiency
>reasons (Section 4).  A client that interleaves EST-coaps /crts
>request with other requests in the same DTLS connection SHOULD
>revalidate the server certificate chain against the updated Explicit
>TA from the /crts response before proceeding with the subsequent
>requests.  If the server certificate chain does not authe

Re: [Ace] Genart last call review of draft-ietf-ace-oauth-authz-27

[Benjamin Kaduk]

On Sat, Dec 14, 2019 at 05:20:34PM +0100, Ludwig Seitz wrote:
> On 2019-12-12 21:44, Stewart Bryant via Datatracker wrote:
> > 
> > o  A RS sending a "cnonce" parameter in an an AS Request Creation
> > SB> An RS...
> 
> This doesn't feel right, since there is no consonant in RS and the R in
> "Resource Server" (the expansion of RS) is not silent either. Is there a
> grammar rule that I'm unaware of?
> 
> You did however make me aware of a typo later in that sentence where
> there it says: "an an".

I think you would say "a resource server" but "an ar ess".

-Ben

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

Re: [Ace] Mirja Kühlewind's No Objection on draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

[Benjamin Kaduk]

On Fri, Oct 25, 2019 at 12:31:42PM -0400, Barry Leiba wrote:
> Yeh, it's very common for authors to try to tell IANA how to handle
> registrations, and I often push back on that as inappropriate.  There
> are certainly special conditions that IANA should be told about, but
> this is standard work-flow management stuff that ought to be left to
> IANA.  I do think it should be changed before this is published,
> probably just removing that last sentence.

While I'm not opposed to normalizing on a default procedure, I think the
authors were just trying to follow existing examples.

RFC 7519:

   Values are registered on a Specification Required [RFC5226] basis
   after a three-week review period on the jwt-reg-rev...@ietf.org
   mailing list, on the advice of one or more Designated Experts.
   However, to allow for the allocation of values prior to publication,
   the Designated Experts may approve registration once they are
   satisfied that such a specification will be published.

   Registration requests sent to the mailing list for review should use
   an appropriate subject (e.g., "Request to register claim: example").

   Within the review period, the Designated Experts will either approve
   or deny the registration request, communicating this decision to the
   review list and IANA.  Denials should include an explanation and, if
   applicable, suggestions as to how to make the request successful.
   Registration requests that are undetermined for a period longer than
   21 days can be brought to the IESG's attention (using the
   i...@ietf.org mailing list) for resolution.

RFC 8414:

   Values are registered on a Specification Required [RFC8126] basis
   after a two-week review period on the oauth-ext-rev...@ietf.org
   mailing list, on the advice of one or more Designated Experts.
   However, to allow for the allocation of values prior to publication,
   the Designated Experts may approve registration once they are
   satisfied that such a specification will be published.

   Registration requests sent to the mailing list for review should use
   an appropriate subject (e.g., "Request to register OAuth
   Authorization Server Metadata: example").

   Within the review period, the Designated Experts will either approve
   or deny the registration request, communicating this decision to the
   review list and IANA.  Denials should include an explanation and, if
   applicable, suggestions as to how to make the request successful.
   Registration requests that are undetermined for a period longer than
   21 days can be brought to the IESG's attention (using the
   i...@ietf.org mailing list) for resolution.

RFC 8447:

   Specification Required [RFC8126] registry requests are registered
   after a three-week review period on the 
   mailing list, on the advice of one or more designated experts.
   However, to allow for the allocation of values prior to publication,
   the designated experts may approve registration once they are
   satisfied that such a specification will be published.

   Registration requests sent to the mailing list for review SHOULD use
   an appropriate subject (e.g., "Request to register value in TLS bar
   registry").

   Within the review period, the designated experts will either approve
   or deny the registration request, communicating this decision to the
   review list and IANA.  Denials SHOULD include an explanation and, if
   applicable, suggestions as to how to make the request successful.
   Registration requests that are undetermined for a period longer than
   21 days can be brought to the IESG's attention (using the
mailing list) for resolution.

[I stopped looking here]

So if we're going to change things around, maybe we should issue an IESG
statement.

-Ben

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

Re: [Ace] Genart last call review of draft-ietf-ace-cwt-proof-of-possession-08

[Benjamin Kaduk]

Thanks for the update, Mike.

I will go ahead and get this in front of the whole IESG, but one comment
below...

On Fri, Oct 18, 2019 at 10:57:06PM +, Mike Jones wrote:
> Hi Christer,
> 
> https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-09 has 
> been published, which addresses your review comments in the ways proposed 
> below.  Thanks again for your review!
> 
>-- Mike
> 
> From: Mike Jones
> Sent: Wednesday, October 16, 2019 12:40 PM
> To: Christer Holmberg ; gen-...@ietf.org
> Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; i...@ietf.org; 
> ace@ietf.org
> Subject: RE: Genart last call review of 
> draft-ietf-ace-cwt-proof-of-possession-08
> 
> 
> Thanks for your review, Christer.  Replies are inline, prefixed by "Mike>"…
> 
> 
> 
> -Original Message-
> From: Christer Holmberg via Datatracker 
> mailto:nore...@ietf.org>>
> Sent: Friday, October 4, 2019 10:44 AM
> To: gen-...@ietf.org
> Cc: 
> draft-ietf-ace-cwt-proof-of-possession@ietf.org;
>  i...@ietf.org; ace@ietf.org
> Subject: Genart last call review of draft-ietf-ace-cwt-proof-of-possession-08
> 
> 
> 
> Reviewer: Christer Holmberg
> 
> Review result: Ready with Issues
> 
> 
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review 
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for the 
> IETF Chair.  Please treat these comments just like any other last call 
> comments.
> 
> 
> 
> For more information, please see the FAQ at
> 
> 
> 
> .
> 
> 
> 
> Document: draft-ietf-ace-cwt-proof-of-possession-08
> 
> Reviewer: Christer Holmberg
> 
> Review Date: 2019-10-04
> 
> IETF LC End Date: 2019-10-09
> 
> IESG Telechat date: Not scheduled for a telechat
> 
> 
> 
> Summary: For most part the document is ready, but I have a few editorial 
> comments and an issue.
> 
> 
> 
> Major issues: N/A
> 
> 
> 
> Minor issues:
> 
> 
> 
> The text says in the Security Considerations that one must ensure that the 
> might not understand the "cnf" claim, and that applications must ensure that 
> receivers support it.
> 
> 
> 
> Q1: How are you going to ensure that, and why do you have to ensure that? RFC
> 
> 8392 doesn't even seem to require that one must ensure that the receivers 
> support CWT.
> 
> 
> 
> Mike> I agree that this text isn't actually actionable.  I propose that we 
> simply delete it.
> 
> 
> 
> Q2: For receivers that do support CWT, RFC 8392 says that unsupported claims 
> must be discarded. If that can't be applied for "cnf" I think you need to 
> explain why.
> 
> 
> 
> Mike> The RFC 8392 requirement does apply.  This is also aligned with the 
> text in 3.1, so I don't think there are any changes needed to the spec for 
> this.

I don't think there's anything else we can reasonably do/say here, but it
does seem potentially surprising that we could get into a state where
client and AS both think that the token is a PoP token but the RS
interprets it as a bearer token.  I expect that in most cases where PoP
CWTs are used in an application context, either the client would be able to
detect this (e.g., by the RS not asking for a confirmation message) or the
client would send a confirmation message and the RS would treat it as
malformed, so the scope for practical impact seems limited, but it's hard
to confidently make sweeping statements.

-Ben

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

Re: [Ace] AD review of draft-ietf-ace-oauth-params-05

[Benjamin Kaduk]

On Sun, Nov 17, 2019 at 04:45:04AM +0100, Ludwig Seitz wrote:
> On 15/11/2019 13:14, Benjamin Kaduk wrote:
> > Hi all,
> > 
> > I'm mostly just nitpicking in the following comments; the actual content
> > here is in good shape.  (But some of these are popular things that
> > directorate reviewers like to complain about, so fixing them preemptively
> > seems wise.)
> > 
> > Section 1
> > 
> > access tokens.  These parameters and claims can also be used in other
> > contexts, and may need to be updated to align them with ongoing OAuth
> > work.  Therefore they have been split out into this document, which
> > can be used and updated independently of [I-D.ietf-ace-oauth-authz].
> > 
> > I expect that we'll get some reviewers who want to wordsmith this last
> > sentence.  It's fine to wait and see what suggestions come in (if any),
> > but if you want to try to forestall those, my suggestion would be:
> > 
> > % Therefore, these parameters and claims have been put into a dedicated
> > % document, to facilitate their use and any potential updates in a manner
> > % independent of [I-D.ace-oauth-authz].
> > 
> Done.
> 
> > Section 3.1
> > 
> > req_cnf
> >OPTIONAL.  This field contains information about the key the
> >client would like to bind to the access token for proof-of-
> >possession.  It is RECOMMENDED that an AS reject a request
> >containing a symmetric key value in the 'req_cnf' field, since the
> >AS is expected to be able to generate better symmetric keys than a
> >potentially constrained client.  The AS MUST verify that the
> > 
> > nit: I'd wordsmith this a bit, since the idea is that the AS-generated
> > key will be better than one generated by a constrained client, but a
> > non-constrained client can probably do just fine at keygen.  So,
> > I'd consider dropping "potentially", as the rest of the sentence does
> > not have anything to imply that all clients using this claim are
> > constrained.
> > 
> Done.
> 
> > Payload:
> > {
> >"req_cnf" : {
> >   "COSE_Key" : {
> >  "kty" : "EC",
> >  "kid" : h'11',
> >  "crv" : "P-256",
> >  "x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8',
> >  "y" : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4'
> >   }
> >}
> >  }
> > 
> > Figure 1: Example request for an access token bound to an asymmetric
> > key.
> > 
> > Shouldn't an access token request have an authorization code?
> > The other parameters from Section 4.1.3 of RFC 6749 have conditions
> > attached to their REQUIRED status, but not "code".
> >
> In draft-ietf-ace-oauth-authz section 5.6.1. (Client-to-AS Request) we 
> specify that when the "grant_type" parameter is missing, then 
> "client_credentials" is implied, which in turn means that the client 
> does not need an authorization code.  Section 4.1.3 of RFC 6749 is about 
> the authorization code grant, you are looking at the ACE-ified version 
> of Section 4.4

Ah, thanks.  I remembered that we had a default "grant_type" but was too
fast when trying to check the other (sometimes-)required parameters.

> > Section 3.2
> > 
> > cnf
> >REQUIRED if the token type is "pop" and a symmetric key is used.
> > 
> > Just to check, this means that if the client includes a symmetric 'cnf'
> > key and the AS ignores the prior recommendation to ignore such a
> > symmetric confirmation key in the request, the AS still has to echo
> > back the symmetric key that is in use?  (There's also potentially some
> > interesting interactions if we use a 'kid'.)
> 
> Indeed as the drafts are written right now, that would be the expected
> AS behaviour. This is not entirely intentional, and my only objection to 
> changing it at this time is that writing specification text handling 
> interactions we are recommending against (i.e. accepting 
> client-suggested symmetric keys) seems icky.
> As for 'kid' I'd just expect the AS to echo back the kid, not the actual 
> key.

I don't see any obvious problems from this behavior, so leaving it as-is
seems like the right thing to do for now.

> > 
> >MAY be present for asymmetric proof-of-possession keys.  This
> >field contains the proof-of-possession k

Re: [Ace] AD review of draft-ietf-ace-oauth-params-05

[Benjamin Kaduk]

One more update on this one: I cancelled the last-call request, because my
discussions with Ludwig about the core framework indicated a strong chance
that we'll want to tweak how rs_cnf works, and we should of course reflect
any change to rs_cnf in this document as well.

Further updates (hopefully) in the framework's thread.

-Ben

On Mon, Nov 18, 2019 at 09:42:41PM -0800, Benjamin Kaduk wrote:
> On Sun, Nov 17, 2019 at 04:45:04AM +0100, Ludwig Seitz wrote:
> > On 15/11/2019 13:14, Benjamin Kaduk wrote:
> > > Hi all,
> > > 
> > > I'm mostly just nitpicking in the following comments; the actual content
> > > here is in good shape.  (But some of these are popular things that
> > > directorate reviewers like to complain about, so fixing them preemptively
> > > seems wise.)
> > > 
> > > Section 1
> > > 
> > > access tokens.  These parameters and claims can also be used in other
> > > contexts, and may need to be updated to align them with ongoing OAuth
> > > work.  Therefore they have been split out into this document, which
> > > can be used and updated independently of [I-D.ietf-ace-oauth-authz].
> > > 
> > > I expect that we'll get some reviewers who want to wordsmith this last
> > > sentence.  It's fine to wait and see what suggestions come in (if any),
> > > but if you want to try to forestall those, my suggestion would be:
> > > 
> > > % Therefore, these parameters and claims have been put into a dedicated
> > > % document, to facilitate their use and any potential updates in a manner
> > > % independent of [I-D.ace-oauth-authz].
> > > 
> > Done.
> > 
> > > Section 3.1
> > > 
> > > req_cnf
> > >OPTIONAL.  This field contains information about the key the
> > >client would like to bind to the access token for proof-of-
> > >possession.  It is RECOMMENDED that an AS reject a request
> > >containing a symmetric key value in the 'req_cnf' field, since the
> > >AS is expected to be able to generate better symmetric keys than a
> > >potentially constrained client.  The AS MUST verify that the
> > > 
> > > nit: I'd wordsmith this a bit, since the idea is that the AS-generated
> > > key will be better than one generated by a constrained client, but a
> > > non-constrained client can probably do just fine at keygen.  So,
> > > I'd consider dropping "potentially", as the rest of the sentence does
> > > not have anything to imply that all clients using this claim are
> > > constrained.
> > > 
> > Done.
> > 
> > > Payload:
> > > {
> > >"req_cnf" : {
> > >   "COSE_Key" : {
> > >  "kty" : "EC",
> > >  "kid" : h'11',
> > >  "crv" : "P-256",
> > >  "x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8',
> > >  "y" : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4'
> > >   }
> > >}
> > >  }
> > > 
> > > Figure 1: Example request for an access token bound to an asymmetric
> > > key.
> > > 
> > > Shouldn't an access token request have an authorization code?
> > > The other parameters from Section 4.1.3 of RFC 6749 have conditions
> > > attached to their REQUIRED status, but not "code".
> > >
> > In draft-ietf-ace-oauth-authz section 5.6.1. (Client-to-AS Request) we 
> > specify that when the "grant_type" parameter is missing, then 
> > "client_credentials" is implied, which in turn means that the client 
> > does not need an authorization code.  Section 4.1.3 of RFC 6749 is about 
> > the authorization code grant, you are looking at the ACE-ified version 
> > of Section 4.4
> 
> Ah, thanks.  I remembered that we had a default "grant_type" but was too
> fast when trying to check the other (sometimes-)required parameters.
> 
> > > Section 3.2
> > > 
> > > cnf
> > >REQUIRED if the token type is "pop" and a symmetric key is used.
> > > 
> > > Just to check, this means that if the client includes a symmetric 'cnf'
> > > key and the AS ignores the prior recommendation to ignore such a
> > > symmetric confirmation key in the request, the AS still has to echo
> &g

Re: [Ace] I-D Action: draft-ietf-ace-oauth-authz-27.txt

[Benjamin Kaduk]

Hi Ludwig,

On Thu, Nov 21, 2019 at 03:16:03AM +0100, Ludwig Seitz wrote:
> Hello ACE,
> 
> turns out -26 didn't cover one of the items in Ben's review, namely the 
> question of using Client introspection to determine token expiration as 
> a lower bound for key expiration. Since the whole issue of Client 
> introspection was contentious between OAuth experts, we decided to 
> remove the text describing that option.  This still leaves us with the 
> two other options, so the problem is still covered.

Thanks for all the updates!  I'm just about ready to push the "request Last
Call" button, but wanted to check one thing first:

Section 5.6.3 seems to limit the error responses to 4.00 and 4.01, but
Section 5.8.2 also talks about 4.03 and 4.05.  I noticed because I was
checking Section 5.1.1's note about "unauthorized_client" error response 
against the
various options in 5.8.2, to see if we're internally consistent about when
we say to send errors vs. AS request creation hints.  My recollection is
that we can have all three of a response code, error response (e.g.,
"unauthorized_client"), and (our custom format of) response payload present
in the same response, so any potential conflict would be limited to just
the response code, but please correct me if I'm wrong about that.

Also, a few nits that could be treated as LC comments:

There's a stray 'W' in Figure 7

In Section 6.8: s/obsole/obsolete/, and s/profile/ace_profile/

In Section 8.16 we removed the entire "Specifications are required for the
standards track range of point assignment[...]" bullet point.  I think that
only the first two sentences of that bullet point were redundant with RFC
8126, and the last two ("Specifications are needed for the first-come,
first-serve range if they are expected [...]") reflected new requirements.


Thanks,

Ben

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

Re: [Ace] I-D Action: draft-ietf-ace-oauth-authz-27.txt

[Benjamin Kaduk]

On Wed, Nov 27, 2019 at 03:31:16PM +, Ludwig Seitz wrote:
> Hi Ben,
> 
> replies inline.
> 
> /Ludwig
> ____
> From: Benjamin Kaduk 
> Sent: Tuesday, November 26, 2019 12:04 AM
> To: Ludwig Seitz
> Cc: ace@ietf.org
> Subject: Re: [Ace] I-D Action: draft-ietf-ace-oauth-authz-27.txt
> 
> Hi Ludwig,
> 
> On Thu, Nov 21, 2019 at 03:16:03AM +0100, Ludwig Seitz wrote:
> > Hello ACE,
> >
> > turns out -26 didn't cover one of the items in Ben's review, namely the
> > question of using Client introspection to determine token expiration as
> > a lower bound for key expiration. Since the whole issue of Client
> > introspection was contentious between OAuth experts, we decided to
> > remove the text describing that option.  This still leaves us with the
> > two other options, so the problem is still covered.
> 
> Thanks for all the updates!  I'm just about ready to push the "request Last
> Call" button, but wanted to check one thing first:
> 
> Section 5.6.3 seems to limit the error responses to 4.00 and 4.01, but
> Section 5.8.2 also talks about 4.03 and 4.05.  I noticed because I was
> checking Section 5.1.1's note about "unauthorized_client" error response 
> against the
> various options in 5.8.2, to see if we're internally consistent about when
> we say to send errors vs. AS request creation hints.  My recollection is
> that we can have all three of a response code, error response (e.g.,
> "unauthorized_client"), and (our custom format of) response payload present
> in the same response, so any potential conflict would be limited to just
> the response code, but please correct me if I'm wrong about that.
> 
> [LS] Section 5.6.3 describes the interaction with the token endpoint at the 
> AS. There we mirrored the behaviour of OAuth error responses.
> Section 5.8.2 describes the interaction with the newly defined authz-info 
> endpoint at the RS. We decided that this warranted more detailed error 
> responses, so that a client gets some hint on what went wrong when an access 
> token is rejected by the RS.
> This is why we have added the  4.03 and 4.05 messages.
> Section 5.1.1 describes an access request to a resource at the RS (other than 
> the authz-info endpoint) and has yet another different error behaviour.
> For the token endpoint (5.6.3), the response code is part of the HTTP/CoAP 
> header, while the "error" parameter (with values such as e.g. 
> "unauthorized_client") is part of the payload in certain error responses 
> (which may also contain "error_description" and "error_uri"), this is just 
> mirroring behaviour of OAuth.
> For the authz-info endpoint (5.8.2) no such parameters are specified in the 
> document (i.e. it just uses the response codes).
> Does this clarify the issue?

It does; thanks for putting the pieces into the proper context for me.

> Also, a few nits that could be treated as LC comments:
> 
> There's a stray 'W' in Figure 7
> 
> In Section 6.8: s/obsole/obsolete/, and s/profile/ace_profile/
> 
> In Section 8.16 we removed the entire "Specifications are required for the
> standards track range of point assignment[...]" bullet point.  I think that
> only the first two sentences of that bullet point were redundant with RFC
> 8126, and the last two ("Specifications are needed for the first-come,
> first-serve range if they are expected [...]") reflected new requirements.
> 
> [LS] Does the " LC comments" part mean I should wait with updating the draft?

It means you're free to wait, yes.  (If you want to update anyway that's
also fine.)

-Ben

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

Re: [Ace] New Version Notification - draft-ietf-ace-cwt-proof-of-possession-07.txt

[Benjamin Kaduk]

On Tue, Sep 24, 2019 at 04:33:18PM -0700, Benjamin Kaduk wrote:
> Hi all,
> 
> Thanks for the updates; they look good!
> 
> Before I kick off the IETF LC, I just have two things I wanted to
> double-check (we may not need a new rev before the LC):
> 
> (1) In Section 3.2 (Representation of an Asymmetric Proof-of-Possession
> Key), the last paragraph is a somewhat different from the main content, in
> that it mentions using "COSE_Key" for an encrypted symmetric key, analogous
> to the last paragraph of Section 3.2 of RFC 7800.  I had wanted to see some
> additional discussion, but we agreed that this was analogous to RFC 7800
> and we did not need to go "out of parity" with it on this point.  So we
> should be able to go ahead without new text here, but did we want to
> explicitly refer back to that portion of RFC 7800 to make the connection
> clear?
> 
> (2) In https://github.com/cwt-cnf/i-d/pull/27/files we removed a large
> chunk of text since it contained several things that are inaccurate.  The
> only things that were removed that I wanted to check if we should think
> about keeping was the note that the same key might be referred to by
> different key IDs in messages directed to different recipients.  What do
> people think about that?

Oops, and my notes were unfortunately misalgined to the terminal window
size:

(3) I think we were going to change the [JWT] reference to [CWT], in
Section 4:

   Applications utilizing proof of possession SHOULD also utilize
   audience restriction, as described in Section 4.1.3 of [JWT], as it
   provides additional protections.  Audience restriction can be used by
   recipients to reject messages intended for different recipients.

That way we won't get asked to make [JWT] a normative reference.

-Ben

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

Re: [Ace] Genart last call review of draft-ietf-ace-coap-est-15

[Benjamin Kaduk]

There will hopefully be a secdir review as well before the document goes
into IESG evaluation; given this is a pretty small change, I'd say hold off
on uploading for now.

Thanks for asking, and thanks David for the review,

Ben

On Tue, Oct 08, 2019 at 06:37:25PM +, Panos Kampanakis (pkampana) wrote:
> Thanks David. Done. I replaced the RFC7525 references with BCP195. 
> 
> Should I upload or will there be more Gen-ART reviews?
> 
> 
> -Original Message-
> From: Ace  On Behalf Of David Schinazi via Datatracker
> Sent: Sunday, October 06, 2019 12:49 AM
> To: gen-...@ietf.org
> Cc: draft-ietf-ace-coap-est@ietf.org; i...@ietf.org; ace@ietf.org
> Subject: [Ace] Genart last call review of draft-ietf-ace-coap-est-15
> 
> Reviewer: David Schinazi
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review 
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for the 
> IETF Chair.  Please treat these comments just like any other last call 
> comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-ace-coap-est-??
> Reviewer: David Schinazi
> Review Date: 2019-10-05
> IETF LC End Date: 2019-10-18
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: Document is clear and well-written.
> 
> Major issues: None.
> 
> Minor issues: None.
> 
> Nits/editorial comments: I believe references to RFC7525 should instead refer 
> to it as BCP195 to point to future revisions.
> 
> 
> ___
> 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] Review for draft-palombini-ace-coap-pubsub-profile

[Benjamin Kaduk]

On Wed, Dec 18, 2019 at 03:47:04PM +, Cigdem Sengul wrote:
> Dear Francesca,
> 
> Thank you for your responses to my comments.
> My comments are inline.
> 
> >
> >
> > In the following, I list a few things reading the draft made me think,
> > especially in its applicability to MQTT:
> >
> > (1) What is planned to make this document a generic pubsub solution? Will
> > there a generic architecture section, and specific descriptions for each of
> > the protocols?
> >
> >
> >
> > FP: Yes, I am planning to make some updates to the text to make this
> > generic. In general, I think the structure of the draft will be the same,
> > but each section would either have a sentence or (if longer text is needed)
> > a subsection talking about the different alternatives. For example, Section
> > 2 would remove current specific text about CoAP pubsub (only talk about
> > general pubsub) and would replace that text with an additional paragraph
> > mentioning that the pubsub protocol can be CoAP or MQTT. Section 3 would
> > have 2 subsections, coap_pubsub_app and mqtt_pubsub_app, etc.
> >
> >
> >
> 
> CS: YEs, sounds good.
> 
> 
> > For instance, if an MQTT client implements this,  the client would talk to
> > AS1 to get a token based on the way we describe in the mqtt-tls profile,
> > and then get keying material for topics from AS2.
> >
> > I expect the MQTT client would use a different profile name like
> > mqtt_tls_app to signal to AS1 that it is supporting the application layer
> > security. This is because the draft hints that there should be a policy
> > agreement between AS1 and AS2: “Note that AS1 and AS2 might either be
> > co-resident or be 2 separate physical entities, in which case access
> > control policies must be exchanged between AS1 and AS2, so that they agree
> > on rights fo  joining nodes about specific topics.”
> >
> >
> >
> > FP: That is all correct. Moreover, we can also discuss details such as
> > what communication protocol the Client uses to talk to AS2. Right now
> > ace-key-groupcomm is only defined for CoAP, but if MQTT prefers to use
> > HTTP, that is very easy to define.
> >
> >
> >
> >
> > (2) If we keep AS1 as the mqtt-tls profile AS, then for consistency sake,
> > the MQTT client would expect to talk to HTTPS to AS2, but the coap-pubsub
> > draft describes these, expectedly, in CoAP. Will there be support for HTTPS?
> >
> >
> >
> > FP: I promise I did not read this question before answering the text above
> > :) Yes. This is really easy to specify, we already do this with CBOR/JSON,
> > in ace-key-groupcomm:
> >
> >
> >
> > The ACE framework is based
> >
> >on CBOR [RFC7049], so CBOR is the format used in this specification.
> >
> >However, using JSON [RFC8259] instead of CBOR is possible, using the
> >
> >conversion method specified in Sections 4.1 and 4.2 of [RFC7049].
> >
> >
> >
> > We would add CoAP/HTTP in the same way ("CoAP is default, but HTTP works
> > the same way"). Then the pubsub-profile could specify which protocol is
> > used in the different profiles.
> >
> 
> CS: Cool. Because, I imagine a client or its AS would follow the same
> protocol, HTTPS,  to talk to the ASes, and then talk to MQTT to RS.
> 
> 
> > (3) In the mqtt_tls profile, the AS grants tokens that identify both
> > “publish” and “subscribe” rights and the topics by adding scopes in the
> > format, e.g. “publish_topic1” “subscribe_topic2/#”..  This format allows
> > representing all publish/subscribe permissions concisely for the client
> > which may be acting both as a publisher and a subscriber.
> >
> > In the coap-pubsub, this is separated between AS1 and AS2. “AS1 hosts the
> > policies about the Broker: what endpoints are allowed to Publish on the
> > Broker.” “The AS2 hosts the policies about the topic: what endpoints are
> > allowed to access what topic. “
> >
> > The coap-pubsub also permits that AS1 can host policies about what
> > endpoints are allowed to Subscribe to the Broker.
> >
> >
> >
> > However, wouldn’t this separation between AS1 and AS2 have the following
> > issue: Publisher P, having the permission to publish to topic1 and hence,
> > successfully getting an access token from AS1, then goes ahead and sends a
> > PUBLISH on topic 2, which it doesn’t have a right to publish.
> >
> > Wouldn't the broker would pass this message to subscribers, and the
> > subscribers would discard the message because the publisher does not belong
> > to their “publishers list” (subscribers have all the public keys of all
> > publishers). Have I missed something, does the draft protect against this
> > at the broker?
> >
> >
> >
> > FP: No, the broker would not accept this message. In fact, during the ACE
> > exchange between Publisher, AS1, and Broker, the Publisher would post a
> > token to the Broker that contains the resource it is allowed to publish to,
> > namely in this case topic 1. If it does have rights to publish to topic 2
> > as well, that would be included in the token. That is 

Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

On Wed, Dec 18, 2019 at 05:27:06AM -0800, Alexey Melnikov via Datatracker wrote:
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-ace-coap-est-17: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> Thank you for this well written document. I have a couple of small DISCUSS
> points and a few minor comments/questions that I would like to discuss.
> 
> DISCUSS:
> 
> 5.4.  Message Bindings
> 
>o  The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content-
>   Format, Block1, Block2, and Accept.  These CoAP Options are used
>   to communicate the HTTP fields specified in the EST REST messages.
>   The Uri-host and Uri-Port Options can be omitted from the COAP
>   message sent on the wire.
> 
> The statement above
> 
>   When omitted, they are logically
>   assumed to be the transport protocol destination address and port
>   respectively.  Explicit Uri-Host and Uri-Port Options are
>   typically used when an endpoint hosts multiple virtual servers and
>   uses the Options to route the requests accordingly.
> 
> and the last quoted statement: How can the sender know whether or not it is Ok
> to omit Uri-Host/Uri-Port?

How do you know when you need to send SNI to a TLS server?  "If you try
without and get a strange certificate back."  I think that a similar
situation is possible here, though of course you may just know from
out-of-band configuration.

> 7.  Parameters
> 
>It is recommended, based on experiments,
>to follow the default CoAP configuration parameters ([RFC7252]).
>However, depending on the implementation scenario, retransmissions
>and timeouts can also occur on other networking layers, governed by
>other configuration parameters.  When a change in a server parameter
>has taken place, the parameter values in the communicating endpoints
>MUST be adjusted as necessary.
> 
> The last sentence: use of MUST with passive voice is really unhelpful here.
> Adjusted by whom? How can this MUST be satisfied?
> 
> 
> --
> COMMENT:
> --
> 
> Comment:
> 
> 5.1.  Discovery and URIs
> 
>Clients and servers MUST support the short resource EST-coaps URIs.
> 
> Just to clarify: the original EST URIs are prohibited in COAP-EST?

My understanding is that the servers also have to support the original
(long) EST paths.

-Ben

> In 5.8:
> 
>In the case where the asymmetric encryption key is suitable for
>transport key operations the generated private key is encrypted with
>a symmetric key which is encrypted by the client-defined (in the CSR)
> 
> I would break up this sentence into 2 to make it clearer, as I initially read
> this as 2 encryption operations applying to the generated private key itself.
> So I suggest something like:
> 
>  In the case where the asymmetric encryption key is suitable for
>  transport key operations the generated private key is encrypted with
>  a symmetric key. The symmetric key itself is encrypted by the client-defined
>  (in the CSR)
> 
>asymmetric public key and is carried in an encryptedKey attribute in
>a KeyTransRecipientInfo structure.
> 
>Finally, if the asymmetric
>encryption key is suitable for key agreement, the generated private
>key is encrypted with a symmetric key which is encrypted by the
>client defined (in the CSR) asymmetric public key and is carried in
>an recipientEncryptedKeys attribute in a KeyAgreeRecipientInfo.
> 
> As above.
> 
> 

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

Re: [Ace] AD review of draft-ietf-ace-oscore-profile-08

[Benjamin Kaduk]

Hi Francesca,

Sorry to cut this so close to the wire...I was on vacation and came back to
a sizeable inbox.

On Mon, Feb 17, 2020 at 03:55:29PM +, Francesca Palombini wrote:
> Hi Ben,
> 
> I am now done with updating the draft following most of your review comments. 
> Out of the 105, I have implemented 88 in the draft, while those left need 
> agreement in the wg as previously mentioned, or require your OK (see inline).
> 
> You can see the result of the update in the PR here: 
> https://github.com/ace-wg/ace-oscore-profile/pull/25  If you give me the 
> go-ahead, I will merge this PR and submit a new version, and then we can 
> continue working on the open issues.

I will have to download the changes locally to view them, as the in-browser
viewer does not do well with the long lines.

> These open issues are:
> 
> * The mechanism of letting the RS pick the identifier of the client is not 
> worth the additional complexity.
>   6, 7, 32, 61, 65,
> * Recommendation about length of nonces N1 and N2 to use.
>   5, 52
> * Define and register 2 new ACE parameters to transport the nonces used in 
> the exchange, instead of using "cnonce".
>   3,  53, 60
> * Check with IANA
>   102
> 
> I hope to discuss these in the mailing list (continuing on the separate 
> thread), and at the interim. 
> 
> I will cut and paste the rest (46 , 47,  58 , 67 , 92 + a couple of more) 
> which I have answered below, whatever is not reported below I found no issue 
> in doing the modifications you suggested, or is covered by the open points I 
> mentioned. Please do bring any of those I do not touch on up again if you 
> feel they were not solved in the PR.
> 
> Thanks again for your extensive review!
> Francesca
> 
> On 03/02/2020, 05:06, "Benjamin Kaduk"  wrote:
> > 29.   The AS MUST also assign an identifier to the RS (serverId), 
> MAY
> >assign an identifier to the client (clientId), and MAY assign an
> >identifier to the context (contextId).  These identifiers are 
> then
> >used as Sender ID, Recipient ID and ID Context in the OSCORE 
> context
> >as described in section 3.1 of [I-D.ietf-core-object-security].  
> The
> >couple (client identifier, context identifier) MUST be unique in 
> the
> >set of all clients on a single RS.  Moreover, when assigned,
> >serverId, clientId and contextId MUST be included in the
> >OSCORE_Security_Context, as defined in Section 3.2.1.
> > 
> > When certain fields are optional, we typically have to ask whether 
> it's
> > possible for the two parties to disagree about whether the field is
> > present.  IIUC, the OSCORE context derivation procedure includes 
> enough
> > information to prevent that possibility, but it would be good if 
> someone
> > would confirm that.
> > 
> > FP: That is correct, a number of fields have default values when non 
> present. Hkdf, alg, salt, contextId, rpl. On the other hand, ms, clientId and 
> serverId need to be set.
> 
> Hmm, so there is not a great mechanism to distinguish "absent" from
> "present with default value", but the practical consequences of such an
> attack seem quite limited.
> 
> FP: That is right. I did not add any text about this, as this is more OSCORE 
> implication.

That's okay.

> > 
> > 34. "access_token" : h'a5037674656d7053656e73 ...'
> >   (remainder of access token omitted for brevity)',
> > 
> > In addition to the invalid-CBOR-diagnostic-notation-syntax comment, 
> we
> > also have unbalanced quotes.
> > 
> > FP: Right, but this is not valid CBOR diagnostic notation syntax 
> anyway, do you have a better idea? I do not think it would be useful to have 
> the full token here. Will remove the unbalanced quote.
> 
> This is probably manageable, though we do often see people put a 
> disclaimer
> before the example that  are truncated for readability;
> some other ADs may have other suggestions, too.
> 
> FP: Thanks for the input text :) Now added.
> 
> ...
> 
> > 43.   hkdf:  This parameter identifies the OSCORE HKDF Algorithm.  
> For more
> >   information about this field, see section 3.1 of
> >   [I-D.ietf-core-object-security].  The values used MUST be
> >   registered in the IANA "COSE Algorithms" registry and MUST be
> >   HMAC-based HKDF algorithms.

Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params

[Benjamin Kaduk]

I want to double-check that I'm understanding you correctly.

The idea is that there's ambiguity about how a CWT 'cnf' claim would get
represented as "equivalent" JWT, and that it may not even be possible for
some 'cnf' values?  I'm not entirely sure what the path forward even looks
like, and thus am inclined to believe that I should request an IESG hold on
the publication of draft-ietf-ace-cwt-proof-of-possession.

Is that right?

Thanks,

Ben

On Mon, Jan 20, 2020 at 01:12:08PM -0800, Jim Schaad wrote:
> I started doing testing of my code and I have started to run into some 
> massive problems with the confirmation claim.The COSE version of the POP 
> key registrations cause a problem because of the way the registration 
> template in the document is written.  It currently says:
> 
>  
> 
> JWT Confirmation Method Name:
> 
>  
> 
> Claim Name of the equivalent JWT confirmation method value, as
> 
> registered in [IANA.JWT.Claims 
> <https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-11#ref-IANA.JWT.Claims>
>  ].  CWT claims should normally have
> 
> a corresponding JWT claim.  If a corresponding JWT claim would not
> 
> make sense, the Designated Experts can choose to accept
> 
> registrations for which the JWT Claim Name is listed as "N/A".
> 
>  
> 
> The issue here is the word “equivalent”.  There are two possible 
> interpretations of this:  That this is a similar item in terms of how things 
> are used, but there is no way to encode this item into a JWT.  Or, that this 
> is how one should encode this item in a JWT.  The first interpretation 
> implies that even though one would like to pass a COSE_Key confirmation in a 
> JWT there is no way to do this.  (Yes, one can potentially convert the COSE 
> Key into a JOSE Key but that is not always going to succeed as some keys in 
> one system may not be representable in the other system.) The second 
> interpretation says that you just encode the COSE_Key as JSON and put it into 
> the map with the ”jwk” key and you are happy.  Which of course will not work.
> 
>  
> 
> I had misled myself in the message below as I had missed reading the JWT 
> Confirmation Method Name field in the registration templates.   If you look 
> at the text below, it is hard to know if “COSE_Key” is to be used in a JSON 
> structure (which I had originally assumed) or if “jwk” is supposed to be used 
> in a JSON structure.
> 
>  
> 
>o  Confirmation Method Name: "COSE_Key"
>o  Confirmation Method Description: COSE_Key Representing Public Key
>o  JWT Confirmation Method Name: "jwk"
>o  Confirmation Key: 1
>o  Confirmation Value Type(s): COSE_Key structure
>o  Change Controller: IESG
>o  Specification Document(s): Section 3.2 
> <https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-11#section-3.2>
>   of [[ this document ]]
> 
>  
> 
> At a minimum we should probably clarify the language on this.  And I need to 
> look at the COSE documents and decode if there needs to be some text on 
> encoding in a JSON environment or not.
> 
>  
> 
> Jim
> 
>  
> 
>  
> 
> From: Ace  On Behalf Of Jim Schaad
> Sent: Sunday, January 19, 2020 3:35 PM
> To: 'Brian Campbell' ; 'Seitz Ludwig' 
> 
> Cc: 'Roman Danyliw' ; oauth-ext-rev...@ietf.org; 'Daniel 
> Migault' ; drafts-lastc...@iana.org; 'Ludwig 
> Seitz' ; 'Benjamin Kaduk' ; ace@ietf.org
> Subject: Re: [Ace] Requested review for IANA registration in 
> draft-ietf-ace-oauth-params
> 
>  
> 
> I have managed to merge most of my code that deals with the confirmation 
> claim and I have ended up with a single problem when dealing with 
> confirmations.  If this is going to get fixed, it needs to get fixed in 
> draft-ietf-ace-cwt-proof-of-possession prior to this document finishing 
> processing the EDIT process in the RFC editor.
> 
>  
> 
> All of the items that can appear in a confirmation claim are unique except 
> for the ‘kid’ claim method.  This field is defined as being a text field for 
> JWT (RFC 7800), but it is defined as being a binary field for CWT.  It is a 
> text field when defined in RFC 7800.  I do not anticipate any issues for the 
> definition of a thumbprint as COSE is using a very different format for the 
> definition of thumbprints which will led to a different naming convention.
> 
>  
> 
> Jim
> 
>  
> 
>  
> 
>  
> 
> From: Brian Campbell  <mailto:bcampb...@pingidentity.com> > 
> Sent: Monday, January 13, 2020 10:01 AM
> To: Seitz Ludwig  <mailto:ludwig.se...@combitech.se> >
> Cc: Ludwig Seitz mailto:ludwig_se...@gmx.de> >; Roman 
> Danyliw mailto:r..

Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params

[Benjamin Kaduk]

Thanks for putting the effort in, Brian.

IANA, do you need to assign a new expert to reviewi the JWT Claims
registration request from this document, or are the experts expected to be
self-organizing here?

Thanks,

Ben

On Thu, Jan 23, 2020 at 02:31:20PM -0700, Brian Campbell wrote:
> Apologies, I forgot to reply-all at some earlier point and dropped the
> mailing lists and other cc's off the thread. Added back now.
> 
> And also apologies because I think I need to recuse myself from the DE
> responsibility on the JWT registry request here. I've spent more time than
> I'd like to admit or really have to spare on it and am still struggling to
> understand.
> 
> I appreciate you pointing out the authz-info endpoint in ACE but I still
> don't follow how "rs_cnf" in an access token would really work in practice.
> The client sends the token to the RS's authz-info endpoint on an insecure
> connection or one that has the server auth with potentially different key
> and the RS stores the access token for later use. Then on resource access
> the RS looks up the access token (with respect to the cnf key in it) based
> on the key the client used in establishing a new mutually authentication
> connection to the RS. For the RS to choose a key for server it will use
> during the handshake (and as far as I know the server key is the first in
> the authn process of the handshake) based on the "rs_cnf" in the access
> token, it needs to remember and associate that client and the access token
> with something else (IP address?) that will be available during the
> handshake. It doesn't fit together for me in a way that seems likely to
> work or be interoperable but, like I said, I'm really struggling to
> understand.
> 
> On Thu, Jan 16, 2020 at 12:54 AM Seitz Ludwig 
> wrote:
> 
> > Hi Brian,
> >
> >
> >
> > Comments inline.
> >
> >
> >
> > /Ludwig
> >
> >
> >
> > *From:* Brian Campbell 
> > *Sent:* den 13 januari 2020 21:22
> > *To:* Seitz Ludwig 
> > *Subject:* Re: [Ace] Requested review for IANA registration in
> > draft-ietf-ace-oauth-params
> >
> >
> >
> > Thanks for the response and updates Ludwig,
> >
> >
> >
> > Please bear with me while I try to wrap my head around some things.
> >
> >
> >
> > The JWT registration request for the "rs_cnf" claim points to Sec 3.3
> > <https://tools.ietf.org/html/draft-ietf-ace-oauth-params-08#section-3.3>
> > saying it is "a hint [in the access token] to the RS about which key it
> > should use to authenticate towards the client".  But doesn't the client
> > have to go through the DTLS/TLS handshake with the RS (which is presumably
> > when it authenticates to the client) before it presents the access token?
> > I'm not seeing how this would work as seems the RS won't see the hint until
> > after it needs it.
> >
> >
> >
> >
> >
> > [LS] Not in the ACE flow. We use the access token to establish keys at the
> > RS both for the client and the RS. We have therefore defined a new
> > ACE-OAuth endpoint (authz-info) at the RS. The client can POST access
> > tokens to this endpoint without prior authentication.
> >
> > At that point, the RS only validates the signature/MAC by the AS.
> >
> >
> >
> > Later at the time of access, the corresponding token is linked to the
> > access request via the pop-mechanism and the client/access specific parts
> > are validated (e.g. scope, subject).
> >
> >
> >
> > Hope that clarifies things a bit.
> >
> >
> >
> > On Sat, Jan 11, 2020 at 8:30 AM Seitz Ludwig 
> > wrote:
> >
> > Hello again Brian,
> >
> >
> >
> > Thank you for reviewing this! Indeed the handling of JWT/JSON interactions
> > was handled sloppily here. I will soon issue a draft update that specifies
> > that the JSON-based interactions should use the syntax from RFC7800 while
> > the CBOR-based ones should use ID.ietf-ace-cwt-proof-of-possession.
> >
> >
> >
> > This correction goes for all the use of “cnf”, “req_cnf” and “rs_cnf”.
> >
> >
> >
> > Regards,
> >
> >
> >
> > Ludwig
> >
> >
> >
> > *From:* Ace  *On Behalf Of *Brian Campbell
> > *Sent:* den 10 januari 2020 22:12
> > *To:* Ludwig Seitz 
> > *Cc:* Roman Danyliw ; jwt-reg-rev...@ietf.org; Jim Schaad <
> > i...@augustcellars.com>; The IESG ; ace@ietf.org;
> > drafts-lastc...@iana.org; Benjamin Kaduk 
> > *Subject:* Re: [Ace] Requested review for I

Re: [Ace] AD review of draft-ietf-ace-oscore-profile-08

[Benjamin Kaduk]

On Wed, Jan 29, 2020 at 02:42:34PM +, Francesca Palombini wrote:
> Hi Ben,
> 
> Thank you so much for this very thorough and in-depth review! 
> 
> I have started a PR (https://github.com/ace-wg/ace-oscore-profile/pull/25 ) 
> where I plan to include all the review comments. I have started with the 
> editorial fixes, which I have collected in one issue: 
> https://github.com/ace-wg/ace-oscore-profile/issues/24 
> 
> The details of answers and additional questions for clarification are inline, 
> I also noted with "OK" the points where I agree with your suggestion and 
> don't see any problem implementing in the PR. I will keep the numbering 
> consistent in the mail thread and in the github to make sure everything is 
> covered.
> 
> Additionally, you made a number of points I'd like to get wg opinion on:
> 
> * The mechanism of letting the RS pick the identifier of the client is not 
> worth the additional complexity. So I propose we revert that, and go back to 
> AS MUST pick the clientId, the clientId MUST be included in the token. This 
> will only add some considerations about the scenario has several-AS-per-RS, 
> in which case these AS need to be synchronized on clientIds they give out. 
> (6., 21., 61., 65.)
> * Recommendation about length of nonces N1 and N2 to use. The wg agreed on 64 
> bits, now Ben suggests to use 128 bits nonces. Reminder: these nonces are 
> appended to the input salt to create the Master Salt, to run the HKDF and 
> derive the keys. Also consider that OSCORE appendix B2 has a similar setting 
> and does some considerations about that, mentioning that "typically nonces of 
> at least 8 bytes will be used".
> * Define and register 2 new ACE parameters to transport the nonces used in 
> the exchange, instead of using "cnonce". (see point 3., 53.)
> * Define the nonces as bstr so that length value is encoded. (7.)
> https://tools.ietf.org/html/rfc8613#page-72 
> * Editorial: point 75.
> 
> Thanks again!
> Francesca
> 
> On 07/01/2020, 17:40, "Ace on behalf of Benjamin Kaduk" 
>  wrote:
> 
> Hi all,
> 
> Some high-level points before the section-by-section commentary:
> 
> 1.I'm a little confused by the registry we are creating in Section 9.2.
> While it's clear that we need something to specify the CBOR map key
> labels to encode the structure for transit, it's not clear that we need
> easy extensibility vs.  a fixed table.  A registry implies expectations
> of future additions, but draft-ietf-core-object-security did not feel a
> need to make a registry for future extensions; what has changed in the
> past few months that makes extensibility needed now?  Why is this
> document the right place to create the registry as opposed to that one?
> 
> FP: Why extensibility now: an example is the Group OSCORE profile, which 
> extends this registry with fields that the OSCORE profile does not need, 
> related to countersignatures (see 
> https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-04#page-22 ). 
> The difference between OSCORE (RFC8613) and this doc is that in OSCORE the 
> security context is never sent on the wire, it is assumed to be 
> pre-established, while here we needed to define a structure to send. Yes, we 
> could avoid defining the registry and define all the fields (we can think of 
> right now), including those for ace-key-groupcomm-oscore as a fixed table, 
> but we thought this would be better, also considering that the OSCORE 
> security context could get extended in a future version of OSCORE.

I would suggest that we have some discussion about how "stock OSCORE"
treats the security context as a logical entity local to each endpoint, but
since we need to serialize it, the registry is required for extensibility.
We will probably still get questions from other IESG members about the
relationship between this registry and the core OSCORE spec, but we can
explain as needed.

> 2.We are in some sense defining a new substructure within "kid" values (a
> CBOR-encoded array of one or two elements) for usage by things using
> this profile.  That's probably not problematic, as the "kid" can be an
> arbitrary bstr and its interpretation is up to the recipient -- any
> recipient that implements this profile will know to handle the
> substructure, but it does feel a little unusual and perhaps worth an
> early note.  (IIUC, we also need to be careful about actually providing
> the bstr framing in our examples.)
> 
> FP: Ok, I will add an early note and also make sure the array is wrapped in a 
> bstr. Do you have any opinion on where best to add this note? Kid appea

[Ace] Fwd: [OAUTH-WG] Doodle Poll for scheduling a discussion on proof-of-possession tokens

[Benjamin Kaduk]

Hi all,

The OAuth WG is planning to talk about proof-of-possession tokens; it would
be great if some of the ACE WG participants could contribute with our
experiences so far.

-Ben

On Mon, Jan 13, 2020 at 05:18:57PM +, Hannes Tschofenig wrote:
> Hi all,
> 
> at the Singapore IETF meeting we talked about setting time aside for 
> discussing proof-of-possession tokens.
> 
> To schedule a call we put a Doodle poll together:
> https://doodle.com/poll/sqhbeeg6knp435ag
> 
> Please let us know by the end of the week what dates work for you.
> 
> Ciao
> Hannes & Rifaat
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you. IMPORTANT NOTICE: The contents of this 
> email and any attachments are confidential and may also be privileged. If you 
> are not the intended recipient, please notify the sender immediately and do 
> not disclose the contents to any other person, use it for any purpose, or 
> store or copy the information in any medium. Thank you.

> ___
> OAuth mailing list
> oa...@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

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

[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

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

[Benjamin Kaduk]

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.

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.

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 client is connecting (and thus what PSK to use), and what
  does the client actually *put* in the "psk_identity" field?  (The
  other aspects of "how to select a proof-of-possession protocol" seem
  to fall out naturally from the DTLS usage.)
- whether/how introspection is used?
- give more details of what this profile mandates when used for
  client/AS interactions (as mentioned above)
- explicitly state that the authz-info endpoint is unprotected (or that
  it might be protected if, e.g., the RS has a trustable certificate
  that would be used instead of RPK or PSK, or by supplying the
  token as the "psk_identity" when symmetric PoP is used, or by only
  doing server-authentication with RPK as known by the client by the
  rs_cnf access information

And now, on to the section-by-section comments.

Section 1

   a DTLS session.  The communication between client and authorization
   server may also be secured with DTLS.  This specification supports
   DTLS with Raw Public Keys (RPK) [RFC7250] and with Pre-Shared Keys
   (PSK) [RFC4279].

[DTLS 1.3 will inherit TLS 1.3's built-in support for (so-called
"external") PSKs.]

   The DTLS handshake requires the client and server to prove that they
   can use certain keying material.  In the RPK mode, the client proves
   with the DTLS handshake that it can use the RPK bound to the token
   and the server shows that it can use a certain RPK.  The access token
   must be presented to the resource server.  For the RPK mode, the
   access token needs to be uploaded to the resource server before the
   handshake is initiated, as described in Section 5.8.1 of the ACE
   framework [I-D.ietf-ace-oauth-authz].

This seems to be making some implicit assumptions about the message flow
that have not yet been 

Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

On Fri, Dec 20, 2019 at 06:16:34PM +0100, Carsten Bormann wrote:
> On Dec 20, 2019, at 17:34, Klaus Hartke  wrote:
> > 
> > I would prefer if draft-ietf-ace-coap-est didn't say anything here,
> > since the Uri-Host and Uri-Port options and whether they should be
> > omitted or not is entirely specified by CoAP [RFC7252].*
> 
> Klaus has an important point here.
> 
> We need to be **much more** vigilant about specifications messing with their 
> normative references.
> Saying how they are used, yes, but re-stating (or, worse, re-interpreting) 
> normative material from those references is prone to creating dialects that 
> no longer interoperate with their unadulterated originals.  Unless these are 
> hopelessly broken(*) and this is the only way to fix them, this is a MUST NOT.

Indeed; thank you Klaus and Carsten for reiterating it.

-Ben

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

Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params

[Benjamin Kaduk]

On Mon, Dec 23, 2019 at 02:32:15PM -0700, Brian Campbell wrote:
> The OAuth Token Introspection Response registry
> 
> already has an entry for "cnf", which makes the first request in
> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section-9.4
> rather problematic.

Indeed.

It seems like the right thing to do is probably just to drop that entry
from the registration request (even though the existing description of
"Confirmation" is kind of lousy), since we are using it with the same
semantics as from 7800 and mtls.

Sorry for missing that initially!

-Ben

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

Re: [Ace] FW: [IANA #1157486] Last Call: (Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)) to Proposed

[Benjamin Kaduk]

On Sat, Dec 21, 2019 at 11:07:34AM -0800, Jim Schaad wrote:
> Personal opinion,
> 
> I think that we should be requesting a separate page.  I think we are going 
> to have enough different registries that keeping them separate from OAuth is 
> going to be useful in preventing confusion.  For the mapping registries, it 
> might be useful to see if IANA can give us a link from the mapping registry 
> to the OAuth registry.

I think IANA can do that sort of link, and am inclined to agree about
having a separate page.

-Ben

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

[Ace] AD review of draft-ietf-ace-oscore-profile-08

[Benjamin Kaduk]

Hi all,

Some high-level points before the section-by-section commentary:

I'm a little confused by the registry we are creating in Section 9.2.
While it's clear that we need something to specify the CBOR map key
labels to encode the structure for transit, it's not clear that we need
easy extensibility vs.  a fixed table.  A registry implies expectations
of future additions, but draft-ietf-core-object-security did not feel a
need to make a registry for future extensions; what has changed in the
past few months that makes extensibility needed now?  Why is this
document the right place to create the registry as opposed to that one?

We are in some sense defining a new substructure within "kid" values (a
CBOR-encoded array of one or two elements) for usage by things using
this profile.  That's probably not problematic, as the "kid" can be an
arbitrary bstr and its interpretation is up to the recipient -- any
recipient that implements this profile will know to handle the
substructure, but it does feel a little unusual and perhaps worth an
early note.  (IIUC, we also need to be careful about actually providing
the bstr framing in our examples.)

I'm concerned about the usage of "cnonce" to carry both N1 and N2,
neither of which correspond to the "cnonce" behavior in the core
framework; I think we should pick a different parameter name for the
differeng semantic usage.  Specifically, the core-framework "cnonce" is
a tool to give RSes some modicum of replay protection -- it verifies
that the client's authorization in the token is "fresh", since the token
includes the random nonce generated by the RS and conveyd to the AS via
the client.  This document uses a parameter named "cnonce" in two ways:
(1) to convey the client-generated nonce N1 to the RS in the authz-info
request; this is giving the client contributory behavior to the
ephemeral randomness input to the Security Context computation but does
not provide any sort of replay-protection in and of itself
(2) to convey the RS-generated nonce N2 back to the client in the
authz-info response; this does serve as replay protection in some sense,
but in that it serves to cause repeated posting of the same token (as
might occur in a replay attack) to generate a different OSCORE context
(due to the RSes contributory nature) so that the resulting key material
will be unique for a given association, as opposed to detecting and
blocking replay outright.  I think all three uses should have distinct
parameter names, based on my current understanding.

We mention several times about getting protection from AEAD nonce/key
reuse, but to some extent leave it to the reader to figure out how that
works.  Specifically, the only guidance we give on nonce selection is
for our N1 and N2 that go into the Master Salt; we don't say how varying
the Master Salt like that will cause the generated keys and (common) IVs
to differ across runs, thus by construction preventing the collision of
(key, nonce) pairs.  (Implementation carelessness that just reuses
key+nonce for a given Security Context is still possible, of course.)

In a related vein, we do not get into full detail about the
cryptographic role played by N1 and N2, so as to make the reader
confident that our 64-bit recommendation does provide full
Internet-grade security (as opposed to a weakened "IoT" variant).  I'm
not specifically concerned, but we may get some reviewers asking for
more detail.

I am, however, concerned about the exposure to an RFC 3552-style
attacker for unprotected authz-info responses.  There are two main
aspects I'm concerned about: identifier selection and nonce selection.
Letting the server override the client's idea of its own identity (even
when the AS has given the client an identifier!) seems to increase the
risk of a client being tricked into impersonating a different client,
and the stated justification (letting the RS preserve uniqueness)
doesn't seem to hold up in our one-AS-per-RS stated scope, where the AS
can equally well do so.  Based on what I know right now, it doesn't feel
like we're at the right point on the cost/benefit curve.  For the nonce
selection, this comes into play due to the lack of injectivity for the
mapping of initial AS-generated salt, N1, and N2 into the Master Salt.
Specifically, if a client chooses an N1 that's a prefix of some other N1
that was used, then the attacker can send an "N2" that contains the tail
end of that other N1 plus the actual N2 picked by the server in that
other exchange, causing a full nonce collision and having the
AS-generated portion be the only difference in Master Salt between
security contexts.  Using a length prefix for the fields being
concatenated provides injectivity and thwarts this type of attack.

There are a few places where I'm not entirely sure how the protocol flow
works for the case where the RS is (re)assigning the clientId; I've
tried to note them in the section-by-section comments.

On to the section-by-section notes:

Section 1

Re: [Ace] [EXTERNAL] Re: [Cwt-reg-review] [IANA #1158953] Requested review for IANA registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

[Benjamin Kaduk]

On Wed, Mar 11, 2020 at 11:39:00PM +, Mike Jones wrote:
> [Adding correct e-mail addresses for Chuck, who recently joined Visa]
> 
> 
> 
> There are two reasons that I believe not using up one of the scarce one-byte 
> claim identifiers for "scope" is appropriate:
> 
>   1.  The claim values for scopes are not short themselves.  They are sets of 
> ASCII strings separated by spaces. So the percentage difference in the total 
> claim representation from adding a single byte will typically be small..

ACE allows the scope to be a binary value and to use a different convention
than space-separated for multi-value scopes.

>   2.  The single-byte claim identifiers already registered at 
> https://www.iana.org/assignments/cwt/cwt.xhtml are claims that are likely to 
> be useful to diverse sets of applications, and therefore merit the short 
> identifiers; whereas, the scope claim is specific to the ACE OAuth protocol 
> and not applicable to diverse sets of applications.  It's reasonable to give 
> protocol-specific claim identifiers 2-byte representations.

(This point I don't have a good response for.)

-Ben

> 
> 
> I'd be interested to hear from the two other designated experts on my 
> assessment of the situation: Hannes and Chuck.
> 
> 
> 
>-- Mike
> 
> 
> 
> -Original Message-
> From: Cwt-reg-review  On Behalf Of Ludwig 
> Seitz
> Sent: Saturday, February 29, 2020 6:25 AM
> To: drafts-expert-rev...@iana.org; cwt-reg-rev...@ietf.org
> Cc: draft-ietf-ace-oauth-au...@ietf.org; ace@ietf.org
> Subject: [EXTERNAL] Re: [Cwt-reg-review] [IANA #1158953] Requested review for 
> IANA registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)
> 
> 
> 
> On 2020-02-26 00:58, Amanda Baber via RT wrote:
> 
> > Ludwig, Hannes,
> 
> >
> 
> > Can you confirm that you can make the CBOR Web Token Claim change
> 
> > requested below?
> 
> >
> 
> > We also have Chuck Mortimore listed as an expert for this registry,
> 
> > but our message to his Salesforce address bounced.
> 
> >
> 
> > Best regards,
> 
> >
> 
> > Amanda Baber Lead IANA Services Specialist
> 
> >
> 
> 
> 
> I strongly disagree with the assessment that the scope claim should be pushed 
> into the two-byte range.
> 
> 
> 
> The reason we introduced the scope claim is that an ACE RS typically does not 
> have a direct connection to the AS, and is therefore unable to retrieve the 
> scope of an access token from other sources than the access token itself.  I 
> therefore assert that ACE access tokens would often need to contain this 
> claim in order to inform the RS.
> 
> Since one of the major drivers of the ACE work has been to reduce the 
> authorization overhead (otherwise we could just have used vanilla OAuth 2.0), 
> I find it strange to needlessly add to the overhead by making the encoding of 
> a frequently used claim longer than necessary.
> 
> 
> 
> I am willing to listen to the arguments that have lead the expert reviewer to 
> denying a value in the one-byte range, and discuss the reasoning further on 
> list.
> 
> 
> 
> Regards,
> 
> 
> 
> Ludwig
> 
> 
> 
> 
> 
> > On Tue Feb 18 22:42:22 2020, 
> > michael.jo...@microsoft.com wrote:
> 
> >> I'm mostly OK with these registrations, however, DO NOT assign the
> 
> >> value 9 to "scope".   Rather, please put it in the two-byte range
> 
> >> - for instance, with the value 41.
> 
> >>
> 
> >> -- Mike
> 
> >>
> 
> >> -Original Message- From: Cwt-reg-review
> 
> >> mailto:cwt-reg-review-boun...@ietf.org>> 
> >> On Behalf Of Sabrina Tanamal via RT
> 
> >> Sent: Tuesday, February 18, 2020 1:06 PM Cc:
> 
> >> cwt-reg-rev...@ietf.org Subject: 
> >> [EXTERNAL] [Cwt-reg-review] [IANA
> 
> >> #1158953] Requested review for IANA registration in
> 
> >> draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)
> 
> >>
> 
> >> Hi all,
> 
> >>
> 
> >> Resending this request for draft-ietf-ace-oauth-authz.
> 
> >>
> 
> >> Thanks,
> 
> >>
> 
> >> Sabrina Tanamal Senior IANA Services Specialist
> 
> >>
> 
> >>> On Sat Dec 21 11:37:11 2019, 
> >>> ludwig_se...@gmx.de wrote:
> 
>  Hello CWT registry reviewers,
> 
> 
> 
>  the IESG-designated experts for the CWT claims registry have asked
> 
>  me to send a review request to you about the claims registered
> 
>  here:
> 
> 
> 
>  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ft
> 
>  o
> 
> 
> 
> 
> 
> ols.ietf.org%2Fhtml%2Fdraft-ietf-ace-oauth-authz-29%23section-
> 
>  8.13
> 
>  mp;data=02%7C01%7CMichael.Jones%40microsoft.com%7Ce23f64ac1ad74269c
> 
>  3
> 
> 
> 
> 
> 
> c408d7b4b65d45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63717656
> 
>  7656665548sdata=r01W5Bx0gJh9ZPH8eNS%2BY765CnGq11DkknsHYQ751Dk%
> 
>  3
> 
> 
> 
> 
> 
> Dreserved=0
> 
> 
> 
>  Thank you in advance for you review 

Re: [Ace] ace - New Interim Meeting Request

[Benjamin Kaduk]

FYI these showed up in the system as duplicates.
I think I approved one set and cancelled the other, but please let me know
if I fat-fingered it.

-Ben

On Sun, Apr 19, 2020 at 07:19:57PM -0700, IETF Meeting Session Request Tool 
wrote:
> 
> A new interim meeting series request has just been submitted by Daniel 
> Migault.
> 
> This request requires approval by the Area Director of the Security Area
> 
> The meetings can be approved here: 
> https://datatracker.ietf.org/meeting/interim/request/interim-2020-ace-06
> https://datatracker.ietf.org/meeting/interim/request/interim-2020-ace-07
> 
> 
> Meeting: 1
> -
> Working Group Name: Authentication and Authorization for Constrained 
> Environments
> Area Name: Security Area
> Session Requester: Daniel Migault
> 
> Meeting Type: Virtual Meeting
> 
> Session 1:
> 
> Date: 2020-05-18
> Start Time: 10:00 America/New_York
> Duration: 01:30
> Remote Participation Information: 
> https://ietf.webex.com/ietf/j.php?MTID=md8728a7cd7aa263c70a3c712da89f3ee
> Agenda Note: 
> 
> -
> Meeting: 2
> -
> Working Group Name: Authentication and Authorization for Constrained 
> Environments
> Area Name: Security Area
> Session Requester: Daniel Migault
> 
> Meeting Type: Virtual Meeting
> 
> Session 1:
> 
> Date: 2020-06-22
> Start Time: 10:00 America/New_York
> Duration: 01:30
> Remote Participation Information: 
> https://ietf.webex.com/ietf/j.php?MTID=md8728a7cd7aa263c70a3c712da89f3ee
> Agenda Note: 
> 
> -
> 
> 

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

Re: [Ace] I-D Action: draft-ietf-ace-oscore-profile-10.txt

[Benjamin Kaduk]

Hi Francesca,

I took a look through the updates and we are looking in quite good shape.

I filed https://github.com/ace-wg/ace-oscore-profile/pull/30 with a few
final suggested tweaks, though I cannot quite say that they are all just
editorial.  In particular, I remove text about "the client MUST include the
access token using the correct CBOR label (e.g., "cwt" for CWT, "jwt" for
JWT")" since I didn't understand how that was expected to work and it
wasn't reflected in the example.  I also propose to remove "verification of
access rights" from the discussion of the procedure to upload a token that
updates the access rights on a given security context -- the "verification
of access rights" is superficially parallel to the procedures specified in
the previous paragraph, but the previous paragraph talks about regular
OSCORE exchanges (that do operations that have access control applied to
them), whereas the text in question is just for the one-shot "upload new
token" operation.

Once the text from Jim arrives, then we should be all set on this one ...
to wait for the DTLS profile, that is, so the group of four documents goes
to the IESG as a unit.

Thanks!

-Ben

On Tue, Mar 10, 2020 at 09:08:11AM +, Francesca Palombini wrote:
> Hi Ben, ace,
> 
> These 2 updates (09 and 10) address almost all the AD review comments of v-08.
> 
> V-09 covers the majority of them, as we discussed in this thread: 
> https://mailarchive.ietf.org/arch/msg/ace/rgVfs3dzcWQnNlXn331DdpQfwwQ/ and 
> listed in this issue: https://github.com/ace-wg/ace-oscore-profile/issues/26 
> 
> v-10 covers the remaining: 
> 
> * The mechanism of letting the RS pick the identifier of the client is not 
> worth the additional complexity.
>   6, 7, 32, 61, 65,
> * Define and register 2 new ACE parameters to transport the nonces used in 
> the exchange, instead of using "cnonce".
>   3,  53, 60
> 
> The following issue is still open (during the interim meeting Jim volunteered 
> to give a try to draft some text, and we really appreciate his help) and we 
> should pinpoint what we need to include in the document about: 
> 
> * Recommendation about length of nonces N1 and N2 to use.
>   5, 52
> 
> 
> Thanks,
> Francesca
> 
> 
> On 09/03/2020, 17:44, "Ace on behalf of internet-dra...@ietf.org" 
>  wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Authentication and Authorization for 
> Constrained Environments WG of the IETF.
> 
> Title   : OSCORE profile of the Authentication and 
> Authorization for Constrained Environments Framework
> Authors : Francesca Palombini
>   Ludwig Seitz
>   Göran Selander
>   Martin Gunnarsson
>   Filename: draft-ietf-ace-oscore-profile-10.txt
>   Pages   : 30
>   Date: 2020-03-09
> 
> Abstract:
>This memo specifies a profile for the Authentication and
>Authorization for Constrained Environments (ACE) framework.  It
>utilizes Object Security for Constrained RESTful Environments
>(OSCORE) to provide communication security, server authentication,
>and proof-of-possession for a key owned by the client and bound to an
>OAuth 2.0 access token.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-10
> https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-10
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-10
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> ___
> 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

[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 

Re: [Ace] Update of access rights

[Benjamin Kaduk]

Hi Francesca,

Thanks for assembling this very nice writeup: I think it's quite helpful
to get clarity, given that Ludwig thought this was already the case but I
couldn't come to that conclusion based on my review of the document.

I just have one (maybe nitpicky) comment: when identifying things by 'kid'
we have to account for the possibility of collisions, so probably we should
talk about the "same key".  Assuming I've retained correctly Jim's
teachings, at least...this one I've had trouble with :)

Thanks again,

Ben

On Tue, May 05, 2020 at 01:36:41PM +, Francesca Palombini wrote:
> Hi Ace chairs, DTLS authors, Ace framework authors, Ben,
> 
> TL;DR: we propose some changes on the OSCORE profile for the "update of 
> access rights" scenario. We have comments for the DTLS profile and the ACE 
> framework regarding this scenario, and we ask for feedback from ACE OSCORE 
> implementers and Ace in general.
> 
> In an attempt to answer Jim's 
> (https://github.com/ace-wg/ace-oscore-profile/issues/20) and Ben's 
> (https://github.com/ace-wg/ace-oscore-profile/pull/30) review of the OSCORE 
> profile, we have been thinking more about the case of updating access rights. 
> This has revealed to us authors that something is missing from the document, 
> and I believe that this part is not explicitly covered in the DTLS profile 
> either, hence this email. 
> 
> This is the scenario, and what is currently defined in the OSCORE profile:
> 
> 1. Client retrieves access token T1 from AS
> 2. Client posts T1 to RS, together with nonce N1
> 3. RS replies with 2.01 and nonce N2
> 4. Client and RS derive OSCORE Sec Ctx "Sec1" from T1 ("osc" object), N1, N2
> 5. Client uses Sec1 to protect its request to RS
> 6. RS uses Sec1 to verify request. Verification success => Sec1 is validated 
> and associated with T1 (at the RS)
> 
> 7. Client wants to update its access rights: retrieves T2 from AS. Note that 
> this T2 has different authorization info, but does not contain input keying 
> material ("osc"), only a reference to identify Sec1 ("kid" in "cnf")
> 8. Client posts T2 to RS, together with nonce N1'
> 9. RS replies with 2.01 and nonce N2'
> 10. Client and RS derive OSCORE Sec Ctx "Sec2" from T1 keying input material 
> ("osc" object), N1', N2'
> 11. Client uses Sec2 to protect its request to RS
> 12. RS uses Sec2 to verify request. Verification success => Sec2 is validated 
> and associated with T2 (at the RS) ; T1 is removed ; Sec1 is removed
> 
> In the document right now, we are missing the exact description of how in 8. 
> RS identifies that this is an update of access rights for C, aiming at 
> replacing T1. We propose to add text stating that (in 3. and 9.) RS MUST 
> check the kid (in the "kid" in the "cnf" of the access token), and match it 
> with existing security contexts, to realize that this is an update for an 
> existing token associated to the sec ctx identified by kid.
> 
> Moreover, while comparing with DTLS profile, we realized there is no reason 
> for which 8. should be sent unprotected. In fact, doing so opens up to 
> possible attacks where an old update (token non expired) is re-injected to 
> the RS by an adversary:
> 
> * Client sends T1 to RS  --> accepted
> * Client sends update of access rights T2 --> accepted
> * Client sends update of access rights T3 --> accepted
> * Malicious node re-sends T2 --> accepted
> 
> Of course that could be mitigated with expiration times and with checking 
> "issued at time" field (which is optional). But we believe even though these 
> are good points (which might actually be worth adding to the framework), 
> sending the token to the RS over the existing protected channel solves this 
> issue. So we propose that 8. is protected with OSCORE and Sec Ctx Sec1. For 
> DTLS authors: I believe Jim has extrapolated from your document that that is 
> the case for the DTLS profile already, i.e. POST token to RS for update of 
> access rights is over DTLS; I think it would be worth explicitly stating that 
> in the DTLS profile.
> 
> Additionally, analogously to DTLS where the same channel is kept even if 
> access rights are updated, I do not see any reason at this point to have the 
> endpoints re-derive a new security context. This is the biggest change I 
> propose, and can be summarized by replacing the points above as follows:
> 
> 7. Client wants to update its access rights: retrieves T2 from AS. Note that 
> this T2 has different authorization info, but does not contain input keying 
> material, only a reference to identify Sec1 
> 8. Client posts T2 to RS, *without nonce* *protected with Sec1*
> 9. RS *verifies that this is an update of access right, replacing T1 
> (associated with Sec1) ; Sec1 is associated with T2; T1 is removed *; RS 
> replies with 2.01 *without nonce* *protected with Sec1*
> 10. Client uses *Sec1* to protect its request to RS
> 
> I can already see the objection from implementers: the authz-info endpoint at 
> the RS becomes 

Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy

[Benjamin Kaduk]

On Thu, Sep 10, 2020 at 02:46:43PM -0400, Michael Richardson wrote:
> 
> John Mattsson  wrote:
> > - That RS shares the AS address with anybody that asks can be a severe
> > privacy problem. If RS is a medical device, the AS address can reveal
> > sensitive information. If RS is a blood pressure sensor it could
> > e.g. be “AS address =
> > coaps://as.hopkinsmedicine.org/kimmel_cancer_center/”
> 
> > The requirement "the client MUST be able to determine whether an AS has
> > the authority to issue access tokens for a certain RS. This can for
> > example be done through pre-configured lists, or through an online
> > lookup mechanism that in turn also must be secured." indicates that C
> > is required to have another mechanism to determine the AS for a
> > specific RS and that the unauthorized AS address is completely
> > redundant.
> 
> This is a hard problem.
>   Q: "Who are you?"
>   A: "Depends upon who is asking! Who are you?"
>   A: "Depends upon who is asking! Who are you?"
>   ...
> 
> The DNS-SD WG produced rfc8882, but as I understand it,
>https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-privacy-05
> was abandonned because the WG did not see implementation/energy.
> I can't seem to find the thread discussing that state.

Interestingly, the corresponding requirements document was just published
recently as RFC 8882.

"A problem with no solution is a hard problem"...

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

[Ace] "default value" for authz-info endpoint

[Benjamin Kaduk]

Hi all,

I was prompted by the discussion at the interim to look more closely at
what we say about the "default name" for endpoint URIs, e.g., the
authz-info endpoint.  The last paragraph of
https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-5.8.1
says:

   The default name of this endpoint in an url-path is '/authz-info',
   however implementations are not required to use this name and can
   define their own instead.

I've gotten advice from some URI experts that this doesn't give an
easy/discoverable path (pun intended) to using a non-default value, which
is problematic from the perspective of BCP 190 (and we should expect to get
discussed at IESG evaluation time).  This sort of issue goes away if we
allocate a well-known URI for authz-info from
https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml and
have that be the default.  In particular, that wouldn't actually stop any
deployments from using /authz-info, but it does mean they'd have to
knowingly "opt in" to doing so.

What do people think?

Thanks,

Ben

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

Re: [Ace] "default value" for authz-info endpoint

[Benjamin Kaduk]

Hi Ludwig,

I'm confident that a well-known URI (or link relation) for discovery of RS
configuration/parameters would address the BCP 190 concerns.  What we need
is an obvious path to not stomp on the server owner's namespace, and
whether we do that by letting the server tell us what what path to use or
by constraining ourself to a well-specified cordoned-off corner reserved
for our use is up to us.

Thanks for all the ideas and follow-up discussion!

-Ben

On Mon, Jun 01, 2020 at 09:13:13AM +, Seitz Ludwig wrote:
> Hi Ben,
> 
> I had a look at the well-known URI list at IANA and it seems that for vanilla 
> OAuth 2.0 endpoints (authorization, token, introspect) there are no 
> well-known URI:s either. What exists is an URI used by the authorization 
> server to self-describe (including attributes giving the values of the 
> endpoint's URIs).
> 
> So my interpretation would be that instead of defining a well-known URI for 
> authz-info, we need to define an attribute that a Resource Server can include 
> in its well-known information to identify the authz-info endpoint URI it is 
> exposing. 
> 
> @Carsten (or other core experts): Would it make sense to define a new 
> attribute in the /.well-known/core format for Resource Servers using coap?
> 
> /Ludwig
> 
> 
> -----Original Message-
> From: Ace  On Behalf Of Benjamin Kaduk
> Sent: den 31 maj 2020 00:36
> To: ace@ietf.org
> Subject: [Ace] "default value" for authz-info endpoint
> 
> Hi all,
> 
> I was prompted by the discussion at the interim to look more closely at what 
> we say about the "default name" for endpoint URIs, e.g., the authz-info 
> endpoint.  The last paragraph of
> https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-5.8.1
> says:
> 
>The default name of this endpoint in an url-path is '/authz-info',
>however implementations are not required to use this name and can
>define their own instead.
> 
> I've gotten advice from some URI experts that this doesn't give an 
> easy/discoverable path (pun intended) to using a non-default value, which is 
> problematic from the perspective of BCP 190 (and we should expect to get 
> discussed at IESG evaluation time).  This sort of issue goes away if we 
> allocate a well-known URI for authz-info from 
> https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml and 
> have that be the default.  In particular, that wouldn't actually stop any 
> deployments from using /authz-info, but it does mean they'd have to knowingly 
> "opt in" to doing so.
> 
> What do people think?
> 
> Thanks,
> 
> Ben
> 
> ___
> 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] IETF 108 tentative agenda and presentations (Daniel Migault)

[Benjamin Kaduk]

On Tue, Jul 21, 2020 at 04:31:05PM -0400, Michael Richardson wrote:
> 
> Mohit Sahni  wrote:
> > To give some background, this draft is an extension of Light Weight CMP
> > Profile (
> > https://tools.ietf.org/html/draft-ietf-lamps-lightweight-cmp-profile-02)
> > draft currently under development in the LAMPS WG. We discussed the 
> "CMPv2
> > over CoAP" draft in the LAMPS WG and figured out that ACE WG is a more
> > appropriate place for this draft. However, Jim suggested that we will 
> need
> > to modify the charter  of the ACE WG to adopt this draft.
> 
> We did est-over-coaps [still in the queue], why shouldn't we do 
> cmp-over-coap(s)?

It may just be that "est-over-coaps is so obviously us" that I didn't check
the charter carefully at that time.  But, at this point, we're probably
overdue for a recharter anyway, as the core framework is making its way to
the IESG.

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

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

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

[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&quo

Re: [Ace] Working Group Adoption Call for draft-bormann-core-ace-aif

[Benjamin Kaduk]

On Wed, Jul 15, 2020 at 01:51:39PM -0700, Jim Schaad wrote:
> I had been holding off doing an adoption call waiting for a formal request
> to adopt it.  However, given that this is now a dependency for three
> different WG documents I think we need to do this now.
> 
> Adoption call for
> https://datatracker.ietf.org/doc/draft-bormann-core-ace-aif/ 
> 
> This document provides a template for an authorization information format
> (AIF) using a CDDL generic.  Questions to be answered:
> 
> 1.  Do you think the ACE WG should adopt this document?  If not please
> provide some reasoning.

Refreshing my memory of the WG charter, it seems like this can be in scope,
but we should be sure to consider what analogues already exist in
non-constrained systems, and whether we are in fact creating something
generally new and broadly useful.

-Ben

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

Re: [Ace] Opsdir last call review of draft-ietf-ace-oscore-profile-11

[Benjamin Kaduk]

Hi Linda,

On Sun, Jul 19, 2020 at 08:16:17PM -0700, Linda Dunbar via Datatracker wrote:
> Reviewer: Linda Dunbar
> Review result: Has Nits
> 
> I have reviewed this document as part of the Ops area directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the Ops area directors.
> Document editors and WG chairs should treat these comments just like any other
> last call comments.
> 
> This document describes how to set specific parameters in using  the
> Authentication and Authorization for Constrained Environments (ACE) framework
> [I-D.ietf-ace-oauth-authz]. The document is written clear, except some minor
> issues:
> 
>  Section 4.1.1 states that Nonce Parameter must be sent from the client to RS.
>  What would be the problem if the client doesn't include the "NONCE"?

There's a little more discussion of the N1 in the previous section, but in
essence, this nonce is required to protect the client against replayed
responses.  Since the token contents (including key derivation material)
would be unchanged across security contexts, the nonce is used to make each
one different; it has to be client-generated so that the client is sure
that this security context is "fresh" (vs. replayed).

> Page 12: It asks RFC editor to validate the numbers listed in Figure 7.  There
> is no explanation or comments for those values. It will be very difficult for
> RFC editor to validate. It seems to me there are 4 columns but  I can't
> understand the meaning of the values under 1st, 2nd, and 3rd columns.

I think this is just a note that the RFC Editor should make sure that
someone has checked the values (i.e., the authors).  The RFC Editor does
not need to be the one actually doing the checking.

Thanks for the review,

Ben

> it is kind of difficult to validate the correctness by just reading through 
> the
> document.  It would be better to have an implementation report of the proposed
> "Profile".
> 
> Best Regards,
>  Linda Dunbar
> 
> 
> 

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

Re: [Ace] Genart last call review of draft-ietf-ace-oscore-profile-11

[Benjamin Kaduk]

On Tue, Jul 21, 2020 at 03:56:07PM -0700, Elwyn Davies via Datatracker wrote:
> Reviewer: Elwyn Davies
> Review result: Almost Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-ace-oscore-profile-11
> Reviewer: Elwyn Davies
> Review Date: 2020-07-21
> IETF LC End Date: 2020-07-20
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:  Almost ready.  There is one minor issue that needs sorting out and a
> fair number of nits.  Overall I have to say that I found it difficult to keep
> clear in my mind what messages were fully encrypted and which ones were sent 
> en
> clair and which are in some intermediate class.  The authors might wish to go
> back over the document from the point of a naive reader to ensure that it is
> clear for implementers.
> 
> Major issues:
> None
> 
> Minor issues:
> s2, para 5:  Where does the 'input salt' come from?  The term is not used
> anywhere else in this document and  isn't defined or mentioned in either
> dreft-ace-oauth-authz or RFC 8613.

Hmm, it looks like this was introduced in the -09 as a result of one of my
review comments (as the formulation in the -08 implicitly had the name
"Master Salt" refer to both the string with and without N1+N2).  I think I
forgot enough of how this works that the authors will need to chime in with
an appropriate clarification of where the original ("input") salt comes
from.

Thanks for spotting that (as well as the other comments),

Ben

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

Re: [Ace] I-D Action: draft-ietf-ace-oscore-profile-14.txt

[Benjamin Kaduk]

Thanks, Francesca!

It looks like the CBOR label values have gotten out of sync between Table 1
and the prose.  (The IANA Considerations just refer to Table 1, so I think
that Section 3.2.1 is the only thing that needs to be kept in sync.)

-Ben

On Mon, Dec 14, 2020 at 09:58:21AM +, Francesca Palombini wrote:
> Hi all,
> 
> This update answers Marco's latest review (thanks Marco!), answering all 
> comments received as WGLC.
> 
> Thanks,
> Francesca
> 
> On 14/12/2020, 09:49, "Ace on behalf of internet-dra...@ietf.org" 
>  wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Authentication and Authorization for 
> Constrained Environments WG of the IETF.
> 
> Title   : OSCORE Profile of the Authentication and 
> Authorization for Constrained Environments Framework
> Authors : Francesca Palombini
>   Ludwig Seitz
>   Göran Selander
>   Martin Gunnarsson
>   Filename: draft-ietf-ace-oscore-profile-14.txt
>   Pages   : 33
>   Date: 2020-12-14
> 
> Abstract:
>This memo specifies a profile for the Authentication and
>Authorization for Constrained Environments (ACE) framework.  It
>utilizes Object Security for Constrained RESTful Environments
>(OSCORE) to provide communication security and proof-of-possession
>for a key owned by the client and bound to an OAuth 2.0 access token.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-14
> https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-14
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-14
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> ___
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
> 
> ___
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

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

[Ace] call for (ACE) co-chairing interest

[Benjamin Kaduk]

Hi all,

With Jim's passing we have a vacancy as ACE co-chair.  It is often the case
that a good WG chair candidate is already interested in the WG technologies
and thus participating in the WG (though someone who is very interested and
authoring many drafts in the WG may be too close to the work to be a good
chair).  Accordingly, I would ask and encourage anyone who thinks they might
be interested in co-chairing ACE, or co-chairing a different security-area
WG, to let me know, so I can take that under consideration as I decide who
to ask to take on the role.  No one can exactly replace Jim, so it will be
a different job for whoever takes it on, but it will be good to have some
help for Daniel!  Even if ACE is not a good fit for you, I do keep a list
of people who have expressed interest in WG chairing in general, to have in
mind as other openings arise.

Thank you,

Ben

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

Re: [Ace] Charter discussion

[Benjamin Kaduk]

Thanks for updating the draft charter at [1], Daniel!

I note that Michael raised the question of whether some other group might
also be interested in working on CMP-over-coap, so the IESG will be sure to
discuss that if CMP is still in the draft ACE charter when it goes to the
IESG for review.

-Ben

On Tue, Nov 17, 2020 at 06:16:48PM -0500, Daniel Migault wrote:
> Thank you all for the feed backs. For the purpose of driving the charter
> discussion at the IETf 109, I have added the comments into the proposed
> text [1].
> 
> My current understanding is that it seems beneficial to add CMPv2 over CoAP
> in the charter. I am happy to be contradicted.
> * I have not seen a clear cut to do one or the other.
> * EST and CMPv2 are two protocols that can be used for enrollment or cert
> management while addressing different cases / needs / situations -- maybe
> we can clarify that point. I can see leveraging the existing CMP
> infrastructure, but it seems that is not the only one.
> * I am not convinced that not having CMP over CoAP will not prevent its
> deployment and as such I prefer to have it standardized - this might be a
> personal thought.
> * Adding any piece of work require cycles, but it seems to me that CPM will
> not have a major impact on the WG progress. The work will probably include
> other WG such a LAMPS.
> 
> Yours,
> Daniel
> 
> [1]
> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing
> 
> On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault  wrote:
> 
> > Hi Goran,
> >
> > I added the text to the charter we will discuss later.
> >
> > Yours,
> > Daniel
> >
> > On Fri, Nov 13, 2020 at 10:26 AM Göran Selander <
> > goran.selan...@ericsson.com> wrote:
> >
> >> Hi Daniel,
> >>
> >>
> >>
> >> Here’s another input to the charter.
> >>
> >>
> >>
> >> The current group key management solutions addresses the problem of
> >> authorized access to group keys and public keys of group members.
> >>
> >>
> >>
> >> A related problem is authorized access of public keys of other devices
> >> not necessarily part of a security group, in the sense of sharing a
> >> symmetric key used to protect group messages.
> >>
> >>
> >>
> >> Authorized access to raw public keys serves an important function in
> >> constrained settings where public key certificates may not be feasible due
> >> to the incurred overhead, e.g. for when authenticating using EDHOC
> >> (draft-ietf-lake-edhoc).
> >>
> >> This functionality is thus a subset of what is already supported, but
> >> since the current solution is geared towards groups a different solution
> >> may be needed (although it is probably possible to reuse parts from the
> >> existing schemes for provisioning and requesting public keys).
> >>
> >>
> >>
> >> With this in mind, I propose the following change (highlighted in
> >> boldface below):
> >>
> >>
> >>
> >> OLD
> >>
> >> The Working Group is charged with maintenance of the framework and
> >> existing profiles thereof, and may undertake work to specify profiles of
> >> the framework for additional secure communications protocols (that are not
> >> necessarily limited to constrained endpoints, though the focus remains on
> >> deployment ecosystems with a substantial portion of constrained devices).
> >>
> >>
> >>
> >> NEW
> >>
> >> The Working Group is charged with maintenance of the framework and
> >> existing profiles thereof, and may undertake work to specify profiles of
> >> the framework for additional secure communications protocols *and **for
> >> additional **support services **providing* *authorized access to crypto* 
> >> *keys
> >> *(that are not necessarily limited to constrained endpoints, though the
> >> focus remains on deployment ecosystems with a substantial portion of
> >> constrained devices).
> >>
> >>
> >>
> >> Göran
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 2020-10-15, 19:50, "Ace"  wrote:
> >>
> >> Hi,
> >>
> >> I would like to start the charter discussion. Here is a draft of a
> >> proposed charter [1].
> >>
> >>
> >>
> >> It seems to be that additional discussion is needed with regard to the
> >> last paragraph related certificate management. In particular the discussion
> >> might revive a discussion that happened in 2017 [2] - when I was not
> >> co-chair of ACE -and considered other expired work such as [3]. Please make
> >> this discussion constructive on this thread.
> >>
> >>
> >>
> >> The fundamental question is whether we need certificate management at
> >> this stage. If the answer is yes, and we have multiple proposals, it would
> >> be good to clarify the position of the different proposals and evaluate
> >> whether a selection is needed or not before validating the charter.
> >>
> >>
> >>
> >> Please provide your inputs on the mailing list before October 30. Of
> >> course for minor edits, you may suggest them directly on the google doc.
> >>
> >>
> >>
> >> Yours,
> >>
> >> Daniel
> >>
> >>
> >>
> >> [1]
> >>