Subject: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp

From: Warren Kumari <[email-masked]>
Date: Mon, 11 Aug 2014 17:28:58 -0400

Dear OpsAWG WG,

This starts a Call for Adoption for draft-hmac-sha-2-usm-snmp.

The draft is available here:
https://datatracker.ietf.org/doc/draft-hmac-sha-2-usm-snmp/

Please review this draft to see if you think it is suitable for
adoption by OpsAWG,
and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends Mon 25-Aug-2014.

In addition, to satisfy RFC 6702 ("Promoting Compliance with
Intellectual Property Rights (IPR)"):
If you are personally aware of any IPR that applies to
draft-hmac-sha-2-usm-snmp, has this IPR been disclosed in compliance
with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more
details.)

Thanks,
Warren Kumari
(as OpsAWG WG co-chair)

---

From: t.petch <[email-masked]>
Date: Tue, 12 Aug 2014 09:43:14 +0100

I support adoption.  It brings USM up-to-date.

However, I am aware of
https://datatracker.ietf.org/doc/draft-hartman-snmp-sha2/
which looks remarkable similar in scope but different in detail.  I
regard
https://datatracker.ietf.org/doc/draft-hmac-sha-2-usm-snmp/
as the superior I-D but am surprised at the existence of the other, with
its distinguished list of editors.  Any ideas what their intentions are?

I would not want to see a merger of the two I-Ds, I think that that
would be the worst outcome, although having both become RFC would also
be a bad result.

Tom Petch

----- Original Message -----
From: "Warren Kumari" <[email-masked]>
To: "[email-masked]" <[email-masked]>;
<[email-masked]>
Sent: Monday, August 11, 2014 10:28 PM
Subject: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp

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

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 12 Aug 2014 15:39:37 -0700

> This starts a Call for Adoption for draft-hmac-sha-2-usm-snmp.

I'm up for it being adopted.  However, it needs work before going
forward (but hey, that's what a WG is for).
-- 
Wes Hardaker
Parsons

---

From: David Reid <[email-masked]>
Date: Wed, 13 Aug 2014 09:29:38 -0400

I support adoption by the working group. I'm willing to review the
document and I also plan to implement it.

-David Reid

---

From: Johannes Merkle <[email-masked]>
Date: Fri, 15 Aug 2014 12:12:32 +0200

t.petch wrote on 12.08.2014 10:43:
> which looks remarkable similar in scope but different in detail.  

We were not aware of this draft. Indeed, at first glance
it seems quite similar. Apart from formal (e.g. missing code point request, descriptions of MIB module and relationship
to other MIB modules, and security considerations) and editorial aspects (our description seems more aligned with RFC
3414), I spotted the following major differences

- draft-hartman-snmp-sha2 defines 3 protocols whereas our draft defines 6 protocols

- draft-hartman-snmp-sha2 does not use any HMAC truncation, whereas in our draft, all HMACs are truncated. (For a
discussion of HMAC truncation see our security consideration)

- in draft-hartman-snmp-sha2, the length of the authentication key K is only a SHOULD, while in our draft it is fixed.

- our draft defines methods for key localization and key change using the same hash function as the authentication protocol.

> its distinguished list of editors.  Any ideas what their intentions are?

I have no clue.

Johannes

-- 
Mit freundlichen Grüßen,
Dr. Johannes Merkle
Principal Beratung, Elektronische Identitäten
Public Sector
secunet Security Networks AG
Mergenthaler Allee 77
65760 Eschborn
Germany
Telefon +49 201 54 54-3091
Telefax +49 201 54 54-1325
Mobil   +49 175 2224439
[email-masked]
www.secunet.com

---

From: t.petch <[email-masked]>
Date: Fri, 15 Aug 2014 12:12:01 +0100

Johannes

As I said before, it is your I-D that I want to see adopted:-)  I am
just worried that this other one will muddy the waters at some later
stage of the process, so want it out in the open now, so that this
adoption call by the WG is made with full knowledge of the existence of
the other one (which I hope I have achieved).

Tom Petch

----- Original Message -----
From: "Johannes Merkle" <[email-masked]>
To: "t.petch" <[email-masked]>; "Warren Kumari"
<[email-masked]>; "[email-masked]" <[email-masked]>;
<[email-masked]>
Sent: Friday, August 15, 2014 11:12 AM
> it seems quite similar. Apart from formal (e.g. missing code point
request, descriptions of MIB module and relationship
> to other MIB modules, and security considerations) and editorial
aspects (our description seems more aligned with RFC
> - draft-hartman-snmp-sha2 does not use any HMAC truncation, whereas in
our draft, all HMACs are truncated. (For a
> - in draft-hartman-snmp-sha2, the length of the authentication key K
is only a SHOULD, while in our draft it is fixed.
>
> - our draft defines methods for key localization and key change using
the same hash function as the authentication protocol.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 25 Aug 2014 10:53:14 -0700

With huge apologies to everyone involved, I'm going to extend this
call for adoption for 2 days (till the 27th).

After Tom found
https://datatracker.ietf.org/doc/draft-hartman-snmp-sha2/ and made us
aware, Scott and I chatted. We decided that we should make the authors
of draft-hartman-snmp-sha2 aware of this CfA so that they could chime
in, and I took it on as an action item to inform them -- and then I
went off to USENIX Security / WOOT and completely forgot (it was a
good conference!).

So, in order to give draft-hartman-snmp-sha2 time to respond, I'm
extending htis.
Apologies to everyone involved.
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: Sam Hartman <[email-masked]>
Date: Tue, 26 Aug 2014 16:26:19 -0400

Hi.

I've reviewed both draft-hartman-snmp-sha2 and
draft-hmac-sha-2-usm-snmp.

In general, I believe that draft-hartman-snmp-sha2 provides a better
starting point for a SHA2 authentication algorithm for USM.

draft-hmac-sha-2-usm-snmp provides differences between the MD5 algorithm
described in RFC 3414 and the SHa2 algorithm.

In general I've found that  describing a specification in terms of
differences in cases where there is not a clear abstraction present is
problematic.  It tends to lead to implementation errors by focusing on
the steps that are different rather than on all the steps that need to
be performed.

In this case, I think that we'll tend to see key derivation and to a
lesser extent messaging processing errors because of the brief text
pointing at these issues.

In our draft (draft-hartman), we create an abstraction for an HMAC-based
hash authentication in USM and plug sha-2 into that abstraction.
I think that's a cleaner approach that will lead to higher
implementation quality  than the draft-hmac-sha-2-usm-snmp approach.

In addition, I'm not convinced that truncating the HMAC is a good idea
in this instance.  If the WG decides that truncation of the HMAC is
desirable, we should add a description of why that's the case and a
security discussion.  (I don't think the truncation proposed has
significant security problems)

My recommendation would be that the WG start with
draft-hartman-snmp-sha2 as a basis for this work, but that the authors
of draft-hmac and draft-hartman work together to make sure that all the
best ideas from both proposals make their way into the final product.

---

From: "Hedanping (Ana)" <[email-masked]>
Date: Wed, 27 Aug 2014 02:06:00 +0000

Hi all,
Please see my comments between [Danping----->>]...[<<-----Danping].

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Wednesday, August 27, 2014 4:26 AM
To: Warren Kumari
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Call for Adoption: draft-hmac-sha-2-usm-snmp

Hi.

I've reviewed both draft-hartman-snmp-sha2 and draft-hmac-sha-2-usm-snmp.

In general, I believe that draft-hartman-snmp-sha2 provides a better starting point for a SHA2 authentication algorithm for USM.

draft-hmac-sha-2-usm-snmp provides differences between the MD5 algorithm described in RFC 3414 and the SHa2 algorithm.

In general I've found that  describing a specification in terms of differences in cases where there is not a clear abstraction present is problematic.  It tends to lead to implementation errors by focusing on the steps that are different rather than on all the steps that need to be performed.

In this case, I think that we'll tend to see key derivation and to a lesser extent messaging processing errors because of the brief text pointing at these issues.

In our draft (draft-hartman), we create an abstraction for an HMAC-based hash authentication in USM and plug sha-2 into that abstraction. I think that's a cleaner approach that will lead to higher implementation quality than the draft-hmac-sha-2-usm-snmp approach.

[Danping----->>] 
Agree. The complexity of implementing the 'draft-hmac' would tend to result in confusions and missing steps related to the key derivation etc. 'draft-hartman' has a better explanation of how the protocol fits into USM and SNMP, as well as a clearer explanation of how the overall system works. It seems that this document is more likely to provide good long-term implementation results.
[<<-----Danping]

In addition, I'm not convinced that truncating the HMAC is a good idea in this instance.  If the WG decides that truncation of the HMAC is desirable, we should add a description of why that's the case and a security discussion.  (I don't think the truncation proposed has significant security problems)

[Danping----->>] 
Agree. Although truncation is fairly well analyzed, there are security disadvantages to do it, and I don't really see significant advantages to truncation. I've searched the mailing list about comments on 'draft-hmac', several members who contributed to improve it, still had doubts and confusions on the truncation to various output lengths. 
[<<-----Danping]

My recommendation would be that the WG start with
draft-hartman-snmp-sha2 as a basis for this work, but that the authors of draft-hmac and draft-hartman work together to make sure that all the best ideas from both proposals make their way into the final product.

[Danping----->>]
I support 'draft-hartman' as a basis and a proper direction towards enhancing USM of SNMP.
[<<-----Danping]

---

From: Johannes Merkle <[email-masked]>
Date: Wed, 27 Aug 2014 13:45:43 +0200

> starting point for a SHA2 authentication algorithm for USM.

In general, I would have no objections with this proposal (saves me some work, I guess) - if your draft really was a
better starting point. However, I do not agree with this.

> the steps that are different rather than on all the steps that need to

The purpose of our delta-description was to make clear that the basic protocol design of RFC 3414 does not change (only
the hash function and the lengths of some data) and to facilitate implementation. Existing implementations of the RFC
3414 auth protocols can be easily modified. No need to implement the protocol from scratch.

In contrast, your description is very different from that in RFC 3414. So an implementor would need to re-implement the
protocol from your description. I don't see why this should be less error-prone.

But I am open to the approach of providing both types of description.

> In addition, I'm not convinced that truncating the HMAC is a good idea

Many well-reputed cryptographers (e.g. Preneel and van Oorschot) advocate HMAC truncation. Could you please elaborate on
why you think that truncation is not a good idea?

> significant security problems)

We have included a detailed discussion in Security Considerations.

> best ideas from both proposals make their way into the final product.

I suggest that others on the list speak up and declare their preference.

-- 
Johannes

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Aug 2014 14:04:50 +0200

> I suggest that others on the list speak up and declare their preference.

I can't declare a clear preference since I have not time at the moment
to study whether there are any real technical differences. One thing I
note, however, is that draft-hartman-snmp-sha2 lacks a MIB module and
thus is incomplete. In contrast, draft-hmac-sha-2-usm-snmp includes a
MIB module but it surely requires some editing work to make it look
nice. Note that a MIB module is needed to define the necessary object
identities for the new authentication protocols.

Since both documents claim to be identical to the authentication
protocols proposed in [RFC3414] except the authentication algorithms
used in generating digests (quoting almost literally
draft-hartman-snmp-sha2), I think short and incremental text is a
feature and not a bug.

/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: Warren Kumari <[email-masked]>
Date: Wed, 27 Aug 2014 15:11:11 -0400

Hi all,

Scott and I just chatted about this.
We see that there is interest in this topic, we think it is an
important topic, and we would like to adopt /a/ document that
addresses this.

We'd appreciate it if the authors of draft-hmac-sha-2-usm-snmp and
draft-hartman-snmp-sha2 can discuss how to move forward, possibly by
combining the documents into one, or selecting one and folding in
comments from the other.

Again, we think that this is an important topic, and would like to get
the best possible document adopted.

Warren and Scott.

---

From: David Reid <[email-masked]>
Date: Wed, 27 Aug 2014 15:49:02 -0400

There was a fair amount of working group discussion around
draft-hmac-sha-2-usm-snmp. That feedback was incorporated
into the latest version of the draft (things like adding a MIB 
module, deciding how many and which hmac authentication protocols 
to use, what descriptor names to use, mac truncation, etc).
It is important that we not lose that collective input. For
that reason, I prefer draft-hmac-sha-2-usm-snmp as the starting
point. I think it is already pretty close to what we want.

I would like to see this move quickly since there is market demand now.

-David Reid

---

From: "Hedanping (Ana)" <[email-masked]>
Date: Thu, 28 Aug 2014 04:40:47 +0000

> Johannes wrote on 27.08.2014 19:46:
> 
> The purpose of our delta-description was to make clear that the basic protocol
> design of RFC 3414 does not change (only the hash function and the lengths of
> some data) and to facilitate implementation. Existing implementations of the
> RFC
> In contrast, your description is very different from that in RFC 3414. So an
> implementor would need to re-implement the protocol from your description. I
> don't see why this should be less error-prone.

Being different from RFC3414 doesn't mean that our method (draft-hartman) needs a re-implementation. Actually both drafts are quite different from RFC3414, 'draft-hartman' describes the SHA2 for USM in terms of key selection, outgoing message generation, incoming message processing, which concisely and clearly follows the logic of USM. But ' draft-hmac' makes diversion to the truncation issue and its definition to MIB. 

What really matters here is whether the mechanism is fit for USM and as you agree, whether the mechanism is easy and practical to be implemented.

> Many well-reputed cryptographers (e.g. Preneel and van Oorschot) advocate
> HMAC truncation. Could you please elaborate on why you think that truncation
> is not a good idea?
> 

Truncation is advocated doesn't mean that it is convinced to be freely applied anywhere. Truncation is actually a weighted trade-off decision, it is open to discuss and will not end up with a best conclusion. Normally the uncertainty of the parameter selection should be out of the scope of a draft.

Although I admit that by truncating the output length the 'attacker can learn less about the output of the compression function', it actually increases the risk of security and the complexity of the implementation.  

Both of the drafts use SHA2 as an enhancement due to the already known disadvantage of SHA1 and MD5. Implementing SHA2 means that the output length will definitely exceed the 12 octets reserved for msgAuthenticationParameters and we can foresee a modification of the SNMP packet format.  I didn't see the advantages by truncating SHA2 to different confusing output lengths and increase the risk of the security and complexity of implementation.

> We have included a detailed discussion in Security Considerations.

It would be better when truncation length be discussed only in the security considerations, truncation issue is more academia and might not be suitable to be proposed as a formal mechanism in the main content of the draft.

---

From: Johannes Merkle <[email-masked]>
Date: Thu, 28 Aug 2014 13:01:47 +0200

> Being different from RFC3414 doesn't mean that our method (draft-hartman) needs a re-implementation. Actually both drafts are quite different from RFC3414, 'draft-hartman' describes the SHA2 for US…

What do you mean by "' draft-hmac' makes diversion to the truncation issue"? RFC 3414 also uses truncated HMACS, so
there is no deviation in this.

> Although I admit that by truncating the output length the 'attacker can learn less about the output of the compression function', it actually increases the risk of security and the complexity of th…

We should not mix up these two topics:
1) Should we use truncation and, if yes, to what extend (50% or 75%)?
2) How many protocols should we specify?

