[ntp:hackers] Handling authentication extensions (was MS-SNTP)

TS Glassey tglassey at earthlink.net
Sat Apr 5 21:06:32 UTC 2008


----- Original Message ----- 
From: "Danny Mayer" <mayer at ntp.isc.org>
To: "David L. Mills" <mills at udel.edu>
Cc: <ntpwg at lists.ntp.isc.org>; <hackers at ntp.org>
Sent: Wednesday, April 02, 2008 7:44 PM
Subject: [ntp:hackers] Handling authentication extensions (was MS-SNTP)


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

How are you going to enforce this? - MUST in these words is a very strong 
requirement, but being in 100% compliance with the NTP specification isnt a 
requirement for the use of the system, the reliable transfer of time-data 
stamps and  their proper recepit acknowledgement is, and that's about all 
that the NTP protocol specification should list.

If you want to specify particular requirement's for use-models for the use 
of the protocol - then that's a different story, but they are two very 
different things and its worthless for this WG to design mandatory use 
specifications into the actual protocol standard itself since these are 
particular to the use-models for the protocol and not the actual protocol 
itself.

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

Thats not such a good idea either since it means that the protocol itself is 
tagged to the use model and they are separate. The problem here is that the 
IETF's license models make it possible to use the core protocol without 
following the use-requirement's without being in violation of the protocol 
itself.

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

Which is fine...

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

Again this is a use-model for the auth-extensions and not a core 
functionality issue for the protocol, and as such it belongs in a Use Model 
document and not the core specification.

>
> Does this all make sense?

Only if the intent is to force people to assume some particular set of 
hurdles in the implementation of their ports, except that the IETF's license 
makes that impossible AFAIK - meaning that the sense this made was 
eliminated once NTP was published through the IETF's licensing model...

Todd

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



More information about the hackers mailing list