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

[[e-mail]]

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]