Re: [secdir] Secdir last call review of draft-ietf-core-object-security-14

[Göran Selander <goran.selander@xxxxxxxxxxxx>]

Hi Daniel,

Thanks for your responses. Detailed comments inline.

With that I believe all outstanding comments are resolved in version -15. Let us know if there are any further comments.

Best regards

Göran

From: Daniel Migault <daniel.migault@xxxxxxxxxxxx>
Date: Friday, 31 August 2018 at 20:24
To: "secdir@xxxxxxxx" <secdir@xxxxxxxx>, Göran Selander <goran.selander@xxxxxxxxxxxx>
Cc: "draft-ietf-core-object-security.all@xxxxxxxx" <draft-ietf-core-object-security.all@xxxxxxxx>, "ietf@xxxxxxxx" <ietf@xxxxxxxx>, "core@xxxxxxxx" <core@xxxxxxxx>
Subject: Re: [secdir] Secdir last call review of draft-ietf-core-object-security-14

Hi Goran,

 

Thank you for your feed backs. I believe all my concerns have been addressed. You can see inline the specific response. <mglt2></mglt2>

 

- - -

>> 

>>   This document defines the Object Security for Constrained RESTful

>>   Environments (OSCORE) security protocol, protecting CoAP and CoAP-

>>   mappable HTTP requests and responses end-to-end across intermediary

>>   nodes such as CoAP forward proxies and cross-protocol translators

>>   incuding HTTP-to-CoAP proxies [RFC8075].  In addition to the core

>>   CoAP features defined in [RFC7252], OSCORE supports Observe

>>   [RFC7641], Block-wise [RFC7959], No-Response [RFC7967], and PATCH and

>>   FETCH [RFC8132].

>><mglt>

>>Maybe too many "and".

>></mglt>

> 

>[GS:] I see what you mean. The title of RFC 8132 is "PATCH and FETCH

>methods for CoAP”. Perhaps we just change the order of the examples in the

>last sentence:

 NEW

>"In addition to the core CoAP features defined in

>[RFC7252], OSCORE supports Observe [RFC7641], Block-wise [RFC7959], PATCH

>and FETCH [RFC8132], and No-Response [RFC7967].”?

> 

> 

<mglt2>

I am fine either ways. I think the problem is that we a have a list of different nature, unless we are considering the documents themselves. I would propose:

OSCORE supports the BlockWise Transfert Signaling  Option [RFC7959], the Observed [RFC7641] and No-Response Option, [RFC7967], as well as the PATCH and FETCH Methods [RFC8132].

</mglt2>

GS: Rephrased in –15.

- - -

 

>> 

>>I believe that Sender Sequence Number also needs to be present in the

>>Recipient

>>Context in order to implement anti replay mechanism.

> 

>[GS:] The replay window is already part of the Recipient Context. Perhaps

>a reference to Section 7.4 would be sufficient to make the connection

>between replay window and sequence number?

> 

<mglt2>

Good, then yes a reference would be usefull

</mglt2>

GS: Included in –15.

- - -

>> 

>>Sequence Number May be interpreted differently. I believe that

>>interpretation

>>should also be part of the Common Security Context.

> 

>[GS:] I didn’t understand this comment.

 

<mglt2>

Sequence Number are not always incremented. This interpretation may impact the session, so that may need to be specify in the future when considering other interpretation of the SSN.

</mglt2>

GS: This specification assumes that SSN is incremented as should be clear from the processing (section 8). In –15 we added a reference to I-D.mcgrew-iv-gen.

- - -

>> 

>>   The following input parameters MAY be pre-established.  In case any

>>   of these parameters is not pre-established, the default value

>>   indicated below is used:

>> 

>>   o  AEAD Algorithm

>> 

>>      *  Default is AES-CCM-16-64-128 (COSE algorithm encoding: 10)

>> 

>>   o  Master Salt

>> 

>>      *  Default is the empty byte string

>><mglt>

>>I believe explicitly providing the string could help. There is always the

>>confusion with "\0" versus "". </mglt>

> 

>[GS:] Note that the Master Salt is never sent and only used as salt in

>HKDF (section 2.2 of RFC 5869). Section 3.2.1 describes how the empty

>string should be interpreted:

>"Note that [RFC5869] specifies that if the salt is not provided, it is set

>to a string of

>zeros. For implementation purposes, not providing the salt is the same

>as setting the salt to the empty byte string. OSCORE sets the salt

>default value to empty byte string, which in [RFC5869] is converted to a

>string of zeroes (see Section 2.2 of [RFC5869])."

>Is that sufficiently clear?

> 

> 

<mglt2>

This is fine. It seems to me that empty string is “” here. I usually like to cite explicitly the string to avoid confusion between “” or “\0”. I agree that saying zero length does not help much

The latest sentence has two reference to RFC5869, maybe one would be sufficient. If possible, it might be better to specify the length of the strings of zeros (HashLen in our case)

</mglt2>

GS: One of the references to RFC5869 removed in –15. The procedure for handling the case of no salt provided is clearly specified in section 2.2 of RFC5869, which we reference. I would rather not include the details in this specification.

- - -

> 

> 

> which defines how to

> 

>> 

>>   o  Key Derivation Function (KDF)

>> 

>>      *  Default is HKDF SHA-256

>> 

>>   o  Replay Window Type and Size

>> 

>>      *  Default is DTLS-type replay protection with a window size of 32

>>         [RFC6347]

>><mglt>

>>This section specifies Type and windows for the anti replay mechanism.

>>This was

>>described as Replay Windows in the context description. </mglt>

> 

>[GS:] I didn’t understand this comment. Do you mean:

>OLD

>Replay Window Type and Size

>NEW

>Replay Window

> 

> 

<mglt2>

If different mechanism could be used, I meant:

* Replay Window Type : default to DTLS 1.2

* Replay Window Size (Parameters):

</mglt>

GS: The default values listed in section 3.2 were intended to repeat the parameters listed in section 3.1. I realised from your comment that  that "Replay Window" deviated from this convention. We resolved that in –15 by changing the term in section 3.2. Your proposal would also require a change to section 3.1. Note that we do not restrict to DTLS type replay protection, so we would rather not itemise the sub-parameters of the replay protection mechanism.

- - -

> 

>[GS:] No, the restriction comes from the nonce construction, I will add a

>reference to Section 5.2.

<mglt2>

Thanks, I believe that would be useful.

</mglt2>

GS: Done in -15

- - -

> 

>>4.1.3.5.2.  Notifications

>> 

>>   If the server accepts an Observe registration, a Partial IV MUST be

>>   included in all notifications (both successful and error), except for

>>   the first one where Partial IV MAY be omitted.  To protect against

>>   replay, the client SHALL maintain a Notification Number for each

>>   Observation it registers.  The Notification Number is a non-negative

>>   integer containing the largest Partial IV of the received

>>   notifications for the associated Observe registration.  Further

>>   details of replay protection of notifications are specified in

>>   Section 7.4.1.

>> 

>>   For notifications, the Inner Observe value MUST be empty (see

>>   Section 3.2 of [RFC7252]).  The Outer Observe in a notification is

>> 

>>Selander, et al.        Expires January 27, 2019               [Page 20]

>> 

>>Internet-Draft                   OSCORE                        July 2018

>> 

>>   needed for intermediary nodes to allow multiple responses to one

>>   request, and may be set to the value of Observe in the original CoAP

>>   message.  The client performs ordering of notifications and replay

>>   protection by comparing their Partial IVs and SHALL ignore the outer

>>   Observe value.

>> 

>>   If the client receives a response to an Observe request without an

>>   Inner Observe option, then it verifies the response as a non-Observe

>>   response, as specified in Section 8.4.  If the client receives a

>>   response to a non-Observe request with an Inner Observe option, then

>>   it stops processing the message, as specified in Section 8.4.

>> 

>>   A client MUST consider the notification with the highest Partial IV

>>   as the freshest, regardless of the order of arrival.  In order to

>>   support existing Observe implementations the OSCORE client

>>   implementation MAY set the Observe value to the three least

>>   significant bytes of the Partial IV; such an implementation needs to

>>   make sure that the Observe value for an observe notification without

>>   Partial IV is smaller than a notification with Partial IV.

>> 

>><mglt>

>>This section discuss the behavior regarding the sequence number. While

>>the

>>sequence number and the partial IV have the same value, I am wondering

>>if

>>it

>>would not be more appropriated to mention the sequence number value is

>>provided

>>by the partial IV, and then use the sequence number variable to describe

>>anti

>>replay. </mglt>

> 

> 

>[GS:] We intended to use the term “partial IV” when referring to the

>number being transported and “SSN" when referring to the number stored in

>the endpoint. I will go through the document and see that this convention

>is kept.

>> 

<mglt2>

Maybe that would be useful to mention this convention

</mglt2>

 

GS: I’m not sure going into this distinction is necessary. We already describe the relationship in several places:

Section 3.1:

"Sender Sequence Number.  Non-negative integer used by the sender
      to enumerate requests and certain responses, e.g.  Observe
      notifications.  Used as 'Partial IV' [RFC8152] to generate unique
      AEAD nonces."

Section 5:

" The 'Partial IV' parameter.  The value is set to the Sender Sequence Number."

Section 7.2:

"Partial IVs (which encode the Sender Sequence Numbers, see Section 5)"

Section 7.4 (addressing another comment of yours):

"Partial IV = Sender Sequence Number"

and also several times in the processing, Section 8.

- - -

>D.4.1.  CoAP Header Fields

> 

>   o  Version.  The CoAP version [RFC7252] is not expected to be

>      sensitive to disclose.  Currently there is only one CoAP version

>      defined.  A change of this parameter is potentially a denial-of-

>      service attack.  Future versions of CoAP need to analyze attacks

>      to OSCORE protected messages due to an adversary changing the CoAP

>      version.

> 

>   o  Token/Token Length.  The Token field is a client-local identifier

>      for differentiating between concurrent requests [RFC7252].  An

>      eavesdropper reading the token can match requests to responses

>      which can be used in traffic analysis.  In particular this is true

>      for notifications, where multiple responses are matched with one

>      request.  CoAP proxies are allowed to change Token and Token

>      Length between UDP hops.  However, modifications of Token and

>      Token Length during a UDP hop may become a denial-of-service

> 

>Selander, et al.        Expires January 27, 2019               [Page 76]

> 

>Internet-Draft                   OSCORE                        July 2018

> 

>      attack, since it may prevent the client to identify to which

>      request the response belongs or to find the correct information to

>      verify integrity of the response.

><mglt>

>I am reading the text as. When the attacker is on-path, a long Token does

>not

>prevents the attack based on a spoofed response. However, for an attacker

>that

>is not on path, the attacker needs to guess the Token, and this can be

>mitigated (partially) by increasing the Token size.  Note that in the

>latest

>case, a long Token should not be seen as a replacement for cryptographic

>protection of the message. </mglt>

> 

>[GS:] There seems to be a misunderstanding somewhere. There is no need

>for anyone to “guess the Token” since it is not encrypted. There is

>nothing hinted about Token being a “replacement for crypto”, so I don’t

>understand why anyone would be lead to think that. Token length is

>mentioned twice; in the next to last sentence - mentioning that CoAP

>proxies (legitimately) may change Token length; and in the last sentence

>- describing that an on-path attacker may modify the Token Length which

>either created mismatch between request and response or no match at all,

>which are both denial of service. Is it clearer in the following way?

NEW

>o Token/Token Length. The Token field is a client-local identifier

>for differentiating between concurrent requests [RFC7252].

> 

> 

<mglt2>

What I was trying to say is that if you want to spoof a response ( like in DNS) and you are not on path, you need to guess the Token. In that sense, the longer the safer. However, as for DNS, we should not rely on this.  

</mglt2>

GS: Right, we don’t rely on the length of token for security.