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

[Theodore V Faber <[e-mail]>]

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 <[e-mail]>
Senior Engineering Specialist
Computer Systems Research Department
The Aerospace Corporation
310-336-7373


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

On 2018-03-28 15:42, Brian Weis (bew) wrote:
> Hi Joe,
>
> Sorry, I missed your reply to this before the errata was rejected.
>
>> On Feb 28, 2018, at 6:56 AM, Joe Touch <[e-mail]> 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.

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


>
> 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
>>> <[e-mail]> 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 <[e-mail]>
>>>
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>
> --
> Brian Weis
> Security, CSG, Cisco Systems
> Telephone: [phone]
> Email: [e-mail]

_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm