[ntpwg] [ntp:hackers] Handling authentication extensions (wasMS-SNTP)

Sat Apr 5 21:11:19 UTC 2008

----- Original Message ----- 
From: "Greg Dowd" <GDowd at symmetricom.com>
To: "David L. Mills" <mills at udel.edu>; "NTP Working Group" 
<ntpwg at lists.ntp.isc.org>
Sent: Thursday, April 03, 2008 5:44 PM
Subject: Re: [ntpwg] [ntp:hackers] Handling authentication extensions 
(wasMS-SNTP)

>
> On the issue of the minimum extension field, why shouldn't we leave the
> minimum at 16 octets?

We should, and this is to support expansion in the size of the LEN's...  so 
the 16 Byte model is totally OK.

>  The MAX_MAC_LEN has been changing over time
> anyway.  I didn't even realize it had been bumped to 6 for the SHA-1
> mac.  Your suggestion would mean that no future hashing scheme could be
> concurrently supported.

> Leaving the definition the way it is currently
> written will leave a little room for the next digest protocol without
> immediately bumping into the minimum extension.

This is starting to sound like that meeting where McNeil and Robinson had 
that argument way back when Greg...

>
> On the extension field header, my hindsight says that we should
> allocated a type value of 1 (ONE) for Autokey v1, a value of 2 (TWO) for
> Autokey v2 and we would still have 65,533 entries left.  Do you have any
> thoughts on how we can make some room available for other protocols
> (e.g., things like negotiating MS-NTP on symmetric link) in the future
> and remain backwards compatible?
>
> BTW, I like the idea of being able to offer multiple crypto options (a
> la SSL families) and letting the client choose the type.  I understand
> that further system engineering may be required to understand the
> convolutions of the trust envelope under different scenarios.

Sure by defining a modular payload definition process, one that can define a 
type and size as a dynamic attachment for NTP.  Err, something like the one 
we all sat around "the table" back in 1998 working on.

>
>
> Greg Dowd
> gdowd at symmetricom dot com (antispam format)
> Symmetricom, Inc.
> www.symmetricom.com
> "Everything should be made as simple as possible, but no simpler" Albert
> Einstein
>
> -----Original Message-----
> From: hackers-bounces+gdowd=symmetricom.com at lists.ntp.org
> [mailto:hackers-bounces+gdowd=symmetricom.com at lists.ntp.org] On Behalf
> Of David L. Mills
> Sent: Thursday, April 03, 2008 4:48 PM
> To: ntpwg at lists.ntp.isc.org; hackers at ntp.org
> Subject: Re: [ntp:hackers] Handling authentication extensions (was
> MS-SNTP)
>
> Danny,
>
> I reviewed the secton on extension fields and found a wee error. The
> minimum extension field length is two words (8 octets), not four words,
> as it says in the spec. The reason for this is how the overall packet is
> parsed for backward compatibility. Right now the only customer with
> extension fields is Autokey, so a packet with extension fields always
> carries a MAC. The parser needs to know whether the next field is a MAC
> or an extension field. It goes like this:
>
> 1 word: crypto-NAK (no digest)
> 3 words: DES-CBC MAC (64-bit digest)
> 5 words: MD5 MAC (128-bit digest)
> 6 words: SHA MAC (160-bit digest)
> 2, 4 words: runt packet - format error
> 7 words or more: eat the extension field, then go around again
>
> The crypto-NAK and DES-CBC don't ordinarily involve extension fields.
> So, the minimum extension field length is two words to avoid mixing up a
> MD5 MAC with a one-word extension field and a SHA MAC.
>
> RIght now the presence of some kind of authentication scheme is
> signalled by the presence of a MAC. If no such scheme were intended, the
> parser would find no words ramining after the parse and that works.
> However, to avoid confusion, the extension field could not have length
> matching the length of one of the MACs.
>
> Moving on, the coding of the extension field hearder is rather loose;
> the version number field could be split in two 4-bit nibbles
> type/version, for instance. In hindsight I should habe interchanged the
> version and opcode octets so the type/version octet comes first in true
> Internet spirit. However, I agree in the classic Internet spirit that,
> if an application doesn't understand the type/version/opcode, it ignores
> the field.
>
> I'm a little uneasy about a design that could include more than one
> scheme (Autokey/MS-SNTP?) in the packet and letting the server pick one
> or the other. There is something called a cryptotype defined in the
> current authentication options page which carefully calls out what
> combinations of options represent acceptable/good practice.
>
> For instance, a non-authenticated client can chime an authentcated
> server, but not the other way around. A IFF server in one secure group
> can be a client of a GQ server in another secure group and so on. I
> suppose the cryptotype table in the doucmentation could be augmented to
> handle cross-schemes between different orthodoxy's like NTP and MS-SNTP,
> but the mind boggles.
>
> Dave
>
> Danny Mayer wrote:
>
>> Dave,
>>
>> I'd like to make the following addition to the NTPv4 spec (and yes I
>> know it's late) but this is important in processing authentication.
>> I'm doing this for the case where there is more than one
>> authentication extension header.
>>
>> Proposed addition text:
>>
>> "When processing extensions to the NTP packet involving authentication
>
>> the ntp server and client MUST process them in the order listed in the
>
>> packet. If the authentication type, as defined in the field type of
>> the extension, is not recognized or supported its content is discarded
>
>> and the application moves on to the next authentication type until it
>> finds one that it does support. All subsequent authentication
>> extension types are then discarded. If no authentication type is found
>
>> the application proceeds based upon the policy of that server
> instance."
>>
>> The goal here is to allow a client to send multiple possible
>> authentication types (in order of preference) and the server will
>> choose the first one it finds that it supports.
>>
>> Does this all make sense?
>>
>> Danny
>>
>> David L. Mills wrote:
>>
>>> Andrew,
>>>
>>> I hear you and don't want to leave Microsoft out in any case. As it
>>> stands, the MS-SNTP key ID scheme is incompatible with ordinary NTP
>>> users and the national laboratories. But, you have given me an idea.
>>>
>>> You say Samba is to simulate an AD controller, which means it would
>>> be a MS-SNTP server for that domain. I wouldn't thnk the Samba AD
>>> would ordinarily be a MS-SNTP client of another MS-SNTP server in
>>> that domaing, but that might happen. On the other hand, the Samba 4
>>> machine would very likely be a client of other NTP server(s). This is
>
>>> the case I am worried about. An even more perplexing case is when the
>
>>> Samba machine is a server for both NTP and MS-SNTP clients.
>>>
>>> For grins, I propose a configuration command to set the default
>>> server key ID scheme (ntp/mssntp/...) plus an association
>>> configuration option to set the default client key ID scheme.
>>> Exceptions can be handled by the restrict mechanism by using the
>>> restrict bits to override the default server scheme. I assume an AD
>>> will not have addresses scattered all over the place and relatively
>>> few address/mask pairs would be necessary. If on the other hand only
>>> a few NTP clients are used, the mask can apply to them.
>>>
>>> Does this work?
>>>
>>> Dave
>>
>
> _______________________________________________
> hackers mailing list
> hackers at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/hackers
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg 