Subject: [OPSAWG] Fwd: New Version Notification for draft-hmac-sha-2-usm-snmp-00.txt

From: Johannes Merkle <[email-masked]>
Date: Mon, 24 Mar 2014 13:35:24 +0100

Dear all,

a while ago, I had announced a draft on a new USM authentication protocol HMAC-SHA-256-128 for use in SNMP. Following
Uri's suggestion (and with his valuable support) I have considerably extended the draft:
 - Further SHA-2 based HMAC authentication protocols have been included to provide ore flexibility.
 - A (short) section explains how to perform key change and key localization with these protocols
 - A MIB definition has been added.

URL:            http://www.ietf.org/internet-drafts/draft-hmac-sha-2-usm-snmp-00.txt
Status:         https://datatracker.ietf.org/doc/draft-hmac-sha-2-usm-snmp/
Htmlized:       http://tools.ietf.org/html/draft-hmac-sha-2-usm-snmp-00

Abstract:
   This memo specifies new optional HMAC-SHA-2 authentication protocols
   for the User-based Security Model (USM) for SNMPv3 defined in RFC
   3414.

Due to the extension of the draft to other SHA-2-based HMAC, I have changed the draft name from
	draft-hmac-sha-256-128-usm-snmp
to
	draft-hmac-sha-2-usm-snmp
resulting in a reset of the version number (00).

Is there interest in adoption of this draft by the WG?

Johannes

---

From: David Reid <[email-masked]>
Date: Mon, 24 Mar 2014 14:00:40 -0400

I think this should be adopted by the working group. I'm willing to
review the document and most likely implement it.

-David Reid

> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Melinda Shore <[email-masked]>
Date: Mon, 24 Mar 2014 10:47:40 -0800

> Is there interest in adoption of this draft by the WG?

Hi, Johannes:

We're trying to make sure that documents get adequate review
before adoption by the working group, so before we put out a
call for adoption we're going to try to get feedback from
someone who can provide cryptographic review and someone on
the snmp side.  We'll start that process moving.

Melinda

---

From: t.petch <[email-masked]>
Date: Tue, 25 Mar 2014 15:33:50 +0000

I am confused by your choice of names.  The text uses, e.g.,
usmHMACSHA224128AuthProtocol

whereas the MIB module has

 usmHmacSha224128Protocol

Do these refer to the same identity (times six)?

I think that the IANA Considerations needs more work; you might want to
review RFC4181 for a more detailed approach but you need at least
something along the lines of an explicit request that the MIB module be
assigned a number under the appropriate tree, eg

.1 IANA is requested to assign an object identifier for

   Descriptor        OBJECT IDENTIFIER value
         ----------        -----------------------
  snmpUsmHmacSha2MIB           { snmpModules XXX }

[with XXX harking back to the same string in the MIB module itself].

And then for each algorithm, so that the entries in IANA can be tied
into the text of the final RFC,

.2 IANA is requested to assign a value in the SnmpAuthProtocols registry
for each of

Value                 Description                        Reference

aa   usmHMACSHA224128AuthProtocol     RFC YYYY
bb   usmHMACSHA256128AuthProtocol    RFC YYYY
cc   usmHMACSHA256192AuthProtocol    RFC YYYY
dd   usmHMACSHA384256AuthProtocol    RFC YYYY
ee   usmHMACSHA512256AuthProtocol    RFC YYYY
ff    usmHMACSHA512384AuthProtocol    RFC YYYY

-- RFC Ed.: replace YYYY with actual RFC number & remove this line

with aa bb cc  etc appearing in the MIB Module.  As it stands, you might
appear to be requesting that all six get the same value, namely mm.

And then there are Security Considerations.  You are replacing a simple,
well understood choice of two values with a choice of eight, and saying
that there is no need to implement them all.  This gives great scope for
a lack of interoperability.  Should there be a mandatory to implement
value (or negotiation - perhaps not)?

I would like to see some discussion of the benefits, if any, of the six
new options.  I have seen discussions along these lines on the TLS WG
list (with a considerable degree of expertise in cryptography present)
that makes it far from clear cut what the best choice is, and that what
appears to be the strongest may not be a good choice for IETF protocols.

Tom Petch

----- Original Message -----
From: "Johannes Merkle" <[email-masked]>
To: <[email-masked]>
Cc: "Manfred Lochter" <[email-masked]>; <[email-masked]>
Sent: Monday, March 24, 2014 12:35 PM
Subject: [OPSAWG] Fwd: New Version Notification
fordraft-hmac-sha-2-usm-snmp-00.txt

> Dear all,
>
> a while ago, I had announced a draft on a new USM authentication
protocol HMAC-SHA-256-128 for use in SNMP. Following
> URL:
http://www.ietf.org/internet-drafts/draft-hmac-sha-2-usm-snmp-00.txt
> Status:
https://datatracker.ietf.org/doc/draft-hmac-sha-2-usm-snmp/
> Htmlized:
http://tools.ietf.org/html/draft-hmac-sha-2-usm-snmp-00

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 25 Mar 2014 11:52:07 -0400

>Do these refer to the same identity (times six)?

I think yes, and would suggest the following (unified) name format:

usmHMAC128SHA224AuthProtocol

for all of them.

>assigned a number under the appropriate tree, e.g.,..............

I'll leave this to Johannes to take care of. :-)

>value (or negotiation - perhaps not)?

Can we have mandatory-to-implement in an "optional" RFC? Assuming the
answer is yes, I'd recommend:

For those who implement this RFC, usmHMAC192SHA256AuthProtocol is MUST,
usmHMAC384SHA512AuthProtocol is SHOULD, everything else is MAY. Unless
there's a preference for the "non-truncated" algorithms.

>new options.

Do you mean "the benefits of having so many rather than just one or two",
or do you mean "the benefits of adding SHA2-based auth"?

If it's the first - then we probably can shrink the number of the
available choices. The question is - do we select truncated ones (as the
prior standards did), or not?

If it's the second - I'll let others speak. :-)

>I have seen discussions along these lines on the TLS WG

Honestly I don't think TLS WG is a good example here, considering the
complexity of the protocol, and the kind of problems they're facing and
are trying to address. But your point is taken.

TNX!

---

From: t.petch <[email-masked]>
Date: Tue, 25 Mar 2014 17:35:08 +0000

A further thought.

The update policy for SnmpAuthProtocols is Standards Track, so at
present this I-D - Informational - will not do.

And while an Individual Submission can be Standards Track, ADs often
prefer it to be a WG I-D.

Tom Petch

----- Original Message -----
From: "Melinda Shore" <[email-masked]>
To: "Johannes Merkle" <[email-masked]>
Cc: "Manfred Lochter" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, March 24, 2014 6:47 PM

---

From: Johannes Merkle <[email-masked]>
Date: Tue, 25 Mar 2014 19:03:01 +0100

>> Do these refer to the same identity (times six)?

Good catch!

> usmHMAC128SHA224AuthProtocol

I like this proposal, because it is easier to read.

> I'll leave this to Johannes to take care of. :-)

Yeah, I'll take care of this.

> Can we have mandatory-to-implement in an "optional" RFC? 

AFAIK this is common.

> Assuming the answer is yes, I'd recommend:

I had already received very positive feedback on the first draft (which specified merely usmHMAC128SHA256AuthProtocol),
.e.g.

Thus, I have no clear preference here, but Uri's proposal is fine for me.

> prior standards did), or not?

All versions use truncated HMAC, the difference lies in the degree of truncation. You probably mean "do we select the
variants using 50% truncation or those with 75% truncation?"

I don't think that interoperability is really a big issue. Crypto libraries typically support most, if not all SHA-2
hash functions. Futhermore, implementing two different lengths for truncation is trivial. Thus, I do not see why anyone
should implement usmHMAC384SHA512AuthProtocol but not usmHMAC256SHA512AuthProtocol.

But, yes, if required for WG consensus, I do not object to remove some variants.

>From Tom's responses to our first draft, I understand that he does not question that SHA2 based HMAC authentication is
useful.

> are trying to address. But your point is taken.

I think Tom is referring to the discussion regarding MAC truncation, which was a sideline of the discussion about the
optimal order of encryption and MAC in TLS.
http://web.archiveorange.com/archive/v/aFZ9KRJi4JLUvLRo8Ek7
http://web.archiveorange.com/archive/v/aFZ9KQVpfdL7WYG1B9l7

The second thread cites Bart Preneel saying
"On the other hand, several (key recovery)
attacks on MAC algorithms (including HMAC-MD4 and HMAC-MD5)
have been found based on internal collisions. These attacks
would become more difficult if fewer output bits are available.
[...]
My conclusion is that my intuition as cryptanalyst was correct
and that it would be best to shorten the output of a MAC
algorithm to half the internal state."
This recommendation is also included in the seminal paper of van Oorschot and Preneel (page 11)
ftp://ftp.esat.kuleuven.ac.be/cosic/preneel/mdxmac_crypto95.ps.gz
For the SHA-2 family, the length of the internal state is 256 bits for SHA-224 and SHA-256 and 512 bits for SHA-384 and
SHA-512 (recall that SHA-224 and SHA-384 are truncated SHA-225 and SHA-512, respectively, with modified constants). This
recommendation results in HMAC128SHA224, HMAC128SHA256, HMAC256SHA384, HMAC256SHA512.

On the other hand, shortening the output length reduces the strength against collision attacks. Thus, we were not
completely comfortable with the 50% truncation for SHA-256 and SHA-512. On the other hand, AFAIK, there are no clear
cryptanalytic results about truncation, let alone on the optimal degree of truncation. For this reason, we also included
HMAC192SHA256 and HMAC384SHA512.

-- 
Johannes

---

From: David Reid <[email-masked]>
Date: Tue, 25 Mar 2014 14:06:01 -0400

> usmHMAC128SHA224AuthProtocol

I like Uri's suggested name format.

> prior standards did), or not?

I would prefer shrinking the number of choices and using the truncated 
ones, although I don't feel strongly about that preference.

> If it's the second - I'll let others speak. :-)

For me, the benefit of adding SHA2-based auth is that I have
customers asking for it. (a small number of customers, but
enough to justify the work since it is very low cost to implement).

-David Reid

---

From: Melinda Shore <[email-masked]>
Date: Tue, 25 Mar 2014 10:11:41 -0800

> prefer it to be a WG I-D.

Right, and if there's interest, energy, and review, we'll
put out a call for adoption.  So, this discussion so far has
been extremely helpful.

Melinda

---

From: t.petch <[email-masked]>
Date: Thu, 27 Mar 2014 14:23:59 +0000

Right!

On the names, I am happy with whatever you choose, as long as the I-D is
internally consistent!  The existing one is usmHMACSHAAuthProtocol so
that looks like a good model to follow, which Uri's suggestion does.

As to how many, I am uncomfortable with giving implementers the choice
of eight along with the statement that you do not have to implement them
all, which, for me, invites a lack of interoperability, regardless of
whether or not the crypto libraries have all the options available so
making them easy to implement!  So my thinking would be either a MUST
implement for one, or recommend that all should be implemented, with a
recommended order to choose, or some such - just not the current
wording.

As to MUST, this I-D will have to be Standards Track, not Informational,
in order to update SnmpAuthProtocols so the use of requirements
language, and the boiler plate thereon, is not an issue.

On Security, I have memories of discussions on the TLS list of the
merits of size and truncation.  One reference I have found is
'SHA-1 is being deprecated'
from 2008 from one 'Uri' - so I think something along those lines worth
including by way of justification for this I-D (Suite B got a lot of
mentions around that time).  I have memories of an argument against the
use of SHA-512, I think on the grounds that the registers were not wide
enough and that the extra security did not justify the extra computation
required, but cannot find a reference for that.  As to degree of
truncation, I understand the argument in principle but do not have the
mathematics to take a view as to what is best.  I do note that in 2006,
it was suggested that the merit of truncation was to save bandwidth in
constrained environments - I don't know if that is now more or less
applicable.  So I would like to see more in the Security Considerations
along these lines with a target audience of non-cryptographers.

Tom Petch

----- Original Message -----
From: "Johannes Merkle" <[email-masked]>
To: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>; "t.petch"
<[email-masked]>; <[email-masked]>
Cc: "Manfred Lochter" <[email-masked]>
Sent: Tuesday, March 25, 2014 6:03 PM
> I had already received very positive feedback on the first draft
(which specified merely usmHMAC128SHA256AuthProtocol),
> All versions use truncated HMAC, the difference lies in the degree of
truncation. You probably mean "do we select the
> I don't think that interoperability is really a big issue. Crypto
libraries typically support most, if not all SHA-2
> hash functions. Futhermore, implementing two different lengths for
truncation is trivial. Thus, I do not see why anyone
> From Tom's responses to our first draft, I understand that he does not
question that SHA2 based HMAC authentication is
> I think Tom is referring to the discussion regarding MAC truncation,
which was a sideline of the discussion about the
> For the SHA-2 family, the length of the internal state is 256 bits for
SHA-224 and SHA-256 and 512 bits for SHA-384 and
> SHA-512 (recall that SHA-224 and SHA-384 are truncated SHA-225 and
SHA-512, respectively, with modified constants). This
> On the other hand, shortening the output length reduces the strength
against collision attacks. Thus, we were not
> completely comfortable with the 50% truncation for SHA-256 and
SHA-512. On the other hand, AFAIK, there are no clear
> cryptanalytic results about truncation, let alone on the optimal
degree of truncation. For this reason, we also included

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Thu, 27 Mar 2014 12:46:44 -0400

>Right!

:-)

>....a good model to follow, which Uri's suggestion does.

:-) Yep!

>making them easy to implement!

Hmm... Yes, but the whole reason the NIST standard defined several was
that different applications have different needs & requirements.
Otherwise, why not just define/standardize SHA512, and say "if you need
fewer bits - mix/truncate"?

>So my thinking would be either a MUST implement for one, or recommend
>that all should be implemented, with a
>recommended order to choose, or some such - just not the current wording.

I personally would be OK with this. One would be MUST, one or two would be
SHOULD, the rest would be MAY in the given order.

Yes it could affect interoperability, on the other hand - the market can
help sorting this part out. :-)

>in order to update SnmpAuthProtocols so the use of requirements language,
>and the boiler plate thereon, is not an issue.

I'd have no problem with this RFC going Standards Track. Johannes?

>On Security, I have memories of discussions on the TLS list of the merits
>of size and truncation.  One reference I have found is 'SHA-1 is being
>deprecated' from 2008 from one 'Uri' - so I think something along those
>lines worth
>mentions around that time).

:-)  Oh yes. And the TLS list discussion is an echo of the former IPsec
list discussion.

Not sure if it's a good idea to bring Suite B up at this time?

>I have memories of an argument against the use of SHA-512, I think on the
>grounds that the registers were not wide
>required, but cannot find a reference for that.

I don't recall that, probably didn't care back then. In any case, (a) I
don't think these arguments apply now, and (b) SHA512 would be only SHOULD
if things go the way I'd like...

>As to degree of truncation, I understand the argument in principle but do
>not have the mathematics to take a view as to what is best.  I do note
>that in 2006, it was suggested that the merit of truncation was to save
>bandwidth in constrained environments - I don't know if that is now more
>or less applicable.

As Hugo Krawczyk (who was the key contributor and participant in that
discussion) recently confirmed, the MAIN reason for truncation was
bandwidth saving - but cryptographers found that it also offers some
benefits. 

IMHO, saving some bandwidth is always a good thing, because you can never
have too much of it. :-)

Would like to hear from others on this subject, given that:
 - truncation saves bandwidth;
 - truncation improves resistance to key guessing attacks;
 - truncation lowers resistance to birthday-paradox/digest-guessing
attacks.

What do we _want_ (care about) here?

>So I would like to see more in the Security Considerations along these
>lines with a target audience of non-cryptographers.

Johannes, would you put a few words there...?

TNX!

---

From: t.petch <[email-masked]>
Date: Thu, 27 Mar 2014 18:02:49 +0000

Some more red tape.

The copyright in the MIB module is 2004.

You used the word 'SHALL' in s.3 which says to me that you need a
reference to RFC2119 and the boilerplate associated with it.

Normally, anything with a MIB Module in it contains standard MIB
boilerplate about the standard management framework; but this MIB Module
contains no objects, just identities, so does it need the boilerplate?
I would say not, but RFC4181 says it does (which in turn drags in four
more references)!  need guidance there.  You should at least include
RFC2578 in the references since that appears in this MIB module.

I must re-read RFC4181 - I suspect that there is more in there to be
added to this I-D.

Tom Petch

---

From: Johannes Merkle <[email-masked]>
Date: Fri, 28 Mar 2014 14:10:09 +0100

>> ....a good model to follow, which Uri's suggestion does.

Ok, I will change names accordingly.

> SHOULD, the rest would be MAY in the given order.

I agree. As soon as we have agreed on the mandatory and recommended protocols, I will include these provisions.

> I'd have no problem with this RFC going Standards Track. Johannes?

No, and we have no choice anyway.

> Not sure if it's a good idea to bring Suite B up at this time?

I'm confuded. Does Suite-B specify the truncation of HMACs?

> if things go the way I'd like...

I'm fine with SHA512 HMAC being only a SHOULD.

>  - truncation lowers resistance to birthday-paradox/digest-guessing

256 bit output length is enough to prevent birthday-paradox/digest-guessing attacks (which require n^(1/2) outputs),
thus I prefer HMAC256SHA512 over HMAC384SHA512. For SHA-256 the situation is different, as collecting 2^64 outputs is
not so completely unthinkable (albeit still not practical).

Thus, I suggest defining usmHMAC192SHA256AuthProtocol as MUST, and usmHMAC256SHA512AuthProtocol as SHOULD.

> Johannes, would you put a few words there...?

Yes, I'll do that next week.

-- 
Johannes

---

From: Johannes Merkle <[email-masked]>
Date: Fri, 28 Mar 2014 14:13:29 +0100

> ones, although I don't feel strongly about that preference.

Please have a second look: all of them are truncated, they only differ in the extend of truncation. Which truncation
lengths do you prefer?

-- 
Johannes

---

From: Johannes Merkle <[email-masked]>
Date: Fri, 28 Mar 2014 14:21:25 +0100

> The copyright in the MIB module is 2004.

oops! Got me, I copied and modified that from RFC 3826.

> reference to RFC2119 and the boilerplate associated with it.

Right, I'll will include reference to RFC 2119.

> I must re-read RFC4181 - I suspect that there is more in there to be

I am not familiar with MIBs, thus I appreciate your and Uri's assistance. Isn't RFC 3826 a proper example how to do it?

-- 
Johannes

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Fri, 28 Mar 2014 10:34:13 -0400

On 3/28/14 9:21 , "Johannes Merkle" <[email-masked]> wrote:

>I am not familiar with MIBs, thus I appreciate your and Uri's assistance.
>Isn't RFC 3826 a proper example how to do it?

I'm afraid this is out of my competence area. I've no clue regarding
boilerplates, and can help only with the actual MIB content (that ASN.1
stuff :).

Sorry!

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Fri, 28 Mar 2014 10:39:03 -0400

On 3/28/14 9:10 , "Johannes Merkle" <[email-masked]> wrote:

>>>merits
>>> lines worth including by way of justification for this I-D (Suite B
>>>got a lot of

No it does not, AFAIK. AFAIK, it specifies: (a) a block cipher, (b) a set
of hash-functions, (c) a digital signature algorithm, and (d) a key
agreement algorithm.

Truncation is probably specified in some of the RFCs produced *based on*
the Suite B spec. I thin they're in line with IPsec, i.e., HMAC-SHA1-96.

>I'm fine with SHA512 HMAC being only a SHOULD.

Let's have it then.

>256 bit output length is enough to prevent
>birthday-paradox/digest-guessing attacks (which require n^(1/2) outputs),

Yes, that means 256-bit output provides 2^128 digest-guessing resistance.

>thus I prefer HMAC256SHA512 over HMAC384SHA512.

I'm OK with it. I'm also OK with removing HMAC384SHA512 altogether, in
favor of HMAC256SHA512.

> For SHA-256 the situation is different, as collecting 2^64 outputs is

:-)

>usmHMAC256SHA512AuthProtocol as SHOULD.

I'm OK with it.

:-)

---

From: Johannes Merkle <[email-masked]>
Date: Fri, 28 Mar 2014 16:10:36 +0100

> the Suite B spec. I thin they're in line with IPsec, i.e., HMAC-SHA1-96.

It is specified in NIST SP 800-107rev1, Section 5.3.3

-- 
Johannes

---

From: t.petch <[email-masked]>
Date: Fri, 28 Mar 2014 15:49:08 +0000

----- Original Message -----
From: "Johannes Merkle" <[email-masked]>
To: "t.petch" <[email-masked]>; <[email-masked]>
Cc: "Manfred Lochter" <[email-masked]>; <[email-masked]>
Sent: Friday, March 28, 2014 1:21 PM
> I am not familiar with MIBs, thus I appreciate your and Uri's
assistance. Isn't RFC 3826 a proper example how to do it?

RFC3826 has not got a MIB module in it and so is not an exemplar for
that.  I have looked for a recent one that adds OBJECT-IDENTITY - as
opposed to OBJECT-TYPE - but cannot find one.  A good example of a
recent MIB module (with OBJECT-TYPE) that does conform is
http://www.ietf.org/id/draft-ietf-6lo-lowpan-mib-00.txt

Sections 2 and 3 could be lifted for use here.

Section 7 applies when there are OBJECT-TYPE and so does not here but
Section 8 gives a partial template for IANA Considerations, for the
module registration but not for the entries in SnmpAuthProtocols.

http://datatracker.ietf.org/doc/rfc6353/
 defines an OBJECT-IDENTITY under snmpDomains while
  draft-ietf-isms-dtls-tm-09.txt
is what it was like beforehand (although I would have liked that I-D to
have spelt things out more clearly -  it is an exemplar but a not
terribly good one IMO).

Sorry if I confused you with my reference to Suite B.  It was a hot
topic around the time that I first saw SHA-2 discussed on the IETF lists
and so was cited as a motivation for moving to it (and stuck in my
mind).  That is probably history but government requirements for SHA-2
were another motivation - which is a post that Uri made many years ago,
in 2008 - and that I imagine is still current. At the same time, my
sense is that for the use to which MAC are used here, then MD5, although
weakened, is still good enough, ditto SHA, but that is very much a lay
opinion; I am sure that you know the field better than I.

Tom Petch

---

From: David Reid <[email-masked]>
Date: Fri, 28 Mar 2014 15:38:50 -0400

> Please have a second look: all of them are truncated, they only differ in the extend of truncation. Which truncation

I prefer not having too many choices, but I really don't have a strong
opinion on which ones are chosen. In the end, I'll implement everything
that is in the final spec, whether optional or mandatory.

-David Reid

---

From: "ietfdbh" <[email-masked]>
Date: Fri, 28 Mar 2014 18:21:13 -0400

Hi,

RFC4181 has guidelines for authors and reviewers of MIB documents.
It has a lot of guidance about how to organize your document, and what boilerplate to use.
It also contains a lot of guidance about writing a MIB.

Tools.ietf.org has templates for documents containing a MIB module.
There is a plaintext template, a plaintext template with guidance, and an xml2rfc template with guidance.
The templates were developed by/with the MIB Doctors, and the guidance is largely based on RFC4181 guidance about a document that contains a MIB module.
The templates do NOT contain guidance on how to write a MIB.
I authored the templates and haven't touched them in years, but RFC4181 hasn't changed either, so the templates probably still contain fairly good guidance on the document organization.
The boilerplate in the templates is probably old.

The O&M wiki page contains current boilerplate recommendations for MIB documents.
This is the most up-to-date recommendation for boilerplate text.
It also has textual conventions that you are encouraged to use rather than reinventing any wheels.
I'm not sure textual-conventions come into play in your document though.
The wiki also points to tools to check your MIB module; the tools typically check for many of the RFC4181 nits and the RFC Editor nits.

Hope this helps,

David Harrington
[email-masked]
+1-603-828-1401

> -----Original Message-----
> From: OPSAWG [mailto:[email-masked]] On Behalf Of
> Blumenthal, Uri - 0558 - MITLL
> Sent: Friday, March 28, 2014 10:34 AM
> To: Johannes Merkle; t.petch; [email-masked]
> Cc: Manfred Lochter
> Subject: Re: [OPSAWG] Fwd: New Version Notification fordraft-hmac-sha-2-
> usm-snmp-00.txt
>

---

From: "ietfdbh" <[email-masked]>
Date: Fri, 28 Mar 2014 23:11:57 -0400

Doh! I forgot to include the link to the O&M wiki
https://svn.tools.ietf.org/area/ops/trac/wiki

David Harrington
[email-masked]
+1-603-828-1401

> From: OPSAWG [mailto:[email-masked]] On Behalf Of ietfdbh
> Sent: Friday, March 28, 2014 6:21 PM
> To: 'Blumenthal, Uri - 0558 - MITLL'; 'Johannes Merkle'; 't.petch';
> [email-masked]
> Cc: 'Manfred Lochter'
> The templates were developed by/with the MIB Doctors, and the guidance is
> largely based on RFC4181 guidance about a document that contains a MIB
> module.
> I authored the templates and haven't touched them in years, but RFC4181
> hasn't changed either, so the templates probably still contain fairly good
> guidance on the document organization.
> The wiki also points to tools to check your MIB module; the tools
typically
> check for many of the RFC4181 nits and the RFC Editor nits.
> 
> Hope this helps,
> 
> David Harrington
> [email-masked]
> +1-603-828-1401
> 
assistance.

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 31 Mar 2014 15:39:24 -0700

Johannes Merkle <[email-masked]> writes:

> birthday-paradox/digest-guessing attacks (which require n^(1/2)
> outputs), thus I prefer HMAC256SHA512 over HMAC384SHA512. For SHA-256
> the situation is different, as collecting 2^64 outputs is not so
> completely unthinkable (albeit still not practical).
>

I'm not entirely convinced that a 256bit truncation is better than a 384
bit truncation, so my preference would be to include just two (not 6)
algorithms because I don't think they're all needed and will just make
things more confusing.  So I'd pick the best two of the 6 and go with
them, for which my preference would be:

1)  MUST: usmHMAC192SHA256AuthProtocol
  SHOULD: usmHMAC384SHA512AuthProtocol

2)  MUST: usmHMAC192SHA256AuthProtocol
  SHOULD: usmHMAC256SHA512AuthProtocol

-- 
Wes Hardaker
Parsons