Subject: [ntpwg] Handling authentication extensions (was MS-SNTP)

From: Danny Mayer <[email-masked]>
Date: Wed, 02 Apr 2008 22:44:53 -0400

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
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: "David L. Mills" <[email-masked]>
Date: Thu, 03 Apr 2008 23:47:57 +0000

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:

> 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:
>
> 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."
>
> authentication types (in order of preference) and the server will 
> choose the first one it finds that it supports.
>
>> 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
>

---

From: "Greg Dowd" <[email-masked]>
Date: Thu, 3 Apr 2008 17:44:16 -0700

On the issue of the minimum extension field, why shouldn't we leave the
minimum at 16 octets?  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.

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.

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=[email-masked]
[mailto:hackers-bounces+gdowd=[email-masked]] On Behalf
Of David L. Mills
Sent: Thursday, April 03, 2008 4:48 PM
To: [email-masked]; [email-masked]
Subject: Re: [ntp:hackers] Handling authentication extensions (was
MS-SNTP)

Danny,

Dave

_______________________________________________
hackers mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/hackers
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 04 Apr 2008 03:39:04 +0000

Greg,

The minimum extension field used by Autokey is two words now. The 
serious design intent is that extension fields are used only at startup 
or when something changes. Normally they are not used all and only the 
MAC appears.

It does not seem likely that anything beyond a 160-bit hash will become 
common anytime soon. It is important to observe that, even if a hash 
collision can be found relatively quickly, the likelihood that the 
result wouls be a valid NTP packet is vanishingly small. Frankly, I 
don't see a needto go beyond MD5.

The MAX_MAC_LEN has changed once since it was born circa 1984. This was 
when MD5 overtook DES as the only practical ITAR alternative. It might 
change should SHA-x come into practice and that's why the prvisions are 
there.

Dave

Greg Dowd wrote:

>> the application proceeds based upon the policy of that server
>
> instance."
>

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 04 Apr 2008 03:42:36 +0000

Greg,

Dave

---

From: "Greg Dowd" <[email-masked]>
Date: Fri, 4 Apr 2008 09:37:57 -0700

Now I see.  We need to change the minimum extension field length
definition in order to be compatible with the currently shipping version
of Autokey.  I agree with that wholeheartedly.  That was probably all
you had to say.   Making it smaller based on the opinion that the there
will never be another hash algorithm update was a much weaker argument.

Let me ask my other question in another way.  Do you support any other
usage of the extensions field in ntp than Autokey for interoperable
implementations?  Are you willing to consider any changes whatsoever to
support alternative uses of the extension mechanism?  While the
definition, going way back to the s/time days, has always defined the
extensions as generic tlv's, the way they are used currently, as well as
the way you talk about when/why/how extensions are sent, are much more
Autokey specific than extensions specific but you don't differentiate.

The main reason for the question is the rapidly closing window for the
ntpv4 protocol doc.  While the Autokey doc describes the autokey
protocol, the ntpv4 doc describes the generic tlv mechanism.  If we are
to have any hope of using extensions to extend the protocol further for
security, association, performance monitoring, etc., now is the time to
structure the type field definition to support that.

Greg Dowd

-----Original Message-----
From: ntpwg-bounces+gdowd=[email-masked]
[mailto:ntpwg-bounces+gdowd=[email-masked]] On Behalf Of
David L. Mills
Sent: Thursday, April 03, 2008 8:43 PM
To: NTP Working Group
Subject: Re: [ntpwg] [ntp:hackers] Handling authentication extensions
(wasMS-SNTP)

Greg,

Dave

Greg Dowd wrote:

> On the issue of the minimum extension field, why shouldn't we leave 
> the minimum at 16 octets? The MAX_MAC_LEN has been changing over time 

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

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

> 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:
>
> So, the minimum extension field length is two words to avoid mixing up

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

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

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

Greg Dowd wrote:

> On the issue of the minimum extension field, why shouldn't we leave 
> the minimum at 16 octets? The MAX_MAC_LEN has been changing over time 

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

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

> 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:
>
> So, the minimum extension field length is two words to avoid mixing up

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

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

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

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 04 Apr 2008 19:05:31 +0000

Greg,

Autokey is not the issue and TLVs have always been the intent. The 
problem is the optional MAC. For backward compatibililty it has to work 
with and without the MAC and with and without extension fields. Without 
a MAC the length of the last field must be seven or more words. In this 
case the parser eats all the fields and finds nothing left. With a MAC 
the length of the last field must be two or more words. In either case 
the lenght of all but the last field can be one or more words. That may 
sound spooky, but campatibility constraints rule it so.

Dave

Greg Dowd wrote:

> snip!

---

From: "Greg Dowd" <[email-masked]>
Date: Fri, 4 Apr 2008 12:25:38 -0700

That's an interesting concept but not consistent with either the code
(ntp_proto.c), the protocol draft (section 7.5) or your book (Section
9.3).  The definition of the extensions has always included the caveat
that a MAC is required if extensions are present.  The overhead of
calculating a MAC on a modern processor (even an embedded one) is not
that onerous.  Why change the definition now?  Do you see a need for
future extensions that could not support a MAC.  If you think we should
change the definition, we would also need to update the general section.
I've included the ntpv4 protocol draft definition for your review.  

7.5.  NTP Extension Field Format

   In NTPv4 one or more extension fields can be inserted after the
   header and before the MAC, which is always present when an extension
   field is present.  Other than defining the field format, this
   document makes no use of the field contents.  An extension field
   contains a request or response message in the format shown in
   Figure 14.

Greg Dowd

-----Original Message-----
From: ntpwg-bounces+gdowd=[email-masked]
[mailto:ntpwg-bounces+gdowd=[email-masked]] On Behalf Of
David L. Mills
Sent: Friday, April 04, 2008 12:06 PM
To: NTP Working Group
Subject: Re: [ntpwg] [ntp:hackers] Handling authentication
extensions(wasMS-SNTP)

Greg,

Dave

Greg Dowd wrote:

> definition in order to be compatible with the currently shipping 
> version of Autokey. I agree with that wholeheartedly. That was 
> probably all you had to say. Making it smaller based on the opinion 
> that the there will never be another hash algorithm update was a much
weaker argument.

> extensions as generic tlv's, the way they are used currently, as well 
> as the way you talk about when/why/how extensions are sent, are much 
> more Autokey specific than extensions specific but you don't
differentiate.

> to have any hope of using extensions to extend the protocol further 
> for security, association, performance monitoring, etc., now is the 
> time to structure the type field definition to support that.
>
>
>
>
> Greg Dowd
> [mailto:ntpwg-bounces+gdowd=[email-masked]] On Behalf 
> Of David L. Mills
> serious design intent is that extension fields are used only at 
> startup or when something changes. Normally they are not used all and 
> only the MAC appears.
>
> It does not seem likely that anything beyond a 160-bit hash will 
> become common anytime soon. It is important to observe that, even if a

> hash collision can be found relatively quickly, the likelihood that 
> the result wouls be a valid NTP packet is vanishingly small. Frankly, 
> I don't see a needto go beyond MD5.
>
> The MAX_MAC_LEN has changed once since it was born circa 1984. This 
> was when MD5 overtook DES as the only practical ITAR alternative. It 
> might change should SHA-x come into practice and that's why the 
> prvisions are there.
>
> Dave
>
> snip!

---

From: "David L. Mills" <[email-masked]>
Date: Sat, 05 Apr 2008 04:46:08 +0000

Greg,

I have tried to be flexible and accomitative in the venture and and am 
willing to change the rules. Do you have a conflict with that? Say your 
proposals.

Dave

---

From: "TS Glassey" <[email-masked]>
Date: Sat, 5 Apr 2008 14:11:19 -0700

----- Original Message ----- 
From: "Greg Dowd" <[email-masked]>
To: "David L. Mills" <[email-masked]>; "NTP Working Group" 
<[email-masked]>
Sent: Thursday, April 03, 2008 5:44 PM
Subject: Re: [ntpwg] [ntp:hackers] Handling authentication extensions 
(wasMS-SNTP)

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

> Leaving the definition the way it is currently

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

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

---

From: "TS Glassey" <[email-masked]>
Date: Sat, 5 Apr 2008 14:06:32 -0700

----- Original Message ----- 
From: "Danny Mayer" <[email-masked]>
To: "David L. Mills" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, April 02, 2008 7:44 PM
Subject: [ntp:hackers] Handling authentication extensions (was MS-SNTP)

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

Which is fine...

> 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

---

From: "TS Glassey" <[email-masked]>
Date: Sat, 5 Apr 2008 14:06:32 -0700

----- Original Message ----- 
From: "Danny Mayer" <[email-masked]>
To: "David L. Mills" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, April 02, 2008 7:44 PM
Subject: [ntp:hackers] Handling authentication extensions (was MS-SNTP)

Which is fine...

Todd

---

From: "TS Glassey" <[email-masked]>
Date: Sat, 5 Apr 2008 14:11:19 -0700

---

From: Danny Mayer <[email-masked]>
Date: Sat, 05 Apr 2008 23:34:52 -0400

Dave,

The problem with all this is that extensions are not being set up 
properly. The extension type field should tell you what type of 
information is in the extension and the length should tell you how long 
it is. There should be no other information in the extension type field.
All other information is private to the extension and should be 
incorporated into the body of the extension itself, including versioning 
information. The MAC itself should be an extension field with a value in 
the extension type field to identify it as a MAC extension. All this is 
straightforward to do and does not require you to guess about the 
extensions and the MAC. This is why the NTPv4 spec does not discuss 
autokey, just how to specify and extension field to the NTP packet. The 
autokey protocol should discuss the extension itself and the contents of 
the extension and only specify one value to appear in the extension type 
field.

We are making it much harder than needed to make the NTP extensions 
practical and it's not as if the packets are large even with extensions. 
Even more than that it makes it easy to identify an extension and what 
to do with it and makes it modular.

If this breaks the current autokey extension layout, I'm sure we can 
come up with something to allow migration with to above scheme possible.

Danny

---

From: Brian Utterback <[email-masked]>
Date: Sun, 06 Apr 2008 06:56:21 -0400

Absolutely. This has been brought up numerous times before, but there 
was never a compelling reason to go back and change it. This has been 
due to a chicken and egg problem; there were no proposed extensions that 
did not require a MAC such that it made a change necessary, but this was 
usually because such proposed extensions were abandoned when the 
limitation was discovered.

Now is what could be our last chance to get this rationalized. Dave is 
willing to make the change, and if we don't do it now, we probably can 
never do it.

---

From: "David L. Mills" <[email-masked]>
Date: Sun, 06 Apr 2008 17:17:48 +0000

Danny,

I'm baffled by your comments. The current NTPv4 spec says nothing about 
Autokey and makes no interpretation about the type field. The parser can 
and does step through the extension fields without knowing anything 
about the contents in order to find the MAC. The MAC can't be in an 
extension field without violating backwards compatibility with 
symmetric-key NTPv3 and NTPv4.

The current extension field design evolved from 1996 and was first 
formally proposed in 2000. It has been through two Autokey versions, 
both with the same extension field format. The point being that it is a 
little late to change it. The further point being that, without breaking 
backwards compatibility, it is easy to add new tenants of the extension 
fields. Break the version field into class/version nibbles. This 
requires no change to the existing Autokey implmentation, as it ignores 
other than class 0, version 2..

Dave

Danny Mayer wrote:

> information is in the extension and the length should tell you how 
> long it is. There should be no other information in the extension type 
> field.
> incorporated into the body of the extension itself, including 
> versioning information. The MAC itself should be an extension field 
> with a value in the extension type field to identify it as a MAC 
> extension. All this is straightforward to do and does not require you 
> to guess about the extensions and the MAC. This is why the NTPv4 spec 
> does not discuss autokey, just how to specify and extension field to 
> the NTP packet. The autokey protocol should discuss the extension 
> itself and the contents of the extension and only specify one value to 
> appear in the extension type field.
>
> practical and it's not as if the packets are large even with 
> extensions. Even more than that it makes it easy to identify an 
> extension and what to do with it and makes it modular.
>
>> 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:
>>
>> 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.
>>
>> works. However, to avoid confusion, the extension field could not 
>> have length matching the length of one of the MACs.
>>
>> 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.
>>
>> the current authentication options page which carefully calls out 
>> what combinations of options represent acceptable/good practice.
>>
>> 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,
>>>
>>> "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."
>>>
>>>> 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.
>>>>
>>>> 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
>>>

---

From: Danny Mayer <[email-masked]>
Date: Sun, 06 Apr 2008 21:54:06 -0400

> other than class 0, version 2..

No, versioning does not belong in that field. It belongs in the 
extension itself. If need be we can take a bit in the extension field 
(or reduce the length field by one bit to accommodate a way to signal 
the type of extension, 0 for current behavior and 1 for new behavior. We 
are unlikely to use 32535 bytes for this information anyway so we don't 
really lose anything by doing this.

Danny

---

From: "David L. Mills" <[email-masked]>
Date: Mon, 07 Apr 2008 02:28:50 +0000

Danny,

The version suggestion is a red herring. See my proposed Section wording.

Dave

Danny Mayer wrote:

> David L. Mills wrote:
>
>> Danny,
>>
>> I'm baffled by your comments. The current NTPv4 spec says nothing 
>> about Autokey and makes no interpretation about the type field. The 
>> parser can and does step through the extension fields without knowing 
>> anything about the contents in order to find the MAC. The MAC can't 
>> be in an extension field without violating backwards compatibility 
>> with symmetric-key NTPv3 and NTPv4.
>>
>> both with the same extension field format. The point being that it is 
>> a little late to change it. The further point being that, without 
>> breaking backwards compatibility, it is easy to add new tenants of 
>> the extension fields. Break the version field into class/version 
>> nibbles. This requires no change to the existing Autokey 
>> implmentation, as it ignores other than class 0, version 2..
>>
>> Dave
>
>
> the type of extension, 0 for current behavior and 1 for new behavior. 
> We are unlikely to use 32535 bytes for this information anyway so we 
> don't really lose anything by doing this.
>
> Danny