Re: NTPv4:Refreshing Certificates, Group Parameters, Public/Private Keys, Cookies

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.comlists.ntp.isc.org
[mailto:ntpwg-bounces+gdowd=symmetricom.comlists.ntp.isc.org] On Behalf
Of David L. Mills
Sent: Tuesday, March 20, 2007 5:25 AM
Cc: ntpwgntp.isc.org
Subject: Re: [ntpwg] NTPv4:Refreshing Certificates, Group
Parameters,
Public/Private Keys, Cookies

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

Chen Helen-A12587 wrote:

> 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-----
> From: ntpwg-bounces+helen.y.chen=motorola.comlists.ntp.isc.org
> [mailto:ntpwg-bounces+helen.y.chen=motorola.comlists.ntp.isc.org] On 
> Behalf Of David L. Mills
> Sent: Thursday, March 15, 2007 12:13 PM
> To: ntpwgntp.isc.org
> Subject: Re: [ntpwg] Updated draft
>
> 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
>
> Chen Helen-A12587 wrote:
>
>> Danny, Please see below. - Helen
>>
>> -----Original Message-----
>> From: Danny Mayer [mailto:mayerntp.isc.org]
>> Sent: Wednesday, March 14, 2007 8:30 PM
>> To: Chen Helen-A12587
>> Cc: David L. Mills; ntpwgntp.isc.org
>> Subject: Re: [ntpwg] Updated draft
>>
>> Chen Helen-A12587 wrote:
>>
>>> 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?
>>
>>
>> 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.
>>
>>> 2) How long has the NTPv4 implementation been
in use and tested?
>>>
>> I don't know. That's a question for Dave.
>> [Helen] Thanks, I'll look forward to Dave's input.
>>
>> Danny
>>
>>> Thanks,
>>> Helen
>>
>>
>
> _______________________________________________
> ntpwg mailing list
> ntpwglists.ntp.isc.org
> http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg


_______________________________________________
ntpwg mailing list
ntpwglists.ntp.isc.org
http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg

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:

> 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.comlists.ntp.isc.org
> [mailto:ntpwg-bounces+gdowd=symmetricom.comlists.ntp.isc.org] On Behalf
> Of David L. Mills
> Sent: Tuesday, March 20, 2007 5:25 AM
> Cc: ntpwgntp.isc.org
> Subject: Re: [ntpwg] NTPv4:Refreshing Certificates,
Group Parameters,
> Public/Private Keys, Cookies
>
> 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
>
> Chen Helen-A12587 wrote:
>
>> 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-----
>> From: ntpwg-bounces+helen.y.chen=motorola.comlists.ntp.isc.org
>> [mailto:ntpwg-bounces+helen.y.chen=motorola.comlists.ntp.isc.org] On
>> Behalf Of David L. Mills
>> Sent: Thursday, March 15, 2007 12:13 PM
>> To: ntpwgntp.isc.org
>> Subject: Re: [ntpwg] Updated draft
>>
>> 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
>>
>> Chen Helen-A12587 wrote:
>>
>>> Danny, Please see below. - Helen
>>>
>>> -----Original Message-----
>>> From: Danny Mayer [mailto:mayerntp.isc.org]
>>> Sent: Wednesday, March 14, 2007 8:30 PM
>>> To: Chen Helen-A12587
>>> Cc: David L. Mills; ntpwgntp.isc.org
>>> Subject: Re: [ntpwg] Updated draft
>>>
>>> Chen Helen-A12587 wrote:
>>>
>>>> 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?
>>>
>>>
>>> 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.
>>>
>>>> 2) How long has the NTPv4 implementation
been in use and tested?
>>>>
>>> I don't know. That's a question for Dave.
>>> [Helen] Thanks, I'll look forward to Dave's
input.
>>>
>>> Danny
>>>
>>>> Thanks,
>>>> Helen
>>>
>>>
>> _______________________________________________
>> ntpwg mailing list
>> ntpwglists.ntp.isc.org
>> http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg
>
>
>

_______________________________________________
ntpwg mailing list
ntpwglists.ntp.isc.org
http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg

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
_______________________________________________
ntpwg mailing list
ntpwglists.ntp.isc.org
http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg

At 5:38 PM -0400 3/20/07, Chen Helen-A12587 wrote:

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

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/?PAG
E=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 <bradshub-internet.org>, Consultant &
Author
LinkedIn Profile: <http://tinyurl.com/y8kp
xu>
Slides from Invited Talks: <http://tinyurl.com/tj6q4
>
_______________________________________________
ntpwg mailing list
ntpwglists.ntp.isc.org
http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg