Subject: [ntpwg] autokey3

From: "David L. Mills" <[email-masked]>
Date: Thu, 23 Jun 2016 12:58:02 -0400

Folks,

I designed and implemented the Autokey security scheme over twenty years 
ago, but time and Moore's law have
 caught up to it. Back then, it took 10 seconds to calculate the shared 
key in the Diffie-Hellman algorithm.
This message outlines a proposed replacement for it.The scheme is based 
on the Diffie-Hellman agreement algorithm which
 results in an economical implementation and running time.This message 
suggests a variant of this algorithm popularly known
as the Station to Station protocol. As my eyesight has severely limited 
my capability to implement the code, I leave
this to others.

backwards compatibility

 It is necessary that the current symmetric keys model and NTP modes, 
including client server, symmetric,
 broadcast and interleave modes, be preserved.  The existing symmetric 
key design must be preserved, including the keys
 file, MAC and hash algorithm. It is not necessary to preserve the 
current Autokey  scheme, although some elements of this
 scheme remain in the proposal.

infrastructure

The fundamental principle in the Autokey design is that no explicit 
infrastructure other than the base network is necessary.
 This means that neither DNS nor certificate validation infrastructure 
is available. Since certificates cannot be authenticated by
 outside means, there is a possibility of a middleman attack where the 
attacker inJects its certificate on the chain leading to
the self-signed certificate authority. There are optional means to 
verify the certificate chain using the identity exchange.
 Other means to do this may be devised as well.

 As aside, ASN.1 encoding of Autokey extension fields  is probably not a 
good idea.  All Autokey extension fields have
 only integer encoded values. Only one of many Autokey messages has more 
than one extension field. The additional complexity of
ASN.1 is not justified, especially in the case of embeded systems.

diversity

In the current architecture the time and security operations proceed 
independently and simultaneously for all
 associations; however, the on-wire protocol protects against most 
attacks as described below. Security for all associations
 is managed seperately. The actual associations selected are managed by 
the Byzantine, intersection  and clustering  algorithms.
 It does not seem feasible to "loosly synchronize" the system clock with 
this design.

access control

 The current reference implementation includes access controls in the 
form of bit permissions and rate
 management parameters. There is no need for additional access control 
function in the cryptographic dance.

The transmit timestamp and loopback test of the underlying on-wire 
protocol protects against lost or duplicate packets, and
protocol restarts, but not middleman attacks. The on-wire protocol  
mitigates against attacks on the cryptographic means as well.

The security model can be summarized as follows:

When an NTP packet arrives, the first thing is to verify the packet 
format, in particular, the extension
 field lengths, if present.

The second is to verify content, in particular, the packet MAC, and hash.

The third step is to verify contents consistent with the on-wire 
protocol. This filters out bogus, duplicate
 and missing packets, as well as detects protocol restarts.

If there is an Autokey dance running, the protocol continues as 
described below.   

two-way issues
 
In broadcast mode it is necessary that a two-way path  be available in 
order to calculate  the roundtrip delay between
 the broadcast server and the client. The NTP specification  does not 
require a two-way path, so it might not be
possible to calculate the roundtrip delay or retrieve any other server 
data. This  means that protocols such as Tesla might
 not work properly.

performance

In the original design, the maximum hash size was 20 octets. It is not 
generally useful to provide larger hash sizes.
 For example, SHA160 is a 20-octet truncated version of SHA256. Other 
hash algorithms can be truncated as well.

protocol basics

The basic protocol dance consists of a parameter exchange followed by a 
recursive certificate exchange to cache the
certificates on the trail to the self-signed certificate authority. The 
cache is shared by all associations. Certificates
 are retrieved by subject name. This is followed by the cookie exchange 
and optional identity exchange. These exchanges
 use NTP messages including extension fields as necessary. The following 
dance is determined by the NTP mode client/server,
symmetric and broadcast. The parameter, certificate and identity  
exchanges are identical for client/server, symmetric and optional
broadcast delay measurement, if used. The parameter exchange includes 
the subject name of the certificate, as well as the
 signature scheme. This makes it awkward if the signature scheme is 
different for each certificate. In any case, the
encryption algorithm can be specified in the parameter exchange.

symmetric  mode

The goal of this dance is to install identical shared hash keys in both 
peers.  Alice and Bob use generator g and large prime p as modulus.
These are public values available to all participants. Alice and Bob 
separately generate large random numbers mod p used as their
private DH key, respectively. The  generator g raised  to the private DH 
keys  as the exponents are the  public DH keys. The public DH key
of one participant raised to the private  DH key of the other 
participant is the shared DH key. Alice sends her public DH key in
an extension field of an Autokey message. Bob constructs the shared DH 
key and sends his public DH key in an extension field of an
Autokey message. Bob then sends his signature of the shared DH key to 
Alice in a second extension field in the same message.  Alice receives
Bob's public DH key and constructs the shared key and verifies Bob's 
signature. The shared key constructed by Alice and Bob is used as the
hash key in subsequent messages. Finally, Alice sends her signature of 
the shared key to Bob for verification. The public and
private DH keys are expunged after use; they are used only once.

client server mode

The goal in this mode is to install a secret client cookie. The cookie 
is  used as the hash key. The cookie can be
regenerated by the server upon arrival of a client packet. Operation in 
this mode is similar to symmetric mode, except the server
keeps no state. Client Alice sends her public DH key in an extension 
field of an Autokey message to server Bob. Bob generates his private
DH key and then the public DH key. He then constructs the  shared DH  
key as described above. Alice and Bob use the shared
 DH key as the  encription key used later. The cookie is the hash of the 
IP address of the client  concatenated with   the secret key using
 the selected hash algorithm.  The secret key is a random number 
regenerated about once per day. Bob sends his public DH key in   an
 extension field of an Autokey message. Bob then sends the encrypted  
cookie to Alice in another extension  field. He sends the
signature of the  cookie to Alice in a third extension field. Alice then 
constructs the shared DH key and decrypts  the cookie  
using Bob's message and the shared key as decryption key. Finally, she 
verifies Bobs signature of the cookie.

broadcast mode

The original Autokey protocol was based on the assumption that the 
cryptographic algorighms were very slow and vulnerable to
a flooding attack. In fact, the Diffie-Hellman agreement took over 10 
seconds on a Sun IPC. As current machines and algorighms are
much faster, it is convenient for the server to compute the signature of 
the NTP header in an extension field and the client verify
 the signature using the   public key on the  server certificate. The 
certificate must be installed in each client.

security brief

once the Autokey dances have left the stage, the result is an agreed 
hash key. The hash key is used to construct the hash for the
 MAC and the key ID. The key ID of the MAC is coded to distinguish 
Autokey keys from table  keys. The cryptographic strength is
 equivalent to a table key. If a hash failure is detected or a signature 
has failed, the receiver sends a crypto NAK, which causes
 the sender to restart the protocol. Ordinarily, a MAC is not used for 
Autokey messages so these messages may be threatened.
 The cryptographic strength of the Autokey dance is something else. The 
parameter exchange includes the subject name on the
 certificate, which is the first one retrieved in the certificate 
exchange. The parameter and certificate exchanges result in  
no change to the server or peer. A hostile intruder can toss fake values 
without effect on the state of the receiver. Attacks on the
cookie exchange values are a different effect. Errors in the signatures 
result in a protocol restart. Note that the original
 Autokey keys and certificate applications continue to work with the 
proposed scheme.

implementation suggestions

Judging from development experience, tinkering with Autokey design can 
be tedious. The dances interact with the timeout and rate
 management functions, while exchanges may either timout or error.  
Current and useful features of the reference implementation
 may be lost in a new implentation. The effective approach may be to 
eviscerate the current Autokey provisions in the reference
implentation and replace with the above design. This may not be as 
difficult as it seems. First, remove all extension field references
to association ID, timestamp and filestamps. Note that the progression 
of exchanges is not changed. The next step is to implement
 the cookie and DH agreement algoriths as described above. The final 
step is to remove all references to the SKEY scheme and replace
with the signature scheme as described.

dave sends

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

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 23 Jun 2016 17:54:00 +0000

Dave,

Is there any chance of a compare/contrast of your proposal with something like the TLS (probably 1.3) handshake to set up keys?  The latter has had significant cryptographic review.

ASN1/DER for keys aren't a barrier on embedded device; they're little more than a few header bytes and an octet string.
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 24 Jun 2016 10:04:59 +0200

>>> "David L. Mills" <[email-masked]> schrieb am 23.06.2016 um 18:58 in Nachricht
<[email-masked]>:
[...]
> hash algorithms can be truncated as well.

I think such arbitrary restrictioins should be avoid. For examples, today's smartphones have more power than servers had 15 years ago. An implementation might ignore any hash that it considers too heavy to handle, but why restrict some intranet setups?

[...]

Regards,
Ulrich
P.S.: Dave, nice to hear from you!