Subject: Re: [ntpwg] Autokey

From: Danny Mayer <[email-masked]>
Date: Sat, 17 Oct 2009 23:19:05 -0400

Dave,

My understanding of this was that the editors and/or chairs felt it
would be too difficult, given the security questions, to get it through
on standards track. I too would prefer standards track.

I haven't heard of another implementation of autokey. Pray tell us more
as this could give an impetus to this document.

Danny

David Mills wrote:
> Danny,
> 
> I have had several jousts with the IESG reviewers, one of which asked me 
> why the document was not on the standards track, especially since all 
> but one reference to the reference implementation was removed by 
> request. I told them my personal preference was that it be on the 
> standards track, especially since there apparently is now another 
> implementation. The opinion of the WG as a group might be different, in 
> which case the IESG should be so advised.
> 
> Dave
> 
> Danny Mayer wrote:
> 
>> Todd Glassey wrote:
>>  
>>
>>> Danny Mayer wrote:
>>>    
>>>
>>>> Todd Glassey wrote:
>>>>
>>>>      
>>>>
>>>>> In regard to this I-D, its according to the filing obsoletes the
>>>>> RFC1305 document which doesnt seem possible since it is not a RFC,
>>>>> and thoughts?
>>>>>
>>>>> Todd
>>>>>    
>>>>>        
>>>>>
>>>> Obsoleting an RFC can only happen when the draft becomes an RFC. When
>>>> issuing a draft you need to state any RFC that will be obsoleted by the
>>>> adoption of the draft. That has nothing to do with Dave, it's standard
>>>> IETF process.
>>>>
>>>>  
>>>>      
>>>>
>>> Danny my concern was that this document is filed for informational
>>> purposes and I am getting underwriting for NTP and the bonding house
>>> wants that in place.  So I want to make sure NTPv4 RFC happens as soon
>>> as possible since its already in use.
>>> Todd
>>>    
>>>
>> The draft is informational so the bonding house will probably be
>> disappointed that it's not a proposed standard. That of course has
>> nothing to do with the NTPv4 draft RFC.
>>
>> Danny
>>
>>  
>>
> 
> _______________________________________________
> ntpwg mailing list
> [email-masked]
> https://lists.ntp.org/mailman/listinfo/ntpwg
> 
> 

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

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

---

From: Brian Haberman <[email-masked]>
Date: Sun, 18 Oct 2009 08:05:40 -0400

The publication status of Autokey was decided when the working group was 
first started.  The Area Directors at the time thought that 
Informational was appropriate given there was a single implementation 
and there was some concerns within the Security Area of the IETF on the 
actual security model used for Autokey. Now, it has been a long enough 
process that we have almost completely changed over the membership of 
the IESG, hence the information loss on the publication status.

If the working group wants to revisit the publication status of Autokey, 
we can do that.  I will note that changing the status to Proposed 
Standard will hold it to a higher level of review.

Regards,
Brian

---

From: Todd Glassey <[email-masked]>
Date: Sun, 18 Oct 2009 07:59:32 -0700

I am submitting a new utility proposal to the WG for consideration. I 
will not submit the draft contents to this WG until it agrees that it 
will allow this new proposed material to the official reference port 
definitions. I will in doing this formally assign all rights in this 
utility to the IETF so this one is good to go under the BCP78/79 IPR 
submission rules - the IETF can own their republication rights in this...

We talked about using NTP to time-stamp documents and its time to 
revisit that - please read the rest of this proposal before dismissing 
it as more of Todd's ranting about the need for reliable evidence in 
time management.

---

NTPStamp - What is it? It is a stripped down version of NTPDATE which I 
call NTPStamp and  which is used to time-stamp a Payload-1 HASH which is 
included in the process. For the target hash we use Payload-1 and 
respond with the signed hash in Payload-2 for our EC-Signed Response 
Hashes.

The purpose of this NTPStamp is a simple third-party evidence service 
which can be tied to the same trust-anchor (the responsible NTP Server) 
who provided the time of day (TOD) that the host is relying on. NTPStamp 
is a one-way trip and it is used to create not verify time-signed hashes 
which are then returned to a central logging service for historical 
archival uses and the client. The justification for building NTPStamp is 
that digital evidence which is tied to time needs to be capable of being 
taken from the same source of time which the host's TOD was taken from 
to remain consistent.

This NTP Time-Stamping Service allows for virtually tens of thousands of 
documents to be time-stamped seamlessly inside of a business process at 
nearly a zero adoption overhead since NTP is already used in one form or 
another pretty much everywhere - including inside MS-SNTP...  and 
NTPStamp since it is not a verification tool it is much simpler than 
RFC3161's complex operating requirements, and it is fully compliant with 
the Legal Metrological Agreements we are tied to today so this makes NTP 
a one-stop shop for all kinds of compliance efforts and will increase 
the importance of NTP significantly in the world.

Be advised we (Certichron) are already using this also as a piece of a 
PCI DSS compliance practice so it is likely to get used everywhere on 
the Earth and bazillions of times daily if its done right.

To that end, I want test the waters for this since the code already 
exists and is in production in our and a number of our clients shops as 
part of EMail certification processes and receipt acknowledgments 
services which we offer commercially. To that end the use of NTP as the 
core time-stamping service is so obvious from an Evidence Practice since 
it eliminates the questions of accuracy and integrity in the process.

