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

From: Tal Mizrahi <[email-masked]>
Date: Sun, 6 Mar 2016 07:58:56 +0000

Hi All,

In the last few days we had two main suggestions:

(1)    Request the value 0x2005 for Checksum Complement extension fields.

(2)    Remove the requirement to have a fixed length of 28 octets.

Suggestion (1) will certainly be addressed.
There was a lot of discussion regarding (2), but it appears that there is no consensus around the suggestion to remove the 28-octet requirement.

Two important points should be made:

-          According to RFC 5905 + erratum 3627 (https://www.rfc-editor.org/errata_search.php?rfc=5905), it is not possible for the Checksum Complement extension field to be shorter than 28 octets. This restriction is further clarified in draft-ietf-ntp-extension-field. Hopefully, future updates to RFC5905 will place the MAC in its own extension field, and will allow other extension fields to be shorter than 28 octets. However, this is currently not the case.

-          The status of draft-ietf-ntp-checksum-trailer is experimental. That means that the definition of the Checksum Complement will be revised in the near future, and this revision may be an opportunity to relax the length requirement, assuming that by that time there will be a clear definition of shorter-than-28-octets extension fields.

Therefore, I would like to suggest to  leave the 28-octet length requirement as-is.

Comments will be welcome.
Thanks,
Tal.

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Sun, 06 Mar 2016 09:53:23 +0000

Tal Mizrahi writes:
> There was a lot of discussion regarding (2), but it appears that there is n=
> o consensus around the suggestion to remove the 28-octet requirement.
> 
> -          According to RFC 5905 + erratum 3627 (https://www.rfc-editor.org=
> /errata_search.php?rfc=3D5905), it is not possible for the Checksum Complem=
> ent extension field to be shorter than 28 octets. This restriction is furth=
> er clarified in draft-ietf-ntp-extension-field. Hopefully, future updates t=
> o RFC5905 will place the MAC in its own extension field, and will allow oth=
> er extension fields to be shorter than 28 octets. However, this is currentl=
> y not the case.

I wish I had noticed Errata ID 3627 earlier.  I think it is incorrect on
several counts and I'll be looking to properly document my concerns
about it.

Having said that, I'm OK with the proposal as Tal outlines moving
forward as an experimental document.

Having said that, ...

Autokey was defined with the requirement that its extension field be
protected by a MAC.  The revising language in Errata 3627 does not
address this at all.  One immediate recommendation is that 3627 be
amended to say that a MAC SHOULD be present in any packet that includes
any extension fields.

The language about the algorithms and resulting length of MAC payloads
is not limiting languaage, it is inclusive language.  While 5906
describes an MD5 MAC as producing a 128 bit digest along with a 4 byte
keyid, for a 20 byte MAC, and it also describes a 160 bit digest (with
no alagorithm named) along with a 4 byte keyid, for a 24 byte MAC.  That
in no way means these are the only two digest payload lengths that are
supported.  The NTP Project's Reference Implementation supports other
digest algorithms and resulting lengths as well, even though not all of
these algorithms are presently fully-implemented in the receiving code.
Some of these algorithms produce 512-bit digests, and result in a MAC of
68 bytes' length.

Even by the current logic of 3627, if that disambiguation style is
considered useful, the shortest extension field possible is 4 bytes.  So
any extension field before the current MAC can really be *any* allowed
length, it's only the *last* extension field where there might be an
issue.  In this case, it would be better (and still wrong, I thing) to
say "the last extension field in a packet cannot be 20 or 24 bytes'
long."

Given that we've never specified additional extension fields and nobody
has requested IANA assign additional Field Types, exactly where is the
risk in the disambiguation process I described in my earlier message?

If we're really that concerned about this problem, then all we need to
do is to create a new extension field, 8 bytes long, which indicates "I am
the last extension field", so any data after that would be an old-style
MAC.  Yes, at first thought this would preclude things like the checksum
complement proposal as currently stated, but in actuality it does not,
as as the checksum complement proposal is currently *only* allowed to
work if there is no MAC protection.

> -          The status of draft-ietf-ntp-checksum-trailer is experimental. T=
> hat means that the definition of the Checksum Complement will be revised in=
>  the near future, and this revision may be an opportunity to relax the leng=
> th requirement, assuming that by that time there will be a clear definition=
>  of shorter-than-28-octets extension fields.
> 
> Therefore, I would like to suggest to  leave the 28-octet length requiremen=
> t as-is.

Even so, if 3627 stands it says that the minimum Field Length is 28
octets.  Also requiring it in this proposal means that we have to
eventually clean up the Field Length issue in at least 2 places.
Removing the Field Length requirement in the checksum-complement
proposal means the Field Length should be adequately described somewhere
else, and it is.

But again, this is not a huge deal for me in the context of this
experimental draft.

H
--

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 7 Mar 2016 10:32:02 +0100

> amended to say that a MAC SHOULD be present in any packet that includes

Why? I think presence of MAC should be required by individual
extension fields which implement some form of authentication, it
shouldn't be a general suggestion. Hopefully in future we will have
extension fields for other things than authentication, and they can be
used without authentication.

> MAC. 

What would prevent a server from misinterpreting a random MAC in a
client packet that doesn't include this extension field as some
extension field?

-- 
Miroslav Lichvar

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 7 Mar 2016 10:01:52 +0000

I posted an updated draft:

https://datatracker.ietf.org/doc/draft-ietf-ntp-checksum-trailer/

Comments are still welcome.

Thanks,
Tal.

From: ntpwg [mailto:ntpwg-bounces+talmi=[email-masked]] On Behalf Of Tal Mizrahi
Sent: Sunday, March 06, 2016 9:59 AM
To: [email-masked]'; Karen ODonoghue ([email-masked]); Brian Haberman ([email-masked]); Suresh Krishnan
Subject: [ntpwg] The next step of draft-ietf-ntp-checksum-trailer

Hi All,

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 07 Mar 2016 10:21:15 +0000

> used without authentication.

Originally, the *only* extension field defined was for autokey, and the
RFCs that included autokey all *required* a MAC.

Tal's EXPERIMENTAL proposal for the next created extension field
*cannot* use a MAC because of the way it's implemented.

Therefore, I have recommended 2 things:

- clean up Tal's' errata so that it says a MAC SHOULD be provided.  That
means "Provide a MAC unless you really understand what's going on and
have a good reason for not using one."

- Use a flag bit in the Field Type that says "My extension field does
not require a following MAC."

There are 2 players here, and I'll call them "A" and "B".  It's one
thing for A to say "I think the extension field I am sending should be
covered by a MAC".  It's another thing for B to have the option to have
looser requirements.

With the proposals I've made, we've got that sort of flexibility.

The following extension fields are currently either available or in
various stages of proposal:

- Autokey
- MAC extension field
- NTS
- Checksum Complement
- Suggested REFID
- "I'm the last extension field"

>> If we're really that concerned about this problem, then all we need
>> to do is to create a new extension field, 8 bytes long, which
>> indicates "I am the last extension field", so any data after that
>> would be an old-style MAC.
> 

A bunch of things, which I may have covered in some earlier emails.

Off the top of my head:

- the only 2 implemented MACs we know about are 20 bytes for MD5 and 24
bytes for DES.  There's also a 28 byte MAC for SHA.  We have at least
partial support for longer digests, at least 256 bit and 512 bit.

- a MAC consists of a 4-byte keyid and a payload.  If there is no
autokey extension field, the keyid MUST be <65535, and we SHOULD have
that keyid in our chain.  If there is an autokey extension field, the
keyid MUST be >65535 and the key ID MUST (but at worst, SHOULD) be in
our chain.  As a secondary check, we could see if there is any way the
first two octets are a Field Type, and the second 2 octets would have to
be a longword-aligned length that was <= the remaining packet length,
and if you wanted to be really careful, if there was leftover data then
this fragment MUST be an extension field, or the next fragment MUST be
either an extension field or a MAC.  So it's pretty easy to validate
these things.

We can also see if it processes "both ways".  But more telling, if we're
dealing with an older/current server, there are limited options.  If
we're dealing with an "updated" server, we'll have enough information in
the packet to know what it contains.

I'm thinking the only other situation is somebody has an NTP network
where they need to send out both old and new style packets.  If they are
this "complicated" then I gotta believe they have the smarts to
understand their deployment, and if they *do* have problems they should
have the resources to configure their NTP network so that they send new
packets to new clients, and old packets to old clients.

But I also figure I could have missed something.
-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 7 Mar 2016 12:28:40 +0100

> have a good reason for not using one."

I still don't follow here.

> not require a following MAC."

Meaning the field is not related to authentication?

> covered by a MAC".  It's another thing for B to have the option to have

Can you give an example in which it would be useful to exchange that
information in NTP packets?

>From the client's point of view, it either requires the server packets
to be authenticated or not. If it does, it will send a field that
enables some form of authentication and the server will have to
process them in order to sent acceptable replies. When the association
is initialized, the client will verify that MAC in the reply is good
and covers all fields in the packet. There could be exceptions in the
future like correction fields for NTP-aware networking devices, but
that would a part of the specification that they are not covered by
MAC and are placed in the packet after the extension field containing
MAC.

> partial support for longer digests, at least 256 bit and 512 bit.

The SHA1 MAC is 24 octets, that's why there is a requirement for the
last extension field to be at least 28 octets.

> autokey extension field, the keyid MUST be <65535, and we SHOULD have

Isn't that restriction for keyid just for the autokey RFC? There are
NTP implementations that allow any keyid with symmetric keys.

> either an extension field or a MAC.  So it's pretty easy to validate

I think a MAC could still pass all these tests and appear as an
extension field. It wouldn't be a valid MAC, that would be extremely
unlikely, but the expected digest would have to be calculated in order
to detect that. The new restrictions on lengths of extension fields
are supposed to prevent that if I understand it correctly.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 07 Mar 2016 12:35:56 +0000

> I still don't follow here.

Please help me out.  I've written about this several times.

Originally, if there was an extension field there MUST be a MAC.

Tal wrrote Errata 3627 (or whatever) and removed that requirement.  I
didn't notice this.  I believe this was done because his experimental
checksum complement extension field, as written, *cannot* be done if
MAC protection is used.  In order to move his proposal forward, I've
delayed my proposal that provides similar functionality but allows the
first part of the packet to be protected by a MAC.

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, and after the NTS packet begins to include MAC protection, one
MAY still want to have additional MAC protection outside of the NTS
packet.

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

> Meaning the field is not related to authentication?

Meaning "My extension field does not require a MAC after it".  This is
the "MAY" case as opposed to the "SHOULD" case.  An example of this is
Tal's checksum complement proposal, as currently written.  If ntpd sends
out an unauthenticated packet, the FPGA engine is free to rewrite the
transmit timestamp, but since the OS has already computed a UDP
checksum, if the transmit timestamp in the packet is changed it's almost
certain that a checksum complement will be needed to make sure the
existing UDP checksum will still be correct.  That's what Tal's proposal
is all about, and it's the first time we've seen a proposal for an
extension field where one MUST NOT have a MAC at the end of the packet.

This is for 2 reasons.  One is that changing the transmit timestamp will
invalidate the MAC.  The other is that the FPGA engine has no idea how
to calculate the MAC, so it can't generate one.

> information in NTP packets?

I'll have to do this after I wake up.
 
> MAC and are placed in the packet after the extension field containing

I'll hvae to look at the above after I wake up.

> last extension field to be at least 28 octets.

4 byte keyid plus 24 octets.  So 28 bytes is clearly potentially
ambiguous.

Extension fields of 4, 8, 12, or 16 bytes are also unambiguous.  Why
prohibit these lengths?

> NTP implementations that allow any keyid with symmetric keys.

Originally:

- any extension field meant there MUST be a MAC.
- the only defined extention field as been autokey.
- if no extension field was present, then no autokey, and a MAC meant
  symmetric key was being used.  keyid < 65535.
- if an extension field was present, the autokey was being used, there
  MUST be a MAC, and  keyid > 65535.

> are supposed to prevent that if I understand it correctly.

Seems like false security to me.  It's easy enough to disambiguate.

Do you want to require *all* extension fields be at >68 bytes long
because somebody will want to use a 512 bit old-style MAC?  What if
somebody wants to use even longer digests?  What if somebody decides to
implement a MAC digest that uses some unexpected lengths?

Old (known) code will *never* do this.  New code will be using "MAC in
an extension field".

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 7 Mar 2016 14:16:25 +0100

> Originally, if there was an extension field there MUST be a MAC.

Right. That requirement was not necessary and it was later removed.

> Tal wrrote Errata 3627 (or whatever) and removed that requirement.

Yes, but why is that a problem?

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

> this field," and the other is "This extension field provides MAC

What will the receiver of this information do with it? 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.
Normally, the client will require all fields to be covered by MAC if
authentication is enabled.

> extension field where one MUST NOT have a MAC at the end of the packet.

Ok, but that information is already included in the specification. The
client or server that generates that field needs to know that.

> 4 byte keyid plus 24 octets.  So 28 bytes is clearly potentially

A SHA1 MAC has 160 bits for the digest and 32 bit for the key ID.
That's 192 bits or 24 octets total.

> Extension fields of 4, 8, 12, or 16 bytes are also unambiguous.  Why

Because MAC in a packet from an old client could be parsed as one or
multiple extension fields.

>   MUST be a MAC, and  keyid > 65535.

That applies to the reference implementation, but not necessarily for
other NTPv4 implementations. They can parse extension fields, but they
don't have to know anything about autokey and can authenticate with
MACs using key IDs above 65535.

---

From: [email-masked]
Date: Mon, 7 Mar 2016 18:08:16 +0100

E-Mail: [email-masked]

"ntpwg" <ntpwg-bounces+dieter.sibold=[email-masked]> schrieb am 
07.03.2016 14:16:25:

> Von: Miroslav Lichvar <[email-masked]>
> An: Harlan Stenn <[email-masked]>
> Kopie: "[email-masked]'" <[email-masked]>, "Karen 
> ODonoghue \([email-masked]\)" <[email-masked]>, Suresh 
> Krishnan <[email-masked]>
> Datum: 07.03.2016 14:40
> Betreff: Re: [ntpwg] The next step of draft-ietf-ntp-checksum-trailer
> Gesendet von: "ntpwg" <ntpwg-bounces+dieter.sibold=[email-masked]>
> 

Harlan, I do not agree that you need to protect the association and key 
exchange of NTS. The goal of the first exchanged messages of NTS is to 
securely authenticate the server and exchange the cookie. And yes, tough 
these messages are piggybacked on NTP messages, they do not protect NTP's 
time stamps. However the NTS messages in itself and especially the cookie 
exchange message are cryptographically protected. A client has the choice 
to trust or not to trust the time stamps exchanged during the association 
and cookie exchange.  After the cookie is being exchanged all following 
time requests and responses are of course protected by a MAC. So, a client 
always has the option only to trust the authenticated time stamps. I don't 
see that anyone want to distribute manually symmetric keys only for the 
purpose to protect the first three message exchanges of NTS. And if you 
are in a situation in which you can exchange symmetric keys with your 
customers you don't need to apply NTS. But in most cases, distribution of 
symmetric keys are realistically not an option.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 07 Mar 2016 22:46:04 +0000

> Right. That requirement was not necessary and it was later removed.

Really?  Please say more.  Where can I learn about this?

> Yes, but why is that a problem?

Because one can legislate the value of pi to be 3 since that would
make so many things easier.  That doesn't mean it's going to work in the
real world.

> authenticated and can't be used for anything except initialization of

Symmetric key would be an OK choice here.  Preferably using the "MAC in
an EF".

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

> The client must

Of course.

> authentication is enabled.

Yes.

So where is the confusion here?

> client or server that generates that field needs to know that.

The >sender< needs to know.  The >recipient< might be running old
software, current software, or software that's aware of these new EFs.

This all goes to what happens down the road when a newer sender is
talking to an older recipient.

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.

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

> multiple extension fields.

An old client will ONLY send autokey.  So this is a non-issue, right?

It's pretty easy to parse an EF and make sure it's sane.  If the current
spot in the extended payload parses as a good EF, then one can do a
quick check on any following data in the payload and get a good idea as
to what's going on.  At worst, you have a packet that CORRECTLY parses
as both "a bunch of EFs" and "an old-style MAC in a packet that either
has no extension field or is an autokey packet".  If only one of those
interpretations is correct, then we can dance on the head of the
false-negative or false-positive pin.

Remember, this is *only* a POTENTIAL problem when mixing new and old
implementations.  In that case folks may need to administratively
segregate these machines.  We can certainly solve this problem in NTPv5.

> MACs using key IDs above 65535.

The RFCs have clear requirements on the keyids.  If an implementation
chooses to be non-compliant that's the implementer's choice.  An
implementation that makes this choice has no leg to stand on if it
doesn't interoperate with compliant implementations.

And in this case it's not really that bad either - this older and
non-compliant implementation simply has to see if the 32-bit keyid is a
valid key in order to disambiguate the packet.

But we're back to the point where if you're running NTP networks where
you have both old and new NTP instances, you may need to have a way to
identify which machines are "old" and which are "new" and communicate
accordingly.

H

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 07 Mar 2016 22:54:40 +0000

Hi Dieter,

> "ntpwg" <ntpwg-bounces+dieter.sibold=[email-masked]> schrieb am 

The above claim has not yet been proven.

> > Yes, but why is that a problem?

The above is under discussion.

> > authenticated and can't be used for anything except initialization of

Answered in a separate email - symmetric key is AVAILABLE for this.
Doing this is a MAY/SHOULD.  Not a MUST.

> symmetric keys are realistically not an option.

Correct.  I am not saying MUST.

Are you saying that each of these 6 initial packets MUST NOT be
protected by any sort of MAC?

H

---

From: Danny Mayer <[email-masked]>
Date: Mon, 7 Mar 2016 22:42:44 -0500

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

>From what I understand from the NTS architects, the early NTS protocol
are protected by the contents and a MAC is not necessary.

> that is useful in deciding what to do in case the client  gets EFs it

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.

>> authentication is enabled.

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 which
needs to be the last part of the packet. 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.

> talking to an older recipient.

Yes. See my previous response.

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

> MACs, and they were 20, 24, and 28 bytes' long.  I'll see what I can

DES is 16, MD5 is 24, SHA1 is 28. Cryto-NAK is 4.
> 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.

> segregate these machines.  We can certainly solve this problem in NTPv5.

See my previous analysis.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Mon, 7 Mar 2016 22:49:28 -0500

> The above claim has not yet been proven.

See RFC 5905 Section 7.3 where it was optional but 7.5 said it was
required in the presence of an extension field. It was ambiguous and has
been clarified in the EF draft.

> protected by any sort of MAC?

What he's sayinmg is that the NTS exchange does not need to be protected
by a MAC. The Timestamps may need it if you want to use them or you wait
for NTS to complete its protocol exchange before trusting the packets.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 08 Mar 2016 05:01:38 +0000

> draft was meant to remove the ambiguities.

Autokey has ALWAYS required MAC authentication.

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.

I'm being a bit harsh.  Regardless of whether or not that harshness is
justified, I'm open to learning a better way to communicate these points.

> are protected by the contents and a MAC is not necessary.

I've asked.

But this issue is more than just NTS.

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

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?

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

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.

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

Sure.

> Yes. See my previous response.

Yes, and please note what I wrote above.

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

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.

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

If there is a 28 byte MAC field, then that errata is wrong.  Regardless,
the errata change does not allow for longer digests.

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

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 my previous analysis.

Your analysis is clearly wrong from what I can see.

Please read what I wrote more carefully.

H

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 08 Mar 2016 06:19:36 +0000

> been clarified in the EF draft.

Yes.  It is optional UNLESS THERE IS AN EF.  Then it is required.

If the errata does not make this clear or reinforce this, the
"clarification" in the errata is wrong.

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

If the above quote came from me, it's not clear that the first few
packets of the NTS exchange MAY/SHOULD have MAC protection.  I don't
recall the context anymore.

Starting with the 7th NTS packet, the NTS EF has a MAC.

We need to see what, if any, extra protection should be applied to the
first 6 packets.

>>> Harlan, I do not agree that you need to protect the association and
>>> key exchange of NTS. The goal of the first exchanged messages of NTS
>>> is to securely authenticate the server and exchange the cookie.

Please 'splain to me how you can "securely authenticate the server and
exchange the cookie" with no MAC on the first exchanged message.

>>> And yes, tough these messages are piggybacked on NTP messages, they
>>> do not protect NTP's time stamps. However the NTS messages in itself
>>> and especially the cookie exchange message are cryptographically
>>> protected.

So the first 6 messages are cryptographically protected but the
timestamps are not protected?

I have not dug in to the NTS protocol dance.  I am curious how the
initial cookie exchange can be trusted if the timestamps are not
protected.

>>> A client has the choice to trust or not to trust the time
>>> stamps exchanged during the association and cookie exchange.

The iburst exchange is an ideal opportunity to exchange NTS keys.  It's
also a critically important time to exchange trustable timestamps.

So the first 3 of 8 exchanges SHOULD be protected with a MAC until NTS
is protecting the timestamps, as that's the startup period where we're
trying to quickly and safely get enough samples to get the filter primed
and see if the loop is stable.

>>> After the cookie is being exchanged all following time requests and
>>> responses are of course protected by a MAC. So, a client always has
>>> the option only to trust the authenticated time stamps. I don't see
>>> that anyone want to distribute manually symmetric keys only for the
>>> purpose to protect the first three message exchanges of NTS.

iburst.  Folks want ntpd stabilized in the first 11 seconds' time.  If
that takes 15 or 17 seconds' time because we have to ignore the first
few packets that will cause complaints, but these folks can set up
symmetric keys or make other changes to mitigate this problem.

We're expecting NTS to be of more value in a WAN setting than in a LAN
setting, right?

>>> And if you are in a situation in which you can exchange symmetric
>>> keys with your customers you don't need to apply NTS. But in most
>>> cases, distribution of symmetric keys are realistically not an
>>> option.
>> 
> What he's saying is that the NTS exchange does not need to be protected

I asked what YOU were saying, Danny, not what Dieter was saying.
Somebody removed a response in there.

Let's get clarification from Dieter, et al on this point.

And you're assuming the sender can dictate policy to the recipient
again.

It's the recipient's choice as to whether or not it will accept
unauthenticated packets.

I'm also curious to see how NTS plays with iburst.

H

---

From: [email-masked]
Date: Tue, 8 Mar 2016 12:29:43 +0100

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

> understand it, then the client can look for an old-style MAC.

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

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

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

---

From: Danny Mayer <[email-masked]>
Date: Tue, 8 Mar 2016 15:01:29 -0500

Yes.

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

>> not it indicates that it requires a MAC. You can't do anything with it.

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.

> understand it, then the client can look for an old-style MAC.

It needs to provide for that possibility anyway.

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

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

> No.  It just means that the MAC verifies content up to the MAC.

Which is what I said though in different words.

> the client doesn't understand that EF, the client has *less* reason to

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.

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

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

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

> 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