Re: Client/Server Cryptotype Question

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

Chen Helen-A12587 wrote:

> 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


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

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.comlists.ntp.isc.org
[mailto:ntpwg-bounces+helen.y.chen=motorola.comlists.ntp.isc.org] On
Behalf Of David L. Mills
Sent: Wednesday, March 28, 2007 2:00 PM
To: ntpwgntp.isc.org
Subject: Re: [ntpwg] Client/Server Cryptotype Question

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

Chen Helen-A12587 wrote:

> 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


_______________________________________________
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