Subject: Re: [manet] Security drafts

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 1 Dec 2009 09:57:44 -0000

I've been guilty twice now of not checking the current
details, the octets specifying these are in the signature
block, not the type extension. But in some cases we don't
need those octets, if it's pre-agreed what algorithms are 
being used. (That these are in the signature block makes
length deduction messier also.)

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 01 December 2009 06:26
To: [email-masked]
Cc: Dearlove, Christopher (UK); Paul Lambert; Teco Boot; Ulrich Herberg; [email-masked]
Subject: Re: [manet] Security drafts

On Mon November 30 2009 19:11:46 Dearlove, Christopher (UK) wrote:
> Actually there's another issue, to do with that the TLV
> value length isn't the hash length, it's the signature
> length, and the hash length and signature length don't
> have to be equal. So - possibly in contradiction to an
> earlier email of mine - you need to include the hash
> length, probably in the type extension specifying the
> hash.
> 
> It is clear that a proper specification of a good set
> of algorithms, pinning down their options, is needed.
So maybe a TLV extension type should specify a hash algorithm and the hash 
output length ?

It can be even worse, because we combine a hash function and an encryption 
function. So we need to know the length of the hash output, must define if it's 
padded or shortened before it's pushed into the encryption function, then we 
have to know the output size of the encryption function and again do have to 
decide if we shorten or pad the final TLV data.

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-263,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Paul Lambert <[email-masked]>
Date: Tue, 1 Dec 2009 10:53:11 -0800

> Sent: Monday, November 30, 2009 10:26 PM
> To: [email-masked]
> Importance: Low

> So maybe a TLV extension type should specify a hash algorithm and the hash

So ... it's best to always use "cipher suites"  - an indication of the full set of algorithms and associated processing for the algorithms.  If the algorithms are selected individually (key exchange, signature, integrity/hash, etc.) you get many combinations and most are not useful and potentially are mismatched for security properties. The cipher suite in this case would indicate both the hash algorithm and length of the truncated value.

A single "security association" can provide the context for both the appropriate cipher suite and the appropriate state (keys, counters, etc.).  A "security association identifier" can be carried in the encapsulation to support the identification of the cipher suite and state (e.g. keys to use).

Prior to encapsulation - key management is obviously required.  This will establish in some manner the security association and the unique security association identifiers.  Note that for a pair-wise security association, two identifiers are required - one for each communicating party.  In a distributed environment it is impossible to coordinate a single such dynamic identifier.  Two identifiers allow each side to select a locally unique security association identifier which is used on encapsulated data that is sent to that entity.

Identification of the algorithm, keys or processing state should in general should not be bound to any addressing associated with the encapsulation.  Such a relationship is not necessary for the processing and limits the architectural layering of the encapsulation (note - this is subtle error introduced in most implementations of IPsec that greatly complicates the use of IPsec in NATing environments).

The down-side of this abstraction is that the encapsulation becomes very generic and some additional fields may need to be added and documented for specific cipher suites.  Some clarity could be provided by picking a specific cipher suite as a worked example in the specification.

In summary - any cryptographic encapsulation mechanism does not need to directly carry any indication of the algorithms used for the protection.  This can actually become problematic since the algorithm type values can be subject to modification. The use of any cryptographic mechanism adds state to what otherwise might be stateless protocol processing.  The direct representation of this association as a unique identifier can carry the predetermined algorithms, keys and other associated parameters necessary for decapsulation and validation.

Paul

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