Todd Glassey
Your favorite pain in the #$%^&*()_

---

From: Todd Glassey <[email-masked]>
Date: Sun, 18 Oct 2009 08:07:56 -0700

> Standard will hold it to a higher level of review.
Brian (and DLM)  - I think the informational AutoKEY I-D needs to be 
refiled on the Standards Track so that we can advance the already proven 
security model to RFC status ASAP and since it is already in production 
on tens of thousands of client sites around the world, get this 
acknowledged as "how it is done" by the IESG.

To accomplish that I suggest that the draft is refiled by the Editor's 
as a Standards Track work immediately so we don't lose another six 
months on this procedural error. I would also ask the IESG to accept 
that since AutoKEY is already in production with  the NTPv4 reference 
port and those that claim interoperability with it, that this is a 
perfect instance of IETF Trailing-Edge Standards work and that we 
already meet the standards of interoperability requirement to jump to a 
Draft-Standard Status.

Any thoughts on this - more below...

>> on standards track. I too would prefer standards track.
Yes but we can work with the security questions just like DNSSEC did. 
This is really important and we need to move forward on it as a 
community IMHO.
>> as this could give an impetus to this document.
There are no other implementations - there is my 'autokey unplugged' 
service which replaced the autokey code with the BERT TOKEN interface 
(BTI) and the LDAP lookup services for it, but beyond that and my new 
dual-protocol model of NTP (where all the upfront negotiations are done 
through a SSL tunnel meaning that they are TCP in form and capable of 
using a client-supplied key instance for the event signing which honors 
proper certificate handing under the Federal PKI Bridge Rules to allow 
for Federal Agencies to use this exclusively) there are no other 
instances of competing authentication schemes.

Todd Glassey
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.422 / Virus Database: 270.14.20/2443 - Release Date: 10/17/09 13:08:00
>
>

---

From: David Mills <[email-masked]>
Date: Mon, 19 Oct 2009 02:58:30 +0000

Danny,.

Were you the one who told me there was another implementation or was it 
Dave Hart? I know that implementation exposed a problem which we fixed.

Brian,

The culturally correct way to proceed is to continue on the 
Informational Track and strike up a new WG with the mission of studying 
NTP security issues and proposing Autokey as a work item. Ordinarily, I 
would be the first to beat that drum, but my faculties and vision have 
deteriorated (but not my mind!), so travel is difficult. However, there 
might be other drummers, possibly including Danny and/or Dave Hart, two 
of the most intrepid warriors in the NTP tribe.

If there is a shorter path to Standards Track, lets take it; however, an 
NTP security WG would still be a good idea.

Dave

Brian Haberman wrote:

> The publication status of Autokey was decided when the working group 
> was first started.  The Area Directors at the time thought that 
> and there was some concerns within the Security Area of the IETF on 
> the actual security model used for Autokey. Now, it has been a long 
> enough process that we have almost completely changed over the 
> membership of the IESG, hence the information loss on the publication 
> status.
>
> If the working group wants to revisit the publication status of 
> Autokey, we can do that.  I will note that changing the status to 
> Proposed Standard will hold it to a higher level of review.
>
> Regards,
> Brian
>
> Danny Mayer wrote:
>
>> Dave,
>>
>>> I have had several jousts with the IESG reviewers, one of which 
>>> asked me why the document was not on the standards track, especially 
>>> since all but one reference to the reference implementation was 
>>> removed by request. I told them my personal preference was that it 
>>> be on the standards track, especially since there apparently is now 
>>> another implementation. The opinion of the WG as a group might be 
>>> different, in which case the IESG should be so advised.
>>>
>>> Dave
>>>
>>> Danny Mayer wrote:
>>>
>>>> Todd Glassey wrote:
>>>>  
>>>>
>>>>> Danny Mayer wrote:
>>>>>   
>>>>>
>>>>>> Todd Glassey wrote:
>>>>>>
>>>>>>     
>>>>>>

---

From: Brian Haberman <[email-masked]>
Date: Sun, 25 Oct 2009 08:56:47 -0400

> Standard will hold it to a higher level of review.

I have gotten a single response so far stating that Proposed Standard 
was desired.  That will not cut it from a consensus perspective.

We also have a pretty significant problem in the document, especially if 
people think it should be a PS document.  Perhaps someone here can help 
with the issue.  The Status Word contains a 16-bit field to hold the 
Digest/Signature NID.  This field is populated by using the OpenSSL 
mapping function (e.g., obj2nid()) to convert the OID for the 
digest/signature scheme defined in RFC 3279 into a 16-bit number. 
However, the document does not provide a reference for that OID<->NID 
mapping, so we have a referential problem with the Autokey spec.  As it 
stands, we have a normative dependency on the OpenSSL *code*.  What we 
need is a reference to a document that describes the mapping.

If we stay at Informational, I can probably add the current mappings 
from the OpenSSL code to the spec and make the document self-containing. 
  Going to PS would probably require a stable reference in order to 
allow future digests/signatures to be added.

Is anyone aware of an existing document that describes the OpenSSL 
mapping of OIDs to NIDs?

Regards,
Brian

---

From: Danny Mayer <[email-masked]>
Date: Sun, 25 Oct 2009 10:27:01 -0400

In case I didn't make my own opinion clear, I would *like* to have it as
a proposed standard but I won't object to it just being informational.

I will see what I can find about the OID<->NID issue.

Danny