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

[Bo Berry <[e-mail]>]

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

On Jun 21, 2010, at 7:25 PM, Paul Lambert wrote:

> 
> 
> 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 | [phone]
> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Bo Berry
>> Sent: Sunday, June 20, 2010 5:14 AM
>> To: [e-mail]
>> Subject: Re: [manet] I-D Action:draft-ietf-manet-packetbb-sec-00.txt
>> 
>> 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
>> 
>>> 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.
>>> <Mail Attachment>_______________________________________________
>>> manet mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/manet
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> manet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet

----
[e-mail]
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.