Subject: Re: [ntpwg] Stronger symmetric NTP authentication

From: "Bhatia, Manav \(Manav\)" <[email-masked]>
Date: Mon, 1 Dec 2008 18:31:36 +0530

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=[email-masked] 
> [mailto:ntpwg-bounces+manav=[email-masked]] 
> On Behalf Of David L. Mills
> Sent: Tuesday, November 18, 2008 7.38 PM
> Cc: [email-masked]
> 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
> >>> [email-masked]
> >>> https://lists.ntp.org/mailman/listinfo/ntpwg
> >>
> >>
> >> _______________________________________________
> >> ntpwg mailing list
> >> [email-masked]
> >> https://lists.ntp.org/mailman/listinfo/ntpwg
> >
> >
> 
> _______________________________________________
> ntpwg mailing list
> [email-masked]
> https://lists.ntp.org/mailman/listinfo/ntpwg
> 
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: "David L. Mills" <[email-masked]>
Date: Mon, 01 Dec 2008 17:34:31 +0000

Bhatia,

I don't think you understood my previous message. To wit:

1. Your suggestion seriously compromises the intended design that the 
extension fields must be validated by the MAC and invites a circular 
deconstruction. The design requires that the packet be validated without 
inspection of the extension field contents.

2. As I said, There already is support for 20-octet digests. However, 
the project to do that, work out the library and build dependencies, 
provide interoperability and automatic selection of which algorithm is 
in use, provide configuration management, etc., is way down on my 
project list.

3. As I said, serious analysis shows that, while it might be possible to 
spoof an acceptable digets, it is near impossible to spoof what might be 
acceptable NTP packet with acceptable spoofed digest.

I don't have anything more to add to this discussion.

Dave

---

From: "Bhatia, Manav \(Manav\)" <[email-masked]>
Date: Tue, 2 Dec 2008 09:44:51 +0530

Tony,

> This is not applicable to most usages of HMAC-MD5 for two 
> very good reasons:

If you read draft-ietf-ntp-ntpv4-proto-11 you will realize that NTP uses
MD5 and not HMAC-MD5.

I totally agree that the attacks may not necessarily result in direct
vulnerabilities in MD5 as used in NTP authentication purposes, because
the colliding message may not necessarily be a syntactically correct
protocol packet. However, there is a need felt to move away from MD5
towards more complex and   difficult to break hash algorithms and I was
just trying to propose an extension that does just that. One cannot
always assume that the authentication data would *always* be just 16
octets (unless somebody is thinking of truncating the SHA hash :))

At the very least, NTP should be using the HMAC construct along with MD5
as against plain MD5 that the spec mandates. 

Cheers, Manav

> From: Tony Li [mailto:[email-masked]] 
> Sent: Tuesday, December 02, 2008 8.26 AM
> To: Bhatia, Manav (Manav); 'David L. Mills'
> Cc: [email-masked]
> Subject: RE: [ntpwg] Stronger symmetric NTP authentication
> 
>  
> 
> Hi all,
> 
> 
> |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). 
> 
> 
> This is vastly misleading.  The literature documents the 
> ability to find
> collisions against straight MD5 hashing.  Thus, given a 
> plaintext block and
> a hash result, it is possible to compute a specific alternate 
> plaintext
> block that would produce the same hash result.  
> 
> This is not applicable to most usages of HMAC-MD5 for two 
> very good reasons:
> first, there is typically a password or other key material 
> concatenated with
> the plaintext block before hashing.  The password is presumably not
> available to the attacker.  [If it is, the algorithm is 
> irrelevant.  ;-)]
> No one has demonstrated a technique for determining a 
> collision to a fixed
> plaintext block modification that is also hashed by key 
> material.  Thus,
> given a valid packet, there is still no documented way to 
> tweak that packet
> and have it pass authentication.
> 
> Second, no one has demonstrated the ability to generate valid 
> hashes of
> plaintext blocks and key material without the actual access to the key
> material.  Instead, the alternate blocks that are generated 
> are unlikely to
> be valid protocol structures in the first place, result in 
> parsing errors in
> the protocol.  Thus, there is no way to wholly forge a packet 
> and generate
> correct authentication for it without the key.
> 
> That said, as always with security, there is no such thing as 
> a perfect
> algorithm and increasing the available algorithms is always a 
> good thing.
> However, it is a vast misrepresentation to suggest that this 
> is a practical
> necessity today.  There is one single (tho large ;-) customer 
> that truly
> requires SHA algorithms today.  BTW, HMAC-SHA-1 has been 
> broken and the
> customer is interested in the larger values.
> 
> Tony
> 
> P.s. This same scare tactic has been used in other IETF WG's.
> 
>

---

From: "Bhatia, Manav \(Manav\)" <[email-masked]>
Date: Tue, 2 Dec 2008 09:52:15 +0530

Dave,

> inspection of the extension field contents.

I think we're going in circles now. 

It's a trivial implementation tweak to check that if the new
authentication scheme is employed then one of the extension fields would
carry the authentication data. I cant seem to understand how this
affects the core protocol design. We cant always assume that our digest
would only be 16 octets.

Cheers, Manav

---

From: "Tony Li" <[email-masked]>
Date: Mon, 1 Dec 2008 18:56:15 -0800

Hi all,

This is vastly misleading.  The literature documents the ability to find
collisions against straight MD5 hashing.  Thus, given a plaintext block and
a hash result, it is possible to compute a specific alternate plaintext
block that would produce the same hash result.  

This is not applicable to most usages of HMAC-MD5 for two very good reasons:
first, there is typically a password or other key material concatenated with
the plaintext block before hashing.  The password is presumably not
available to the attacker.  [If it is, the algorithm is irrelevant.  ;-)]
No one has demonstrated a technique for determining a collision to a fixed
plaintext block modification that is also hashed by key material.  Thus,
given a valid packet, there is still no documented way to tweak that packet
and have it pass authentication.

Second, no one has demonstrated the ability to generate valid hashes of
plaintext blocks and key material without the actual access to the key
material.  Instead, the alternate blocks that are generated are unlikely to
be valid protocol structures in the first place, result in parsing errors in
the protocol.  Thus, there is no way to wholly forge a packet and generate
correct authentication for it without the key.

That said, as always with security, there is no such thing as a perfect
algorithm and increasing the available algorithms is always a good thing.
However, it is a vast misrepresentation to suggest that this is a practical
necessity today.  There is one single (tho large ;-) customer that truly
requires SHA algorithms today.  BTW, HMAC-SHA-1 has been broken and the
customer is interested in the larger values.

Tony

---

From: "David L. Mills" <[email-masked]>
Date: Tue, 02 Dec 2008 13:04:46 +0000

Manav,

Will you read my messages again? I don't disagree it would be a good 
idea to implement a 20-octet digest; in fact, as I said previously, 
there are already provisions for that in the design to suppor that. 
However, in the wisdom of good engineering design and utilization of 
current resources, this is not likely to be done soon. There are lots of 
other projects of importance in the evolution of NTP and this is not one 
of urgent priority. An advocacy to implement a 20-octet digest based 
purely on he perceived hazard of possible masquerade without 
consideration of the overall security hazard is simply not a good 
engineering strategy.

If your point is that NIST says SHA is good and MD5 is bad based on 
nothing other than demonstration that it is possible so spoof a digest 
with a contrived but necessarily invalid NTP message, then I suggest 
there is something seriously wrong with the security analysis. This 
point is stressed in the course I teach on computer security.

Dave

---

From: "David L. Mills" <[email-masked]>
Date: Tue, 02 Dec 2008 13:44:29 +0000

Manav,

One of the principles I teach in my course on compute security is the 
necessity of transparency and layering.

As applied to NTP, this means the authentication at one layer should not 
depend on the underlying layers. Thus, the question of whether to use 
MD5 or some other digest algorithm should not depend in interpreting an 
underlying layer, in this case an extension field. It should depend only 
on the outer layer, in this case the syntactic rules that define the 
packet format.

The NTP design is carefully layered so that the integrity of the packet 
and extension fields is determined only by the packet syntax and digest 
algorithm. Then, the integrity of the authentication scheme itself is 
determined by the cryptographic protocol, in the intended case Autokey. 
Then, the integrity of the packet itself is determined by the reverse 
hashing scheme. Finally, the integrity of the packet payload is 
confirmed by the values checks, in particular the loopback test. To 
select the digest algorithm by inspecting the extension fields violates 
this model.

Dave

---

From: Brian Utterback <[email-masked]>
Date: Tue, 02 Dec 2008 09:31:11 -0500

I happen to agree with you Dave. We don't need to implement this ASAP. 
On the other hand, you say that the design has provisions to support 
20-octet digests, but that it isn't high on the list.

I would like to suggest that you publish your list and provide the 
notes you have on the line items. The beauty of open source is that 
with enough hands, "all problems are shallow". Keep the list to 
yourself, and one or two of the top items may get implemented. Publish 
the list and probably two or three times as many will eventually 
happen, although not necessarily in your priority order. Their are 
hands available to you Dave, if you would just allow them to help.

-- 
blu

"Murderous organizations have increased in size and scope; they are
more daring, they are served by the most terrible weapons offered by
modern science, and the world is nowadays threatened by new forces
which, if recklessly unchained, may some day wreck universal
destruction."  - Arthur Griffith, 1898
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: "David L. Mills" <[email-masked]>
Date: Thu, 04 Dec 2008 15:56:26 +0000

Brian,

Publish my list? At the top is work for JPL on time synchronization in 
space, followed closely by a second edition of my book. At the moment, 
there is nothing about NTP on that list, but that could change.

The work to bring up a 20-octet digest is messy. In principle it is 
easy, as the required crypto code is already available in OpenSSL and 
the NTP crypto interface is the same. However, the ick comes in the 
build and configuration code and interaction with various defines 
scattered all over the code.

For instance, the OPENSSL define is lit when the OpenSSL library is 
present and in that case lights up Autokey. Probably, if you need only 
HMAC and don't want Autoke, that has to change. Also, it could be that 
somebody wants HMAC with Autokey.

Next, the crypto command is used to configure Autokey now. Some change 
to th econfiguration syntax and semantics would need to be done to 
configure HMAC separatly from the digest/signature combinations now 
supported. Those combinations are built in the OpenSSL library and 
passed transparently by th econfiguration code..

Next, some considerations need to be implemented to handle cases where 
the digests are mismatched. An innocent client equipped with both MD5 
and HMAC would need to automatically reconfigure when presented with one 
or the other. This might apply also if other digest algorithms were 
available.

Next, the key cache code would need to be modified to support 20-octet 
keys. This is in principle not hard, but needs review. My approach would 
be to allow keys of any length independent of digest algorithm, but that 
requires overhaul of the cache code.

I'm really opposed to a hack; the issues should be thought through and 
carefully integrated in a seamless design.

Dave

Brian Utterback wrote:

>> current resources, this is not likely to be done soon. There are lots 
>> of other projects of importance in the evolution of NTP and this is 
>> not one of urgent priority. An advocacy to implement a 20-octet 
>> digest based purely on he perceived hazard of possible masquerade 
>> without consideration of the overall security hazard is simply not a 
>> good engineering strategy.
>>
>>
>> nothing other than demonstration that it is possible so spoof a 
>> digest with a contrived but necessarily invalid NTP message, then I 
>> suggest there is something seriously wrong with the security 
>> analysis. This point is stressed in the course I teach on computer 
>> security.
>>
>>
>> Dave
>>
>>

---

From: Danny Mayer <[email-masked]>
Date: Thu, 04 Dec 2008 12:56:09 -0500

In addition this would require an update to the NTPv4 protocol.

Danny

---

From: Brian Utterback <[email-masked]>
Date: Thu, 04 Dec 2008 13:27:45 -0500

