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

[[e-mail]]

E-Mail: [e-mail]


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

> Von: Miroslav Lichvar <[e-mail]>
> An: Harlan Stenn <[e-mail]>
> Kopie: "'[e-mail]'" <[e-mail]>, "Karen 
> ODonoghue \([e-mail]\)" <[e-mail]>, Suresh 
> Krishnan <[e-mail]>
> Datum: 07.03.2016 14:40
> Betreff: Re: [ntpwg] The next step of draft-ietf-ntp-checksum-trailer
> Gesendet von: "ntpwg" <ntpwg-bounces+dieter.sibold=[e-mail]>
> 
> On Mon, Mar 07, 2016 at 12:35:56PM +0000, Harlan Stenn wrote:
> > Originally, if there was an extension field there MUST be a MAC.
> 
> Right. That requirement was not necessary and it was later removed.
> 
> > Tal wrrote Errata 3627 (or whatever) and removed that requirement.
> 
> Yes, but why is that a problem?
> 
> > MAC protection is good.  NTS uses a 'single' Field Type, but the first
> > few packets have no MAC protection.  Therefore, the first few packets 
of
> > an NTS exchange arguably MUST have MAC protection outside the NTS
> > packet
> 
> With what key would that MAC be generated? Unless I misunderstood how
> NTS is supposed to work, the first few packets are simply not
> authenticated and can't be used for anything except initialization of
> the NTS association.


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


> 
> > We're getting ready to publish a "MAC in an Extension Field", and
> > arguably this is how it should have been originally done.  So in 
keeping
> > with the above logic, there are 2 pieces of information we want to see
> > for an extension field.  One is "SHOULD or MAY have MAC protection 
after
> > this field," and the other is "This extension field provides MAC
> > protection."
> 
> What will the receiver of this information do with it? The client must
> have its own policy on what extension fields has to be covered with
> MAC in order to accept the packet. The server can't dictate that.
> Normally, the client will require all fields to be covered by MAC if
> authentication is enabled.
> 
> > > > - Use a flag bit in the Field Type that says "My extension field 
does
> > > > not require a following MAC."
> > > 
> > > Meaning the field is not related to authentication?
> > 
> > Meaning "My extension field does not require a MAC after it".  This is
> > the "MAY" case as opposed to the "SHOULD" case.  An example of this is
> > Tal's checksum complement proposal, as currently written.  If ntpd 
sends
> > out an unauthenticated packet, the FPGA engine is free to rewrite the
> > transmit timestamp, but since the OS has already computed a UDP
> > checksum, if the transmit timestamp in the packet is changed it's 
almost
> > certain that a checksum complement will be needed to make sure the
> > existing UDP checksum will still be correct.  That's what Tal's 
proposal
> > is all about, and it's the first time we've seen a proposal for an
> > extension field where one MUST NOT have a MAC at the end of the 
packet.
> 
> Ok, but that information is already included in the specification. The
> client or server that generates that field needs to know that.
> 
> > > The SHA1 MAC is 24 octets, that's why there is a requirement for the
> > > last extension field to be at least 28 octets.
> > 
> > 4 byte keyid plus 24 octets.  So 28 bytes is clearly potentially
> > ambiguous.
> 
> A SHA1 MAC has 160 bits for the digest and 32 bit for the key ID.
> That's 192 bits or 24 octets total.
> 
> > Extension fields of 4, 8, 12, or 16 bytes are also unambiguous.  Why
> > prohibit these lengths?
> 
> Because MAC in a packet from an old client could be parsed as one or
> multiple extension fields.
> 
> > >> - a MAC consists of a 4-byte keyid and a payload.  If there is no
> > >> autokey extension field, the keyid MUST be <65535, and we SHOULD 
have
> > > 
> > > Isn't that restriction for keyid just for the autokey RFC? There are
> > > NTP implementations that allow any keyid with symmetric keys.
> > 
> > Originally:
> > 
> > - any extension field meant there MUST be a MAC.
> > - the only defined extention field as been autokey.
> > - if no extension field was present, then no autokey, and a MAC meant
> >   symmetric key was being used.  keyid < 65535.
> > - if an extension field was present, the autokey was being used, there
> >   MUST be a MAC, and  keyid > 65535.
> 
> That applies to the reference implementation, but not necessarily for
> other NTPv4 implementations. They can parse extension fields, but they
> don't have to know anything about autokey and can authenticate with
> MACs using key IDs above 65535.
> 
> -- 
> Miroslav Lichvar
> _______________________________________________
> ntpwg mailing list
> [e-mail]
> http://lists.ntp.org/listinfo/ntpwg

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