From Chris.Dearlove@baesystems.com Tue Dec 1 01:58:15 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81F9A3A6A2D for ; Tue, 1 Dec 2009 01:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZLQJqrZJbdo for ; Tue, 1 Dec 2009 01:58:14 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 389253A67BE for ; Tue, 1 Dec 2009 01:58:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.47,319,1257120000"; d="scan'208";a="35908616" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 01 Dec 2009 09:58:06 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nB19wEpE003850; Tue, 1 Dec 2009 09:58:15 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 09:58:06 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 1 Dec 2009 09:57:44 -0000 Message-ID: In-Reply-To: <200912010726.28014.henning.rogge@fkie.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Security drafts Thread-Index: AcpyTz5FKNyiUK58TrOOFQFZAh5PbwAHSAtA References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBAB3B@SC-VEXCH2.marvell.com> <200912010726.28014.henning.rogge@fkie.fraunhofer.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , X-OriginalArrivalTime: 01 Dec 2009 09:58:06.0090 (UTC) FILETIME=[C76686A0:01CA726C] Cc: T.Clausen@computer.org Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 09:58:15 -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=20 being used. (That these are in the signature block makes length deduction messier also.) --=20 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:henning.rogge@fkie.fraunhofer.de]=20 Sent: 01 December 2009 06:26 To: manet@ietf.org Cc: Dearlove, Christopher (UK); Paul Lambert; Teco Boot; Ulrich Herberg; T.= Clausen@computer.org 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. >=20 > 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= =20 output length ? It can be even worse, because we combine a hash function and an encryption= =20 function. So we need to know the length of the hash output, must define if = it's=20 padded or shortened before it's pushed into the encryption function, then w= e=20 have to know the output size of the encryption function and again do have t= o=20 decide if we shorten or pad the final TLV data. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de 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@marvell.com Tue Dec 1 10:53:21 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE7CE3A67F2 for ; Tue, 1 Dec 2009 10:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pergnmdzvdVm for ; Tue, 1 Dec 2009 10:53:21 -0800 (PST) Received: from dakia2.marvell.com (dakia2.marvell.com [65.219.4.35]) by core3.amsl.com (Postfix) with ESMTP id F23E73A680B for ; Tue, 1 Dec 2009 10:53:20 -0800 (PST) X-ASG-Debug-ID: 1259693593-2d88021e0000-Rp4q3q X-Barracuda-URL: http://10.68.76.222:80/cgi-bin/mark.cgi Received: from maili.marvell.com (maili.marvell.com [10.68.76.51]) by dakia2.marvell.com (Spam & Virus Firewall) with ESMTP id 56E991F3F21; Tue, 1 Dec 2009 10:53:13 -0800 (PST) Received: from maili.marvell.com (maili.marvell.com [10.68.76.51]) by dakia2.marvell.com with ESMTP id Hw7VxkePzATP3IxG; Tue, 01 Dec 2009 10:53:13 -0800 (PST) Received: from MSI-MTA.marvell.com (msi-mta.marvell.com [10.68.76.91]) by maili.marvell.com (Postfix) with ESMTP id 3F6C880A64; Tue, 1 Dec 2009 10:53:13 -0800 (PST) Received: from sc-owa01.marvell.com ([10.93.76.21]) by MSI-MTA.marvell.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 10:53:12 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa01.marvell.com ([10.93.76.21]) with mapi; Tue, 1 Dec 2009 10:53:12 -0800 From: Paul Lambert To: Henning Rogge , "manet@ietf.org" Date: Tue, 1 Dec 2009 10:53:11 -0800 X-ASG-Orig-Subj: RE: [manet] Security drafts Thread-Topic: [manet] Security drafts Thread-Index: AcpyT0CZf6PnCyyDTAul4hVhihjaCwAYvPGw Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBAE3A@SC-VEXCH2.marvell.com> References: <25c114b90911112143r6453c425h7386d76d1c77a0c7@mail.gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D013B5DBAB3B@SC-VEXCH2.marvell.com> <200912010726.28014.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <200912010726.28014.henning.rogge@fkie.fraunhofer.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Dec 2009 18:53:12.0997 (UTC) FILETIME=[889BBD50:01CA72B7] X-Barracuda-Connect: maili.marvell.com[10.68.76.51] X-Barracuda-Start-Time: 1259693593 X-Barracuda-Virus-Scanned: by dakia2.marvell.com at marvell.com X-Barracuda-Spam-Score: -1002.00 X-Barracuda-Spam-Status: No, SCORE=-1002.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 Cc: "Dearlove, Christopher \(UK\)" , "T.Clausen@computer.org" Subject: Re: [manet] Security drafts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 18:53:22 -0000 > -----Original Message----- > From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] > Sent: Monday, November 30, 2009 10:26 PM > To: manet@ietf.org > Cc: Dearlove, Christopher (UK); Paul Lambert; Teco Boot; Ulrich Herberg; > T.Clausen@computer.org > Subject: Re: [manet] Security drafts > Importance: Low >=20 > 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 has= h > output length ? >=20 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 al= gorithms are selected individually (key exchange, signature, integrity/hash= , etc.) you get many combinations and most are not useful and potentially a= re 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 approp= riate cipher suite and the appropriate state (keys, counters, etc.). A "se= curity association identifier" can be carried in the encapsulation to suppo= rt the identification of the cipher suite and state (e.g. keys to use). Prior to encapsulation - key management is obviously required. This will e= stablish in some manner the security association and the unique security as= sociation identifiers. Note that for a pair-wise security association, two= identifiers are required - one for each communicating party. In a distrib= uted environment it is impossible to coordinate a single such dynamic ident= ifier. 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 arch= itectural layering of the encapsulation (note - this is subtle error introd= uced in most implementations of IPsec that greatly complicates the use of I= Psec in NATing environments). The down-side of this abstraction is that the encapsulation becomes very ge= neric and some additional fields may need to be added and documented for sp= ecific 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 dir= ectly carry any indication of the algorithms used for the protection. This= can actually become problematic since the algorithm type values can be sub= ject to modification. The use of any cryptographic mechanism adds state to = what otherwise might be stateless protocol processing. The direct represen= tation of this association as a unique identifier can carry the predetermin= ed algorithms, keys and other associated parameters necessary for decapsula= tion and validation. Paul =20 Paul A. Lambert | Marvell Semiconductor | +1 650-787-9141 =20 From hrogge@googlemail.com Tue Dec 8 08:44:18 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9E2828C1FE for ; Tue, 8 Dec 2009 08:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFzJjMuLNy3b for ; Tue, 8 Dec 2009 08:44:18 -0800 (PST) Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by core3.amsl.com (Postfix) with ESMTP id D4B8228C204 for ; Tue, 8 Dec 2009 08:44:17 -0800 (PST) Received: by ewy1 with SMTP id 1so2970474ewy.28 for ; Tue, 08 Dec 2009 08:44:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:mime-version:content-type:content-transfer-encoding :message-id; bh=pIFkcuFJrDrI/fFDuFoEqC2jtk3LCzBm+vCSZDSslk4=; b=dnVmEOLAEghZ9tolb5c3syFv2evQE0A98q0PZNnnjM5wJ7xW0WDBsA8ltN23mtQVFg cECTnD86AKW5BBRd0k2Ns4gmxoXsIzg8bHGfNJpndvXbHOpU4SbDSCZNrSB0ArXb17Ah KV578cAg4MuGrFnUpSsdXiqvTnURbPTM6xpQ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; b=JNHPnfqwqWUWkaCHOhn62DPcuDBBVTG79+6tprSUNDHZT4qcG0rHDOsf3MWC3nxMtb +k4PqTDkTwbsmsx/1q0T/Uzkjj27L0oYIfGtPykIuD5dMfc4eqZd5d3BBWRY/B6mDsXN IFR/3TUFaXCqhq2BdnhWLB7zAOaJ1grtDOxAQ= Received: by 10.213.110.201 with SMTP id o9mr3032552ebp.35.1260290635187; Tue, 08 Dec 2009 08:43:55 -0800 (PST) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 14sm4084997ewy.11.2009.12.08.08.43.54 (version=SSLv3 cipher=RC4-MD5); Tue, 08 Dec 2009 08:43:54 -0800 (PST) From: Henning Rogge To: manet@ietf.org Date: Tue, 8 Dec 2009 17:43:40 +0100 User-Agent: KMail/1.12.4 (Linux/2.6.32-gentoo; KDE/4.3.4; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4068265.amRluvRLp2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200912081743.53428.hrogge@googlemail.com> Subject: [manet] ETX metric draft-00 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 16:44:19 -0000 --nextPart4068265.amRluvRLp2 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, as announced by Thomas Clausen at the IETF Meeting in Hiroshima we have wor= ked=20 on a draft about the ETX metric for OLSRv2 we use at the Freifunk and=20 =46unkfeuer networks. http://www.ietf.org/id/draft-funkfeuer-manet-olsrv2-etx-00.txt Henning Rogge --nextPart4068265.amRluvRLp2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEABECAAYFAksegkkACgkQcenvcwAcHWeK8gCeNieqo8qOuMPk2sWz32TVMEN4 0WYAoIv+a+Pqmn6yvlfWbW37QyExkzqL =Fpkd -----END PGP SIGNATURE----- --nextPart4068265.amRluvRLp2--