Subject: [ntpwg] Parsing NTP packets regarding MACs and EXTs.

From: brian utterback <[email-masked]>
Date: Mon, 20 Jun 2016 21:18:43 -0400

Now that we seem to have a way forward for the extension type field, we
still have a bit of a mess on how to break parse the packets into its
component parts. We know how to break apart a packet that has no
extensions and no MAC, it has a fixed size.

Now, the NTP RFCs have more often then not took the strategy of saying
that the reference implementation is the definitive reference for the
protocol. Looking at the current software we find a few restrictions
that it uses to parse the packet:

1. All extensions are 24 bytes or more in size.
2. A MAC field is 20 bytes or less.
3. The MAC, if present, is always the last thing in a packet.
4. A packet that is 48 bytes long has neither extension fields nor a MAC.
5. A MAC or extension field starts at byte 49.
 
I don't believe it makes any other assumptions in order to parse the packet.

Now, our problem is that we would like to have MACs greater than 20
bytes and extension fields less than 24. The question is, how can we
relax these constraints and still be able to parse the packet?

We can do some minor changes. While the current software assumes that
all extensions are at least 25 bytes, to parse the packet we only need
require that the last extension in the packet be 24 bytes. We can
continue to limit the MAC to 20 bytes and say that going forward if a
MAC longer than 20 bytes is desired then the new MAC extension field
needs to used. Forcing the last extension to be 24 bytes seems like a
kludge, while limiting a legacy MAC field to 20 bytes does not since we
would like to encourage the use of the new MAC extension field anyway.

There have been several suggestions on how to eliminate the problem with
length of the extension fields, but none of them seem very elegant.
Danny said he and Aanchal had discussed this and believe they have a
solution. If so, or if anyone else has a solution, please propose them
here. But do try to limit yourself to practical solutions and not
propose something that "feels" like it would work.
-- 
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 start to exhibit their own agenda
------------------------------------------------------------------------
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: Tue, 21 Jun 2016 03:25:32 +0000

> 1. All extensions are 24 bytes or more in size.

I submit:  s/are/have been/

> 2. A MAC field is 20 bytes or less.

We have a recollection that this has sometimes been larger, but we
haven't gone thru some of the older code to see when this might have
changed.  I know we intended to support longer MACs.

> would like to encourage the use of the new MAC extension field anyway.

I'm not seeing the problem yet.  An EF is well-formed.  We know its type
and length.  We can look to see what, if anything, comes after it.

If we want to assume (or even require) that a legacy MAC is 20 bytes (in
new code, at least) then this gets even easier.

A legacy MAC is well-formed.  We know where it's coming from.  We know
what keyID we're expecting from that source.

We will likely soon have I-DO.

> propose something that "feels" like it would work.

Please bear with me:  I don't think we need to or even should codify how
we decide this issue.  Let the implementations figure it out.  I really
don't think it's that hard to do.  Certainly not with legacy packets, as
those will be either plain packets or Autokey+legacy MAC.

The current EF proposal list has this pretty well covered, and I'm not
seeing any clear benefit to specifying exactly how an implementation
MUST decide if data after the base packet is [EF]*LegacyMac? .  Beyond
that, I believe we're giving ourselves a whole lot more work to do.

H

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 21 Jun 2016 01:37:51 +0000

Are we limited to what the current installed base can handle?
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 21 Jun 2016 08:14:49 +0000

> Are we limited to what the current installed base can handle?

I don't think so.

The currently installed base at best knows:

- base packet
- base packet + legacy MAC
- base packet + Autokey EF + legacy MAC

H

---

From: Hal Murray <[email-masked]>
Date: Tue, 21 Jun 2016 02:39:32 -0700

[email-masked] said:
> We have a recollection that this has sometimes been larger, but we haven't
> gone thru some of the older code to see when this might have changed.  I
> know we intended to support longer MACs.

What do you mean by "MAC field"?

The simple shared key MACs include a 4 byte header.  MD5 mode has a 16 byte 
hash for 20 bytes total.  SHA1 has a 20 byte hash for a 24 byte total.

[email-masked] said:
> A legacy MAC is well-formed.  We know where it's coming from.  We know what
> keyID we're expecting from that source. 

I don't understand what you mean by "know where it's coming from".  The 
server doesn't know which clients will be using which keys.

-- 
These are my opinions.  I hate spam.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 21 Jun 2016 10:58:32 +0000

> The simple shared key MACs include a 4 byte header.  MD5 mode has a 16
> byte hash for 20 bytes total.  SHA1 has a 20 byte hash for a 24 byte total.

And both of those are very very, and fairly, obsolete respectively.

No new security mechanism, and that's what we're defining here, should use anything less than SHA 256.
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Danny Mayer <[email-masked]>
Date: Tue, 21 Jun 2016 10:26:45 -0400

> No new security mechanism, and that's what we're defining here, should use anything less than SHA 256.

Yes. The reference code supports the creation of better hashes than MD5
and SHA-1, since OpenSSL supports it, but the parsing code does not and
that's what needs to get fixed. This is not a NTP WG issue, it's a
problem with the reference implementation that needs to get fixed. I do
note that RFC5905 only references MD5 and that IS a WG problem.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Tue, 21 Jun 2016 11:45:09 -0400

On 6/21/2016 10:51 AM, Daniel Franke wrote:
> On 6/21/16, Danny Mayer <[email-masked]> wrote:
> A bigger problem than MD5 is the fact that NTP's  "HMAC" isn't HMAC;
> it's the H(K||V) construction vulnerable to length-extension attacks.
> 
> However, supporting better hash functions shouldn't require any
> changes to parsing. The length of a MAC tag doesn't have to be the
> same as the digest size of the hash function you're using. It's
> perfectly safe, e.g., to truncate HMAC-SHA256 to 128 bits.
> 
> I oppose putting the legacy MAC field to any new uses or allowing it
> take on anything other than its current size. Any new crypto should be
> done in extension fields. The parsing rules should be as follows:
> 
> If the packet is 48 bytes, it has no extensions and no MAC.
> If the packet is between 49 and 67 bytes inclusive, it's malformed; discard it.
> If the packet is 68 bytes, it has a legacy MAC and no extensions.
> If the packet is more than 68 bytes, the last 20 bytes are the keyid
> and MAC, the first 48 bytes are the standard fields, and everything in
> between is extension fields. If the keyid field is 0, then the MAC
> field is ignored, and these last 20 bytes are basically just filler to
> make the packet parse correctly.
> 
> At such time as we publish a standard for NTPv5, we can get rid of the
> legacy MAC fields and move their functionality into extension fields,
> so that the 20 bytes of wasted filler is no longer necessary.

Yes, the intention is to relegate the old MAC to existing usage and only
use EF MAC for future use. We are also planning to move to GMAC for
hashing algorithms.

Danny

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 21 Jun 2016 15:51:54 +0000

> Yes, the intention is to relegate the old MAC to existing usage and only use
> EF MAC for future use. We are also planning to move to GMAC for hashing
> algorithms.

Why?  I understand AES-GCM as it's widespread and has hardware assist on most server platforms, but why GMAC and not one of the more common mechanisms?
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Danny Mayer <[email-masked]>
Date: Tue, 21 Jun 2016 12:41:48 -0400

> Why?  I understand AES-GCM as it's widespread and has hardware assist on most server platforms, but why GMAC and not one of the more common mechanisms?

The intention is not to limit ourselves and AES-GCM is only one of the
algorithms. The RFC needs to be updated but the reference implementation
will support what's available and should be be flexible enough to switch
algorithms in case any of them become regarded as vunerable.

Danny

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 21 Jun 2016 16:52:13 +0000

> algorithms in case any of them become regarded as vunerable.

Theoretically yes, but if AES-GCM is broken we'll all be using sundials anyway :)

I strongly recommend we look to what TLS is doing.  It has had the most attention from cryptographers of any IETF WG. For plaintext MAC, SHA256 HMAC.  For encrypted MAC, AES-GCM with chacha/poly as a backup.  Include an algorithm ID.

Do we have any reason to know that's not good enough?
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Rob Seaman <[email-masked]>
Date: Tue, 21 Jun 2016 09:55:51 -0700

> Theoretically yes, but if AES-GCM is broken we'll all be using sundials anyway :)

If UTC is redefined sundials won’t help.

Rob Seaman

---

From: Hal Murray <[email-masked]>
Date: Tue, 21 Jun 2016 12:22:53 -0700

> anything less than SHA 256. 

I was describing current usage.

I thought we were trying to sort out how to parse the extension - look at the 
Subject.  The goal is to find something that will allow a new clean extension 
mechanism and also coexist with current usage without needing to bump the 
version number.

I agree that new work should use something better than MD5 and SHA1.

---

From: Danny Mayer <[email-masked]>
Date: Tue, 21 Jun 2016 15:28:11 -0400

> If UTC is redefined sundials won’t help.

Well we just heard a lot about sundials over the last few weeks!

Danny

---

From: Hal Murray <[email-masked]>
Date: Tue, 21 Jun 2016 12:32:50 -0700

> If the packet is 68 bytes, it has a legacy MAC and no extensions.

Current usage also includes a 72 byte legacy MAC for SHA1.

> If the packet is more than 68 bytes, the last 20 bytes are the keyid and MAC, the first 48 bytes
> are the standard fields, and everything in between is extension fields. If
> the keyid field is 0, then the MAC field is ignored, and these last 20 bytes
> are basically just filler to make the packet parse correctly. 

Why would the last N bytes be a keyid and MAC rather than putting the MAC in 
a new extension?

My attempt at that tangle would be:
  If length is 68 or 72, parse as legacy MAC.
  else parse as new extension.
Sender must insert filler if the length of a new format packet will be 68 or 
72.

---

From: Hal Murray <[email-masked]>
Date: Tue, 21 Jun 2016 13:31:13 -0700

[email-masked] said:
> I was just going through WG documents and saw that we already opined on this
> issue last March with RFC7822. It's consistent with what I've suggested so
> far, except that it allows extension fields without a MAC as long as the
> final extension field is at least 28 bytes long. I think this is too clever
> by half and I wish I'd been paying attention before it was ratified so that
> I could have objected. Oh well, too late now and no big deal. 

We can fix that.  The clean way is to issue an updating RFC.

The quick way is to just ignore that corner case.  It won't be the first time 
that real-life and RFCs have diverged.

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 21 Jun 2016 22:46:52 +0000

"Salz, Rich" writes:
> > byte hash for 20 bytes total.  SHA1 has a 20 byte hash for a 24 byte tota=
> l.
> 
> No new security mechanism, and that's what we're defining here, should use =
> anything less than SHA 256.

We're talking about a digital signature used to valdate a ~48 byte
packet.  Unless it has an EF, when it will be longer.

Sure, 160 bits is a current lower bound on how good it should be.

But again, how thoroughly do you want to "protect" this 48-byte message?

How big of a signature do you need to feel warm and fuzzy regarding the
validity of a packet 10 times that size, which is likely to be *way*
more than we'll be seeing?

H

---

From: brian utterback <[email-masked]>
Date: Tue, 21 Jun 2016 22:11:15 -0400

> I submit:  s/are/have been/

Agreed.

> changed.  I know we intended to support longer MACs.

Not in xntpd, nor any version in bitkeeper and it goes back 18 years.

> and length.  We can look to see what, if anything, comes after it.

Yes.

> what keyID we're expecting from that source.

Not true. We could be the server with no association for the source.

> we decide this issue.  Let the implementations figure it out.  

I would be fine with that on two conditions. One, we know it to be true.
Two, that it is obvious enough from the RFC for an implementer to figure
it out.  If it is not obvious then we most document it. If it doesn't
exist then we must make changes until it does exist.

> I really

(what about plain+legacy MAC?)

We agree that we do not want to codify anything we don't have to, but
what ever we decide for the algorithm to parse the packet, any
assumptions it makes must be made to always hold in the future.

> that, I believe we're giving ourselves a whole lot more work to do.

Agreed, with the stipulations above about existence and obviousness. The
current EF drafts and RFCs are inconsistent in this regard. We must make
them consistent. We can only do that once we know how to parse the
packets so we can determine which inconsistencies to erase and which to
keep. I do not see an obvious algorithm yet so the obviousness condition
is clearly not fulfilled, and the existence condition may not be either.
So, ignoring our current inconsistent docs, how should a packet be
parsed? We cannot have both longer MACs and shorter EFs without adding
some other restrictions. What should those restrictions be? One proposal
is one the floor, legacy MACs must not be longer than 24 bytes, longer
MACs must use the MAC EF. This is not a sufficient condition, but it
helps limit the problem. Do we want to stipulate this before proceeding?

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 22 Jun 2016 06:01:12 +0000

> Not in xntpd, nor any version in bitkeeper and it goes back 18 years.

OK, then this was never reported as a problem, as it's a bug.

> Not true. We could be the server with no association for the source.

OK, in that case we at least have a keyID and we can see if we have a
corresponding keyID and try and validate the MAC.

If it's the last thing in the packet, there are 4 choices:

- it matches an EF:
- - if this or any previous EF requires a MAC and this is the last
    bit of data in the packet, it's a FAIL on this possibility.
- - if it also matches a MAC:
- - - if it is a valid MAC, then we should believe it was a MAC.
- - - if it does not match a valid MAC, then it's either a valid EF
      or an invalid EF (see the first sub-point)

- it is NOT a potentially valid EF:
- - then if it's a valid MAC we should believe it was a MAC
- - otherwise it's neither a valid EF nor a valid MAC.

There are a few holes in the above list, but they're easy to find and
address.

> exist then we must make changes until it does exist.

If we decide to document this, we should document it as a POSSIBLE
solution, not a REQUIRED solution.

> assumptions it makes must be made to always hold in the future.

Sure, and again, we have only had 1 EF in the past.  The rules for MAC
are pretty easy.  It's trivial to decide if a packet has an Autokey EF,
and if it does, there MUST be a (legacy) MAC after it.

With new code we've clearly got the mechanism in place to handle these
things.  I'm still not seeing why we're putting so much energy in to
this.

> helps limit the problem. Do we want to stipulate this before proceeding?

The new proposals include:

- I-DO
- MAC-EF
- LAST-EF

amongst others.  It is possible to implement a new instance of NTP and
mess this up?  Sure.  It will take some work and, I submit, particular
lack of clue.

A server should not be sending anything the client has not asked for.

A client has a means to query the server and see what is acceptable.  A
client will be saving some state, so it can remember.

Symmetric modes can also query to see what the other side can accept.
In this case, we're already saving some state.  We can remember here,
too.

We're looking at Transparent Clock proposals.  A device "in the middle"
SHOULD NOT (and that's very nearly a MUST NOT) be adding these
corrections to a packet unless there is a clear indication that such
augmentation is allowed.

H

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 22 Jun 2016 09:46:28 +0200

> Current usage also includes a 72 byte legacy MAC for SHA1.

There is also 52-octet packet with crypto-NAK.

> > are basically just filler to make the packet parse correctly. 

The trouble with this is that it doesn't allow packets without MAC.
There is already an extension field specified which relies on that.

The requirements that I think were discussed on this list at some
point are:

1. unambiquous parsing, the parser shouldn't have to look inside or
   have access to keys to distinguish an extension field from MAC
2. allow packets with extension fields but no MAC
3. allow specification of small extension fields to not waste too
   much bandwidth
4. compatible with existing implementations to allow reliable
   detection of support for new extension fields (i.e. don't send a
   request that won't have a response due to invalid format)
5. allow arbitrary padding to make length of request and response
   symmetric to not create asymmetric network delay and add extra
   error to the NTP measurements

I think the original RFC 5905 satisfies 1 and 4. RFC 7822 satisfies 1,
2, and 4. There is a possible ambiguity in parsing of packets with
crypto-NAKs, but that could be resolved by allowing crypto-NAKs only
in packets without extension fields.

>From what has been discussed so far, I think the only approach that
satisfies all of these requirements is RFC 7822 extended with the
packing and padding extension fields I proposed few weeks ago and some
extension field for MACs. Basically, old implementations would see
just one long extension field and would not drop it for having an
invalid format. New implementations would check if the length of the
packet is at least 76 octets and the octets on position 49 and 50
match the packing field type. If yes, there is no legacy MAC and the
rest of the packet is always one or more extension fields with no
restrictions on their length. This costs just 4 octets. I think that's
reasonable.

Does anyone see a different approach that would satisfy all these
requirements?

If we don't need them all, the solution could be simpler. If we can
drop requirement #4, there is always the option to bump the protocol
version and we can change anything we need, but that should be the
last resort.

-- 
Miroslav Lichvar

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Jun 2016 13:59:05 +0000

> If we can drop
> requirement #4, there is always the option to bump the protocol version and
> we can change anything we need, but that should be the last resort.

I would like us to strongly consider this.
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Jun 2016 14:01:18 +0000

> But again, how thoroughly do you want to "protect" this 48-byte message?

The size of the message is not relevant; the importance of it is what counts.

I want to protect network-based time synchronization with best-practice security.

---

From: Daniel Franke <[email-masked]>
Date: Tue, 21 Jun 2016 10:51:32 -0400

---

From: Daniel Franke <[email-masked]>
Date: Tue, 21 Jun 2016 15:41:39 -0400

> make the packet parse correctly.

I was just going through WG documents and saw that we already opined
on this issue last March with RFC7822. It's consistent with what I've
suggested so far, except that it allows extension fields without a MAC
as long as the final extension field is at least 28 bytes long. I
think this is too clever by half and I wish I'd been paying attention
before it was ratified so that I could have objected. Oh well, too
late now and no big deal.
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Daniel Franke <[email-masked]>
Date: Tue, 21 Jun 2016 16:38:05 -0400

I would let sleeping dogs lie as far as the RFC goes. For
implementations, I would make it policy to accept such packets but
never to emit them.

---

From: Daniel Franke <[email-masked]>
Date: Tue, 21 Jun 2016 16:52:25 -0400

> implementations, I would make it policy to accept such packets but

Actually, there's a clarification which I think does need to be added
somewhere. In the case where extensions are present and all are <28
bytes, a legacy MAC field needs to be included for correct parsing. To
facilitate this, any legacy MAC with a keyid of 0 MUST be ignored. We
don't want implementations responding to those with a crypto-NAK
rather than something useful.

I think we can stick this clarification somewhere into
draft-mayer-ntp-mac-extension-field.
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Daniel Franke <[email-masked]>
Date: Wed, 22 Jun 2016 11:07:19 -0400

> I want to protect network-based time synchronization with best-practice

To expand on Rich's point: MD5 is broken and SHA-1 is weak, for
reasons that mostly have *nothing to do* with their digest length.
MD5's digest length is 128 bits. That's not enough these days for
collision resistance, but for a MAC it's plenty; the problem is
elsewhere! As I've already pointed out earlier in this thread, MACs
may be truncated. HMAC-SHA-256 with its output truncated to 128 bits
is just fine.
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Brian Utterback <[email-masked]>
Date: Wed, 22 Jun 2016 11:20:14 -0400

> OK, then this was never reported as a problem, as it's a bug.

Not a bug, a design decision. It was clearly intentional, if short-sighted.

> corresponding keyID and try and validate the MAC.
That is a clear layer violation. The packet must be parseable using only 
the information in the packet. Firewalls, load balancers, packet capture 
dissectors require that. And more to the point, so does the checksum 
complement field.

Worse still, parsing it by attempting to validate sounds like the worst 
possible solution. Typically you would expect to process a packet as 
follows:

1. Check for well-formedness.
2. Check for validity.
3. process packet.

But the current software defers the MAC validity check until the last 
possible moment in the hopes that prior test failures will make doing 
the decrypt auth check unnecessary due to the high cycles cost. Moving 
it to the first step and then doing the decrypt where it might actually 
be unnecessary seems...ill-advised.

> If it's the last thing in the packet, there are 4 choices:

If you can't parse it you can't know if it is the last thing in the packet.
> - it matches an EF:
Might be an unknown EF.
> There are a few holes in the above list, but they're easy to find and

I submit that they are impossible to find and address as is. And while I 
agree that if you find a valid MAC then the field is definitely a MAC, 
it is unacceptable to require a decrypt operation to parse the packet. 
Your algorithm is circular hand waving.

The current algorithm absolutely depends on MACs being 24 bytes (not 20 
bytes, sorry, my mistake) or less and extensions being more than 24 
bytes. Removing either constraint makes any algorithm indeterminate 
without adding another constraint somewhere, because without the length 
restrictions an unknown EF is indistinguishable from an invalid MAC. In 
the pathological case, it is even possible to have a valid MAC that is 
indistinguishable from a known EF, but that will never happen in practice.

Agreed.

> and if it does, there MUST be a (legacy) MAC after it.

It is only trivial because of the length restrictions. Without them it 
is indeterminate. You can ignore the indeterminacy and probably be right 
almost all of the time. But it is still indeterminate.

> things.  I'm still not seeing why we're putting so much energy in to

A whole lot of lexing problems become a whole lot easier if you decide 
to ignore the hard cases. Parsing a packet should be trivial and it is 
for virtually every other protocol on the Internet. If we can't get even 
that right, what hope do we have on the more difficult problems?

Imagine that the NTP RFC said the client is free to put the first 6 
words of the standard NTP packet in any order and the server has to 
figure out which is which. It is a similar problem and in fact might 
even be easier than what you proposed. It is also indeterminate but is 
solvable in the majority of cases. And an implementer, writing the code 
is going to curse all the while asking why they just didn't specify the 
order so all the work isn't necessary. That is why we need to put the 
energy in to this.

All working systems eventually show their own agendas.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Jun 2016 15:26:30 +0000

> But the current software defers the MAC validity check until the last possible moment in the hopes that prior test failures will make doing the decrypt auth check unnecessary due to the high cycles cost. Moving it to the first step and then doing the decrypt where it might actually be unnecessary seems...ill-advised.

It depends on the cost of doing the decryption (and doing it properly, e.g. constant-time).

Our belief is that AES-GCM will not be burdensome to any server.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Brian Utterback <[email-masked]>
Date: Wed, 22 Jun 2016 11:52:58 -0400

> Our belief is that AES-GCM will not be burdensome to any server.

Define burdensome. It has to be more burdensome than not doing it at 
all. It has to be more burdensome than a couple of arithmetic operations 
and a couple of compares. And it still requires information not in the 
packet.

---

From: Brian Utterback <[email-masked]>
Date: Wed, 22 Jun 2016 12:01:36 -0400

> draft-mayer-ntp-mac-extension-field.

That is one of several possible solutions. We all have different, 
mutually exclusive ideas of the additional restrictions needed in our 
heads. We need a consensus on what is necessary and sufficient and then 
agree to all stick to it.

By the way, I think your restriction doesn't need apply if all the 
extensions are less than 28 bytes, only if  the last extension is less 
than 28 bytes. Unless you were thinking that the larger ones could be 
placed last? Either way it needs to be explicit.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Jun 2016 16:40:44 +0000

> Define burdensome. It has to be more burdensome than not doing it at all. It has to be more burdensome than a couple of arithmetic operations and a couple of compares. And it still requires information not in the packet. 

Well yeah, sure doing something is more work than doing nothing.

There is no zero-cost security fairy dust that we can sprinkle over NTS to make it secure by default without some additional work being done.

In that context, and in what I thought the thread was, my claim was that AES-GCM is no more burdensome to servers than  weaker mechanisms.
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Daniel Franke <[email-masked]>
Date: Wed, 22 Jun 2016 13:35:20 -0400

> agree to all stick to it.

I agree, and in an attempt to push things forward, I'm going to submit
an I-D clarifying processing expectations for legacy MACs when the
keyid is 0. This, combined with existing guidance in RFC7822, will be
sufficient always to provide senders *a* way to construct
syntactically unambiguous packets, regardless of the size of the
extension fields or whether they're employing legacy authentication.
If we also want to come up with alternate ways to cleverly shave off
bytes, we won't have precluded them.
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 22 Jun 2016 21:57:20 +0000

> I would like us to strongly consider this.

Are you talking about:

I'm very strongly opposed to bump the protocol version number to only
accomplish this goal.

It's easy to start an association with an I-DO EF and see if a response
comes back or not.

H

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 22 Jun 2016 22:00:54 +0000

"Salz, Rich" writes:
> =20

What do you mean by "protect"?

Seems to me the two concerns are:

- prevent spoofing
- detect tampering

and we need to identify ways to do this that are not too expensive.

H

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 22 Jun 2016 22:03:37 +0000

> draft-mayer-ntp-mac-extension-field.

Actually, ignoring crypto-NAK for the moment, this isn't true if the EFs
do not reqire MAC protection.

The crypto-NAK issue is a separate discussion.

H

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 22 Jun 2016 23:12:23 +0000

> Not a bug, a design decision. It was clearly intentional, if short-sighted.

Even so, had I seen it I would have fixed it.

> be unnecessary seems...ill-advised.

The validity check includes "did it pass authentication".

> If you can't parse it you can't know if it is the last thing in the packet.

Yes, in which case we can see what comes after it and decide if it's a
potentially-valid but unknown EF.

For new code, we have I-DO so this begs the question "If we're talking
about new code why is somebody sending me something I haven't said I'll
accept?"

> it is unacceptable to require a decrypt operation to parse the packet. 

We're not decrypting to parse a packet.

At some point we decide if the packet has proper syntax.

At some point we decide if the packet contents are semantically valid.
This includes authentication.

If the packet has proper syntax and semantics, we are reasonably
comfortable believing it is appropriate to process the packet.

Please show me a real example of legacy packets where we need to clean
this up.

Please show me how a reasonably contstructed and possibly negotiated
association will produce an ambiguous or "difficult" packet.

We have responsibilities *to* people, not *for* people.

http://www.dumblaws.com/

> Your algorithm is circular hand waving.

Perhaps, but it sure looks to me that it works anyway.

And I'm fine backing off as long as it's clear that what is proposed is
a MAY/SHOULD and not a MUST.

> indistinguishable from a known EF, but that will never happen in practice.

Can you show me an example?

Sure, somebody could write a new implementation that does new EFs where
they don't implement/use I-DO or LAST-EF.

Do we really need to prohibit that?

> almost all of the time. But it is still indeterminate.

What length restrictions?  I think the ones specificed in the updated
RFC are wrong, needlessly restrictive, and unnecessary.  These can be
fixed by going to SHOULD instead of MUST.

Again, with a reasonable/sane setup, can you show me any example of how
old or new code would step afoul of this indeterminism?

> that right, what hope do we have on the more difficult problems?

If we have to write correct code to handle a situation it doesn't really
matter if it happens never, rarely, or often.

In this case, I believe we're in the never/rarely category.  So we log
it, look at it, decide what went on and what we should do about it.

> order so all the work isn't necessary. That is why we need to put the 

I'm not buying that similarity.

But the good news is that we're getting close to having usable code so
we can see what happens in reality.

H

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 22 Jun 2016 23:17:18 +0000

> placed last? Either way it needs to be explicit.

I'm still not seeing it.

Old code may have an Autokey EF.  You said you saw one case where there
were 2 of them.  These cases MUST always have a legacy MAC after them.

The new experimental checksum complement case is a non-issue, as it
is intolerant of a MAC.  If somebody *tried* to use a MAC with it, the
packet would be ignored at the receiving end because the MAC would not
match.

So what's left is the "new code" case, and that's where we can expect
I-DO, MAC-EF, and LAST-EF.

But I'm repeating myself.  If I'm missing something I'd love to know
what it is.

H

---

From: brian utterback <[email-masked]>
Date: Wed, 22 Jun 2016 22:37:00 -0400

> The validity check includes "did it pass authentication".

Yes, but you can't do step one if it depends on the results of step two
to do it.

> about new code why is somebody sending me something I haven't said I'll

You also are making assumptions that are not codified and might not be
valid in other implementations. You said why would you get a new packet
that doesn't have a I-DO, well the answer is because nothing in any of
the RFCs/Drafts say that you shouldn't and it does explicitly say you
can send an EF that the other system is not known to be able to receive.
 
> At some point we decide if the packet has proper syntax.

Yes. This should be done first, before any other processing. And should
(bordering on must) be able to be done without any information external
to the packet.
> This includes authentication.
Also correct, but as I said before the current software defers the
authentication longer than one would normally expect.

Yes.

> Please show me a real example of legacy packets where we need to clean

A legacy MAC has not structure. If autokey is not in use then there are
two bytes that are known to be zero. Since autokey caches its keys in
the key cache but does not create an association on the server, the fact
that we may not know the source doesn't change whether or not it might
be autokey, so if autokey is in use between our system and any other
system, then a legacy MAC might contain any bit pattern. An EF isn't
quite so free form, but without processing the contents of the EF the
payload must be assumed to be random data. If we allow a legacy MAC to
be arbitrarily long and an EF to be any length but only longer than four
bytes and correspondingly normalize all the current EF drafts and RFCs
to get rid of all of their attempts to impose restrictions that you
think are unnecessary, then if I have some number of bytes left in the
packet, starting immediately after the regular NTP fields, there is no
way for me to know if they represent one EF, more than one EF, or one
Legacy MAC or some EFs followed by a Legacy MAC. Suppose I look at the
first word. For any of the EFs I understand or possibly do not
understand, there is a possible valid MAC that will have the exact same
bit pattern in that word. There is simply no way for me to tell whether
I am looking at a MAC or EF without checking information that is not in
the packet.

Now we might say we can start bringing other info into play, like do we
have an autokey in the cache that matches the keyid of this MAC or a
symmetric key. The EF that the MAC looks like might be an autokey EF, so
that doesn't help, but we might guess one way or the other based on the
chain of lengths and be right 2^31 times out of 2^32, or something, but
that was the point of my analogy below.

It would be absurd to create a packet made of fixed sized fields with
the first six words able to be in any order, no one would ever do it. My
point is that we are arguing over something more subtle but just as
absurd, creating a packet that is unable to be parsed with the
information in the packet, for no reason whatsoever, just to avoid
adding any restriction at all, when one or two minor restrictions that
no one would object to would solve all of these problems.

The problem is that we have (I think) about four different proposed sets
of restrictions designed to solve the problem. And you, Harlan, think
there should be fewer restrictions than we have now. Since no one
involved in this discussion except you think that it is solvable without
*adding* restrictions, I think it is incumbent upon you to give us an
exact algorithm. And if you need to resort to info not in the packet to
do it, then I think you really really need to give us very good reason
for doing that.

to this.

> we can see what happens in reality.

Is that code available somewhere?

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 23 Jun 2016 02:39:11 +0000

> and we need to identify ways to do this that are not too expensive.

Yes.  Tamper-protection can be done via HMAC/SHA256 or AES-GCM depending on plaintext or encrypted. Outside of the state issue of a shared key, which Daniel has talked about, the load this would impose on a modern server would not be a factor.

As for preventing spoofing, another way to state this issue is how you authenticate/verify the other side. For peer-to-peer server configuration, or perhaps S1 to S2, pre-shared keys might be reasonable. For larger fan-out, the state of the art is X509 certificate based. 

Hope this helps.

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 23 Jun 2016 09:34:39 +0200

> it's the H(K||V) construction vulnerable to length-extension attacks.

Are length-extension attacks actually possible with NTP packets?

I'm not sure how could a valid NTP packet be extended into another
valid packet. The lengths of the NTP header and optional fields
are all multiples of 32 bits. Therefore, the padding added by the
crypto hashes always starts with 0x80000000, which is not a valid
header of an extension field, right? Even if a field type of 0x8000
was specified and inserting the extension field was useful for some
attack, the length in the header would be zero and it wouldn't pass
the format check. The implementation would have to have a very odd bug
if it accepted a packet like that and processed the inserted extension
field.

Don't get me wrong. I'm not saying we should not adopt HMAC or
something else. I'd very like to see that. I'm just wondering how big
the issues with the current MAC really are.

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 23 Jun 2016 09:41:57 +0200

> I'm very strongly opposed to bump the protocol version number to only

Bumping the protocol version is a sure way to break the requirement as
old implementations are not expected to respond to packets using a
newer version. If we don't care about compatibility with existing
servers and rely on new clients to be able to fall back to the older
version, then we can consider bumping the version. For the record, I
think we should wait until there are more interesting changes in the
queue.

---

From: Daniel Franke <[email-masked]>
Date: Fri, 24 Jun 2016 13:43:57 -0400

> think we should wait until there are more interesting changes in the

Fully agreed. At such as we *do* bump the version number, getting rid of
the legacy MAC field should be a no-brainer. But I see no need for it now,
or any time in the near future so long as we come to some reasonable
resolution on parsing rules. On the other hand, a sufficiently
*un*reasonable resolution could paint us into a corner wherein we're unable
to make further progress without a version bump because every new extension
we want to add results in an exponential increase to the tangle of
heuristics required for correct parsing. So let's not do that.
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg