Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt

From: Johannes Merkle <[email-masked]>
Date: Thu, 15 Jan 2015 11:19:04 +0100

Warren, Scott,

just one comment was received on the new draft (from David). Shall I revise the document accordingly and resubmit so
that we can go for LC?

Johannes

[email-masked] schrieb am 12.12.2014 um 23:30:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF.
> 
>         Title           : HMAC-SHA-2 Authentication Protocols in USM for SNMP
>         Authors         : Johannes Merkle
>                           Manfred Lochter
> 	Filename        : draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt
> 	Pages           : 13
> 	Date            : 2014-12-12
> 
> Abstract:
>    This memo specifies new HMAC-SHA-2 authentication protocols for the
>    User-based Security Model (USM) for SNMPv3 defined in RFC 3414.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-opsawg-hmac-sha-2-usm-snmp-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
> 
>

---

From: Warren Kumari <[email-masked]>
Date: Fri, 16 Jan 2015 16:21:10 -0500

Yup, please revise the document to address David's comment.

There was a fair bit of discussion around this document before it was
adopted, and so it did get a fair bit of review then, but some more
would be even better... We could get that at LC, but getting that
before WGLC would be nicer -- so, can some folk please volunteer to
review?

If we don't get any volunteers in the next week or two we'll force the
issue by going to LC... so, y'all can read it now, or you can read it
later. Now would be better :-)

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: t.petch <[email-masked]>
Date: Tue, 27 Jan 2015 18:09:53 +0000

I think that there are still some glitches (and I have yet to finish
reading it).

The names used for the four protocols are not consistent within the
document.  Following RFC3414, I think that including Auth is correct.

Updates to this registry requires a Standards Track document which this
is not.

MIB Module copyright is 2004

Does this document update RFC3414?  It adds to the registry that that
RFC created which some ADs say is NOT an update, some ADs say it IS an
update; I think that we need guidance here (the update by RFC5590 of
RFC3414 is a whole different ball game).

Tom Petch

----- Original Message -----
From: "Warren Kumari" <[email-masked]>
To: "Johannes Merkle" <[email-masked]>
Cc: <[email-masked]>; "Scott Bradner" <[email-masked]>
Sent: Friday, January 16, 2015 9:21 P

> > just one comment was received on the new draft (from David). Shall I
revise the document accordingly and resubmit so
> >>       Filename        :
draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt

---

From: t.petch <[email-masked]>
Date: Wed, 28 Jan 2015 18:39:30 +0000

Some more stray thoughts, having now read it all (but not followed up
the details of HMAC-SHA-2 - too gory).

s4.2.1 step 2 uses RFC6234 in a way that I think must make it a
Normative reference.  RFC6234 is not Standards Track but that is ok, it
is already in the list of IESG permitted downrefs (does that need
calling out at IETF Last Call?)

s9.1
/apply the use /apply to the use /

s9.2
is it the length of the key that gives it strength or its entropy?  Is
abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd0004
really stronger than
!qaurk/99SS~ ?

I look at RFC5310 here (although there may be something more recent and
better).

s9.4 refers to OBJECTS, but there aren't any, only IDENTITY so I think
that s9.4 should reflect that (lest it confuses, or am I confused having
missed an OBJECT somewhere?)

Tom Petch

----- Original Message -----
From: "t.petch" <[email-masked]>
To: "Warren Kumari" <[email-masked]>; "Johannes Merkle"
<[email-masked]>
Cc: <[email-masked]>; "Scott Bradner" <[email-masked]>
Sent: Tuesday, January 27, 2015 6:09 PM

> > >> A New Internet-Draft is available from the on-line
Internet-Drafts
> directories.
> > >>    This memo specifies new HMAC-SHA-2 authentication protocols
for
> the

---

From: Johannes Merkle <[email-masked]>
Date: Thu, 29 Jan 2015 09:03:17 +0100

Tom,

thanks for the thorough review. This really helps improving the document.

> calling out at IETF Last Call?)

You are right, but the question is whether I should rather use references [RFC2104] and [SHA] here.

> /apply the use /apply to the use /

Right.

> abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd0004

Strictly speaking, you are right, but it is common sense that cryptographic keys should have maximum entropy, i.e., they
should be selected uniformly at random from bit string of that length. Consequently, virtually all cryptographic papers
and text books use key the key length synonymous to its entropy. Thus, I consider this distinction as unnecessary.

> missed an OBJECT somewhere?)

Here I definitely need help, as I have no knowledge about MIBs. Actually, I copied that section from RFC 3411. Please
give advise what to write here or if this section is needed at all.

> document.  Following RFC3414, I think that including Auth is correct.
oops, this escaped my attention.

> Updates to this registry requires a Standards Track document which this

Wright. If the chairs agree, I'll change the track.

> MIB Module copyright is 2004

opps again. Copy and paste error.

> RFC3414 is a whole different ball game).

I will wait for the guidance here.

--
Johannes

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 29 Jan 2015 10:13:40 +0100

> give advise what to write here or if this section is needed at all.

The 'official' security considerations template for MIB modules can be
found here:

http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security

It does not really apply here since this MIB module only defines a
couple of constants. Perhaps write something along these lines:

  The SNMP-USM-HMAC-SHA2-MIB module defines OBJECT IDENTIFIER values
  for use in other MIB modules. It does not define any objects that
  can be accessed. As such, the SNMP-USM-HMAC-SHA2-MIB does not, by
  itself, have any effect on the security of the Internet.

  The values defined in this module are expected to be used with the
  usmUserTable defined in the SNMP-USER-BASED-SM-MIB [RFC3414]. The
  considerations in Section 11.5 of [RFC3414] should be taken into
  account.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: t.petch <[email-masked]>
Date: Thu, 29 Jan 2015 10:30:22 +0000

----- Original Message -----
From: "Johannes Merkle" <[email-masked]>
To: "t.petch" <[email-masked]>; "Warren Kumari" <[email-masked]>
Cc: <[email-masked]>; "Scott Bradner" <[email-masked]>
Sent: Thursday, January 29, 2015 8:03 AM

> You are right, but the question is whether I should rather use
references [RFC2104] and [SHA] here.

Don't know - this is the gory detail which I did not pursue - really
need an implementor to say if the older references are adequate for
SHA2; but as I say, a Normative reference to RFC6234 is fine if we want
it

> Strictly speaking, you are right, but it is common sense that
cryptographic keys should have maximum entropy, i.e., they
> should be selected uniformly at random from bit string of that length.
Consequently, virtually all cryptographic papers
> and text books use key the key length synonymous to its entropy. Thus,
I consider this distinction as unnecessary.

Yes but, consider the audience.  Cryptographic material is aimed at
cryptographers who know about entropy without being told, the audience
of this I-D is all sorts, including MIB module specialists whose
knowledge of cryptography is probably less than useless.  So I think
'length' is wrong, 'entropy' is probably too technical (especially if,
like me, Thermodynamics was part of your degree), RFC5310 uses 'size and
quality of the key' which is probably a good compromise.

> Here I definitely need help, as I have no knowledge about MIBs.
Actually, I copied that section from RFC 3411. Please
> give advise what to write here or if this section is needed at all.

RFC3826 is a good parallel here - it omits this paragraph entirely so I
would do the same, unless Juergen, Bert or Randy say otherwise.

No further comments on the points outstanding below (Standards Track I
consider a must, Updates RFC3414 not needed unless our AD requires it).

Tom Petch

---

From: t.petch <[email-masked]>
Date: Thu, 29 Jan 2015 13:58:24 +0000

Another stray thought.

I see RFC3412 in the references but cannot see it referenced in the
text.

And Juergen has responded on the question of what to put in the Security
Considerations so ignore my comments on that.

Tom Petch

----- Original Message -----
From: "t.petch" <[email-masked]>
To: "Johannes Merkle" <[email-masked]>; "Warren Kumari"
<[email-masked]>
Cc: <[email-masked]>; "Scott Bradner" <[email-masked]>
Sent: Thursday, January 29, 2015 10:30 AM
Subject: Re: [OPSAWG] I-D
Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt

> > > Normative reference.  RFC6234 is not Standards Track but that is
ok,
> > > RFC created which some ADs say is NOT an update, some ADs say it
IS
> an

---

From: t.petch <[email-masked]>
Date: Fri, 30 Jan 2015 10:21:37 +0000

Joel

One of the issues that I raise below on this I-D would benefit from AD
guidance.

The I-D adds entries to a registry established by RFC3411.  Should the
I-D then say that is updates RFC3411 or not?  My experience is that some
ADs say that this is NOT an update, while other ADs have said, at least
in the past, that it IS an update.   I would prefer that the I-D is in
line with your thinking before it advances.

Guidance please.

The nearest parallel in the SNMP world is RFC3826 which added an
snmpPrivProtocol to the registry also established by RFC3411, in June
2004, and which is not listed as updating any RFC.

Tom Petch

---

From: t.petch <[email-masked]>
Date: Fri, 30 Jan 2015 10:22:21 +0000

Warren

One of the points I raise below calls for input from the WG Chairs.

The registry that is being updated
http://www.iana.org/assignments/snmp-number-spaces/snmp-number-spaces.xh
tml#snmp-number-spaces-5
requires Standards Track for updating.  The current I-D is
Informational.  This will hit a brick wall when it reaches IANA (I-d
Advancement Not Admissible).

Johannes wisely said that that he would look for the agreement of the
chairs for this change.

Do you agree?

Tom Petch

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Fri, 30 Jan 2015 12:13:41 +0100

My personal view is that it does NOT update RFC3411.
It adds an entry to a registry that we maintain at IANA, right?

WHen other IANA-maintained registries get an entry added, then
that also does not mean that some other RFC (That established the registry
and that specified the rules for adding entries) gets updated either
(I would hope).

Bert