[ntp:hackers] [Bug 736] Support for W32Time authentication in ntpd

David L. Mills mills at udel.edu
Thu Nov 23 08:35:08 PST 2006


Luke,

I think it is time we take this issue off the bugs list and on the 
hackers list.

To the hackers, Luke and I have been tossing ideas back and forth about 
the cryptgraphic provisions in the current distribution. Historically, 
the present means was developed by Dennis Fergusson in the early 
eighties and hasn't changed much since. By present IPSEC design 
standards it is leaky as a sieve. Although the crypto algorithms are 
specifically intended to be public, the security parameters, including 
the keys themselves along with related data, should be quarrantined 
behind a fence. Luke understands that and has proposed a demilitarized 
interface together with (possibly) proprietary libraries to do this. One 
of the libraries would support the current means. Presumably, another 
dynamic library would support Windows.

Luke's primary goal is to support Windows, which relies on a domain 
controller to generate private keys and distribute to NTP clients. That 
function is opaque to ntpd itself. The (proprietary) library would 
handle the generation and verification functions, as well as the 
housekeeping functions that handle ageing and trust and so on.

I have no problems with the suggested interface, but I do have two 
questions. First, the interface should handle the selection of functions 
other than MD5, which means the size of the hash can vary. Second, 
whatever means is developed should work for Autokey as well, at least 
the hash operations.

A lot of this stuff may involve public FIPS libraries, which would be a 
good thing and help establish credibility in general. Your comments and 
contributions are welcome.

Dave

bugzilla at ntp.isc.org wrote:

> http://bugs.ntp.isc.org/736
>
>
>
> ----------------------------------------------------------------------------
> Additional Comments From lukeh at novell.com (Luke Howard)
> Submitted on 2006-11-23 06:43
>
> Subject: Support for W32Time authentication in ntpd
>
> I am thinking of something like the following:
>
> /*
> * An authentication provider backend, allocated by the provider's
> * constructor.
> */
> struct authkey_be {
> void (*destructor)(struct authkey_be *be);
> int (*decrypt)(struct authkey_be *be, keyid_t keyno, u_int32 *pkt, int 
> length, int size);
> int (*encrypt)(struct authkey_be *be, keyid_t keyno, u_int32 *pkt, int 
> length);
> void (*agekeys)(struct authkey_be *be);
> void (*delkeys)(struct authkey_be *be);
> int (*havekey)(struct authkey_be *be, keyid_t keyno, int cache);
> void (*trust)(struct authkey_be *be, keyid_t keyno, u_long trust);
> int (*istrusted)(struct authkey_be *be, keyid_t keyno);
> int (*setkey)(struct authkey_be *be, keyid_t keyno, const u_char *key, 
> const int len);
> int (*refresh)(struct authkey_be *be);
> };
>
> /*
> * Current authentication provider version
> */
> #define AUTHPROV_VERSION_V1 1
> #define AUTHPROV_VERSION AUTHPROV_VERSION_V1
>
> /*
> * Authentication provider constructor, allocates backend object
> * (provider specific state can be stored at end of structure)
> */
> typedef struct authkey_be *(*authkey_be_constructor)(int version, 
> const char *args);
>
> A default backend containing the existing operations would be always 
> registered; others could be loaded on platforms that support dynamic 
> loading (module exports a single well known symbol being the backend 
> constructor; the constructor returns an authkey_be structure).
>
> libntp would internally keep a list of backends and their keyid bounds 
> and dispatch to the appropriate backend, maintaining the existing APIs.
>
> I am presently trying to remove the use of global variables for 
> authentication state management and the fixed NTP_MAXKEY pivot. For 
> example, the internal key cache state would be stored within the 
> internal authkey backend:
>
> struct internal_authkey_be {
> struct authkey_be be; /* backend callback table */
> u_long authnumkeys; /* number of active keys */
> /*
> * The key cache. We cache the last key we looked at here.
> */
> keyid_t cache_keyid; /* key identifier */
> ...
> }
>
> -- Luke
>
>



More information about the hackers mailing list