As to 1), I have already elaborated on the reasoning for truncation
http://permalink.gmane.org/gmane.ietf.opsawg/3244
and there was some discussion on this, where most participants expressed their preference for truncation.

Your statement that truncation "increases the risk of security" probably refers to the reduction of strength against
collision attacks, which require n^(1/2) collected messages. At least for the protocols with HMAC output length of 192
bits or greater, we can safely consider such attacks as impractical in the foreseeable future.

Just to be sure that there is no misunderstanding: The security issues of TLS with HMC truncation are caused by the
MAC-then-PAD-then-Encrypt construction of TLS, see
http://web.archiveorange.com/archive/v/aFZ9KRJi4JLUvLRo8Ek7#HF6Jnaf1plca1DC

Are you strictly objecting to truncation or is it just not your preference?

As to 2), there was already some discussion on this list where, and many expressed a preference for cutting down the
list. You can find the thread here: http://comments.gmane.org/gmane.ietf.opsawg/3237

I am open to reducing the number of protocols, we just need to agree on how many and which protocols we want. If there
is consensus on this list for a set of protocols, even if they do not use truncation, I will not object.

> It would be better when truncation length be discussed only in the security considerations, truncation issue is more academia and might not be suitable to be proposed as a formal mechanism in the m…

I don't get it: truncation length _is_ discussed only in the security considerations. What exactly are you objecting to?

