Subject: [ntpwg] RFC7822 issues

From: Harlan Stenn <[email-masked]>
Date: Thu, 5 May 2016 11:04:02 -0700

Folks,

As I've mentioned before, I have some major concerns about this document.

I'd like to describe these now, in "document order".

1. Introduction

   The NTP header format consists of a set of fixed fields that may be
   followed by some optional fields. Two types of optional fields are
   defined, Message Authentication Codes (MAC), and extension fields, as
   defined in Section 7.5 of [RFC5905].

   If a MAC is used, it resides at the end of the packet. This field can
   be either 24 octets long, 20 octets long, or a 4-octet crypto-NAK.

   NTP extension fields were defined in [RFC5905] as a generic mechanism
   that allows to add future extensions and features without modifying
   the NTP header format (Section 16 of [RFC5905]).

   The only currently defined extension fields are the ones used by the
   AutoKey protocol [RFC5906], and the Checksum Complement [NTPComp].
   The AutoKey extension field is always followed by a MAC, and Section
   10 of [RFC5906] specifies the parsing rules that allow a host to
   distinguish between an extension field and a MAC. However, a MAC is
   not mandatory after an extension field; an NTPv4 packet can include
   one or more extension fields without including a MAC (Section 7.5 of
   [RFC5905]).

First, a nit in the first paragraph.  I'd swap the order in the last
sentence and gently tweak, so it instead reads:

   Two types of optional fields are defined, extension fields, as
   defined in Section 7.5 of [RFC5905], and a Message Authentication
   Code (MAC), as defined in Section 7.3 of [RFC5905].

My concerns about the 2nd paragraph are more substantive.  The way it's
phrased seems exclusionary.  It must not be.  I recommend:

   If a MAC is provided it resides at the end of the packet. The
   length of this field depends on the algorithm used and any
   extra padding which may be added.  Usual values are 24 octets
   long, 20 octets long, or a 4-octet crypto-NAK.

Similarly, the 4th paragraph lays groundwork for subsequent assertions
that I believe are not desirable.  I recommend changing it to:

   The only originally-defined extension field was the one used by
   the AutoKey protocol [RFC5906], and the presence of any
   extension field required a subsequent MAC.  In 2016 a second
   extension field was added, the (experimental) Checksum Complement
   [NTPComp] extension field. [NTPComp-v0]
 (not sure how to properly cite that)
   PROHIBITS the use of a MAC. Again, the AutoKey extension field is
   always followed by a MAC, and Section 10 of [RFC5906] specifies
   the parsing rules that allow a host to distinguish between an
   extension field and a MAC.

That's where I think that paragraph should end.  In particular, I
believe the last sentence:

   However, a MAC is not mandatory after an extension field; an
   NTPv4 packet can include one or more extension fields without
   including a MAC (Section 7.5 of [RFC5905]).

needs to be removed, as it just muddies the waters and lays what I
believe to be inappropriate ground work for points below.

In Section 3, the replacement language includes:

   The Field Type, Value, and Padding fields are specific to the defined
   function and are not elaborated here; the Field Type value is defined
   in an IANA registry and its Length, Value and Padding are defined by
   the document referred to by the registry. If a host receives an
   extension field with an unknown Field Type, the host SHOULD ignore
   the extension field and MAY drop the packet altogether if policy
   requires it.

I'm thinking we want to offer some information about the Field Type, as
we're going to need to provide IANA with documentation on how they
should be allocating future Field Types:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Field Type           |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where Field Type is further described as:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R|E|O|M| Code  | Primary Type  |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and:

 R: Response (used by AutoKey and I-Do)
 E: Error (used by AutoKey)
 O: Subsequent MAC Optional (used by NTPComp, NTS, MAC-EF, ???)
 M: MAC Included (used by NTS, MAC-EF)

Informational: The Code field is currently used by AutoKey, and as a
version field for a soon-to-be-proposed "Extended Information Extension
Field."

The AutoKey specification uses the value '2' as the Primary Type, and
currently reserves types 1 and 3-7 for "future versions of AutoKey".
However "future versions of AutoKey" seem unlikely, and the following
Primary Types have been assigned or requested:

 0x02	AutoKey
 0x03	MAC Extension Field
 0x04	NTS
 0x05	Checksum Complement
 0x06	Suggest REFID
 0x07	I-Do
 0x08	Last Extension/Legacy MAC follows

Now, the new paragraph:

   While the minimum field length containing required fields is four
   words (16 octets), the maximum field length cannot be longer than
   65532 octets due to the maximum size of the length field.

should really be:

   The minimum field length containing required fields is four
   octets.  There is one current instance of this, for a CRYPTO_NAK,
   which is a special case where the value of the Field Type is
   0x0000 and the Length is 0x0000.  The proposed "Last Extension
   Field" is another instance of a four-octet Extension Field.  The
   maximum field length cannot be longer than 65532 octets due to
   the maximum size of the length field.  Note that packets with
   a length that exceeds the MTU will be fragmented and may not
   be properly received.

In the proposed 7.5.1.1 "Extension Fields in the Presence of a MAC" the
first/only paragraph is:

   An extension field can be used in an NTP packet that includes a MAC,
   for example, as defined in [RFC5906]. A specification that defines a
   new extension field MUST specify whether the extension field requires
   a MAC or not. If the extension field requires a MAC, the extension
   field specification MUST define the algorithm to be used to create
   the MAC and the length of the MAC thus created. An extension field
   MAY allow for more than one algorithm to be used in which case the
   information about which one was used MUST be included in the
   extension field itself.

The first sentence is:

   An extension field can be used in an NTP packet that includes a MAC,
   for example, as defined in [RFC5906].

What purpose does it serve?  We've already established stuff around both
EFs and MAC.  I think this sentence should be removed if it provides no
more useful purpose.

As for:

   A specification that defines a new extension field MUST specify
   whether the extension field requires a MAC or not. If the
   extension field requires a MAC, the extension field
   specification MUST define the algorithm to be used to create the
   MAC and the length of the MAC thus created. An extension field
   MAY allow for more than one algorithm to be used in which case the
   information about which one was used MUST be included in the
   extension field itself.

How about:

   The specification of a new extension field MUST specify whether
   or not the presence of this extension field requires a subsequent
   MAC, and whether or not this extension field provides a MAC. It
   does this using the 'O' and 'M' bits in the Field Type, described
   above.

What is the reason for stating:

   If the extension field requires a MAC, the extension field
   specification MUST define the algorithm to be used to create
   the MAC and the length of the MAC thus created. An extension
   field MAY allow for more than one algorithm to be used in which
   case the information about which one was used MUST be included
   in the extension field itself.

Under what circumstances would it be either useful or the responsibility
of an extension field proposal to define allowable MAC algorithms?

Why do we specify >MUST define the algorithm<, which implies that only 1
algorithm would be allowed?  I see that in the next sentence multiple
algorithms are allowed, but the paragraph is confusing as-written.

Why require "... and the length of the MAC this created."?  I imagine
it's *possible* to have less data than is required, and if both sides
agree on how to process this case, while it's arguably a very poor
choice, it is a possibility.  Also, some implementations might choose to
pad the MAC data with extra, probably random padding.  This should be
explicitly allowed.

Finally, "... in which case the information about which one was used
MUST be included in the extension field itself."  Why is this being
stated?  The keyid in the MAC identifies the algorithm used, and if the
MAC-EF proposal is used it already specifies how to handle this case.
We have never had this requirement before.  Saying "too much" here seems
to be an invitation for trouble.

Moving on:

   7.5.1.2 Multiple Extension Fields with a MAC

   If there are multiple extension fields that require a MAC they MUST
   all require use of the same algorithm and MAC length. Extension
   fields that do not require a MAC can be included with extension
   fields that do require a MAC.

Why is that first sentence there?  It has not been established that any
given EF should ever care what algorithm is used for the MAC that
protects it.  If no strong case can be made for this requirement, the
first sentence above should be removed.

   An NTP packet MUST NOT be sent with two or more extension fields that
   require a MAC with different algorithms.

Again, that sentence should be removed if it cannot be established that
any given EF should care what MAC algorithm is used.

   If an NTP packet is received with two or more extension fields that
   this receiver recognizes and those fields require a MAC with
   different algorithms, the packet MUST be discarded.

Same as before - this sentence should be removed if no valid reason can
be given for why an EF should care what algorithms are needed to protect it.

OK, now for:

   7.5.1.3 MAC in the absence of an Extension field

   A MAC MUST NOT be longer than 24 octets if there is no extension
   field present, unless a longer MAC is agreed upon by both client and
   server. The client and server can negotiate this behavior using a
   previous exchange of packets with an extension field which defines
   the size and algorithm of the MAC transmitted in NTP packets.

This is needlessly restrictive and I think it should be removed.  It
creates the appearance of a restriction when none existed before and no
current need has been established.  The keyid in the MAC is enough to
specify what algorithm is used, and if that algorithm is acceptable to
each side and each side has the appropriate key, the MAC will validate.
Otherwise, it won't.

Now for:

   7.5.1.4 Extension Fields in the Absence of a MAC

This is a *legacy* MAC, and with the MAC-EF proposal this should be
clarified.

   If a MAC is not present, one or more extension fields can be inserted
   after the header, according to the following rules:

   o  If the packet includes a single extension field, the length of the
      extension field MUST be at least 7 words, i.e., at least 28
      octets.

This is needlessly restrictive and wasteful.  There is no good reason
for it.  Even without the MAC-EF and Last-EF proposals, a legacy MAC can
be easily disambiguated from an EF.  Several of my proposed new EFs can
be implemented in less than 28 octet EFs.  Requiring the last EF to be
28 octets or longer, especially since a legacy MAC can easily be more
than 24 octets, doesn't really serve any purpose.  The purported reason
for requiring a minimum last EF to be 28 octets or more vanishes.

   o  If the packet includes more than one extension field, the length
      of the last extension field MUST be at least 28 octets. The length
      of the other extension fields in this case MUST be at least 16
      octets each.

What I wrote above.

Also see the MAC-EF and the LAST-EF proposals.

I don't know enough about the statements in 4. "Security Considerations"
to say anything.

So those are the points I wanted to raise and see addressed.

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

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

---

From: Brian Utterback <[email-masked]>
Date: Thu, 5 May 2016 22:30:03 -0400

>     does this using the 'O' and 'M' bits in the Field Type, described

The idea of having the requirement as to whether or not an extension 
field requires a MAC being a bit in the extension field seems broken to 
me.  A man in the middle that intercepts a NTP packet with extension 
fields that require a MAC according to the specification of that field 
is stuck, unable to modify the packet since doing so would invalidate 
the MAC and also unable to calculate a new MAC without knowing the 
shared key between the systems.

If the need for a MAC is carried in a bit in the extension, then all the 
man in the middle attacker needs to do is discard the MAC and clear the 
bit, make whatever other changes are desired and resend the packet.

-- 
Oracle <http://www.oracle.com>
Brian Utterback | Principal Software Engineer
Phone: +1 6038973049 <tel:+1%206038973049>
Oracle Systems/RPE Solaris Network
1 Oracle Dr. | Nashua, NH 03062
------------------------------------------------------------------------
All working systems eventually show their own agendas.
------------------------------------------------------------------------
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 6 May 2016 01:14:44 -0700

> bit, make whatever other changes are desired and resend the packet.

Here's the question: Is that bit informative or controlling?

>From the first instance of extension fields, the presence of an
extension field meant a MAC MUST be provided.

It was certainly required for Autokey, the only defined use of an
extension field for a very long time.

The changes in RFC7822 come, I believe, from Tal's experimental checksum
complement proposal, which, as written, is an extension field that MUST
NOT be followed by a MAC.  As described, it's a perfectly reasonable way
to do things, but it is an exception to the 0-day rule about "If there
is an EF there MUST be a MAC."

The next issue goes to: What to do about EFs we don't understand?

The choices are to either ignore those EFs or drop the packet.

The purpose of these status bits is to give higher-level packet
validation code a hint as to what is expected for this packet.

A MITM attacker can cause no end of problems.

So first we had a base packet, then we added a MAC, and finally we added
an extension field.

We're now to the point where it's useful to put the (legacy) MAC into an
EF, for ease of packet processing.  At that point we'll have an EF that
*includes* a MAC, and the MAC-EF would not *need* to have a subsequent MAC.

There will be old code out there, that won't know what to do with some
of these new EFs.

That's why the I-DO EF can be interesting - if we send a packet with
I-DO and get no response, did we not get that response because it was
lost along the way or dropped because the other side did not understand
the EF.  But if new code is on both sides, the I-DO exchange can tell us
a lot about what we can expect from an association.

Therefore I think we need to be really careful about what is said in
RFC7822.  There's trouble if we say too much, and trouble if we say too
little.

What do you recommend?

---

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 6 May 2016 11:21:57 +0200

> As I've mentioned before, I have some major concerns about this document.

I agree there are some things that could be improved in this draft,
but I'm not sure if the changes you propose are heading in the right
direction.

>    long, 20 octets long, or a 4-octet crypto-NAK.

I think it's exclusionary on purpose as other lengths would break the
detection of extension fields. Longer MACs may be used only if both
sides agree on that, it is a special case described in 7.5.1.3.

>  M: MAC Included (used by NTS, MAC-EF)

I still don't understand what the O and M bits would be useful for. In
the recent "Comments on new drafts" thread this hasn't been answered
yet.

>    The minimum field length containing required fields is four

This would break compatibility with implementations that follow the
old minimum length of 16 from RFC 5905 and it would also break
detection of extension fields vs legacy MACs as two or more extension
fields would fit in 28 octets.

>    There is one current instance of this, for a CRYPTO_NAK,
>    0x0000 and the Length is 0x0000.

This doesn't work. The length would have to be 4 if it should pass as
an extension field (ignoring the requirement on minimum length).

>    does this using the 'O' and 'M' bits in the Field Type, described

I'm sorry for asking this once again, but if the information is in the
specification of the extension field, why does it need to be in the
field type?

> of an extension field proposal to define allowable MAC algorithms?

As I understand it, this is meant for extension fields that implement
authentication (e.g. NTS, Autokey). If they didn't specify how was the
MAC calculated (or this information wasn't transmitted in the
extension field), how would the other side be able to verify it?

> each side and each side has the appropriate key, the MAC will validate.

The problem is when one side is using a wrong key. The MAC could be
interpreted as an extension field. A clean design shouldn't allow
that. When we have an extension field for "transparent clocks",
which would be modified by switches/routers on the network path, they
will have to be able to reliably detect this field in NTP packets, it
can't be a misinterpreted MAC.

> be easily disambiguated from an EF. 

No, it can't. That's the whole point of adding this restriction, to be
able to reliably distinguish between legacy MAC and extension field.
It just describes what ntpd has been doing. Why do you think it doesn't
support longer MACs than SHA-1? This is the main reason why we need the
MAC extension field.

> Several of my proposed new EFs can
> than 24 octets, doesn't really serve any purpose.

I agree it's a waste of bandwidth, but I'm not sure if it can be
improved without breaking compatibility. If we could ignore autokey,
extension fields could be restricted to packets without legacy MACs
and the only requirement could be that all extension fields together
are at least 28 octets.

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 6 May 2016 03:17:35 -0700

> sides agree on that, it is a special case described in 7.5.1.3.

Please show how this breaks anything.

It's easy to detect an EF.  Besides, only 1 EF was ever described.  If
some other implementation has done others, those can also be trivially
handled, even by old code, if they follow the spec.

It's easy to see if remaining data is a MAC, based on the keyID field
and the length of the remaining data.

So where is the problem here?

> the recent "Comments on new drafts" thread this hasn't been answered

Please see all of the other EF proposals.

I don't personally see the value in duplicating that information in this
RFC, but if that's really useful, long-term, we can certainly add it in.

> fields would fit in 28 octets.

What old minimum length of 16?  What about the CRYPTO-NAK?

I disagree on your point about detecting one or more EFs v. a legacy
MAC.  I think I've even written about this pretty clearly, covering all
of the conditions.

Please give me a concrete example of old or new code where this would be
a problem.

> an extension field (ignoring the requirement on minimum length).

It already works, and it should continue working as-is.
Backward-compatibility.

A CRYPTO_NAK is a single 32-bit word of all zeroes.

> specification of the extension field, why does it need to be in the

Because, as I've said before:

- for the last very long time the presence of an EF meant a
  subsequent MAC was REQUIRED.

- we now have a case where there is a new EF (granted, it's
  experimental) that FORBIDS a subsequent MAC.

- old code will do whatever old code will do.

- now that we're adding more EFs, even new code may sometime
  get EFs it doesn't understand.  Who can say what some implementations
  will or won't implement here?  Therefore, content hints are more (or
  at least as) useful than *no* content hints.

So to directly answer your last question, if you get an EF that you
don't understand, how can you tell anything about the content and
expectations of that EF?

> extension field), how would the other side be able to verify it?

That information is either opaque or presented out-of-band.

For legacy MACs, if each side is able to validate the MAC then each side
either has a symmetric key ID, or it has an autokey session key with a
previously-negotiated algorithm.

We've never had the requirement to specify an algorithm before,
requiring it now will be backward-incompatible.

There are also folks who are are opposed to "information leakage".

There is no demonstrated benefit to this new requirement.

There is demonstrated cost to this new requirement.

Let's get rid of it.

> can't be a misinterpreted MAC.

Doubtful.  Please show a concrete example.

It's pretty easy to decide if the data is a valid EF or not.  We an even
look-ahead to help with this.

We can also test to see if data is a MAC or not.

We don't have a transparent clock EF yet.  And when we do it will be
easy to address this - I already suggested changes to the checksum
complement proposal to allow for this.

As for in-path modification, it's pretty easy for new code to use a
packet that has NTP...EF-MAC followed by EF-MAC-OPTIONAL-TC fields.

Is there a problem I'm missing?

> support longer MACs than SHA-1? This is the main reason why we need the

Obviously I disagree with your position.

I even disagreed with it before we had the EF-MAC and LAST-EF proposals.
 With EF-MAC and LAST-EF, your concern is a non-issue, right?

Please show me a concrete example.  I'm comfortable with the analysis
I've done on this to have suggested it.  There's a chance I've missed
something.

> and the only requirement could be that all extension fields together

Autokey should no longer be used.  We've known this for at least 3
years' time now.  But even so:

- autokey requires a subsequent MAC - legacy or EF
- old packets will continue to work
- it's easy to disambiguate an EF from a legacy MAC
- with the new EF stuff, it's trivial to make this easy
- it's possible to configure things badly

---

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 6 May 2016 13:54:22 +0200

> and the length of the remaining data.

I don't think it is. A key ID of a MAC may look like a valid header of
an extension field.

For example, an MD5 MAC (20 octets) after an autokey extension field
may have key ID of 0x02020014, which would be a valid header of an
extension field matching the length of the MAC. If the specification
didn't require the last extension field in packets without MAC to be
at least 28 octets long, the parser wouldn't know if it is a MAC or
extension field.

> Please see all of the other EF proposals.

I've read and commented on them in the "Comments on new drafts"
thread. I asked for an example which would show how would the
implementation use these bits, no one was given.

> What old minimum length of 16?  What about the CRYPTO-NAK?

RFC 5905 said "the minimum field length containing required fields is
four words (16 octets)".

Crypto-NAK is not an extension field.

> MAC.  I think I've even written about this pretty clearly, covering all

I'd suggest you to try to implement support for longer MACs than SHA-1
in ntpd without breaking autokey, you would quickly see where the
problem is.

> It already works, and it should continue working as-is.

crypto-NAKs are not extension fields and need special care. To allow
unambiquous parsing RFC 7822 may need to restrict their use to
packets without extension fields.

> don't understand, how can you tell anything about the content and

Without its specification I can't. I will either ignore that EF or
drop the packet completely. I don't see how would the O or M bit in
the field type change my decision. That's what I asked before.

> Doubtful.  Please show a concrete example.

Ok, here is another example. Let's assume the "transparent clock"
extension field uses type 0x1234 and is 28 octets long, i.e. the
header of the extension field is 0x1234001c. A client which doesn't
know about this extension field is using a new authentication
mechanism and sends a packet with MAC that is 28 octets long and has
key ID 0x1234001c. The switch sees the magic word, modifies the
packet and the packet fails the authentication check on the server.

---

From: Harlan Stenn <[email-masked]>
Date: Sat, 7 May 2016 03:01:00 -0700

> at least 28 octets long, the parser wouldn't know if it is a MAC or

Yes, but...

Autokey extention fields are single EFs.  If we parse an autokey EF,
additional autokey EFs are prohibited.

But if we want to allow non-autokey EFs, that should still be OK.

Next, this 2nd autokey EF is too short to be a "group name" packet, I
believe - 0x0202.... meaning Autokey, CRYPTO_CONF_IDENT.

Next, if that packet *was* valid, it would require a following MAC and
there isn't one.

Next, even if the first few bytes were 0x22020014, meaning: Autokey,
CRYPTO_CONF_IDENT, MAC not required, the code that actually parses
autokey stuff already knows that autokey requires a MAC, so this cannot
be a valid autokey EF.

> implementation use these bits, no one was given.

Are you saying you want that description in this document, or are you
saying you didn't find the information in the other drafts I've proposed?

> Crypto-NAK is not an extension field.

True.  But it's cleaner to say "EF" than it is to write and document "EF
or CRYPTO-NAK".

The "special case" I documented seems to me to be the least confusing
option here.

Do you disagree?

> in ntpd without breaking autokey, you would quickly see where the

I thought we have long had support for longer MACs.

Please say more, because relying on 28 bytes won't help if somebody
relies on that and starts seeing 256-bit digests after the MAC header.

> packets without extension fields.

Crypto-NAK was specifically added for Autokey, which is an EF.  March of
2005.

Do you disagree?

> the field type change my decision. That's what I asked before.

Sometimes we know things and are unable to use that knowledge in the
current "location".

For the MAC-OPTIONAL bit, that can be used in both the lower-level EF
processing code (if this bit is set for an Autokey packet, that's
immediate grounds to disbelieve the packet) or in higher-level code (see
the experimental checksum complement proposal).

> packet and the packet fails the authentication check on the server. 

By my read, 0x1 means MAC INCLUDED, but assuming you are intending it to
mean MAC OPTIONAL I'll proceed.  No idea why you'd want a 'code' of
0x.2.. there but that's probably not important, and I'm assuming 0x0034
is the field type.

For 0x1234001c to be a MAC, that means it's an autokey session key, as
it's greater than 65535.  The rest of the data would have to be a valid
hash for this to be considered a valid MAC.

If there is no MAC and the EF is really a transparent clock EF, then the
proper thing to do would be to have the base packet, the TC-EF, and a
LAST-EF (with both of these EFs specifying "MAC OPTIONAL").  Where is
the problem?

If there are still issues, then the sender should have started with an
I-DO EF and learned if the client can accept the TC-EF before sending
it.  If this didn't happen, then yeah, there is a configuration problem
here, and it's one we can't address at this level.

So I'll ask about that now.  How would some MITM device that acts like a
transparent clock know if it's safe to add TC-EFs to NTP packets?  I
submit this is something that we may not be able to address in NTPv4.

But if we were really interested in that, I suspect the answer would be
"Do not add TC-EFs to packets that use a legacy MAC", and we can solve
much of the problem that way.

---

From: Brian Utterback <[email-masked]>
Date: Sat, 7 May 2016 10:16:05 -0400

> Here's the question: Is that bit informative or controlling?

If an extension field says in the spec that a MAC is optional, then it 
is controlling. If an extension field says in the spec that a MAC is 
required, then it is informative, *but* either an implementation knows 
that a particular field required a MAC, in which case the bit is 
useless, or it does not and then the bit is a security hole. So, it is a 
security hole for fields where a MAC is optional or if the 
implementation doesn't know what the spec for the field says or doesn't 
enforce it and if it does know and enforce the spec the bit is useless.

---

From: Harlan Stenn <[email-masked]>
Date: Sat, 7 May 2016 09:31:02 -0700

If MACs have always been required if there is an EF and now there are EFs where that is not the case, and if the recipient does not recognize an EF and it gets a packet with an unknown EF and no MAC, how can the receiver know it it should drop the entire packet because the required MAC was missing, or it should just ignore the EF because for that EF no MAC is required?

Sent from my iPhone - please excuse brevity and typos

> On May 7, 2016, at 7:16 AM, Brian Utterback <[email-masked]> wrote:
> 
> If an extension field says in the spec that a MAC is optional, then it is controlling. If an extension field says in the spec that a MAC is required, then it is informative, *but* either an implementation knows that a particular field required a MAC, in which case the bit is useless, or it does not and then the bit is a security hole. So, it is a security hole for fields where a MAC is optional or if the implementation doesn't know what the spec for the field says or doesn't enforce it and if it does know and enforce the spec the bit is useless.
> 
> -- 
>   
> Phone: +1 6038973049 
>   Oracle is committed to developing practices and products that help protect the environment

---

From: brian utterback <[email-masked]>
Date: Sat, 7 May 2016 13:38:00 -0400

That is a policy decision. That presents a question. Should EF data be
allowed to change the interpretation of the standard NTP data? If the
answer is no and the standard portion always contains the same data it
would have contained before the addition of EFs and MACS, then you
should process or drop the packet according to the same rules you would
have applied to the packet if the unknown EF hadn't been there at all.
However if we allow an EF to change the data in the standard data
portion, then an unknown EF suggests that we should always drop the
packet since the data may be tainted. This has relevance to the leap
smear, I think.

To elaborate, if we always say that the standard NTP data always
contains our best estimate of the correct absolute time at this moment,
then it is safe to use the data even if the MAC is missing if we would
have used the data if the MAC were missing and the EF had not been
there. BUT, if we we allow the NTP data to reflect the current system
presentation time and then include a EF that says what the correction is
to get the correct absolute time, then using the NTP data when there is
an unknown field is not safe.

On 5/7/2016 12:31 PM, Harlan Stenn wrote:
> If MACs have always been required if there is an EF and now there are
> EFs where that is not the case, and if the recipient does not
> recognize an EF and it gets a packet with an unknown EF and no MAC,
> how can the receiver know it it should drop the entire packet because
> the required MAC was missing, or it should just ignore the EF because
> for that EF no MAC is required?
>
> On May 7, 2016, at 7:16 AM, Brian Utterback
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>> If an extension field says in the spec that a MAC is optional, then
>> it is controlling. If an extension field says in the spec that a MAC
>> is required, then it is informative, *but* either an implementation
>> knows that a particular field required a MAC, in which case the bit
>> is useless, or it does not and then the bit is a security hole. So,
>> it is a security hole for fields where a MAC is optional or if the
>> implementation doesn't know what the spec for the field says or
>> doesn't enforce it and if it does know and enforce the spec the bit
>> is useless.
>>
>> -- 
>> Green Oracle <http://www.oracle.com/commitment> Oracle is committed
>> to developing practices and products that help protect the environment

All working systems eventually start to exhibit their own agenda

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 9 May 2016 11:58:37 +0200

> additional autokey EFs are prohibited.

Are they? I didn't see such restriction in RFC 5905 or 5906. Even if
they were, the parser shouldn't (and at least in ntpd it doesn't) know
that.

> Next, if that packet *was* valid, it would require a following MAC and

Autokey would require a MAC, but not NTP. The parser needs to be able to
identify extension fields in NTP packets, even if the implementation
doesn't understand the individual extension fields.

> saying you didn't find the information in the other drafts I've proposed?

For now, I'd like to understand the purpose of the bits. One clear
example of an NTP packet which has them and how the implementation
works with them would help a lot. From the other mails in this thread
it looks like I'm not alone who has troubles with it.

> True.  But it's cleaner to say "EF" than it is to write and document "EF

I don't follow here.

> I thought we have long had support for longer MACs.

No, we need the MAC extension field first to implement it cleanly. See
the ntp bug #2039.

> Crypto-NAK was specifically added for Autokey, which is an EF.  March of

No. I'm just saying crypto-NAK is not an extension field and can't be
parsed as such. It's a special "short" MAC.

> 0x.2.. there but that's probably not important, and I'm assuming 0x0034

0x1234 is just an example of an unallocated field type, don't try to
interpret the bits.

> hash for this to be considered a valid MAC.

Ok, but the device doesn't have the key and can't (and shouldn't) know
if it's a valid MAC.

> submit this is something that we may not be able to address in NTPv4.

It wouldn't add a new field to the packet. The packets sent by the
client or server would already have it and the devices on the network
path would be allowed to modify it. But they would need to be able to
reliably identify the field, without knowing anything about other (old
and new) extension fields.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 9 May 2016 12:44:41 -0700

> they were, the parser shouldn't (and at least in ntpd it doesn't) know

Yes.  Autokey EFs are a *single* EF in an NTP packet, and there have
*never* been cases where the reference implementation has used multiple
EFs before.  Is anybody aware of a separate implementation of Autokey
that uses multiple EFs?  If so, they have never used it to connect with
the reference implementation.

And who cares if the parser knows it or not.  As I've been saying,
sometimes we get information in one place and use it in another.

Let's not create problems where none have been before.

Autokey is going to be deprecated unless somebody comes up with an
upgraded spec.  Nobody I know has any plans to do this.  Why are we
spending effort thinking about autokey?

> Autokey would require a MAC, but not NTP.

Yes.

> The parser needs to be able to

Yes.  That's been my point.

> it looks like I'm not alone who has troubles with it.

Look at the I-DO proposal.  Look at the MAC-EF proposal.  Look at the
Checksum Complement spec.  We already know that Autokey requires MAC
protection.  How that MAC is provided *has been* legacy MAC, but I see
no language that would prohibit an Autokey-EF from using a MAC-EF.

>> True.  But it's cleaner to say "EF" than it is to write and document "EF

Somewhere, I recommended a change to the IANA document for extension
fields where we reserve a Field Type of 0x0000 as a Crypto-NAK and
specifically state that as an exception, the Field Length for the
Crypto-NAK EF be 0x0000.

I'm not seeing that offhand right now.

> No, we need the MAC extension field first to implement it cleanly. See

OK, I haven't dug in to that in a long time.  My understanding (and I
could well be wrong) was that we allowed longer MAC digests and the code
just handled it.  I still think we can address this as a bug, and not a
required limit that must be expressly handled elsewhere.

> parsed as such. It's a special "short" MAC.

I'll look for my proposal to EFs and IANA recommendation that
categorizes 0x0000 0x0000 as an explicit Crypto-NAK that is listed as an EF.

Is there a good reason this should not be done?

> 0x1234 is just an example of an unallocated field type, don't try to

But the whole point is "what would somebody do with an unrecognized
Field Type?"

You may not know the 2nd nybble (the) or the bottom octet, but there is
information (which I think is advisory in all cases) in the first nybble.

> Ok, but the device doesn't have the key and can't (and shouldn't) know

If it doesn't have the key it *cant* be a authenticated MAC.  It can
still be a MAC.  It could even be a valid MAC, but unless each side can
check, that (potentially valid) MAC cannot be authenticated, and until
it's authenticated it's not valid.

So that means the implementation is free to *also* ask: "Can this data
be a valid EF?".

> and new) extension fields.

If it's not adding a new field to the packet how is it doing the TC
adjustment?

How would the client ever be able to tell if the resulting packet is
trustworthy?

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 10 May 2016 09:17:41 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 09.05.2016 um 21:44 in Nachricht
<[email-masked]>:

[...]
> spending effort thinking about autokey?
[...]

Because you (the NTP guys) let the beast escape to the wild. Once released you cannot deny its existence.

BEFORE you want to kill it, you need a substitute. NOT the other way 'round.

Ulrich

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 10 May 2016 09:21:17 +0200

On Mon, May 09, 2016 at 12:44:41PM -0700, Harlan Stenn wrote:
> EFs before.

Isn't that because until very recently there were no other extension
fields than those used by autokey? Now you are proposing new fields
and we want the old implementations to be able to parse them, right?

So far, all specified extension fields were at least 28 octets long
and MACs were not longer than 24 octets. Parsing NTP packets like that
was easy. If the remaining part of the packet is >= 28 octets, it's an
extension field. If it's shorter, it's a MAC. That's how it's
implemented in ntpd.

Now, in order to not waste bandwidth with new extension fields, we
would like to be able to specify extension fields shorter than 28
octets. But we don't want old ntpd to reject packets with them as
having invalid format, right? That's one of the reasons why RFC 7822
was written. It allows extension fields that are shorter than 28
octets, down to 16 octets, as long as they are not the last extension
field in a packet without MAC. This works with the ntpd parsing code.

