Optional NTPv4 Authentication

Perhaps I need to reread the doc but I think that there is a
disconnect
with respect to the mandatory authenticator.  The presence
of ntp
extensions requires the inclusion (concatenation) of the MD5
HMAC
authenticator, which is independent of the autokey protocol.
 

As for the generic issue of inclusion/exclusion of autokey
in the
protocol docs, I'm all for any structure in which autokey
is shown as a
current authentication scheme which is plugged into the ntp
extensions
framework.  


-----Original Message-----
From: ntpwg-bounceslists.ntp.isc.org
[mailto:ntpwg-bounceslists.ntp.isc.org] On Behalf Of Burbank,
Jack L.
Sent: Tuesday, March 21, 2006 11:38 AM
To: ntpwglists.ntp.isc.org
Subject: [ntpwg] Optional NTPv4 Authentication

Hi everybody,

This issue is related to, at least in part, the 'document
vs. design'
discussion that was had at yesterday's meeting.  The
comments in
yesterday's meeting gave me the impression the general
consensus of the
group was that the purpose of this working group is to first
document
the existing protocol, then potentially move on to
enhancements/extensions/development.  This seems very
reasonable to me.

But, that leaves the remaining issue of authentication.  The
existing
protocol has an (optional) authentication mechanism that
many believe
will be frowned upon by the IESG.  But, if we do not include
this
information, we are starting to diverge from the existing
protocol.  The
original drafts had the autokey information (the -00 and
-01).  The -02
currently does not.  

I would like to keep this discussion going in the hopes of
building some
consensus, so that we (the editors) know whether to include
this
information or not.  

One question we have to ask ourselves is: does the exclusion
of Autokey
from the draft do potential future harm to interoperability?
 If so, it
should definitely be included.  If not, then perhaps it is
OK to leave
the optional authentication field as a placeholder?    

One thing that complicates the subject a little more is that
the
authentication field is actually mandatory if NTPv4
extension fields are
present.  To me, that makes it a little more difficult to
just leave a
placeholder.

Another related question is that since we are now in the
phase of
documenting what already exists, will the IESG still put the
security
aspects under the same scrutiny as something being newly
developed?
After all, regardless of what the IESG says, it will still
be deployed.
If they will, and we determine that indeed the
authentication mechanism
must be defined, then it seems we are approaching an
impasse.

Any thoughts you have on this topic would be much
appreciated!

Thanks,
Jack

Jack L. Burbank
Senior Professional Staff
The Johns Hopkins University Applied Physics Laboratory
Communications
Systems and Network Engineering Group
(240) 228-7127 (Washington)
(443) 778-7127 (Baltimore)
FAX (240) 228-0789 / (443) 778-0789
SIPRnet:  telecommGCCS.JHUAPL.Contractor.DSS.SMIL.MIL
_______________________________________________
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,

My original intent, subject to modification by this group,
was that, if 
symmetric key cryptography is employed, provisions for the
current MD5 
digest be required. Optionally, other message digests
algorithms might 
be employed, some with or without extension fields. This
might require 
the exclusion or padding to avoid ambiguity in the parsing
process. I 
think it a bad idea to use a digest length with no extension
field that 
would result in loss of interoperability should later
extension fields 
be used.

My p;osition on public key cryptography is that the spec
should define 
the extention field format, preferably including the 
timestamp/value/signature format, on the assumption that
Autokey or 
another scheme could be used.

Dave

Greg Dowd wrote:

> Perhaps I need to reread the doc but I think that there
is a disconnect
> with respect to the mandatory authenticator. The
presence of ntp
> extensions requires the inclusion (concatenation) of
the MD5 HMAC
> authenticator, which is independent of the autokey
protocol.
>
> As for the generic issue of inclusion/exclusion of
autokey in the
> protocol docs, I'm all for any structure in which
autokey is shown as a
> current authentication scheme which is plugged into the
ntp extensions
> framework.
>
>
> -----Original Message-----
> From: ntpwg-bounceslists.ntp.isc.org
> [mailto:ntpwg-bounceslists.ntp.isc.org] On
Behalf Of Burbank, Jack L.
> Sent: Tuesday, March 21, 2006 11:38 AM
> To: ntpwglists.ntp.isc.org
> Subject: [ntpwg] Optional NTPv4 Authentication
>
> Hi everybody,
>
> This issue is related to, at least in part, the
'document vs. design'
> discussion that was had at yesterday's meeting. The
comments in
> yesterday's meeting gave me the impression the general
consensus of the
> group was that the purpose of this working group is to
first document
> the existing protocol, then potentially move on to
> enhancements/extensions/development. This seems very
reasonable to me.
>
> But, that leaves the remaining issue of authentication.
The existing
> protocol has an (optional) authentication mechanism
that many believe
> will be frowned upon by the IESG. But, if we do not
include this
> information, we are starting to diverge from the
existing protocol. The
> original drafts had the autokey information (the -00
and -01). The -02
> currently does not.
>
> I would like to keep this discussion going in the hopes
of building some
> consensus, so that we (the editors) know whether to
include this
> information or not.
>
> One question we have to ask ourselves is: does the
exclusion of Autokey
> from the draft do potential future harm to
interoperability? If so, it
> should definitely be included. If not, then perhaps it
is OK to leave
> the optional authentication field as a placeholder?
>
> One thing that complicates the subject a little more is
that the
> authentication field is actually mandatory if NTPv4
extension fields are
> present. To me, that makes it a little more difficult
to just leave a
> placeholder.
>
> Another related question is that since we are now in
the phase of
> documenting what already exists, will the IESG still
put the security
> aspects under the same scrutiny as something being
newly developed?
> After all, regardless of what the IESG says, it will
still be deployed.
> If they will, and we determine that indeed the
authentication mechanism
> must be defined, then it seems we are approaching an
impasse.
>
> Any thoughts you have on this topic would be much
appreciated!
>
> Thanks,
> Jack
>
> Jack L. Burbank
> Senior Professional Staff
> The Johns Hopkins University Applied Physics Laboratory
Communications
> Systems and Network Engineering Group
> (240) 228-7127 (Washington)
> (443) 778-7127 (Baltimore)
> FAX (240) 228-0789 / (443) 778-0789
> SIPRnet: telecommGCCS.JHUAPL.Contractor.DSS.SMIL.MIL
> _______________________________________________
> 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 mailing list
ntpwglists.ntp.isc.org
http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg