(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ace-oscore-profile-11. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are six actions which we must complete.

IANA understands that some of the actions requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document: draft-ietf-ace-oauth-authz-35.

Section 8.8 of that document creates a new registry with the following fields:

Name: The name of the profile, to be used as the value of the profile attribute.

Description: Text giving an overview of the profile and the context it is developed for.

CBOR Value: CBOR abbreviation for this profile name. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as Standards Action. Integer values from -65536 to -257 and from 256 to 65535 are designated as Specification Required. Integer values greater than 65535 are designated as "Expert Review". Integer values less than -65536 are marked as Private Use.

Reference: This contains a pointer to the public specification of the profile abbreviation if one exists.

First, in the new registry created by section 8.8 of draft-ietf-ace-oauth-authz-35 a single, new registration will be made as follows:

Name: coap_oscore
Description: Profile for using OSCORE to secure communication between constrained nodes using the Authentication and Authorization for Constrained Environments framework.
CBOR Value: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Second, in the OAuth Parameters Registry on the OAuth Parameters registry page located at:

https://www.iana.org/assignments/oauth-parameters/

two, new registrations are to be made as follows:

Name: nonce1
Parameter Usage Location: token request
Change Controller: IETF
Reference: [ RFC-to-be ]

Name: nonce2
Parameter Usage Location: token response
Change Controller: IETF
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated expert for the OAuth Parameters registry has asked that you send a review request to the mailing list oauth-ext-review@ietf.org. This review must be completed before the document's IANA state can be changed to "IANA OK."

Third, in the new registry created by section 8.10 of draft-ietf-ace-oauth-authz-35 two, new registrations will be made as follows:

Name: nonce1
CBOR Key: [ TBD-at-Registration ]
Value Type: bstr
Reference: [ RFC-to-be ]

Name: nonce2
CBOR Key: [ TBD-at-Registration ]
Value Type: IESG
Reference: [ RFC-to-be ]

Fourth, a new registry is to be created called the OSCORE Security Context Parameters registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The new registry will be managed as follows (see RFC 8126):

CBOR Label Registration
Value Policy
------------------+---------------------------------
less than -65536 Private Use
-65536 to -257 Specification required
-256 to 255 Standards track document required
256 to 65535 Specification required
greater than 65536 Expert review
String length = 1 Standards track document required
String length = 2 Specification required
String length > 2 Expert review

There are initial registrations in the new registry as follows (all of these initial registrations will have a reference of [ RFC-to-be ] and [RFC8613]:

Name: version
CBOR label: 0
CBOR type: int
Registry:
Description: OSCORE Version

Name: ms
CBOR label: 1
CBOR type: bstr
Registry:
Description: OSCORE Master Secret value

Name: clientId
CBOR label: 2
CBOR type: bstr
Registry:
Description: OSCORE Sender ID value of the client, OSCORE Recipient ID value of the server 

Name: serverId
CBOR label: 3
CBOR type: bstr
Registry:
Description: OSCORE Sender ID value of the server, OSCORE Recipient ID value of the client 

Name: hkdf
CBOR label: 4
CBOR type: tstr / int
Registry: COSE Algorithm Values (HMAC-based)
Description: OSCORE HKDF value

Name: alg
CBOR label: 5
CBOR type: tstr / int
Registry: COSE Algorithm Values (AEAD)
Description: OSCORE AEAD Algorithm value

Name: salt
CBOR label: 6
CBOR type: bstr
Registry:
Description: OSCORE Master Salt value

Name: contextId
CBOR label: 7
CBOR type: bstr
Registry:
Description: OSCORE ID Context value

Fifth, in the CWT Confirmation Methods registry on the CBOR Web Token (CWT) Claims registry page located at:

https://www.iana.org/assignments/cwt/

a single registration will be made as follows:

Confirmation Method Name: "osc"
Confirmation Method Description: OSCORE_Security_Context carrying the parameters for using OSCORE per-message security with implicit key confirmation
Confirmation Key: [ TBD-at-Registration ] (value between 4 and 255)
Confirmation Value Type(s): map
Change Controller: IESG
Reference: [ RFC-to-be; Section 3.2.1 ]

As this also requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the CWT Confirmation Methods registry have also asked that you send a review request to the mailing list cwt-reg-review@ietf.org. This review must be completed before the document's IANA state can be changed to "IANA OK."

Sixth, in the JWT Confirmation Methods registry on the JSON Web Token (JWT) registry page located at:

https://www.iana.org/assignments/jwt/

a single, new registration will be made as follows:

Confirmation Method Value: "osc"
Confirmation Method Description: OSCORE_Security_Context carrying the parameters for using OSCORE per-message security with implicit key confirmation
Change Controller: IESG
Reference: [ RFC-to-be; Section 3.2.1 ]

As this also requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the JWT Confirmation Methods registry have also asked that you send a review request to the mailing list jwt-reg-review@ietf.org. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-07-20):

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: ietf@augustcellars.com, draft-ietf-ace-oscore-profile@ietf.org, ace@ietf.org, Jim Schaad <ietf@augustcellars.com>, kaduk@mit.edu, ace-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-ace-oscore-profile-11.txt> (OSCORE profile of the Authentication and Authorization for Constrained Environments Framework) to Proposed Standard


The IESG has received a request from the Authentication and Authorization for
Constrained Environments WG (ace) to consider the following document: -
'OSCORE profile of the Authentication and Authorization for Constrained
  Environments Framework'
  <draft-ietf-ace-oscore-profile-11.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-07-20. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) This is requested to be a Proposed Standard.  The header of the