I think we could allow even shorter extension fields if we put them
inside a longer extension field. I proposed a packing extension field
in my other mail yesterday.

> sometimes we get information in one place and use it in another.

I'm not sure which implementation assumes there is only one autokey
extension field when parsing an NTP packet, but it's not ntpd.

> Let's not create problems where none have been before.

Ok, then stop proposing changes that will break things. Please, look
at the ntpd code and think how it would process packets not following
the restrictions in RFC 7822 you want to remove.

> Is there a good reason this should not be done?

Is there a good reason it should?

> But the whole point is "what would somebody do with an unrecognized

Yes, and my question was how the bits will change my decision. I can
skip the unknown extension field or drop the packet completely. How
does a bit in the field type help me?

> If it's not adding a new field to the packet how is it doing the TC

It would just increment a field in the packet by its transit time. See
[1] for a correction field I proposed for the complement extension
field.

> How would the client ever be able to tell if the resulting packet is

The data in the packet (except the TC field) could still be
authenticated. The TC correction would be accepted only if it was
sane, e.g. smaller than maximum asymmetry in the measured delay.

[1] http://lists.ntp.org/pipermail/ntpwg/2015-August/002335.html

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 10 May 2016 00:22:36 -0700

Rely on autokey's protection at your own risk, Ulrich.

Autokey was doing fine until Moore's law caught up with it.

H
--

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 10 May 2016 00:53:50 -0700

> and we want the old implementations to be able to parse them, right?

1) nobody has implemented these new EFs yet.

2) As far as autokey goes, there will be at most one autokey EF in a
packet.  There may be more EFs, eventually.

3) If A sends an EF to B and B does not respond, it's up to A to decide
to either keep trying or decide B can't handle this new EF.  This is
another reason I came up with the I-DO EF proposal.

It's not that difficult to figure out if the ntp instance on the "far
side" can handle these or not.

> extension field. If it's shorter, it's a MAC. That's how it's

You may be right.  I submit it doesn't matter.

Old code will do whatever it does.

We can test for this easily.

How is what you describe a real problem?

It's really easy to detect if there are any EFs before a legacy MAC.

If old code cannot do this, then folks can do some combination of:

- don't send new EFs to old instances
- upgrade old instances

Where will any of this not work?

> field in a packet without MAC. This works with the ntpd parsing code.

RFC 7822 imposes bogus restrictions and needlessly complicates things.

IMO.  As a very long-time implementor.

Again, it's easy to start an NTP exchange with an I-DO EF and see if a
response comes back.  That could be:

- a normal NTP packet, which means the sender should infer that the
receiver does not understand any new EFs

- a normal packet with an I-DO-RESPONSE, which describes what the
receiver understands

Again, if no response is seen, then either the packet was lost or the
receiver dropped the packet, likely because it didn't understand I-DO.

The sender is free to continue normally, and if the association actually
comes up and runs, there's nothing stopping either side from trying
another I-DO exchange later.

I'm still not seeing any problem here.

> in my other mail yesterday.

Why bother?  To protect old code?  In that case it's better to just not
send EFs that are not understood.

> extension field when parsing an NTP packet, but it's not ntpd.

Maybe I don't understand.  I am pretty confident that ntpd will only put
at most 1 autokey EF into an NTP packet.

> the restrictions in RFC 7822 you want to remove.

I'm very comfortable with the changes I've proposed.  I'm comfortable
that these changes will work with old versions of (x)ntpd.  I'm
surprised you would think otherwise.

I'm very comfortable that if ntpd tries to talk to any of these other
unidentified implementations that the protocol will work, too.

> Is there a good reason it should?

I'm close to giving up on you.

> does a bit in the field type help me?

"Some" information is better than "no" information.  If you don't want
to pay attention to it, feel free to ignore it.  Why should you have the
authority to limit what others choose to do?

The "MAC OPTIONAL" bit is needed because of the new experimental
checksum complement proposal, because since the beginning of EFs, the
presence of an EF meant a MAC was REQUIRED.

RFC7822 is just trying to rewrite history.  No, thank you.

> [1] http://lists.ntp.org/pipermail/ntpwg/2015-August/002335.html

Got bounds on that asymmetry?  Sure looks like an easily exploitable
situation to me, certainly more exploitable than many of the recent
security bugs we've addressed.

You've said nothing that even begins to convince me that you are raising
useful points here.  You might feel the same about what I've said.

I'm ready to agree to disagree with you.
-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 11 May 2016 14:14:04 +0200

> side" can handle these or not.

Ok, it's starting to make sense to me now. You seem to be saying it's
acceptable to send old implementations packets in a format which they
don't understand. The server drops the packet and the client can try
the older format after several missed replies. Do I understand it
correctly?

> send EFs that are not understood.

Yes, I assumed there was an interest in making only backward
compatible changes in the same version of the protocol. An old server
can ignore an unknown extension field and reply to the client, which
will immediatelly know the server doesn't support the extension field.

If the server drops the packet due to invalid format, the client has
to guess if the server really dropped it (for whatever reason) or the
packet was just lost in the network, or its network connection is not
up yet. This will be slower and less reliable. The I-Do specification
will help with new extension fields, but the client will still need to
detect if the server supports I-Do.

Anyway, I think it would be cleaner if the specification didn't
require the implementation to look at the field type/key ID in order
to distinguish extension fields from a MAC, i.e. avoid rules like if
the packet has at least one autokey field, it must have a MAC, or if
the key ID is < 65536, it's not an extension field.

> security bugs we've addressed.

Half of the measured delay is the upper bound. There could be also a
configurable limit for the correction. A MITM attacker can create a
larger error in the measurement simply by delaying the request or
response, there is no need to modify anything in the packet.

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 11 May 2016 14:21:22 -0700

> the older format after several missed replies. Do I understand it

I would not say it's an unknown format, as the spec for EFs has allowed
multiple EFs since its inception.  The only use of EFs that I'm aware of
was for the reference implementation, and in that case we only expected
to see a single EF and in every case where there was an EF, a (legacy)
MAC MUST be provided.

NTPv3 and NTPv4  allow a base packet, or a base packet and a (legacy) MAC.

> compatible changes in the same version of the protocol.

I'm still not seeing how the proposed new stuff is backward incompatible.

> An old server
> will immediately know the server doesn't support the extension field.

Yes.  And a new server can also see if the "other side" responds to the
most basic packet format.

A new server may also decide to send a fresh I-DO packet once a day,
just to see if anything has changed.

> detect if the server supports I-Do.

Yes.  And as I mentioned above, we can send I-DO refreshes from time to
time.

There are other reasons to do an I-DO refresh as well.  Using NTS as an
example, the initial volley might indicate one or both sides support
I-DO, NTS, and maybe some other things.  If both sides support I-DO and
NTS, then after authentication has been done that may authorize one or
both sides to perform additional operations, and in that case the I-DO
dance should be able to convey these now-authorized operations.

> the key ID is < 65536, it's not an extension field.

It's more than looking at the field type.  The field length is important
too.

If the field length is longer than the remaining data, this CANNOT be an
EF.  If it is exactly the remaining data, this MAY (and probably is) an
EF.  If it's less than the remaining data, then we have the option to
look-ahead and see if the remaining data has the valid structure of an
EF or a legacy MAC.

> response, there is no need to modify anything in the packet.

If it was me I'd need to feel a lot more comfortable before I started
trusting unauthenticated TC data then.

I'd be much happier with either:

BASE-PKT,OPT-EF,MAC-EF,NET-TC-EF,MAC-EF

or

BASE-PKT,OPT-EF,MAC-EF,{TC-EF,MAC-EF}+

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 12 May 2016 10:13:22 +0200

> to see a single EF and in every case where there was an EF, a (legacy)

The spec allowed multiple extension fields, but it also said the
minimum length is 16 octets. chrony follows that. If you send it a
packet with an I-Do field that has 8 or 12 octets, it will discard it
and the client won't get any reply.

ntpd seems to reply with a crypto-NAK. I'm not sure if it's
intentional, but in this case it could be helpful.

openntpd as an example of SNTPv4 implementation seems to reply only to
packets that have either 48 or 68 octets. There is no support for
extension fields.

Clients will always have to be able to deal with servers that don't
understand any extension fields, but I thought it would be nice if it
at least worked with implementations that tried to follow the RFC.

> It's more than looking at the field type.  The field length is important

The question is if the length alone is sufficient. I think it would be
nice if it was.

> EF.

Right.

> If it is exactly the remaining data, this MAY (and probably is) an
> EF.

Yes, most likely it is an EF, but it may also be a legacy MAC using a
symmetric key or autokey and we can't reliably tell that. I think any
sane specification would want to avoid this ambiguity.

> If it's less than the remaining data, then we have the option to

Yes, but this can't be 100% reliable. If we allow 4-octet extension
fields anywhere in the packet, a 20-octet legacy MAC could be
interpreted as 5 valid extension fields. I think we should try to
prevent that.

> trusting unauthenticated TC data then.

Sure, that's your local policy. The idea is to provide something
similar to PTP, which is never or very rarely authenticated.
Unauthenticated NTP is still more secure than unauthenticated PTP.

> BASE-PKT,OPT-EF,MAC-EF,{TC-EF,MAC-EF}+

That could work. For the basic use case I don't think it's necessary.

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 12 May 2016 01:56:13 -0700

> and the client won't get any reply.

And we can certainly note this, and use it as part of the "probing"
process.  This would pretty much handle old code.

If you are going to update chrony to handle the new formats, would the
new chrony code be able to handle the new spec?

> packets that have either 48 or 68 octets. There is no support for

There are 2 points there.  The first is that openntpd as it stands does
not handle EFs.  That's fine, and if they choose to add that capability
and the Standard is properly described, it's their choice what to do
about it.

> at least worked with implementations that tried to follow the RFC.

I think I'm missing your point here.

The "initiator" has a lot of control here.  If it sends something the
recipient doesn't handle, then there will either be no response or a
"basic" response.  Where is the problem in this case?  If we're talking
about a broadcast server, then it could, for example, send I-DO once
every 10 packets (just to pick a configurable number).  New or restarted
clients could see this, or we just go the other way, and when a
broadcast client decides to do a volley with the server, it could send
the I-DO at that time.  I'm also not sure how useful this would be, as
I'm not yet seeing any cases where a broadcast server would want to send
EFs itself.

> The question is if the length alone is sufficient. I think it would be

One can try.  No harm in that.  But we can get some real useful
information from the Field Type.

> sane specification would want to avoid this ambiguity.

We know more based on the key ID.  If it's <65535 it would have to be a
symmetric key.  For it to be valid we'd have to have that key ID in our
list.  If it's greater than 65535 it would be an autokey session key,
and we'll know whether or not the data might be a valid MAC.

> interpreted as 5 valid extension fields. I think we should try to

There's nothing stopping any implementation from trying all the
combinations, and keeping track of which ones make sense and which ones
do not.

I'm real curious about how some of these things might happen.  We can
expect new code to use MAC-EF instead of legacy MAC.  We can expect a
wodge of short EFs at the end of a packet to either have a MAC-EF or
make sure that all of these short EFs had the MAC-OPTIONAL bit set, and
we could also recommend that these packets end with a LAST-EF packet.

This should get lots easier if new code no longer uses only a legacy MAC
at the end.

And I'd like to see some examples here.

There's also nothing stopping the LAST-EF or perhaps some other EF types
from padding their last field if that turns out to be useful.

> Unauthenticated NTP is still more secure than unauthenticated PTP.

I'm not so sure about that.  NTP is designed for WAN/LAN use.  PTP was
designed for use on a bus, and its scope has grown to the LAN.  While
PTP over WAN studies have been done, I believe there would have to be
some equipment upgrades for the PTP signals to generally propagate over
WANs.

> That could work. For the basic use case I don't think it's necessary.

I may have lost context.  Are you saying you're likely going to be happy
with NTP TC things in switches that only work on unauthenticated
packets, and either update the actual timestamps and use the checksum
complement EF, or they append/update a TC-EF after everything else?

Note that in this last case, one CANNOT use a legacy MAC, one would have
to use a MAC-EF.

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 12 May 2016 12:15:08 +0200

> process.  This would pretty much handle old code.

Ok, if the first I-Do was always at least 16 (or maybe rather 28?)
octets, that could work.

> new chrony code be able to handle the new spec?

New code, sure, but I'm concerned about old code.

> "basic" response.  Where is the problem in this case? 

The problem is that no response doesn't necessarily mean the server
doesn't support the format. Maybe the packet was lost. Maybe rate
limiting is active. This adds uncertainty.

> and we'll know whether or not the data might be a valid MAC.

Yes, an NTP server that knows the symmetric keys or the private autokey
value could do that. But the switch which is supposed to update the TC
field, or a general tool working with NTP packets like tcpdump or
wireshark can't.

The server could still misinterpret a MAC when the keys change (e.g.
on autokey refresh). An old client using autokey could get a reply it
doesn't understand. Of course, it should be robust enough to handle
that and recover, but I think a sane protocol shouldn't allow that to
happen in the first place.

> combinations, and keeping track of which ones make sense and which ones

The server can't always know what the client meant. It could be a MAC
using an old/misconfigured key. If it looks like an I-Do and the
server responds with an I-Do, the client may get a reply it doesn't
understand.

> we could also recommend that these packets end with a LAST-EF packet.

I'm not sure if recommendations are good enough. I think the
specification needs be so strict that no ambiguities in the parsing of
NTP packets are allowed and the parser should use only information
that is contained in the packet (i.e. no access to keys or any state).

I think the current RFC 7822 does that with the exception of
crypto-NAKs (they should be restricted to packets with no extension
fields). The packing and padding extension fields I proposed would
allow specification of shorter extension fields.

If you remove the restrictions on lengths completely, I'm not sure how
it can work.

> complement EF, or they append/update a TC-EF after everything else?

I'd be happy if switches could update a TC field in packets that don't
have legacy MACs. Before that is implemented, the specification of the
format needs to allow reliable identification of the TC field without
access to any keys, it must not be a random MAC that happens to look
like the TC field.

Right.

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 12 May 2016 13:17:40 -0700

> New code, sure, but I'm concerned about old code.

Yes, see below.

> limiting is active. This adds uncertainty.

Yes, so as a matter of policy we try once, and we either send "basic" or
"EF" stuff based on the response.  If reach goes to 0 we start over.
Once a day (or so) we re-probe.

Is there a problem with this approach?

> field, or a general tool working with NTP packets like tcpdump or

Then the base packet might need to contain an "ALLOW_TC" indication that
the switch can see, and if that isn't set then the switch should not add
TC-EFs.

Speaking of which, do you have a TC-EF proposal I could look at?

> happen in the first place.

I wouldn't worry too much about autokey as it's currently implemented,
as we have every intention of deprecating that soon.

> server responds with an I-Do, the client may get a reply it doesn't

If a MAC decodes as bad then either it's a bad MAC or it was never a MAC
to begin with.

We can also decode the EFs.

There will be various combinations of good/bad results here.

If all the possibilities are bad then we have a bad packet.  Log it.

If only one possibility is good, it's *probably* best to decide that's
what was intended.

If multiple choices are good, then we have more choices.  But in this
case the bottom line seems to be "we can get time from the packet" and
that may be the best we can do.  We should log this case too.

> that is contained in the packet (i.e. no access to keys or any state).

How is that a good thing?  At some point if we have a MAC we're going to
see if the hash is valid.  We check timestamps and poll intervals for
sanity.  Why should we bury our head in the sand when validating EFs and
MACs?

There's a steering wheel in a car.  We expect most folks will use it to
keep their car on the road.

If somebody wants to ignore the road, that's their choice.

If the GPS map application says you're driving along side a river and
there's a bridge across it "here", are you just going to turn onto it or
are you going to look to see if it's really there?

> If you remove the restrictions on lengths completely, I'm not sure how

It works like it has always worked.  My recommendations bring things in
line with what I've seen in practice and in "intent".

The language in RFC 7822 goes way too far, which is confusing in some
cases and wrong in others.

If you think my changes go too far the other way, let's examine it.

And remember, when all is said and done we need to have things work and
interoperate.