Wasn't the whole point of this discussion about how to do it without 
changing (or not incompatibly changing) the protocol? If we are going 
to allow a change in the protocol, then simply make the MAC field 
variable length we're pretty much done.

-- 
blu

---

From: Danny Mayer <[email-masked]>
Date: Thu, 04 Dec 2008 15:07:54 -0500

Brian Utterback wrote:
> changing (or not incompatibly changing) the protocol? If we are going to
> allow a change in the protocol, then simply make the MAC field variable
> length we're pretty much done.
> 

No, you also have to identify the digest type or you will have
interoperability issues. it's not just a matter of specifying the MAC
field length.

Danny

>>> Publish my list? At the top is work for JPL on time synchronization
>>> in space, followed closely by a second edition of my book. At the
>>> moment, there is nothing about NTP on that list, but that could change.
>>>
>>> present and in that case lights up Autokey. Probably, if you need
>>> only HMAC and don't want Autoke, that has to change. Also, it could
>>> be that somebody wants HMAC with Autokey.
>>>
>>> Next, the crypto command is used to configure Autokey now. Some
>>> change to th econfiguration syntax and semantics would need to be
>>> done to configure HMAC separatly from the digest/signature
>>> combinations now supported. Those combinations are built in the
>>> OpenSSL library and passed transparently by th econfiguration code..
>>>
>>> Next, some considerations need to be implemented to handle cases
>>> where the digests are mismatched. An innocent client equipped with
>>> both MD5 and HMAC would need to automatically reconfigure when
>>> presented with one or the other. This might apply also if other
>>> digest algorithms were available.
>>>
>>> Next, the key cache code would need to be modified to support
>>> 20-octet keys. This is in principle not hard, but needs review. My
>>> approach would be to allow keys of any length independent of digest
>>> algorithm, but that requires overhaul of the cache code.
>>>
>>> I'm really opposed to a hack; the issues should be thought through
>>> and carefully integrated in a seamless design.
>>>
>>> Dave
>>>
>>> Brian Utterback wrote:
>>>
>>>> I happen to agree with you Dave. We don't need to implement this
>>>> ASAP. On the other hand, you say that the design has provisions to
>>>> support 20-octet digests, but that it isn't high on the list.
>>>>
>>>>
>>>> yourself, and one or two of the top items may get implemented.
>>>> Publish the list and probably two or three times as many will
>>>> eventually happen, although not necessarily in your priority order.
>>>> Their are hands available to you Dave, if you would just allow them
>>>> to help.
>>>>
>>>>
>>>> David L. Mills wrote:
>>>>
>>>>> Manav,
>>>>>
>>>>>
>>>>> Will you read my messages again? I don't disagree it would be a
>>>>> good idea to implement a 20-octet digest; in fact, as I said
>>>>> previously, there are already provisions for that in the design to
>>>>> suppor that. However, in the wisdom of good engineering design and
>>>>> utilization of current resources, this is not likely to be done
>>>>> soon. There are lots of other projects of importance in the
>>>>> evolution of NTP and this is not one of urgent priority. An
>>>>> advocacy to implement a 20-octet digest based purely on he
>>>>> perceived hazard of possible masquerade without consideration of
>>>>> the overall security hazard is simply not a good engineering strategy.
>>>>>
>>>>>

---

From: Brian Utterback <[email-masked]>
Date: Thu, 04 Dec 2008 15:48:11 -0500

I realize that. But the point I am making is that if we can change the 
  format of the packet, then adding longer MAC hashes is trivial, just 
make the field bigger and add whatever you need to get to work. So, I 
presume that the discussion in this thread is how to do this in a 
backwards compatible manner within the existing format.

-- 
blu

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 05 Dec 2008 21:21:08 +0000

Brian,

The new interleaved modes aren't in the specification either. However, 
servers and clients automatically back out of these modes if the server 
or client is not equipped for them. So, the operation is completely 
transparent. The current development version supporting these modes is 
on all our public and private servers and clients. Yes, it is in the web 
document collection and further described in the white paper on the NTP 
Project Page.

A similar thing can be done for 20-octet digests. The original plan for 
this was formulated several years ago. The parsing rules  provide for 
8-octet (DES), 16-octet (MD5) and 20-octet (SHA) digests. This does not 
change the specification other than to require extension fields to have 
a minimum of two 32-bit words with 16-octet digests. A simple extension 
field test would even detect an extension field of only one word.

The parsing rules detect the digest as a function of the number of words 
following the NTP payload including extension fields):

0    none (no extension fields)
1   crypto-NAK
2   invalid
3   DES (no extension fields)
4   invalid
5   MD5 minimum extension field two words)
6   SHA (minimum extension field one word)
7 or more  extension field

For all extension fields now defined the minimum extension field length 
is two words.

The interoperability and configuration rules are proposed as follows:

A host is configured to support specified algorithms for both 16- and 
20-octet digests. This includes all algorithms supported by the OpenSSL 
library with the expected defaults. A new configuration command

digest <NID> ...

Where NID is consistent with OpenSSL NIDs used in the crypto command. 
There can be one NID or several in a circular list. The digest size is 
implicit in the NID. The client and symmetric peer maintains a pointer 
to the current NID. When a digest arrives, the first NID with matching 
digest size is used for subsequent packets. In case of crypto NAK, the 
next NID on the list is used, whether that be 16 or 20 octets. In 
principle, the list could be populated with all OpenSSL digest NIDs and 
a caller with any of them would clank around until a matching pair was 
found.

Operation with a stateless server with lots of clients would be somewhat 
messy with a mixture of clients using different NIDs. Normally there 
would be one NID for 16-octet digests and another for 20-octet digests. 
The server would select either depending on the client request and use 
the same one for the server reply.

Note the digest size determines the size of the key material prepended 
by the keyed-MD5 operation defined by the RFC. So far as I know, a 
similar operation has not been defined for digests other than MD5, but 
the extension is obvious.

Dave

---

From: "Greg Dowd" <[email-masked]>
Date: Fri, 5 Dec 2008 14:26:30 -0800

Since MAC always includes keyed, why not let the key id specify the
expected hash length, as opposed to a separate configuration element.
The rest of the rules would still apply.  That is actually the current
definition, although I haven't seen a DES key used in a while.

-----Original Message-----
From: ntpwg-bounces+gdowd=[email-masked]
[mailto:ntpwg-bounces+gdowd=[email-masked]] On Behalf Of
David L. Mills
Sent: Friday, December 05, 2008 1:21 PM
To: [email-masked]
Subject: Re: [ntpwg] Stronger symmetric NTP authentication

Brian,

digest <NID> ...

Dave

>>>>>>>> towards more complex and difficult to break hash algorithms and

>>>>>>>> I was
>>>>>>>>> |and the IETF community is moving away from this towards
stronger
>>>>>>>>> hash
>>>>>>>>> the plaintext block before hashing. The password is presumably

>>>>>>>>> not

---

From: "David L. Mills" <[email-masked]>
Date: Sat, 06 Dec 2008 00:10:31 +0000

Greg,

Your suggestion would preclude the use of Autokey. Even if this is 
acceptable, the 16-bit key space is already too small to partition.

Dave

Greg Dowd wrote:

>>>>allow a change in the protocol, then simply make the MAC field
>>>>        
>>>>
>variable
>  
>
>>>>>>Publish my list? At the top is work for JPL on time
>>>>>>            
>>>>>>
>synchronization
>  
>
>>>>>>The work to bring up a 20-octet digest is messy. In principle it
>>>>>>            
>>>>>>
>is
>  
>
>>>>>>easy, as the required crypto code is already available in OpenSSL
>>>>>>            
>>>>>>
>and
>  
>
>>>>>>the NTP crypto interface is the same. However, the ick comes in
>>>>>>            
>>>>>>
>the
>  
>
>>>>>>For instance, the OPENSSL define is lit when the OpenSSL library
>>>>>>            
>>>>>>
>is
>  
>
>>>>>>only HMAC and don't want Autoke, that has to change. Also, it
>>>>>>            
>>>>>>
>could
>  
>
>>>>>>OpenSSL library and passed transparently by th econfiguration
>>>>>>            
>>>>>>
>code..
>  
>
>>>>>>approach would be to allow keys of any length independent of
>>>>>>            
>>>>>>
>digest
>  
>
>>>>>>>ASAP. On the other hand, you say that the design has provisions
>>>>>>>              
>>>>>>>
>to
>  
>
>>>>>>>I would like to suggest that you publish your list and provide
>>>>>>>              
>>>>>>>
>the
>  
>
>>>>>>>notes you have on the line items. The beauty of open source is
>>>>>>>              
>>>>>>>
>that
>  
>
>>>>>>>eventually happen, although not necessarily in your priority
>>>>>>>              
>>>>>>>
>order.
>  
>
>>>>>>>Their are hands available to you Dave, if you would just allow
>>>>>>>              
>>>>>>>
>them
>  
>
>>>>>>>to help.
>>>>>>>
>>>>>>>
>>>>>>>David L. Mills wrote:
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>Manav,
>>>>>>>>
>>>>>>>>
>>>>>>>>previously, there are already provisions for that in the design
>>>>>>>>                
>>>>>>>>
>to
>  
>
>>>>>>>>suppor that. However, in the wisdom of good engineering design
>>>>>>>>                
>>>>>>>>
>and
>  
>
>>>>>>>>If your point is that NIST says SHA is good and MD5 is bad based
>>>>>>>>                
>>>>>>>>
>on
>  
>
>>>>>>>>digest with a contrived but necessarily invalid NTP message,
>>>>>>>>                
>>>>>>>>
>then I
>  
>
>>>>>>>>analysis. This point is stressed in the course I teach on
>>>>>>>>                
>>>>>>>>
>computer
>  
>
>>>>>>>>security.
>>>>>>>>
>>>>>>>>
>>>>>>>>Dave
>>>>>>>>
>>>>>>>>
>>>>>>>>>octets (unless somebody is thinking of truncating the SHA hash
>>>>>>>>>                  
>>>>>>>>>
>:))
>  
>

---

From: Danny Mayer <[email-masked]>
Date: Fri, 05 Dec 2008 22:02:57 -0500

> For all extension fields now defined the minimum extension field length 

This won't work since each digest algorithm will give a different digest
output and you should not assume that the length is sufficient to tell
you the difference. You actually need different id's for each digest
algorithm.

Danny

---

From: "David L. Mills" <[email-masked]>
Date: Sat, 06 Dec 2008 14:46:30 +0000

Danny,

I don't understand your objection. There already is a different NID for 
each algorithm and a matching ASCII string defined in the OpenSSL 
library. In the scheme I proposed the operator selects NIDs for 16-octet 
or 20-octet digests or both. Normally the client would select one 
16-octet MD5 and one 20-octet SHA or whatever as defaults. The server 
would select either based on the client request digest size and reply 
with the same NID. This is the same paradigm as selecting the version 
number when replying to a client request.

The scheme I suggested is a natural extension, providing multiple NIDs 
when more than one NID for each digest size is available. Most operators 
not care to use it, but it would support a more complicated setup should 
some diversity remain in the digest proponent community.

Dave

---

From: Danny Mayer <[email-masked]>
Date: Sun, 07 Dec 2008 11:51:28 -0500

> number when replying to a client request.

What I mean is that the ID's need to be specific algorithm identifiers,
that's all. SHA-1 comes in different flavors and strengths, for example.
The protocol just needs to understand what the specific algorithm is. I
have no problem with the rest.

Danny

---

From: "David L. Mills" <[email-masked]>
Date: Thu, 11 Dec 2008 13:39:13 +0000

Danny,

I repeat. Whatever is in OpenSSL, specifically the NID for each 
algorithm, is transparent and NTP could in principle support any of them.

Dave

---

From: "Greg Dowd" <[email-masked]>
Date: Thu, 11 Dec 2008 07:46:35 -0800

I'm not quite following this proposal. If the client gets to choose an
algorithm to associate with a particular digest size, how would the
server know which one was chosen.  The example of version is an invalid
case as version is transferred in the frame.  Where would NID be
transferred?  Also, is NID proprietary to OpenSSL?  If it human readable
for config file usage?  If these are issues, wouldn't we rather select
by ISO OID?  Not that I'm saying that is legible.

-----Original Message-----
From: ntpwg-bounces+gdowd=[email-masked]
[mailto:ntpwg-bounces+gdowd=[email-masked]] On Behalf Of
David L. Mills
Sent: Thursday, December 11, 2008 5:39 AM
To: [email-masked]
Subject: Re: [ntpwg] Stronger symmetric NTP authentication

Danny,

I repeat. Whatever is in OpenSSL, specifically the NID for each 
algorithm, is transparent and NTP could in principle support any of
them.

Dave

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 12 Dec 2008 00:51:07 +0000

Greg,

My proposal was not intended to be a generic solution, but rather a 
practical approach that would work in most cases without rewriting the 
protocol and causing version warp. Most would agree that, if the digest 
is 16 octets, the only reasonable choice is MD5. Most would agree on a 
common denominator for a 20-octet digest, but I won't hazard which at 
this time. My orginal proposal was for the client to keep an 
individually configured list of NIDs and use them in round-robin order 
if a MAC fails. This assumes only a small number of choices are 
available for the servers.

Save fancier schemes for some future NTP protocol rewrite. Frankly, I 
don't see the wisdom of a backwards incompatible protocol rewrite if the 
only reason is to provide completely general selection of algortihm.

I don't know if the OpenSSL NID conforms to the ISO or not, but from a 
practical standpoint it doesn't matter. I and those appl;ication 
developers known to me use the OpenSSL library because it is freely 
available, not ITAR vulnerable and the NID selection is on the basis of 
a printable ASCII string as a configuration parameter. The use of some 
other library with incompatible interface or different string mappings 
or ITAR vulnerable is simply not in the cards.

Dave

Greg Dowd wrote:

>>>I don't understand your objection. There already is a different NID
>>>      
>>>
>for 
>  
>
>>>library. In the scheme I proposed the operator selects NIDs for
>>>      
>>>
>16-octet 
>  
>
>>that's all. SHA-1 comes in different flavors and strengths, for
>>    
>>
>example.
>  
>
>>>when more than one NID for each digest size is available. Most
>>>      
>>>
>operators 
>  
>
>>>not care to use it, but it would support a more complicated setup
>>>      
>>>
>should 
>  
>
>>>>>The new interleaved modes aren't in the specification either.
>>>>>          
>>>>>
>However, 
>  
>
>>>>>servers and clients automatically back out of these modes if the
>>>>>          
>>>>>
>server 
>  
>
>>>>>transparent. The current development version supporting these modes
>>>>>          
>>>>>
>is 
>  
>
>>>>>on all our public and private servers and clients. Yes, it is in the
>>>>>          
>>>>>
>web 
>  
>
>>>>>document collection and further described in the white paper on the
>>>>>          
>>>>>
>NTP 
>  
>
>>>>>Project Page.
>>>>>
>>>>>A similar thing can be done for 20-octet digests. The original plan
>>>>>          
>>>>>
>for 
>  
>
>>>>>this was formulated several years ago. The parsing rules  provide
>>>>>          
>>>>>
>for 
>  
>
>>>>>8-octet (DES), 16-octet (MD5) and 20-octet (SHA) digests. This does
>>>>>          
>>>>>
>not 
>  
>
>>>>>change the specification other than to require extension fields to
>>>>>          
>>>>>
>have 
>  
>
>>>>>a minimum of two 32-bit words with 16-octet digests. A simple
>>>>>          
>>>>>
>extension 
>  
>
>>>>>The parsing rules detect the digest as a function of the number of
>>>>>          
>>>>>
>words 
>  
>
>>>>>For all extension fields now defined the minimum extension field
>>>>>          
>>>>>
>length 
>  
>
>>>>>is two words.
>>>>>  
>>>>>
>>>>>       
>>>>>
>>>>>          
>>>>>
>>>>This won't work since each digest algorithm will give a different
>>>>        
>>>>
>digest
>  
>
>>>>output and you should not assume that the length is sufficient to
>>>>        
>>>>
>tell
>  
>
>>>>>The interoperability and configuration rules are proposed as
>>>>>          
>>>>>
>follows:
>  
>
>>>>>A host is configured to support specified algorithms for both 16-
>>>>>          
>>>>>
>and 
>  
>
>>>>>20-octet digests. This includes all algorithms supported by the
>>>>>          
>>>>>
>OpenSSL 
>  
>
>>>>>Where NID is consistent with OpenSSL NIDs used in the crypto
>>>>>          
>>>>>
>command. 
>  
>
>>>>>There can be one NID or several in a circular list. The digest size
>>>>>          
>>>>>
>is 
>  
>
>>>>>implicitin the NID. The client and symmetric peer maintains a
>>>>>          
>>>>>
>pointer 
>  
>
>>>>>to the current NID. When a digest arrives, the first NID with
>>>>>          
>>>>>
>matching 
>  
>
>>>>>digest size is used for subsequent packets. In case of crypto NAK,
>>>>>          
>>>>>
>the 
>  
>
>>>>>principle, the list could be populated with all OpenSSL digest NIDs
>>>>>          
>>>>>
>and 
>  
>
>>>>>a caller with any of them would clank around until a matching pair
>>>>>          
>>>>>
>was 
>  
>
>>>>>found.
>>>>>
>>>>>Operation with a stateless server with lots of clients would be
>>>>>          
>>>>>
>somewhat 
>  
>
>>>>>would be one NID for 16-octet digests and another for 20-octet
>>>>>          
>>>>>
>digests. 
>  
>
>>>>>The server would select either depending on the client request and
>>>>>          
>>>>>
>use 
>  
>
>>>>>Note the digest size determines the size of the key material
>>>>>          
>>>>>
>prepended 
>  
>
>>>>>similar operation has not been defined for digests other than MD5,
>>>>>          
>>>>>
>but 
>  
>

---

From: Danny Mayer <[email-masked]>
Date: Tue, 30 Dec 2008 00:15:24 -0500

> as against plain MD5 that the spec mandates. 

The basic flaw in this argument is the assumption that MD5 is being used
for authentication. It isn't. It is only used to verify that the packet,
including the autokey information has not been modified in transit (or
spoofed). In many ways this is no different from a checksum. MD5 is only
being used as a digest, not an authentication mechanism. There are
enough bits in the packet to make the nonce effectively unspoofable. NTP
will drop a packet that does not meet the series of tests that ensure
that the packet is valid. You are endowing the MAC with attributes that
don't actually exist.

Danny

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 30 Dec 2008 10:53:33 +0530

> for authentication. It isn't. It is only used to verify that 

Yes Danny, I know that :-)

Two sides using MD5 can only arrive at the same digest if they use the same key. If the keys are different then the digest would differ, and the message would get dropped. The fact that one side is able to compute the same digest with its key, kind of "authenticates" that the original message was indeed sent by the router that shares the same key. 

Now, reread my original mail and see if you have problems parsing it.

Cheers, Manav

> the packet,

---

From: Danny Mayer <[email-masked]>
Date: Tue, 30 Dec 2008 00:57:13 -0500

Bhatia, Manav (Manav) wrote:
> Two sides using MD5 can only arrive at the same digest if they use
> the
same key. If the keys are different then the digest would differ, and
the message would get dropped. The fact that one side is able to compute
the same digest with its key, kind of "authenticates" that the original
message was indeed sent by the router that shares the same key.

No, autokey is used for authentication and it doesn't use MD5.

> Now, reread my original mail and see if you have problems parsing it.

No, you didn't understand what I said. You need to reread my message.

Danny