document correctly reflects this.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The OAuth authentication and Authorization for Constrained Devices
  provides a message format and framework for moving keys and tokens
  between authority servers, clients, and resource servers.
  This document provides a set of security services so that the
  communication and authorizations can be performed.

Working Group Summary

  Once the CoRE document dealing with OSCORE there was
  only one issue of significance.  That issue was how to deal
  with re-use of tokens in order to make sure that the same
  transport key was not going to be regenerated.  This has
  been addressed.

Document Quality

  The document has been fairly extensively vetted.  There are
  at least two implementations of a version of the document
  prior to the WGLC being done.

Personnel

  Jim Schaad is acting as the Document Shepherd.  Benjamin Kaduk
  is the Responsible Area Director.

(3) I have read and implemented the protocol in the document.  I have done a full
read through the document prior to releasing it as well as double checking
my implementation against the current document.

(4) I have no concerns with the review of this document.  It is expected
that an updated interop test will be run at the Prague Hackathon.

(5) There are no portions of this document that need extra review.

(6) Given the current state of the OSCORE document, some attention may need
to be focused on the method used to add randomness to the key derivation process.
I believe that what is done is sufficient, but others may want to look at it.

(7)  All authors have confirmed that all IPR disclosures have been made.
Ludwig 2/25/19
Francesca 1/31/19
Goeran 2/25/19
Martin 2/16/19

(8) No IPR disclosures have been filed on this document.

(9) This document represents a strong consensus of a small group of people.
Most of the reviews came from me and the authors.

(10) There are not any indications of appeals or extreme discontent.

(11) No ID nits were found in the document.

(12) There is no formal review required.

(13) All references are appropriately normative or informative.

(14) All normative references are either complete or soon to advance
to the IESG

(15) There are no downward normative references.

(16) This document contains all new material and does not modify any
existing RFCs.

(17) I checked that all items that were setup as being defined in the text
also occurred in the registration sections.  Went through and verified that
the template for registering new OSCORE Security Context Parameters made sense.

(18) This document creates one new registry:

OSCORE Security Context Parameters Registry - This registry is setup to
require expert review.  This registry is similar but not identical in usage
to the currently existing COSE_Key registry.  As such a combination of
current DEs for that registry and authors for the OSCORE document
(draft-ietf-core-object-security) would be recommended to act as the DEs
for ths registry.

(19) There are no external reviews or automated checks needed.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) This is requested to be a Proposed Standard.  The header of the
document correctly reflects this.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The OAuth authentication and Authorization for Constrained Devices
  provides a message format and framework for moving keys and tokens
  between authority servers, clients, and resource servers.
  This document provides a set of security services so that the
  communication and autthorizations can be performed.

