Subject: Re: [tcpm] [Technical Errata Reported] RFC5926 (5267)

From: "Brian Weis (bew)" <[email-masked]>
Date: Wed, 28 Mar 2018 19:42:11 +0000

Hi Joe,

Sorry, I missed your reply to this before the errata was rejected.

On Feb 28, 2018, at 6:56 AM, Joe Touch <[email-masked]<mailto:[email-masked]>> wrote:

Hi, all,

This errata should be rejected.

NIST-SP800-108 does not require the use of 0x00 (see cited text below). It only requires that the length and order of each field be defined unambiguously.

This is correct. The issue is whether all TCP-AO implementations implementing NIST SP800-108 all add the 0x00 or not. If there is confusion between implementations then they will not generate the same session keys.

The length of “TCP-AO” is clearly and unambiguously 6 octets, as defined in the existing RFC text. The method of providing that length unambiguously to the KDF algorithm is an implementation issue.

I disagree that it is unambiguously 6 octets.  The use of double-quotes is often construed as a null-terminated string. This can be read as a null-terminated 7 octet string. In fact, this is the exact question asked by an implementor, and why I filed the errata. I believe it is a reasonable request to clarify this one way or the other.

If you agree with this, I’ll open another errata indicating the problem more clearly.

My preference for clarifying that it does include the 0x00 is for safety. While the current RFC has only one label field (“TCP-AO”), if another string beginning with ‘TCP-AO’ were also defined then there could be confusion between the two generated keys. Since the cost of adding 0x00 to the calculation is negligible, it seems prudent to  be safe.

Thanks,
Brian

Joe

The following text is clear that 0x00 is optional:

12) 0x00 – An all zero octet. An optional data field used to indicate a separation of different variable length data fields1.

1 This indicator may be considered as a part of the encoding method for the input data and can be replaced by other indicators, for example, an indicator to represent the length of the variable length field. If, for a specific KDF, only data fields with identical length are used, then the indicator may be omitted.

and later, 0x00 is given as a choice used in the example presented, not as a requirement:

The length for each data field and an order shall be defined unambiguously. For example, the length and the order may be defined as a part of a KDF specification or by the protocol where the KDF is used. In each of the following sections, a specific order for the feedback value, the counter, the Label, the separation indicator 0x00, the Context, and [L]2 is used, assuming that each of them is represented with a specific length. This Recommendation specifies several families of KDFs. Alternative orders for the input data fields may be used for different KDFs.

---------------------

On Feb 26, 2018, at 11:02 AM, RFC Errata System <[email-masked]<mailto:[email-masked]>> wrote:

The following errata report has been submitted for RFC5926,
"Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5267

--------------------------------------
Type: Technical
Reported by: Brian Weis <[email-masked]<mailto:[email-masked]>>

Section: 3.1.1

Original Text
-------------
- Label:     A binary string that clearly identifies the purpose
                  of this KDF's derived keying material.  For TCP-AO,
                  we use the ASCII string "TCP-AO", where the last
                  character is the capital letter "O", not to be
                  confused with a zero.  While this may seem like
                  overkill in this specification since TCP-AO only
                  describes one call to the KDF, it is included in
                  order to comply with FIPS 140 certifications.

Corrected Text
--------------
- Label:     A binary string that clearly identifies the purpose
                  of this KDF's derived keying material.  For TCP-AO,
                  we use the ASCII string "TCP-AO", where the last
                  character is the capital letter "O", not to be
                  confused with a zero. The ASCII string is terminated
                  with a null octet (0x00). While this may seem like
                  overkill in this specification since TCP-AO only
                  describes one call to the KDF, it is included in
                  order to comply with FIPS 140 certifications.

Notes
-----
This section states that "Both of these KDFs are based on the iteration-mode KDFs specified in [NIST-SP800-108].", which is later clarified to be the "counter mode" KDF defined in that document. The definition of the "Label" input to the KDF in the original text is not clear.

[NIST-SP800-108] specifies that a 0x00 octet should follow the Label. This 0x00 octet is important when the KDF does not have control over the Context given it, which is the case here -- RFC 5926 depends on the definition in RFC 5925. RFC 5925 currently declares two fixed-size inputs for the Context (See Figures 7 & 8 of RFC 5925), so the Context length differs. Also, RFC 5925 RFC could be updated over over time to include other Contexts that are variable sized. The risk of excluding 0x00 is enabling an attacker to choose a specially-crafted Context that violates the clean separation between the Label and Context arguments. Therefore, it is important to include the 0x00 octet for TCP-AO.

I believe this 0x00 is implied in the specification of the string "TCP-AO", since conventionally many string definitions include a trailing 0x00 octet, The text should state that the 0x00 octet is present as part of the string.

If this errata does not result in adding the 0x00 octet, then its omission needs to be justified.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5926 (draft-ietf-tcpm-tcp-ao-crypto-03)
--------------------------------------
Title               : Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)
Publication Date    : June 2010
Author(s)           : G. Lebovitz, E. Rescorla
Category            : PROPOSED STANDARD
Source              : TCP Maintenance and Minor Extensions
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
tcpm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tcpm

--
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]<mailto:[email-masked]>

---

From: [email-masked]
Date: Thu, 29 Mar 2018 11:46:55 -0400

On 2018-03-28 15:42, Brian Weis (bew) wrote:
>> On Feb 28, 2018, at 6:56 AM, Joe Touch <[email-masked]> wrote:
>> 
>> 
>> Hi, all,
>> 
>> NIST-SP800-108 does not require the use of 0x00 (see cited text
>> below). It only requires that the length and order of each field be
>> defined unambiguously.
> 
>  This is correct. The issue is whether all TCP-AO implementations
> implementing NIST SP800-108 all add the 0x00 or not. If there is
> confusion between implementations then they will not generate the same
> session keys.

We use a fixed string ("TCP-AO"), not a variable one. As a result, we 
don't need a flag to indicate the length of the string, and the flag 
0x00 is only one way to do such an indication (vs. a second length field 
or other flag value). Page 11 footnote of the NIST spec explains this.

> 
>> The length of “TCP-AO” is clearly and unambiguously 6 octets, as
>> defined in the existing RFC text. The method of providing that
>> length unambiguously to the KDF algorithm is an implementation
>> issue.
> 
>  I disagree that it is unambiguously 6 octets.  The use of
> double-quotes is often construed as a null-terminated string.

strlen("TCP-AO") = 6.

The null is a C encoding. Other languages use other ways to indicate the 
length of the string.

> This can
> be read as a null-terminated 7 octet string.

That actually cannot be expressed in C. Strings in C cannot have 
internal nulls; they would be interpreted as terminators.

> In fact, this is the
> exact question asked by an implementor, and why I filed the errata. I
> believe it is a reasonable request to clarify this one way or the
> other.

Neither Mirja nor I read the NIST spec that way. C strlen agrees with us 
too.

I really think the implementer is getting wrapped around implementation 
details, which are both language and implementation specific and don't 
need to be in the spec IMO.

Joe

> My preference for clarifying that it does include the 0x00 is for
> safety. While the current RFC has only one label field (“TCP-AO”),
> if another string _beginning_ with ‘TCP-AO’ were also defined then
> there could be confusion between the two generated keys. Since the
> cost of adding 0x00 to the calculation is negligible, it seems prudent
> to  be safe.
> 
> Thanks,
> Brian
> 
>> Joe
>> 
>>> 12) 0x00 – An all zero octet. An optional data field used to
>>> indicate a separation of different variable length data fields1.
>>> 
>>> 1 This indicator may be considered as a part of the encoding
>>> method for the input data and can be replaced by other indicators,
>>> for example, an indicator to represent the length of the variable
>>> length field. If, for a specific KDF, only data fields with
>>> identical length are used, then the indicator may be omitted.
>> 
>>> The length for each data field and an order shall be defined
>>> unambiguously. For example, the length and the order may be
>>> defined as a part of a KDF specification or by the protocol where
>>> the KDF is used. In each of the following sections, a specific
>>> order for the feedback value, the counter, the Label, the
>>> separation indicator 0x00, the Context, and [L]2 is used, assuming
>>> that each of them is represented with a specific length. This
>>> Recommendation specifies several families of KDFs. Alternative
>>> orders for the input data fields may be used for different KDFs.
>> 
>> ---------------------
>> 
>>> On Feb 26, 2018, at 11:02 AM, RFC Errata System
>>> <[email-masked]> wrote:
>>> 
>>> Reported by: Brian Weis <[email-masked]>
>>> 
>>> Section: 3.1.1
>>> 
>>> Original Text
>>> -------------
>>> This section states that "Both of these KDFs are based on the
>>> iteration-mode KDFs specified in [NIST-SP800-108].", which is
>>> later clarified to be the "counter mode" KDF defined in that
>>> document. The definition of the "Label" input to the KDF in the
>>> original text is not clear.
>>> 
>>> [NIST-SP800-108] specifies that a 0x00 octet should follow the
>>> Label. This 0x00 octet is important when the KDF does not have
>>> control over the Context given it, which is the case here -- RFC
>>> 5926 depends on the definition in RFC 5925. RFC 5925 currently
>>> declares two fixed-size inputs for the Context (See Figures 7 & 8
>>> of RFC 5925), so the Context length differs. Also, RFC 5925 RFC
>>> could be updated over over time to include other Contexts that are
>>> variable sized. The risk of excluding 0x00 is enabling an attacker
>>> to choose a specially-crafted Context that violates the clean
>>> separation between the Label and Context arguments. Therefore, it
>>> is important to include the 0x00 octet for TCP-AO.
>> 
>>> I believe this 0x00 is implied in the specification of the string
>>> "TCP-AO", since conventionally many string definitions include a
>>> trailing 0x00 octet, The text should state that the 0x00 octet is
>>> present as part of the string.
>>> 
>>> [email-masked]
>> [email-masked]
> Email: [email-masked]

---

From: Theodore V Faber <[email-masked]>
Date: Thu, 29 Mar 2018 15:55:26 +0000

Do you need to specify the character encoding (something like utf-8 encoding of unicode or ASCII) to guarantee that the string is 6 octets?

--
Ted Faber <[email-masked]>
Senior Engineering Specialist
Computer Systems Research Department
The Aerospace Corporation
310-336-7373

________________________________________
From: tcpm <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Thursday, March 29, 2018 08:46
To: Brian Weis (bew)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; RFC Editor
Subject: Re: [tcpm] [Technical Errata Reported] RFC5926 (5267)

strlen("TCP-AO") = 6.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 29 Mar 2018 08:58:09 -0700

We spec the label as those 6 characters as ASCII. 

Joe

> On Mar 29, 2018, at 8:55 AM, Theodore V Faber <[email-masked]> wrote:
>