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

[Danny Mayer <[e-mail]>]

On 3/8/2016 12:01 AM, Harlan Stenn wrote:
> Danny Mayer writes:
>> On 3/7/2016 5:46 PM, Harlan Stenn wrote:
>>> Miroslav Lichvar writes:
>>>> On Mon, Mar 07, 2016 at 12:35:56PM +0000, Harlan Stenn wrote:
>>>>> Originally, if there was an extension field there MUST be a MAC.
>>>>
>>>> Right. That requirement was not necessary and it was later removed.
>>>
>>> Really?  Please say more.  Where can I learn about this?
>>>
>>
>> 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.

Yes.

> If y'all clarified it otherwise that was a mistake, and it SHOULD be
> rectified.
> 
> See https://www.eecis.udel.edu/~mills/ntp/html/autokey.html for more
> information.
> 
> I find it disturbing that an error of this magnitude was able to make it
> this far given the level and quantity of people who looked at it.
> 

No. See Section 7.5.1.1 of that draft. To quote: "A specification that
defines a new extension field MUST specify whether the extension field
requires a MAC or not."

>>>>> MAC protection is good.  NTS uses a 'single' Field Type, but the first
>>>>> few packets have no MAC protection.  Therefore, the first few packets of
>>>>> an NTS exchange arguably MUST have MAC protection outside the NTS
>>>>> packet
>>>>
>>>> With what key would that MAC be generated? Unless I misunderstood how
>>>> NTS is supposed to work, the first few packets are simply not
>>>> authenticated and can't be used for anything except initialization of
>>>> the NTS association.
>>
>> From what I understand from the NTS architects, the early NTS protocol
>> are protected by the contents and a MAC is not necessary.
> 
> I've asked.
> 
> But this issue is more than just NTS.
> 
>>> Symmetric key would be an OK choice here.  Preferably using the "MAC in
>>> an EF".
>>>
>>>>> 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.

An extension field that requires a MAC will include the MAC unless it's
a rogue packet. Either way, if it's an unknown EF then it makes no
difference whether or not a MAC is present since there's nothing you can
do with an unknown extension field except to ignore it or drop the
packet. Either way it makes no difference whether or not an EF requires
a MAC.

> 
> 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.
> 

It needs to provide for that possibility anyway.

> 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.
> 

If the EF is unknown there is no context since the EF is meaningless to
the receipient.

> I think the better questiion is why do you want to categoricaly deny
> this information to the client?
> 

Nothing is being denied to the recipient. If there is a MAC then there's
no issue whether or not the EF needs one. If there is no MAC and you
encounter an unknown EF it also makes no difference since there is
nothing you can do with the EF anyway.

>>>> The client must
>>>> have its own policy on what extension fields has to be covered with
>>>> MAC in order to accept the packet. The server can't dictate that.
>>>
>>> Of course.
>>>
>>>> Normally, the client will require all fields to be covered by MAC if
>>>> authentication is enabled.
>>>
>>> Yes.
>>
>> If you mean the sender then either it provides a MAC of either style or
>> it doesn't. The MAC covers all parts of the packet until the MAC
> 
> Yes.
> 
>> which needs to be the last part of the packet.
> 
> No.  It just means that the MAC verifies content up to the MAC.
> 

Which is what I said though in different words.

>>> If a recipient gets data it does not understand, it may benefit from a
>>> hint as to what's going on with that unknown EF.
>>
>> No, it has no way of going on with any unknown EF. If you don't
>> understand it you can't do anything with it.
> 
> Danny, I think you are too sure of your facts.
> 
> For example, if a client sees an EF that says "I don't need a MAC" and
> the client doesn't understand that EF, the client has *less* reason to
> drop the entire packet.
> 

Since it doesn't know the EF it has zero knowledge of what to do with
it. As I said earlier just because it may not need a MAC doesn't mean
that a MAC may not be available anyway because some other EF needs it.

> Note well what you wrote above:
> 
>   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.
> 
> so you are now arguing both sides of your position.
> 

In normal operation an sender which includes an EF that needs a MAC will
include one (or more). If the recipient doesn't understand the EF it
will still get the MAC and verify the digest but then what. It still has
no idea what to do with the EF.

>>>>>> The SHA1 MAC is 24 octets, that's why there is a requirement for the
>>>>>> last extension field to be at least 28 octets.
>>>>>
>>>>> 4 byte keyid plus 24 octets.  So 28 bytes is clearly potentially
>>>>> ambiguous.
>>>>
>>>> A SHA1 MAC has 160 bits for the digest and 32 bit for the key ID.
>>>> That's 192 bits or 24 octets total.
>>>
>>> OK.  What I remember is hearing that we were seeing 3 sizes of old-style
>>> MACs, and they were 20, 24, and 28 bytes' long.  I'll see what I can
>>> find out.
>>
>> DES is 16, MD5 is 24, SHA1 is 28. Cryto-NAK is 4.
> 
> Miroslav disagrees with you, but what you wrote is what I recall, too.
> 

I got the numbers from the reference implementation code. However the
only real requirement in that code is the it be no larger than 6*32 bits.

> If there is a 28 byte MAC field, then that errata is wrong.  Regardless,
> the errata change does not allow for longer digests.
> 
>>>>> Extension fields of 4, 8, 12, or 16 bytes are also unambiguous.  Why
>>>>> prohibit these lengths?
>>>>
>>>> Because MAC in a packet from an old client could be parsed as one or
>>>> multiple extension fields.
>>>
>>> An old client will ONLY send autokey.  So this is a non-issue, right?
>>
>> No. An old client may also send symmetric key, ie only a MAC and no EF.
> 
> Huh?  You don't seem to be paying attention.  The premise here is that
> extension field that DOES NOT have the same length of a MAC is allowed.
> 

But you don't know the actual size of the MAC so it's very hard to tell.

> So if we're to believe that "we should not allow an EF that has the same
> length as a MAC" then what you say makes no sense.  Furthermoer, it's
> only the *last* EF that would have this length restriction.
> 

See the EF Draft Section 7.5.1.2 to 7.5.1.4 which spells out the rules.

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