Subject: [ntpwg] Updated draft-mizrahi-ntp-extension-field

From: Tal Mizrahi <[email-masked]>
Date: Thu, 14 Feb 2013 10:22:35 +0200

Hi,

Main changes compared to draft 00:

-          Danny Mayer has joined as a co-author.

-          We have separated the draft into two sections:

o   Section 3 describes how extension fields can be used in the absence of a MAC according to the existing RFC 5905 and 5906.

o   Section 4 defines further extensions for using extension fields, and therefore updates RFC 5905. The intended status of the document was changed to 'Standards Track' accordingly.

http://tools.ietf.org/html/draft-mizrahi-ntp-extension-field-01

Comments are welcome.

Thanks,
Tal.

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Greg Dowd <[email-masked]>
Date: Thu, 14 Feb 2013 17:38:10 +0000

Section 4.1 seems wrong.  Ntp supports MD5 checksums on packets without extensions.
Ergo, the following statement is contradicting existing behavior.  What was the intent there?

If there is no extension field present then a MAC MUST NOT be
   included in the packet. This is because there is no way to tell the
   difference between an unknown extension field and a MAC.

Greg Dowd | Symmetricom(r), Inc.
Staff Scientist
2300 Orchard Parkway, San Jose, CA 95131
Direct:  408.964.7643
[email-masked]<mailto:[email-masked]>  |  www.symmetricom.com<http://www.symmetricom.com/>
Symmetricom.  Leading the world in precise time solutions.

From: ntpwg-bounces+gdowd=[email-masked] [mailto:ntpwg-bounces+gdowd=[email-masked]] On Behalf Of Tal Mizrahi
Sent: Thursday, February 14, 2013 12:23 AM
To: [email-masked]
Subject: [ntpwg] Updated draft-mizrahi-ntp-extension-field

Hi,

Comments are welcome.

Thanks,
Tal.

---

From: [email-masked]
Date: Fri, 15 Feb 2013 12:53:35 +0100

I have the same question as Greg. It seems that this section would disable 
the symmetric authentication mechanism. From the point of view of an NTP 
service provider this would be a pity, because if users are requesting an 
authenticated NTP service they generally would  request just this old 
approach, since normally they wouldn't understand autokey or autokey 
wouldn't work because it doesn't work in conjunction with NAT.

As far as I know there is  a key/algorithm identifier in front of the 
actual MAC. Is it possible to use this to identify a MAC?

Regards
Dieter

----------------------------------
Physikalisch-Technische Bundesanstalt
Q.42 - Server Administration
Dr. Dieter Sibold
Bundesallee 100 
D-38116 Braunschweig
Tel:    +49-531-592-84 20
Mobile
E-Mail: [email-masked]

Von:    Greg Dowd <[email-masked]>
An:     Tal Mizrahi <[email-masked]>, "[email-masked]" 
<[email-masked]>, 
Datum:  14.02.2013 18:39
Betreff:        Re: [ntpwg] Updated draft-mizrahi-ntp-extension-field
Gesendet von:   ntpwg-bounces+dieter.sibold=[email-masked]

Section 4.1 seems wrong.  Ntp supports MD5 checksums on packets without 
extensions. 
Ergo, the following statement is contradicting existing behavior.  What 
was the intent there?

Greg Dowd | Symmetricom®, Inc.
Staff Scientist 
2300 Orchard Parkway, San Jose, CA 95131
Direct:  408.964.7643 
[email-masked]  |  www.symmetricom.com
Symmetricom.  Leading the world in precise time solutions.
 
From: ntpwg-bounces+gdowd=[email-masked] [
mailto:ntpwg-bounces+gdowd=[email-masked]] On Behalf Of Tal 
Mizrahi
Sent: Thursday, February 14, 2013 12:23 AM
To: [email-masked]
Subject: [ntpwg] Updated draft-mizrahi-ntp-extension-field
 
Hi,
 
Main changes compared to draft 00:
-          Danny Mayer has joined as a co-author.
-          We have separated the draft into two sections: 
o   Section 3 describes how extension fields can be used in the absence of 
a MAC according to the existing RFC 5905 and 5906.
o   Section 4 defines further extensions for using extension fields, and 
therefore updates RFC 5905. The intended status of the document was 
changed to ‘Standards Track’ accordingly.

Comments are welcome.
 
Thanks,
Tal.

---

From: Greg Dowd <[email-masked]>
Date: Fri, 15 Feb 2013 17:17:05 +0000

I think it must have been an editing error.  The overriding requirement that extensions be at least 28 bytes supports the original MAC.  There are legacy implementations that parsed the len to determine keytype (DES, MD5).  If it goes beyond that, then we'd have extensions.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 15, 2013 3:54 AM
To: [email-masked]; ntpwg-bounces+dieter.sibold=[email-masked]; Tal Mizrahi; Greg Dowd
Subject: Re: [ntpwg] Updated draft-mizrahi-ntp-extension-field

Regards
Dieter

 

 
Hi,

 
Comments are welcome.
 
Thanks,
Tal.

---

From: Danny Mayer <[email-masked]>
Date: Sun, 17 Feb 2013 23:03:32 -0500

Yes, I need to withdraw this. The reason for wanting this is that there
is no way to identify whether or not a MAC is present or an extension
field and it's just implied indirectly. This makes dealing with unknown
extension fields even more difficult and it was an attempt to reduce the
possible sources of implementation errors.

I managed to miss symmetric key authentication implementation which
apparently does not use an extension field. Worse is the fact that
symmetric key authentication is not documented in RFC5905 and going back
to look at RFC1305 Appendix C is not much better. Looking back at the
archives I found that I had raised this as an issue back in August 2008
but I had forgotten that too. See the WG exchange on this issue here:
http://lists.ntp.org/pipermail/ntpwg/2008-August/001393.html and was
never really resolved. We need to get symmetric key authentication
properly documented. Maybe a separate draft?

Longer term we need to consider a NTP v5 protocol which will then be
able to specify the existence of a MAC and its size as part of the base
part of packet. An additional issue is that the size of the MAC is not
fixed and can be one size for an MD5 generated MAC and another size for
an SHA generated MAC. Moreover it's not even clear which SHA we are
talking about. That's one of the reasons I pushed to have the MAC
implementation completely specified by the extension field in this draft,

Sorry for the delay in answering but I had to do some research first.
I'm not completely satisfied with my research but I was able to make it
clear that I cannot remove the MAC without an extension field.

My thanks to Harlan for useful discussions on this.

Danny

On 2/14/2013 12:38 PM, Greg Dowd wrote:
> Greg Dowd | *Symmetricom®, Inc.*
> 
> /Staff Scientist /
> [email-masked]
> <mailto:[email-masked]>  |  www.symmetricom.com
> <http://www.symmetricom.com/>
> 
> /Symmetricom.  Leading the world in precise time solutions./
> 
>  
> 
> *From:*ntpwg-bounces+gdowd=[email-masked]
> [mailto:ntpwg-bounces+gdowd=[email-masked]] *On Behalf Of
> *Tal Mizrahi
> *Sent:* Thursday, February 14, 2013 12:23 AM
> *To:* [email-masked]
> *Subject:* [ntpwg] Updated draft-mizrahi-ntp-extension-field
> 
>  
> 
> Hi,
> 
>  
> 
> o   Section 3 describes how extension fields can be used in the absence
> of a MAC according to the existing RFC 5905 and 5906.
>

---

From: Danny Mayer <[email-masked]>
Date: Sun, 17 Feb 2013 23:17:27 -0500

The problem with the key identifier in front of the digest is that there
is no way to know whether the key identifier is the first part of the
MAC or it's an extension field header. I haven't spent the time looking
at this in detail to work out whether it's realistic to be able to
differentiate between an extension field and a MAC. That might help
implementations but would require additional restrictions on extension
fields to ensure no errors in processing the extension fields and MAC.

Danny