Subject: [ntpwg] WG: Re: draft-ietf-ntp-cms-for-nts-message

From: [email-masked]
Date: Wed, 9 Mar 2016 13:22:45 +0100

Russ

from our point of view there is no real reason not to include the 
suggested changes. Apart from the CMS-draft we shall have to introduce 
additional changes at least to the draft-ietf-network-time-security in 
order to make non hmac  MAC algorithm negotiable.

We shall send you the proposed changes in the CMS draft  and also include 
the proposed ASN.1 module additions.

Dieter

-------------------------------------
Dr. Dieter Sibold
Physikalisch-Technische Bundesanstalt
Q.42 - Serversysteme und Datenhaltung
QM-Verantwortlicher der Stelle IT
Bundesallee 100 
D-38116 Braunschweig
Tel:    +49-531-592-84 20
E-Mail: [email-masked]

Russ Housley <[email-masked]> schrieb am 09.03.2016 00:34:50:

> Von: Russ Housley <[email-masked]>
> An: "Jim Schaad" <[email-masked]>
> Kopie: <[email-masked]>
> Datum: 09.03.2016 00:35
> Betreff: Re: draft-ietf-ntp-cms-for-nts-message
> 
> Jim:
> 
> That is a pretty simple change.  I support it.
> 
> Do the other authors of this document agree?
> 
> Russ
> 
> 
> On Mar 8, 2016, at 3:53 PM, Jim Schaad wrote:
> 
> > This draft popped up for an early review of content types due to the 
fact
> > that it is going to be released soon in OPENSSL.  I would like to 
strongly
> > push back on one of the features that is being placed in the 
structures for
> > algorithm selection.
> > 
> > You are fixing thing to only use HMAC by using the term hmacHashAlgos. 
 What
> > happens when NIST produces a MAC algorithm using the SHA-3 hash 
functions
> > which does not require HMAC?  Is there a reason for not making this 
field a
> > set of MAC algorithm identifiers?  RFC 4231 defines HMAC OIDs for all 
of the
> > SHA-2 algorithms and RFC 3370 defines the same for SHA-1.
> > 
> > Also, I experience a small irritation that you are not using 
authenticated
> > encryption but that is somewhat understandable.
> > 
> > Jim
> > 
> > 
> 

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

---

From: Danny Mayer <[email-masked]>
Date: Wed, 9 Mar 2016 12:48:21 -0500

My possibly erroneous assumption was that the protocol will include an
identifier to indicate which hashing algorithm to use for the digest and
that it be configurable outside the protocol. There shouldn't be any
limits on those algorithms especially as new ones become available on a
regular basis and it's better not to bake any particular flavour into
the protocol. Was I wrong?

I'm not sure I understood Jim's comment about authenticated encryption.
Can someone comment and explain what that means and what are the
implications and does it require an already valid time?

Danny

On 3/9/2016 7:22 AM, [email-masked] wrote:
> We shall send you the proposed changes in the CMS draft  and also
> include  the proposed ASN.1 module additions.
> 
> Dieter
> 
>> > You are fixing thing to only use HMAC by using the term
> hmacHashAlgos.  What
>> > set of MAC algorithm identifiers?  RFC 4231 defines HMAC OIDs for
> all of the

---

From: Richard Welty <[email-masked]>
Date: Wed, 9 Mar 2016 14:22:15 -0500

> the protocol. Was I wrong?
my plan for the reference implementation was to enforce the basic
requirement of the drafts (nothing weaker than sha-256) and otherwise
allow access to whatever OpenSSL provides. the ntp config file will
contain a list of what algorithms a particular ntp peer wishes to support,
with a sensible set of defaults.
the ordering of this list on the server end will determine algorithm
priority.

richard

-- 
[email-masked]
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search