Re: [Ace] AD review of draft-ietf-ace-cmpv2-coap-transport-04

2022-02-14 Thread Brockhaus, Hendrik
Ben

Thank you for your review and your comment on CMP Updates.
I will just comment on the usage of "cmp" well-known URI and leave the other 
comments to the authors of draft-ietf-ace-cmpv2-coap-transport-04.

> Von: Ace  Im Auftrag von Benjamin Kaduk
> Gesendet: Montag, 14. Februar 2022 20:22
> 
> Hi all,
> 
> Jumping right in...
> 
> 
> I guess this is probably more of a comment on draft-ietf-lamps-cmp-updates,
> but since we are duplicating some of its content I will still call it out as 
> a as a
> serious concern.  My concern relates to the usage of the "cmp"
> well-known URI -- we hvae some text in §2.1 that effectively says that a local
> site can just put more path segments under that path at its own discretion,
> and there's not even any restrictions made on the structucture of the
> additional path segments -- the next segment could be an operational label
> or a profile label, in the examples given.  This seems entirely at odds with
> the purpose of well-known URIs as per RFC 8615 -- they are to be URIs whose
> semantics are entirely specified by a protocol specification and are *not*
> subject to local operator control.  While it is possible for a specification 
> to
> introduce additional structure under its registered well-known path, it's
> expected that the semantics of those subtrees are still specified by the
> protocol, and any extensions are to be managed by a (sub-)registry.  See, for
> example, §8.3.2 of RFC 8995, that establishes a sub-registry for the path
> components under /.well-known/brski .
> 
> Any changes here will of course need to be synchronized with draft-ietf-
> lamps-cmp-updates, but I don't think this draft can go forward in its current
> form.
> 
When writing the sections on http and coap transfer in Lightweight CMP Profile 
and CMP Updates I took RFC 7030 as example.
RFC 7030 §3.2.2 states
   An EST server MAY provide service for multiple CAs as indicated by an
   OPTIONAL additional path segment between the registered application
   name and the operation path.  To avoid conflict, the CA label MUST
   NOT be the same as any defined operation path segment.  The EST
   server MUST provide services regardless of whether the additional
   path segment is present.  The following are three example valid URIs:

   1.  https://www.example.com/.well-known/est/cacerts

   2.  https://www.example.com/.well-known/est/arbitraryLabel1/cacerts

   3.  https://www.example.com/.well-known/est/arbitraryLabel2/cacerts

Also draft-ietf-ace-coap-est §5.1 makes use of arbitraryLables
   For both types of installations, saving header space is important and
   short EST-coaps URIs are specified in this document.  These URIs are
   shorter than the ones in [RFC7030].  Two example EST-coaps resource
   path names are:

   coaps://example.com:/.well-known/est/
   coaps://example.com:/.well-known/est/ArbitraryLabel/

CMP Updates §3.3 makes use of these examples and adapts them to CMP needs 
renaming arbitraryLable to profileLable. The operationLable is specified in 
Lightweight CMP Profile.
   The CMP client needs to be configured with sufficient information to
   form the CMP server URI.  This is at least the authority portion of
   the URI, e.g., 'www.example.com:80', or the full operation path
   segment of the PKI management entity.  Additionally, OPTIONAL path
   segments MAY be added after the registered application name as part
   of the full operation path to provide further distinction.  A path
   segment could for example support the differentiation of specific
   CAs, certificate profiles, or PKI management operations.  A valid
   full CMP path can look like this:

  http://www.example.com/.well-known/cmp
  http://www.example.com/.well-known/cmp/operationLabel
  http://www.example.com/.well-known/cmp/profileLabel
  http://www.example.com/.well-known/cmp/profileLabel/operationLabel

The operational labels for usage with http are further specified in Lightweight 
CMP Profile §6.1 (and for coap see §6.2).
   PKI management operations SHOULD use URI paths consisting of '/.well-
   known/cmp/' followed by an operation label depending on the type of
   PKI management operation.

   ++=+=+
   | PKI management operation   |   operation label   | Details |
   ++=+=+
   | Enroll client to new PKI   |   /initialization   | Section |
   || | 4.1.1   |
   ++-+-+
   | Enroll client to existing  |/certification   | Section |
   | PKI| | 4.1.2   |
   ++-+-+
   | Update client certificate  |  /keyupdate | Section |
   || | 4.1.3   |
   ++-+-+
   | Enroll clien

[Ace] Last Call: (An Authorization Information Format (AIF) for ACE) to Proposed Standard

2022-02-14 Thread The IESG


The IESG has received a request from the Authentication and Authorization for
Constrained Environments WG (ace) to consider the following document: - 'An
Authorization Information Format (AIF) for ACE'
   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-c...@ietf.org mailing lists by 2022-02-28. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   Information about which entities are authorized to perform what
   operations on which constituents of other entities is a crucial
   component of producing an overall system that is secure.  Conveying
   precise authorization information is especially critical in highly
   automated systems with large numbers of entities, such as the
   "Internet of Things".

   This specification provides a generic information model and format
   for representing such authorization information, as well as two
   variants of a specific instantiation of that format for use with REST
   resources identified by URI path.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ace-aif/



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





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


[Ace] I-D Action: draft-ietf-ace-aif-05.txt

2022-02-14 Thread internet-drafts


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   : An Authorization Information Format (AIF) for ACE
Author  : Carsten Bormann
Filename: draft-ietf-ace-aif-05.txt
Pages   : 15
Date: 2022-02-14

Abstract:
   Information about which entities are authorized to perform what
   operations on which constituents of other entities is a crucial
   component of producing an overall system that is secure.  Conveying
   precise authorization information is especially critical in highly
   automated systems with large numbers of entities, such as the
   "Internet of Things".

   This specification provides a generic information model and format
   for representing such authorization information, as well as two
   variants of a specific instantiation of that format for use with REST
   resources identified by URI path.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-aif/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-ace-aif-05.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-aif-05


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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


Re: [Ace] AD review of draft-ietf-ace-cmpv2-coap-transport-04

2022-02-14 Thread Mohit Sahni
Hi Ben,
Many thanks for your comments. I will review them and make the changes
accordingly.

Regards,
Mohit

On Mon, Feb 14, 2022 at 11:24 AM Benjamin Kaduk  wrote:

> Hi all,
>
> Jumping right in...
>
>
> I guess this is probably more of a comment on draft-ietf-lamps-cmp-updates,
> but since we are duplicating some of its content I will still call it out
> as
> a as a serious concern.  My concern relates to the usage of the "cmp"
> well-known URI -- we hvae some text in §2.1 that effectively says that a
> local site can just put more path segments under that path at its own
> discretion, and there's not even any restrictions made on the structucture
> of the additional path segments -- the next segment could be an operational
> label or a profile label, in the examples given.  This seems entirely at
> odds with the purpose of well-known URIs as per RFC 8615 -- they are to be
> URIs whose semantics are entirely specified by a protocol specification and
> are *not* subject to local operator control.  While it is possible for a
> specification to introduce additional structure under its registered
> well-known path, it's expected that the semantics of those subtrees are
> still specified by the protocol, and any extensions are to be managed by a
> (sub-)registry.  See, for example, §8.3.2 of RFC 8995, that establishes a
> sub-registry for the path components under /.well-known/brski .
>
> Any changes here will of course need to be synchronized with
> draft-ietf-lamps-cmp-updates, but I don't think this draft can go forward
> in
> its current form.
>
> Abstract
>
>This document specifies the use of Constrained Application Protocol
>(CoAP) as a transfer mechanism for the Certificate Management
>Protocol (CMP).  purpose of certificate creation and management.
>
> Is the last quoted sentence (fragment) an editing artifact or is there
> supposed to be more content there?
>
>CoAP is an HTTP like client-server protocol used by various
>constrained devices in the IoT space.
>
> nit: hyphenate "HTTP-like"
>
> Section 1
>
>messages.  The Constrained Application Protocol (CoAP) defined in
>[RFC7252], [RFC7959] and [RFC8323] is a client-server protocol like
>HTTP.  It is designed to be used by constrained devices over
>
> (editorial) I would suggest putting a paragraph break before talking about
> CoAP.
>
> Section 2.2
>
>   If the port number is not specified in
>the authority, then port 5683 MUST be assumed for the "coap://"
>scheme and port 5684 MUST be assumed for the "coaps://" scheme.
>
> If I'm not mistaken, these ports 5683/5684 are the normal default ports for
> coap/coaps, as mandated by RFC 7252.  We don't need to restate that
> requirement using normative keywords, as the normative requirement is made
> in RFC 7252.  Instead (if anything), we should just provide a statement of
> fact, e.g., "the default port for coap: scheme URIs is 5683 and the default
> port for coaps: scheme URIs is 5684 [RFC7252]".  But really, we should be
> able to expect people to know to find the deafult port for a given URI
> scheme.
>
> Section 2.3
>
>CoAP POST request.  A CMP client SHOULD send CoAP requests marked as
>Confirmable message ([RFC7252] section 2.1).  If the CoAP request is
>
> nit: singular/plural mismatch "message"/"requests".  Since we use the
> singular in the next sentence, going to singular here is probably best,
> e.g., "SHOULD send each CoAP request marked as a Confirmable message".
>
>successful then the server MUST return a "2.05 Content" response
>code.  [...]
>
> Perhaps I am reading too much into the analogy between HTTP and CoAP and
> thus to the applicability of draft-ietf-httpbis-bcp56bis (currently with
> the
> RFC Editor), but it doesn't seem terribly useful to name a specific
> response
> code here.  The standard CoAP semantics apply, and we could probably just
> say that "the paylaod of a successful response contains the DER-encoded
> ...".
>
>When transferring CMP PKIMesssage over CoAP the media type
>"application/pkixcmp" MUST be used.
>
> Do we want to say media type or content-format here?
>
> Section 2.4
>
>These structures may contain many optional
>and potentially large fields, a CMP message can be much larger than
>the Maximum Transmission Unit (MTU) of the outgoing interface of the
>device.  [...]
>
> nit: comma splice
>
>MUST be used for the CMP Transactions over CoAP.  If a CoAP-to-HTTP
>proxy is in the path between EEs and CA or EEs and RA then it MUST
>receive the entire body from the client before sending the HTTP
>request to the server.  [...]
>
> It will be interesting to see what the ART and transport reviewers think of
> this guidance.  It seems like it is technically possible for the proxy to
> use a chunked encoding and stream the message without buffering, and it's
> not immediately clear to me that the cost of having to buffer 

[Ace] AD review of draft-ietf-ace-cmpv2-coap-transport-04

2022-02-14 Thread Benjamin Kaduk
Hi all,

Jumping right in...


I guess this is probably more of a comment on draft-ietf-lamps-cmp-updates,
but since we are duplicating some of its content I will still call it out as
a as a serious concern.  My concern relates to the usage of the "cmp"
well-known URI -- we hvae some text in §2.1 that effectively says that a
local site can just put more path segments under that path at its own
discretion, and there's not even any restrictions made on the structucture
of the additional path segments -- the next segment could be an operational
label or a profile label, in the examples given.  This seems entirely at
odds with the purpose of well-known URIs as per RFC 8615 -- they are to be
URIs whose semantics are entirely specified by a protocol specification and
are *not* subject to local operator control.  While it is possible for a
specification to introduce additional structure under its registered
well-known path, it's expected that the semantics of those subtrees are
still specified by the protocol, and any extensions are to be managed by a
(sub-)registry.  See, for example, §8.3.2 of RFC 8995, that establishes a
sub-registry for the path components under /.well-known/brski .

Any changes here will of course need to be synchronized with
draft-ietf-lamps-cmp-updates, but I don't think this draft can go forward in
its current form.

Abstract

   This document specifies the use of Constrained Application Protocol
   (CoAP) as a transfer mechanism for the Certificate Management
   Protocol (CMP).  purpose of certificate creation and management.

Is the last quoted sentence (fragment) an editing artifact or is there
supposed to be more content there?

   CoAP is an HTTP like client-server protocol used by various
   constrained devices in the IoT space.

nit: hyphenate "HTTP-like"

Section 1

   messages.  The Constrained Application Protocol (CoAP) defined in
   [RFC7252], [RFC7959] and [RFC8323] is a client-server protocol like
   HTTP.  It is designed to be used by constrained devices over

(editorial) I would suggest putting a paragraph break before talking about
CoAP.

Section 2.2

  If the port number is not specified in
   the authority, then port 5683 MUST be assumed for the "coap://"
   scheme and port 5684 MUST be assumed for the "coaps://" scheme.

If I'm not mistaken, these ports 5683/5684 are the normal default ports for
coap/coaps, as mandated by RFC 7252.  We don't need to restate that
requirement using normative keywords, as the normative requirement is made
in RFC 7252.  Instead (if anything), we should just provide a statement of
fact, e.g., "the default port for coap: scheme URIs is 5683 and the default
port for coaps: scheme URIs is 5684 [RFC7252]".  But really, we should be
able to expect people to know to find the deafult port for a given URI
scheme.

Section 2.3

   CoAP POST request.  A CMP client SHOULD send CoAP requests marked as
   Confirmable message ([RFC7252] section 2.1).  If the CoAP request is

nit: singular/plural mismatch "message"/"requests".  Since we use the
singular in the next sentence, going to singular here is probably best,
e.g., "SHOULD send each CoAP request marked as a Confirmable message".

   successful then the server MUST return a "2.05 Content" response
   code.  [...]

Perhaps I am reading too much into the analogy between HTTP and CoAP and
thus to the applicability of draft-ietf-httpbis-bcp56bis (currently with the
RFC Editor), but it doesn't seem terribly useful to name a specific response
code here.  The standard CoAP semantics apply, and we could probably just
say that "the paylaod of a successful response contains the DER-encoded
...".

   When transferring CMP PKIMesssage over CoAP the media type
   "application/pkixcmp" MUST be used.

Do we want to say media type or content-format here?

Section 2.4

   These structures may contain many optional
   and potentially large fields, a CMP message can be much larger than
   the Maximum Transmission Unit (MTU) of the outgoing interface of the
   device.  [...]

nit: comma splice

   MUST be used for the CMP Transactions over CoAP.  If a CoAP-to-HTTP
   proxy is in the path between EEs and CA or EEs and RA then it MUST
   receive the entire body from the client before sending the HTTP
   request to the server.  [...]

It will be interesting to see what the ART and transport reviewers think of
this guidance.  It seems like it is technically possible for the proxy to
use a chunked encoding and stream the message without buffering, and it's
not immediately clear to me that the cost of having to buffer chunks for
reassembly outweights the cost of maintaining an HTTP connection in the
current threat model.

Also, nit: I would suggest using "EE" singular in both instances.

   This will avoid unnecessary errors in case
   the entire content of the PKIMesssage is not received and the proxy
   opens a connection with the server.

I'm n