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

[Sean Turner <[e-mail]>]

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.