[ntp:hackers] MS-SNTP

David L. Mills mills at udel.edu
Fri Mar 28 03:55:10 UTC 2008


Andrew,

Yes, the key select is clever. The orignal NTP design anticipated 
password/key ID change by providing possibly several keys with 
respective key IDs. The client uses the active key ID until the server 
switches to another now active key ID. The client notices this and 
switches to that key ID.

You bring up a most interesting point. My fear is a violent trainwreck 
between the Autokey key space and what I have been told the MS-SNTP key 
space. Because on Autokey pseudo-random key generation and hash chains, 
shrinking the key ID space much would create crippling collisions. On 
the other hand, I understand the RID space is in the order of 500, which 
is far below the symmetric key pivot of 65535. If the MS-SNTP key ID 
space could fit below the pivot, that problem would disappear 
completely. On the other hand, MS-SNTP key space might work if the pivot 
point were increased from 2^16 to 2^18.

Here's a really serious showstopper. Is the gang sweating the runup to 
the last call willing to wait while we shake out these issues? Assuming 
this can be done relatively quickly, I would advise it be so. Here are a 
couple of things that might make it easier.

1. Change the spec to allow the client to opt-out of the requirement to 
construct a MAC. That would be indicated if the client message digest 
was all zeros. This is a no-brainer and should have been anticipated. 
This can be done in the current reference implemenation with two lines 
of code.

2. Resolve whether to activate my suggestion of optional 32/64-bit key 
IDs. WATCH OUT: We now do have the option of incorporating 160-bit 
message digests (SHA_x). Activating 64-bit key IDs prohibits that 
option. If we choose to reject 64-bit key IDs and embrace the 160-bit 
option, that should be so stated in the spec.

3. Resolve the issues on how MS-SNTP and Autokey can cohabit the same 
carcass; however, this must be done without requiring the server to 
retain state.

Dave

Andrew Bartlett wrote:

> On Thu, 2008-03-27 at 18:50 +0000, David L. Mills wrote:
>
>> Andrew,
>>
>> Gawd, I have enough trouble with the IETF to go boil in some other
>> standards ocean.
>
>
> The beauty of the WSPP process is that we have purchased the right to
> make Microsoft boil the ocean until our satisfaction :-). But yes, it
> takes time and effort.
>
>> Somewhen on the bugs list I was told th key ID would be a hash of the
>> RID with possibly the top bit stolen for the key selector. The key
>> selector is used to select which of two preloaded keys to use and s
>> small state machine used to remember the last selected by the server.
>
>
> The RID is not hashed. The 'key selector' is because each RID has an
> old and new password, and a number of similar protocols in this area
> permit use of the old password, to cope with replication delays.
>
> Andrew Bartlett
>



More information about the hackers mailing list