-- 
Johannes

---

From: Sam Hartman <[email-masked]>
Date: Thu, 28 Aug 2014 13:33:54 -0400

Hi.

My concern in describing things as diffs to the md5 algorithm in 3414 s
that there's not a well defined abstraction there at that layer.

The SNMP community has been very careful to define rules of procedure
and very well-defined interfaces afor extension and for variability in
SNMP.  When we started work on the transport security model we
considered providing differences to the existing SNMP processing.
It would have been a lot less text.
However, we  were not using proper SNMP extension points in doing so.
Extending SNMP only at its proper extension points helps in reasoning
about SNMP correctness, security, etc.
For the same reason abstraction helps you when coding, it helps you when
working on specifications for large complex systems.

Authentication algorithms in USM are a valid extension point today.
However, as I read 3414, HMAC-based algorithms that work approximately
like hmac-md5 are *not* a well-defined extension point.

I think it is important to create a new extension point that plugs into
the existing extension point of USM authentication algorithm and
provides hmac-based authentication with an extensible hash function.

draft-hartman tries to do that today. draft-hmac does not.

I think it is  important  for SNMP forward evolution that we do that and
only extend at maintainable extension points.
For that reason, regardless of which draft the working group chooses, I
believe it is important to first define a new extension point for
generic hmac-based authentication algorithms that plug into the USM
authentication algorithm extension point in 3414, and then to plug sha-2
into that newly created extension point.

--Sam

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 Aug 2014 08:51:57 +0200

The SNMP architecture in RFC3411 has 'Abstract Service Interfaces'
between 'Subsystems'. What we are talking about here is a possible
'extension point' within a specific Model implementing a specific
Subsystem. I think these are different things and it remains unclear
whether it is worth to define 'extension points' of Models (USM is a
Model implementing the Security Subsystem Abstract Service Interface).

At least, we should not confuse 'Abstract Service Interfaces',
'Subsystems', 'Models' and 'extension points' (which is a new concept
since so far Models do not have such plugin extension points).

/js

---

From: t.petch <[email-masked]>
Date: Fri, 29 Aug 2014 11:28:50 +0100

I would like to see draft-hmac proceed, pretty much as is.

I find draft-hartman more complex to follow with its elements of
procedure.

draft-hmac is a delta to the existing USM which is what it it intending
to be; you need to understand USM in order to implement it, in which
case, all you need is in draft-hmac.

draft-hartman contains additional information that seems extraneous and
likely to confuse.

Tom Petch

----- Original Message -----
From: "David Reid" <[email-masked]>
To: "Warren Kumari" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>;
<[email-masked]>
Sent: Wednesday, August 27, 2014 8:49 PM
Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp

---

From: Sam Hartman <[email-masked]>
Date: Fri, 29 Aug 2014 08:01:32 -0400

>>>>> "Juergen" == Juergen Schoenwaelder <[email-masked]> writes:

    Juergen> At least, we should not confuse 'Abstract Service
    Juergen> Interfaces', 'Subsystems', 'Models' and 'extension points'
    Juergen> (which is a new concept since so far Models do not have
    Juergen> such plugin extension points).

Hmm, I actually do think USM has several such extension points.
There does seem to be an extension point for an authentication algorithm
in the model already.

It's been my experience that adding security algorithms without such
extension points does tend to cause problems both in interoperability
because you tend to use much less pprecision when you don't need to
define a clear extension point and in security because that lack of
precision tends to lead to security analysis problems.  I've seen this
both in the routing area and with core security protocols.

I don't have enough SNMP experience to figure out whether the results
will be different here.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 Aug 2014 14:25:26 +0200

> I don't have enough SNMP experience to figure out whether the results

Let me try to clarify my statement. I was trying to say is that we
should not use references to RFC 3011 architectural modularity in this
discussion since the RFC 3011 modularity concerns subsystems not what
happens in modules implementing subsystems. In particular, ISMS was
struggling with the fact that the subsystems did not forsee security
provided by the transport. What we are discussing here is different
from that.

/js

---

From: David Reid <[email-masked]>
Date: Fri, 29 Aug 2014 09:36:27 -0400

> I would like to see draft-hmac proceed, pretty much as is.

+1

-David Reid

---

From: Sam Hartman <[email-masked]>
Date: Fri, 29 Aug 2014 14:30:54 -0400

Thanks for your clarification.
At this point I think we understand each other, and it is up to the WG
to form an opinion.

--Sam