[ntp:hackers] MS-SNTP

Andrew Bartlett abartlet at samba.org
Fri Mar 28 05:13:29 UTC 2008


On Fri, 2008-03-28 at 03:55 +0000, David L. Mills wrote:
> 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

Values would start at 500, and increase to around the number of users
and computers in your domain/organisation. 

> , 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.

Remember that the high bit may or may not be set, and it is in little
endian.  This would seem to preclude any use of a pivot.  

What endian does the standard signing mech expect?

> 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.

Perhaps I'm missing something, but surely if the client has set an
all-zero checksum, then it's key ID is a MS-SNTP key, while if it has
specified a checksum, then things fall back to whatever the RFC process
specifies.

If not, could this be done outside the standards space, on the basis
that servers wishing to participate in both Microsoft's bastard signing
scheme - useful *only* on an AD-like domain controller - and proper,
internet standard NTP signing would be mutually exclusive?

In any case, perhaps we are taking the wrong approach here.  I think we
need to validate actual, not spec, behaviours, and ensure that
assumptions we are making are real.  I think this might all make more
sense with a patch, and I'll try and work on that soon. 

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ntp.org/pipermail/hackers/attachments/20080328/e3712de8/attachment.bin 


More information about the hackers mailing list