Re: Client/Server Cryptotype Question

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

Chen Helen-A12587 wrote:

> 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