Subject: [ntpwg] Updated draft

From: Helen.Y.Chen at motorola.com (Chen Helen-A12587)
Date: Thu, 1 Mar 2007 09:34:39 -0500

Danny,

Thank you for responding. Please see below.

Thanks,
Helen

-----Original Message-----
From: Danny Mayer [mailto:mayer at ntp.isc.org]
Sent: Wednesday, February 28, 2007 10:48 PM
To: Chen Helen-A12587
Cc: David L. Mills; ntpwg at ntp.isc.org
Subject: Re: [ntpwg] Updated draft

Chen Helen-A12587 wrote:
> Dave,
>
> Thank you. I have a few questions related to the autokey protocol
document:
>
>     * The autokey protocol assumes server is polled 1/minute.

I doubt that you will find that to be true. Can you point to any
document that says that? The autokey protocol has no need to make that
assumption. When the client receives the first packet with the autokey,
it immediately sends back a packet to that server asking for further
information (described in the autokey protocol). The server responds
with that information and the client immediately asks additional
information of the server until it has satisfied itself that the server
is authenticated or not. This is known as the autokey dance. After that
it will accept the NTP packets from that specific server as long as the
authentication information is found in the packet and follows the
autokey requirements.

[Helen] This is mentioned in the 1st paragraph of section 9 of David
Mills' The Autokey Security Architecture, Protocol and Algorithms
(January 2006): "Autokey assumes clients poll servers at a relatively
low rate, such as once per minute or slower". Did I misinterpret? Is
this assumption for the rate on the client side instead of for the
server?

> Would the
>       performance become unacceptable if the server is polled more
often
>       than once per minute, e.g. in the order of 300 polls per minute?

Why would you ever do that? Or are you asking if multiple clients make
requests and the server needs to handle 300 requests/minute? I stress
test servers and it sends much more than that from multiple places and
the load is barely visible and certainly not noticeable.

[Helen] Yes, I was asking if multiple clients make requests and the
server needs to handle many requests per minute?

>     * Autokey dance at beginning of protocol requires several
exchanges
>       to establish various keys, cookies, identity scheme, etc. Are
ALL
>       5 exchanges (Parameter, Certificate, Identity, Values and
>       Signature Exchanges) mandatory for the autokey protocol to work?

Yes. It stops as soon as it has determined that the server is authentic
(or not).

[Helen] Please help me better understand this. Is it possible for it to
determine the server is authentic BEFORE all 5 echanges are completed?
Or does it require all 5 exchanges to make this determination?

>     * From what I read, it seems that the autokey authentication is
>       performed for each request, correct?

Yes, in the sense that it checks and validates the authentication part o
the header each time that it receives the packet.

Danny

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ntp.isc.org/pipermail/ntpwg/attachments/20070301/b644d93c/attachment.html

---

From: mills at udel.edu (David L. Mills)
Date: Thu, 01 Mar 2007 15:25:55 +0000

Chen,

See below.

Dave

Chen Helen-A12587 wrote:

> *	The autokey protocol assumes server is polled 1/minute. Would
> the performance become unacceptable if the server is polled more often

The protocol runs relatively infrequencly, generally once per hour to 
refresh the key list. Other than that, the poll interval is not affected 
  and runs at the same interval as without Autokey. In any case, running 
with poll intervals in the order of five per second is 
counterproductive, both with respect to network overhead and also with 
respect to the expected network jitter (e.g., Allan intercept).

> *	From what I read off the NTP Project website, it seems that your
> team has done performance analysis on NTPv4 and/or the autokey protocol.
> Would it be possible to share the outcome of the analysis?

There is a great deal of network performance analysis in the book cited 
on the project page. However, the performance issues generlly have 
nothing to do with Autokey, as it runs only occasionally, so the only 
intrusion in ordinary operation is the expense to computer the MD5 hash, 
and that is ordinarily buried in the noise.

> exchanges to establish various keys, cookies, identity scheme, etc. Are
> ALL 5 exchanges (Parameter, Certificate, Identity, Values and Signature
> Exchanges) mandatory for the autokey protocol to work?

There are slightly differenct Autokey dances for the three NTP modes and 
minor modifications due to identity scheme selection. In general, at 
least three exchanges are required; most require all five.

> performed for each request, correct?

No. The exchanges are required when a new key list is generated and that 
defaults to about once per hour. A private value refresh happens about 
once per day.

> From: David L. Mills [mailto:mills at udel.edu]
> Sent: Monday, February 12, 2007 6:26 PM
> To: Chen Helen-A12587
> Cc: mayer at ntp.isc.org; ntpwg at ntp.isc.org
> Chen,
> The document is now restored. The Windwoes name was in upper case; the
> Unix link in lower case. Sign.
> 
> There is no provision for Autokey in the standards document. In
> prinicple there could be, but it doesn't seem useful to add all that
> baggage and not make a NTP-conformant version. I'm happy to add that
> option to the SNTP text if this seems desirable.
> 
> Dave
> 
> Chen Helen-A12587 wrote:
> 
> 
>>Danny, David,
>>
>>The link I tried (draft-ietf-ntp-ntpv4-proto-04) didn't work. I would
>>like to know if SNTPv4 includes the sutokey algorithm, or if the
>>autokey can only be implemented in NTPv4.
>>
>>Thanks,
>>Helen Chen
>>
>>From: ntpwg-bounces+helen.y.chen=motorola.com at lists.ntp.isc.org
>>[mailto:ntpwg-bounces+helen.y.chen=motorola.com at lists.ntp.isc.org] On
>>Behalf Of Danny Mayer
>>Sent: Sunday, February 11, 2007 3:52 PM
>>To: David L. Mills
>>Cc: ntpwg at ntp.isc.org
>>That's exactly what I wanted. Otherwise I would have opposed it going
>>forward with it obsoleting RFC 4330. I think I'll start reviewing your
>>edited version instead.
>>
>>Danny
>>
>>David L. Mills wrote:
>>
>>
>>>3. The SNTP protocol subset now has a separate section. The
>>>implementer wishing to build SNTP can avoid eye fatigue with the full
>>
>>NTP prose.
>>_______________________________________________
>>ntpwg mailing list
>>ntpwg at lists.ntp.isc.org
>>https://lists.ntp.isc.org/mailman/listinfo/ntpwg
> 
> 
> 
> 
>

---

From: Helen.Y.Chen at motorola.com (Chen Helen-A12587)
Date: Thu, 1 Mar 2007 11:21:09 -0500

Dave,

Thank you for your response. Please see below (red text) for a couple
more follow-up questions.

Helen

-----Original Message-----
From: ntpwg-bounces+helen.y.chen=motorola.com at lists.ntp.isc.org
[mailto:ntpwg-bounces+helen.y.chen=motorola.com at lists.ntp.isc.org] On
Behalf Of David L. Mills
Sent: Thursday, March 01, 2007 9:26 AM
To: ntpwg at ntp.isc.org
Subject: Re: [ntpwg] Updated draft

Chen,

See below.

Dave

[Helen] I assume you're referring to the client's poll interval and
rate, correct?

> exchanges to establish various keys, cookies, identity scheme, etc.
> Are ALL 5 exchanges (Parameter, Certificate, Identity, Values and
> Signature

[Helen] We're trying figure out which parameters we need to store. In a
previous email exchange with your team, we were advised that IFF is the
"default" identity scheme to try, and we're interested in the
client-server mode. Does the client-server mode with the IFF scheme need
all 5 key exchanges? Would you mind sharing which schemes require which
key exchanges, to help us determine which parameters we need to store
and manage on our clients/servers?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ntp.isc.org/pipermail/ntpwg/attachments/20070301/3b61e5a0/attachment-0001.html

---

From: mills at udel.edu (David L. Mills)
Date: Thu, 01 Mar 2007 17:27:49 +0000

Chen,

My browser reports no red text in your message. Please don't use color.

Dave

Chen Helen-A12587 wrote:

>>team has done performance analysis on NTPv4 and/or the autokey
> 
> protocol.
>

---

From: Helen.Y.Chen at motorola.com (Chen Helen-A12587)
Date: Thu, 1 Mar 2007 12:32:58 -0500

Dave,
 
Sorry about the red text - re-sending with black text...
 
Helen

________________________________

From: Chen Helen-A12587 
Sent: Thursday, March 01, 2007 10:21 AM
To: 'David L. Mills'; ntpwg at ntp.isc.org
Subject: RE: [ntpwg] Updated draft

Dave,

Helen

-----Original Message-----
From: ntpwg-bounces+helen.y.chen=motorola.com at lists.ntp.isc.org
[mailto:ntpwg-bounces+helen.y.chen=motorola.com at lists.ntp.isc.org
<mailto:ntpwg-bounces+helen.y.chen=motorola.com at lists.ntp.isc.org> ] On
Behalf Of David L. Mills
Sent: Thursday, March 01, 2007 9:26 AM
To: ntpwg at ntp.isc.org
Subject: Re: [ntpwg] Updated draft

Chen,

See below.

Dave

protocol.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ntp.isc.org/pipermail/ntpwg/attachments/20070301/bca8a8aa/attachment.html

---

From: mills at udel.edu (David L. Mills)
Date: Thu, 01 Mar 2007 18:06:04 +0000

Helen,

See below.

Dave

> Sorry about the red text - re-sending with black text...

In client/server modes the server does not poll.

> and manage on our clients/servers?

The quickest way to answer this is the briefings 
http://www.eecis.udel.edu/~mills/proto.html and 
http://www.eecis.udel.edu/~mills/ident.html. Another way to gain insight 
is the state diagrams in the report 
http://www.eecis.udel.edu/~mills/database/reports/stime1/stime.pdf.

---

From: mayer at ntp.isc.org (Danny Mayer)
Date: Thu, 01 Mar 2007 23:35:33 -0500

Chen Helen-A12587 wrote:
> Mills' _The Autokey Security Architecture, Protocol and Algorithms
> (January 2006)_: "Autokey assumes clients poll servers at a relatively
> this assumption for the rate on the client side instead of for the server?
> 

Probably. The client normally is set up to query the server at an
interval ranging from every 64 seconds (minpoll) to 1024 seconds
(maxpoll). For broadcast and multicast which also can use autokey, the
interval is always 64 seconds and is sent by the server without any
queries from the client except for autokey authentication.

>> Would the
>>       performance become unacceptable if the server is polled more often

The load that I've been putting on my own test system has been in the
1000's if not 10,000 queries/min range and it's not even noticeable.

>>     * Autokey dance at beginning of protocol requires several exchanges
>>       to establish various keys, cookies, identity scheme, etc. Are ALL

The autokey scheme requires a different number of exchanges depending on
the scheme chosen. You need to consult the documentation for the actual
number required for each.

Danny

---

From: Helen.Y.Chen at motorola.com (Chen Helen-A12587)
Date: Tue, 13 Mar 2007 18:01:59 -0400

Danny,

Thank you. A couple more questions:
1) If the client (or server) went off line for some time, and the keys
don't macth after the client (or server) returns online, what happens?
Would the autokey dance kick off automatically when the message header
authentication fails?
2) How long has the NTPv4 implementation been in use and tested?

Thanks,
Helen

-----Original Message-----
From: Danny Mayer [mailto:mayer at ntp.isc.org] 
Sent: Thursday, March 01, 2007 10:36 PM
To: Chen Helen-A12587
Cc: David L. Mills; ntpwg at ntp.isc.org
Subject: Re: [ntpwg] Updated draft

> assumption. When the client receives the first packet with the 
> autokey, it immediately sends back a packet to that server asking for 
> further information (described in the autokey protocol). The server 
> responds with that information and the client immediately asks 
> additional information of the server until it has satisfied itself 
> that the server is authenticated or not. This is known as the autokey 
> dance. After that it will accept the NTP packets from that specific 
> server as long as the authentication information is found in the 
> packet and follows the autokey requirements.
> 

server?

often

exchanges
ALL
> Yes. It stops as soon as it has determined that the server is 
> authentic (or not).
> 
> [Helen] Please help me better understand this. Is it possible for it 
> to determine the server is authentic BEFORE all 5 echanges are
completed?

> Yes, in the sense that it checks and validates the authentication part

> o the header each time that it receives the packet.
> 
> Danny
> 

Danny

---

From: mayer at ntp.isc.org (Danny Mayer)
Date: Wed, 14 Mar 2007 21:30:25 -0400

> Would the autokey dance kick off automatically when the message header

The client will reject the packets, find it needs to reestablish
authentication and start the keydance. This should be automatic. If you
find that it's not working that way then you need to let us know so that
it can be fixed. I assume you are testing this?

> 2) How long has the NTPv4 implementation been in use and tested?

I don't know. That's a question for Dave.

Danny

---

From: Helen.Y.Chen at motorola.com (Chen Helen-A12587)
Date: Thu, 15 Mar 2007 11:10:52 -0400

Danny, Please see below. - Helen 

-----Original Message-----
From: Danny Mayer [mailto:mayer at ntp.isc.org] 
Sent: Wednesday, March 14, 2007 8:30 PM
To: Chen Helen-A12587
Cc: David L. Mills; ntpwg at ntp.isc.org
Subject: Re: [ntpwg] Updated draft

The client will reject the packets, find it needs to reestablish
authentication and start the keydance. This should be automatic. If you
find that it's not working that way then you need to let us know so that
it can be fixed. I assume you are testing this?
[Helen] This is good to know. At this time, we are not testing this yet.
If we run into problems, we'll let you know.

I don't know. That's a question for Dave.
[Helen] Thanks, I'll look forward to Dave's input.

Danny

---

From: mills at udel.edu (David L. Mills)
Date: Thu, 15 Mar 2007 17:13:05 +0000

Chen Helen-A12587,

The current version of the protocol has been running here since February 
2003. The only thing you have to worry about, should a client go offline 
for awhile, is to be sure the certificate is valid; that is, the current 
time is within the period of validity claimed for the certificate. By 
default, the period of validity is one year, so every year I have to 
refresh the certificates.

Dave

---

From: Helen.Y.Chen at motorola.com (Chen Helen-A12587)
Date: Thu, 15 Mar 2007 13:37:32 -0400

Dave, Danny,

As Danny said below, the client code will automatically start the
autokey sequence after it fails the authentication. Would the autokey
sequence, in the NTP project reference implementation, automatically
take care of checking for the certificate validity?

Thanks,
Helen 

-----Original Message-----
From: ntpwg-bounces+helen.y.chen=motorola.com at lists.ntp.isc.org
[mailto:ntpwg-bounces+helen.y.chen=motorola.com at lists.ntp.isc.org] On
Behalf Of David L. Mills
Sent: Thursday, March 15, 2007 12:13 PM
To: ntpwg at ntp.isc.org
Subject: Re: [ntpwg] Updated draft

Chen Helen-A12587,

Dave

---

From: tglassey at earthlink.net (todd glassey)
Date: Thu, 15 Mar 2007 14:39:58 -0700

There is no CRL or OSCP capabilities in AutoKey per se now that I know of. 
Those would have to be bolted on to the start/restart process.

Todd

---

From: mills at udel.edu (David L. Mills)
Date: Thu, 15 Mar 2007 22:27:26 +0000

Chen Helen-A12587,

Helen,

Checking and validating certificates is an integral part of the porotocol.

Dave

Chen Helen-A12587 wrote:

>>> 1) If the client (or server) went off line for some time, and the
>>
> keys
>
>>
>>> don't macth after the client (or server) returns online, what
>>
> happens?
>
>>> Would the autokey dance kick off automatically when the message
>>
> header
>
>>
>>> authentication fails?
>>
>>
>> authentication and start the keydance. This should be automatic. If
>
> you
>
>> find that it's not working that way then you need to let us know so
>
> that
>
>> [Helen] This is good to know. At this time, we are not testing this
>
> yet.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ntp.isc.org/pipermail/ntpwg/attachments/20070315/05bd5507/attachment.html

---

From: Helen.Y.Chen at motorola.com (Chen Helen-A12587)
Date: Mon, 19 Mar 2007 19:05:20 -0400

Dave et al,

The Autokey Protocol and Architecture (page 16) states that "all
cryptographic values used by the protocol are time sensitive and are
regularly refreshed".
1) Is this done automatically by the protocol and code?
2) Does the protocol automatically refresh public/private keys (of
client and server), certificates, and identity scheme group parameters?
3) Since the server cookie is dependent on the private value, is it also
automatically refreshed by the protocol when the server seed refreshes?

Thanks,
Helen

-----Original Message-----

Chen Helen-A12587,

Dave

keys
happens?
header
you
that
yet.

---

From: mills at udel.edu (David L. Mills)
Date: Tue, 20 Mar 2007 12:24:59 +0000

Helen,

The protocol itself has no business refreshing keys or other 
cryptographic media. Ordinarily, that is done with scripts and cron 
jobs. This is a matter of local security policy.

The private value is refreshed automatically about once per day. The 
server cookie is recalculated on the next dance opportunity.

Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ntp.isc.org/pipermail/ntpwg/attachments/20070320/62d887f9/attachment.html

---

From: GDowd at symmetricom.com (Greg Dowd)
Date: Tue, 20 Mar 2007 06:22:40 -0700

I'm not sure I followed that.  You seem to be interchanging protocol (no
business refreshing keys) with application (scripts and cron jobs).  It
would be easier to follow if you differentiate protocol and app.

Protocol
========
I presume that the Autokey v2 protocol is RESPONSIBLE for continually
verifying the validity of the key information used to identify the
endpoint when Autokey (or the material in question) is in use. As NTP
has defined its own protocol for building a trusted chain of clocks, the
protocol itself MUST have a check for stale data (including identities
integral to the protocol in the form of x.509 certs).  It could be
implementation dependent how to handle that check (check attributes,
check sigs, tc store, ca, crl, etc) in that the application could die,
regen keys, whatever but the state machine MUST support knowledge of the
boundary condition.  Otherwise, there is no trust.  While the ephemeral
nature of the association may mean that the time transfer component does
not need to be rigorously constrained, the idea that later in time you
may wish to make a statement that a particular identity could only have
been used for time transfer during its validity interval will likely be
required in any system which tries to build a true traceable reference.

Application
===========
AFAIK, the application does NOT actually check the validity of a
certificate on a recurring basis to determine whether or not the key may
continue to be used.  AFAIK, there is also not a way to introduce new
keys/certs into the application without restarting.  Has that changed?
Actually, in the original deployment, I remember that the code which
checked the cert for validity never actually checked that the pub key in
the cert matched the pub key input for use.  I haven't followed that
part of the protocol development as there hasn't been much deployment
but I look forward to future applications.  

-----Original Message-----
From: ntpwg-bounces+gdowd=symmetricom.com at lists.ntp.isc.org
[mailto:ntpwg-bounces+gdowd=symmetricom.com at lists.ntp.isc.org] On Behalf
Of David L. Mills
Sent: Tuesday, March 20, 2007 5:25 AM
Cc: ntpwg at ntp.isc.org
Subject: Re: [ntpwg] NTPv4:Refreshing Certificates, Group Parameters,
Public/Private Keys, Cookies

Helen,

Dave

Chen Helen-A12587 wrote:

> 3) Since the server cookie is dependent on the private value, is it 
> also automatically refreshed by the protocol when the server seed
refreshes?
> The current version of the protocol has been running here since 
> February 2003. The only thing you have to worry about, should a client

> go offline for awhile, is to be sure the certificate is valid; that 
> is, the current time is within the period of validity claimed for the 
> certificate. By default, the period of validity is one year, so every 
> year I have to refresh the certificates.
>
> Dave
>
> Chen Helen-A12587 wrote:
>

---

From: mills at udel.edu (David L. Mills)
Date: Tue, 20 Mar 2007 19:35:43 +0000

Greg,

The protocol does not automatically refresh file-based cryptographic 
media, but it does check the certificate trail about once per day and 
verify both lifetime and the system clock. In general, there may be 
several certificate trails to different primary servers. So, the easiest 
way to do this is simply restart the protocol, but this is transparent 
to the timing function. Once the protocol has completed, it is 
completely transparent.

It is assumed, but not required by the protocol, that the keys and 
certificates are refreshed occasionally, and there is a program that 
does that. In practice, a cron job runs this program once per month. 
This is transparent to the protocol; the new media are used the next 
time the protocol is restarted. The protocol itself doesn't do that; 
it's a matter of local policy.

You should see the Autokey document in the appendix on certificates, 
filestamps and timestamps. There is a very intricate dependency relation 
to insure all the steps are valid and file/timestamps have valid partial 
order. The implementation does check just about everything that can be 
checked.

The Autokey protocol itself has no provision for revocation; however, it 
does provide for certificate generation other than the Autokey 
utilities. In principle, industry standard mechanisms could be used, but 
then the lifetimes could not be reliably determined or enforced. It's 
that chicken and egg thing again.

You raise an interesting point about the meaning of the lifetime. 
Strictly interpreted the lifetime specifies the validity of the 
signature and nothing else. Since the certificates on all trails are 
cached, it could be that one or more may expire in the cache. This will 
be discovered the next time the expired certificate is used, in which 
case it will be discarded and an error message returned. A new 
certificate for the same issuer and subject always causes old ones to be 
discarded.

A host will not provide a certificate, sign a certificate or provide any 
cryptographic values unless the time is valid and within the lifetime of 
the certificate involved. It is conceivable that, for instance, the host 
certificate can run out while the host continues to provide assumed 
valid time until the next time a signature is requested.

Dave

Greg Dowd wrote:

>> client and server), certificates, and identity scheme group
>
> parameters?
>

---

From: Helen.Y.Chen at motorola.com (Chen Helen-A12587)
Date: Tue, 20 Mar 2007 17:38:59 -0400

NTPWG,

Does the your NTP project reference implementation version 4.1.1b
contain the autokey protocol? Which is the earliest version that can be
used? Or should only the latest version available be used?

Thanks,
Helen

---

From: stenn at ntp.isc.org (Harlan Stenn)
Date: Tue, 20 Mar 2007 22:52:49 +0000

Helen,

Newer versions contain bugfixes and enhancements.

Why would you want to use an older version?

H

---

From: tglassey at earthlink.net (todd glassey)
Date: Tue, 20 Mar 2007 16:03:57 -0700

----- Original Message ----- 
From: "Chen Helen-A12587" <Helen.Y.Chen at motorola.com>
To: "David L. Mills" <mills at udel.edu>; <ntpwg at ntp.isc.org>
Sent: Monday, March 19, 2007 4:05 PM
Subject: [ntpwg] NTPv4:Refreshing Certificates, Group 
Parameters,Public/Private Keys, Cookies

> cryptographic values used by the protocol are time sensitive and are

This is specific to "Within the AutoKEY framework" and doesnt deal with 
verifying that the underlying x509 is any good. That is an OCSP/CRL or CA 
Lookup Function and its not part of NTP today...

> 1) Is this done automatically by the protocol and code?

No...

> client and server), certificates, and identity scheme group parameters?

For the AutoKEY functions only.

---

From: brad at shub-internet.org (Brad Knowles)
Date: Tue, 20 Mar 2007 18:08:02 -0500

>  used? Or should only the latest version available be used?

Speaking only for myself, the NTP 4.1.1 tag was laid down over five 
years ago.  The NTP BitKeeper repository change list at 
<http://ntp.bkbits.net:8080/ntp-stable/?PAGE=changes> has a list of 
all changes made to the code since it was imported into BitKeeper. 
The tag for 4.1.1 is at 
<http://ntp.bkbits.net:8080/ntp-stable/?PAGE=cset&REV=1.683.7.1> and 
indicates that the exact date/time stamp was 2002-02-26 22:44:34 
-05:00.

Take a look at the changes that have been made since then.  If you do 
that, I think you'll understand why you want to be using much more 
recent code.

-- 
Brad Knowles <brad at shub-internet.org>, Consultant & Author
LinkedIn Profile: <http://tinyurl.com/y8kpxu>
Slides from Invited Talks: <http://tinyurl.com/tj6q4>

---

From: mills at udel.edu (David L. Mills)
Date: Wed, 21 Mar 2007 03:29:45 +0000

Helen,

The Autokey has been in the distribution for some time; however, in the 
developing climate, it is always best to use the most recent one. The 
most recent modification date was 3 January 2007, but recent changes 
have mainly been cosmetic, like correct source commentary.

Dave

---

From: Helen.Y.Chen at motorola.com (Chen Helen-A12587)
Date: Tue, 27 Mar 2007 18:24:34 -0400

Dave et al,

"The Autokey Security Architecture, Protocol and Algorithms", page 50,
Appendix E.7, 2nd paragraph states that when a client association is
mobilized at configuration time, it can be designated non-authentic,
authenticated with some Autokey scheme,and the client will send packets
with that cryptotype. When the responding server is mobilized, the
server is designated with the same cryptotype as the packet the server
receives.

My questions:
1) Am I correct in assuming that the reference implementation allows a
particular client to have a non-authentic association with 1 server and
an authentic association with a different server?
2) Does the reference implementation support the following deployment
where an entity acts as a client as well as a server - this entity's
client portion has a non-authentic association with a server while at
the same time, the same entity's server portion has an authentic
(autokey) association with another client?

Thanks,
Helen

---

From: GDowd at symmetricom.com (Greg Dowd)
Date: Tue, 27 Mar 2007 16:32:56 -0700

Dave's the authority but my testing showed that 1) was possible but 2)
was not as the proventic bit was not set when synchronizing via an
unauthenticated link upstream.

Greg Dowd
gdowd at symmetricom dot com (antispam format)
Symmetricom, Inc. 
www.symmetricom.com
"The current implementation is non-obvious and may need to be improved."

-----Original Message-----
From: ntpwg-bounces+gdowd=symmetricom.com at lists.ntp.isc.org
[mailto:ntpwg-bounces+gdowd=symmetricom.com at lists.ntp.isc.org] On Behalf
Of Chen Helen-A12587
Sent: Tuesday, March 27, 2007 3:25 PM
To: David L. Mills; ntpwg at ntp.isc.org
Subject: [ntpwg] Client/Server Cryptotype Question

Dave et al,

My questions:

Thanks,
Helen

---

From: mills at udel.edu (David L. Mills)
Date: Wed, 28 Mar 2007 19:59:49 +0100

Helen,

A client can have a mix of authenticated and non-authenticated servers. 
There is nothing in the model to prohibit that, although it might not be 
good practice. If acting as well as a server, it can have a mix of both 
types as clients. However, the server/client will appear as 
authenticated to dependent clients requesting authentication.

Yes, there is a curious case when a client loses its authentcated 
servers with only non-authenticated servers remaining. If acting as a 
server, it will continue to provide synchronization to dependent clients 
until such time the Autokey dance is resumed. At this time the 
certificate trail cannot be verified and the dance will fail.

These mixed modes are probably not a good idea for a secure 
configuration, but the model does not prohibit bad practices.

Dave

---

From: mills at udel.edu (David L. Mills)
Date: Wed, 28 Mar 2007 20:09:17 +0100

Greg,

Actually, it gets really interesting in a mixed-mode system where more 
than one trusted agent is involved. My example in the report shows a 
scenario where two trusted agents (primary servers) are involved 
together with a secondary trusted agent that dispenses time within an 
organization such as a bank. Now consider the issue of algorithm 
selection for each server and client. The cryptotypes do get complicated.

Dave

---

From: Helen.Y.Chen at motorola.com (Chen Helen-A12587)
Date: Wed, 28 Mar 2007 15:22:56 -0400

Dave,

Thank you for clarifying. I see that after the server/client loses all
its authenticated servers with only the non-authenticated servers
remaining and the autokey dance resumes and fails, none of the clients
of the server/client can synchronize time with it.

Please help me see if I got this right: I am considering the following
scenario, where server/client B gets time from (the only configured)
non-authentic server A, and has a dependent client C requesting
authentication. The C-B association is authentic but B-A association is
non-authentic. From your description below, it seems that server/client
B will never be able to authenticate to client C, correct?

Helen
-----Original Message-----
From: ntpwg-bounces+helen.y.chen=motorola.com at lists.ntp.isc.org
[mailto:ntpwg-bounces+helen.y.chen=motorola.com at lists.ntp.isc.org] On
Behalf Of David L. Mills
Sent: Wednesday, March 28, 2007 2:00 PM
To: ntpwg at ntp.isc.org
Subject: Re: [ntpwg] Client/Server Cryptotype Question

Helen,

Dave

> authenticated with some Autokey scheme,and the client will send 
> packets with that cryptotype. When the responding server is mobilized,

> the server is designated with the same cryptotype as the packet the 
> server receives.
>
> My questions:

> particular client to have a non-authentic association with 1 server 
> and an authentic association with a different server?

---

From: mills at udel.edu (David L. Mills)
Date: Fri, 30 Mar 2007 03:30:29 +0100

Helen,

IN your example, B would never synchronize to A and thus C would never 
synchroinze to B.

If a client requests authentication (either symmetric or public) for a 
particular server, it will include that server in the mitigation process 
only if authenticated. If the client does not request authentication, it 
will include that server in the mitigation process. AZ client can in 
principle be configured with some servers authentic and others not 
depending on local security policy. Ordinarily, this would not be a good 
idea. The reference implementation conforms to this model.

In public cryptography (Autokey) everu descendent of a trusted host must 
be authenticated to its source, as it requires a certificate trail to 
that host. However, a bad thing could happen if an intruder attempted to 
masquerade as a trusted host. That's what the identity scheme is 
designed to prevent.

In symmetric cryptography there is no certificate trail; in effect every 
server is a trusted source.

Here is a extreme, but possible, scenario. The trusted host/primary 
server loses its radio and for some dingbat reason has a non-authentic 
backup to another primary server in another location known to be secure. 
In this case it would continue to provide authentic service at stratum two.

Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ntp.isc.org/pipermail/ntpwg/attachments/20070330/f4bd4cb4/attachment.html