Re: [Ace] AD review of draft-ietf-ace-cmpv2-coap-transport-04
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
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
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
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
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