> access to any keys, it must not be a random MAC that happens to look

I don't think so - all that's needed is a way to identify that a packet
will allow a TC-EF to be appended.  I think I have a solution for that.

---

From: Danny Mayer <[email-masked]>
Date: Thu, 12 May 2016 22:48:28 -0400

> packets that have either 48 or 68 octets. There is no support for

It looks like it's not conformant to RFC5905 for extension fields and
only supports MD5 MAC's which is conformant since RFC5905 only mentions
MD5. It would then fail with any other hashing scheme.

Danny

---

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 13 May 2016 11:05:00 +0200

> the switch can see, and if that isn't set then the switch should not add

I'm curious to see where in the base packet you want to store that
information.

In any case, I think it should rather be updating an existing EF in
the packet than adding a new one. We probably don't want the packet to
grow as it travels through the network as that may create an asymmetry
in the network delay which would be difficult to correct. The TC field
is supposed to improve accuracy.

> Speaking of which, do you have a TC-EF proposal I could look at?

The idea is explained in the mail I referred to earlier. If there is
an agreement it makes sense and ideally at least one vendor interested
in implementing that, I can try to propose it as an RFC draft. 

> that may be the best we can do.  We should log this case too.

Yes, you said that several times already. I agree it could work most
of the time, but I don't think implementations should be expected to
do that. I'm wondering if this would be the first RFC intentionally
using an approach based on probability.

> sanity.  Why should we bury our head in the sand when validating EFs and

Validation and guessing shouldn't be involved in parsing. That's not
how sane specifications are written. The four timestamp fields are not
in some random order and we don't have to guess which one is which, do
we? 

I don't think I can explain it any better. We are going in circles
here and it's very frustrating. Maybe someone else will have better
luck.

---

From: brian utterback <[email-masked]>
Date: Tue, 17 May 2016 18:23:50 -0400

> to see a single EF and in every case where there was an EF, a (legacy)

Sorry this is late. This turns out not to be the case. The reference
implementation can handle any number of EFs on the receive side and may
transmit zero, one or two EFs on the send side. All autokey of course
since as far as it is concerned autokey is the only type. The reason
that the code allows for two EFs is that the autokey protocol volleys
back and forth with requests, but the packet also contains the response
EF for the request it got from the last packet received. The autokey
protocol allows for any number of responses but only one request, but I
think the reference implementation only ever sends a single response in
the packet in addition to the new request.

I think maybe our best bet is to rev the autokey protocol (if we want to
retain it at all, that is) and then say that a legacy MAC MUST be 24
bytes or less and may only be used with no EFs at all, or if one or more
EFs are present they MUST be only the current autokey EFs, in which case
a legacy MAC must be present. All other EFs, if they require a MAC, MUST
use the new MAC extension and a legacy MAC MUST NOT be present. That
leaves us with only a single problem, if any EF other than the autokey
EFs are in a packet, the total length of all the EFs in the packet MUST
NOT be less than 25 bytes. We would have to use something like the LAST
EF to pad it out. Not necessarily as is but we need some way to pad the
EF. I don't think it would be wise to demand that all new EFs be able to
handle an arbitrarily long set of padding to accommodate the
requirement, but perhaps that wouldn't be bad.

I believe that this scheme is sufficiently backwards compatible to
accomodate existing software and solves the problem of parsing the EFs
going forward. And the requirement for the autokey and legacy mac stuff
can go away when we rev to version 5.

With this scheme, if the total extensions length is 24 bytes or less it
is a legacy MAC. If it is longer than that, look at the first field and
see if it is an autokey EF. If it is autokey, traverse the chain until
there is 24 bytes or less remaining, which will be a legacy MAC. Check
that all EFs are only autokey EFs. If there are any other types of EF,
ignore all EFs and MAC and process normally or drop the packet. If the
first extension is not autokey, then traverse the chain and verify that
none are autokey and that the chain ends with no residual. If that is
not the case, ignore the EFs or drop the packet. Otherwise process the
EFs normally.

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 18 May 2016 21:44:26 -0700

On 5/17/16 3:23 PM, brian utterback wrote:
>> I would not say it's an unknown format, as the spec for EFs has
>> allowed multiple EFs since its inception.  The only use of EFs that
>> I'm aware of was for the reference implementation, and in that case
>> we only expected to see a single EF and in every case where there
>> was an EF, a (legacy) MAC MUST be provided.
> 
>  implementation can handle any number of EFs on the receive side and
> may transmit zero, one or two EFs on the send side. All autokey of
> course since as far as it is concerned autokey is the only type. The
> reason that the code allows for two EFs is that the autokey protocol
> volleys back and forth with requests, but the packet also contains
> the response EF for the request it got from the last packet received.
> The autokey protocol allows for any number of responses but only one
>  request, but I think the reference implementation only ever sends a
> single response in the packet in addition to the new request.

I believe you, and I based my assertion on some code I read not that
long ago where I thought we specifically only looked for a single EF.
We generalized the code to handle more.  I could be confused, or there
might be more than one place in the code where this was handled.

> I think maybe our best bet is to rev the autokey protocol (if we want
> to retain it at all, that is) and then say that a legacy MAC MUST be
> 24 bytes or less and may only be used with no EFs at all, or if one
> or more EFs are present they MUST be only the current autokey EFs, in
> which case a legacy MAC must be present. All other EFs, if they
> require a MAC, MUST use the new MAC extension and a legacy MAC MUST
> NOT be present. That leaves us with only a single problem, if any EF
>  other than the autokey EFs are in a packet, the total length of all
> the EFs in the packet MUST NOT be less than 25 bytes. We would have
> to use something like the LAST EF to pad it out. Not necessarily as
> is but we need some way to pad the EF. I don't think it would be wise
> to demand that all new EFs be able to handle an arbitrarily long set
> of padding to accommodate the requirement, but perhaps that wouldn't
> be bad.

If somebody wants to rev the autokey proposal to address its current
limitations, that's fine.  We can do that.  I'm not sure it's worth the
effort, especially with NTS on the near horizon.

Is what you describe necessary to address real, current problems, or is
it an attempt to address potential or expected problems?

I ask this because I'm loathe to add things to a standard that are not
clearly needed.

Are we CERTAIN that *nobody* is using legacy MACs that are more than 24
bytes?  I know the ntpd codebase is *supposed* to allow for larger
digests.  And I also see the codebase currently limits these to 24
bytes.  That's arguably a bug, but still.  There may be other
implementations out there that do allow larger MACs.

> accommodate existing software and solves the problem of parsing the
> EFs going forward. And the requirement for the autokey and legacy mac
> stuff can go away when we rev to version 5.

Yes we should be able to get rid of legacy MAC with v5.

As for the parsing problem moving forward, I still don't see there is a
problem.

Old code will continue to work.

We have methods with the new EFs to see if the implementation will
support any new EFs.  That all happens easily, and very early.

We can easily see if what we're pointing it is a potential EF or a
potential MAC.  We can try parsing the remaining data in several ways,
and see if there is a potential ambiguity or not.  I think I've
described this before.

My concern here is that I think that the constraints in 7822 are
needless and excessive.  They prevent useful future behaviors.

To go back to what you wrote:

> That leaves us with only a single problem, if any EF other than the
> autokey EFs are in a packet, the total length of all the EFs in the
> packet MUST NOT be less than 25 bytes.

Is this necessary?  If we're going to use new EFs, then we're looking at
new code, and we'd have negotiated this.  For that matter, if there is a
real concern that this will ever be a problem, we could do an initial EF
exchange where we negotiated what the minimum would be.

But doesn't this problem also go away if, with new code (since we're
dealing with new EFs), we see that each side supports EF-MAC?  In that
case, we won't be using legacy MACs and there will be no expectation to
see one.

> With this scheme, if the total extensions length is 24 bytes or less
> it is a legacy MAC. If it is longer than that, look at the first
> field and see if it is an autokey EF. If it is autokey, traverse the
> chain until there is 24 bytes or less remaining, which will be a
> legacy MAC. Check that all EFs are only autokey EFs. If there are any
> other types of EF, ignore all EFs and MAC and process normally or
> drop the packet. If the first extension is not autokey, then traverse
> the chain and verify that none are autokey and that the chain ends
> with no residual. If that is not the case, ignore the EFs or drop the
> packet. Otherwise process the EFs normally.

But if we're using new code, we can know that we'll never be expecting a
legacy MAC.

Am I missing something?

---

From: Hal Murray <[email-masked]>
Date: Wed, 18 May 2016 23:54:48 -0700

> Yes we should be able to get rid of legacy MAC with v5.

Why not bump to v5 now?

My straw man for v5 would be all extensions get a type/length header.  No 
more dancing around grandfathered stuff.

What are the downsides of going to v5 now?  What other things do people have 
in mind for v5?  How long would it take us to work things out?

> Old code will continue to work.

Mumble.  That depends upon what you mean by "work" and what the new code does.

> We can easily see if what we're pointing it is a potential EF or a potential
> MAC.  We can try parsing the remaining data in several ways, and see if
> there is a potential ambiguity or not.

That seems unreasonably complicated.  It's the sort of code I hate to 
maintain.

I think it's reasonable to point out that we haven't yet managed to agree on 
how to add new EFs while still allowing the old stuff.  It may seem 
reasonable to you, but I haven't seen a lot of agreement.  If others think 
Harlan's proposal is good enough, please speak up and help explain things to 
the rest of us.

-- 
These are my opinions.  I hate spam.

---

From: Brian Utterback <[email-masked]>
Date: Fri, 20 May 2016 11:23:06 -0400

> it an attempt to address potential or expected problems?

A little of both. The problem is that the legacy MAC is a field of 
opaque data in which each byte is able to all possible values and except 
for the first couple of bytes, will take those values with a uniform 
distribution. Thus looking inside the field to identify it is 
non-deterministic since no matter what I am looking for there is a 
possibility that I can find it just by chance.

So, the only other choice is to identify it by context. Currently we 
know two things about about the MAC, it either is alone with no 
extensions or it appears with only AUTOKEY extensions and comes after 
them. And we know that AUTOKEY always requires a MAC.  And that all MACs 
are 24 bytes or less. Thus you are correct, it isn't too hard at this 
point to identify a MAC, except for the case of a lone MAC without 
extensions, which is currently identified by being 24 bytes or fewer.

However, the problem is that as we introduce extension fields, we hope 
that software will adopt them. Thus we need guidance to developers to 
maintain the status quo so that no new software violates the assumptions 
we use to identify the MAC field. This is what led to my suggestions, 
they are what I believe is necessary and sufficient to avoid the 
possibility of someone coming along and invalidating a necessary 
assumption but still following the RFCs.

I think it is ironic that Dr. Mills choose the system he did because he 
desired that the packet be able to be parsed with a minimum of reliance 
on its internal consistency and cracking of its fields, but those 
choices have left us with a situation where we now need to validate 
almost everything in the packet just to be able to identify its structure.

> implementations out there that do allow larger MACs.

Certainly there is a desire to use larger MACs, so while I cannot say 
for certain that such an implementation doesn't currently exist, I can 
also say for certain that if we do not forbid it there soon will be one 
or more. It is fairly simple to convert software that does use longer 
MACs (if such exist) to conform to my proposal. And in any case such 
software will almost certainly inter-operate only with itself.

> needless and excessive.  They prevent useful future behaviors.

Can you give an example of what behaviors you envision?

We really only have one problem, the legacy MAC field. It needs to die, 
but it has been around too long to simply kill it without rev'ing the 
protocol version. But if we can't kill it then we have to make sure it 
doesn't get used in any new contexts. The only way to do that is to 
outlaw its use on any thing other than what it already is used for, 
stand-alone and Autokey.

The fact that we have standalone MACs mean that we have to be able to 
distinguish between one and a set of extensions without looking inside 
the field itself. This is currently done by size and I don't know 
another way to do it. Allowing a set of extensions to meet the same 
criteria used to distinguish a standalone MAC invalidates that procedure 
without another one being available. I see two ways to ensure that the 
extensions cannot be mistaken for a standalone MAC, either pad at least 
one extension so that the length is more than 24 bytes or create a no-op 
extension that can be padded. I don't like padding arbitrary extensions 
for two reasons. First, an extension might convey information in its 
length and second it complicates the process of sending an extension, 
where after one or more extensions are written to a buffer the code has 
to possibly go back and rewrite one of them. I think it is cleaner to 
have a no-op extension that is simply added if the extensions are too 
short.

> case, we won't be using legacy MACs and there will be no expectation to

You will not be using a legacy MAC only if you forbid them with new EFs 
and as a server you cannot tell if an arbitrary client packet has new 
extensions or a standalone MAC unless you either make the length 
restriction or know something about the client's ability to send EFs.

> But if we're using new code, we can know that we'll never be expecting a

We don't know what code the other side is using.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 23 May 2016 11:56:34 +0200

On Fri, May 20, 2016 at 11:23:06AM -0400, Brian Utterback wrote:
> Certainly there is a desire to use larger MACs, so while I cannot say for
> certain that such an implementation doesn't currently exist, I can also say
> for certain that if we do not forbid it there soon will be one or more. It
> is fairly simple to convert software that does use longer MACs (if such
> exist) to conform to my proposal. And in any case such software will almost
> certainly inter-operate only with itself.

chrony supports symmetric keys with longer MACs (e.g. SHA256) and I
know there are people who use it. It was implemented when it was still
an NTPv3 implementation and it didn't have to know anything about
extension fields.

When the code was updated to NTPv4, this was obviously a problem. The
spec didn't have the new restrictions on lengths yet and it just said
extension fields are at least 16 octets. This was a problem even for
MD5 MACs as they are 20 octets. So the code had to be modified to do
what Harlan is now proposing. It checks if it's a MAC that
authenticates the packet first and if not, it's skipped if it looks
like a valid extension field. It doesn't do anything with the
extension fields yet, so there is no problem with clients getting
responses they don't understand.

I don't like it and I'm looking forward to the new specification for
MAC extension fields. I'd also like to allow "truncated" MACs, so they
are not longer than 160 bits even if using SHA256 or longer hashes. I
don't think there is any point in sending full 32 or 64-octet hashes.

> distinguish between one and a set of extensions without looking inside the
> field itself. This is currently done by size and I don't know another way to
> do it. Allowing a set of extensions to meet the same criteria used to
> distinguish a standalone MAC invalidates that procedure without another one
> being available. I see two ways to ensure that the extensions cannot be
> mistaken for a standalone MAC, either pad at least one extension so that the
> length is more than 24 bytes or create a no-op extension that can be padded.

Right. And if we wanted to avoid adding a full 28-octet padding field,
we could put the extension fields in a packing field and just add
enough padding so they all together are 28 octets.

> I don't like padding arbitrary extensions for two reasons. First, an
> extension might convey information in its length and second it complicates
> the process of sending an extension, where after one or more extensions are
> written to a buffer the code has to possibly go back and rewrite one of
> them. I think it is cleaner to have a no-op extension that is simply added
> if the extensions are too short.

+1

---

From: brian utterback <[email-masked]>
Date: Mon, 23 May 2016 07:53:16 -0400

> responses they don't understand.

Oddly, the reference implementation is able to send longer MACs but it
cannot receive them. I wonder if chrony can receive the longer MACs it
sends? But in any case, chrony is almost certainly exchanging those
longer MACs with other systems running chrony.
> don't think there is any point in sending full 32 or 64-octet hashes.

And this would be a simple solution to the problem. Use whatever
algorithm you like, but just truncate it to fit in the legacy MAC size
restriction. If we ever decide we need longer MACs then the MAC
extension field would be the way forward. Not only that, but today I
learned about length extension attacks, so a truncated MAC could
actually be more secure. Learn something new everyday.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 23 May 2016 15:35:17 +0200

> longer MACs with other systems running chrony.

Yes, chrony receives the packet and responds, but ntpd rejects that
because it doesn't see the MAC thinking it's an extension field.

> restriction.

That would make sense to me. Maybe the length of the hash could be
specified in the key file together with the algorithm, e.g SHA-256/160
or SHA-512/64 if someone prefered shorter packets.

> If we ever decide we need longer MACs then the MAC

That's a interesting point. As new extension fields are introduced the
chances this could be used in a real attack might go up. At least for
the new MAC extension field it would be good to allow also HMAC, like
NTS does, and avoid this problem entirely.