Re: [Ace] call for adoption draft-selander-ace-coap-est-oscore

[Marco Tiloca]

Hi Daniel and all,

I support the adoption of this document and I am willing to review it as 
it progresses.


Best,
/Marco

On 2023-03-31 03:52, Daniel Migault wrote:

Hi,

Following the IETF116 meeting we are starting a 2 week adoption call 
for the following document. Please indicate whether you would like the 
document to be adopted or if you are against its adoption. The call 
ends April 15 2023.


https://datatracker.ietf.org/doc/draft-selander-ace-coap-est-oscore/ 



Yours,
Daniel
--
Daniel Migault
Ericsson

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


--
Marco Tiloca
Ph.D., Senior Researcher

Phone: +46 (0)70 60 46 501

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se



OpenPGP_0xEE2664B40E58DA43.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Last Call: (CoAP Transfer for the Certificate Management Protocol) to Proposed Standard

[The IESG]

The IESG has received a request from the Authentication and Authorization for
Constrained Environments WG (ace) to consider the following document: - 'CoAP
Transfer for the Certificate Management Protocol'
   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 2023-04-14. 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


   This document specifies the use of Constrained Application Protocol
   (CoAP) as a transfer mechanism for the Certificate Management
   Protocol (CMP).  CMP defines the interaction between various PKI
   entities for the purpose of certificate creation and management.
   CoAP is an HTTP-like client-server protocol used by various
   constrained devices in the IoT space.




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



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





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

Re: [Ace] WGLC draft-ietf-ace-revoked-token-notification-04.txt

[Daniel Migault]

Hi All,

Anyone volunteering to do shepherd write up would be highly appreciated.
Marco and others folks already provided all the necessary information, so
that could be done very easily.

Yours,
Daniel

On Sat, Mar 25, 2023 at 12:46 AM Rikard Höglund 
wrote:

> Hello.
>
> Please find my review of draft-ietf-ace-revoked-token-notification-04
> below.
>
> Best
> Rikard Höglund
>
>
> [Abstract]
>
> *"with the possible additional use of resource observation for the
> Constrained Application Protocol (CoAP)"
>
> Seems to me that CoAP is mentioned quite late here. Not only the
> observations, but the whole functionality of this draft is based on CoAP
> messages. Same comment is applicable to the introduction.
>
>
> [Section 1.1]
>
> *What is the difference between "TRL resource" and "TRL endpoint"? Earlier
> in the terminology it says that "endpoint" is used for denoting resources.
>
>
> *"A registered device acts as a caller of the TRL endpoint."
>
> Perhaps it can be rephrased or another word than "caller" used? I don't
> see caller used in RFC9200, RFC7252, or RFC6749. Practically the registered
> device will perform a request to the TRL endpoint right?
>
>
> [Section 2]
>
> *Regarding the following 3 sentences:
> "the registered device can send an Observation Request to the TRL resource"
> "the registered device can send a GET request to the TRL endpoint"
> "An administrator can access and subscribe to the TRL like"
>
> First "resource" is used, then "endpoint" is used, and in the last
> instance neither is used. Best to stick to one choice. This is a comment
> applicable to the document overall.
>
>
> *"provides the current updated list of revoked Access Tokens in the
> portion of the TRL pertaining to that device"
>
> Why not instead?
> "provides the current updated list of revoked Access Tokens from the TRL
> pertaining to that device"
> "Pertaining Access Token" was already defined in the terminology. I'm not
> sure also the concept of "portions" of the TRL are needed.
>
> The concept of "portion of the TRL" comes back multiple times in the
> document, but is it really needed?
>
>
> [Section 3]
>
> *Is it neccessary to have both parameters ENCODED_TOKEN and HASH_INPUT.
> Can't the value of HASH_INPUT be defined directly?
>
>
> [Section 4]
>
> *"The order of the token hashes in the CBOR array is irrelevant, and the
> CBOR array MUST be treated as a set in which the order of elements has no
> significant meaning."
>
> It seems this sentence is saying the same thing twice. This kind of
> construction occurs multiple times in the document.
>
>
> [Section 5]
>
> s/two types of query of the TRL/two types of queries of the TRL
>
>
> [Section 5.1.1]
>
> *"where "**" is the exponentiation operator"
>
> Any reason not to use the ^ notation instead?
>
>
> [Section 6]
>
> *"does not support the "Cursor" extension (if it supports diff queries at
> all)"
>
> Suggested rephrasing:
> "does not support the "Cursor" extension nor diff queries"
>
>
> [Section 7]
>
> *In this section I miss a mention of "trl_patch". Should it not be used
> here, as it is defined in CDDL in Figure 6 and described in Section 5.1?
> Alternatively remove the mention of "trl_patch", and just describe it as a
> CBOR array of token_hash values.
>
>
> *Section 5.1 says the following:
> "The series items in the update collection MUST be strictly ordered in a
> chronological fashion."
>
> Then in Section 7 it says:
> "Within 'diff_set_value', the CBOR arrays 'diff_entry' MUST be sorted to
> reflect the corresponding updates to the TRL in reverse chronological
> order."
>
> Why mandate to store in one order, and send in another?
>
>
> [Section 8.2.1]
>
> s/regardless whether/regardless of whether
>
>
> [Section 8.2.2]
>
> If the request does not include the 'cursor' query parameter, why does the
> AS still use it in the response? What if the requester doesn't support
> and/or doesn't want to use it at all? Cannot the decision to use the
> 'cursor' be an explicit indication by the requester, like having to include
> 'cursor' with value 0 in the request, or similar?
>
> The requester may know MAX_N and expect behaviour according to that. Even
> if it got MAX_DIFF_BATCH during the registration procedure, it may not
> understand that parameter if it doesn't support the 'cursor' extension.
>
>
> [Section 10.1]
>
> *"A response from the TRL endpoint indicating that t1 has expired."
>
> Could be good to clarify this sentence to say that this indication is
> about th1 having been removed from the TRL.
>
>
> *"If expunging or not accepting t2 yields the deletion of th2 as per the
> two conditions specified above"
>
> Suggested rephrasing:
> "If receiving t2 yields the deletion of th2 as per the two conditions
> specified above"
> It is the "receiving and seeing" that is criteria 1. "Expunging" or "not
> accepting" is not part of critera 1 or 2.
>
>
> *"iii) has the sequence number encoded in the 'cti' claim not greater than
> the highest sequence number 

