Re: [ntpwg] The next step of draft-ietf-ntp-checksum-trailer

[[e-mail]]

> > I recall that there were conflicting statements in RFC5905 (NTPv4) and
> > RFC5906 (autokey) when we were doing the extension field draft and 
that
> > was one of the reasons that we clarified that the MAC was optional in
> > that draft. Section 7.3 of RFC5905 indicates that the MAC is optional
> > but elsewhere it seemed to be required. The EF draft makes it clear 
that
> > it is optional though any specific extension field may require it. The
> > draft was meant to remove the ambiguities.
> 
> Autokey has ALWAYS required MAC authentication.

There is a distinction between "an Autokey EF always requires a MAC in the 
packet" (which makes sense) and "any EF always requires a MAC in the 
packet" (which does not make much sense).

However, the latter is what the language of RFC5905 implies:
> 7.5.  NTP Extension Field Format
>
>   In NTPv4, one or more extension fields can be inserted after the
>   header and before the MAC, which is always present when an extension
>   field is present.

This language was absolutely worth re-considering.



> >>>> We're getting ready to publish a "MAC in an Extension Field", and
> >>>> arguably this is how it should have been originally done.  So in 
keeping
> >>>> with the above logic, there are 2 pieces of information we want to 
see
> >>>> for an extension field.  One is "SHOULD or MAY have MAC protection 
after
> >>>> this field," and the other is "This extension field provides MAC
> >>>> protection."
> >>>
> >>> What will the receiver of this information do with it?
> >> 
> >> Whatever it wants.  This goes to giving the client basic information
> >> that is useful in deciding what to do in case the client  gets EFs it
> >> doesn't understand.
> >> 
> > 
> > If it gets EF's it doesn't understand it makes no difference whether 
or
> > not it indicates that it requires a MAC. You can't do anything with 
it.
> 
> That's not true.
> 
> If the EF says "I am a MAC" and the client doesn't
> understand it, then the client can look for an old-style MAC.

Shouldn't the client always scan for an old-style MAC?

> 
> If the unknown EF says "I don't NEED a MAC" then context can provide
> information as to whether or not it makes a difference.
> 
> I think the better questiion is why do you want to categoricaly deny
> this information to the client?

For a long time, my opinion on this topic was: "I don't see how the 
information [Do I require a MAC: Yes/No] and [Do I contain a MAC: Yes/No] 
is useful, but I also don't see how it would hurt."

This has changed after some more consideration: I now believe it would be 
dangerous to include a bit [Do I require a MAC: Yes/No]. An attacker would 
have the option of moving extension fields to the end of the packet (e.g. 
after a MAC-containing EF) and to be able to flag them as [Do I require a 
MAC: No]. If the receiver actually considered this in their processing of 
the packet, bad things could happen (in particular, this might lead to 
cases where false security is created).

> > If it uses an extension
> > field that requires a MAC, not providing it needs to cause the packet
> > to be dropped by the receiving server.

Yes, I would add to this: "If [a packet] uses an extension field that [as 
per the receiver's own policy] requires a MAC, then not providing [said 
MAC] needs to cause the packet to be dropped by the receiver [, even if 
the extension field claims in its field type flag that it does not need to 
be secured]."

Overall, I would prefer a requirement that the client MUST NOT change 
their behavior towards a packet because of the proposed new bits, 
especially those in unprotected EFs. Which makes me think that introducing 
those bits is maybe not a good idea after all.


ADDENDUM: I don't think it is a great idea, but IF you really want to 
communicate information about what contents of a packet are allowed to be 
included unsecured in the case where at least parts of the packet are 
secured, then the list of permitted unsecured content should be secured 
itself. Read: there would be an EF before the MAC, and the payload of that 
EF would contain a list of EF field type values, each representing an 
unsecured EF that is to be appended after the MAC (this assumes that the 
sender knows the number and type of unsecured EFs that it later wishes to 
append).
My proposal would solve the problem posed in the following:
 
> My alternative to Tal's proposal *allows* a "MAC as an EF", and the
> checksum complement that comes after this has the bit that says "I do
> not need a MAC".  So what is protected is the base NTP packet, any other
> EFs, and the "MAC as and EF".  The only other subsequent data in the
> packet is the "precision transmit adjustmenet and the checksum
> complement".
> 
> This last EF is *not* protected, and that's OK.

_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg