[ntpwg] Stronger symmetric NTP authentication

[Bhatia, Manav (Manav)]

Hi Dave,

Sorry for the late response. I was perhaps not very articulate in my
earlier mail. Let me give it another shot! :-)

Current NTP specs provide provision for only MD5 digests (16 octets).
This is not good enough, as there have been attacks found against MD5
and the IETF community is moving away from this towards stronger hash
algorithms (HMAC-SHA-1, HMAC-SHA-224, etc). We cannot reuse the existing
MAC field in the NTP packet as the size of digests for other hash
algorithms may not necessarily be 16 octets (its 20 octets for
HMAC-SHA-1, 28 for HMAC-SHA-224, etc.).

I was proposing a new extension field (authentication extension field)
that would add support for carrying authentication info when using other
hash algorithms. 

For backward compatibility, implementations must send the existing MAC
field filled with zeroes, so that the packet can be parsed properly. The
Key Identifier field would carry the symmetric key (<65536). The length
of the authentication extension field would the based on the
authentication algorithm being used, i.e., based on the size of the hash
it generates. The sender (server) must fill this field with zeros before
starting the computation. The hash must be calculated as in [RFC1321]
over the entire NTP header and *all* optional extension fields
(including the auth extension field) and the MAC too. Remember the MAC
has been filled with zeroes.

The receiving side (clients) must store the hash or the authentication
data carried in the auth extension field of the NTP packet. They should
then zero out the auth extension field, before the computation starts.
The client looks up the key associated with the key ID and computes the
hash from the NTP header and extension fields together + the MAC with
the key value, using the algorithm as specified in the Security
Association associated with the Key ID. 

It should now compare the hash value with what it received in the
packet; the packet is only accepted if the two match.

Am I missing something?

Cheers, Manav

> -----Original Message-----
> From: ntpwg-bounces+manav=alcatel-lucent.com at lists.ntp.org 
> [mailto:ntpwg-bounces+manav=alcatel-lucent.com at lists.ntp.org] 
> On Behalf Of David L. Mills
> Sent: Tuesday, November 18, 2008 7.38 PM
> Cc: ntpwg at lists.ntp.org
> Subject: Re: [ntpwg] Stonger symmetric NTP authentication
> 
> Manav,
> 
> Please, please, read the spec. To distinguish between an 
> extension field 
> and a possible MAC is a delicate syntactic adventure, most 
> significantly 
> to preserve backwards compatibility.
> 
> Dave
> 
> Bhatia, Manav (Manav) wrote:
> 
> > Hi David,
> >
> >> As I said previously, the encoding format supports 20-octet digests
> >> should somebody choose to implement it and preserve backward
> >> compatibility. You cannot use an extension fielf do specify
> >> the digest
> >> algorithm without imposing a deadly circularity.
> >
> >
> > So, are you suggesting that we *cannot* use any hashing 
> algorithm that
> > goes beyond 20 bytes? If we think there can be some backward
> > compatibility issues then we need to sort those out.
> >
> > Cheers, Manav
> >
> >> There is no need to specify an additional sequence number as that
> >> function is provided by the transmit timestamp and the
> >> loopback check.
> >> See the protocol specification for justification.
> >>
> >> Bhatia, Manav (Manav) wrote:
> >>
> >>> Hi,
> >>>
> >>> Is there any plan underway to use
> >>> HMAC-SHA-1/HMAC-SHA-256/HMAC-SHA-384/etc for NTPv4? We 
> could use the
> >>> extension field header to encode the new hash digest, or 
> it could be
> >>> prepared in such a way that its generic enough to support 
> any crypto
> >>> algorithm. The new extension field header could also include a
> >>> monotonically increasing sequence number that could help
> >>
> >> prevent replay
> >>
> >>> attacks.
> >>>
> >>> Cheers, Manav
> >>>
> >>> _______________________________________________
> >>> ntpwg mailing list
> >>> ntpwg at lists.ntp.org
> >>> https://lists.ntp.org/mailman/listinfo/ntpwg
> >>
> >>
> >> _______________________________________________
> >> ntpwg mailing list
> >> ntpwg at lists.ntp.org
> >> https://lists.ntp.org/mailman/listinfo/ntpwg
> >
> >
> 
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg
>