[ntp:hackers] UDel security

David L. Mills mills at udel.edu
Thu May 12 19:13:06 PDT 2005

Steve & Co.,

Thanks for the quick reply. I can't easily read variable width fonts and 
this contraption forces me into variable width font if I try inline 
reply, so this will be top post.

I saw your key page. It certainly does what needs to fetch the key, but 
the key is for only one machine. My hope would be to have the duly 
authorized server administrator upload the script including the key as 
part of name server list maintenance and clients be able to retrieve it 
as part of the lookup-name-select process. The client selects the 
password, which is presumably a different secret for every client. 
However, I hear you about  possible legal concerns.

All private key files, including the host key, sign key and group key, 
are stored in encrypted form using a password. Without the password they 
are of no use if stolen and used on another machine, either in or out of 
the group. Note that it is very likely that a client/server will have 
multiple keys for different groups. The only file that needs to be 
root-only is the configuration file, but the others could be as well if 
local policy requires it.

Access control via firewall doesn't work if you have 25 millioon 
clients, each with a different IP address. While the autokey scheme 
works for server authentication, the client access to get the group key 
can use pem, as there are far fewer servers than clients, at least for 
the primary servers.

This is only a first shot; there might be other ways to skin the cat. 
For now I intend to create pseudo mailboxes associated with the server 
names. It would be nice to create an alternate access policy called 
autokey for the server list entry, possibly with instructions on the 
clickable link and mailbox name in the comments.

I see on the primary server list that the contact person is listed for 
all primary servers except the ones I administer. I am listed on the old 
lists from here. That doesn't matter; everybody knows who those servers 
belong to.


Steve Kostecke wrote:

>Note: Lightly reformatted and slightly reordered to allow in-line
>"David L. Mills" said:
>>"Danny Mayer" said:
>>>"David L. Mills" said:
>>>>I am asking the ISC to regularize the Autokey group key provision
>>>>via the web. Can we set up a scheme that allows registration and
>>>>retrieval of a group key for designated machines?
>>>Are you talking about the autokey key distribution scheme that Steve
>>>set up?
>>At the moment, I can't find the magic secure web page that serves as a
>>way to get the group key wrapped in a shell script that installs the
>>key and links.
>My IFF key request page is at https://ntp.isc.org/crypto.php
>That key request page currently only provides users with a way of
>viewing or downloading their key. There is no shell-script wrapper,
>>>Or is this something else? What keys would be distributed and
>>>for what machines?
>>Recent experience at USNO and NIST strongly suggests some form of
>>mandatory access control is necessary for at least some public servers.
>>Case in point is at USNO, where the operators want to screen out all
>>except military customers. Autokey and notrust would seem the natural
>Group key files with a group password are not a decent means of access
>control because there is nothing to prevent the free exchange of the
>group key. As I understand it, NTP Authentication is only intended to
>authenticate the server's packets to it's clients. The way to control
>access is with ntpd restrictions or at the router/firewall.
>>What I would like to see at ISC is a secure web page which does this
>>where the user supplies the server name and password to encrypt the
>Since the key request page is only accessible via SSL I don't understand
>why the key would need another layer of encryption in transit.
>There needs to be a way to authenticate the users before giving out
>keys. Otherwise anyone could request a key for any server. And we're
>back to the problem of uncontrolled access.
>>The group key could be supplied at the time the public list is updated.
>>I would assume some way would be required to upload the group key. Is
>>this possible?
>This sounds like you would like ISC to be the group key distribution
>point for other organizations. This is really not the right approach for
>a number of reasons. Although the bandwidth requirement may not be high,
>there will almost certainly be liability issues (e.g. who is responsible
>if the USNO group key is released to the wrong party?). And there is the
>group password issue.
>There are two files, in addition to the host parameters, used in the
>IFF identity scheme: the server parameters (IFFpar) and the client key
>(IFFkey). The IFFkey file is encrypted with the client's password when
>it is exported from the IFFpar file (either by the server or a trusted
>third party). Yes, it is possible to use the IFFpar file on all of the
>members of an NTP Trust Group. But, in practice, you really don't want
>to do this.
>If you use an IFFpar file as a shared group key, every member of the
>Trust Group must use the same crypto password (e.g. a group password).
>This is not necessarily a show-stopper for systems which only belong to
>one NTP Trust Group, although I'm sure that most time server operators
>would not want to reveal their crypto password to anyone else. You could
>export a group IFFkey and encrypt it it with a group (client) password.
>This method avoids revealing the server's crypto password, but you still
>are using a group password.
>Group passwords are a significant issue when systems are members of more
>than one Trust Group. Since a system only has one crypto password, all
>of the group keys would need to be encrypted with that same password.
>The end result would be many groups using the same group password so
>that systems may belong to multiple Trust Groups unless there is a way
>for clients to use unique crypto passwords.
>Unless there is a way of adding a client password to a group key
>(IFFkey) subsequent to the export process, we would need to have a copy
>of the server key file (IFFpar) _and_ know the server's crypto password
>so that we can export IFFkey files on the fly. The server's RSA-MD5cert
>and RSAkey files are not needed during the export process.

More information about the hackers mailing list