[Ace] call for adoption draft-selander-ace-coap-est-oscore

[Daniel Migault]

Hi,

Following the IETF116 meeting we are starting a 2 week adoption call for
the following document. Please indicate whether you would like the document
to be adopted or if you are against its adoption. The call ends April 15
2023.

https://datatracker.ietf.org/doc/draft-selander-ace-coap-est-oscore/

Yours,
Daniel
-- 
Daniel Migault
Ericsson
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Daniel Migault]

Thanks!
Yours,
Daniel

From: Ace  On Behalf Of Mohit Sahni
Sent: March 30, 2023 2:22 PM
To: Paul Wouters 
Cc: Mohit Sahni ; ace@ietf.org; 
draft-ietf-ace-cmpv2-coap-transp...@ietf.org
Subject: Re: [Ace] AD review of draft-ietf-ace-cmpv2-coap-transport-07

Thanks Paul, I will upload a new version today.


On Wed, Mar 29, 2023 at 9:33 PM Paul Wouters 
mailto:40aiven...@dmarc.ietf.org>> 
wrote:



On Fri, Mar 10, 2023 at 4:12 AM Mohit Sahni 
mailto:msa...@paloaltonetworks.com>> wrote:

[ proposed changes / confirmations in the xml file ]

I have read the xml diff and I agree with all changes made.


Just noticed an incomplete response for this comment, responding again to it.

>The next bullet I just do not understand:
>
>In order to to reduce the risks imposed by DoS attacks, the
>implementations SHOULD optimally use the available datagram size
>i.e. avoid small datagrams containing partial CMP PKIMessage data.
>
>Please explain what is meant here and/or rephrase it.

The intent here is to instruct clients to send CMP messages in as few 
packets as possible. Fragmentation of CMP messages may cause the server to 
buffer packets which will consume resources on the server. With clients 
instructed to send CMP messages in as few packets as possible, servers can 
choose to ignore fragmented CMP messages to mitigate such DOS attacks.


So maybe:

Implementations SHOULD use the available datagram size and avoid small 
datagrams containing partial CMP PKIMessage data in order to reduce memory 
usage for packet buffering.

Please submit a new version to the datatracker with these changes, so we can 
start the IETF Last Call.

Paul
___
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] I-D Action: draft-ietf-ace-cmpv2-coap-transport-08.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Authentication and
Authorization for Constrained Environments (ACE) WG of the IETF.

   Title   : CoAP Transfer for the Certificate Management Protocol
   Authors : Mohit Sahni
 Saurabh Tripathi
   Filename: draft-ietf-ace-cmpv2-coap-transport-08.txt
   Pages   : 10
   Date: 2023-03-30

Abstract:
   This document specifies the use of Constrained Application Protocol
   (CoAP) as a transfer mechanism for the Certificate Management
   Protocol (CMP).  CMP defines the interaction between various PKI
   entities for the purpose of certificate creation and management.
   CoAP is an HTTP-like client-server protocol used by various
   constrained devices in the IoT space.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-cmpv2-coap-transport/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-ace-cmpv2-coap-transport-08

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-ace-cmpv2-coap-transport-08

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

[Mohit Sahni]

Thanks Paul, I will upload a new version today.


On Wed, Mar 29, 2023 at 9:33 PM Paul Wouters  wrote:

>
>
>
> On Fri, Mar 10, 2023 at 4:12 AM Mohit Sahni 
> wrote:
>
> [ proposed changes / confirmations in the xml file ]
>
> I have read the xml diff and I agree with all changes made.
>
>
>
>> Just noticed an incomplete response for this comment, responding again to
>> it.
>>
>> >The next bullet I just do not understand:
>> >
>> >In order to to reduce the risks imposed by DoS attacks, the
>> >implementations SHOULD optimally use the available datagram size
>> >i.e. avoid small datagrams containing partial CMP PKIMessage
>> data.
>> >
>> >Please explain what is meant here and/or rephrase it.
>>
>> The intent here is to instruct clients to send CMP messages in as
>> few packets as possible. Fragmentation of CMP messages may cause the server
>> to buffer packets which will consume resources on the server. With clients
>> instructed to send CMP messages in as few packets as possible, servers can
>> choose to ignore fragmented CMP messages to mitigate such DOS attacks.
>>
>>
> So maybe:
>
> Implementations SHOULD use the available datagram size and avoid small
> datagrams containing partial CMP PKIMessage data in order to reduce memory
> usage for packet buffering.
>
> Please submit a new version to the datatracker with these changes, so we
> can start the IETF Last Call.
>
> Paul
> ___
> 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