Subject: [TICTOC] security ID submitted for review

From: "David L. Mills" <[email-masked]>
Date: Thu, 01 Aug 2013 20:42:08 +0000

Guys,

Here are some general comments on the ID.  I apologize if they are a 
little rough as I have to dictate this message instead of my usual 
polished wordsmithing.

format.
The ID does not specify an extension field format.  Presumably, the 
extension field format described in RFC 5906 is adequate with new 
message types as required.  However, in keeping with long Internet 
tradition, it must be possible to determine correct format without 
interpreting the header or extension fields.  In addition, it must be 
possible to verify message integrity without interpreting the extension 
fields.  In particular, the private key for the message authentication 
code (MAC) , if used, must be known beforehand.  This is where the 
"cookie snatcher" issue comes up as described in previous messages.  In 
particular, an important constraint for normal operation is that 
extension fields are not used unless required for cookie determination.

Glaring vulnerability exists when using extension fields, as the key 
value is public and must be known in advance.  This invites a 
cut-and-paste attack, as well as header changes, even if subsequently 
detected by the on-wire protocol.

certificate.
Both RFC 5906 and the ID require the server certificate.  The server 
certificate can be conveyed, either off-line, or directly or indirectly 
via a certificate trail as described in RFC 5906 or the ID.  If obtained 
via the trail, there is a hazzard due to a middle-man attack and 
masquerade.  A solution proposed in RFC 5906 uses an identity scheme 
such as IFF.  There may be an equivalent, or better schemes available now.

protocol.
Most of the discussion following the ID announcement is from protocol 
weenies, affectionately known as protomeister.  When the Autokey scheme 
was first defined in 1996,  the signature time required ranged up to one 
second on the computers of the time.  Therefore, a clogging hazzard 
existed in the form of  a replay attack.  This is why the timestamp was 
included in the extension field format to suppress duplicates.  Most of 
the extension fields were computed and signed off-line.  Nevertheless, a 
clogging vulnerability remains in the cookie request message.  This 
requires the server to do two public key incriptions and two hash 
functions. Today, this overhead may no longer  be considered  excessive; 
however, this may not be true for public time servers with thousands and 
thousands of clients.

In broadcast mode, the protocols described in RFC 5906 and the ID are 
messy and with several possible vulnerabilities.  Here is a suggestion 
that might be useful.  Define a new broadcast packet format as the NTP 
header followed by one extension field representing the MAC.  The 
extension field represents the signature of the header computed using 
the private key of the server and can be verified by the client using 
the public key in the server certificate.  Originally, this was 
considered an unacceptable dilution of accuracy due to the variability 
of the signature computing time and the length of the signature.  
However, at least in modern NTP, the interleaved broadcast mode can be 
used to correct for this overhead.  This assumes that the overhead for 
either the server or client is reduced using fast modern processors.

As mentioned previously, in NTP symmetric mode the current protocol in 
RFC 5906 should be changed to use Diffie-Hellman key agreement.  This is 
so easy to do that it can be incorporated separately in the standard.

While the interleaved mode is useful in symmetric and broadcast modes, 
it can't be used when the server does not maintain state separately for 
each client.  However, as in the orginal NTP design many years ago, the 
output delay can be computed for each transmitted server packet.  The 
output delay can be averaged and used to augment  the transmit timestamp 
or retrieve using an extension field.

Note that this message does not address the cookie snatcher issue 
discussed by our German protomeisters, who have concocted a brillient 
solution.  Many of the issues discussed are relevant to both NTP and 
PTP, although the on-wire protocol details may be different.  I hope 
this discussion is useful in either context.

Dave

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 3 Aug 2013 19:40:08 +0200

On Thu, Aug 01, 2013 at 08:42:08PM +0000, David L. Mills wrote:
> The ID does not specify an extension field format.

The draft only seems to specify the the general idea of how it
should work and doesn't seem to go into detail how this should
work at the protocol level.  I assume he first wants to know if
the solution is something that can work and that others see
as a good solution before he works out the details.

> In particular, the private key for the message
> authentication code (MAC) , if used, must be known beforehand.  This
> is where the "cookie snatcher" issue comes up as described in
> previous messages.  In particular, an important constraint for
> normal operation is that extension fields are not used unless
> required for cookie determination.

I'm not sure I understand your remark.  As far as I know the
"cookie snatcher" you talk about is the normal "man in the middle"
attack.  As I understand we would change the verification by
replacing it by the normal X.509 verification as done for instance
SSL/TLS.

I assume you meant public key and note private key.

> cut-and-paste attack, as well as header changes, even if
> subsequently detected by the on-wire protocol.

I've seen this cut-and-paste attack mentioned before, but I've
never really understood it.  As I understand things, the MAC
is generated over the NTP + extensions.  I don't see how you
can take the extension from 1 packet into an other and still
have a valid MAC.  Or are you saying that you do something
with a packet even when it doesn't have a valid MAC?

> certificate can be conveyed, either off-line, or directly or
> indirectly via a certificate trail as described in RFC 5906 or the
> ID.  If obtained via the trail, there is a hazzard due to a
> middle-man attack and masquerade.

I really don't understand how such a man in the middle attack
can work.  Either the certificate + the chain validate, or they
don't.  It is of course important to you check that the CommonName
in the certificate matches the server you're trying to reach,
and that the root CA is in your list of trusted CAs.  But there
really isn't anything new or hard about this.

> In broadcast mode, the protocols described in RFC 5906 and the ID
> are messy and with several possible vulnerabilities.  Here is a
> suggestion that might be useful.  Define a new broadcast packet
> format as the NTP header followed by one extension field
> representing the MAC.  The extension field represents the signature
> of the header computed using the private key of the server and can
> be verified by the client using the public key in the server
> certificate.  Originally, this was considered an unacceptable
> dilution of accuracy due to the variability of the signature
> computing time and the length of the signature.  However, at least
> in modern NTP, the interleaved broadcast mode can be used to correct
> for this overhead.  This assumes that the overhead for either the
> server or client is reduced using fast modern processors.

I think that in all cases where it's no problem to keep track of
all clients you should use the interleaved mode, and we can use
something like the Diffie-Hellman key agreement for those.

But there clearly is also a need for servers that can't keep
the state of each client, and we need something else for that.
So maybe we need to define 2 ways of working.

Kurt

---

From: "David L. Mills" <[email-masked]>
Date: Wed, 07 Aug 2013 01:01:47 +0000

Kurt,

Thanks for your reply.  As a window of history, the Autokey protocol was 
devised during several walks in Regents Park, London, in 1996.  I 
thought the most significant hazzard was the replay of client messages 
requiring extensive server cryptographic computations.  At that time, I 
did not think that a middle-man attack would be significant.  Both of 
those assumptions are probably inadvisable today. 

One problem with Autokey is the assumption that secret keys for each 
client can be manufactured using packet header fields and a hash of a 
server private value.  A middle-man can manipulate the header fields 
compromising the client private key.  There does not seem to be a 
solution for this problem other than requiring server state.

There are two problems with requiring a server state variable associated 
with each client.  The first is how to reliably match the server state 
with the client packet.  For public time servers with thousands of 
clients, the storage of something like a client certificate for each 
client could be prohibitive.  The storage could be dynamically allocated 
as a field in the MRU list maintained in the current NTP implimentation; 
however, the MRU list for several hundred entries has a lifetime of only 
15 seconds, at NIST, for example. 

In the current Autokey design, the MAC computation covers the header and 
all extension fields.  However, the key used for the MAC computation in 
packets with extension fields is not private.  Therefore, in a 
cut-and-paste attack, an intruder could mix and match extension fields 
and simply recalculate the MAC. 

RFC 5906 defines the extension field including the filestamp and 
timestamp.  The filestamp was designed to reliably associate the 
cryptographic media with the current version, as it can be frequently 
changed.  This might not be useful in current designs.  The timestamp 
field was designed to detect replays requiring expensive cryptographic 
computations which could take up to a second.  However, the "call gap" 
(minimum headway) provisions nicely deflect such attacks, so the 
timestamp field might not be useful in current designs.   Lastly, in the 
current design, each extension field is separately signed  at the time 
the data were constructed.  In current designs the signature might be 
computed at the time of transmission.

The more I think of it, the better I like a design where the existing 
MAC is replaced by a single extension field computed as the signature of 
the header.  I previously suggested this for broadcast mode, but I think 
this could be useful in other modes as well.  It would be hightly 
interesting to determine the overhead for such a signature using modern 
processors.  An experiment could be designed for the current NTP 
implementation.  It would consist of an adaptor routine that matches an 
OpenSSL signature routine to the authencrypt/authdecrypt interface 
routine.  I would do this myself, but with my current vision condition, 
it would not be practical.  For someone with knowledge of the NTP 
programming style, this would be an interesting weekend project.

In theis proposed design a busy server could be presented with thousands 
of signed client requests, each requiring  a signed server response.  
However, the server might ignore the client request signature on the 
expectation that the  server response could be reliably determined.  
Actually, the NTP on-wire protocol is very good for this.  As an aside, 
the protocol analysis and simulation described in the white paper at the 
NTP project page could be done for PTP as well.

Dave

---

From: Kurt Roeckx <[email-masked]>
Date: Wed, 7 Aug 2013 12:23:24 +0200

Hi Dave,

On Wed, Aug 07, 2013 at 01:01:47AM +0000, David L. Mills wrote:
> Kurt,
> 
> Thanks for your reply.  As a window of history, the Autokey protocol
> was devised during several walks in Regents Park, London, in 1996.
> I thought the most significant hazzard was the replay of client
> messages requiring extensive server cryptographic computations.  At
> that time, I did not think that a middle-man attack would be
> significant.  Both of those assumptions are probably inadvisable
> today.
> 
> client can be manufactured using packet header fields and a hash of
> a server private value.  A middle-man can manipulate the header
> fields compromising the client private key.  There does not seem to
> be a solution for this problem other than requiring server state.

This proposal also generates a cookie based on the something the
client sends and a secret in the server, which is then encrypted
using the client's public key.

The ID does not mention that this message is signed by the server,
but Stephen's mail said it was.  This part is important to avoid
the man in the middle attack.

So as result the client got a unique secret for him, and only
the client and the server known it.  It can also be sure that
it really comes from the server, so that there can be no man
in the middle attack.  And the server doesn't need to keep
state since it can calculate it again based on what the client
sends him.

> In the current Autokey design, the MAC computation covers the header
> and all extension fields.  However, the key used for the MAC
> computation in packets with extension fields is not private.
> Therefore, in a cut-and-paste attack, an intruder could mix and
> match extension fields and simply recalculate the MAC.

If the key is not private, by adding extentions to a packet an
attacker can just generate anything he wants?

> cryptographic media with the current version, as it can be
> frequently changed.  This might not be useful in current designs.
> The timestamp field was designed to detect replays requiring
> expensive cryptographic computations which could take up to a
> second.  However, the "call gap" (minimum headway) provisions nicely
> deflect such attacks, so the timestamp field might not be useful in
> current designs.   Lastly, in the current design, each extension
> field is separately signed  at the time the data were constructed.
> In current designs the signature might be computed at the time of

I'm not sure I understand what you're trying to say.

I'm not sure what the filestamps are used for.  But I assume
that for instance for the leap seconds you send when it was
last updates.  I guess you can sign this once and always send
this signed in an extension, even when you're otherwise not
using any encryption.  Since you already signed it, the overhead
of adding that extension is small.

The problem I see with only sending the MAC over the ntp headers
and not over the extensions is that the extensions can be removed
or added and the client can't tell.  So it could for instance
be replaced with an old version of the extension. I think it's
important that the MAC covers everything.

Kurt

---

From: Kurt Roeckx <[email-masked]>
Date: Wed, 7 Aug 2013 13:45:30 +0200

> important that the MAC covers everything.

You could of course also add a timestamp indicating when the
signature of the extension expires.  I think we should do
that in any case.

Then I'm not sure if there is still a need to to sign the
whole packet.  Can all extensions be signed? Is there a
need to sign them all?

Kurt

---

From: [email-masked]
Date: Wed, 7 Aug 2013 14:19:33 +0200

Hello Dave and Kurt,

thanks for your comments:

As Kurt already pointed out. Currently the ID specifies only the design of 
the security protocol. We believe that we need to be clear about the 
design questions before specifying the technical details. 

The private key of the client is not needed for the MAC. Instead the 
calculation of the MAC includes the cookie and the whole NTP packet (i.e. 
the extension fields also). The cookie is calculated from the server seed 
and the client's public key, which the client attaches to each time 
request (which requires a new extension field as pointed out in the 
draft). During cookie exchange the server encrypts the cookie with the 
client's public key before transmission. An adversary is therefore not 
able to abuse a cookie which he requests in behalf of the client. 

As Kurt pointed out the certificate exchange works as in a standard PKI. I 
emphasize that this is different to autokey. In autokey the chain of trust 
and time are equal whereas in this ID chain of trust and time might be 
disjunct.

Regarding the broadcast mode. I agree with Dave that the use of TESLA for 
the broadcast mode adds additional complexity.  It also has the 
disadvantage that the authenticity of a packet can only be verified in 
retrospect. But I don't see security vulnerabilities. Dave's suggestion to 
use a combination of interleave mode with asymmetric cryptography is 
interesting. We should consider this. The argument that asymmetric 
cryptography might be feasible because of modern power of CPUs is okay for 
traditional computer systems but I'm not sure whether this assumption also 
applies for small devices with constrained resources. 

Regards
Dieter

----------------------------------
Physikalisch-Technische Bundesanstalt
Dr. Dieter Sibold
Q.42 - Serversysteme und Datenhaltung
QM-Verantwortlicher der Stelle IT-Infrastruktur
Bundesallee 100 
D-38116 Braunschweig
Tel: +49-531-592-84 20
E-Mail: [email-masked]

Von:    Kurt Roeckx <[email-masked]>
An:     "David L. Mills" <[email-masked]>
Kopie:  NTP Working Group <[email-masked]>, "[email-masked]" 
<[email-masked]>
Datum:  03.08.2013 20:04
Betreff:        Re: [ntpwg] security ID submitted for review
Gesendet von:   ntpwg-bounces+dieter.sibold=[email-masked]

Kurt

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

---

From: [email-masked]
Date: Wed, 7 Aug 2013 14:45:18 +0200

Hello Kurt,

thanks for your comments. Your are right that the draft currently does not 
specifies that the server has to sign the message during cookie message 
exchange. We shall add this to the next version of the draft.

Dieter

Datum:  07.08.2013 12:23

Hi Dave,

Kurt

---

From: Kurt Roeckx <[email-masked]>
Date: Wed, 7 Aug 2013 17:16:37 +0200

> really isn't anything new or hard about this.

So thinking about this so more, I do see 1 problem with this.  I
would like to be able to use this for the pool for those that wish
to use it.  But if you're verify the certificate you're not going
to know which server you're talking too, so there is no way to
check the CommonName.  Does it make sense to just skip this
check in case of the pool?

Kurt

---

From: "David L. Mills" <[email-masked]>
Date: Tue, 13 Aug 2013 15:10:07 +0000

[email-masked] wrote:

> Dieter,

There are several minor points I might mention.  First the easy ones.  
You mentioned TESLA , which sound very much like the existing Autokey in 
broadcast mode.  Actually, the Autokey scheme was stolen from S-KEY of 
many years ago.   I still think this should all be replaced by a 
signature using the server public key. This is complicated in the case 
of multiple broadcast servers implemented in the same system.  In these 
cases,  the network delay calibration might be different, as is the case 
in the current NTP implementation. In order to support this requirement, 
the extension field for the broadcast message needs to include the 
process ID for the broadcast association.  The process ID is used for 
the particular security protocol in the delay calculation.  Other means 
might be devised in the new protocol to perform this function.

For client/server and symmetric modes, I suggest the following design 
candidate.  This would be appropriate for national time servers operated 
by NIST , USNO and NRC.  A certain number of these servers currently 
support symmetric key verification, where each key is chosen for each 
subscriber upon payment of a fee.  For instance, NIST has over 25 
million clients of their public servers, and where probably several 
million use the bolder complex with no cryptographic support.  One 
machine includes support for symmetric key cryptography, so probably 
several hundred different keys could be supported. 

Symmetric key cryptography becomes unwieldy when the number of customer 
clients much exceeds this number.  An alternative design using public 
key cryptography might be more appropriate.  This design would use 
Diffy-Hellman key agreement.  The client would send the public value to 
the server signed by the client public key.  The server would respond 
with its public value signed by the server public key.  The agreed key 
for both the client and server would be split in two portions, the 
32-bit key identifier and a 160-bit symmetric key.  Both the client and 
the server would save the values in the same data structure used for 
static symmetric keys.  Subsequently, operation would continue as in 
ordinary static symmetric keys. 

The devil is in the details.  The server needs a table with entries 
corresponding to the client IP address and certificate. This is what the 
subscriber pays for.  Additional provisions are necessary to time out 
old keys and regenerate accordingly. 

This scheme avoids the use of extension fields in all cases except when 
a new agreement is negotiated.  A question remains on whether the 
sgreement messages are to be authenticated by other than the agreed key 
itself.  My suggestion is simply to avoid this step on condition that 
the NTP header time values are ignored. 

My experience over 17 years operating experiment configurations on up to 
17 different machines running various combinations of unsecured 
symmetric and public key combinations suggests that the supporting 
infrastructure is of serious concern.  For one thing, certificate 
lifetimes are meaningless until the correct time has been verified.  
There is no a-priori assumption about the certificate lifetimes other 
than a continuous trail, possibly spanning several intermediate 
servers,   Consider the effect of replacing a public/private key when a 
server fails and is replaced.  Consider what happens when an 
intermediate server rolls a new certificate which interupts  the trail 
continuity.  Remember, a typical NTP client runs multiple servers, each 
of which might have a different trail to the same server or servers.  A 
large crop of obscure interworking issues have been found and corrented 
over the years.  I suspect similar issues and corrections will be found 
in PTP applications.

The particular set of rules and constraints described in previous 
reports and RFC 5906 were constructed with great care.  They established 
the security model and partial-order precidents relations considered at 
a meeting of computer science theorists and myself at the Dagstuhl 
(Germany) meeting in 1996.   The rules require that all security changes 
conform to Lamport's "happens before" relation.  The filestamps and 
timestamps described in RFC 5906 conform to these rules.  Unfortunately, 
to my knowledge, current applications do not necessarily conform to 
these rules.  It may be a lost cause to incorporate these rules in new 
NTP or PTP protocols and applications.

I hope these comments are useful in the evolution of NTP and PTP 
security protocols.

Dave

> As Kurt already pointed out. Currently the ID specifies only the 
> design of the security protocol. We believe that we need to be clear 
> about the design questions before specifying the technical details.
>
> calculation of the MAC includes the cookie and the whole NTP packet 
> (i.e. the extension fields also). The cookie is calculated from the 
> server seed and the client's public key, which the client attaches to 
> each time request (which requires a new extension field as pointed out 
> in the draft). During cookie exchange the server encrypts the cookie 
> with the client's public key before transmission. An adversary is 
> therefore not able to abuse a cookie which he requests in behalf of 
> the client.
>
> As Kurt pointed out the certificate exchange works as in a standard 
> PKI. I emphasize that this is different to autokey. In autokey the 
> chain of trust and time are equal whereas in this ID chain of trust 
> and time might be disjunct.
>
> Regarding the broadcast mode. I agree with Dave that the use of TESLA 
> for the broadcast mode adds additional complexity.  It also has the 
> retrospect. But I don't see security vulnerabilities. Dave's 
> suggestion to use a combination of interleave mode with asymmetric 
> cryptography is interesting. We should consider this. The argument 
> that asymmetric cryptography might be feasible because of modern power 
> of CPUs is okay for traditional computer systems but I'm not sure 
> whether this assumption also applies for small devices with 
> constrained resources.
>
> Regards
> Dieter
>
>
> Kopie:        NTP Working Group <[email-masked]>, 
> "[email-masked]" <[email-masked]>
> Datum:        03.08.2013 20:04
> ------------------------------------------------------------------------
>
>
>