Subject: [ntpwg] Autokey refilihng - my point...

From: Todd Glassey <[email-masked]>
Date: Sun, 25 Oct 2009 12:43:15 -0700

Brian - my point in asking to advance the autokey draft is both based in 
getting NTP further along to its v4 standards status and also in getting 
the autokey component more formalized than 'an informational' status 
since its in use in production in many shops around the world, that is 
no longer appropriate. Autokey as it is implemented today works and is 
relied on, so we need to get what is out their today documented as an 
in-place accepted standard.

If you want to make changes to the protocol itself that's fine but dont 
hold up acknowledging what's already in pervasive use in the world for 
secure NTP.

Todd Glassey
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: Brian Haberman <[email-masked]>
Date: Sun, 25 Oct 2009 18:18:20 -0400

Todd,

> hold up acknowledging what's already in pervasive use in the world for 

My point is not to hold up the spec, but it can't advance unless it can 
clearly specify how OIDs for the algorithms in use are converted to NIDs 
for use in the Status Word.  The current text refers to an RFC that only 
defines the OIDs for the various Signature and Digest schemes and not 
the NIDs carried by NTP.  This is not changing the protocol, it is 
providing a way to have inter-operable implementations of Autokey.

Regards,
Brian

---

From: Danny Mayer <[email-masked]>
Date: Sun, 25 Oct 2009 18:36:50 -0400

> in-place accepted standard.

Advancing the NTP draft has nothing whatsoever to do with the Autokey
draft. The autokey *is* documented by the autokey draft. An
informational draft is much better than none at all. Getting the autokey
draft to proposed standard track has a *much* higher hurdle to pass than
informational and *requires* very serious security review. Since the
security side of autokey is very complex and there are many pages
devoted to it in the draft this will take a long time to review, have
questions answered, draft updated to reflect those questions and
answers, and so on. Don't expect a short period for IESG to approve such
a draft. The NTP draft, in the meantime, needs to proceed forward.

> hold up acknowledging what's already in pervasive use in the world for 

Pervasive use? I don't think so, but that's a matter of numbers and has
no affect whatsoever on the IETF. Noone has suggested a change to the
protocol itself, just finding references to the way something is done.
If you see a change of protocol, please state explicitly what it is.
Since autokey has already passed Working Group review, it would have to
be pulled back to the working group to change the protocol and then
resubmitted to IESG.

Danny

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 26 Oct 2009 09:05:15 +0000

> be pulled back to the working group to change the protocol and then
It would also need to go for IETF LC before it went to the IESG.

Given where the document is, the best strategy would be to continue with 
Informational.
That can only reduce the time taken to PS. The issues Brian raises are 
real, and need to be
addressed before a PS can be published, and the sooner the process of 
starting to address
then starts, the sooner it will finish.

- Stewart

---

From: Todd Glassey <[email-masked]>
Date: Mon, 26 Oct 2009 08:20:55 -0700

Brian Haberman wrote:
> Todd,
>
> Todd Glassey wrote:
>> Brian - my point in asking to advance the autokey draft is both based 
>> in getting NTP further along to its v4 standards status and also in 
>> getting the autokey component more formalized than 'an informational' 
>> status since its in use in production in many shops around the world, 
>> that is no longer appropriate. Autokey as it is implemented today 
>> works and is relied on, so we need to get what is out their today 
>> documented as an in-place accepted standard.
>>
>> If you want to make changes to the protocol itself that's fine but 
>> dont hold up acknowledging what's already in pervasive use in the 
>> world for secure NTP.
>
> My point is not to hold up the spec, but it can't advance unless it 
> can clearly specify how OIDs for the algorithms in use are converted 
> to NIDs for use in the Status Word.  
Sure if the current draft is advanced. It may be that we need to create 
a more restrained draft which documents how it actually works in 
production today since this is a trailing-edge effort.
> The current text refers to an RFC that only defines the OIDs for the 
> various Signature and Digest schemes and not the NIDs carried by NTP.  
> This is not changing the protocol, 
Sure it is - it seeks to change how existing implementations of AutoKEY 
work, and that is the issue - it doesnt matter whether the current 
version of AutoKEY works everywhere or not - it is what's in production 
and it is what people who rely on IETF Standards to codify what they are 
already using need the IETF to embrace, and if the NTPWG wants to change 
it next time around that is fine - but NTP is already a key part of 
auditing and it needs to be standardized as it is today to insure proper 
controls on the reference ports and that testing can be done properly 
outside the IETF. So it doesnt matter that you want to fix AutoKEY so 
that there are interoperable versions of NTP, what matters is 
standardizing what is in production use now.

Todd Glassey
> it is providing a way to have inter-operable implementations of Autokey.
>
> Regards,
> Brian
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.423 / Virus Database: 270.14.31/2458 - Release Date: 10/25/09 08:10:00
>
>

---

From: Todd Glassey <[email-masked]>
Date: Mon, 26 Oct 2009 08:22:48 -0700

Danny Mayer wrote:
> draft. The autokey *is* documented by the autokey draft. 
As an INFORMATIONAL DRAFT only Danny - and you may not like that this 
limits the use of this but its the way it is. Otherwise there is no 
purpose in having a standards track at all.
> An
> informational draft is much better than none at all. dd

No Danny - an Informational Draft is just that - informational in form 
and not to be used in any part of a standards process.

To
> Getting the autokey

---

From: Todd Glassey <[email-masked]>
Date: Mon, 26 Oct 2009 08:26:31 -0700

Stewart Bryant wrote:
> Given where the document is, the best strategy would be to continue 
> with Informational.
No its not. But I am betting you have a financial interest in keeping 
NTP where it is considering the pain you will have to go through with 
IOS to fix them.
> then starts, the sooner it will finish. 
Then no one can use NTP with AutoKEY in production Stewart if they are 
regulated and one of their security controls is 'that only vetted and 
tested technologies are used in their IT' department. You know Sorta 
like your company Cisco does Stewart... If you doubt me ask the 
compliance director over at corporate. I will forward you the number off 
list.

Todd
> Version: 8.5.423 / Virus Database: 270.14.32/2459 - Release Date: 10/25/09 19:57:00
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 26 Oct 2009 15:47:41 +0000

> NTP where it is considering the pain you will have to go through with 
That is a completely inappropriate remark and I require an apology to 
the list!

>
>> That can only reduce the time taken to PS. The issues Brian raises 
>> are real, and need to be
> compliance director over at corporate. I will forward you the number 
> off list. 
Sure, so start the process of getting this to PS. From the thread the 
first thing you
need to do is to provide proof positive of an independent 
implementation, then
you should provide Brian with the text he asked for. However I do not 
see why
that should stop NTP WG from continuing with the plan of record to take 
this to
Informational in the meantime.

- Stewart

---

From: Todd Glassey <[email-masked]>
Date: Mon, 26 Oct 2009 09:47:05 -0700

> That is a completely inappropriate remark and I require an apology to 
No there is NO apology coming, and for the record - this demand of yours 
is an attack and a misrepresentation of my words. This was not pointed 
at you personally but rather the people you work for and it was ONLY an 
observation as to what it would cost in time and money a company with 
the deployment footprint (as in millions of devices)  like Cisco's to 
fix an NTP issue  through a firmware release, so there was NO personal 
commentary pointed at you. But since you have insisted there is we 
should get John Chandler involved in this - do you want to call him or 
should I?

> that should stop NTP WG from continuing with the plan of record to 
> take this to
Because Stewart there are already hundreds and hundreds of instances in 
use where AutoKEY as it is today is in use and is in production. I have 
about 300 client's using it already myself.
> Version: 8.5.423 / Virus Database: 270.14.32/2460 - Release Date: 10/26/09 08:10:00
>
>

---

From: Danny Mayer <[email-masked]>
Date: Mon, 26 Oct 2009 21:56:03 -0400

> production today since this is a trailing-edge effort.

Which is exactly what this document is doing.

> version of AutoKEY works everywhere or not - it is what's in production 

That is exactly what this document is doing. There are no changes to the
protocol.

> already using need the IETF to embrace,

The IETF doesn't have to do anything, that's not an IETF requirement.

> and if the NTPWG wants to change it next time around that is fine

I have yet to see any requests to change the protocol. The OID<->NID
question has to do with standardizing what's already been implemented.

 - but NTP is already a key part of
> outside the IETF.

IETF does not specify or test any controls whatsoever and is outside the
scope of this document. Remember that there is no Internet police to
enforce anything. Vendors can only make claims as to what they support
but the IETF cannot prevent someone from implementing something
nonconforming.

 So it doesnt matter that you want to fix AutoKEY so
> standardizing what is in production use now.

What interoperability problems? We are fixing nothing, just documenting
it. If you think some is broken why don't you say exactly what is broken
and how?

Danny

---

From: Danny Mayer <[email-masked]>
Date: Mon, 26 Oct 2009 22:01:23 -0400

> purpose in having a standards track at all.

It limits noone in any way and certainly not me. If it limits you, why
are you not buckling down and getting it docmented in such a way that it
can go through on the track you want? If you aren't willing to do the
work why should you expect others to do it for you?

> and not to be used in any part of a standards process.

So what?

Danny

---

From: Danny Mayer <[email-masked]>
Date: Mon, 26 Oct 2009 22:06:09 -0400

> NTP where it is considering the pain you will have to go through with

Does IOS have its own implementation of NTP or does it just use the
reference implementation? If the latter then all they have to do is to
upgrade to the latest version of NTP reference implementation. Do you
even know or are you commenting for the sake of it?

> compliance director over at corporate. I will forward you the number off

This has nothing to do with the IETF and is completely off-topic.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Mon, 26 Oct 2009 22:12:17 -0400

> about 300 client's using it already myself.

Nobody cares about this. Either provide and alternate draft or provide
fixes to the current draft. Noone is going to bother with your comments
otherwise. Are you unable to produce a draft?

Danny