Re: [secdir] secdir review of draft-ietf-ntp-extension-field

[Tal Mizrahi <[e-mail]>]

Hi Sean,

Sorry for the delayed response.
We have revised the draft, and we hope the current version addresses the issues you raised.
Since we can't currently post the new version, it is attached, along with a diff version.

Please let us know if there are further comments.

Thanks,
Tal.

>-----Original Message-----
>From: Sean Turner [mailto:[e-mail]]
>Sent: Wednesday, October 14, 2015 4:34 PM
>To: [e-mail]
>Cc: [e-mail]; The IESG; [e-mail]
>Subject: Re: secdir review of draft-ietf-ntp-extension-field
>
>Danny,
>
>Sorry it's been so long to get back to you on this.  Responses inline (I snipped
>out he nits and the ones that look like we agreed on).
>
>spt
>
>On Sep 16, 2015, at 13:02, Danny Mayer <[e-mail]> wrote:
>
>> Sorry for the delay in responding. I've been up to my ears in problems.
>> See my feedback below.
>>
>> Danny
>>
>> On 8/27/2015 9:08 AM, Sean Turner wrote:
>>> Fear not as this is just the secdir review!
>>>
>>> I have reviewed this document as part of the security directorate's
>>> ongoing effort to review all IETF documents being processed by the
>>> IESG.  These comments were written with the intent of improving
>>> security requirements and considerations in IETF drafts. Comments not
>>> addressed in last call may be included in AD reviews during the IESG
>>> review.  Document editors and WG chairs should treat these comments
>>> just like any other last call comments.
>>>
>>> draft summary: This draft updates NTPv4 Protocol and Algorithm
>>> Specification (aka RFC 5905) s7.5, which is the section that
>>> describes extension fields, and to paraphrase the: clarify the
>>> relationship between extension fields and MACs and define the
>>> behavior of a host that receives an unknown extension field.  Note
>>> that when comparing the "OLD" section to RFC 5905, you'll should note
>>> that the "OLD" text incorporates a verified errata
>>> (http://www.rfc-editor.org/errata_search.php?eid=3627).  The "NEW"
>>> text requires things like when defining an extension the definition
>>> must specify whether it must be MACed or not, the MTI MAC, the length
>>> of the MAC, etc.
>>>
>>> secdir status summary: I need to clarify something in my mind, which
>>> I hope fall into the "you missed that in this spec over here" or the
>>> "these are *NOT* the droids you're looking for" bucket, before I can
>>> say "ready with nits":
>>>
>>> 0) 7.5.1.1 says an extension can support multiple MACs, that the
>>> extension's document defines the MTI algorithm & MAC length, and that
>>> if more than one algorithm is allowed the extension includes an
>>> indication of which one was actually used; all great.  But, I'm
>>> trying to figure out how that fits with RFC 5905:
>>>
>>> - In s7.3, I see "dgst (128)" in f8
>>>
>>> - In s9.2, I see "There is no specific requirement for
>>> authentication; however, if authentication is implemented, then the
>>> MD5-keyed hash algorithm described in [RFC1321] must be supported"
>>>
>>> Doesn't s7.3 limit the MAC to HMAC-MD5 and the length to 128?  I mean
>>> if you're going to allow an extension to override s9.2 that seems
>>> like something worth noting in say the abstract/intro.
>>
>> Now that you bring this up, I should tell you that the reference
>> implementation implements MD5 and NOT HMAC_MD5 but it also
>implements
>> DES (not 3DES) and SHA-1! None of this is documented of course and the
>> packets are inspected for which algorithm to use based on the size of
>> the MAC field! Since there is no way to know from the packet whether
>> there is one or more extension fields or if there is a MAC present the
>> code ends up guessing which in turn limits the size that you can give
>> an extension field. This all leads to the strange wording in section
>> 7.5.1.3 and 7.5.1.4 in the draft and is necessary to detect the
>> presence of a MAC.
>>
>> We probably need to update the dgest field in RFC5905 to make it clear
>> that it can have multiple lengths depending on the algorithm used. On
>> the other hand I would prefer to get rid of the MAC and turn it into
>> an extension field, assuming that the NTS/CMS scheme is not used. The
>> advantages of that is obvious especially as no guessing would be
>> required and we could specify the algorithm to use and you could have
>> multiple MAC extension fields that would cover different parts of the
>> packet.
>>
>>>
>>> Thinking there's got to be a reason for this I went off and looked at
>>> the other NTP WG drafts ... after finding the NTS & CMS-based specs,
>>> are the changes proposed in this draft to to allow an NTP packet blob
>>> that doesn't use the MAC mechanism described in RFC 5905 but instead
>>> use the NTS/CMS "scheme", i.e., an NTP extension that is a CMS
>>> object, with no MAC in the 5905 sense - the CMS object instead of the
>>> NTP MAC field gives you the authentication?
>>>
>>> 1) s7.5.1.2 seems to be saying if extension A specifies alg X, and
>>> extension B specifies alg X and Y, and extension C specifies alg Y
>>> then extension A and B can appear together as can extension B and C,
>>> but A and C can't appear together?   Sounds great, but what if A and
>>> C do appear together what happens?
>>
>> I think that the draft makes it clear that you cannot have that case
>> since it requires that the MAC use one algorithm. "multiple extension
>> fields that require a MAC they MUST all require use of the same
>> algorithm and MAC length"
>
>Ah that might be it MTI vs MTU.  I was reading this as extension A specifies the
>MTI (Mandatory to Implement) algorithms X, Y.  What you're saying is that the
>definition says extension A MUST use algorithm X.
>
>>> 2) Still on 7.5.12: "If there are multiple extension fields that
>>> require a MAC they MUST all require use of the same algorithm and MAC
>>> length."
>>>
>>> So if I specify extension A with X as the MUST, and extension B with
>>> X as the SHOULD and Y as the MUST, then I can't include both
>>> extension A and B?  Extension A requires X, but extension B requires
>>> Y.
>>
>> That's right.
>
>I guess the IETF review process for extension types should provide some
>sanity here, but couldn't this result in multiple versions of the same attribute
>one for each algorithm?  Extension A requires the use of alg X, Extension A'
>requires the use of alg Y, etc?  (then again maybe I'm being dense this
>morning)
>
>>> 3) s7.5.1.3: What's the 24-octet limitation based on?
>>>
>>
>> The MAC guessing game. See the insanity above.
>
>Okay so it's not just me ;)
>
>>> Minor:
>>>
>>> 0) The new s7.5 says:
>>>
>>> The Field Type field is specific to the defined function and is not
>>> elaborated here.  If a ....
>>>
>>> 0.a) I think what you're trying to say is that the Field Type field
>>> is defined in an IANA registry and it's length and value are defined
>>> by the document referred to by the registry?
>>>
>>
>> Yes.
>
>Might be worth unpacking that in the draft, but I'm certainly not hard over on
>this ;)
>
>  The Field Type field is specific to the defined function and is not
>  elaborated here;  the Field Type field is defined in an IANA registry
>  and its length and value are defined by the document referred to
>  by the registry.
>
>>> 0.b) Neither RFC5905 nor this document specify how the padding is
>>> done.  Is padding determined by the document referred to by the field
>>> type?  I.e., can I do padding with all 1s and somebody else do it
>>> with all zeros?
>>>
>>
>> It shouldn't matter. If the extension field specification needs it to
>> be specific it should state that in the specification.
>
>ack - you define the extension and the padding just falls out.