Working Group Summary

   
  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Document Quality

  The document has been fairly extensively vetted.  There are
  at least two implementations of a version of the document
  prior to the WGLC being done.

Personnel

  Jim Schaad is acting as the Document Shepherd.  Benjamin Kaduk
  is the Responsible Area Director.

(3) I have read and implemented the protocol in the document.  I have done a full
read through the document prior to releasing it as well as double checking
my implementation againist the current document.

(4) I have no concerns with the review of this document.  It is expected
that an updated interop test will be run at the Prague Hackathon.

(5) There are no portions of this document that need extra review.

(6) Given the current state of the OSCORE document, some attention may need
to be focused on the method used to add randomness to the key derivation process.
I believe that what is done is sufficent, but others may want to look at it.

(7)  All authors have confirmed that all IPR disclosures have been made.
Ludwig 2/25/19
Francesca 1/31/19
Goeran 2/25/19
Martin 2/16/19

(8) No IPR disclosures have been filed on this document.

(9) This document represents a strong consensus of a small group of people.
Most of the reviews came from me and the authors.

(10) There are not any indications of appeals or extreme discontent.

(11) No ID nits were found in the document.

(12) There is no formal review required.

(13) All references are appropriately normative or informative.

(14) All normative references are either complete or soon to advance
to the IESG

(15) There are no downward normative references.

(16) This document contains all new material and does not modify any
existing RFCs.

(17) I checked that all items that were setup as being defined in the text
also occured in the registration sections.  Went through and verified that
the template for registering new OSCORE Security Context Parameters made sense.

(18) This document creates one new registry:

OSCORE Security Context Parameters Registry - This registry is setup to
require expert review.  This registry is similar but not identical in usage
to the currently existing COSE_Key registry.  As such a combination of
current DEs for that registry and authors for the OSCORE document
(draft-ietf-core-object-security) would be recommended to act as the DEs
for ths registry.

(19) There are no external reviews or automated checks needed.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) This is requested to be a Proposed Standard.  The header of the
document correctly reflects this.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The OAuth authentication and Authorization for Constrained Devices
  provides a message format and framework for moving keys and tokens
  between authority servers, clients, and resource servers.
  This document provides a set of security services so that the
  communication and autthorizations can be performed.

Working Group Summary

   
  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Document Quality

  The document has been fairly extensively vetted.  There are
  at least two implementations of a version of the document
  prior to the WGLC being done.

Personnel

  Jim Schaad is acting as the Document Shepherd.  Benjamin Kaduk
  is the Responsible Area Director.

(3) I have read and implemented the protocol in the document.  I have done a full
read through the document prior to releasing it as well as double checking
my implementation againist the current document.

(4) I have no concerns with the review of this document.  It is expected
that an updated interop test will be run at the Prague Hackathon.

(5) There are no portions of this document that need extra review.

(6) Given the current state of the OSCORE document, some attention may need
to be focused on the method used to add randomness to the key derivation process.
I believe that what is done is sufficent, but others may want to look at it.

(7)  All authors have confirmed that all IPR disclosures have been made.
Ludwig 2/25/19
Francesca 1/31/19
Goeran 2/25/19
Martin 2/16/19

(8) No IPR disclosures have been filed on this document.

(9) This document represents a strong consensus of a small group of people.
Most of the reviews came from me and the authors.

(10) There are not any indications of appeals or extreme discontent.

(11) No ID nits were found in the document.

(12) There is no formal review required.

(13) All references are appropriately normative or informative.

(14) All normative references are either complete or soon to advance
to the IESG

(15) There are no downward normative references.

(16) This document contains all new material and does not modify any
existing RFCs.

(17) I checked that all items that were setup as being defined in the text
also occured in the registration sections.  Went through and verified that
the template for registering new OSCORE Security Context Parameters made sense.

(18) This document creates one new registry:

OSCORE Security Context Parameters Registry - This registry is setup to
require expert review.  This registry is similar but not identical in usage
to the currently existing COSE_Key registry.  As such a combination of
current DEs for that registry and authors for the OSCORE document
(draft-ietf-core-object-security) would be recommended to act as the DEs
for ths registry.

(19) There are no external reviews or automated checks needed.