Subject: [manet] I-D Action:draft-ietf-manet-packetbb-sec-00.txt

From: [email-masked]
Date: Sat, 19 Jun 2010 19:15:04 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF.

	Title           : MANET Cryptographical Signature TLV Definition
	Author(s)       : U. Herberg, T. Clausen
	Filename        : draft-ietf-manet-packetbb-sec-00.txt
	Pages           : 17
	Date            : 2010-06-19

This document describes a general and flexible TLV (type-length-value
structure) for representing cryptographic signatures as well as
timestamps, using the generalized MANET packet/message format
[RFC5444].  It defines two Packet TLVs, two Message TLVs, and two
Address Block TLVs, for affixing cryptographic signatures and
timestamps to a packet, message and address, respectively.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-sec-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Bo Berry <[email-masked]>
Date: Sun, 20 Jun 2010 08:14:06 -0400

Ulrich, Thomas:

Below are a few points for consideration and discussion.

Regards
-Bo Berry

In section 10.2.2.  Hash Function suggest adding  SHA-128, SHA-256, 
SHA-386, SHA-512 under SHA-2.

And in section 10.2.3.  Cryptographic Algorithm, suggest adding ECC.

As noted in section 5, "Before being able to validate a cryptographic 
signature, routers have to exchange keys (e.g. public keys)."  Each
router (node) may have several keys (key ring). In this case, it would 
be useful to define a key index TLVs.  The Key Index TLV would be
needed when multiple keys are used. 

Also suggest breaking the <signature> TLV into separate TLVs to
increase flexibility and to align with the separate <timestamp> TLV.
Nodes may wish/need to configure the hash and crypto functions when 
keys are configured and would not need to carry this info in the
signature TLV.

So we could define the following TLVs:

      <key-index TLV> := <key index value>
      <hash-function TLV> := <hash function identifier>
      <cryptographic-algorithm TLV> := <crypto-algor identifier>
      <signature-value TLV> := <signature value>

On Jun 20, 2010, at 4:41 AM, Ulrich Herberg wrote:

> I have submitted the packetbb-sec draft as WG draft. The draft does
> not contain any changes since the last individual draft
> (draft-herberg-manet-packetbb-sec-03). We will work on a new revision
> until the IETF meeting in Maastricht.
> 
> Best regards
> Ulrich

> <Mail Attachment>_______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Paul Lambert <[email-masked]>
Date: Mon, 21 Jun 2010 16:25:20 -0700

Seems like a bad idea to have separate hash and signature values:

> The rationale for separating the hash function and the cryptographic
   algorithm into two octets instead of having all combinations in a
   single octet - possibly as TLV type extension - is twofold: First, if
   further hash functions or cryptographic algorithms are added in the
   future, the number space might not remain continuous.  More
   importantly, the number space of 256 possible combinations would be
   rapidly exhausted: 16 different hash functions and 16 different
   cryptographic algorithms would lead to exhaustion.

Having multiple combinations is a bad idea.  It greatly complicates testing of devices since it leaves available many combinations.

The notion that 16 hash and 16 signature values would fill the number space is incorrect.  There is no reason to allow all of the combinations - only a few really make sense.

Similar comments for the parameters.  The overall security context needs to have a definition, but allowing parameterization complicates testing and leaves open room for downgrade attacks.

MD5 should NOT be included in the requested list of hash algorithms.

The cryptographic algorithm registry is poorly constructed and does not accommodate modes of operation (modes should not be a parameter)

This whole encapsulation seems generic and not specific to MANET.  Aren't there existing encapsulations that could be used?

Paul

Paul A. Lambert | Marvell Semiconductor | +1 650-787-9141

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Bo Berry
> Sent: Sunday, June 20, 2010 5:14 AM
> To: [email-masked]
> Subject: Re: [manet] I-D Action:draft-ietf-manet-packetbb-sec-00.txt
> 
> Ulrich, Thomas:
> 
> _______________________________________________
> manet mailing list
> [email-masked]

---

From: Bo Berry <[email-masked]>
Date: Tue, 22 Jun 2010 10:41:40 -0400

Paul

Since RFC5444 and the draft is meant to be a generic packeting framework, having greater flexibility should be the goal so the framework does not hinder a future design/need.  Multiple combinations does not imply that a specific implementation would support all the combos.  It is reasonable that an implementation may choose to support a single feature and error on everything else. 

As for MD5, I do not desire to use it but someone out there may have a real, acceptable need.

A different perspective.

-Bo

>>> https://www.ietf.org/mailman/listinfo/manet

----
[email-masked]
This email may contain confidential and privileged material for the sole use of the intended recipient. This email may contain information that is protected by NDA. Any unauthorized review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

---

From: Paul Lambert <[email-masked]>
Date: Tue, 22 Jun 2010 08:29:09 -0700

Combining the cryptographic parameters into a single suite identifier does not limit or hinder "future design/need".  It only clearly identifies the intended pairing/combinations of algorithms.

Allowing mix and match parameterization causes severe interoperability problems, testing complexity and potential security attacks (downgrade attacks).

A example of the mess that such a design can create is the mix-and-match parameterization used in the 802.11i security parameters.  Even though two devices may both support the same encryption algorithms, the parameterization can prevent interoperability.  The lare number of combinations due to the parameterization also prevents adequate testing.

Picking algorithms and allowing bad choices (like Md5) is poor design.  It's the result of not having clear product/system requirements.  Rather than perpetuating this indecision and the associated poor design practices, only one or two algorithm suites should be defined.  The RFC and number assignment process will allow extension of the defined suites when there are advocates for the new mechanisms.  

Including MD5 and 3DES in a new design is bad idea.  There is no existing implementation of the new protocol so there can be no legacy need for the depreciated algorithms.

Paul

 
> From: Bo Berry [mailto:[email-masked]]
> Sent: Tuesday, June 22, 2010 7:42 AM
> To: Paul Lambert
> Cc: [email-masked]
> Since RFC5444 and the draft is meant to be a generic packeting framework,
> having greater flexibility should be the goal so the framework does not
> hinder a future design/need.  Multiple combinations does not imply that a
> specific implementation would support all the combos.  It is reasonable
> that an implementation may choose to support a single feature and error on
> everything else.
> 
> > Having multiple combinations is a bad idea.  It greatly complicates
> testing of devices since it leaves available many combinations.
> >
> > The notion that 16 hash and 16 signature values would fill the number
> space is incorrect.  There is no reason to allow all of the combinations -
> only a few really make sense.
> >
> > Similar comments for the parameters.  The overall security context needs
> to have a definition, but allowing parameterization complicates testing
> and leaves open room for downgrade attacks.
> >
> > The cryptographic algorithm registry is poorly constructed and does not
> accommodate modes of operation (modes should not be a parameter)
> >
> > This whole encapsulation seems generic and not specific to MANET.
> Aren't there existing encapsulations that could be used?
> >
> > Paul
> >
> >
> >>> This draft is a work item of the Mobile Ad-hoc Networks Working Group
> of
> >> the IETF.
> >>>
> >>>
> This email may contain confidential and privileged material for the sole
> use of the intended recipient. This email may contain information that is
> protected by NDA. Any unauthorized review, use, distribution or disclosure
> by others is strictly prohibited. If you are not the intended recipient
> (or authorized to receive for the recipient), please contact the sender by
> reply email and delete all copies of this message.
> 
> 
> 
>

---

From: Henning Rogge <[email-masked]>
Date: Wed, 23 Jun 2010 09:02:03 +0200

On Tue June 22 2010 17:29:09 Paul Lambert wrote:
> Picking algorithms and allowing bad choices (like Md5) is poor design. 
> It's the result of not having clear product/system requirements.  Rather
> than perpetuating this indecision and the associated poor design
> practices, only one or two algorithm suites should be defined.  The RFC
> and number assignment process will allow extension of the defined suites
> when there are advocates for the new mechanisms.
> 
> Including MD5 and 3DES in a new design is bad idea.  There is no existing
> implementation of the new protocol so there can be no legacy need for the
> depreciated algorithms.
MD5 and 3DES are not much faster than SHA1 and AES128, so we might really drop 
this options.

It make sense to have some less secure algorithms if they are much faster, but 
not if they are just less secure (and as fast as a better one).

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0