From sshen@huawei.com Tue Jan 1 23:42:25 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m024gOsn016358 for ; Tue, 1 Jan 2008 23:42:25 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m024gESY006475 for ; Tue, 1 Jan 2008 23:42:14 -0500 (EST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [61.144.161.55]) by mit.edu (Spam Firewall) with ESMTP id 4C5C4EEE682 for ; Tue, 1 Jan 2008 23:41:51 -0500 (EST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JU0007C72DO0V@szxga03-in.huawei.com> for saag@mit.edu; Wed, 02 Jan 2008 12:41:48 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JU000CFL2DNGB@szxga03-in.huawei.com> for saag@mit.edu; Wed, 02 Jan 2008 12:41:48 +0800 (CST) Received: from s102542 ([10.111.12.53]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JU0004IC2DJ7O@szxml03-in.huawei.com> for saag@mit.edu; Wed, 02 Jan 2008 12:41:47 +0800 (CST) Date: Wed, 02 Jan 2008 12:41:44 +0800 From: Sean Shuo Shen In-reply-to: <4775344B.7020105@isi.edu> To: "'Joe Touch'" Message-id: <001901c84cf9$c6e6eed0$350c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AchJeQ22h+aYLANbT/2nojmb9/a3MADas4Ag X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, cfrg@ietf.org Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 04:42:25 -0000 Hi, Joe >> >> 1. interface: >> I agree that MAC interface without a nonce may make implementation easier. >> But nonce may not expand the size of MAC because it can be generated by both >> sides of a TCP connection. For example, the nonce in UMAC can simply be a >> counter from 0 to a certain upper bound. Even if nonce requires randomness, >> a PRFed value of a counter or sequence number (I remember Joe Touch >> mentioned in Vancouver that key generation of TCP AO should not use any >> bytes of TCP packets, but I think nonce should be ok.) can provide >> randomness. Noticing the good performance of MACs like UMAC, maybe we should >> keep the door open to MACs with nonce. >The TCP fields must not be used as a nonce for the MAC; although they do >change, the ways they change are not ensured to be predictable (e.g., >TCP can validly send overlapping segments). As such, a per-packet nonce >would need to be sent in the TCP option field, and there is insufficient >space to do that on a per-packet basis (which is why there is no such >field in TCP-AO). I think I may need to clarify what I said: if a random nonce is needed for TCP MAC, a PRFed value of sequence number provides randomness, for example: nonce=F_K2(seq num), K2 is the key for the pseudo random function F. K2 is different from the hash function key K1. (Actually, in UMAC, the nonce itself does not require randomness at all, the nonce processing part of UMAC already create randomness). The distribution/rekeying of K2 will be done together with K1. I don't get why you hope sequence number be predictable here. Both sides will know the sequence number from the TCP header and calculate the nonce=F_K2(seq num), they are not predicting either the sequence number or the nonce. >> 2. incremental MAC >> I understand the use of incrementality for virus protection but can not see >> the benefit of incrementality for TCP AO, at least in the BGP situation. In >> tcpm-tcp-auth-op, the MAC is computed over "TCP pseudo header + TCP header + >> TCP data", the first two parts (totally about 32 bytes or more for ipv4, 60 >> bytes or more for ipv6) are fixed for a connection, >The TCP sequence number varies during a connection, but it can wrap >around. It's entirely possible to have two segments that have the same >sequence number at different times in a connection, however. This is why >we probably need to explicitly require that the connection key change >whenever the sequence number rolls over (through the ISN). Does this have anything to do with incrementality of MAC? The connection key (hash function key) should change whenever the sequence number rolls over, so does the key for pseudorandom function, actually, that's exactly what UMAC requires. The distribution/rekeying of PRF key should be done together with the hash function key and it won't require much work from future TCP-AO key management scheme (by the way, anything available yet? ). Sean From touch@ISI.EDU Wed Jan 2 01:02:58 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m0262weF026907 for ; Wed, 2 Jan 2008 01:02:58 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m0262mbI005358 for ; Wed, 2 Jan 2008 01:02:48 -0500 (EST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 3B08BEB8C7C for ; Wed, 2 Jan 2008 01:02:27 -0500 (EST) Received: from [192.168.1.44] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m0261sLO006731; Tue, 1 Jan 2008 22:01:55 -0800 (PST) Message-ID: <477B28C5.2050903@isi.edu> Date: Tue, 01 Jan 2008 22:01:41 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Sean Shuo Shen References: <001901c84cf9$c6e6eed0$350c6f0a@china.huawei.com> In-Reply-To: <001901c84cf9$c6e6eed0$350c6f0a@china.huawei.com> X-Enigmail-Version: 0.95.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB50BA631F13DA0D0A8907910" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, cfrg@ietf.org Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 06:02:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB50BA631F13DA0D0A8907910 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sean Shuo Shen wrote: > Hi, Joe >=20 >>> 1. interface: >>> I agree that MAC interface without a nonce may make implementation > easier. >>> But nonce may not expand the size of MAC because it can be generated = by > both >>> sides of a TCP connection. For example, the nonce in UMAC can simply = be a >>> counter from 0 to a certain upper bound. Even if nonce requires > randomness, >>> a PRFed value of a counter or sequence number (I remember Joe Touch >>> mentioned in Vancouver that key generation of TCP AO should not use a= ny >>> bytes of TCP packets, but I think nonce should be ok.) can provide >>> randomness. Noticing the good performance of MACs like UMAC, maybe we= > should >>> keep the door open to MACs with nonce. >=20 >> The TCP fields must not be used as a nonce for the MAC; although they = do >> change, the ways they change are not ensured to be predictable (e.g., >> TCP can validly send overlapping segments). As such, a per-packet nonc= e >> would need to be sent in the TCP option field, and there is insufficie= nt >> space to do that on a per-packet basis (which is why there is no such >> field in TCP-AO). >=20 > I think I may need to clarify what I said: if a random nonce is needed = for > TCP MAC, a PRFed value of sequence number provides randomness, for exam= ple: > nonce=3DF_K2(seq num), K2 is the key for the pseudo random function F. = K2 is > different from the hash function key K1. (Actually, in UMAC, the nonce > itself does not require randomness at all, the nonce processing part of= UMAC > already create randomness). The distribution/rekeying of K2 will be don= e > together with K1.=20 > I don't get why you hope sequence number be predictable here. Both side= s > will know the sequence number from the TCP header and calculate the > nonce=3DF_K2(seq num), they are not predicting either the sequence numb= er or > the nonce. I'm not at all clear on hashing a single 32-bit number to generate a useful nonce. If you're using it to index a nonce generate by some other means, perhaps - but that assumes some other source of randomness is used to create a sequence of nonces (K2, above). In that case, K2 would need to be managed and updated when the seqnum rolls over as well. However, there is no rule that the seqnum is used only once until rollover. TCP can retransmit a segment, and the retransmitted segment can be longer or shorter than the original transmission. For this reason, I don't believe seqnum is useful as a nonce, or to derive a nonce, for crypto purposes. >>> 2. incremental MAC >>> I understand the use of incrementality for virus protection but can n= ot > see >>> the benefit of incrementality for TCP AO, at least in the BGP situati= on. > In >>> tcpm-tcp-auth-op, the MAC is computed over "TCP pseudo header + TCP > header + >>> TCP data", the first two parts (totally about 32 bytes or more for ip= v4, > 60 >>> bytes or more for ipv6) are fixed for a connection,=20 >=20 >> The TCP sequence number varies during a connection, but it can wrap >> around. It's entirely possible to have two segments that have the same= >> sequence number at different times in a connection, however. This is w= hy >> we probably need to explicitly require that the connection key change >> whenever the sequence number rolls over (through the ISN). >=20 > Does this have anything to do with incrementality of MAC? =20 > The connection key (hash function key) should change whenever the seque= nce > number rolls over, so does the key for pseudorandom function, actually,= > that's exactly what UMAC requires.=20 It's not clear why UMAC then needs to treat the nonce field differently from the rest of the segment - unless the nonce itself is ensured nonrepeated for that key set. If that's the case, then, as noted above, seqnum isn't a viable source of that nonce. > The distribution/rekeying of PRF key > should be done together with the hash function key and it won't require= much > work from future TCP-AO key management scheme (by the way, anything > available yet? ).=20 TCPM is asking for the key management protocol to come out of SAAG - that's why we're having that discussion here. Joe --------------enigB50BA631F13DA0D0A8907910 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHeyjME5f5cImnZrsRArl5AKCqocU1KtL1uJf+Z4cctJpZnMovOgCeIHd3 YFQYsa9xI/JPR6YYjq4IHKM= =uQDF -----END PGP SIGNATURE----- --------------enigB50BA631F13DA0D0A8907910-- From sshen@huawei.com Wed Jan 2 03:50:11 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m028oBMf005838 for ; Wed, 2 Jan 2008 03:50:11 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m028nxQe024189 for ; Wed, 2 Jan 2008 03:49:59 -0500 (EST) Received: from szxga02-in.huawei.com (unknown [61.144.161.54]) by mit.edu (Spam Firewall) with ESMTP id 62B33C87526 for ; Wed, 2 Jan 2008 03:49:36 -0500 (EST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JU0009I2DU2WA@szxga02-in.huawei.com> for saag@mit.edu; Wed, 02 Jan 2008 16:49:14 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JU000JMCDU0HD@szxga02-in.huawei.com> for saag@mit.edu; Wed, 02 Jan 2008 16:49:14 +0800 (CST) Received: from s102542 ([10.111.12.53]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JU000K3TDTWPO@szxml04-in.huawei.com> for saag@mit.edu; Wed, 02 Jan 2008 16:49:12 +0800 (CST) Date: Wed, 02 Jan 2008 16:49:09 +0800 From: Sean Shuo Shen In-reply-to: <477B28C5.2050903@isi.edu> To: "'Joe Touch'" Message-id: <002d01c84d1c$5746f430$350c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AchNBZkr8xErVA8JTe+HYHBtv0ufpwAByRlQ X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, cfrg@ietf.org Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 08:50:11 -0000 >>>> 1. interface: >>>> I agree that MAC interface without a nonce may make implementation >> easier. >>>> But nonce may not expand the size of MAC because it can be generated by >> both >>>> sides of a TCP connection. For example, the nonce in UMAC can simply be a >>>> counter from 0 to a certain upper bound. Even if nonce requires >> randomness, >>>> a PRFed value of a counter or sequence number (I remember Joe Touch >>>> mentioned in Vancouver that key generation of TCP AO should not use any >>>> bytes of TCP packets, but I think nonce should be ok.) can provide >>>> randomness. Noticing the good performance of MACs like UMAC, maybe we >> should >>>> keep the door open to MACs with nonce. > >>> The TCP fields must not be used as a nonce for the MAC; although they do >>> change, the ways they change are not ensured to be predictable (e.g., >>> TCP can validly send overlapping segments). As such, a per-packet nonce >>> would need to be sent in the TCP option field, and there is insufficient >>> space to do that on a per-packet basis (which is why there is no such >>> field in TCP-AO). >> >> I think I may need to clarify what I said: if a random nonce is needed for >> TCP MAC, a PRFed value of sequence number provides randomness, for example: >> nonce=F_K2(seq num), K2 is the key for the pseudo random function F. K2 is >> different from the hash function key K1. (Actually, in UMAC, the nonce >> itself does not require randomness at all, the nonce processing part of UMAC >> already create randomness). The distribution/rekeying of K2 will be done >> together with K1. >> I don't get why you hope sequence number be predictable here. Both sides >> will know the sequence number from the TCP header and calculate the >> nonce=F_K2(seq num), they are not predicting either the sequence number or >> the nonce. >I'm not at all clear on hashing a single 32-bit number to generate a >useful nonce. If you're using it to index a nonce generate by some other >means, perhaps - but that assumes some other source of randomness is >used to create a sequence of nonces (K2, above). In that case, K2 would >need to be managed and updated when the seqnum rolls over as well. In the example: nonce=F_K2(seq num). The randomness comes from the K2, seq num is used to let PRF gives different pseudo random integers each time. And as I said above, K2 does need be managed and updated just as the hash function key does. ( Similarly, in crypto algorithms like PRF_HMAC_SHA1 or the nonce processing part of UMAC, the randomness comes from the key, not from some input counter, non-secret pad or strings.) >However, there is no rule that the seqnum is used only once until >rollover. TCP can retransmit a segment, and the retransmitted segment >can be longer or shorter than the original transmission. For this >reason, I don't believe seqnum is useful as a nonce, or to derive a >nonce, for crypto purposes. Thank you for pointing out the situation when a seq num is used again before rollover. Since both sides of a tcp connection know the header length of TCP and IP headers, also know the total length of the IP datagram, they can calculate the length of the segment that TCP transmitted. Therefore the nonce can be calculated as: nonce=F_K2(seq num, segment length), where segment length=ip_total_length - 4 * tcp_header_length - 4 * ip_header_length. In case TCP retransmit a segment (same starting byte) with different size, a different nonce will be generated. The nonce will be same only when the exact same segment is retransmitted. >>>> 2. incremental MAC >>>> I understand the use of incrementality for virus protection but can not >> see >>>> the benefit of incrementality for TCP AO, at least in the BGP situation. >> In >>>> tcpm-tcp-auth-op, the MAC is computed over "TCP pseudo header + TCP >> header + >>>> TCP data", the first two parts (totally about 32 bytes or more for ipv4, >> 60 >>>> bytes or more for ipv6) are fixed for a connection, >> >>> The TCP sequence number varies during a connection, but it can wrap >>> around. It's entirely possible to have two segments that have the same >>> sequence number at different times in a connection, however. This is why >>> we probably need to explicitly require that the connection key change >>> whenever the sequence number rolls over (through the ISN). >> >> Does this have anything to do with incrementality of MAC? >> The connection key (hash function key) should change whenever the sequence >> number rolls over, so does the key for pseudorandom function, actually, >> that's exactly what UMAC requires. >It's not clear why UMAC then needs to treat the nonce field differently >from the rest of the segment - unless the nonce itself is ensured >nonrepeated for that key set. If that's the case, then, as noted above, >seqnum isn't a viable source of that nonce. Yes, the nonce can be ensured nonrepeated as described above. Sean From mcgrew@cisco.com Wed Jan 2 10:08:16 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m02F8Ghk024685 for ; Wed, 2 Jan 2008 10:08:16 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m02F84c6017211 for ; Wed, 2 Jan 2008 10:08:04 -0500 (EST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by mit.edu (Spam Firewall) with ESMTP id 2C9DAD0405D for ; Wed, 2 Jan 2008 10:07:40 -0500 (EST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 02 Jan 2008 10:07:40 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m02F7d8K012421; Wed, 2 Jan 2008 10:07:39 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m02F7T9R023962; Wed, 2 Jan 2008 15:07:39 GMT Received: from xmb-rtp-20c.amer.cisco.com ([64.102.31.57]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Jan 2008 10:06:53 -0500 Received: from 10.32.254.211 ([10.32.254.211]) by xmb-rtp-20c.amer.cisco.com ([64.102.31.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 2 Jan 2008 15:06:53 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Wed, 02 Jan 2008 07:06:49 -0800 From: mcgrew To: Sean Shuo Shen , "'Brian Weis'" Message-ID: Thread-Topic: [Cfrg] Re: [saag] TCP-AO MAC algorithms Thread-Index: AchDIAo/SQgSTa8TEdyWUgAUUQnMFgF/NZAgAQ0OKyI= In-Reply-To: <000901c8491f$43da4150$350c6f0a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Jan 2008 15:06:53.0506 (UTC) FILETIME=[1BDA9A20:01C84D51] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6309; t=1199286459; x=1200150459; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:=20mcgrew=20 |Subject:=20Re=3A=20[Cfrg]=20Re=3A=20[saag]=20TCP-AO=20MAC= 20algorithms |Sender:=20 |To:=20Sean=20Shuo=20Shen=20,=20=22'Brian =20Weis'=22=20; bh=pwtppJ3SM03tcJ3Cz4H0ULK7eCwXebCyoeQU+vyFsqA=; b=ZJnPvozwZyPiFKn6Tf4MopcoadhHyWZQtEtYQ+jy8B149bJrSUfwA2DOE+ Lixc/3fX8ZNTTBQpKJSGPv1xwcC+XNm1NyrpXMISafsStoEYwntkCzwGT/2h Xjg0Cop1Uc; Authentication-Results: rtp-dkim-1; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.14 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, cfrg@ietf.org Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 15:08:16 -0000 Hi Sean, Thanks for your comments, more inline: On 12/27/07 11:00 PM, "Sean Shuo Shen" wrote: > Dear David, > I read the draft-irtf-cfrg-fast-mac-requirements and believe the draft gives > good security and efficiency description for TCP AO MAC. I have a few > thoughts according the following issues in the draft: > > 1. interface: > I agree that MAC interface without a nonce may make implementation easier. > But nonce may not expand the size of MAC because it can be generated by both > sides of a TCP connection. For example, the nonce in UMAC can simply be a > counter from 0 to a certain upper bound. Agreed, it is true that in some cases the nonce need not be carried explicitly along with the MAC value, but instead can be reconstructed by the receiver using other information. It is also possible to use "Partially Implicit Nonces", in the terms of Section 3.2.1 of draft-mcgrew-auth-enc, which trades off nonce size against protocol robustness. Perhaps this is worth investigating for TCP-AO, though I still think that nonceless MACs should be favored because of their simplicity. However, the implicit nonce idea does nothing to address the fact that nonce-based algorithms are undesirable whenever it is difficult to ensure nonce coordination, i.e. when key management is absent. > Even if nonce requires randomness, > a PRFed value of a counter or sequence number (I remember Joe Touch > mentioned in Vancouver that key generation of TCP AO should not use any > bytes of TCP packets, but I think nonce should be ok.) can provide > randomness. Noticing the good performance of MACs like UMAC, maybe we should > keep the door open to MACs with nonce. I'm optimistic that worthwhile nonceless MACs can be made. For example, UMAC can easily be turned into a nonceless MAC by changing its definition from MAC = AES(K, Nonce) (+) Hash(Message) To MAC = AES(K, Hash(Message)) The latter form is actually closer to the initial version of UMAC. MACs of this form don't meet requirement R6, though. > > 2. incremental MAC > I understand the use of incrementality for virus protection but can not see > the benefit of incrementality for TCP AO, at least in the BGP situation. I agree, I didn't mean to imply in the requirements draft that TCP AO would find incrementality useful. That feature seems more useful in a data-storage context than a communications context. Brian and I included that feature in the list because it is a desirable property of a general-purpose MAC. > In > tcpm-tcp-auth-op, the MAC is computed over "TCP pseudo header + TCP header + > TCP data", the first two parts (totally about 32 bytes or more for ipv4, 60 > bytes or more for ipv6) are fixed for a connection, while the length of BGP > part (that part that will change) will be ranged from 19 to 4096 bytes. Thus > difference of packets is not small. Please let me know if there are good > ways to use incrementality in BGP or other scenarios. I think you hit the nail on the head here. In many communication protocols, it is possible (in principle at least) for the MAC to pre-process the headers, but in practice the gains often are not worth the effort. > > Thank you and happy new year to all! Thanks, and wishing you the same! Best regards, David > Regards, > > Sean > > -----Original Message----- > From: mcgrew [mailto:mcgrew@cisco.com] > Sent: Thursday, December 20, 2007 11:50 PM > To: Brian Weis > Cc: saag@mit.edu; cfrg@ietf.org > Subject: [Cfrg] Re: [saag] TCP-AO MAC algorithms > > Hi Brian, > > I've cross-posted to CFRG to tie the TCP Auth work in with > draft-irtf-cfrg-fast-mac-requirements draft. > > On 12/18/07 4:23 PM, "Brian Weis" wrote: > >> Greetings, >> >> The TCPM WG seeks advice from SAAG on which MACs to include as >> required MACs for the TCP Authentication Option (draft-ietf-tcpm-tcp- >> auth-opt-00). Two MACs with differing internal constructions are >> desired. > > I assume that the reason for having two mandatory-to-implement MACs is to > ensure algorithm agility. > >> >> In my opinion, it is also important that MACs defined by an Internet >> standard as required to be implemented be based on NIST-approved >> algorithms and modes, and also be generally available in both >> software and cryptographic hardware. >> >> The following two MACs are reasonable recommendations that taken >> together easily meet the above criteria: HMAC-SHA-1 and AES-CMAC. I >> propose that these be the algorithms provided to the TCPM WG. >> >> Brian > > Sounds like reasonable choices to me. > > It would be good to have a MAC that performs exceptionally well in software, > along the lines of what we've targeted in > draft-irtf-cfrg-fast-mac-requirements, but if the choice of MACs has to be > made *today*, there may not be a suitable candidate that has been > sufficiently specified and/or reviewed. I expect that MACs that will be > more suitable for use in TCP Authentication will be developed (candidates > include [1] and [2]). I trust that there is a path for the adoption of new > MACs in TCP Auth. > > Probably the biggest open question is the length of the MAC. The CMAC > specification states that lengths 64 bits and higher are acceptable, but > that smaller values "shall only be used in conjunction > with a careful analysis of the risks" [1]. It would be good to do this > analysis for TCP Auth, of course, but it is encouraging that AES-128-CMAC > could be used with a 64-bit tag and still meet the conformance goals that > you outlined. > > Best regards, > > David > > > [1] J. Black and M. Cochran, "MAC Reforgeability", > http://eprint.iacr.org/2006/095 > > [2] D.J. Bernstein, "Polynomial evaluation and message authentication", > http://cr.yp.to/antiforgery/pema-20071022.pdf > > [3] M. Dworkin, NIST Special Publication 800-38B, "Recommendation for Block > Cipher Modes of Operation: The CMAC Mode for Authentication" > http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg From touch@ISI.EDU Wed Jan 2 10:30:41 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m02FUfPu032129 for ; Wed, 2 Jan 2008 10:30:41 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m02FUX4o023348 for ; Wed, 2 Jan 2008 10:30:33 -0500 (EST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id E24D94CFBFD for ; Wed, 2 Jan 2008 10:29:59 -0500 (EST) Received: from [192.168.1.44] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m02FTUaB012912; Wed, 2 Jan 2008 07:29:31 -0800 (PST) Message-ID: <477BADD1.60307@isi.edu> Date: Wed, 02 Jan 2008 07:29:21 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Sean Shuo Shen References: <002d01c84d1c$5746f430$350c6f0a@china.huawei.com> In-Reply-To: <002d01c84d1c$5746f430$350c6f0a@china.huawei.com> X-Enigmail-Version: 0.95.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig75376A5B1F7B1FFD2FA3D975" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, cfrg@ietf.org Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 15:30:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig75376A5B1F7B1FFD2FA3D975 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sean Shuo Shen wrote: >>>>> 1. interface: =2E.. >> However, there is no rule that the seqnum is used only once until >> rollover. TCP can retransmit a segment, and the retransmitted segment >> can be longer or shorter than the original transmission. For this >> reason, I don't believe seqnum is useful as a nonce, or to derive a >> nonce, for crypto purposes. >=20 > Thank you for pointing out the situation when a seq num is used again b= efore > rollover. Since both sides of a tcp connection know the header length o= f TCP > and IP headers, also know the total length of the IP datagram, they can= > calculate the length of the segment that TCP transmitted. Therefore the= > nonce can be calculated as: nonce=3DF_K2(seq num, segment length), wher= e > segment length=3Dip_total_length - 4 * tcp_header_length - 4 * > ip_header_length. In case TCP retransmit a segment (same starting byte)= with > different size, a different nonce will be generated. The nonce will be = same > only when the exact same segment is retransmitted.=20 I presume you're looking for a nonce that would be unique per unique segment. It would be preferable to insert either that nonce or an index thereto in the MAC itself, than to make assumptions of the uniqueness of any fields of the TCP segment or a hash that would be derived from them. Joe --------------enig75376A5B1F7B1FFD2FA3D975 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHe63VE5f5cImnZrsRAqovAKC/DkTO1DhGeMXm3wo69saaZJKKuwCgxzxc 2+sJJ7ymHnWJ5ywkfDO0+aM= =jqXK -----END PGP SIGNATURE----- --------------enig75376A5B1F7B1FFD2FA3D975-- From kent@bbn.com Wed Jan 2 10:37:40 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m02Fbes0004383 for ; Wed, 2 Jan 2008 10:37:40 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m02FbWcC010739 for ; Wed, 2 Jan 2008 10:37:32 -0500 (EST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by mit.edu (Spam Firewall) with ESMTP id 83706ED9BBE for ; Wed, 2 Jan 2008 10:37:11 -0500 (EST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.0.101]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JA5eY-00009a-46; Wed, 02 Jan 2008 10:37:10 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 2 Jan 2008 10:37:16 -0500 To: mcgrew From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Sean Shuo Shen , cfrg@ietf.org Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 15:37:40 -0000 Anoher issue to keep in mind is that a nonce-less MAC avoids the FIPS evaluation problems that would arise from attempts to make use of the TCP sequence number as an input to the nonce generation process. Steve From touch@ISI.EDU Wed Jan 2 11:28:20 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m02GSKp9025876 for ; Wed, 2 Jan 2008 11:28:20 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m02GSD1H014423 for ; Wed, 2 Jan 2008 11:28:13 -0500 (EST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id CA0CFEDA830 for ; Wed, 2 Jan 2008 11:27:52 -0500 (EST) Received: from [75.215.99.146] (146.sub-75-215-99.myvzw.com [75.215.99.146]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m02GRYTH026820; Wed, 2 Jan 2008 08:27:35 -0800 (PST) Message-ID: <477BBB71.8020906@isi.edu> Date: Wed, 02 Jan 2008 08:27:29 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Joe Touch References: <002d01c84d1c$5746f430$350c6f0a@china.huawei.com> <477BADD1.60307@isi.edu> In-Reply-To: <477BADD1.60307@isi.edu> X-Enigmail-Version: 0.95.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC3543E9A69C40D1B649D60BD" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Sean Shuo Shen , cfrg@ietf.org Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 16:28:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC3543E9A69C40D1B649D60BD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Joe Touch wrote: >=20 > Sean Shuo Shen wrote: >>>>>> 1. interface: > ... >>> However, there is no rule that the seqnum is used only once until >>> rollover. TCP can retransmit a segment, and the retransmitted segment= >>> can be longer or shorter than the original transmission. For this >>> reason, I don't believe seqnum is useful as a nonce, or to derive a >>> nonce, for crypto purposes. >> Thank you for pointing out the situation when a seq num is used again = before >> rollover. Since both sides of a tcp connection know the header length = of TCP >> and IP headers, also know the total length of the IP datagram, they ca= n >> calculate the length of the segment that TCP transmitted. Therefore th= e >> nonce can be calculated as: nonce=3DF_K2(seq num, segment length), whe= re >> segment length=3Dip_total_length - 4 * tcp_header_length - 4 * >> ip_header_length. In case TCP retransmit a segment (same starting byte= ) with >> different size, a different nonce will be generated. The nonce will be= same >> only when the exact same segment is retransmitted.=20 >=20 > I presume you're looking for a nonce that would be unique per unique > segment. It would be preferable to insert either that nonce or an index= > thereto in the MAC itself, than to make assumptions of the uniqueness o= f > any fields of the TCP segment or a hash that would be derived from them= =2E >=20 > Joe FWIW, it might be possible for TCP to retransmit a segment with the same offset and size but with different options. In particular, if the user sets an option between a segment's initial transmission and subsequent retransmission, this could occur. I'm checking to see if this could also occur with TCP flags (e.g., FIN if a user closes a connection while data is outstanding). For these reasons, and because of the potential to constrain the evolution of TCP, I would urge the MAC computation to treat the non-zeroed TCP header and pseudoheader fields as opaque. Joe --------------enigC3543E9A69C40D1B649D60BD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHe7txE5f5cImnZrsRAlVNAJ9jpMDqGVFG0TvXnrdwSQPRU41ZvACgpNWG I9Jt9Zz8S2vy4oa9BdvOguQ= =7Bbh -----END PGP SIGNATURE----- --------------enigC3543E9A69C40D1B649D60BD-- From sshen@huawei.com Thu Jan 3 20:33:19 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m041XJqf032603 for ; Thu, 3 Jan 2008 20:33:19 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m041X95h017459 for ; Thu, 3 Jan 2008 20:33:10 -0500 (EST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [61.144.161.53]) by mit.edu (Spam Firewall) with ESMTP id 25DD2BBB88E for ; Thu, 3 Jan 2008 20:32:48 -0500 (EST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JU300GTBIYLUN@szxga01-in.huawei.com> for saag@mit.edu; Fri, 04 Jan 2008 09:32:45 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JU3001TYIYKUZ@szxga01-in.huawei.com> for saag@mit.edu; Fri, 04 Jan 2008 09:32:45 +0800 (CST) Received: from s102542 ([10.111.12.53]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JU300C1DIYGXS@szxml04-in.huawei.com> for saag@mit.edu; Fri, 04 Jan 2008 09:32:44 +0800 (CST) Date: Fri, 04 Jan 2008 09:32:36 +0800 From: Sean Shuo Shen In-reply-to: To: "'mcgrew'" , "'Brian Weis'" Message-id: <001b01c84e71$b2420040$350c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AchDIAo/SQgSTa8TEdyWUgAUUQnMFgF/NZAgAQ0OKyIAJaSU4A== X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, cfrg@ietf.org Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 01:33:19 -0000 Hi David, >> 1. interface: >> I agree that MAC interface without a nonce may make implementation easier. >> But nonce may not expand the size of MAC because it can be generated by both >> sides of a TCP connection. For example, the nonce in UMAC can simply be a >> counter from 0 to a certain upper bound. >Agreed, it is true that in some cases the nonce need not be carried >explicitly along with the MAC value, but instead can be reconstructed by the >receiver using other information. It is also possible to use "Partially >Implicit Nonces", in the terms of Section 3.2.1 of draft-mcgrew-auth-enc, >which trades off nonce size against protocol robustness. Perhaps this is >worth investigating for TCP-AO, though I still think that nonceless MACs >should be favored because of their simplicity. >However, the implicit nonce idea does nothing to address the fact that >nonce-based algorithms are undesirable whenever it is difficult to ensure >nonce coordination, i.e. when key management is absent. If a nonce is used for MAC and requires a key, I think it's reasonable to let the nonce key updated together with the hash key, similar as some other security schemes in which encryption keys and integrity protection keys are generated/renewed synchronously. Though the key management solution for TCP AO is not proposed yet, adding nonce key generation/distribution together with hash key won't affect much on overall performance. >> Even if nonce requires randomness, >> a PRFed value of a counter or sequence number (I remember Joe Touch >> mentioned in Vancouver that key generation of TCP AO should not use any >> bytes of TCP packets, but I think nonce should be ok.) can provide >> randomness. Noticing the good performance of MACs like UMAC, maybe we should >> keep the door open to MACs with nonce. >I'm optimistic that worthwhile nonceless MACs can be made. For example, >UMAC can easily be turned into a nonceless MAC by changing its definition >from >MAC = AES(K, Nonce) (+) Hash(Message) >To >MAC = AES(K, Hash(Message)) >The latter form is actually closer to the initial version of UMAC. >MACs of this form don't meet requirement R6, though. Yes, I agree. Regards Sean From sshen@huawei.com Thu Jan 3 20:59:43 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m041xh7h003807 for ; Thu, 3 Jan 2008 20:59:43 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m041xY3U022442 for ; Thu, 3 Jan 2008 20:59:34 -0500 (EST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [61.144.161.55]) by mit.edu (Spam Firewall) with ESMTP id 05BDDEE233A for ; Thu, 3 Jan 2008 20:59:12 -0500 (EST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JU300GDWK6I6O@szxga03-in.huawei.com> for saag@mit.edu; Fri, 04 Jan 2008 09:59:06 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JU300BD0K6IGE@szxga03-in.huawei.com> for saag@mit.edu; Fri, 04 Jan 2008 09:59:06 +0800 (CST) Received: from s102542 ([10.111.12.53]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JU300FA5K6EFO@szxml03-in.huawei.com> for saag@mit.edu; Fri, 04 Jan 2008 09:59:06 +0800 (CST) Date: Fri, 04 Jan 2008 09:59:02 +0800 From: Sean Shuo Shen In-reply-to: <477BBB71.8020906@isi.edu> To: "'Joe Touch'" Message-id: <002201c84e75$613c48a0$350c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AchNXNXWqhAputGBQOeV4aMCJw0xJQBFO4pA X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, cfrg@ietf.org Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 01:59:43 -0000 Hi Joe, >> I presume you're looking for a nonce that would be unique per unique >> segment. It would be preferable to insert either that nonce or an index >> thereto in the MAC itself, than to make assumptions of the uniqueness of >> any fields of the TCP segment or a hash that would be derived from them. Yes, I am discussing the possibility that unique nonce are generated by both sides without carrying extra info in MAC. Inserting an index (like a counter) or even the nonce itself certainly can make life easier, if we don't care the extra bytes together with the MAC. >FWIW, it might be possible for TCP to retransmit a segment with the same >offset and size but with different options. In particular, if the user >sets an option between a segment's initial transmission and subsequent >retransmission, this could occur. I'm checking to see if this could also >occur with TCP flags (e.g., FIN if a user closes a connection while data >is outstanding). >For these reasons, and because of the potential to constrain the >evolution of TCP, I would urge the MAC computation to treat the >non-zeroed TCP header and pseudoheader fields as opaque. I also believe some other bits in TCP header might be different even if the TCP is retransmitting the same segment. But all of these changes can easily be included in the PRF input when the nonce is calculated (it won't be heavy work compared with the calculation of MAC) to make sure different nonces are used when the authenticated content changes. Regards Sean From sshen@huawei.com Thu Jan 3 21:01:42 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m0421gIE004183 for ; Thu, 3 Jan 2008 21:01:42 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m0421Wwe012972 for ; Thu, 3 Jan 2008 21:01:32 -0500 (EST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [61.144.161.53]) by mit.edu (Spam Firewall) with ESMTP id DFC73BC9735 for ; Thu, 3 Jan 2008 21:01:09 -0500 (EST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JU300G4RK9VUN@szxga01-in.huawei.com> for saag@mit.edu; Fri, 04 Jan 2008 10:01:07 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JU30061BK9VYM@szxga01-in.huawei.com> for saag@mit.edu; Fri, 04 Jan 2008 10:01:07 +0800 (CST) Received: from s102542 ([10.111.12.53]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JU300FUSK9RFO@szxml03-in.huawei.com> for saag@mit.edu; Fri, 04 Jan 2008 10:01:06 +0800 (CST) Date: Fri, 04 Jan 2008 10:01:03 +0800 From: Sean Shuo Shen In-reply-to: To: "'Stephen Kent'" Message-id: <002301c84e75$a9354580$350c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AchNVcJzFHaHzEciSXq7I5MMswFqCABH6kaA X-Spam-Score: 0.14 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, cfrg@ietf.org Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 02:01:42 -0000 Hi Stephen, Can you talk more details about the FIPS evaluation problem? Sean -----Original Message----- From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of Stephen Kent Sent: Wednesday, January 02, 2008 11:37 PM To: mcgrew Cc: saag@mit.edu; Sean Shuo Shen; cfrg@ietf.org Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms Anoher issue to keep in mind is that a nonce-less MAC avoids the FIPS evaluation problems that would arise from attempts to make use of the TCP sequence number as an input to the nonce generation process. Steve _______________________________________________ saag mailing list saag@mit.edu http://mailman.mit.edu/mailman/listinfo/saag From smb@cs.columbia.edu Thu Jan 3 22:05:47 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m0435l86012823 for ; Thu, 3 Jan 2008 22:05:47 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m0435YqY011614 for ; Thu, 3 Jan 2008 22:05:35 -0500 (EST) Received: from machshav.com (machshav.com [198.180.150.44]) by mit.edu (Spam Firewall) with ESMTP id 2B0A4CBC80C for ; Thu, 3 Jan 2008 22:05:11 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id B609C183; Fri, 4 Jan 2008 03:05:10 +0000 (GMT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4E493160; Fri, 4 Jan 2008 03:05:09 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 27C4276618B; Thu, 3 Jan 2008 22:05:08 -0500 (EST) Date: Fri, 4 Jan 2008 03:05:07 +0000 From: "Steven M. Bellovin" To: Sean Shuo Shen Message-ID: <20080104030507.7297e280@cs.columbia.edu> In-Reply-To: <002301c84e75$a9354580$350c6f0a@china.huawei.com> References: <002301c84e75$a9354580$350c6f0a@china.huawei.com> Organization: Columbia University X-Mailer: Claws Mail 3.2.0 (GTK+ 2.12.0; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.13 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, cfrg@ietf.org Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 03:05:47 -0000 On Fri, 04 Jan 2008 10:01:03 +0800 Sean Shuo Shen wrote: > Hi Stephen, > Can you talk more details about the FIPS evaluation problem? > The issue is what the assurance boundary is. If the TCP sequence number is cryptographically significant, the entire process by which it's set (including original generation and anything else in the stack or kernel that could touch it) has to be part of the evaluation, too. It is, I think, less of an issue for TCP-AO, since I suspect that that's not very likely to be done by a dedicated hardware module. Still, as a matter of design principle one should keep security-critical matters separate. > > -----Original Message----- > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of > Stephen Kent > Sent: Wednesday, January 02, 2008 11:37 PM > To: mcgrew > Cc: saag@mit.edu; Sean Shuo Shen; cfrg@ietf.org > Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms > > Anoher issue to keep in mind is that a nonce-less MAC avoids the FIPS > evaluation problems that would arise from attempts to make use of the > TCP sequence number as an input to the nonce generation process. > > Steve > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag > > > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg > --Steve Bellovin, http://www.cs.columbia.edu/~smb From sshen@huawei.com Thu Jan 3 22:36:03 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m043a3dB016697 for ; Thu, 3 Jan 2008 22:36:03 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m043ZrUu022860 for ; Thu, 3 Jan 2008 22:35:53 -0500 (EST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [61.144.161.55]) by mit.edu (Spam Firewall) with ESMTP id 1889ECBCF5D for ; Thu, 3 Jan 2008 22:35:24 -0500 (EST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JU300GHAOMX4L@szxga03-in.huawei.com> for saag@mit.edu; Fri, 04 Jan 2008 11:35:21 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JU3008PLOMXH7@szxga03-in.huawei.com> for saag@mit.edu; Fri, 04 Jan 2008 11:35:21 +0800 (CST) Received: from s102542 ([10.111.12.53]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JU300MPDOMT56@szxml04-in.huawei.com> for saag@mit.edu; Fri, 04 Jan 2008 11:35:21 +0800 (CST) Date: Fri, 04 Jan 2008 11:35:17 +0800 From: Sean Shuo Shen In-reply-to: <20080104030507.7297e280@cs.columbia.edu> To: "'Steven M. Bellovin'" Message-id: <002a01c84e82$d36efb40$350c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AchOf0SsfVRFlWWWRnerLPhBihZpGgAAN1Pw X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, cfrg@ietf.org Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 03:36:03 -0000 Thank you Steven. >>Sean Shuo Shen wrote: >> Hi Stephen, >> Can you talk more details about the FIPS evaluation problem? >The issue is what the assurance boundary is. If the TCP sequence >number is cryptographically significant, the entire process by which >it's set (including original generation and anything else in the stack >or kernel that could touch it) has to be part of the evaluation, too. The isn generation of some windows versions and linux is not random enough and is vulnerable (like RST attack). So the seq num can not be a source for randomness. But if a seq num is used just as an index instead of a random seed, it is not cryptographically significant and I don't think it will affect the cryptographic strength. What do you think, Steven? Regards Sean From smb@cs.columbia.edu Thu Jan 3 23:33:27 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m044XROG024637 for ; Thu, 3 Jan 2008 23:33:27 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m044XFqS024495 for ; Thu, 3 Jan 2008 23:33:16 -0500 (EST) Received: from machshav.com (machshav.com [198.180.150.44]) by mit.edu (Spam Firewall) with ESMTP id 2223DBB17C1 for ; Thu, 3 Jan 2008 23:32:52 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id D016B5BB; Fri, 4 Jan 2008 04:32:51 +0000 (GMT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3DCC817E; Fri, 4 Jan 2008 04:32:51 +0000 (GMT) Received: by berkshire.machshav.com (Postfix, from userid 54047) id 3DB8C7661D4; Thu, 3 Jan 2008 23:32:50 -0500 (EST) Date: Fri, 4 Jan 2008 04:32:50 +0000 From: "Steven M. Bellovin" To: Sean Shuo Shen Message-ID: <20080104043250.586adf6c@berkshire.machshav.com> In-Reply-To: <002a01c84e82$d36efb40$350c6f0a@china.huawei.com> References: <20080104030507.7297e280@cs.columbia.edu> <002a01c84e82$d36efb40$350c6f0a@china.huawei.com> Organization: Columbia University X-Mailer: Claws Mail 3.2.0 (GTK+ 2.12.0; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.13 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, cfrg@ietf.org Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 04:33:27 -0000 On Fri, 04 Jan 2008 11:35:17 +0800 Sean Shuo Shen wrote: > Thank you Steven. > > >>Sean Shuo Shen wrote: > >> Hi Stephen, > >> Can you talk more details about the FIPS evaluation problem? > > >The issue is what the assurance boundary is. If the TCP sequence > >number is cryptographically significant, the entire process by which > >it's set (including original generation and anything else in the > >stack or kernel that could touch it) has to be part of the > >evaluation, too. > > The isn generation of some windows versions and linux is not random > enough and is vulnerable (like RST attack). So the seq num can not be > a source for randomness. But if a seq num is used just as an index > instead of a random seed, it is not cryptographically significant and > I don't think it will affect the cryptographic strength. What do you > think, Steven? > The questions to ask are (a) what are the consequences if there's a collision or repetition; (b) what are the consequences if the enemy can predict the value; (c) can the enemy cause such things, with some probability; and (d) if the answer to the previous questions indicates potential trouble, what are the assurances that trouble won't happen? For example -- in a straight RFC 793 TCP, the approximate value of an ISN is knowable; after all, that's how sequence number attacks are launched. If RFC 1948 sequence numbers are used, the ISN of a new instance of a connection 4-tuple is approximately knowable. The sequence numbers of subsequent packets in a connection are 100% knowable. The answer to (c) is yes, the attacker will generally know it. Is this a problem? I've lost track of what specific algorithm is being discussed here, so I won't try to answer in detail, but in general these are the kinds of questions that have to be answered. --Steve Bellovin, http://www.cs.columbia.edu/~smb From touch@ISI.EDU Fri Jan 4 00:45:55 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m045jtuu002286 for ; Fri, 4 Jan 2008 00:45:55 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m045jiEt025477 for ; Fri, 4 Jan 2008 00:45:44 -0500 (EST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 1819DC8E2E5 for ; Fri, 4 Jan 2008 00:45:23 -0500 (EST) Received: from [192.168.1.44] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m045iUT2024215; Thu, 3 Jan 2008 21:44:31 -0800 (PST) Message-ID: <477DC7BE.6010102@isi.edu> Date: Thu, 03 Jan 2008 21:44:30 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Sean Shuo Shen References: <002201c84e75$613c48a0$350c6f0a@china.huawei.com> In-Reply-To: <002201c84e75$613c48a0$350c6f0a@china.huawei.com> X-Enigmail-Version: 0.95.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7246B49D769CCB4EC7C53D6D" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 3.5 X-Spam-Level: *** (3.5) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, cfrg@ietf.org Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 05:45:55 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7246B49D769CCB4EC7C53D6D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sean Shuo Shen wrote: =2E.. >> For these reasons, and because of the potential to constrain the >> evolution of TCP, I would urge the MAC computation to treat the >> non-zeroed TCP header and pseudoheader fields as opaque. >=20 > I also believe some other bits in TCP header might be different even if= the > TCP is retransmitting the same segment. But all of these changes can ea= sily > be included in the PRF input when the nonce is calculated (it won't be = heavy > work compared with the calculation of MAC) to make sure different nonce= s are > used when the authenticated content changes.=20 Steve B. suggests not corrupting the FIPS boundary by using TCP header info. I am suggesting not limiting TCP design by making assumptions about the TCP header's uniqueness in each transmitted segment. We thus have two reasons not to do this; I hope that's sufficient reason to either have a shorter MAC coupled with an explicit nonce, a longer overall option field, or to seek algorithms that avoid the need for nonce= s. Joe --------------enig7246B49D769CCB4EC7C53D6D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHfce+E5f5cImnZrsRAuXcAJ9KcgZ6HHH/SlUeK5xlob73wsgGBACg1tIL dW878ez8LpGZpDld6SI38dw= =EWyE -----END PGP SIGNATURE----- --------------enig7246B49D769CCB4EC7C53D6D-- From sshen@huawei.com Fri Jan 4 02:23:02 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m047N2bO028832 for ; Fri, 4 Jan 2008 02:23:02 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m047MqPP014709 for ; Fri, 4 Jan 2008 02:22:53 -0500 (EST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [61.144.161.55]) by mit.edu (Spam Firewall) with ESMTP id 2E2B4BC8B27 for ; Fri, 4 Jan 2008 02:22:29 -0500 (EST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JU300L4WZ5C4I@szxga03-in.huawei.com> for saag@mit.edu; Fri, 04 Jan 2008 15:22:24 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JU3007LDZ5B9W@szxga03-in.huawei.com> for saag@mit.edu; Fri, 04 Jan 2008 15:22:24 +0800 (CST) Received: from s102542 ([10.111.12.53]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JU300I73Z58JU@szxml04-in.huawei.com> for saag@mit.edu; Fri, 04 Jan 2008 15:22:23 +0800 (CST) Date: Fri, 04 Jan 2008 15:22:20 +0800 From: Sean Shuo Shen In-reply-to: <477DC7BE.6010102@isi.edu> To: "'Joe Touch'" Message-id: <006201c84ea2$8b12e940$350c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AchOlYIbI0SMXXrETkieNxZeh4c/2QABfqWQ X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, cfrg@ietf.org Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 07:23:02 -0000 >>> For these reasons, and because of the potential to constrain the >>> evolution of TCP, I would urge the MAC computation to treat the >>> non-zeroed TCP header and pseudoheader fields as opaque. > >> I also believe some other bits in TCP header might be different even if the >> TCP is retransmitting the same segment. But all of these changes can easily >> be included in the PRF input when the nonce is calculated (it won't be heavy >> work compared with the calculation of MAC) to make sure different nonces are >> used when the authenticated content changes. >Steve B. suggests not corrupting the FIPS boundary by using TCP header >info. The FIPS boundary does matter only if the use of TCP header info is cryptographic significant. For example, using seq num as a random seed definitely is not a good idea. However, in a calculation like: nonce=PRF(key, seqnum and other header info) The seqnum et.al. are to provide difference of input to get different output. It works like a index and totally allowed to be predictable (it can even be a counter just like the nonce processing part of umac: PRF(key, counter)). When we are not using a seqnum as a random source we don't have to worry it's not random enough. >I am suggesting not limiting TCP design by making assumptions >about the TCP header's uniqueness in each transmitted segment. In a tcp transmission, as long as the MAC protected content are different, there will be enough difference in tcp header (seq num et.al., actually, the possible difference in option field or other bits are also good to contribute difference here). This difference will be good enough for both sides to generate different nonce for MAC calculation. It's not to make any assumption here. >We thus have two reasons not to do this; I hope that's sufficient reason >to either have a shorter MAC coupled with an explicit nonce, a longer >overall option field, or to seek algorithms that avoid the need for nonces. The two ways mentioned above both have the advantage of simple implementation. But implicit nonce generated by both sides is also achievable, and the benefit of it will be: less bytes in MAC transmission, more randomness (from PRF key, not from seqnum), more variety. Sean From touch@ISI.EDU Fri Jan 4 11:10:43 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m04GAhcm022175 for ; Fri, 4 Jan 2008 11:10:43 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m04GAYBe017215 for ; Fri, 4 Jan 2008 11:10:34 -0500 (EST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id C8186BDE88D for ; Fri, 4 Jan 2008 10:50:14 -0500 (EST) Received: from [192.168.1.44] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m04FnULQ022354; Fri, 4 Jan 2008 07:49:31 -0800 (PST) Message-ID: <477E558A.2080803@isi.edu> Date: Fri, 04 Jan 2008 07:49:30 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Sean Shuo Shen References: <006201c84ea2$8b12e940$350c6f0a@china.huawei.com> In-Reply-To: <006201c84ea2$8b12e940$350c6f0a@china.huawei.com> X-Enigmail-Version: 0.95.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB0590ED015165AAB8FCC0E4C" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, cfrg@ietf.org Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 16:10:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB0590ED015165AAB8FCC0E4C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sean Shuo Shen wrote: >>>> For these reasons, and because of the potential to constrain the >>>> evolution of TCP, I would urge the MAC computation to treat the >>>> non-zeroed TCP header and pseudoheader fields as opaque. >>> I also believe some other bits in TCP header might be different even = if > the >>> TCP is retransmitting the same segment. But all of these changes can > easily >>> be included in the PRF input when the nonce is calculated (it won't b= e > heavy >>> work compared with the calculation of MAC) to make sure different non= ces > are >>> used when the authenticated content changes.=20 >=20 >> Steve B. suggests not corrupting the FIPS boundary by using TCP header= >> info.=20 > The FIPS boundary does matter only if the use of TCP header info is > cryptographic significant. For example, using seq num as a random seed > definitely is not a good idea. However, in a calculation like: > nonce=3DPRF(key, seqnum and other header info) > The seqnum et.al. are to provide difference of input to get different > output. It works like a index and totally allowed to be predictable (it= can > even be a counter just like the nonce processing part of umac: PRF(key,= > counter)).=20 > When we are not using a seqnum as a random source we don't have to worr= y > it's not random enough. I don't know what FIPS boundary requirements consider, but I would expect it would include any required property of the fields. In this case, it would be the presumed uniqueness of the fields on a per-segment basis, which AFAICT cannot be assumed. >> I am suggesting not limiting TCP design by making assumptions >> about the TCP header's uniqueness in each transmitted segment. > In a tcp transmission, as long as the MAC protected content are differe= nt, > there will be enough difference in tcp header (seq num et.al., actually= , the > possible difference in option field or other bits are also good to > contribute difference here). This difference will be good enough for bo= th > sides to generate different nonce for MAC calculation. It's not to make= any > assumption here.=20 If there were no assumption, then I would agree, but the above indicates a clear assumption that we cannot clearly ensure. >> We thus have two reasons not to do this; I hope that's sufficient reas= on >> to either have a shorter MAC coupled with an explicit nonce, a longer >> overall option field, or to seek algorithms that avoid the need for no= nces. > The two ways mentioned above both have the advantage of simple > implementation. But implicit nonce generated by both sides is also > achievable, and the benefit of it will be: less bytes in MAC transmissi= on, > more randomness (from PRF key, not from seqnum), more variety. Again, I feel that a good MAC doesn't depend on a nonce for variety. Joe --------------enigB0590ED015165AAB8FCC0E4C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHflWKE5f5cImnZrsRAg9qAKDQTWEf7gpXDLwSDlHYPmz8KsuZ9ACbBRgs XEqq4cITmdvg3ECF0hCxqSc= =fgKq -----END PGP SIGNATURE----- --------------enigB0590ED015165AAB8FCC0E4C-- From kent@bbn.com Fri Jan 4 11:25:21 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m04GPKJZ028973 for ; Fri, 4 Jan 2008 11:25:20 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m04GP9OM011697 for ; Fri, 4 Jan 2008 11:25:10 -0500 (EST) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by mit.edu (Spam Firewall) with ESMTP id 1C556CB99BF for ; Fri, 4 Jan 2008 11:24:48 -0500 (EST) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JApLj-0007Dv-49; Fri, 04 Jan 2008 11:24:47 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <002301c84e75$a9354580$350c6f0a@china.huawei.com> References: <002301c84e75$a9354580$350c6f0a@china.huawei.com> Date: Fri, 4 Jan 2008 09:38:27 -0500 To: Sean Shuo Shen From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, cfrg@ietf.org Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 16:25:21 -0000 At 10:01 AM +0800 1/4/08, Sean Shuo Shen wrote: >Hi Stephen, >Can you talk more details about the FIPS evaluation problem? > >Sean > Sure. FIPS 140-x evaluation of crypto modules generally will NOT encompass implementation of mechanisms used for anti-replay, e.g., the sequence numbers used in IPsec or in TCP. This is because these mechanisms are not part of a crypto algorithm definition. However, if these same values are used as inputs to crypto algorithms, e.g., a MAC algorithm or a confidentiality algorithm such as counter mode encryption, THEN they become part of the evaluated code/hardware base. So, if one were to use TCP sequence numbers in a MAC algorithm, and the algorithm required the numbers to be unique, then all aspects of TCP sequence number management would become part of the evaluated code base. In general, one tries to minimize the size of the evaluated code and hardware, to increase likelihood that the evaluation will succeed, to reduce the need for re-evaluation when any of the evaluated code/hardware changes, etc. This observation caused IPsec to decide to NOT reuse its anti-replay sequence numbers for counter-mode encryption. Rather IPsec requires carriage of the counter-mode, per-packet value in each packet header. Steve From bew@cisco.com Fri Jan 4 18:07:20 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m04N7J9c014288 for ; Fri, 4 Jan 2008 18:07:19 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m04N77lx010840 for ; Fri, 4 Jan 2008 18:07:07 -0500 (EST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mit.edu (Spam Firewall) with ESMTP id 14F28EFD2E8 for ; Fri, 4 Jan 2008 18:06:42 -0500 (EST) X-IronPort-AV: E=Sophos;i="4.24,247,1196668800"; d="scan'208";a="17433947" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 04 Jan 2008 15:06:42 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m04N6gh2015544; Fri, 4 Jan 2008 15:06:42 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m04N6MHU023223; Fri, 4 Jan 2008 23:06:42 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jan 2008 15:06:31 -0800 Received: from [10.32.244.212] ([10.32.244.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jan 2008 15:06:30 -0800 In-Reply-To: <20080101020627.CBFAE5081A@romeo.rtfm.com> References: <98FA6BE8-0825-41F6-8DAA-1A5706D974A9@cisco.com> <20080101020627.CBFAE5081A@romeo.rtfm.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Brian Weis Date: Fri, 4 Jan 2008 15:06:59 -0800 To: Eric Rescorla X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 04 Jan 2008 23:06:30.0892 (UTC) FILETIME=[7156BAC0:01C84F26] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2107; t=1199488002; x=1200352002; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bew@cisco.com; z=From:=20Brian=20Weis=20 |Subject:=20Re=3A=20[saag]=20TCP-AO=20MAC=20algorithms |Sender:=20; bh=eIh55aD1lAcSZrvJ3wr1M8md39lW4FrqUKJ0YF3i3p8=; b=GonSxE9w99mUWUZo5BDVjcVdSRh/l/+23KtrZDMYpiza7iByGqmzhvu7vA 6W3vU7vFky8Qzi1moLT8+UEMSVDHUaHga86SnqeHcOX6N3pwa3piVZloApLF 1CUKiGWJvjIL2SbCVcoRfJrWeGXgL8HH407E7nu/dThStIDOmojD0=; Authentication-Results: sj-dkim-1; header.From=bew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 23:07:20 -0000 On Dec 31, 2007, at 6:06 PM, Eric Rescorla wrote: > At Tue, 18 Dec 2007 16:23:51 -0800, > Brian Weis wrote: >> >> Greetings, >> >> The TCPM WG seeks advice from SAAG on which MACs to include as >> required MACs for the TCP Authentication Option (draft-ietf-tcpm-tcp- >> auth-opt-00). > > I would note that TLS has one MTI MAC (HMAC-SHA1) and based on RFC > 4835, so does ESP/AH (HMAC-SHA1-96). What's the rationale for why > TCP-AO should have stricter MTI requirements than we have for > our dedicated security protocols? The rationale is simply that two methods with differing internal constructions implies that the standard is better prepared for the future (if one of the two MACs is perceived to be broken). As far as I can recall, there was no other reason. If the consensus in SAAG is that one algorithm is sufficient, then that advice will be taken into consideration. >> Two MACs with differing internal constructions are >> desired. > > I don't understand this either. Most modern MACs are constructed from > two pieces: > > - An underlying cryptographic function > - A composition operation > > Thus, for instance, HMAC-SHA1 is constructed by using the HMAC > composition operation with SHA-1. In general, the security properties > of the composition operations are well understood (often with some > kind of reduction proof) where the security properties of the > underlying function are unproven. So, while it might make sense > to have two different base cryptographic functions (e.g., > SHA-1 and SHA-256), it's not at all clear that it's of that > much value to have two different constructions. Agreed that if two RTI MACs are chosen that the MACs must be significantly different. That's why the proposed set includes one of SHA-1 using HMAC (a Wegman-Carter MAC), and another of AES using CMAC (a cipher block chaining mode intended for authentication). Brian > -Ekr > > -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From ekr@networkresonance.com Fri Jan 4 19:44:55 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m050itfb002667 for ; Fri, 4 Jan 2008 19:44:55 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m050ilP8016514 for ; Fri, 4 Jan 2008 19:44:47 -0500 (EST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by mit.edu (Spam Firewall) with ESMTP id E54A9D1911B for ; Fri, 4 Jan 2008 19:44:26 -0500 (EST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 9577F5081A; Fri, 4 Jan 2008 16:44:55 -0800 (PST) Date: Fri, 04 Jan 2008 16:44:55 -0800 From: Eric Rescorla To: Brian Weis In-Reply-To: References: <98FA6BE8-0825-41F6-8DAA-1A5706D974A9@cisco.com> <20080101020627.CBFAE5081A@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080105004455.9577F5081A@romeo.rtfm.com> X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 00:44:55 -0000 At Fri, 4 Jan 2008 15:06:59 -0800, Brian Weis wrote: > > > On Dec 31, 2007, at 6:06 PM, Eric Rescorla wrote: > > > At Tue, 18 Dec 2007 16:23:51 -0800, > > Brian Weis wrote: > >> > >> Greetings, > >> > >> The TCPM WG seeks advice from SAAG on which MACs to include as > >> required MACs for the TCP Authentication Option (draft-ietf-tcpm-tcp- > >> auth-opt-00). > > > > I would note that TLS has one MTI MAC (HMAC-SHA1) and based on RFC > > 4835, so does ESP/AH (HMAC-SHA1-96). What's the rationale for why > > TCP-AO should have stricter MTI requirements than we have for > > our dedicated security protocols? > > The rationale is simply that two methods with differing internal > constructions implies that the standard is better prepared for the > future (if one of the two MACs is perceived to be broken). Yes, this strikes me as massive overkill, given that typical MAC constructions are designed with some kind of reduction to the primitive they are based on. If, for instance, SHA-256 is broken badly enough that it implicates HMAC, it seems likely that we're going to have so many other cryptographic problems that the remaining security of TCP-AO will be the least of our worries. > >> Two MACs with differing internal constructions are > >> desired. > > > > I don't understand this either. Most modern MACs are constructed from > > two pieces: > > > > - An underlying cryptographic function > > - A composition operation > > > > Thus, for instance, HMAC-SHA1 is constructed by using the HMAC > > composition operation with SHA-1. In general, the security properties > > of the composition operations are well understood (often with some > > kind of reduction proof) where the security properties of the > > underlying function are unproven. So, while it might make sense > > to have two different base cryptographic functions (e.g., > > SHA-1 and SHA-256), it's not at all clear that it's of that > > much value to have two different constructions. > > Agreed that if two RTI MACs are chosen that the MACs must be > significantly different. That's why the proposed set includes one of > SHA-1 using HMAC (a Wegman-Carter MAC), and another of AES using CMAC > (a cipher block chaining mode intended for authentication). I'm not sure why you say "agreed". As I said, I don't agree with this. On the contrary, I don't see much value in using different constructions. There's no reason to believe there's anything wrong with HMAC, the issue (to the extent to which there is any) is purely with the digests used by HMAC. If, for some reason, there is a perceived need to specify two functions HMAC with two different (potentially unrelated) digests seems fine. -Ekr From sshen@huawei.com Sat Jan 5 01:45:50 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m056joNG018332 for ; Sat, 5 Jan 2008 01:45:50 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m056jePU025769 for ; Sat, 5 Jan 2008 01:45:40 -0500 (EST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [61.144.161.53]) by mit.edu (Spam Firewall) with ESMTP id 0D6EECB4C57 for ; Sat, 5 Jan 2008 01:45:17 -0500 (EST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JU500CM8S3DD3@szxga01-in.huawei.com> for saag@mit.edu; Sat, 05 Jan 2008 14:45:13 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JU50031IS3CS3@szxga01-in.huawei.com> for saag@mit.edu; Sat, 05 Jan 2008 14:45:13 +0800 (CST) Received: from s102542 ([10.111.12.53]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JU500GQWS38H1@szxml04-in.huawei.com> for saag@mit.edu; Sat, 05 Jan 2008 14:45:12 +0800 (CST) Date: Sat, 05 Jan 2008 14:45:08 +0800 From: Sean Shuo Shen In-reply-to: <477E558A.2080803@isi.edu> To: "'Joe Touch'" Message-id: <006401c84f66$83665780$350c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AchO6X4Z0hY38T9STKCOP+za8TZ1ZgAVzJWA X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, cfrg@ietf.org Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 06:45:50 -0000 >> The FIPS boundary does matter only if the use of TCP header info is >> cryptographic significant. For example, using seq num as a random seed >> definitely is not a good idea. However, in a calculation like: >> nonce=PRF(key, seqnum and other header info) >> The seqnum et.al. are to provide difference of input to get different >> output. It works like a index and totally allowed to be predictable (it can >> even be a counter just like the nonce processing part of umac: PRF(key, >> counter)). >> When we are not using a seqnum as a random source we don't have to worry >> it's not random enough. >I don't know what FIPS boundary requirements consider, but I would >expect it would include any required property of the fields. In this >case, it would be the presumed uniqueness of the fields on a per-segment >basis, which AFAICT cannot be assumed. >> In a tcp transmission, as long as the MAC protected content are different, >> there will be enough difference in tcp header (seq num et.al., actually, the >> possible difference in option field or other bits are also good to >> contribute difference here). This difference will be good enough for both >> sides to generate different nonce for MAC calculation. It's not to make any >> assumption here. >If there were no assumption, then I would agree, but the above indicates >a clear assumption that we cannot clearly ensure. Ok we discussed: nonce=PRF(key, index) . index =segment length + tcp header without dport&sport. The index can include all the tcp header including options, but the fields (like port numbers) that won't change within a connection can be omitted, fields that are set to be zero in mac culculations can also be omitted. The problem is: In a tcp connection, before a seqnum rollover (when rollver happens, both hash key and PRF key need to be renewed), index must be different when the authenticated content described in tcpm-tcp-auth-opt-00 is different. Hence the calculation nonce=PRF(key, index) will give different values. Proof: When the authenticated content changes, there are just two cases: seqnum changes or not. If seqnum changes the index changes. If seqnum does not change, segment length either changes or not: If segment length changes, index changes; If segment length does not change, changes can only come from TCP header including option, in this case, the index also changes. Thus in all cases, the index must change when authenticated content changes, hence different nonce value are produces. Done. If a statement is proved, it is not an assumption. Of course a proof needs other assumptions, just like we can not play Euclidean Geometry without assuming Parallel Postulate, we can not play Real Analysis without assuming Axiom of Choice. Here we should agree that a PRF produces different values given different input, this is not an assumption which we should deeply argue before using it. Just like, although we know a hash function is not injective, we still believe it produces different tags for different messages because of the small probability of collision, without believing this the MAC protection for tcp makes no sense. >>> We thus have two reasons not to do this; I hope that's sufficient reason >>> to either have a shorter MAC coupled with an explicit nonce, a longer >>> overall option field, or to seek algorithms that avoid the need for nonces. >> The two ways mentioned above both have the advantage of simple >> implementation. But implicit nonce generated by both sides is also >> achievable, and the benefit of it will be: less bytes in MAC transmission, >> more randomness (from PRF key, not from seqnum), more variety. >Again, I feel that a good MAC doesn't depend on a nonce for variety. Nonce is one way, of course not the only way, to contribute variety. Sean From sshen@huawei.com Sat Jan 5 01:46:41 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m056kfjO018474 for ; Sat, 5 Jan 2008 01:46:41 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m056kWAF026494 for ; Sat, 5 Jan 2008 01:46:32 -0500 (EST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [61.144.161.7]) by mit.edu (Spam Firewall) with ESMTP id 0273FC97F47 for ; Sat, 5 Jan 2008 01:46:10 -0500 (EST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JU5006LDS4WEI@szxga04-in.huawei.com> for saag@mit.edu; Sat, 05 Jan 2008 14:46:08 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JU5001XUS4WIZ@szxga04-in.huawei.com> for saag@mit.edu; Sat, 05 Jan 2008 14:46:08 +0800 (CST) Received: from s102542 ([10.111.12.53]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JU500GE0S4QDS@szxml04-in.huawei.com> for saag@mit.edu; Sat, 05 Jan 2008 14:46:08 +0800 (CST) Date: Sat, 05 Jan 2008 14:46:02 +0800 From: Sean Shuo Shen In-reply-to: To: "'Stephen Kent'" Message-id: <006501c84f66$a35f4f10$350c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AchO7sJbABb0XSbeTJmJfzPczjHuPQATz47Q X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, cfrg@ietf.org Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 06:46:41 -0000 Thank you, Stephen, >Sure. >FIPS 140-x evaluation of crypto modules generally will NOT encompass >implementation of mechanisms used for anti-replay, e.g., the sequence >numbers used in IPsec or in TCP. This is because these mechanisms are >not part of a crypto algorithm definition. However, if these same >values are used as inputs to crypto algorithms, e.g., a MAC algorithm >or a confidentiality algorithm such as counter mode encryption, THEN >they become part of the evaluated code/hardware base. So, if one were >to use TCP sequence numbers in a MAC algorithm, and the algorithm >required the numbers to be unique, then all aspects of TCP sequence >number management would become part of the evaluated code base. In >general, one tries to minimize the size of the evaluated code and >hardware, to increase likelihood that the evaluation will succeed, to >reduce the need for re-evaluation when any of the evaluated >code/hardware changes, etc. >This observation caused IPsec to decide to NOT reuse its anti-replay >sequence numbers for counter-mode encryption. Rather IPsec requires >carriage of the counter-mode, per-packet value in each packet header. Here I agree that carrying the nonce (or an index/counter for nonce) with the MAC is a good way for a nonce MAC algorithm to get express pass from fips. Sean From touch@ISI.EDU Sat Jan 5 11:49:47 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m05GnlDS019831 for ; Sat, 5 Jan 2008 11:49:47 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m05GnbOA013494 for ; Sat, 5 Jan 2008 11:49:37 -0500 (EST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 90A3FCAD13D for ; Sat, 5 Jan 2008 11:49:16 -0500 (EST) Received: from [192.168.1.44] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m05Gmdqg010561; Sat, 5 Jan 2008 08:48:40 -0800 (PST) Message-ID: <477FB4E6.4030507@isi.edu> Date: Sat, 05 Jan 2008 08:48:38 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Sean Shuo Shen References: <006401c84f66$83665780$350c6f0a@china.huawei.com> In-Reply-To: <006401c84f66$83665780$350c6f0a@china.huawei.com> X-Enigmail-Version: 0.95.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCDC0E181C501E94CFFC293C0" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, cfrg@ietf.org Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 16:49:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCDC0E181C501E94CFFC293C0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable =2E.. >> If there were no assumption, then I would agree, but the above indicat= es >> a clear assumption that we cannot clearly ensure. > Ok we discussed: > nonce=3DPRF(key, index) .=20 > index =3Dsegment length + tcp header without dport&sport. The index can= > include all the tcp header including options, but the fields (like port= > numbers) that won't change within a connection can be omitted, fields t= hat > are set to be zero in mac culculations can also be omitted. > The problem is: > In a tcp connection, before a seqnum rollover (when rollver happens, bo= th > hash key and PRF key need to be renewed), index must be different when = the > authenticated content described in tcpm-tcp-auth-opt-00 is different. H= ence > the calculation nonce=3DPRF(key, index) will give different values. > Proof:=20 > When the authenticated content changes, there are just two cases: seqnu= m > changes or not.=20 > If seqnum changes the index changes. > If seqnum does not change, segment length either changes or not: > If segment length changes, index changes; > If segment length does not change, changes can only come from TCP > header > including option, in this case, the index also changes. Please indicate the proof for this. First, it requires that the rest of the system enforce the "no reuse of keys during seqno rollover"; second, it requires that TCP implementations not allow the socket data to change between initial transmission and retransmission. Although I wouldn't think such data changes would be useful, I wouldn't want to require FIPS validation of that property, since it creeps down into the socket layer. Joe --------------enigCDC0E181C501E94CFFC293C0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHf7TmE5f5cImnZrsRAplgAJ9kPmTSfRYHF3O+3XeCZUJet6HEDACfVG51 uMHRz/QQse0GoeA8zX9I9+k= =8fj5 -----END PGP SIGNATURE----- --------------enigCDC0E181C501E94CFFC293C0-- From sshen@huawei.com Mon Jan 7 07:44:09 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m07Ci91O015407 for ; Mon, 7 Jan 2008 07:44:09 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m07ChxpT003314 for ; Mon, 7 Jan 2008 07:43:59 -0500 (EST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [61.144.161.53]) by mit.edu (Spam Firewall) with ESMTP id 80B10D1AF60 for ; Mon, 7 Jan 2008 07:43:36 -0500 (EST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JU900A8QY0KBU@szxga01-in.huawei.com> for saag@mit.edu; Mon, 07 Jan 2008 20:43:32 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JU9007PTY0JG1@szxga01-in.huawei.com> for saag@mit.edu; Mon, 07 Jan 2008 20:43:31 +0800 (CST) Received: from s102542 ([10.111.12.53]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JU900CRIY0F0H@szxml04-in.huawei.com> for saag@mit.edu; Mon, 07 Jan 2008 20:43:31 +0800 (CST) Date: Mon, 07 Jan 2008 20:43:27 +0800 From: Sean Shuo Shen In-reply-to: <477FB4E6.4030507@isi.edu> To: "'Joe Touch'" Message-id: <000601c8512a$e6785060$350c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AchPuuoXYxsXIcERShWEt2RG5G0EgABZi98g X-Spam-Score: 3.5 X-Spam-Level: *** (3.5) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, cfrg@ietf.org Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 12:44:09 -0000 Hi Joe, >Please indicate the proof for this. First, it requires that the rest of >the system enforce the "no reuse of keys during seqno rollover"; second, >it requires that TCP implementations not allow the socket data to change >between initial transmission and retransmission. First, I remember somewhere it is said that the MAC key should be renewed when sequence number rollover, in your first email you also mentioned that "This is why we probably need to explicitly require that the connection key change whenever the sequence number rolls over (through the ISN)." I believe you are giving a reasonable and achievable requirement (hash key renewing during rollover). If hash key renewing during rollover is doable, nonce key renewing during rollover is also doable and it's not an extra requirement. The way to renew keys is out of the scope of our discussion. I don't think we have to give a key management scheme before talking about MAC algorithms. Second, maybe there is a misunderstanding here. What I mean is: the nonce generation algorithm can guarantee that nonce is different when the MAC protected data are different (because some mac algorithms require different nonce when hashing different messages). If the MAC protected data (I assume this is what you mean by "socket data") are same between transmission and retransmission, it is totally fine for nonce to be same. So I did not require that TCP implementations not allow the socket data to change between initial transmission and retransmission. Regards Sean From touch@ISI.EDU Mon Jan 7 09:57:11 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m07EvBIB010853 for ; Mon, 7 Jan 2008 09:57:11 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m07Ev0mg001900 for ; Mon, 7 Jan 2008 09:57:01 -0500 (EST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id EAAF4EF4114 for ; Mon, 7 Jan 2008 09:56:39 -0500 (EST) Received: from [192.168.1.44] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m07EssZx028692; Mon, 7 Jan 2008 06:54:55 -0800 (PST) Message-ID: <47823D3D.1010001@isi.edu> Date: Mon, 07 Jan 2008 06:54:53 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Sean Shuo Shen References: <000601c8512a$e6785060$350c6f0a@china.huawei.com> In-Reply-To: <000601c8512a$e6785060$350c6f0a@china.huawei.com> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig924FCE58138A1F9DDF9BD219" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, cfrg@ietf.org Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 14:57:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig924FCE58138A1F9DDF9BD219 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Sean Shuo Shen wrote: > Hi Joe, >=20 >> Please indicate the proof for this. First, it requires that the rest o= f >> the system enforce the "no reuse of keys during seqno rollover"; secon= d, >> it requires that TCP implementations not allow the socket data to chan= ge >> between initial transmission and retransmission. > > First, I remember somewhere it is said that the MAC key should be renew= ed > when sequence number rollover, in your first email you also mentioned t= hat > "This is why we probably need to explicitly require that the connection= key > change whenever the sequence number rolls over (through the ISN)." I be= lieve > you are giving a reasonable and achievable requirement (hash key renewi= ng > during rollover). If hash key renewing during rollover is doable, nonce= key > renewing during rollover is also doable and it's not an extra requireme= nt. > The way to renew keys is out of the scope of our discussion. I don't th= ink > we have to give a key management scheme before talking about MAC algori= thms. It all depends on whether key reuse during rollover is prohibited=20 outright or just recommended against. If the former, I agree it's=20 sufficient to roll over the nonce key at the same time. It's the latter=20 case that's the issue, and whether to make this something FIPS=20 certification relies upon. > Second, maybe there is a misunderstanding here. What I mean is: the non= ce > generation algorithm can guarantee that nonce is different when the MAC= > protected data are different (because some mac algorithms require diffe= rent > nonce when hashing different messages). If the MAC protected data (I as= sume > this is what you mean by "socket data") are same between transmission a= nd > retransmission, it is totally fine for nonce to be same. That depends on whether the nonce is used to provide replay protection.=20 If it is, then it can't be the same if the entire segment is the same. Joe --------------enig924FCE58138A1F9DDF9BD219 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHgj09E5f5cImnZrsRAm5SAJ9xoEAowE/aECicX6hgxhSVRxNoSACfaqpw bVz30vatOYOvmH5a18VKvKY= =iarB -----END PGP SIGNATURE----- --------------enig924FCE58138A1F9DDF9BD219-- From sshen@huawei.com Mon Jan 7 19:44:56 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m080iu4c007877 for ; Mon, 7 Jan 2008 19:44:56 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m080ikMB011013 for ; Mon, 7 Jan 2008 19:44:47 -0500 (EST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [61.144.161.7]) by mit.edu (Spam Firewall) with ESMTP id 1F411F00FC3 for ; Mon, 7 Jan 2008 19:44:24 -0500 (EST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JUA00G39VDU15@szxga04-in.huawei.com> for saag@mit.edu; Tue, 08 Jan 2008 08:44:18 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JUA004LSVDUSY@szxga04-in.huawei.com> for saag@mit.edu; Tue, 08 Jan 2008 08:44:18 +0800 (CST) Received: from s102542 ([10.111.12.53]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JUA008K9VDQDA@szxml04-in.huawei.com> for saag@mit.edu; Tue, 08 Jan 2008 08:44:18 +0800 (CST) Date: Tue, 08 Jan 2008 08:44:14 +0800 From: Sean Shuo Shen In-reply-to: <47823D3D.1010001@isi.edu> To: "'Joe Touch'" Message-id: <001f01c8518f$97c6cae0$350c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AchRPYU4UeOgjgnWSEaVda7pz8s/5QAUBaAg X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, cfrg@ietf.org Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2008 00:44:56 -0000 >> First, I remember somewhere it is said that the MAC key should be renewed >> when sequence number rollover, in your first email you also mentioned that >> "This is why we probably need to explicitly require that the connection key >> change whenever the sequence number rolls over (through the ISN)." I believe >> you are giving a reasonable and achievable requirement (hash key renewing >> during rollover). If hash key renewing during rollover is doable, nonce key >> renewing during rollover is also doable and it's not an extra requirement. >> The way to renew keys is out of the scope of our discussion. I don't think >> we have to give a key management scheme before talking about MAC algorithms. >It all depends on whether key reuse during rollover is prohibited >outright or just recommended against. If the former, I agree it's >sufficient to roll over the nonce key at the same time. It's the latter >case that's the issue, and whether to make this something FIPS >certification relies upon. Key reuse during rollover is prohibited. >> Second, maybe there is a misunderstanding here. What I mean is: the nonce >> generation algorithm can guarantee that nonce is different when the MAC >> protected data are different (because some mac algorithms require different >> nonce when hashing different messages). If the MAC protected data (I assume >> this is what you mean by "socket data") are same between transmission and >> retransmission, it is totally fine for nonce to be same. >That depends on whether the nonce is used to provide replay protection. >If it is, then it can't be the same if the entire segment is the same. The nonce here is not used against replay attack. Sean From hartmans@MIT.EDU Tue Jan 8 14:59:40 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m08Jxdm3009836 for ; Tue, 8 Jan 2008 14:59:39 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m08JxRmv012731 for ; Tue, 8 Jan 2008 14:59:28 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (dhcp-18-188-10-61.dyn.MIT.EDU [18.188.10.61]) by mit.edu (Spam Firewall) with ESMTP id 77822C1180B for ; Tue, 8 Jan 2008 14:59:01 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3A19F4817; Tue, 8 Jan 2008 14:59:00 -0500 (EST) From: Sam Hartman To: saag@MIT.EDU Date: Tue, 08 Jan 2008 14:59:00 -0500 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Score: 0.40 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] [Russ Housley] Fwd: New Liaison Statement, "Liaison statement from JCA-IdM Co-conveners to IETF Security Area on initial meeting of JCA-IdM and IdM-GSI" X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2008 19:59:40 -0000 Return-Path: Received: from localhost ([unix socket]) by mail.suchdamage.org (Cyrus v2.2.13-Debian-2.2.13-10) with LMTPA; Mon, 07 Jan 2008 15:32:58 -0500 X-Sieve: CMU Sieve 2.2 Received: from south-station-annex.mit.edu (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by mail.suchdamage.org (Postfix) with ESMTP id 0EE9C4622 for ; Mon, 7 Jan 2008 15:32:49 -0500 (EST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by south-station-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m07KWlhp001308 for ; Mon, 7 Jan 2008 15:32:48 -0500 (EST) Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m07KWbDl006107 for ; Mon, 7 Jan 2008 15:32:37 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by mit.edu (Spam Firewall) with SMTP id 38A35D21FC8 for ; Mon, 7 Jan 2008 15:27:20 -0500 (EST) Received: (qmail 20543 invoked by uid 0); 7 Jan 2008 20:27:12 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.129.167) by woodstock.binhost.com with SMTP; 7 Jan 2008 20:27:12 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 07 Jan 2008 15:21:58 -0500 To: hartmans-ietf@mit.edu, tim.polk@nist.gov From: Russ Housley Subject: Fwd: New Liaison Statement, "Liaison statement from JCA-IdM Co-conveners to IETF Security Area on initial meeting of JCA-IdM and IdM-GSI" Message-Id: <20080107202720.38A35D21FC8@mit.edu> X-Spam-Score: 1.11 X-Spam-Level: * (1.11) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Mon Jan 7 15:32:58 2008 X-DSPAM-Confidence: 0.9994 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 47828c7a17398165217127 X-DSPAM-Factors: 27, From*Russ Housley , 0.00010, //datatracker, 0.00016, //datatracker, 0.00016, //datatracker+ietf, 0.00016, //datatracker+ietf, 0.00016, From*Housley, 0.00036, From*Housley+, 0.00036, From*Russ+Housley, 0.00036, From*vigilsec.com>, 0.00036, to+IETF, 0.00037, to+IETF, 0.00037, Received*(HELO+THINKPADR52.vigilsec.com), 0.00039, Received*from+woodstock.binhost.com, 0.00039, Received*by+woodstock.binhost.com, 0.00039, Received*THINKPADR52.vigilsec.com), 0.00039, Received*woodstock.binhost.com+with, 0.00039, >+>The, 0.00039, >+>The, 0.00039, Received*woodstock.binhost.com, 0.00039, Received*woodstock.binhost.com, 0.00039, 0500+>, 0.00044, Received*(woodstock.binhost.com, 0.00058, Received*woodstock.binhost.com+(woodstock.binhost.com, 0.00058, Standards+>, 0.00061, >Cc, 0.00122 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit For your action.... >To: Scott Bradne >Cc: rcbrack@VERIZON.NET, olivier.dubuisson@orange-ftgroup.com, > chae-sub.lee@ties.itu.int, tsbidm@itu.int, rcbrack@VERIZON.NET, > olivier.dubuisson@orange-ftgroup.com, chae-sub.lee@ties.itu.int >From: Xiaoya Yang (ITU-T SG 17) >Subject: New Liaison Statement, "Liaison statement from JCA-IdM > Co-conveners to IETF Security Area on initial meeting of JCA-IdM > and IdM-GSI" >Reply-To: tsbidm@itu.int >Date: Mon, 07 Jan 2008 11:07:24 -0500 > > >Title: Liaison statement from JCA-IdM Co-conveners to IETF Security >Area on initial meeting of JCA-IdM and IdM-GSI >Submission Date: 2008-01-07 >URL of the IETF Web page: >https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=402 >Please reply by 2008-01-15 > >From: Xiaoya Yang(ITU-T SG 17) >To: IETF Security Area(Scott Bradne ) >Cc: rcbrack@VERIZON.NET >olivier.dubuisson@orange-ftgroup.com >chae-sub.lee@ties.itu.int >Reponse Contact: tsbidm@itu.int >Technical Contact: rcbrack@VERIZON.NET >olivier.dubuisson@orange-ftgroup.com >chae-sub.lee@ties.itu.int >Purpose: For action >Body: The Telecommunication Standards Advisory Group (TSAG) which >manages the overall work of the ITU-T, at its December 2007 meeting, >approved the creation of the Joint Coordination Activity on Identity >Management (JCA-IdM) together with a Global Standards Initiative for >Identity Management (IdM-GSI). The purpose of the JCA-IdM is to >coordinate the ITU-T Identity Management (IdM) work among ITU-T >Study Groups. Other SDOs, consortia and forums are invited to >nominate one or two representatives. The JCA-IdM will provide a >report on its work to the TSAG which next meets in July 2008. The >IdM-GSI is a grouping of ITU-T Study Group Rapporteur meetings >working on IdM for telecommunications. > >The membership of the JCA-IdM is composed of representatives from >the ITU Study Groups and invited representatives from recognized IdM >external SDOs, consortia and forums. It would be helpful if the ITU >Study Groups and forums external to the ITU could provide the >co-Conveners the name, organization, telephone number and email >address for one or two individuals that can serve as a >representative to the JCA-IdM. > >The first IdM-GSI event will occur on 18 and 21 January 2008 in >Seoul, Korea, and will involve Q.6/17 and Q.15/13. Representatives >from interested external SDOs, consortia and forums are invited to >contact the Rapporteurs (Abbie Barbir, abbieb@nortel.com; Igor >Faynberg, faynberg@alcatel-lucent.com) if they want to participate. >The first JCA-IdM meeting will occur on 22 January 2008 at the same >venue. For those who will not be able to attend in person, the >following telecommunication bridge will be available from 9 am to 6 >pm, Seoul time (GMT +8): > Telephone Number: +33 1 58 99 29 15 >Please inform the co-Conveners of intended remote participation. >More details of these IdM related events in Seoul are found in TSB >Circular 174, revision 1 >(http://www.itu.int/md/meetingdoc.asp?lang=en&parent=T05-TSB-CIR-0174) >and available on the JCA-IdM website at >http://www.itu.int/ITU-T/jca/idm/index.html. >Other IdM GSI events are planned during the 7 ­ 18 April 2008 SG 17 >joint meeting with ISO/IEC JTC 1/SC 6, and during the 14 ­ 23 May >NGN-GSI event. Both events will be held in Geneva. Detailed meeting >information (including final dates) will be available on the IdM-GSI >website at http://www.itu.int/ITU-T/idm/index.html. > > >Contributions to the first JCA-IdM meeting >For the first JCA-IdM meeting on 22 January, we request >contributions/briefings that describe: >• The IdM work that is occurring in your study >group/organization, to include objectives, scope, milestones and >other information that you believe would be useful to the JCA-IdM; >• Your views on new IdM work items that could be undertaken by >the ITU-T; >• What material in the reports of the Focus Group on IdM (see >Annex 3) are relevant to your activities and should be pursued by >your organization; and >• What is your definition and scope of IdM. >Please send contributions to the TSB secretariat by electronic mail >to tsbidm@itu.int by Sunday midnight, Geneva time, 15 January 2008. >Attachment(s): > Initial Meetings of the Joint Coordination Activity for > Identity Management (JCA IdM) and of the Global Standards > Initiative for Identity Management (IdM-GSI) > (https://datatracker.ietf.org/documents/LIAISON/file506.doc) From pbaker@verisign.com Thu Feb 14 16:12:47 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1ELClhI004054 for ; Thu, 14 Feb 2008 16:12:47 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1ELCduV000685 for ; Thu, 14 Feb 2008 16:12:39 -0500 (EST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id B5F9A661053 for ; Thu, 14 Feb 2008 16:12:11 -0500 (EST) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id m1EL3T25015669; Thu, 14 Feb 2008 13:03:29 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Feb 2008 13:11:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C86F4E.30468BBD" Date: Thu, 14 Feb 2008 13:11:38 -0800 Message-ID: <2788466ED3E31C418E9ACC5C31661557085054@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Managing aglorithms RE: [saag] TCP-AO MAC algorithms Thread-Index: AchPNZnvg3oZINqbR9OlgXOnfhQIpQgFjeCh References: <98FA6BE8-0825-41F6-8DAA-1A5706D974A9@cisco.com><20080101020627.CBFAE5081A@romeo.rtfm.com> <20080105004455.9577F5081A@romeo.rtfm.com> From: "Hallam-Baker, Phillip" To: "Eric Rescorla" , "Brian Weis" X-OriginalArrivalTime: 14 Feb 2008 21:11:39.0106 (UTC) FILETIME=[30736420:01C86F4E] X-Spam-Score: 0.14 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: [saag] Managing aglorithms RE: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2008 21:12:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C86F4E.30468BBD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To tie a number of threads together here I think it would help = enormously if we had some sort of cross IETF statement of the set of = algorithms that are currently the consensus recommendations for support. =20 I don't think that there is a lot of disagreement on the important = points, e.g. : =20 * If you are designing an entirely new protocol that requires block = encryption specify AES-128 and AES-256 as MUST =20 * The use of 3DES, HMAC-SHA1, should be avoided in entirely new = protocols but is not cause for concern in deployed protocols. =20 * Use of SHA1 should be avoided except in deployed protocols where there = has been careful analysis that demonstrates use in that application is = not cause for concern. =20 * Use of MD5, ciphers with a strength of 56 bits or less should be = avoided in almost all circumstances. Use of ciphers with key sizes of 64 = bits or less should be discontinued as soon as is practicable. =20 * If someone wants to specify vanity crypto, give them the necessary URI = or OID and tell them to use it at their own discretion. =20 =20 I don't think we should have this discussion in every individual working = group.=20 =20 I especially don't want to have to have the discussion on how to use ECC = with each individual IETF spec in turn. Or worse have extended = discussions over the optimal choice of group etc. so that we end up with = different choices across the IETF. If the specifications are well = designed we should have all the information necessary to specify how to = use algorithms across the board. =20 As things stand I think we are going to end up with more crypto = configurations in IETF protocols than we have crypto people. And that = would be a bad thing when there is a pretty strong consensus on = preferred algorithms in the field. ________________________________ From: saag-bounces@mit.edu on behalf of Eric Rescorla Sent: Fri 04/01/2008 7:44 PM To: Brian Weis Cc: saag@mit.edu Subject: Re: [saag] TCP-AO MAC algorithms At Fri, 4 Jan 2008 15:06:59 -0800, Brian Weis wrote: > > > On Dec 31, 2007, at 6:06 PM, Eric Rescorla wrote: > > > At Tue, 18 Dec 2007 16:23:51 -0800, > > Brian Weis wrote: > >> > >> Greetings, > >> > >> The TCPM WG seeks advice from SAAG on which MACs to include as > >> required MACs for the TCP Authentication Option = (draft-ietf-tcpm-tcp- > >> auth-opt-00). > > > > I would note that TLS has one MTI MAC (HMAC-SHA1) and based on RFC > > 4835, so does ESP/AH (HMAC-SHA1-96). What's the rationale for why > > TCP-AO should have stricter MTI requirements than we have for > > our dedicated security protocols? > > The rationale is simply that two methods with differing internal=20 > constructions implies that the standard is better prepared for the=20 > future (if one of the two MACs is perceived to be broken). Yes, this strikes me as massive overkill, given that typical MAC constructions are designed with some kind of reduction to the primitive they are based on. If, for instance, SHA-256 is broken badly enough that it implicates HMAC, it seems likely that we're going to have so many other cryptographic problems that the remaining security of TCP-AO will be the least of our worries. > >> Two MACs with differing internal constructions are > >> desired. > > > > I don't understand this either. Most modern MACs are constructed = from > > two pieces: > > > > - An underlying cryptographic function > > - A composition operation > > > > Thus, for instance, HMAC-SHA1 is constructed by using the HMAC > > composition operation with SHA-1. In general, the security = properties > > of the composition operations are well understood (often with some > > kind of reduction proof) where the security properties of the > > underlying function are unproven. So, while it might make sense > > to have two different base cryptographic functions (e.g., > > SHA-1 and SHA-256), it's not at all clear that it's of that > > much value to have two different constructions. > > Agreed that if two RTI MACs are chosen that the MACs must be=20 > significantly different. That's why the proposed set includes one of=20 > SHA-1 using HMAC (a Wegman-Carter MAC), and another of AES using CMAC=20 > (a cipher block chaining mode intended for authentication). I'm not sure why you say "agreed". As I said, I don't agree with this. On the contrary, I don't see much value in using different constructions. There's no reason to believe there's anything wrong with HMAC, the issue (to the extent to which there is any) is purely with the digests used by HMAC. If, for some reason, there is a perceived need to specify two functions HMAC with two different (potentially unrelated) digests seems fine. -Ekr _______________________________________________ saag mailing list saag@mit.edu http://mailman.mit.edu/mailman/listinfo/saag ------_=_NextPart_001_01C86F4E.30468BBD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [saag] TCP-AO MAC algorithms=0A= =0A= =0A= =0A=
=0A=
To tie a = number of threads together here I think it would help enormously if we = had some sort of cross IETF statement of the set of algorithms that are = currently the consensus recommendations for support.
=0A=
 
=0A=
I don't think that there is a = lot of disagreement on the important points, e.g. :
=0A=
 
=0A=
* If you are designing an = entirely new protocol that requires block encryption specify AES-128 and = AES-256 as MUST
=0A=
 
=0A=
* The use of 3DES, HMAC-SHA1, = should be avoided in entirely new protocols but is not cause for concern = in deployed protocols.
=0A=
 
=0A=
* Use of SHA1 should be = avoided except in deployed protocols where there has been careful = analysis that demonstrates use in that application is not cause for = concern.
=0A=
 
=0A=
* Use of MD5, ciphers with a = strength of 56 bits or less should be avoided in almost all = circumstances. Use of ciphers with key sizes of 64 bits or less should = be discontinued as soon as is practicable.
=0A=
 
=0A=
* If someone wants to specify = vanity crypto, give them the necessary URI or OID and tell them to use = it at their own discretion.
=0A=
 
=0A=
 
=0A=
I don't think we should have = this discussion in every individual working group.
=0A=
 
=0A=
I especially don't want to = have to have the discussion on how to use ECC with each individual IETF = spec in turn. Or worse have extended discussions over the optimal choice = of group etc. so that we end up with different choices across the IETF. = If the specifications are well designed we should have all the = information necessary to specify how to use algorithms across the = board.
=0A=
 
=0A=
As things stand I think we = are going to end up with more crypto configurations in IETF protocols = than we have crypto people. And that would be a bad thing when there is = a pretty strong consensus on preferred algorithms in the = field.
=0A=

=0A=
=0A= From: saag-bounces@mit.edu on behalf = of Eric Rescorla
Sent: Fri 04/01/2008 7:44 PM
To: = Brian Weis
Cc: saag@mit.edu
Subject: Re: [saag] = TCP-AO MAC algorithms

=0A=
=0A=

At Fri, 4 Jan 2008 15:06:59 -0800,
Brian Weis = wrote:
>
>
> On Dec 31, 2007, at 6:06 PM, Eric = Rescorla wrote:
>
> > At Tue, 18 Dec 2007 16:23:51 = -0800,
> > Brian Weis wrote:
> >>
> >> = Greetings,
> >>
> >> The TCPM WG seeks advice = from SAAG on which MACs to include as
> >> required MACs for = the TCP Authentication Option (draft-ietf-tcpm-tcp-
> >> = auth-opt-00).
> >
> > I would note that TLS has one = MTI MAC (HMAC-SHA1) and based on RFC
> > 4835, so does ESP/AH = (HMAC-SHA1-96). What's the rationale for why
> > TCP-AO should = have stricter MTI requirements than we have for
> > our = dedicated security protocols?
>
> The rationale is simply = that two methods with differing internal 
> constructions = implies that the standard is better prepared for the 
> = future (if one of the two MACs is perceived to be broken).

Yes, = this strikes me as massive overkill, given that typical
MAC = constructions are designed with some kind of reduction
to the = primitive they are based on. If, for instance, SHA-256
is broken = badly enough that it implicates HMAC, it seems
likely that we're = going to have so many other cryptographic
problems that the remaining = security of TCP-AO will be the
least of our worries.


> = >> Two MACs with differing internal constructions are
> = >> desired.
> >
> > I don't understand this = either. Most modern MACs are constructed from
> > two = pieces:
> >
> > - An underlying cryptographic = function
> > - A composition operation
> >
> = > Thus, for instance, HMAC-SHA1 is constructed by using the = HMAC
> > composition operation with SHA-1. In general, the = security properties
> > of the composition operations are well = understood (often with some
> > kind of reduction proof) where = the security properties of the
> > underlying function are = unproven. So, while it might make sense
> > to have two = different base cryptographic functions (e.g.,
> > SHA-1 and = SHA-256), it's not at all clear that it's of that
> > much = value to have two different constructions.
>
> Agreed that = if two RTI MACs are chosen that the MACs must be 
> = significantly different. That's why the proposed set includes one = of 
> SHA-1 using HMAC (a Wegman-Carter MAC), and another of = AES using CMAC 
> (a cipher block chaining mode intended for = authentication).

I'm not sure why you say "agreed". As I said, I = don't agree with this.

On the contrary, I don't see much value in = using different
constructions. There's no reason to believe there's = anything wrong
with HMAC, the issue (to the extent to which there is = any) is purely
with the digests used by HMAC. If, for some reason, = there is a perceived
need to specify two functions HMAC with two = different (potentially
unrelated) digests seems = fine.

-Ekr



________________________________________= _______
saag mailing list
saag@mit.edu
http://mailman.mit.= edu/mailman/listinfo/saag

------_=_NextPart_001_01C86F4E.30468BBD-- From vishwas.ietf@gmail.com Fri Feb 15 12:49:55 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1FHntHw025083 for ; Fri, 15 Feb 2008 12:49:55 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1FHnjVP001470 for ; Fri, 15 Feb 2008 12:49:45 -0500 (EST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mit.edu (Spam Firewall) with ESMTP id C8100D595F0 for ; Fri, 15 Feb 2008 12:49:44 -0500 (EST) Received: by ug-out-1314.google.com with SMTP id e2so1249597ugf.36 for ; Fri, 15 Feb 2008 09:49:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Rtw2BtQBU/gq+k/9p8cgpfpl0ZGE7br6yZLM9uBVsxE=; b=PNBGMFz0V3/YWrjKsUyL4MzlWwj84lAAjjWvaMp0hma2cLiic3UJEhwKfD24RQCDpQahXeYEMx85atc8qgXnHWbJGBk3D2ng7iAhGYwL4sNchBsb7/p6vGdBTwWcDM1ZyOHUFIDW7NbyK/JIW+XXs9rzG8WOeo1MwZB/JygNoU0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aiF03cH+D9Bq46IxjBFJyPf6SKmLyoNUMsuNyYcpJYfN/j4YINPrQQwZ++A8NAdMn/YV0SjKDy3WpOG3arianv6VR7uKmNPg1T1tQmez5MUy9MrpYLu86P/pOoHNIpV/Ov9GcdEDmWiVOFgJ3hqnbW89foWr4/sKuW7I4w65wS8= Received: by 10.142.141.21 with SMTP id o21mr2516935wfd.84.1203097782998; Fri, 15 Feb 2008 09:49:42 -0800 (PST) Received: by 10.143.164.14 with HTTP; Fri, 15 Feb 2008 09:49:42 -0800 (PST) Message-ID: <77ead0ec0802150949j5e6c9a70kde201d667362ce2c@mail.gmail.com> Date: Fri, 15 Feb 2008 09:49:42 -0800 From: "Vishwas Manral" To: "Hallam-Baker, Phillip" In-Reply-To: <2788466ED3E31C418E9ACC5C31661557085054@mou1wnexmb09.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <98FA6BE8-0825-41F6-8DAA-1A5706D974A9@cisco.com> <20080101020627.CBFAE5081A@romeo.rtfm.com> <20080105004455.9577F5081A@romeo.rtfm.com> <2788466ED3E31C418E9ACC5C31661557085054@mou1wnexmb09.vcorp.ad.vrsn.com> X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Managing aglorithms RE: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2008 17:49:55 -0000 Hi Phillip, I agree we probably could have some document talking about generic recommendations like those you suggest. However I would feel every application may have its own set of requirements which may overlap but not necessarily be the same. Not all applications require the same level of security. That said I would think the TCP-AO draft should follow the recommendations of RFC4835 like Eric mentioned earlier. Thanks, Vishwas 2008/2/14 Hallam-Baker, Phillip : > > > > To tie a number of threads together here I think it would help enormously if > we had some sort of cross IETF statement of the set of algorithms that are > currently the consensus recommendations for support. > > I don't think that there is a lot of disagreement on the important points, > e.g. : > > * If you are designing an entirely new protocol that requires block > encryption specify AES-128 and AES-256 as MUST > > * The use of 3DES, HMAC-SHA1, should be avoided in entirely new protocols > but is not cause for concern in deployed protocols. > > * Use of SHA1 should be avoided except in deployed protocols where there has > been careful analysis that demonstrates use in that application is not cause > for concern. > > * Use of MD5, ciphers with a strength of 56 bits or less should be avoided > in almost all circumstances. Use of ciphers with key sizes of 64 bits or > less should be discontinued as soon as is practicable. > > * If someone wants to specify vanity crypto, give them the necessary URI or > OID and tell them to use it at their own discretion. > > > I don't think we should have this discussion in every individual working > group. > > I especially don't want to have to have the discussion on how to use ECC > with each individual IETF spec in turn. Or worse have extended discussions > over the optimal choice of group etc. so that we end up with different > choices across the IETF. If the specifications are well designed we should > have all the information necessary to specify how to use algorithms across > the board. > > As things stand I think we are going to end up with more crypto > configurations in IETF protocols than we have crypto people. And that would > be a bad thing when there is a pretty strong consensus on preferred > algorithms in the field. > > ________________________________ > From: saag-bounces@mit.edu on behalf of Eric Rescorla > Sent: Fri 04/01/2008 7:44 PM > To: Brian Weis > Cc: saag@mit.edu > Subject: Re: [saag] TCP-AO MAC algorithms > > > > > At Fri, 4 Jan 2008 15:06:59 -0800, > Brian Weis wrote: > > > > > > On Dec 31, 2007, at 6:06 PM, Eric Rescorla wrote: > > > > > At Tue, 18 Dec 2007 16:23:51 -0800, > > > Brian Weis wrote: > > >> > > >> Greetings, > > >> > > >> The TCPM WG seeks advice from SAAG on which MACs to include as > > >> required MACs for the TCP Authentication Option (draft-ietf-tcpm-tcp- > > >> auth-opt-00). > > > > > > I would note that TLS has one MTI MAC (HMAC-SHA1) and based on RFC > > > 4835, so does ESP/AH (HMAC-SHA1-96). What's the rationale for why > > > TCP-AO should have stricter MTI requirements than we have for > > > our dedicated security protocols? > > > > The rationale is simply that two methods with differing internal > > constructions implies that the standard is better prepared for the > > future (if one of the two MACs is perceived to be broken). > > Yes, this strikes me as massive overkill, given that typical > MAC constructions are designed with some kind of reduction > to the primitive they are based on. If, for instance, SHA-256 > is broken badly enough that it implicates HMAC, it seems > likely that we're going to have so many other cryptographic > problems that the remaining security of TCP-AO will be the > least of our worries. > > > > >> Two MACs with differing internal constructions are > > >> desired. > > > > > > I don't understand this either. Most modern MACs are constructed from > > > two pieces: > > > > > > - An underlying cryptographic function > > > - A composition operation > > > > > > Thus, for instance, HMAC-SHA1 is constructed by using the HMAC > > > composition operation with SHA-1. In general, the security properties > > > of the composition operations are well understood (often with some > > > kind of reduction proof) where the security properties of the > > > underlying function are unproven. So, while it might make sense > > > to have two different base cryptographic functions (e.g., > > > SHA-1 and SHA-256), it's not at all clear that it's of that > > > much value to have two different constructions. > > > > Agreed that if two RTI MACs are chosen that the MACs must be > > significantly different. That's why the proposed set includes one of > > SHA-1 using HMAC (a Wegman-Carter MAC), and another of AES using CMAC > > (a cipher block chaining mode intended for authentication). > > I'm not sure why you say "agreed". As I said, I don't agree with this. > > On the contrary, I don't see much value in using different > constructions. There's no reason to believe there's anything wrong > with HMAC, the issue (to the extent to which there is any) is purely > with the digests used by HMAC. If, for some reason, there is a perceived > need to specify two functions HMAC with two different (potentially > unrelated) digests seems fine. > > -Ekr > > > > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag > > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag > > From rja@extremenetworks.com Sat Feb 16 18:43:27 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1GNhRlg009443 for ; Sat, 16 Feb 2008 18:43:27 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1GNhKeq021111 for ; Sat, 16 Feb 2008 18:43:20 -0500 (EST) Received: from ussc-casht-p2.corp.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id C8B9CFABA1C for ; Sat, 16 Feb 2008 18:42:59 -0500 (EST) Received: from USEXCHANGE.corp.extremenetworks.com ([172.168.1.2]) by ussc-casht-p2.corp.extremenetworks.com ([10.255.181.88]) with mapi; Sat, 16 Feb 2008 15:42:58 -0800 From: Randall Atkinson To: "saag@mit.edu" Date: Sat, 16 Feb 2008 15:42:57 -0800 Thread-Topic: Algorithms/modes requested by users/customers Thread-Index: AQHIcPWoS7HEfANh0kyQUz3uBqgcnA== Message-ID: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1GNhRlg009443 Subject: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2008 23:43:27 -0000 Earlier, someone said: % I think it would help enormously if we had some sort of % cross IETF statement of the set of algorithms that are % currently the consensus recommendations for support. I will answer a slightly different question. For the question: "What algorithms/modes are most paying customers asking for ?" the answers turn out to be: 1) NIST FIPS-140 conforming algorithms/modes. and 2) Suite-B conforming algorithms/modes. Approximately speaking, (2) above is a subset of (1) above. The IETF might make some different decision than those, but equipment vendors will have to implement (1) or (2) to please most commercial users (e.g. banks, insurance firms, stock brokerages/markets, top international commercial firms in other areas). So whether or not these are specified by IETF on the standards-track, there is interoperability value in having open specifications (e.g. Informational RFC would do quite nicely) for (1) and (2) for nearly any Internet-related protocol using cryptography. This seems to be driven externally by insurance firms that tell their customers to only use equipment whose cryptographic subsystems/modules have been (or are going to be) evaluated formally under FIPS-140. And I'll note that this are not really driven particularly by US firms. European, Asia/Pacific, and Latin American firms are making the exact same requests for FIPS-140 of their equipment vendors. Yours, Ran rja@extremenetworks.com From paul.hoffman@vpnc.org Sun Feb 17 12:48:54 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1HHmsSK026239 for ; Sun, 17 Feb 2008 12:48:54 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1HHmimj023096 for ; Sun, 17 Feb 2008 12:48:44 -0500 (EST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 793A4CD3DCC for ; Sun, 17 Feb 2008 12:48:23 -0500 (EST) Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1HHmIvk020317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Feb 2008 10:48:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks. com> References: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks. com> Date: Sun, 17 Feb 2008 09:47:53 -0800 To: Randall Atkinson , "saag@mit.edu" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2008 17:48:54 -0000 At 3:42 PM -0800 2/16/08, Randall Atkinson wrote: >1) NIST FIPS-140 conforming algorithms/modes. >and >2) Suite-B conforming algorithms/modes. This seems reasonable, and similar to what I hear from VPNC members. (Sadly, these same members ship new equipment defaulting to algorithms not in that list, but that's a different thread...) >This seems to be driven externally by insurance firms that tell >their customers to only use equipment whose cryptographic >subsystems/modules have been (or are going to be) evaluated >formally under FIPS-140. That is unreasonable. The ratio of "number of systems that use crypto" to "number of systems that have been or are going to be evaluated formally under FIPS-140" is incredibly high. The FIPS 140 evaluation process is horribly broken on a number of axes, and all the vendors in the field know it and complain privately about it. If you had instead said "have been (or at least could be) evaluated", I would agree with you. Buyers want to know that, if pressed hard, they can say "well, it is like that other system over there that got certified", and to do that, the uncertified system has to at least support all the right crypto. There is a noticeable but non-quantifiable preference for systems with a FIPS 140 certificate, but (outside the USGovt, of course) nearly no hard demand. >And I'll note that this are not really driven particularly by US firms. >European, Asia/Pacific, and Latin American firms are making the >exact same requests for FIPS-140 of their equipment vendors. I have heard that as well from VPNC members. But note the use of the term "requests". It would be a mistake for the IETF to look like we support the FIPS 140 certification process, even though it makes good sense for us to use the algorithms in that process as the basis for a suggested cross-IETF algorithm suite. --Paul Hoffman, Director --VPN Consortium From rja@extremenetworks.com Sun Feb 17 20:07:54 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1I17qsX030461 for ; Sun, 17 Feb 2008 20:07:52 -0500 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1I17gF7026626 for ; Sun, 17 Feb 2008 20:07:42 -0500 (EST) Received: from ussc-casht-p2.corp.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 982ED7773BA for ; Sun, 17 Feb 2008 20:06:56 -0500 (EST) Received: from USEXCHANGE.corp.extremenetworks.com ([172.168.1.2]) by ussc-casht-p2.corp.extremenetworks.com ([10.255.181.88]) with mapi; Sun, 17 Feb 2008 17:06:45 -0800 From: Randall Atkinson To: "saag@mit.edu" Date: Sun, 17 Feb 2008 17:06:44 -0800 Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: AchxjUlasNZBMgpDR7eptKQLGarIKgAOyiW0 Message-ID: <8329C86009B2F24493D76B486146769A9429B7A9@USEXCHANGE.corp.extremenetworks.com> References: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks. com>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1I17qsX030461 Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 01:07:54 -0000 Earlier Paul Hoffman said: % If you had instead said "have been (or at least could be) evaluated", % I would agree with you. Buyers want to know that, if pressed hard, % they can say "well, it is like that other system over there that got % certified", and to do that, the uncertified system has to at least % support all the right crypto. There is a noticeable but % non-quantifiable preference for systems with a FIPS 140 certificate, % but (outside the USGovt, of course) nearly no hard demand. It seems that what you are hearing and what I am hearing differ somewhat in this area. As an example, I've had multiple large non-US commercial firms in the City of London tell me that they require FIPS-140 approvals for cryptographic equipment they will purchase -- and that this was originally the idea of their insurers. These same firms have very substantial networking deployments at present and purchase equipment in large quantities. Separately, several governments other than the USA are requiring FIPS-140 approvals in equipment that they purchase. These other countries include places in Europe and Asia/Pacific and other continents/regions. Again, the volume of such systems is both non-trivial and quantifiable. % It would be a mistake for the IETF to look like we support % the FIPS 140 certification process, So far as I am aware, your comments above are the first suggestion of that. Certainly I did NOT suggest that and don't suggest it now. % even though it makes good sense for us to use the algorithms in % that process as the basis for a suggested cross-IETF algorithm suite. That is farther than I went. I simply suggested that there ought to be open specifications for how to use FIPS-conformant algorithms and modes with Internet protocols. An "open specification" could be an Informational status RFC, for example. That way users who do care about FIPS approvals would have a reasonable shot at being able to purchase interoperable equipment from multiple vendors -- and implementers would have a clear specification to work with. I did not (and do not now) advocate that the IETF standards track ought to do any particular thing with respect to cryptographic algorithms/modes. Yours, Ran Atkinson rja@extremenetworks.com From kent@bbn.com Tue Feb 19 10:16:10 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1JFGAv6006937 for ; Tue, 19 Feb 2008 10:16:10 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1JFG2hn016246 for ; Tue, 19 Feb 2008 10:16:03 -0500 (EST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by mit.edu (Spam Firewall) with ESMTP id 776AACCF438 for ; Tue, 19 Feb 2008 10:15:41 -0500 (EST) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JRUC4-0002Ch-5y; Tue, 19 Feb 2008 10:15:41 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks. com> Date: Tue, 19 Feb 2008 10:15:42 -0500 To: Paul Hoffman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: "saag@mit.edu" , Randall Atkinson Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 15:16:10 -0000 At 9:47 AM -0800 2/17/08, Paul Hoffman wrote: >... >>This seems to be driven externally by insurance firms that tell >>their customers to only use equipment whose cryptographic >>subsystems/modules have been (or are going to be) evaluated >>formally under FIPS-140. > >That is unreasonable. The ratio of "number of systems that use >crypto" to "number of systems that have been or are going to be >evaluated formally under FIPS-140" is incredibly high. The FIPS 140 >evaluation process is horribly broken on a number of axes, and all >the vendors in the field know it and complain privately about it. > >If you had instead said "have been (or at least could be) evaluated", >I would agree with you. Buyers want to know that, if pressed hard, >they can say "well, it is like that other system over there that got >certified", and to do that, the uncertified system has to at least >support all the right crypto. There is a noticeable but >non-quantifiable preference for systems with a FIPS 140 certificate, >but (outside the USGovt, of course) nearly no hard demand. Paul, Can you share the reasons cited by vendors to support the notion that the FIPS 140 process is broken. Compared to other security evaluation criteria, e.g. CC or the old Organge Book, most security folks I know view the FIPS 140 evaluation program as well managed and not very onerous. Also, if buyers believe that a device that "could be evaluated" is good enough, they are being rather naive. Experience with the FIPS 140 program has shown that a significant fraction of of products submitted for evaluation fail the process. Presumably a vendor submitting a product for evaluation believes that the product is ready, and will pass, otherwise the vendor is wasting money on the evaluation effort. The fact that many products fail evaluation (for good security reasons), tells me that a vendor's claim that a product "could be evaluated" is not much of an assurance. Steve From rja@extremenetworks.com Tue Feb 19 10:35:40 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1JFZeXt015205 for ; Tue, 19 Feb 2008 10:35:40 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1JFZVXb008340 for ; Tue, 19 Feb 2008 10:35:32 -0500 (EST) Received: from ussc-casht-p2.corp.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id D06F4DDF61A for ; Tue, 19 Feb 2008 10:35:10 -0500 (EST) Received: from USEXCHANGE.corp.extremenetworks.com ([172.168.1.2]) by ussc-casht-p2.corp.extremenetworks.com ([10.255.181.88]) with mapi; Tue, 19 Feb 2008 07:35:09 -0800 From: Randall Atkinson To: "saag@mit.edu" Date: Tue, 19 Feb 2008 07:35:08 -0800 Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: AchzCkrWW2rvMNdgR4y9V+Rd88/V4AAADsK4 Message-ID: <8329C86009B2F24493D76B486146769A9429B7C6@USEXCHANGE.corp.extremenetworks.com> References: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks. com> , In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1JFZeXt015205 Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 15:35:40 -0000 Earlier, Steve Kent wrote: % Also, if buyers believe that a device that "could be evaluated" is % good enough, they are being rather naive. Experience with the % FIPS 140 program has shown that a significant fraction of of % products submitted for evaluation fail the process. The quoted text above is fully consistent with my information (and my very limited personal experience) on this topic. % Presumably a vendor submitting a product for evaluation % believes that the product is ready, and will pass, otherwise the % vendor is wasting money on the evaluation effort. Some purchasers, including some US DoD components, do not require that a product actually be FIPS-140 certified in order for the purchaser to buy the product. Instead, some purchasers, including some US DoD components, only require that a product be "in evaluation" on the NIST web site in order to bid/sell that product. This can incent some vendors to submit products for FIPS-140 evaluation in order to bid/sell the product -- even if the vendor is unsure whether the product will pass that evaluation at that point in time. This last is a business decision based on various business factors, and is not necessarily a technical decision. Separately, there is substantial documentation required to pass a FIPS-140 evaluation, and it is not crystal clear upfront what level of detail on which topics is required to pass the evaluation. So, separate from the question of whether the product itself is ready, there is usually substantial documentation work required of the submitter after the formal FIPS-140 evaluation commences. The one area where I have heard concerns expressed by many implementers is that it can be difficult/time-consuming/expensive to "RAMP" an approved product so that a later version is approved formally under FIPS-140. I don't know if this is an actual process issue or merely a perceived issue. At least one implementer has commented to me that their latest FIPS-approved firmware has known-bugs fixed in subsequent non-FIPS-approved firmware because of (real or perceived) "RAMP" process issues. % The fact that many products fail evaluation (for good security % reasons), tells me that a vendor's claim that a product % "could be evaluated" is not much of an assurance. Agreed. And this point has been made to me by several different commercial/financial firms. It is not a coincidence that the encryptor I use at my home has an actual FIPS-140 certificate, nor that I use that system in FIPS mode. (And at this point, I seem a bit far from the charter of the SAAG list, but I'm not sure where followups should go. My apologies to any who viewed this as excessively off-topic.) Yours, Ran rja@extremenetworks.com DISCLAIMER: I am employed by Extreme Networks, but I am never authorised to speak for my employer. The text from me above is my own personal views/understanding, and must not be taken as a position held by my employer. From paul.hoffman@vpnc.org Tue Feb 19 11:19:18 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1JGJIdo001231 for ; Tue, 19 Feb 2008 11:19:18 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1JGJAd0019344 for ; Tue, 19 Feb 2008 11:19:11 -0500 (EST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 76AE5C9E700 for ; Tue, 19 Feb 2008 11:18:49 -0500 (EST) Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1JGIQhh073200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2008 09:18:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks . com> Date: Tue, 19 Feb 2008 08:18:24 -0800 To: Stephen Kent From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: "saag@mit.edu" , Randall Atkinson Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 16:19:18 -0000 At 10:15 AM -0500 2/19/08, Stephen Kent wrote: >Can you share the reasons cited by vendors to support the notion >that the FIPS 140 process is broken. Sure. - It takes way too long from submission of system to validation, even if no problems are found. - If problems are found during evaluation, the restart time is too long. - Some of the tests are fairly subjective, and it becomes a game of fixing code to please the testing service, not to make the product more secure. - An evaluated product cannot have its core firmware updated without losing the validation. For example, if a customer asks for a new feature that might touch the crypto, the vendor has to choose between losing the validation (and paying for a new one, and waiting for the results) or keeping the customer happy. - The validation doesn't even check for on-the-wire interoperability, which is what the customers care about most. - The test process is too expensive for many low-end devices that would be very useful in USGovt offices. - The system introduces silly modes that make the systems more complicated. These are the top complaints I hear from both large and small vendors. There are certainly others. "Oh, don't get me started" is commonly heard when discussing FIPS 140 testing. > Compared to other security evaluation criteria, e.g. CC or the old >Organge Book, most security folks I know view the FIPS 140 >evaluation program as well managed and not very onerous. "Security folks" are not good evaluators on how some processes affect the market. >Also, if buyers believe that a device that "could be evaluated" is >good enough, they are being rather naive. Maybe. If a buyer cares about "does this box support the needed crypto in an interoperable fashion", then the perception is fine. If they care about all the details that FIPS 140 testing covers, then of course it is naive. >Experience with the FIPS 140 program has shown that a significant >fraction of of products submitted for evaluation fail the process. This statement is usually bandied about without any quantification of what failures were found, as it is here. As someone who creates test suites, I can assure you that I can make a few picky rules for systems that would cause some of those systems to fail, but most end users who understood those few rules would say that those rules were silly. Of course, different end users have different requirements. It is generally felt by vendors that some/many of the rules for FIPS 140 are silly and unneeded; on the other hand, it is likely that at least a few USGovt customers would really want some of those rules for particular reasons. >Presumably a vendor submitting a product for evaluation believes >that the product is ready, and will pass, otherwise the vendor is >wasting money on the evaluation effort. Wrong, very wrong. You cannot tell what the testing agency might try to knock you down on ahead of time. Of course, you cover what you can, but you also know that there is a good chance they'll just whack you a bit because it makes them look good. >The fact that many products fail evaluation (for good security >reasons), tells me that a vendor's claim that a product "could be >evaluated" is not much of an assurance. If you believe in the testing regime, that's fine. Others don't, and I believe for very good reasons in their own use scenarios. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Tue Feb 19 13:05:07 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1JI5774017621 for ; Tue, 19 Feb 2008 13:05:07 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1JI4uI2023267 for ; Tue, 19 Feb 2008 13:04:57 -0500 (EST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 7617DDA0F82 for ; Tue, 19 Feb 2008 13:04:35 -0500 (EST) Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1JI4Fjl086137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2008 11:04:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks. com> Date: Tue, 19 Feb 2008 10:04:12 -0800 To: "Santosh Chokhani" , "Stephen Kent" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Randall Atkinson Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 18:05:07 -0000 At 11:49 AM -0500 2/19/08, Santosh Chokhani wrote: >On the issue of restart, that is misunderstanding on Paul's part. There >is no restart. Ahem. I am reporting what the members of VPNC report to me. They are the vendors in the testing, not me. I have heard this from multiple vendors. If I was not clear that I was reporting what others said, I apologize. >Generally, problem is fixed and you pick up that point. Not to be too picky, but how can you say "generally" without seeing every test that was stopped? Maybe you have not had this problem, but others say they have. >Subjective tests seems to be misunderstanding on Paul's part. Having >been in the Orange Book, CC and FIPS process, I as validator, tester, >and certifier as well as vendor generally rue about rigidness of the >standard and lack of subjective judgment on the part of the tester or >lack of subjective latitude to vendors. If you, as a tester, feel that there are no subjective parts of the test process, that's fine. Some/many people who are being tested disagree with you. >FIPS 140 has specific guidelines on how to deal with minor incremental >changes that helps reduce cost and calendar time. Great! It does not seem to have gotten through to the vendors themselves as "inexpensive enough" or "fast enough". As a tester, you may have a different view. >The standard is NOT a protocol standard. It does verify the algorithm >implementations and thus, FIPS validated algorithms can interoperate. Quite true. >In terms of low end devices, 20-30K for level 1 testing amortized over >devices does not seem too onerous. ...to you. Others disagree, both on the financial cost, and particularly on the cost of elapsed time before customers can use the latest release from a vendor. >I do not understand what Paul refers to as silly modes. The module >being FIPS validated must use FIPS validated or recognized algorithms >for a given crypto service. That seems like a good thing to me. That is a good thing; it is also not what I was talking about. There is disagreement about what needs to be in a "FIPS mode", and whether the shipped product needs to allow "FIPS mode" to be enabled, and if so, how. Again: I am reporting what I hear from many VPNC members over many years. You as a single vendor and/or tester might feel differently; your feeling does not invalidate the views of others. --Paul Hoffman, Director --VPN Consortium From lloyd@randombit.net Tue Feb 19 13:10:45 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1JIAjIC019859 for ; Tue, 19 Feb 2008 13:10:45 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1JI9iqK002398 for ; Tue, 19 Feb 2008 13:09:44 -0500 (EST) Received: from mail.randombit.net (lain.randombit.net [66.179.181.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 90BEAF7263F for ; Tue, 19 Feb 2008 13:09:22 -0500 (EST) Received: by mail.randombit.net (Postfix, from userid 501) id 2BB153B60F7; Tue, 19 Feb 2008 13:09:24 -0500 (EST) Date: Tue, 19 Feb 2008 13:09:24 -0500 From: Jack Lloyd To: saag@mit.edu Message-ID: <20080219180923.GE7163@randombit.net> Mail-Followup-To: saag@mit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Fingerprint: 3F69 2E64 6D92 3BBE E7AE 9258 5C0F 96E8 4EC1 6D6B X-PGP-Key: http://www.randombit.net/pgpkey.html User-Agent: Mutt/1.5.11 X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 18:10:45 -0000 On Tue, Feb 19, 2008 at 08:18:24AM -0800, Paul Hoffman wrote: > - Some of the tests are fairly subjective, and it becomes a game of > fixing code to please the testing service, not to make the product > more secure. [...] > - The system introduces silly modes that make the systems more complicated. I have no experience with the purchasing side, but in my experience doing FIPS 140 validations, we often had to ask vendors to include hooks for testing that, from any objective standpoint, made the system less secure. And because the tests must be made on the same firmware/software as the as-shipped one (not in a special test/debug mode), that increased the attack surface of some of these devices greatly. I will fondly remember the validation where I found several exploitable buffer overflows in an HSM that had already passed two previous validations - all the holes were found in the hooks used for FIPS-140 testing. The tests that require the RNG be able to seeded with fixed data always seeemed particularly troublesome/dangerous to me. Obvious disclaimer: Anecdotes are not data - I just thought a relatively concrete example might be relevant to the discussion at hand. -Jack From paul.hoffman@vpnc.org Tue Feb 19 13:52:13 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1JIqDI1004439 for ; Tue, 19 Feb 2008 13:52:13 -0500 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1JIq3ck024805 for ; Tue, 19 Feb 2008 13:52:03 -0500 (EST) Received: from balder-227.proper.com (balder-227.proper.com [192.245.12.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id BE9D777702A for ; Tue, 19 Feb 2008 13:51:58 -0500 (EST) Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1JIpnJm092659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Feb 2008 11:51:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks. com> Date: Tue, 19 Feb 2008 10:51:46 -0800 To: saag@mit.edu From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 18:52:13 -0000 At 1:13 PM -0500 2/19/08, Santosh Chokhani wrote: >My general observation is that vendors do not assign their engineers to >these efforts and there is a dearth of qualified testers, resulting in >blind leading the blind. That is a fairly damning criticism of the process, of course. It would not be bad if this were a voluntary logo program like VPNC or ICSA Labs has; when it prevents a large customer (many large customers, according to Ran) from buying up-to-date equipment that meets their security needs, it has serious implications for the security of the purchasers. --Paul Hoffman, Director --VPN Consortium From mcgrew@cisco.com Tue Feb 19 14:28:28 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1JJSS3R019263 for ; Tue, 19 Feb 2008 14:28:28 -0500 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1JJSF01001750 for ; Tue, 19 Feb 2008 14:28:15 -0500 (EST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by mit.edu (Spam Firewall) with ESMTP id C7F2D791B3B for ; Tue, 19 Feb 2008 14:27:51 -0500 (EST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 19 Feb 2008 14:27:50 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1JJRnb6027750; Tue, 19 Feb 2008 14:27:49 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1JJRiSE013583; Tue, 19 Feb 2008 19:27:44 GMT Received: from xmb-rtp-20c.amer.cisco.com ([64.102.31.57]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 14:27:34 -0500 Received: from 10.32.254.212 ([10.32.254.212]) by xmb-rtp-20c.amer.cisco.com ([64.102.31.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 19 Feb 2008 19:27:34 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Tue, 19 Feb 2008 11:27:32 -0800 From: mcgrew To: Randall Atkinson , "saag@mit.edu" Message-ID: Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: AQHIcPWoS7HEfANh0kyQUz3uBqgcnI1VeQZu In-Reply-To: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 19 Feb 2008 19:27:34.0421 (UTC) FILETIME=[7A64D450:01C8732D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2428; t=1203449269; x=1204313269; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:=20mcgrew=20 |Subject:=20Re=3A=20[saag]=20Algorithms/modes=20requested=2 0by=20users/customers |Sender:=20 |To:=20Randall=20Atkinson=20,=20=2 2saag@mit.edu=22=20; bh=0MBqj5sFQpqZo1/VEcLy6U1y74b27MLKWLdbp1zPFoA=; b=SlaR3FsFzAWRnJLOnLawvYcusMednwmngpsHR299jfhrMPII2in4cMG2sD gsGFT0sV3c4DN5hzm+IH0HRNpPrwY/dd+f/NFbDaV5oNQPQxqEGrZS8rXcRN Xscz7RA7mD; Authentication-Results: rtp-dkim-2; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.14 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 19:28:28 -0000 Hi Ran, Winston Churchill said that democracy is the worst form of government, except for all of the others. I think that the same is true for the FIPS-140 cryptomodule validation process ;-) I agree with you that there is good value in having open specs for FIPS-140 and Suite-B versions of Internet protocols (even though I also agree with many of the criticisms of the validation process made on this thread). I expect that the choice of which algorithm(s) should be mandatory-to-implement will continue to be made on the basis of technical (well, mostly technical) discussions in the WGs. Best, David On 2/16/08 3:42 PM, "Randall Atkinson" wrote: > Earlier, someone said: > % I think it would help enormously if we had some sort of > % cross IETF statement of the set of algorithms that are > % currently the consensus recommendations for support. > > I will answer a slightly different question. For the question: > "What algorithms/modes are most paying customers asking for ?" > the answers turn out to be: > > 1) NIST FIPS-140 conforming algorithms/modes. > and > 2) Suite-B conforming algorithms/modes. > > Approximately speaking, (2) above is a subset of (1) above. > > The IETF might make some different decision than those, > but equipment vendors will have to implement (1) or (2) > to please most commercial users (e.g. banks, insurance firms, > stock brokerages/markets, top international commercial > firms in other areas). So whether or not these are specified > by IETF on the standards-track, there is interoperability value > in having open specifications (e.g. Informational RFC would > do quite nicely) for (1) and (2) for nearly any Internet-related > protocol using cryptography. > > This seems to be driven externally by insurance firms that tell > their customers to only use equipment whose cryptographic > subsystems/modules have been (or are going to be) evaluated > formally under FIPS-140. > > And I'll note that this are not really driven particularly by US firms. > European, Asia/Pacific, and Latin American firms are making the > exact same requests for FIPS-140 of their equipment vendors. > > Yours, > > Ran > rja@extremenetworks.com > > > > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag From kent@bbn.com Tue Feb 19 17:35:47 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1JMZlVo030923 for ; Tue, 19 Feb 2008 17:35:47 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1JMZbm1022094 for ; Tue, 19 Feb 2008 17:35:37 -0500 (EST) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by mit.edu (Spam Firewall) with ESMTP id 32200DDC1FE for ; Tue, 19 Feb 2008 17:35:16 -0500 (EST) Received: from col-dhcp33-244-170.bbn.com ([128.33.244.170]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JRb3T-0000VO-4g; Tue, 19 Feb 2008 17:35:15 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks . com> Date: Tue, 19 Feb 2008 17:35:18 -0500 To: Paul Hoffman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: "saag@mit.edu" , Randall Atkinson Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 22:35:48 -0000 At 8:18 AM -0800 2/19/08, Paul Hoffman wrote: >At 10:15 AM -0500 2/19/08, Stephen Kent wrote: >>Can you share the reasons cited by vendors to support the notion >>that the FIPS 140 process is broken. > >Sure. > >- It takes way too long from submission of system to validation, >even if no problems are found. I have gone through a level 3 eval and compared to ALL other security criteria evaluations, the time to perform the eval is much, much better. So, my guess is that anyone complaining about this has no experience with evals for things like CC. >- If problems are found during evaluation, the restart time is too long. ibid. >- Some of the tests are fairly subjective, and it becomes a game of >fixing code to please the testing service, not to make the product >more secure. It is true that some test criteria are not completely cut and dried. That is a problem with every one of these secruity eval criteria. My experience is that FIPS 40 is better i this regard than all the others. >- An evaluated product cannot have its core firmware updated without >losing the validation. For example, if a customer asks for a new >feature that might touch the crypto, the vendor has to choose >between losing the validation (and paying for a new one, and waiting >for the results) or keeping the customer happy. Absolutely right, and it should be that way! To expect otherwise is to fail to understand what a security eval is al about. However, the representation above is silly. The old product with the old feature set is still validated. It's the new version that cannot yet be sold as evaluated. When we had a level 3 device, we also sold a version that was not yet evaluated, but had nifty new features, and explained the situation to clients, some of who opted for the old version until the new version was evaluated. >- The validation doesn't even check for on-the-wire >interoperability, which is what the customers care about most. It's a crypto security eval criteria, not a protocol compliance eval criteria. The labs are not testers of IPsec or TLS; they are testers of crypto module functions, period. a buyer who doesn't understand that is misinformed. >- The test process is too expensive for many low-end devices that >would be very useful in USGovt offices. > >- The system introduces silly modes that make the systems more complicated. e.g., ? >These are the top complaints I hear from both large and small >vendors. There are certainly others. "Oh, don't get me started" is >commonly heard when discussing FIPS 140 testing. Whiners :-). >> Compared to other security evaluation criteria, e.g. CC or the >>old Organge Book, most security folks I know view the FIPS 140 >>evaluation program as well managed and not very onerous. > >"Security folks" are not good evaluators on how some processes >affect the market. But we are experienced with various security eval criteria, and one ought to judge such criteria in context. In that context FIPS 140 is viewed as having a great track record. > >>Also, if buyers believe that a device that "could be evaluated" is >>good enough, they are being rather naive. > >Maybe. If a buyer cares about "does this box support the needed >crypto in an interoperable fashion", then the perception is fine. If >they care about all the details that FIPS 140 testing covers, then >of course it is naive. Your statement seems to conflate two very separate issues. if a buyer is concerned primarily with interoperability or (non-crypto) standards compliance, then FIPS 140 is irrelevant. if they care about whether a product that purports to use crypto for security does so securely, then FIPS 140 eval is a solid prerequisite. I think a client who cares more about interoperability of a crypto-based security product than the security of the product is naive. > >>Experience with the FIPS 140 program has shown that a significant >>fraction of of products submitted for evaluation fail the process. > >This statement is usually bandied about without any quantification >of what failures were found, as it is here. As someone who creates >test suites, I can assure you that I can make a few picky rules for >systems that would cause some of those systems to fail, but most end >users who understood those few rules would say that those rules were >silly. Of course, different end users have different requirements. >It is generally felt by vendors that some/many of the rules for FIPS >140 are silly and unneeded; on the other hand, it is likely that at >least a few USGovt customers would really want some of those rules >for particular reasons. I have served several terms on an committee operated by the National Academy of Sciences that provides an external review for the NIST Security Lab. In our review meetings I have seen the figures for the pas/fail rate, and have seen descriptions of the reasons for failures, some of which are hilariously bad. I is not only US Givernment clients who care about most of the "picky rules." The banking community has mandated FIPS evaluation for years. However, if a client is more concerned about the performance of a VPN appliance than the security of the device, FIPS 140 is not a good criteria for that client. > >>Presumably a vendor submitting a product for evaluation believes >>that the product is ready, and will pass, otherwise the vendor is >>wasting money on the evaluation effort. > >Wrong, very wrong. You cannot tell what the testing agency might try >to knock you down on ahead of time. Of course, you cover what you >can, but you also know that there is a good chance they'll just >whack you a bit because it makes them look good. Nonsense, utter nonsense (says the guy who went trough this process, as opposed to the guy who is relating what he has been told by others). The criteria are complemented by guidelines for eval labs, and these guidelines are available to vendors. So, a smart vendor would study the criteria and the guidelines before designing a product that will be evaluated. A smart vendor will discuss the criteria with the lad it chooses, to minimize uncertainty. >>The fact that many products fail evaluation (for good security >>reasons), tells me that a vendor's claim that a product "could be >>evaluated" is not much of an assurance. > >If you believe in the testing regime, that's fine. Others don't, and >I believe for very good reasons in their own use scenarios. What I said is true, irrespective of whether one believes in the criteria or the testing methodology. The reality is the products fail, and many (not all) of the failures are demonstrably due to serious security problems. So, given this experience, one really ought not believe a vendor (whose goal is to sell products) who says "oh yeah, our product would pass evaluation, but we don't think it's worth the investment." A client who believes this argument should buy a used car without a warranty or an inspection by a mechanic. The likelihood of a good outcome is similar. Steve From jon@callas.org Tue Feb 19 19:10:22 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1K0ALKU001620 for ; Tue, 19 Feb 2008 19:10:21 -0500 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1K0ABQ1007001 for ; Tue, 19 Feb 2008 19:10:11 -0500 (EST) Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by mit.edu (Spam Firewall) with ESMTP id 5014B77B2AF for ; Tue, 19 Feb 2008 19:10:09 -0500 (EST) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 33D39CCE529 for ; Tue, 19 Feb 2008 16:10:09 -0800 (PST) Received: from [192.168.16.100] ([12.37.185.170]) by keys.merrymeet.com (PGP Universal service); Tue, 19 Feb 2008 16:10:09 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 19 Feb 2008 16:10:09 -0800 Message-Id: <57147A59-BFAE-4F55-AE28-C653EB7475D1@callas.org> From: Jon Callas To: saag@mit.edu In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 19 Feb 2008 16:10:06 -0800 References: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks. com> X-Mailer: Apple Mail (2.919.2) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 00:10:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 1:13 PM -0500 2/19/08, Santosh Chokhani wrote: > My general observation is that vendors do not assign their engineers > to > these efforts and there is a dearth of qualified testers, resulting in > blind leading the blind. I want to agree with Paul Hoffman that FIPS 140 is unnecessarily painful. I think I will also agree with Stephen Kent and say that FIPS is to CC as laparoscopic surgery is to open heart. Santosh also gets a big +1 from me, and I'll tell how even this dark cloud has a silver lining. When PGP first went through FIPS 140, we assigned a dedicated engineer to the process. Shepherding software through FIPS 140 was so painful, so mind-numbing, so annoying that he quit the company, quit cryptography, and quit computer security altogether. He took a job with a company that produced MP3 music software. That company was bought out by Apple, and the software turned into what we now know as iTunes. He is at Apple to this day as the lead of iTunes. So the next time you listen to an iPod, think about FIPS 140, and thank the horrible process. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFHu2/hsTedWZOD3gYRAuZbAJ9IFEWuafL6fAB+2MxJvwIEOmLJiACgkJrs eRur6xWa+w6FdH022GobtDg= =ZTOd -----END PGP SIGNATURE----- From pgut001@cs.auckland.ac.nz Wed Feb 20 06:16:38 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KBGc6k013104 for ; Wed, 20 Feb 2008 06:16:38 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1KBGPwa005987 for ; Wed, 20 Feb 2008 06:16:28 -0500 (EST) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by mit.edu (Spam Firewall) with ESMTP id 4DF87CCDCC7 for ; Wed, 20 Feb 2008 06:16:03 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7D64A4806FF; Thu, 21 Feb 2008 00:16:01 +1300 (NZDT) Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQ-TTEyFaCRj; Thu, 21 Feb 2008 00:16:01 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 1A349480425; Thu, 21 Feb 2008 00:16:00 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id DFF1AE080BD; Thu, 21 Feb 2008 00:15:56 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JRmvc-0007T0-QF; Thu, 21 Feb 2008 00:15:56 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: kent@bbn.com, paul.hoffman@vpnc.org In-Reply-To: Message-Id: Sender: pgut001 Date: Thu, 21 Feb 2008 00:15:56 +1300 X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, rja@extremenetworks.com Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 11:16:39 -0000 Paul Hoffman writes: Some quick notes on the consequences of three of these which may not be immediately obvious: >- It takes way too long from submission of system to validation, even if no >problems are found. Corollary: Users have the option of running a current, up-to-date non- evaluated version or an obsolete evaluated version. This becomes particularly critical if there's a security advisory issued for the old version, because you can't close the hole without losing the eval. So you get the choice of running an insecure FIPS 140-blessed version or a secure (well, as far as anyone knows) non-FIPS 140-blessed version. For some reason this doesn't seem to go down well with customers. >- Some of the tests are fairly subjective, and it becomes a game of fixing >code to please the testing service, not to make the product more secure. Corollary: You can get completely different results depending on how you submit your product, and who to, and when. I've heard of vendors doing the equivalent of jury-shopping in order to ease the evaluation process. >- The validation doesn't even check for on-the-wire interoperability, which >is what the customers care about most. Corollary: An ability to perform a TLS connect to Amazon (if the product is in this case a TLS crypto system) tells the customer more than the FIPS 140 eval ever can, since much of the TLS functionality is orthogonal to what FIPS 140 tests. >"Oh, don't get me started" is commonly heard when discussing FIPS 140 >testing. That's why I've tried to keep out of this so far :-). Ask enough people and you can get a very long list. This and CC do make for good conversation starters among security geeks though. Peter. From pgut001@cs.auckland.ac.nz Wed Feb 20 06:37:16 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KBbG1G018564 for ; Wed, 20 Feb 2008 06:37:16 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1KBb42v005458 for ; Wed, 20 Feb 2008 06:37:05 -0500 (EST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by mit.edu (Spam Firewall) with ESMTP id 955DCFC05B4 for ; Wed, 20 Feb 2008 06:36:43 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 991349C78D; Thu, 21 Feb 2008 00:36:40 +1300 (NZDT) Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dc7iktaQ4nY; Thu, 21 Feb 2008 00:36:40 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id E26249C78B; Thu, 21 Feb 2008 00:36:39 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 2A993E080BD; Thu, 21 Feb 2008 00:36:39 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JRnFf-0008Uw-1D; Thu, 21 Feb 2008 00:36:39 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: mcgrew@cisco.com, rja@extremenetworks.com, saag@mit.edu In-Reply-To: Message-Id: Sender: pgut001 Date: Thu, 21 Feb 2008 00:36:39 +1300 X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 11:37:16 -0000 mcgrew writes: >Winston Churchill said that democracy is the worst form of government, except >for all of the others. I think that the same is true for the FIPS-140 >cryptomodule validation process ;-) I think it's more a case of the Politician's Fallacy: 1. Something must be done. 2. This is something. 3. This must be done. It'd be interesting to see a study of the effectiveness in terms of finding security and interop problems of: A. A FIPS 140 eval. B. Running the code through Fortify/Coverity/whatever and completing a crypto exchange with a peer (TLS, S/MIME, PGP, whatever the underlying crypto is that's being used). in particular in terms of return for effort-involved. Peter. From smb@cs.columbia.edu Wed Feb 20 08:13:18 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KDDG8B021254 for ; Wed, 20 Feb 2008 08:13:17 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1KDD5PF015636 for ; Wed, 20 Feb 2008 08:13:05 -0500 (EST) Received: from machshav.com (machshav.com [198.180.150.44]) by mit.edu (Spam Firewall) with ESMTP id F3E836B5DA5 for ; Wed, 20 Feb 2008 08:10:50 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 9907F65E; Wed, 20 Feb 2008 13:10:50 +0000 (GMT) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id ECE1D15F; Wed, 20 Feb 2008 13:10:49 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id E7075282CFE; Wed, 20 Feb 2008 08:10:48 -0500 (EST) Date: Wed, 20 Feb 2008 13:10:48 +0000 From: "Steven M. Bellovin" To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Message-ID: <20080220131048.55faab0b@cs.columbia.edu> In-Reply-To: References: Organization: Columbia University X-Mailer: Claws Mail 3.2.0 (GTK+ 2.12.5; x86_64--netbsd) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.41 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, rja@extremenetworks.com, mcgrew@cisco.com Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 13:13:18 -0000 On Thu, 21 Feb 2008 00:36:39 +1300 pgut001@cs.auckland.ac.nz (Peter Gutmann) wrote: > mcgrew writes: > > >Winston Churchill said that democracy is the worst form of > >government, except for all of the others. I think that the same is > >true for the FIPS-140 cryptomodule validation process ;-) > > I think it's more a case of the Politician's Fallacy: > > 1. Something must be done. > 2. This is something. > 3. This must be done. > > It'd be interesting to see a study of the effectiveness in terms of > finding security and interop problems of: > > A. A FIPS 140 eval. > > B. Running the code through Fortify/Coverity/whatever and completing > a crypto exchange with a peer (TLS, S/MIME, PGP, whatever the > underlying crypto is that's being used). > > in particular in terms of return for effort-involved. Right. But here's the problem with this choice: FIPS-140 is mostly about assurance of security, and not just correctness of the crypto. Given the really bad mistakes we've all seen -- things that would be caught by any decent outside evaluation -- what is the alternative? What is the *assurance* a customer has that the product is adequately secured? --Steve Bellovin, http://www.cs.columbia.edu/~smb From pgut001@cs.auckland.ac.nz Wed Feb 20 08:51:20 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KDpKrF005230 for ; Wed, 20 Feb 2008 08:51:20 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1KDp9AR026495 for ; Wed, 20 Feb 2008 08:51:09 -0500 (EST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by mit.edu (Spam Firewall) with ESMTP id 2F3A4D66C28 for ; Wed, 20 Feb 2008 08:50:47 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 508FD9C78E; Thu, 21 Feb 2008 02:50:46 +1300 (NZDT) Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sClDQVRjcD-U; Thu, 21 Feb 2008 02:50:46 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4A4CA9C783; Thu, 21 Feb 2008 02:50:45 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id C569219EC0B7; Thu, 21 Feb 2008 02:50:42 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JRpLO-0006MQ-Lc; Thu, 21 Feb 2008 02:50:42 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, smb@cs.columbia.edu In-Reply-To: <20080220131048.55faab0b@cs.columbia.edu> Message-Id: Sender: pgut001 Date: Thu, 21 Feb 2008 02:50:42 +1300 X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, rja@extremenetworks.com, mcgrew@cisco.com Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 13:51:20 -0000 "Steven M. Bellovin" writes: >FIPS-140 is mostly about assurance of security, and not just correctness of >the crypto. Is it about assurance of security, or assurance of production of paperwork showing the certification conditions have been met? There have been plenty of security advisories issued for CC and FIPS-140 evaluated products (and even more not publicised but silently fixed in a certification-voiding manner). >Given the really bad mistakes we've all seen -- things that would be caught >by any decent outside evaluation -- what is the alternative? What is the >*assurance* a customer has that the product is adequately secured? Politician's Fallacy again: Is FIPS 140 really the best way to spend your money? If FIPS 140 is the answer now, why wasn't the Orange Book the answer then? What about giving the money to (picking a random name) Cigital and saying "make sure this code is OK"? What about giving the money to Dan Bernstein and saying "implement this and make it secure"? What about having the code written by Germans and pen-tested by the French? [0]. We have no hard data either way (although I'd put my money on Cigital and Dan to produce the more secure product :-). But simply saying "We must use FIPS 140... just... well, just because!" is hardly a scientific approach to solving the problem. Peter. [0] A very much under-exploited strategy in security evaluation. From SChokhani@cygnacom.com Tue Feb 19 11:50:27 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1JGoQrw015899 for ; Tue, 19 Feb 2008 11:50:26 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1JGoGki015630 for ; Tue, 19 Feb 2008 11:50:17 -0500 (EST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by mit.edu (Spam Firewall) with SMTP id 08DE9CD4D90 for ; Tue, 19 Feb 2008 11:49:55 -0500 (EST) Received: (qmail 2626 invoked from network); 19 Feb 2008 16:42:22 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 19 Feb 2008 16:42:22 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 19 Feb 2008 16:42:22 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 19 Feb 2008 11:49:53 -0500 Message-ID: in-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: AchzFO3PhWGkWHRDTSG0q9i/xNMp9gAAJGnw References: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks. com> From: "Santosh Chokhani" To: "Paul Hoffman" , "Stephen Kent" X-Spam-Score: 0.14 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1JGoQrw015899 X-Mailman-Approved-At: Wed, 20 Feb 2008 10:05:23 -0500 Cc: saag@mit.edu, Randall Atkinson Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 16:50:27 -0000 On the issue of it takes too long, the FIPS process is the envy of other schemes. One could always be faster. On the issue of restart, that is misunderstanding on Paul's part. There is no restart. Generally, problem is fixed and you pick up that point. This is generally a vendor problem. Depending on the nature of problem/failure, other aspects of the testing can continue without loss of calendar time. Subjective tests seems to be misunderstanding on Paul's part. Having been in the Orange Book, CC and FIPS process, I as validator, tester, and certifier as well as vendor generally rue about rigidness of the standard and lack of subjective judgment on the part of the tester or lack of subjective latitude to vendors. FIPS 140 has specific guidelines on how to deal with minor incremental changes that helps reduce cost and calendar time. The standard is NOT a protocol standard. It does verify the algorithm implementations and thus, FIPS validated algorithms can interoperate. In terms of low end devices, 20-30K for level 1 testing amortized over devices does not seem too onerous. I do not understand what Paul refers to as silly modes. The module being FIPS validated must use FIPS validated or recognized algorithms for a given crypto service. That seems like a good thing to me. -----Original Message----- From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of Paul Hoffman Sent: Tuesday, February 19, 2008 11:18 AM To: Stephen Kent Cc: saag@mit.edu; Randall Atkinson Subject: Re: [saag] Algorithms/modes requested by users/customers At 10:15 AM -0500 2/19/08, Stephen Kent wrote: >Can you share the reasons cited by vendors to support the notion >that the FIPS 140 process is broken. Sure. - It takes way too long from submission of system to validation, even if no problems are found. - If problems are found during evaluation, the restart time is too long. - Some of the tests are fairly subjective, and it becomes a game of fixing code to please the testing service, not to make the product more secure. - An evaluated product cannot have its core firmware updated without losing the validation. For example, if a customer asks for a new feature that might touch the crypto, the vendor has to choose between losing the validation (and paying for a new one, and waiting for the results) or keeping the customer happy. - The validation doesn't even check for on-the-wire interoperability, which is what the customers care about most. - The test process is too expensive for many low-end devices that would be very useful in USGovt offices. - The system introduces silly modes that make the systems more complicated. These are the top complaints I hear from both large and small vendors. There are certainly others. "Oh, don't get me started" is commonly heard when discussing FIPS 140 testing. > Compared to other security evaluation criteria, e.g. CC or the old >Organge Book, most security folks I know view the FIPS 140 >evaluation program as well managed and not very onerous. "Security folks" are not good evaluators on how some processes affect the market. >Also, if buyers believe that a device that "could be evaluated" is >good enough, they are being rather naive. Maybe. If a buyer cares about "does this box support the needed crypto in an interoperable fashion", then the perception is fine. If they care about all the details that FIPS 140 testing covers, then of course it is naive. >Experience with the FIPS 140 program has shown that a significant >fraction of of products submitted for evaluation fail the process. This statement is usually bandied about without any quantification of what failures were found, as it is here. As someone who creates test suites, I can assure you that I can make a few picky rules for systems that would cause some of those systems to fail, but most end users who understood those few rules would say that those rules were silly. Of course, different end users have different requirements. It is generally felt by vendors that some/many of the rules for FIPS 140 are silly and unneeded; on the other hand, it is likely that at least a few USGovt customers would really want some of those rules for particular reasons. >Presumably a vendor submitting a product for evaluation believes >that the product is ready, and will pass, otherwise the vendor is >wasting money on the evaluation effort. Wrong, very wrong. You cannot tell what the testing agency might try to knock you down on ahead of time. Of course, you cover what you can, but you also know that there is a good chance they'll just whack you a bit because it makes them look good. >The fact that many products fail evaluation (for good security >reasons), tells me that a vendor's claim that a product "could be >evaluated" is not much of an assurance. If you believe in the testing regime, that's fine. Others don't, and I believe for very good reasons in their own use scenarios. --Paul Hoffman, Director --VPN Consortium _______________________________________________ saag mailing list saag@mit.edu http://mailman.mit.edu/mailman/listinfo/saag From SChokhani@cygnacom.com Tue Feb 19 13:16:27 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1JIGRkf021471 for ; Tue, 19 Feb 2008 13:16:27 -0500 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1JIGHED013637 for ; Tue, 19 Feb 2008 13:16:17 -0500 (EST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by mit.edu (Spam Firewall) with SMTP id D68867913AC for ; Tue, 19 Feb 2008 13:13:08 -0500 (EST) Received: (qmail 3499 invoked from network); 19 Feb 2008 18:05:36 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 19 Feb 2008 18:05:36 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 19 Feb 2008 18:05:36 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 19 Feb 2008 13:13:06 -0500 Message-ID: in-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: AchzIeEnGWfnkW1lSVWs0LiLJakuowAAGwGw References: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks. com> From: "Santosh Chokhani" To: "Paul Hoffman" , "Stephen Kent" X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1JIGRkf021471 X-Mailman-Approved-At: Wed, 20 Feb 2008 10:05:23 -0500 Cc: saag@mit.edu, Randall Atkinson Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 18:16:27 -0000 Paul, These statements are not based on "feelings". They are based on experience of doing third party testing such as TPEP (TCSEC), TTAP (TCSEC and CC), CC testing and FIPS since 1987 and being involved in the FIPS program since its pre-formative days. If there are specific concerns, I would be happy to look into those. My general observation is that vendors do not assign their engineers to these efforts and there is a dearth of qualified testers, resulting in blind leading the blind. If you get a good tester, he/she will force the vendor to provide a good engineering answer and many of the general issues you are mentioning will get tackled right. I would recommend that VPNC members/vendors have good engineers making sound arguments. Most of the times, that works. -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Tuesday, February 19, 2008 1:04 PM To: Santosh Chokhani; Stephen Kent Cc: saag@mit.edu; Randall Atkinson Subject: RE: [saag] Algorithms/modes requested by users/customers At 11:49 AM -0500 2/19/08, Santosh Chokhani wrote: >On the issue of restart, that is misunderstanding on Paul's part. There >is no restart. Ahem. I am reporting what the members of VPNC report to me. They are the vendors in the testing, not me. I have heard this from multiple vendors. If I was not clear that I was reporting what others said, I apologize. >Generally, problem is fixed and you pick up that point. Not to be too picky, but how can you say "generally" without seeing every test that was stopped? Maybe you have not had this problem, but others say they have. >Subjective tests seems to be misunderstanding on Paul's part. Having >been in the Orange Book, CC and FIPS process, I as validator, tester, >and certifier as well as vendor generally rue about rigidness of the >standard and lack of subjective judgment on the part of the tester or >lack of subjective latitude to vendors. If you, as a tester, feel that there are no subjective parts of the test process, that's fine. Some/many people who are being tested disagree with you. >FIPS 140 has specific guidelines on how to deal with minor incremental >changes that helps reduce cost and calendar time. Great! It does not seem to have gotten through to the vendors themselves as "inexpensive enough" or "fast enough". As a tester, you may have a different view. >The standard is NOT a protocol standard. It does verify the algorithm >implementations and thus, FIPS validated algorithms can interoperate. Quite true. >In terms of low end devices, 20-30K for level 1 testing amortized over >devices does not seem too onerous. ...to you. Others disagree, both on the financial cost, and particularly on the cost of elapsed time before customers can use the latest release from a vendor. >I do not understand what Paul refers to as silly modes. The module >being FIPS validated must use FIPS validated or recognized algorithms >for a given crypto service. That seems like a good thing to me. That is a good thing; it is also not what I was talking about. There is disagreement about what needs to be in a "FIPS mode", and whether the shipped product needs to allow "FIPS mode" to be enabled, and if so, how. Again: I am reporting what I hear from many VPNC members over many years. You as a single vendor and/or tester might feel differently; your feeling does not invalidate the views of others. --Paul Hoffman, Director --VPN Consortium From rja@extremenetworks.com Wed Feb 20 10:27:52 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KFRqDS009432 for ; Wed, 20 Feb 2008 10:27:52 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1KFRg3e024056 for ; Wed, 20 Feb 2008 10:27:42 -0500 (EST) Received: from ussc-casht-p1.corp.extremenetworks.com (ussc-casht-p2.extremenetworks.com [207.179.9.62]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 8CDAEFBB7BA for ; Wed, 20 Feb 2008 10:27:21 -0500 (EST) Received: from USEXCHANGE.corp.extremenetworks.com ([172.168.1.2]) by ussc-casht-p1.corp.extremenetworks.com ([172.16.1.201]) with mapi; Wed, 20 Feb 2008 07:27:20 -0800 From: Randall Atkinson To: Peter Gutmann Date: Wed, 20 Feb 2008 07:27:19 -0800 Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: Achzx5t1Z954WaFCTeK7vP5dTSWgTAADDiZ/ Message-ID: <8329C86009B2F24493D76B486146769A9596B14F@USEXCHANGE.corp.extremenetworks.com> References: <20080220131048.55faab0b@cs.columbia.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1KFRqDS009432 Cc: "saag@mit.edu" Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 15:27:52 -0000 Earlier, Peter Gutmann wrote: % Politician's Fallacy again: Is FIPS 140 really the best way to spend your % money? If someone has a better proposal, I am very sure that there is a large audience that would love to hear it. (More on this at bottom) % If FIPS 140 is the answer now, why wasn't the Orange Book % the answer then? You are comparing apples to oranges above. FIPS-140 is only about assurance for cryptographic modules. Orange Book (TCSEC) was only about operating system security. The two address different issues. % What about giving the money to (picking a random name) Cigital and % saying "make sure this code is OK"? One needs a process that is as consistent and reproducible as practical -- no human process could ever be 100% consistent and reprodcible -- otherwise implementers will legitimately complain about a non-level playing field. Or were you proposing to setup a monopoly ? FIPS-140 has multiple certification labs in multiple countries evaluating products -- to avoid creating a monopoly. This HAS driven the evaluation costs downwards over time, and it permits implementers the choice to trade more money for less evaluation time. I don't think anyone has claimed FIPS-140 is perfect. The claims (not by me so much as by other folks on the SAAG list) have been that (1) FIPS-140 is better than other extant security evaluations and that (2) so far no serious alternative proposal that looks reasonably better has appeared. If you think that FIPS-140-* is a target-rich environment, then please try to seriously propose something better. I understand NIST and its partners are looking to evolve into FIPS 140-3 from FIPS 140-2. Have you sent them any concrete suggestions for improvement ? I know the folks at NIST are happy to listen to any serious inputs or proposals. Cheers, Ran From SChokhani@cygnacom.com Wed Feb 20 10:33:12 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KFXBhA011504 for ; Wed, 20 Feb 2008 10:33:11 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1KFX3aG004148 for ; Wed, 20 Feb 2008 10:33:03 -0500 (EST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by mit.edu (Spam Firewall) with SMTP id 374A96D2856 for ; Wed, 20 Feb 2008 10:32:41 -0500 (EST) Received: (qmail 14473 invoked from network); 20 Feb 2008 15:25:07 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 20 Feb 2008 15:25:07 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 20 Feb 2008 15:25:07 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 20 Feb 2008 10:32:39 -0500 Message-ID: in-reply-to: <8329C86009B2F24493D76B486146769A9596B14F@USEXCHANGE.corp.extremenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: Achzx5t1Z954WaFCTeK7vP5dTSWgTAADDiZ/AAB557A= References: <20080220131048.55faab0b@cs.columbia.edu>, <8329C86009B2F24493D76B486146769A9596B14F@USEXCHANGE.corp.extremenetworks.com> From: "Santosh Chokhani" To: "Randall Atkinson" , "Peter Gutmann" X-Spam-Score: 0.14 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1KFXBhA011504 Cc: saag@mit.edu Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 15:33:12 -0000 Orange Book was not about OS security alone. It was successfully applied to network components and DBMS systems also. -----Original Message----- From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of Randall Atkinson Sent: Wednesday, February 20, 2008 10:27 AM To: Peter Gutmann Cc: saag@mit.edu Subject: Re: [saag] Algorithms/modes requested by users/customers Earlier, Peter Gutmann wrote: % Politician's Fallacy again: Is FIPS 140 really the best way to spend your % money? If someone has a better proposal, I am very sure that there is a large audience that would love to hear it. (More on this at bottom) % If FIPS 140 is the answer now, why wasn't the Orange Book % the answer then? You are comparing apples to oranges above. FIPS-140 is only about assurance for cryptographic modules. Orange Book (TCSEC) was only about operating system security. The two address different issues. % What about giving the money to (picking a random name) Cigital and % saying "make sure this code is OK"? One needs a process that is as consistent and reproducible as practical -- no human process could ever be 100% consistent and reprodcible -- otherwise implementers will legitimately complain about a non-level playing field. Or were you proposing to setup a monopoly ? FIPS-140 has multiple certification labs in multiple countries evaluating products -- to avoid creating a monopoly. This HAS driven the evaluation costs downwards over time, and it permits implementers the choice to trade more money for less evaluation time. I don't think anyone has claimed FIPS-140 is perfect. The claims (not by me so much as by other folks on the SAAG list) have been that (1) FIPS-140 is better than other extant security evaluations and that (2) so far no serious alternative proposal that looks reasonably better has appeared. If you think that FIPS-140-* is a target-rich environment, then please try to seriously propose something better. I understand NIST and its partners are looking to evolve into FIPS 140-3 from FIPS 140-2. Have you sent them any concrete suggestions for improvement ? I know the folks at NIST are happy to listen to any serious inputs or proposals. Cheers, Ran _______________________________________________ saag mailing list saag@mit.edu http://mailman.mit.edu/mailman/listinfo/saag From rja@extremenetworks.com Wed Feb 20 10:40:32 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KFeWMw014306 for ; Wed, 20 Feb 2008 10:40:32 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1KFeMYo017807 for ; Wed, 20 Feb 2008 10:40:22 -0500 (EST) Received: from ussc-casht-p2.corp.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 78297CE1F1E for ; Wed, 20 Feb 2008 10:40:01 -0500 (EST) Received: from USEXCHANGE.corp.extremenetworks.com ([172.168.1.2]) by ussc-casht-p2.corp.extremenetworks.com ([10.255.181.88]) with mapi; Wed, 20 Feb 2008 07:40:00 -0800 From: Randall Atkinson To: Santosh Chokhani Date: Wed, 20 Feb 2008 07:39:59 -0800 Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: Achzx5t1Z954WaFCTeK7vP5dTSWgTAADDiZ/AAB557AAAA5/gw== Message-ID: <8329C86009B2F24493D76B486146769A9596B151@USEXCHANGE.corp.extremenetworks.com> References: <20080220131048.55faab0b@cs.columbia.edu>, <8329C86009B2F24493D76B486146769A9596B14F@USEXCHANGE.corp.extremenetworks.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1KFeWMw014306 Cc: "saag@mit.edu" Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 15:40:32 -0000 Earlier, Santosh Chokhani wrote: % Orange Book was not about OS security alone. % % It was successfully applied to network components and DBMS systems also. Santosh, I was using terms precisely, not loosely. The network evaluations were done against Red Book (TNI) published as NCSC TG-005, and not against the Orange Book proper. DBMS evals were done against the Purple Book, published as NCSC TG-021, and not against the Orange Book proper. (I have a full set of colouring books to hand from a previous life. :-) Cheers, Ran From SChokhani@cygnacom.com Wed Feb 20 10:42:04 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KFg4T2014652 for ; Wed, 20 Feb 2008 10:42:04 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1KFftpp020432 for ; Wed, 20 Feb 2008 10:41:55 -0500 (EST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by mit.edu (Spam Firewall) with SMTP id 200D5CC0EF1 for ; Wed, 20 Feb 2008 10:41:35 -0500 (EST) Received: (qmail 14563 invoked from network); 20 Feb 2008 15:34:01 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 20 Feb 2008 15:34:01 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 20 Feb 2008 15:34:01 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 20 Feb 2008 10:41:33 -0500 Message-ID: in-reply-to: <8329C86009B2F24493D76B486146769A9596B151@USEXCHANGE.corp.extremenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: Achzx5t1Z954WaFCTeK7vP5dTSWgTAADDiZ/AAB557AAAA5/gwAAP6Lg References: <20080220131048.55faab0b@cs.columbia.edu>, <8329C86009B2F24493D76B486146769A9596B14F@USEXCHANGE.corp.extremenetworks.com>, <8329C86009B2F24493D76B486146769A9596B151@USEXCHANGE.corp.extremenetworks.com> From: "Santosh Chokhani" To: "Randall Atkinson" X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1KFg4T2014652 Cc: saag@mit.edu Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 15:42:04 -0000 The other books were no more than the interpretations so that we can reuse the standard. Except for TNI Part 2, the source document and requirement for rainbow series is TCSEC. -----Original Message----- From: Randall Atkinson [mailto:rja@extremenetworks.com] Sent: Wednesday, February 20, 2008 10:40 AM To: Santosh Chokhani Cc: saag@mit.edu Subject: RE: [saag] Algorithms/modes requested by users/customers Earlier, Santosh Chokhani wrote: % Orange Book was not about OS security alone. % % It was successfully applied to network components and DBMS systems also. Santosh, I was using terms precisely, not loosely. The network evaluations were done against Red Book (TNI) published as NCSC TG-005, and not against the Orange Book proper. DBMS evals were done against the Purple Book, published as NCSC TG-021, and not against the Orange Book proper. (I have a full set of colouring books to hand from a previous life. :-) Cheers, Ran From rja@extremenetworks.com Wed Feb 20 10:48:18 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KFmIkp016958 for ; Wed, 20 Feb 2008 10:48:18 -0500 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1KFm8o5002132 for ; Wed, 20 Feb 2008 10:48:08 -0500 (EST) Received: from ussc-casht-p1.corp.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 3019D785562 for ; Wed, 20 Feb 2008 10:48:06 -0500 (EST) Received: from USEXCHANGE.corp.extremenetworks.com ([172.168.1.2]) by ussc-casht-p1.corp.extremenetworks.com ([172.16.1.201]) with mapi; Wed, 20 Feb 2008 07:48:05 -0800 From: Randall Atkinson To: Santosh Chokhani Date: Wed, 20 Feb 2008 07:45:13 -0800 Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: Achzx5t1Z954WaFCTeK7vP5dTSWgTAADDiZ/AAB557AAAA5/gwAAP6LgAAAoK1E= Message-ID: <8329C86009B2F24493D76B486146769A9596B153@USEXCHANGE.corp.extremenetworks.com> References: <20080220131048.55faab0b@cs.columbia.edu>, <8329C86009B2F24493D76B486146769A9596B14F@USEXCHANGE.corp.extremenetworks.com>, <8329C86009B2F24493D76B486146769A9596B151@USEXCHANGE.corp.extremenetworks.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1KFmIkp016958 Cc: "saag@mit.edu" Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 15:48:18 -0000 Earlier Santosh wrote: % The other books were no more than the interpretations so that we can % reuse the standard. % % Except for TNI Part 2, the source document and requirement for rainbow % series is TCSEC. So then you do agree with me, Network evals and DBMS evals used the other volumes that I cited, because the Orange book didn't really cover either networking or DBMS topics. I was involved in formal evaluations for the US DoD, while a DoD employee in a prior life, so I've got specific first hand experience with this topic. :-) Cheers, Ran From SChokhani@cygnacom.com Wed Feb 20 10:50:07 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KFo7CI017463 for ; Wed, 20 Feb 2008 10:50:07 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1KFnvWX009342 for ; Wed, 20 Feb 2008 10:49:58 -0500 (EST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by mit.edu (Spam Firewall) with SMTP id 6EF1EFA6312 for ; Wed, 20 Feb 2008 10:49:36 -0500 (EST) Received: (qmail 14626 invoked from network); 20 Feb 2008 15:42:03 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 20 Feb 2008 15:42:03 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 20 Feb 2008 15:42:02 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 20 Feb 2008 10:49:32 -0500 Message-ID: in-reply-to: <8329C86009B2F24493D76B486146769A9596B153@USEXCHANGE.corp.extremenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: Achzx5t1Z954WaFCTeK7vP5dTSWgTAADDiZ/AAB557AAAA5/gwAAP6LgAAAoK1EAAB+LoA== References: <20080220131048.55faab0b@cs.columbia.edu>, <8329C86009B2F24493D76B486146769A9596B14F@USEXCHANGE.corp.extremenetworks.com>, <8329C86009B2F24493D76B486146769A9596B151@USEXCHANGE.corp.extremenetworks.com>, <8329C86009B2F24493D76B486146769A9596B153@USEXCHANGE.corp.extremenetworks.com> From: "Santosh Chokhani" To: "Randall Atkinson" X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1KFo7CI017463 Cc: saag@mit.edu Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 15:50:08 -0000 Folks like me when we had issues, we focused on pragmatics and the TCSEC and not the two interpretations you cite. -----Original Message----- From: Randall Atkinson [mailto:rja@extremenetworks.com] Sent: Wednesday, February 20, 2008 10:45 AM To: Santosh Chokhani Cc: saag@mit.edu Subject: RE: [saag] Algorithms/modes requested by users/customers Earlier Santosh wrote: % The other books were no more than the interpretations so that we can % reuse the standard. % % Except for TNI Part 2, the source document and requirement for rainbow % series is TCSEC. So then you do agree with me, Network evals and DBMS evals used the other volumes that I cited, because the Orange book didn't really cover either networking or DBMS topics. I was involved in formal evaluations for the US DoD, while a DoD employee in a prior life, so I've got specific first hand experience with this topic. :-) Cheers, Ran From jon@callas.org Wed Feb 20 11:54:44 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KGsiJD005324 for ; Wed, 20 Feb 2008 11:54:44 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1KGsY1w015637 for ; Wed, 20 Feb 2008 11:54:34 -0500 (EST) Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by mit.edu (Spam Firewall) with ESMTP id E6230DE6589 for ; Wed, 20 Feb 2008 11:54:06 -0500 (EST) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id C856CCD34EB for ; Wed, 20 Feb 2008 08:54:05 -0800 (PST) Received: from [192.168.5.147] ([12.53.176.4]) by keys.merrymeet.com (PGP Universal service); Wed, 20 Feb 2008 08:54:05 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 20 Feb 2008 08:54:05 -0800 Message-Id: <71651A38-58E5-4575-9E05-E57A728623B0@callas.org> From: Jon Callas To: "Santosh Chokhani" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 20 Feb 2008 08:54:00 -0800 References: <20080220131048.55faab0b@cs.columbia.edu>, <8329C86009B2F24493D76B486146769A9596B14F@USEXCHANGE.corp.extremenetworks.com> X-Mailer: Apple Mail (2.919.2) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Randall Atkinson Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 16:54:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > I don't think anyone has claimed FIPS-140 is perfect. The claims (not > by > me so much as by other folks on the SAAG list) have been that (1) > FIPS-140 > is better than other extant security evaluations and that (2) so far > no serious alternative proposal that looks reasonably better has > appeared. I agree that both of these are true, but these true statements are not inconsistent with the complaints. A system can be the best available, as well as there being no "serious alternative" and still be inadequate. I think this is the true problem. I hope that we're not saying that FIPS 140 is the best of all possible systems. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFHvFstsTedWZOD3gYRArNbAJ4m8Xr8xugA2UAOQ78ONt3Pkzi2QACgv7qR eLBNHoY54jxCur581CX8lgI= =139k -----END PGP SIGNATURE----- From kent@bbn.com Wed Feb 20 17:52:14 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KMqAfK023292 for ; Wed, 20 Feb 2008 17:52:10 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1KMq0Mv013087 for ; Wed, 20 Feb 2008 17:52:00 -0500 (EST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by mit.edu (Spam Firewall) with ESMTP id E26FCC4F75F for ; Wed, 20 Feb 2008 17:51:39 -0500 (EST) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JRxmt-0003lI-3R; Wed, 20 Feb 2008 17:51:39 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 20 Feb 2008 17:51:41 -0500 To: pgut001@cs.auckland.ac.nz (Peter Gutmann) From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, rja@extremenetworks.com, mcgrew@cisco.com Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 22:52:15 -0000 At 12:36 AM +1300 2/21/08, Peter Gutmann wrote: >mcgrew writes: > >>Winston Churchill said that democracy is the worst form of government, except >>for all of the others. I think that the same is true for the FIPS-140 >>cryptomodule validation process ;-) > >I think it's more a case of the Politician's Fallacy: > >1. Something must be done. >2. This is something. >3. This must be done. > >It'd be interesting to see a study of the effectiveness in terms of finding >security and interop problems of: since I and others have pointed out several times that FIPS 140 eval has nothing to do with protocol interoperability, the reference to "interoo" above must be viewed purely within the context of crypto algorithms and modes thereof. > >A. A FIPS 140 eval. > >B. Running the code through Fortify/Coverity/whatever and completing a crypto > exchange with a peer (TLS, S/MIME, PGP, whatever the underlying crypto is > that's being used). > >in particular in terms of return for effort-involved. > >Peter. FIPS 140 encompasses both hardware and software implementations of crypto modules. I see its greatest benefits in the context of the former. The process described above does not address hardware security module eval at all. Steve From mcgrew@cisco.com Thu Feb 21 10:01:10 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1LF19hP016915 for ; Thu, 21 Feb 2008 10:01:09 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1LF0wRc026509 for ; Thu, 21 Feb 2008 10:00:58 -0500 (EST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by mit.edu (Spam Firewall) with ESMTP id 7B36ACD6A31 for ; Thu, 21 Feb 2008 10:00:37 -0500 (EST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 21 Feb 2008 10:00:37 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1LF0be3009783; Thu, 21 Feb 2008 10:00:37 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1LExtVG017362; Thu, 21 Feb 2008 15:00:36 GMT Received: from xmb-rtp-20c.amer.cisco.com ([64.102.31.57]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 10:00:33 -0500 Received: from 10.32.254.210 ([10.32.254.210]) by xmb-rtp-20c.amer.cisco.com ([64.102.31.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 21 Feb 2008 15:00:33 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Thu, 21 Feb 2008 07:00:32 -0800 From: mcgrew To: Peter Gutmann , , Message-ID: Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: Ach0moEcv2aO4uCNEdyLkQAUUQnMFg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Feb 2008 15:00:33.0899 (UTC) FILETIME=[823EABB0:01C8749A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1072; t=1203606037; x=1204470037; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:=20mcgrew=20 |Subject:=20Re=3A=20[saag]=20Algorithms/modes=20requested=2 0by=20users/customers |Sender:=20 |To:=20Peter=20Gutmann=20,=20,=0A=20=20=20=20=20=20=20=20; bh=oc51/+WI0v8ooyb5/ZHcG+BZnkqhVvCKGW+8Kl0DZWY=; b=Gnn9mS5kdms5a3pHl+2KN8WjqVdhgwo2VqT+lYSbCSA7+WMyYPGWqoPw4/ BuIX4Ls8Wezbl99zLeRHgjpGpNwwKYdsargwsKPOHJlOWBqL4hc0x087Hjz/ fdomtcKY9d; Authentication-Results: rtp-dkim-1; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.30 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 15:01:10 -0000 Hi Peter, On 2/20/08 3:36 AM, "Peter Gutmann" wrote: > mcgrew writes: > >> Winston Churchill said that democracy is the worst form of government, except >> for all of the others. I think that the same is true for the FIPS-140 >> cryptomodule validation process ;-) > > I think it's more a case of the Politician's Fallacy: > > 1. Something must be done. > 2. This is something. > 3. This must be done. > I like that. > It'd be interesting to see a study of the effectiveness in terms of finding > security and interop problems of: > > A. A FIPS 140 eval. > > B. Running the code through Fortify/Coverity/whatever and completing a crypto > exchange with a peer (TLS, S/MIME, PGP, whatever the underlying crypto is > that's being used). > > in particular in terms of return for effort-involved. > > Peter. I share you interest in the automation of validation testing; the more that can be automated, the better. It would be great to see more work in this area. David From vishwas.ietf@gmail.com Thu Feb 21 19:59:10 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1M0xAgt017851 for ; Thu, 21 Feb 2008 19:59:10 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1M0x2Z1029949 for ; Thu, 21 Feb 2008 19:59:03 -0500 (EST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mit.edu (Spam Firewall) with ESMTP id 48B17CD653B for ; Thu, 21 Feb 2008 19:59:02 -0500 (EST) Received: by ug-out-1314.google.com with SMTP id e2so1045125ugf.36 for ; Thu, 21 Feb 2008 16:59:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=+ZV8f3svxlezc2j2UlWrCZMKiARSUo9TJxrfDtlpRF8=; b=wmyhVV/koZt7I6VzX7bR73mAWkje9gVW42jnIX9ygvTWTqodywhGodls7Z1BOwZftLzv+AoeCQXq+p9oTOlQzSii4bLSURYG2ih+cfmAnU/PqURx9oLUI24+CDxar/eLRZQdvUPC6KwVW/r3bqK+foEUpwBHoufUxosUDp4wb8Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PEm/8Jp8PP+iw3048gdZTg3mxNd0uRU9n7vjh5rY0KWqw6gfYI1JCbhU3+IHtXTx2LSA597aYua5NzSiMLL6Y2veBAVXJK4VYFEWfGYlwWwIFj9ETHQ3Oz4Ymaogolrn+ZV6NhqXPHZ2E5QZA4RDdnqZKiPyyRd77P9PEhaWiNw= Received: by 10.142.100.1 with SMTP id x1mr8247112wfb.131.1203641940205; Thu, 21 Feb 2008 16:59:00 -0800 (PST) Received: by 10.143.164.14 with HTTP; Thu, 21 Feb 2008 16:59:00 -0800 (PST) Message-ID: <77ead0ec0802211659led5fe3axb7c8a1a27e190c1@mail.gmail.com> Date: Thu, 21 Feb 2008 16:59:00 -0800 From: "Vishwas Manral" To: "Jon Callas" In-Reply-To: <57147A59-BFAE-4F55-AE28-C653EB7475D1@callas.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <57147A59-BFAE-4F55-AE28-C653EB7475D1@callas.org> X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 00:59:10 -0000 Hi Jon, > When PGP first went through FIPS 140, we assigned a dedicated engineer > to the process. Shepherding software through FIPS 140 was so painful, > so mind-numbing, so annoying that he quit the company, quit > cryptography, and quit computer security altogether. He took a job > with a company that produced MP3 music software. That company was > bought out by Apple, and the software turned into what we now know as > iTunes. He is at Apple to this day as the lead of iTunes. > > So the next time you listen to an iPod, think about FIPS 140, and > thank the horrible process. Mind you, iTunes has its own DRM mechanism and that requires cryptography. I have in the past worked on DTCP-IP which is now the content protection mechanism in home devices (after DLNA adopted it) used for content. It uses mechanisms similar to IKE (called AKE) and DTCP (like IPsec). So may be it is not as far away from cryptography as you might assume. Thanks, Vishwas > Jon > > > -----BEGIN PGP SIGNATURE----- > Version: PGP Universal 2.6.3 > Charset: US-ASCII > > wj8DBQFHu2/hsTedWZOD3gYRAuZbAJ9IFEWuafL6fAB+2MxJvwIEOmLJiACgkJrs > eRur6xWa+w6FdH022GobtDg= > =ZTOd > -----END PGP SIGNATURE----- > > > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag > From pgut001@cs.auckland.ac.nz Mon Feb 25 10:44:46 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1PFikTL028438 for ; Mon, 25 Feb 2008 10:44:46 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1PFiUlj020528 for ; Mon, 25 Feb 2008 10:44:35 -0500 (EST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by mit.edu (Spam Firewall) with ESMTP id 4C308DCE69D for ; Mon, 25 Feb 2008 10:44:02 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 38F5C9C418; Tue, 26 Feb 2008 04:44:01 +1300 (NZDT) Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgBA08TEH3sX; Tue, 26 Feb 2008 04:44:01 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D0F779C3FD; Tue, 26 Feb 2008 04:44:00 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 41AED19EC0BE; Tue, 26 Feb 2008 04:44:00 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JTfUm-00089i-3o; Tue, 26 Feb 2008 04:44:00 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, rja@extremenetworks.com In-Reply-To: <8329C86009B2F24493D76B486146769A9596B14F@USEXCHANGE.corp.extremenetworks.com> Message-Id: Sender: pgut001 Date: Tue, 26 Feb 2008 04:44:00 +1300 X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2008 15:44:46 -0000 Randall Atkinson writes: >Earlier, Peter Gutmann wrote: >% If FIPS 140 is the answer now, why wasn't the Orange Book >% the answer then? > >You are comparing apples to oranges above. > >FIPS-140 is only about assurance for cryptographic modules. >Orange Book (TCSEC) was only about operating system security. > >The two address different issues. They certainly seem to be addressing them in very similar ways. >Or were you proposing to setup a monopoly ? Ten years ago the rule-of-thumb estimate for a FIPS 140 level 1 eval was $100K and 6-12 months no matter who you went to. In 2006 (last time I checked) the rule-of-thumb estimate for a FIPS 140 level 1 eval was $100K and 6-12 months no matter who you went to. So it looks like we already have a well- established oligopoly with FIPS 140 evals, the only difference is the nomenclature. >One needs a process that is as consistent and reproducible as practical Why? This is the ISO 9000-for-software fallacy, reproducibility is great when you're cranking out lightbulbs, but not much use for software, which isn't a mass production process but instead is based on the cloning of the result of a one-off development effort which is the product of the creativity, skill, and co-operation of developers and users. I can easily get 100% consistency in reproducing an executable on a CDROM, but I don't think that's what's meant here. >If you think that FIPS-140-* is a target-rich environment, then please try to >seriously propose something better. I understand NIST and its partners are >looking to evolve into FIPS 140-3 from FIPS 140-2. It depends on what you want from FIPS 140 (and I'm talking specifically FIPS 140 for software modules here, which is the form that 99.9% of users encounter it in ). Some people have said you get "assurance", but the assurance you're getting here is a high level of assurance that the vendors were desperate enough for government sales that they shelled out a large amount of money in order to get a ticket to ride the gravy train. The problem is that like "religion" or "morals", "assurance" is a loaded term and can be interpreted to mean almost anything. Without some basic definition of what's meant by "assurance", it's not really possible to reason about this. So here's an attempt to nail it down: For me (and I would guess most end users) assurance is being able to sleep at night knowing there's little chance of anyone compromising my system ("things that should happen do happen, things that shouldn't happen don't happen"). Let's see what FIPS 140 gives you to help you sleep at night. It tests some crypto mechanisms, but ignores others. If you're buying an IPsec product it doesn't test all the mechanisms needed for IPsec. If you're buying a TLS product it doesn't test the mechanisms needed for TLS. If you're buying... well, you get the idea. Compare this to the example I gave earlier of performing a TLS exchange with Amazon. This performs an in-depth test of all the crypto algorithms (corresponding to the FIPS algorithm tests, including ones that FIPS ignores), and the crypto mechanisms (many/most of which FIPS again ignores). In other words simply by connecting to Amazon using TLS and ordering a "Scrubs" DVD for $19.95 I'm getting more comprehensive algorithm testing than I can for a five- figure sum with the FIPS algorithm tests. So what else do you get? You get a bit of a code review and some checking that you don't do stupid things with keys. Only some of the code is reviewed (for example that trivial buffer overflow in the client handshake that allows a remote attacker to do whatever they want with your server, including the FIPS 140-evaluated portion, isn't checked because it's outside the scope of what FIPS 140 is interested in), and (from having gone through several of these) the review itself seems to be more coding style nitpicks than looking for potential exploits, and in any case you can often document away any problems without having to fix them. So the assurance a FIPS 140 eval gets you is a tautological "the product vendor was able to pass a FIPS 140 eval". In terms of being able to demonstrate this type of assurance, I agree completely with you that there is no better mechanism for it than FIPS 140. Admittedly there is some value to FIPS 140: You know that a subset of the crypto used is OK, that the code doesn't do anything stupid with its keys (unless the vendor has documented away the stupid things that do happen, e.g. CryptoAPI's plaintext private-key export, you ask it "Give me the user's private key in plaintext form" and it says "Sure, here you go"), and that it's had a bit of a code check (and obviously if you're doing hardware crypto you get a lot more value than this, but the discussion here is about software modules). What you don't get from FIPS 140 is the stuff that customers really care about: Assurance that your IPsec product can actually do IPsec, that your TLS product can do TLS, or that the product really is secure(-ish). Excusing this by saying that a FIPS 140 crypto product eval doesn't have to check half your crypto so this isn't a problem is like saying that your TSA passenger- screening process is OK even though it doesn't bother checking men with beards or anyone under 5'6" tall. If I'm going to spend $100K to feel safe then I can really think of better ways than FIPS 140 (or CC, or ITSEC, or ...). How about the following comparison: You get to spend the cost of a FIPS 140 eval in one of two ways: $100K: FIPS 140 -- or -- $20K: Fortify (or whatever) scan. $20K: Cigital (or whatever) audit/analysis (these are just representative figures/estimates since there don't seem to be any fixed rates for this sort of thing). $5K: Grant to French university to pen-test code "written at a German university". $5K: Grant to British university to pen-test code "written at a French university". $5K: Set up a fake banking site running the code and bring it to the attention of the Russian Business Network. $free: Leak "security code for Windows 7" to Slashdot. $free: Leak "security code for BluRay++" on warez boards. $free: Leak "Diebold voting machine security code" to Cryptome. $45K: 50" plasma TV, home theatre system, and beer to kill time while you wait for the results to come in (and to emphasise how much cheaper this is than FIPS 140 :-). If your life depended on the security of the product that went through those two processes, which one would you trust? FIPS 140 is just not cost-effective in providing assurance - it costs too much, it takes too long, and it doesn't evaluate the stuff that real users care about having evaluated. >The claims (not by me so much as by other folks on the SAAG list) have been >that (1) FIPS-140 is better than other extant security evaluations Thus showing that the politician's fallacy is alive and well :-). There was a long and extremely interesting discussion on the (somewhat misnamed) open-source list recently, thread topic "How can high assurance FLOSS development be encouraged?". The archives are at http://lists.csl.sri.com/mailman/listinfo/open-source, but you have to sign up to the list in order to access them. Peter. From SChokhani@cygnacom.com Mon Feb 25 12:21:25 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1PHLOGA000940 for ; Mon, 25 Feb 2008 12:21:24 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1PHLAps017642 for ; Mon, 25 Feb 2008 12:21:10 -0500 (EST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by mit.edu (Spam Firewall) with SMTP id AC2136E769A for ; Mon, 25 Feb 2008 12:20:45 -0500 (EST) Received: (qmail 13300 invoked from network); 25 Feb 2008 17:13:05 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 25 Feb 2008 17:13:05 -0000 X-EntrustECS-Action: Trigger(Bad Language) X-EntrustECS-Id: (scygmxsecs1.cygnacom.com)1203959583134231027 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 25 Feb 2008 17:13:03 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 25 Feb 2008 12:20:43 -0500 Message-ID: in-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: Ach3xZ7X0SuZb1t4TBCR8zapsHjpLgADKoSw References: <8329C86009B2F24493D76B486146769A9596B14F@USEXCHANGE.corp.extremenetworks.com> From: "Santosh Chokhani" To: "Peter Gutmann" , X-Spam-Score: 0.42 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1PHLOGA000940 Cc: saag@mit.edu Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2008 17:21:25 -0000 Peter, You are wrong about FIPS 140-1 costs being 100K for Level 1. It is more like 30K. In terms of what FIPS buys is that you ensure that the algorithm is implemented correctly, keys will be generated in accordance with FIPS (meaning that the seed feeding the PRNG will have requisite entropy and PRNG will be FIPS approved). You also get the assurance that the keys are being managed properly in the crypto module. -----Original Message----- From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of Peter Gutmann Sent: Monday, February 25, 2008 10:44 AM To: pgut001@cs.auckland.ac.nz; rja@extremenetworks.com Cc: saag@mit.edu Subject: Re: [saag] Algorithms/modes requested by users/customers Randall Atkinson writes: >Earlier, Peter Gutmann wrote: >% If FIPS 140 is the answer now, why wasn't the Orange Book >% the answer then? > >You are comparing apples to oranges above. > >FIPS-140 is only about assurance for cryptographic modules. >Orange Book (TCSEC) was only about operating system security. > >The two address different issues. They certainly seem to be addressing them in very similar ways. >Or were you proposing to setup a monopoly ? Ten years ago the rule-of-thumb estimate for a FIPS 140 level 1 eval was $100K and 6-12 months no matter who you went to. In 2006 (last time I checked) the rule-of-thumb estimate for a FIPS 140 level 1 eval was $100K and 6-12 months no matter who you went to. So it looks like we already have a well- established oligopoly with FIPS 140 evals, the only difference is the nomenclature. >One needs a process that is as consistent and reproducible as practical Why? This is the ISO 9000-for-software fallacy, reproducibility is great when you're cranking out lightbulbs, but not much use for software, which isn't a mass production process but instead is based on the cloning of the result of a one-off development effort which is the product of the creativity, skill, and co-operation of developers and users. I can easily get 100% consistency in reproducing an executable on a CDROM, but I don't think that's what's meant here. >If you think that FIPS-140-* is a target-rich environment, then please try to >seriously propose something better. I understand NIST and its partners are >looking to evolve into FIPS 140-3 from FIPS 140-2. It depends on what you want from FIPS 140 (and I'm talking specifically FIPS 140 for software modules here, which is the form that 99.9% of users encounter it in ). Some people have said you get "assurance", but the assurance you're getting here is a high level of assurance that the vendors were desperate enough for government sales that they shelled out a large amount of money in order to get a ticket to ride the gravy train. The problem is that like "religion" or "morals", "assurance" is a loaded term and can be interpreted to mean almost anything. Without some basic definition of what's meant by "assurance", it's not really possible to reason about this. So here's an attempt to nail it down: For me (and I would guess most end users) assurance is being able to sleep at night knowing there's little chance of anyone compromising my system ("things that should happen do happen, things that shouldn't happen don't happen"). Let's see what FIPS 140 gives you to help you sleep at night. It tests some crypto mechanisms, but ignores others. If you're buying an IPsec product it doesn't test all the mechanisms needed for IPsec. If you're buying a TLS product it doesn't test the mechanisms needed for TLS. If you're buying... well, you get the idea. Compare this to the example I gave earlier of performing a TLS exchange with Amazon. This performs an in-depth test of all the crypto algorithms (corresponding to the FIPS algorithm tests, including ones that FIPS ignores), and the crypto mechanisms (many/most of which FIPS again ignores). In other words simply by connecting to Amazon using TLS and ordering a "Scrubs" DVD for $19.95 I'm getting more comprehensive algorithm testing than I can for a five- figure sum with the FIPS algorithm tests. So what else do you get? You get a bit of a code review and some checking that you don't do stupid things with keys. Only some of the code is reviewed (for example that trivial buffer overflow in the client handshake that allows a remote attacker to do whatever they want with your server, including the FIPS 140-evaluated portion, isn't checked because it's outside the scope of what FIPS 140 is interested in), and (from having gone through several of these) the review itself seems to be more coding style nitpicks than looking for potential exploits, and in any case you can often document away any problems without having to fix them. So the assurance a FIPS 140 eval gets you is a tautological "the product vendor was able to pass a FIPS 140 eval". In terms of being able to demonstrate this type of assurance, I agree completely with you that there is no better mechanism for it than FIPS 140. Admittedly there is some value to FIPS 140: You know that a subset of the crypto used is OK, that the code doesn't do anything stupid with its keys (unless the vendor has documented away the stupid things that do happen, e.g. CryptoAPI's plaintext private-key export, you ask it "Give me the user's private key in plaintext form" and it says "Sure, here you go"), and that it's had a bit of a code check (and obviously if you're doing hardware crypto you get a lot more value than this, but the discussion here is about software modules). What you don't get from FIPS 140 is the stuff that customers really care about: Assurance that your IPsec product can actually do IPsec, that your TLS product can do TLS, or that the product really is secure(-ish). Excusing this by saying that a FIPS 140 crypto product eval doesn't have to check half your crypto so this isn't a problem is like saying that your TSA passenger- screening process is OK even though it doesn't bother checking men with beards or anyone under 5'6" tall. If I'm going to spend $100K to feel safe then I can really think of better ways than FIPS 140 (or CC, or ITSEC, or ...). How about the following comparison: You get to spend the cost of a FIPS 140 eval in one of two ways: $100K: FIPS 140 -- or -- $20K: Fortify (or whatever) scan. $20K: Cigital (or whatever) audit/analysis (these are just representative figures/estimates since there don't seem to be any fixed rates for this sort of thing). $5K: Grant to French university to pen-test code "written at a German university". $5K: Grant to British university to pen-test code "written at a French university". $5K: Set up a fake banking site running the code and bring it to the attention of the Russian Business Network. $free: Leak "security code for Windows 7" to Slashdot. $free: Leak "security code for BluRay++" on warez boards. $free: Leak "Diebold voting machine security code" to Cryptome. $45K: 50" plasma TV, home theatre system, and beer to kill time while you wait for the results to come in (and to emphasise how much cheaper this is than FIPS 140 :-). If your life depended on the security of the product that went through those two processes, which one would you trust? FIPS 140 is just not cost-effective in providing assurance - it costs too much, it takes too long, and it doesn't evaluate the stuff that real users care about having evaluated. >The claims (not by me so much as by other folks on the SAAG list) have been >that (1) FIPS-140 is better than other extant security evaluations Thus showing that the politician's fallacy is alive and well :-). There was a long and extremely interesting discussion on the (somewhat misnamed) open-source list recently, thread topic "How can high assurance FLOSS development be encouraged?". The archives are at http://lists.csl.sri.com/mailman/listinfo/open-source, but you have to sign up to the list in order to access them. Peter. _______________________________________________ saag mailing list saag@mit.edu http://mailman.mit.edu/mailman/listinfo/saag From pgut001@cs.auckland.ac.nz Tue Feb 26 01:34:34 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1Q6YYsu012546 for ; Tue, 26 Feb 2008 01:34:34 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1Q6YMZc010113 for ; Tue, 26 Feb 2008 01:34:23 -0500 (EST) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by mit.edu (Spam Firewall) with ESMTP id 4B152DF95F7 for ; Tue, 26 Feb 2008 01:34:01 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 3E6EB4804F5; Tue, 26 Feb 2008 19:33:58 +1300 (NZDT) Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAkStm7vxQxC; Tue, 26 Feb 2008 19:33:58 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2459D4803EC; Tue, 26 Feb 2008 19:33:58 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 574CC19EC0F1; Tue, 26 Feb 2008 19:33:57 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JTtO1-00080p-6o; Tue, 26 Feb 2008 19:33:57 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, rja@extremenetworks.com, SChokhani@cygnacom.com In-Reply-To: Message-Id: Sender: pgut001 Date: Tue, 26 Feb 2008 19:33:57 +1300 X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2008 06:34:34 -0000 "Santosh Chokhani" writes: >You are wrong about FIPS 140-1 costs being 100K for Level 1. It is more like >30K. The figures I've been given, from numerous vendors going through numerous labs over a number of years, is that their all-up cost for a level 1 software eval was around $100K (give or take a few tens of $K). This isn't just the final cheque they cut to get the coloured piece of paper, this is the all-up cost of getting their product through a FIPS 140 eval. I realise the following may be a bit unfair since you weren't intending to provide a price quote :-), but I'm willing to put my money where my mouth is: If Cygnacom can get me a FIPS 140 level 1 on my code for an all-up cost of $30K I'll send you a cheque and CDROM of the source within 24 hours (I need to get mgt.approval first). Just let me know where to send it and who to make the payment out to. >In terms of what FIPS buys is that you ensure that the algorithm is >implemented correctly, That a *subset* of the algorithms used are impemented correctly, in other words a subset of what you can get for $19.95 via a TLS connect to Amazon. And the actual crypto mechanisms don't get tested at all. >keys will be generated in accordance with FIPS (meaning that the seed feeding >the PRNG will have requisite entropy and PRNG will be FIPS approved). A nice circular definition: "A FIPS evaluation guarantees that keys will be generated as required in order to pass a FIPS evaluation". >You also get the assurance that the keys are being managed properly in the >crypto module. ... unless the vendor has documented away the mismanagement, e.g. CryptoAPIs plaintext private key export. You're not making a very convincing argument here :-). Peter. From SChokhani@cygnacom.com Tue Feb 26 07:40:12 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1QCeBoA025835 for ; Tue, 26 Feb 2008 07:40:11 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1QCe1Kp017202 for ; Tue, 26 Feb 2008 07:40:02 -0500 (EST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by mit.edu (Spam Firewall) with SMTP id 1F8F4CF336C for ; Tue, 26 Feb 2008 07:39:41 -0500 (EST) Received: (qmail 24703 invoked from network); 26 Feb 2008 12:31:59 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 26 Feb 2008 12:31:59 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 26 Feb 2008 12:31:59 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 26 Feb 2008 07:39:40 -0500 Message-ID: in-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: Ach4QZI6/TYJ7/uKQPmFL6pYftWfCwAMq+Sw References: From: "Santosh Chokhani" To: "pgut001" , X-Spam-Score: 0.30 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1QCeBoA025835 Cc: saag@mit.edu Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2008 12:40:12 -0000 Peter, I do not think this is a forum for negotiations. But, we will be happy to do FIPS testing for your product for Level 1 for quoted price. As to algorithms, all FIPS approved algorithms need to be tested. As to key generation there are standards that come out of NIST and ANSI X9 that IETF also takes its cue from, and FIPS process ensures that the keys are generated in accordance with those standards. Have you yourself participated in a FIPS evaluation or have you looked at the NIST FIPS 140-2 DTR and FIPS 140-2 IG (i.e. Implementation Guidance) available on the Web? -----Original Message----- From: pgut001 [mailto:pgut001@cs.auckland.ac.nz] Sent: Tuesday, February 26, 2008 1:34 AM To: pgut001@cs.auckland.ac.nz; rja@extremenetworks.com; Santosh Chokhani Cc: saag@mit.edu Subject: RE: [saag] Algorithms/modes requested by users/customers "Santosh Chokhani" writes: >You are wrong about FIPS 140-1 costs being 100K for Level 1. It is more like >30K. The figures I've been given, from numerous vendors going through numerous labs over a number of years, is that their all-up cost for a level 1 software eval was around $100K (give or take a few tens of $K). This isn't just the final cheque they cut to get the coloured piece of paper, this is the all-up cost of getting their product through a FIPS 140 eval. I realise the following may be a bit unfair since you weren't intending to provide a price quote :-), but I'm willing to put my money where my mouth is: If Cygnacom can get me a FIPS 140 level 1 on my code for an all-up cost of $30K I'll send you a cheque and CDROM of the source within 24 hours (I need to get mgt.approval first). Just let me know where to send it and who to make the payment out to. >In terms of what FIPS buys is that you ensure that the algorithm is >implemented correctly, That a *subset* of the algorithms used are impemented correctly, in other words a subset of what you can get for $19.95 via a TLS connect to Amazon. And the actual crypto mechanisms don't get tested at all. >keys will be generated in accordance with FIPS (meaning that the seed feeding >the PRNG will have requisite entropy and PRNG will be FIPS approved). A nice circular definition: "A FIPS evaluation guarantees that keys will be generated as required in order to pass a FIPS evaluation". >You also get the assurance that the keys are being managed properly in the >crypto module. ... unless the vendor has documented away the mismanagement, e.g. CryptoAPIs plaintext private key export. You're not making a very convincing argument here :-). Peter. From amamsaad@hotmail.com Sat Feb 23 04:17:21 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1N9HLN7028209 for ; Sat, 23 Feb 2008 04:17:21 -0500 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1N9H95m011867 for ; Sat, 23 Feb 2008 04:17:09 -0500 (EST) Received: from bay0-omc3-s3.bay0.hotmail.com (bay0-omc3-s3.bay0.hotmail.com [65.54.246.203]) by mit.edu (Spam Firewall) with ESMTP id E08AD79EBA1 for ; Sat, 23 Feb 2008 04:17:07 -0500 (EST) Received: from BAY126-W47 ([65.55.131.82]) by bay0-omc3-s3.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 23 Feb 2008 01:17:06 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_3fb6503a-cb93-4732-b6ee-22ccfd01385c_" X-Originating-IP: [62.150.226.151] From: AHMED Abdallah To: Date: Sat, 23 Feb 2008 09:17:06 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 23 Feb 2008 09:17:06.0548 (UTC) FILETIME=[DC21F340:01C875FC] X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Tue, 26 Feb 2008 09:52:38 -0500 Subject: [saag] Manet security group X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2008 09:17:21 -0000 --_3fb6503a-cb93-4732-b6ee-22ccfd01385c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Daer sir, =20 Why i can't find any group for manet security. if there please iform me how= to access it. =20 best regards, =20 Ahmed M. Abdullah =20 _________________________________________________________________ Climb to the top of the charts!=A0Play the word scramble challenge with sta= r power. http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja= n= --_3fb6503a-cb93-4732-b6ee-22ccfd01385c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Daer sir,
 
Why i can't find any group for manet security. if there please iform me how= to access it.
 
best regards,
 
Ahmed M. Abdullah
 

Climb to the top of the charts!=A0Play the word scram= ble challenge with star power. Play now!<= /body> = --_3fb6503a-cb93-4732-b6ee-22ccfd01385c_-- From tim.polk@nist.gov Tue Feb 26 10:01:49 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1QF1m9v008910 for ; Tue, 26 Feb 2008 10:01:49 -0500 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1QF1XXI018892 for ; Tue, 26 Feb 2008 10:01:35 -0500 (EST) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 38A597AB6BD for ; Tue, 26 Feb 2008 10:01:00 -0500 (EST) Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m1QF0uq7005255; Tue, 26 Feb 2008 10:00:56 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tim Polk Date: Tue, 26 Feb 2008 10:01:01 -0500 To: saag@mit.edu X-Mailer: Apple Mail (2.752.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Call for presentation topics X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2008 15:01:49 -0000 Folks, Sam, Pasi, and I are putting together the SAAG agenda for Philadelphia. The agenda traditionally includes one or two invited presentations after the working group reports. We would appreciate submission of presentation topics that you believe would be of interest to the community. If you can identify an appropriate presenter (not necessarily yourself) that would be helpful. Note: If you previously submitted a topic or presentation request, I missed it or it got filtered accidentally. Please resubmit! Thanks, Tim Polk From tim.polk@nist.gov Tue Feb 26 10:52:10 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1QFq9Mn027375 for ; Tue, 26 Feb 2008 10:52:10 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1QFq0VV028053 for ; Tue, 26 Feb 2008 10:52:00 -0500 (EST) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 21DECDEBF5F; Tue, 26 Feb 2008 10:51:38 -0500 (EST) Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m1QFpVps021585; Tue, 26 Feb 2008 10:51:31 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <454FA23D-9DC9-4F2B-BD69-53181E998178@nist.gov> Content-Transfer-Encoding: 7bit From: Tim Polk Date: Tue, 26 Feb 2008 10:51:36 -0500 To: saag@mit.edu X-Mailer: Apple Mail (2.752.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov X-Spam-Score: 3.5 X-Spam-Level: *** (3.5) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: Sam Hartman Subject: Re: [saag] Call for presentation topics, again... X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2008 15:52:10 -0000 One final note - please direct your presentation topics to Pasi, Sam, and I. Unfortunately, I forgot to CC them on the last message, so a reply would only go to me... On Feb 26, 2008, at 10:01 AM, Tim Polk wrote: > Folks, > > Sam, Pasi, and I are putting together the SAAG agenda for > Philadelphia. > > The agenda traditionally includes one or two invited presentations > after the > working group reports. We would appreciate submission of > presentation topics > that you believe would be of interest to the community. > > If you can identify an appropriate presenter (not necessarily > yourself) that would > be helpful. > > Note: If you previously submitted a topic or presentation request, > I missed it or it > got filtered accidentally. Please resubmit! > > Thanks, > > Tim Polk From kent@bbn.com Tue Feb 26 21:10:31 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1R2AQxJ016576 for ; Tue, 26 Feb 2008 21:10:26 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1R2AGLS001954 for ; Tue, 26 Feb 2008 21:10:16 -0500 (EST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by mit.edu (Spam Firewall) with ESMTP id 2BC75F96588 for ; Tue, 26 Feb 2008 21:09:55 -0500 (EST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[169.223.13.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JUBjz-00068K-4J; Tue, 26 Feb 2008 21:09:54 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 26 Feb 2008 21:09:51 -0500 To: pgut001@cs.auckland.ac.nz (Peter Gutmann) From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, rja@extremenetworks.com Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 02:10:31 -0000 At 4:44 AM +1300 2/26/08, Peter Gutmann wrote: >... > >Ten years ago the rule-of-thumb estimate for a FIPS 140 level 1 eval was $100K >and 6-12 months no matter who you went to. In 2006 (last time I checked) the >rule-of-thumb estimate for a FIPS 140 level 1 eval was $100K and 6-12 months >no matter who you went to. So it looks like we already have a well- >established oligopoly with FIPS 140 evals, the only difference is the >nomenclature. BBN developed the first crypto module evaluated at level 3 under FIPS 140-1. The fee we paid to the eval lab was about $40K, and the elapsed time was about 6 months. That was more than ten years ago, but we're also talking about a much more thorough eval. The cost to a developer is, of course, higher, when you add in the time required to prepare the necessary documentation. Also, if the developer is not experienced in secure development practices, the likelihood increases that the eval will not go smoothly, and thus the costs will be higher. Maybe what you're reporting is the result of more developers, with less experience secure crypto module development experience submitting products that are "not quite ready." ... > >If you think that FIPS-140-* is a target-rich environment, then >please try to >>seriously propose something better. I understand NIST and its partners are >>looking to evolve into FIPS 140-3 from FIPS 140-2. > >It depends on what you want from FIPS 140 (and I'm talking specifically FIPS >140 for software modules here, which is the form that 99.9% of users encounter >it in ). Some people have said you get "assurance", but the assurance you're >getting here is a high level of assurance that the vendors were desperate >enough for government sales that they shelled out a large amount of money in >order to get a ticket to ride the gravy train. Sotware modules are easier for a developer to create and submit, and this too may cause more submissions that are less well thought out. If you're building hardware there may be more of an effort to "get it right" in the planning stages, because the costs of redesign are potentially higher. >The problem is that like "religion" or "morals", "assurance" is a loaded term >and can be interpreted to mean almost anything. Without some basic definition >of what's meant by "assurance", it's not really possible to reason about this. >So here's an attempt to nail it down: For me (and I would guess most end >users) assurance is being able to sleep at night knowing there's little chance >of anyone compromising my system ("things that should happen do happen, things >that shouldn't happen don't happen"). Assurance (in the security context) is not as squishy a term as your suggest. Security assurance is generally characterized as confidence that an implementation meet certain objective security-relevant criteria. These are not interoperability criteria. It is distinguished from security functionality, which refers to the set of functions (features) ascribed to a product (without confidence that these features operate as promised). >Let's see what FIPS 140 gives you to help you sleep at night. It tests some >crypto mechanisms, but ignores others. If you're buying an IPsec product it >doesn't test all the mechanisms needed for IPsec. If you're buying a TLS >product it doesn't test the mechanisms needed for TLS. If you're buying... >well, you get the idea. For a protocol such as TLS or IPsec, crypto module security assurance does not encompass most aspects of what a users sees as "correct" operation. It makes sense to look for both functionality testing and security assurance evaluation, if you care about both functionality and security. >Compare this to the example I gave earlier of performing a TLS exchange with >Amazon. This performs an in-depth test of all the crypto algorithms >(corresponding to the FIPS algorithm tests, including ones that FIPS ignores), >and the crypto mechanisms (many/most of which FIPS again ignores). In other >words simply by connecting to Amazon using TLS and ordering a "Scrubs" DVD for >$19.95 I'm getting more comprehensive algorithm testing than I can for a five- >figure sum with the FIPS algorithm tests. nonsense! what you get is confidence that the SSL/TLS implementation at Amazon and in your browser work compatibly, even if both happen to be "wrong." In fact, the test you propose checks only a small subset of the SSL/TLS spec, as it verifies only that the RSA key transport method of key management works, none of the other key management methods defined by the RFCs. So, maybe what you meant to say was that the proposed test regimen verifies that a protocol and associated crypto work compatibility with an implementation of the most common subset of the crypto modes and protocol features deployed. That's a useful finding, but let's not confuse it with protocol standard conformance or security assurance. I won't bother to respond to the rest of your observations, since they repeat many of the themes I touched upon above. It is silly to ask FIPS 140 to address protocol interop issues; that is simply not in scope for a generic crypto security eval criteria. So let's forgo all the arguments along those lines. Vendor claims about security sometimes (often?) prove to be wrong. Thus is makes sense to seek external, independent assurances about security, if you care. The fact that FIPS 140 addresses only a subset of those claims is also not a basis for criticizing a generic crypto module evaluation criteria like FIPS 140. Common Criteria eval of products is more encompassing, but also MUCH more expensive. So, IF one cares about crypto security, THEN FIPS 140 eval is the best option for now. That does not make it ideal, but it also does not make it as bad as some comments have suggested, and it is unfair to criticize it for not doing something that it has never promised to do. Steve From pgut001@cs.auckland.ac.nz Thu Mar 6 00:38:15 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m265cEpW027642 for ; Thu, 6 Mar 2008 00:38:15 -0500 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m265c360012830 for ; Thu, 6 Mar 2008 00:38:03 -0500 (EST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by mit.edu (Spam Firewall) with ESMTP id 00D917E7152 for ; Thu, 6 Mar 2008 00:38:01 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 01C9F9C693; Thu, 6 Mar 2008 18:38:00 +1300 (NZDT) Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBfO28U-kvwx; Thu, 6 Mar 2008 18:37:59 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 5D4019C68A; Thu, 6 Mar 2008 18:37:58 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 0221419EC0B8; Thu, 6 Mar 2008 18:37:58 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JX8nl-0005nH-Rl; Thu, 06 Mar 2008 18:37:57 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, rja@extremenetworks.com, SChokhani@cygnacom.com In-Reply-To: Message-Id: Sender: pgut001 Date: Thu, 06 Mar 2008 18:37:57 +1300 X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 05:38:15 -0000 "Santosh Chokhani" writes: >I do not think this is a forum for negotiations. Absolutely, that's why I pointed out that I wasn't taking it as a price quote, more to make a point. >But, we will be happy to do FIPS testing for your product for Level 1 for >quoted price. > >As to algorithms, all FIPS approved algorithms need to be tested. And there's the rub, it's not just handing over $30K and getting back a coloured certificate, you need to get the algorithms certified, prepare a ton of paperwork, spend a considerable amount of time on this, and that's where the $100K all-up figure comes from. If I could simply hand over $30K and the source code *with no further effort or expense on my behalf* I'd jump at the chance. Just to show that I'm not trying to pick on Cygnacom here I'll make this an open offer to anyone: If I can hand you $30K and a copy of my source code and you can get me a FIPS 140 cert for it without me incurring any additional effort or expense, please get in touch. >Have you yourself participated in a FIPS evaluation or have you looked at the >NIST FIPS 140-2 DTR and FIPS 140-2 IG (i.e. Implementation Guidance) >available on the Web? Probably about half a dozen directly (+/- one or two, I haven't kept an exact tally), and been involved indirectly in about a dozen more via discussions with (and listening to complaining about :-) others going through the process. (Again, YMMV, I haven't kept an exact tally on the latter, and in some cases it was nothing more than "what did you guys do to get past ...?", and sympathising with them over problems). Peter. From ben@links.org Thu Mar 6 04:43:45 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m269hfQ4010831 for ; Thu, 6 Mar 2008 04:43:41 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m269hTKh019524 for ; Thu, 6 Mar 2008 04:43:29 -0500 (EST) Received: from mail.links.org (mail.links.org [217.155.92.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 7BC2BFDF416 for ; Thu, 6 Mar 2008 04:43:05 -0500 (EST) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id C480233C1C; Thu, 6 Mar 2008 09:42:42 +0000 (GMT) Message-ID: <47CFBC99.3000608@links.org> Date: Thu, 06 Mar 2008 09:42:49 +0000 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, rja@extremenetworks.com, mcgrew@cisco.com Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 09:43:45 -0000 Peter Gutmann wrote: > mcgrew writes: > >> Winston Churchill said that democracy is the worst form of government, except >> for all of the others. I think that the same is true for the FIPS-140 >> cryptomodule validation process ;-) > > I think it's more a case of the Politician's Fallacy: > > 1. Something must be done. > 2. This is something. > 3. This must be done. > > It'd be interesting to see a study of the effectiveness in terms of finding > security and interop problems of: > > A. A FIPS 140 eval. > > B. Running the code through Fortify/Coverity/whatever and completing a crypto > exchange with a peer (TLS, S/MIME, PGP, whatever the underlying crypto is > that's being used). > > in particular in terms of return for effort-involved. Having done both of these, I can give you an impromptu answer, and also comment on some other themes I've seen on this thread. The background here is I did most of the initial work for the FIPS-140 eval of OpenSSL. I also have access to Coverity runs over OpenSSL. There's no doubt that Coverity gives far more return on effort. It actually found problems. FIPS-140 did not (though it did create some, see below). Coverity took only a few days of investment. FIPS-140 took months (and years of elapsed time). Other themes... Silly modes: FIPS-140 doesn't introduce silly modes that are available to client s/w, but it does introduce some really quite complex silliness for the tests, involving repeated encryption of a block, extracting some of the output and using it to create new keys and data for more repeated encryptions. Getting those right was really very painful - and, as far as I can see, no more useful than standard test vectors. Fixed input to PRNGs: someone observed that this is worrisome from a security point of view. The fact that OpenSSL got certified and yet had a huge security hole because it accidentally left the PRNG seeded from the self-test supports this concern (http://openssl.org/news/secadv_20071129.txt). Weak PRNGs: no-one mentioned this, I don't think, but one of the things that bugged me most was having to replace OpenSSL's PRNG with a much weaker one, as required by FIPS-140. Enforced security holes: again, not mentioned, but one of the problems with PRNGs under Unix is that after a fork, both copies will produce the same randomness. OpenSSL protects against this by detecting a fork and mixing in different stuff in the two processes. I replicated this behaviour for FIPS-140 and was forced to remove it. The result is that if you use FIPS-140 mode and you fork, if you don't reseed the PRNG yourself, you have made a big mistake. Cost: Peter Gutmann points out that the total cost of an eval vastly exceeds the cost of the testing lab. He's right. There's a huge amount of paperwork and pointless code to write. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From SChokhani@cygnacom.com Thu Mar 6 07:26:57 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m26CQuC0027798 for ; Thu, 6 Mar 2008 07:26:56 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m26CQmYi000046 for ; Thu, 6 Mar 2008 07:26:48 -0500 (EST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by mit.edu (Spam Firewall) with SMTP id 2AF64FFDE10 for ; Thu, 6 Mar 2008 07:26:25 -0500 (EST) Received: (qmail 5619 invoked from network); 6 Mar 2008 12:18:31 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 06 Mar 2008 12:18:31 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 6 Mar 2008 12:18:31 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 6 Mar 2008 07:26:24 -0500 Message-ID: in-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: Ach/TD54DSqCiVDLSG+vCOidUOjT/wAOMVEA References: From: "Santosh Chokhani" To: "pgut001" , X-Spam-Score: 0.30 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m26CQuC0027798 Cc: saag@mit.edu Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 12:26:57 -0000 Most of the standards are based on the assumption that you have some software development processes in place and thus will have documentation on the architecture and design of the product and not just the source code. One would think that you would also done some testing based on the knowledge of the design, interfaces and source code. -----Original Message----- From: pgut001 [mailto:pgut001@cs.auckland.ac.nz] Sent: Thursday, March 06, 2008 12:38 AM To: pgut001@cs.auckland.ac.nz; rja@extremenetworks.com; Santosh Chokhani Cc: saag@mit.edu Subject: RE: [saag] Algorithms/modes requested by users/customers "Santosh Chokhani" writes: >I do not think this is a forum for negotiations. Absolutely, that's why I pointed out that I wasn't taking it as a price quote, more to make a point. >But, we will be happy to do FIPS testing for your product for Level 1 for >quoted price. > >As to algorithms, all FIPS approved algorithms need to be tested. And there's the rub, it's not just handing over $30K and getting back a coloured certificate, you need to get the algorithms certified, prepare a ton of paperwork, spend a considerable amount of time on this, and that's where the $100K all-up figure comes from. If I could simply hand over $30K and the source code *with no further effort or expense on my behalf* I'd jump at the chance. Just to show that I'm not trying to pick on Cygnacom here I'll make this an open offer to anyone: If I can hand you $30K and a copy of my source code and you can get me a FIPS 140 cert for it without me incurring any additional effort or expense, please get in touch. >Have you yourself participated in a FIPS evaluation or have you looked at the >NIST FIPS 140-2 DTR and FIPS 140-2 IG (i.e. Implementation Guidance) >available on the Web? Probably about half a dozen directly (+/- one or two, I haven't kept an exact tally), and been involved indirectly in about a dozen more via discussions with (and listening to complaining about :-) others going through the process. (Again, YMMV, I haven't kept an exact tally on the latter, and in some cases it was nothing more than "what did you guys do to get past ...?", and sympathising with them over problems). Peter. From SChokhani@cygnacom.com Thu Mar 6 09:16:14 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m26EGAxS020310 for ; Thu, 6 Mar 2008 09:16:10 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m26EFvZk016572 for ; Thu, 6 Mar 2008 09:15:58 -0500 (EST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by mit.edu (Spam Firewall) with SMTP id DBD46D22525 for ; Thu, 6 Mar 2008 09:15:26 -0500 (EST) Received: (qmail 6324 invoked from network); 6 Mar 2008 14:07:32 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 06 Mar 2008 14:07:32 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 6 Mar 2008 14:07:31 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 6 Mar 2008 09:15:24 -0500 Message-ID: in-reply-to: <47CFBC99.3000608@links.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: Ach/b+RUBDjQzHyhRzG3UZKk+fm1NQAI1zpQ References: <47CFBC99.3000608@links.org> From: "Santosh Chokhani" To: "Ben Laurie" , "Peter Gutmann" X-Spam-Score: 0.14 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m26EGAxS020310 Cc: saag@mit.edu, rja@extremenetworks.com, mcgrew@cisco.com Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 14:16:15 -0000 Ben, 1. In terms of Coverity, it complements what FIPS does. Coverity is a good tool for looking at code complexity and possible soft spots. Note that FIPS scrutiny is not very deep. It does not even perform full functional or interface testing. It is more akin to demonstration testing at EAL 2 for Common Criteria. For Common Criteria, for vulnerability analysis and testing, we do recommend that the developers use automated tools for static code analysis and test coverage analysis. 2. On the PRNG, I see FIPS having some cogent requirements. The basic requirements are that the entropy of the seed by commensurate with the entropy for the key being generated and the seed be pseudo randomized. I have myself worked with the developer to successfully obtain NIST approval when the PRNG algorithm has varied from FIPS approved methods. 3. I do not know what happened in your case. A wild stab is that may be the you were going for level 1 only for the operating environment also and multi-threading was not permitted. That is not an excuse. I do not know enough to suggest how U would handle this. 4. As to extra code, I do not know what you are specifically concerned with. I have for about 8-9 years unsuccessfully advocated to NIST to do away with self-tests. They were meaningful in old days of truly hardware crypto. Now, most hardware crypto is on some generic processor, and POST for the processor are sufficient as opposed to crypto specific tests. -----Original Message----- From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of Ben Laurie Sent: Thursday, March 06, 2008 4:43 AM To: Peter Gutmann Cc: saag@mit.edu; rja@extremenetworks.com; mcgrew@cisco.com Subject: Re: [saag] Algorithms/modes requested by users/customers Peter Gutmann wrote: > mcgrew writes: > >> Winston Churchill said that democracy is the worst form of government, except >> for all of the others. I think that the same is true for the FIPS-140 >> cryptomodule validation process ;-) > > I think it's more a case of the Politician's Fallacy: > > 1. Something must be done. > 2. This is something. > 3. This must be done. > > It'd be interesting to see a study of the effectiveness in terms of finding > security and interop problems of: > > A. A FIPS 140 eval. > > B. Running the code through Fortify/Coverity/whatever and completing a crypto > exchange with a peer (TLS, S/MIME, PGP, whatever the underlying crypto is > that's being used). > > in particular in terms of return for effort-involved. Having done both of these, I can give you an impromptu answer, and also comment on some other themes I've seen on this thread. The background here is I did most of the initial work for the FIPS-140 eval of OpenSSL. I also have access to Coverity runs over OpenSSL. There's no doubt that Coverity gives far more return on effort. It actually found problems. FIPS-140 did not (though it did create some, see below). Coverity took only a few days of investment. FIPS-140 took months (and years of elapsed time). Other themes... Silly modes: FIPS-140 doesn't introduce silly modes that are available to client s/w, but it does introduce some really quite complex silliness for the tests, involving repeated encryption of a block, extracting some of the output and using it to create new keys and data for more repeated encryptions. Getting those right was really very painful - and, as far as I can see, no more useful than standard test vectors. Fixed input to PRNGs: someone observed that this is worrisome from a security point of view. The fact that OpenSSL got certified and yet had a huge security hole because it accidentally left the PRNG seeded from the self-test supports this concern (http://openssl.org/news/secadv_20071129.txt). Weak PRNGs: no-one mentioned this, I don't think, but one of the things that bugged me most was having to replace OpenSSL's PRNG with a much weaker one, as required by FIPS-140. Enforced security holes: again, not mentioned, but one of the problems with PRNGs under Unix is that after a fork, both copies will produce the same randomness. OpenSSL protects against this by detecting a fork and mixing in different stuff in the two processes. I replicated this behaviour for FIPS-140 and was forced to remove it. The result is that if you use FIPS-140 mode and you fork, if you don't reseed the PRNG yourself, you have made a big mistake. Cost: Peter Gutmann points out that the total cost of an eval vastly exceeds the cost of the testing lab. He's right. There's a huge amount of paperwork and pointless code to write. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff _______________________________________________ saag mailing list saag@mit.edu http://mailman.mit.edu/mailman/listinfo/saag From ravi.gami@ennovatetech.com Thu Mar 6 07:56:55 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m26CuomK006388 for ; Thu, 6 Mar 2008 07:56:55 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m26Cuhw2004766 for ; Thu, 6 Mar 2008 07:56:43 -0500 (EST) Received: from ahmedabad.einfochips.com (india.einfochips.com [203.88.139.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 2490CE11DB8 for ; Thu, 6 Mar 2008 07:56:21 -0500 (EST) Received: (qmail 1418 invoked by uid 118); 6 Mar 2008 12:52:09 -0000 Received: from 10.101.1.136 by ahm (envelope-from , uid 112) with qmail-scanner-1.25st (clamdscan: 0.91.2/6143. spamassassin: 3.1.7-deb. altermime: ???. perlscan: 1.25st. Clear:RC:1(10.101.1.136):. Processed in 0.019263 secs); 06 Mar 2008 12:52:09 -0000 Received: from unknown (HELO Ravi) (ravi.gami@ennovatetech.com@[10.101.1.136]) (envelope-sender ) by ahmedabad.einfochips.com (qmail-ldap-1.03) with SMTP for ; 6 Mar 2008 12:52:09 -0000 Message-ID: <001001c87f89$78a53840$8801650a@Ravi> From: "Gami Ravi" To: Date: Thu, 6 Mar 2008 18:26:18 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C87FB7.921F80E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 5.51 X-Spam-Level: ***** (5.51) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Thu, 06 Mar 2008 10:12:29 -0500 Subject: [saag] How security is maintained by IANA X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 12:56:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C87FB7.921F80E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I want to register multicast IP address.I want to know that once i = register multicast IP address can any other use that IP to send data on = that IP? How security is implemented for that ? Thanks & Regards, Ravi Gami. -- eInfochips Business Disclaimer: This message may contain confidential, proprietary or legally Privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose,distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated.Nothing contained in this message shall be construed as an offer or acceptance of any offer by eInfochips Limited and/or eInfochips Inc(“eInfochips”) unless sent with that express intent and with due authority of eInfochips.EInfochips has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. ------=_NextPart_000_000D_01C87FB7.921F80E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
    I want to register = multicast IP=20 address.I want to know that once i register multicast IP address can any = other=20 use that IP to send data on that IP? How security is implemented for = that=20 ?
 
 
Thanks & Regards,
Ravi Gami.

-- 
eInfochips Business Disclaimer:
 
This message may contain confidential, proprietary or legally Privileged
information. In case you are not the original intended Recipient of the
message, you must not, directly or indirectly, use, Disclose,distribute,
print, or copy any part of this message and you are requested to delete
it and inform the sender. Any views expressed in this message are those
of the individual sender unless otherwise stated.Nothing contained in
this message shall be construed as an offer or acceptance of any offer
by eInfochips Limited and/or eInfochips Inc(“eInfochips”) unless sent
with that express intent and with due authority of eInfochips.EInfochips
has taken enough precautions to prevent the spread of viruses. However
the company accepts no liability for any damage caused by any virus
transmitted by this email.

------=_NextPart_000_000D_01C87FB7.921F80E0-- From ekr@networkresonance.com Mon Mar 10 19:33:41 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2ANXfIl026578 for ; Mon, 10 Mar 2008 19:33:41 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m2ANXS0M022779 for ; Mon, 10 Mar 2008 19:33:29 -0400 (EDT) Received: from kilo.rtfm.com (unknown [130.129.87.199]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id D4B3E77EE71 for ; Mon, 10 Mar 2008 19:33:04 -0400 (EDT) Received: from dhcp-1679.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 47E9B1AA4C7; Mon, 10 Mar 2008 19:33:04 -0400 (EDT) Date: Mon, 10 Mar 2008 19:33:04 -0400 From: Eric Rescorla To: tcpm@ietf.org User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080310233304.47E9B1AA4C7@kilo.rtfm.com> X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: [saag] Comments on draft-ietf-tcpm-tcp-auth-opt-00 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2008 23:33:41 -0000 I started writing comments on this and after I'd spent about 2 hours writing background material, I decided to cram it into an I-D. Until it appears on the I-D directory, you can find it at: https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tcp-auth-arch.txt Anyway, review follows: $Id: draft-ietf-tcpm-tcp-auth-opt-00-rev.txt,v 1.2 2008/03/10 23:11:21 ekr Exp $ GENERAL COMMENTS I'm not convinced it's necessary to have a new key for each connection. This is primarily useful to prevent inter-connection cut-and-paste attacks, and it's not clear how serious those are. I think it's particularly problematic to levy this requirement without providing some mechanism for arranging that, since that basically implies having some automatic mechanism for establishing fresh per-connection keys, which doesn't currently exist. That makes this mechanism distinctly less useful than RFC 2385. I don't think this API, specification of the TSAD, etc., is particularly helpful. IPsec needed the concept of an association database because packets corresponding to multiple associations got similar treatment. However, TCP has an explicit notion of connection so it would be far more convenient to simply refer to keys as tied to connections, and then have a set of rules for mapping which connections get which keys. Even if some TSAD-type abstraction is useful, I don't think it's appropriate to define things like the size of each parameter in the TSAD as opposed to on the wire, or to describe the default values of various parameters as in S 3. For instance: iii. Key length. A byte indicating the length of the connection key in bytes. Those are internal implementation issues. Certainly, I might want to use a native int in my implementation. Why should this document tell me otherwise? TECHNICAL COMMENTS S 1.1. I don't see a lot of value in pre-specifying two MAC algorithms as MTI. There's no reason to believe one isn't plenty, as used in other protocols. S 2.2. This thing with the key-id being present if the MAC is odd, but absent if it's even strikes me as being overly clever. Let's just burn an octet on key-id and leave it at that. S 3. >> At least one direction (inbound/outbound) SHOULD have a non-NONE MAC in practice, but this MUST NOT be strictly required by an implementation. 1. This seems like a bad idea. It's very hard to analyze the security properties of a connection when only one side is protected. To take one case that is obviously bad, if you're worried about DoS attacks and you use TCP-AO, then forging packets in either direction can bring it down. I would reverse this and require MACs in both directions. 2. Even if we stipulate that this might be an OK idea, it's not appropriate to require implementations to support it. S 4.1. >> New TSAD entries MUST be checked against a table of previously used TSAD entries, and key reuse MUST be prohibited. Huh? So, I have to keep a list of every TSAD entry ever and check against the table. Seems better to just to do this by construction. S 4.3. >> TCP segments with TCP-AO but not matching TSAD entries MUST be silently accepted; this is required for equivalent function with TCPs not implementing TCP-AO. I don't see this. Can you explain? >> Silent discard events SHOULD be signaled to the user as a warning, and silent accept events MAY be signaled to the user as a warning. I don't really understand what a warning means here? syslog? S 5. Implementations are encouraged to keep keys in a suitably private area. Users of TCP-AO are encouraged to use different keys for inbound and outbound MACs on a given TCP connection. Some discussion of why different keys are good or bad would help here. As far as I can tell, reflection attacks aren't an issue as long as the host/port quartet is incuded in the header. S 5.1. o Number of bytes to be sent/received (two bytes); this is used on the send side to trigger bytecount-based KeyID changes, and on the receive side only for statistics or length-sensitive KeyID selection. Please explain the cryptographic rationale for why you would want to do bytecount based key changes. S 9. TCP-AO does not expose the MAC algorithm used to authenticate a particular connection; that information is kept in the TSAD at the endpoints, and is not indicated in the header. This seems to be of extremely marginal security benefit. There are likely to be <5 algorithms in use. So, searching all of them increases the effective key size by <3 bits. EDITORIAL COMMENTS S 1. there have been escalating attacks on the algorithm itself [Be05] [Bu06]. TCP MD5 also lacks both key management and algorithm These citations should be to the original papers, not the summaries (not that I mind you citing Steve's and my paper...) o S 2.2. Figure 2 is kind of hard to read since the length of the kind field is 16 bits, but kinds are 8 bits, rigth? S 3. Note that the connection key is not included here; we expect that the MAC algorithm will indicate how to use the key, e.g., as HMACs do in s/HMACs do/HMAC does/ TCP-AO by default includes the TCP options because these options are intended to be end-to-end and some are required for proper TCP operation (e.g., SACK, timestamp, large windows). Middleboxes that I dpn't understand what "by default" means here. This needs to be configured on both sides, right? So, this is just a UI issue. S 5. the default case. Segments carry only enough context to identify the security association [RFC4301][RFC4306]. In TCP-AO, this context is I'm not sure what security association means here. You're not using IKE, right? S 9. TCP-AO does not expose the MAC algorithm used to authenticate a particular connection; that information is kept in the TSAD at the endpoints, and is not indicated in the header. I may not be enough of a TCP wonk, but what's a connection ID? -Ekr From touch@ISI.EDU Mon Mar 10 21:31:36 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2B1VaWF005482 for ; Mon, 10 Mar 2008 21:31:36 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m2B1VNYY010731 for ; Mon, 10 Mar 2008 21:31:24 -0400 (EDT) X-ASG-Whitelist: Client Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 9D1C8752794 for ; Mon, 10 Mar 2008 21:31:23 -0400 (EDT) Received: from [127.0.0.1] ([63.133.180.130]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m2B1UlLU015902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Mar 2008 18:30:50 -0700 (PDT) Message-ID: <47D5E09A.5000803@isi.edu> Date: Mon, 10 Mar 2008 18:30:02 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Eric Rescorla , IETF Security Area WG , tcpm@ietf.org X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig591A580DD43B812CE3076EB4" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] discussion of draft-rescorla-tcp-auth-arch-00.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2008 01:31:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig591A580DD43B812CE3076EB4 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Eric, Again, thanks for the detailed comments. Discussion below... This too should be useful to discuss further in TCPM. Joe > Network Working Group E. Rescorl= a > Internet-Draft RTFM, Inc= =2E > Intended status: Informational March 09, 200= 8 > Expires: September 10, 2008 >=20 >=20 > Notes on TCP Authentication Architectures > draft-rescorla-tcp-auth-arch-00.txt =2E.. > 1. Introduction =2E.. > Note that there is currently two documents > [I-D.ietf-tcpm-tcp-auth-opt] [I-D.bellovin-tcpsec] that discuss > additional requirements, but it's not clear to me that these > requirements have consensus or in fact are correct. The documents were presented at the last IETF, where we solicited=20 comments on those requirements. The requirements were presented as=20 having the consensus of the TCP-AO design team only at that time. =2E.. > 3. Keys and Associations >=20 > Probably the most important architectural question is the > relationship of keys to associations. As indicated above, TCP MD5 > uses a single static key for all associations. This key is > configured in a pairwise fashion. By contrast, conventional channel= > security protocols such as TLS [RFC4346] or IPsec [RFC4301] establis= h > a fresh set of keying material for each association. The proposed > TCP Authentication Option [I-D.ietf-tcpm-tcp-auth-opt] also requires= > (though does not arrange for) a fresh key for each association. TCP-AO is identical to IPsec [i.e., 4301] in that regard; neither=20 arranges for keys, and both rely on a separate protocol to do so, in the = sense that IPsec relies on IKE. > >> New TSAD entries MUST be checked against a table of previously= > used TSAD entries, and key reuse MUST be prohibited. >=20 > There are two good (and one not so good) reasons why it's desirable > to have mechanisms for changing keys: Changing keys is not related to the above key reuse issue AFAICT. Key changes are to reduce the amount of material signed under a single=20 key, to reduce the utility of signed packets to a cryptoanalyst. Key reuse is critical to preventing replay attacks within a connection=20 ID (src IP, dst IP, src port, dst port, aka socket pair). It is useful=20 to avoid keying different ports or even different hosts with the same=20 key, but only in a general sense (i.e., to again reduce the amount of=20 material signed with a single key). > o To arrange for different cryptographic keying material to be used= > for each connection, thus preventing cut-and-paste attacks betwee= n > connections. (Good) Those don't seem relevant; the ports change, so the signatures would chan= ge. > o To allow rekeying in case of key compromise. (Good) Rekeying of a connection is not necessarily related to rekeying an=20 endpoint. Connection key compromise is not something we're designing to=20 address per se. > o To limit the amount of plaintext/MAC pairs available to the > attacker (Not-so-good) Is that the 'amount of keyed material' kind of stuff above? That was=20 given by Bellovin as an issue with TCP-MD5. > In TCP, cut-and-paste attacks are also possible within a connection > due to sequence number rollover. This can be fixed, however, by > extending the sequence numbers virtually, as done with ESP/AH. We definitely do not want to tie the keying directly to the sequence=20 space for a variety of reasons (we listed some, I believe); this is done = indirectly by bytecounts or packet counts to trigger key changes. > 4. Credentials Interface >=20 > As described at the beginning of this document, essentially all the > currently deployed systems use a single pre-configured pairwise > shared key. This key is directly configured on the router interface= =2E > For instance, here's the example from Cisco's IOS manuals [REF: htt= p > ://www.cisco.com/en/US/docs/ios/12_0/np1/configuration/guide/ > 1cbgp.html#wp5978] >=20 > router bgp 109 neighbor 145.2.2.2 password v61ne0qkel33& >=20 > It's extremely desirable to be able to retain the existing > interfaces. Any solution which requires a significant change to > those interfaces and especially to the interaction model creates a > substantial additional burden on operators, which creates a major > barrier to deployment. That would be allowed if the key management system used a single master=20 endpoint key, and derived connection keys from that key. I.e., if this=20 is critical to BGP, then BGP will require TCP-AO and a specific key=20 management protocol. Again, this isn't different from saying "IPsec with = IKE" at the IP layer, except that we are intending that TCP-AO and its=20 key management system are simpler to implement (partly because they're=20 specific to a single transport protocol). > 5. Handshake and Capabilities Discovery >=20 > The ability to automatically discover a peer's capabilitiies is a > common feature of modern cryptographic protocols. \ Like IPsec, we rely on the key management protocol to perform this. This = is not a part of TCP-AO as a result. > 6. Potential Architectures >=20 > This section describes a number of potential architectures for key > management for TCP. I'll skip them here, excepting ones that affect TCP-AO: > 6.2.1. Internal Key Management Protocol >=20 > The traditional approach to this problem would be to build a KMP int= o > TCP. This would presumably entail designing a new crypto protocol > (no small job) which is then carried in a TCP option. TCP option space is already consumed by a number of commonly used=20 options, and we want to retain space for additional options where=20 possible. Space is most limited in the SYN packet, which is where the=20 initial key exchange would occur. Because there isn't enough TCP option space for this sort of solution,=20 we excluded it as a possibility. =2E.. > 6.2.3. Layered KMP >=20 > Another way to provide a separate KMP is to bind it more tightly to > the transport protocol by running it over (or next to, as in DTLS- > SRTP [I-D.ietf-avt-dtls-srtp]) the transport protocol. At the time > that the association is created, the application initiating the > association also initiates a KMP exchange over (next to) the > transport protocol. When the KMP terminates, it outputs keying and > parameter information and imposes them on the association. In the > case of TLS over TCP, this would look something like: >=20 > TCP Client TCP Server > ---------- ---------- > TCP SYN -------------------------------------> > <---------------------------------- TCP SYN/ACK > TCP ACK -------------------------------------> > <--------- TLS Handshake (over TCP) ------> > Keys to TCP Keys to TCP= > App data (protected with TCP integrity) -----> > <----- App data (protected with TCP integrity) This fails to protect the SYN exchange, which we consider a requirement. = It also changes state from non-keyed to keyed; it would be very=20 difficult to introduce that sort of stateful change inside the TCP=20 protocol in ways that affect the data stream, since no other options=20 have that kind of effect (i.e., of affecting all data after some point). --- --------------enig591A580DD43B812CE3076EB4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH1eCaE5f5cImnZrsRAtqKAKCkOpSWIcSR0yqtvqyNSEeif5nIPACgl5// grdeJWN5biUgovCo/MKyD00= =7rmx -----END PGP SIGNATURE----- --------------enig591A580DD43B812CE3076EB4-- From touch@ISI.EDU Mon Mar 10 21:31:40 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2B1VeYd005498 for ; Mon, 10 Mar 2008 21:31:40 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m2B1VRTh010768 for ; Mon, 10 Mar 2008 21:31:27 -0400 (EDT) X-ASG-Whitelist: Client Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id B472EE2965F for ; Mon, 10 Mar 2008 21:31:26 -0400 (EDT) Received: from [127.0.0.1] ([63.133.180.130]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m2B1UdSR015862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Mar 2008 18:30:42 -0700 (PDT) Message-ID: <47D5E090.9010608@isi.edu> Date: Mon, 10 Mar 2008 18:29:52 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Eric Rescorla References: <20080310233304.47E9B1AA4C7@kilo.rtfm.com> In-Reply-To: <20080310233304.47E9B1AA4C7@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE118A070FCD485B77E83166F" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, tcpm@ietf.org Subject: Re: [saag] [tcpm] Comments on draft-ietf-tcpm-tcp-auth-opt-00 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2008 01:31:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE118A070FCD485B77E83166F Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Eric, Thanks for the detailed comments. Some responses based on the text below. I'll comment on the ID separately... Also, I would expect that most of these issues would be useful to=20 discuss further in TCPM if you're available. Otherwise, we could meet=20 separately... Joe Eric Rescorla wrote: > I started writing comments on this and after I'd spent about=20 > 2 hours writing background material, I decided to cram it=20 > into an I-D. Until it appears on the I-D directory, you > can find it at: >=20 > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tcp-auth= -arch.txt >=20 > Anyway, review follows: >=20 > $Id: draft-ietf-tcpm-tcp-auth-opt-00-rev.txt,v 1.2 2008/03/10 23:11:21 = ekr Exp $ >=20 > GENERAL COMMENTS > I'm not convinced it's necessary to have a new key for each > connection. This is primarily useful to prevent inter-connection > cut-and-paste attacks, and it's not clear how serious those > are.=20 It's there primarily to prevent packets from an old version of a=20 connection from being used on a new connection, i.e., replay attacks=20 between a connection and its successor using the same port pair. I.e., IMO it's a MUST within a port pair for some period of time (the=20 cache check), and a SHOULD (for general security reasons) between port=20 pairs. The SHOULD can be dropped if (IMO) SAAG doesn't consider reusing=20 keys for different datasets an issue. > I think it's particularly problematic to levy this > requirement without providing some mechanism for arranging > that, since that basically implies having some automatic > mechanism for establishing fresh per-connection keys, which > doesn't currently exist. That makes this mechanism distinctly > less useful than RFC 2385. It does imply that for systems that re-establish connections frequently=20 either a a fresh key generation system is available, or a fairly long=20 list is preloaded. > I don't think this API, specification of the TSAD, etc., is > particularly helpful. IPsec needed the concept of an association > database because packets corresponding to multiple associations > got similar treatment. However, TCP has an explicit notion > of connection so it would be far more convenient to simply > refer to keys as tied to connections, and then have a set > of rules for mapping which connections get which keys. That's exactly what the TSAD is (or at least is supposed to be). It=20 might be useful to discuss this offline to figure out what the=20 disconnect is... > Even if some TSAD-type abstraction is useful, I don't think > it's appropriate to define things like the size of each > parameter in the TSAD as opposed to on the wire,=20 The TSAD API needs to be specified in detail because the key management=20 solution needs to rely on that information. > or to > describe the default values of various parameters as in > S 3. For instance: > > iii. Key length. A byte indicating the length of the=20 > connection key in bytes. =20 >=20 > Those are internal implementation issues. Certainly, I might > want to use a native int in my implementation. Why should > this document tell me otherwise? Again, it's to allow another party - the key management solution - to=20 load the TSAD. > TECHNICAL COMMENTS > S 1.1. > I don't see a lot of value in pre-specifying two MAC algorithms > as MTI. There's no reason to believe one isn't plenty, as used > in other protocols. >=20 > S 2.2. > This thing with the key-id being present if the MAC is odd, > but absent if it's even strikes me as being overly clever. > Let's just burn an octet on key-id and leave it at that. That would be discussed in TCPM further. The primary utility is for=20 short connections where the key isn't expected to need to rollover, and=20 where TCP option bytes are in extreme scarcity, esp. because single byte = can end up adding 4 overall, due to alignment issues. If that's not useful, we can decide to make the key-id always present. > S 3. > >> At least one direction (inbound/outbound) SHOULD have= =20 > a non-NONE MAC in practice, but this MUST NOT be strictl= y=20 > required by an implementation. =20 >=20 > 1. This seems like a bad idea. It's very hard to analyze the security > properties of a connection when only one side is protected. To take > one case that is obviously bad, if you're worried about DoS attacks > and you use TCP-AO, then forging packets in either direction can > bring it down. I would reverse this and require MACs in both directions= =2E For BGP, this is important. For servers, it's not necessarily feasible - = clients may authenticate the server, but the converse may not=20 necessarily be true. Yes, this allows attacks in one direction to=20 succeed, but it also isn't clear that both directions are equally=20 vulnerable, is it? > 2. Even if we stipulate that this might be an OK idea, it's not > appropriate to require implementations to support it. I'm not sure I understand this; if we say that connections MAY have=20 unidirectional auth, then it seems like the implementation MUST support=20 that capability. > S 4.1. > >> New TSAD entries MUST be checked against a table of previously=20 > used TSAD entries, and key reuse MUST be prohibited.=20 >=20 > Huh? So, I have to keep a list of every TSAD entry ever and check > against the table. Seems better to just to do this by construction. I'm not sure what "by construction" means, but that's certainly better=20 if possible. Can you suggest text or explain this off-line? > S 4.3. > >> TCP segments with TCP-AO but not matching TSAD entries MUST be=20 > silently accepted; this is required for equivalent function with TCP= s=20 > not implementing TCP-AO. =20 >=20 > I don't see this. Can you explain? TCP-AO is just a signature. If you don't have enough information to=20 invalidate the signature, you don't have enough reason to drop a segment.= The expected use case is that an endsystem will authenticate only a=20 subset of its connections; for those connections, it would install keys=20 - even if random ones - to "lock" those ports down. It's simpler to do=20 that than to lock everything by default and open things up explictly,=20 IMO, but we can default in either direction if necessary. Consider the case of a system that does not implement TCP-AO. TCP=20 ignores options it doesn't understand, so the connection will work fine. = Now you install TCP-AO, but don't load any keys. The intent is that an=20 un-keyed connection is the same as TCP without TCP-AO. > >> Silent discard events SHOULD be signaled to the user as a warning= ,=20 > and silent accept events MAY be signaled to the user as a warning.=20 >=20 > I don't really understand what a warning means here? syslog? That's one way. Others accumulate the info in a variable that apps can=20 check, e.g., via the socket interface. > S 5. > Implementations are encouraged to keep keys in a suitably private=20 > area. Users of TCP-AO are encouraged to use different keys for=20 > inbound and outbound MACs on a given TCP connection.=20 >=20 > Some discussion of why different keys are good or bad would help > here. As far as I can tell, reflection attacks aren't an issue > as long as the host/port quartet is incuded in the header. Sure. The goal is the general one of avoiding rekeying symmetric data=20 with the same key. It's not based on a specific kind of attack. > S 5.1. > o Number of bytes to be sent/received (two bytes); this is used on = > the send side to trigger bytecount-based KeyID changes, and on th= e=20 > receive side only for statistics or length-sensitive KeyID=20 > selection.=20 >=20 > Please explain the cryptographic rationale for why you would want to > do bytecount based key changes. That part of the API is strawman; we expect to need to count either=20 messages or bytes or both. If message counts are more useful, then we=20 can change to that. > S 9. > TCP-AO does not expose the MAC algorithm used to authenticate a=20 > particular connection; that information is kept in the TSAD at the=20 > endpoints, and is not indicated in the header.=20 >=20 > This seems to be of extremely marginal security benefit. There > are likely to be <5 algorithms in use. So, searching all of them > increases the effective key size by <3 bits.=20 The other reason to not include it is space; it's not needed, since it's = effectively bound to the active key anyway. > EDITORIAL COMMENTS Fixed separately.... Joe --------------enigE118A070FCD485B77E83166F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH1eCQE5f5cImnZrsRAllHAKDo/WvgfbrU52AMgJ5ohFwOINKvYgCg5x0u EHY8Tv0u6qWefoMybdZ95wk= =1QMC -----END PGP SIGNATURE----- --------------enigE118A070FCD485B77E83166F-- From ekr@networkresonance.com Tue Mar 11 07:52:49 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2BBqmVf025552 for ; Tue, 11 Mar 2008 07:52:48 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2BBqdEw000811 for ; Tue, 11 Mar 2008 07:52:39 -0400 (EDT) Received: from kilo.rtfm.com (dhcp-11ec.ietf71.ietf.org [130.129.17.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 9C138E2F407 for ; Tue, 11 Mar 2008 07:52:18 -0400 (EDT) Received: from dhcp-1679.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id A85891AB2B9; Tue, 11 Mar 2008 07:52:20 -0400 (EDT) Date: Tue, 11 Mar 2008 07:52:20 -0400 From: Eric Rescorla To: Joe Touch In-Reply-To: <47D5E09A.5000803@isi.edu> References: <47D5E09A.5000803@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080311115220.A85891AB2B9@kilo.rtfm.com> X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: IETF Security Area WG , tcpm@ietf.org Subject: Re: [saag] discussion of draft-rescorla-tcp-auth-arch-00.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2008 11:52:49 -0000 At Mon, 10 Mar 2008 18:30:02 -0700, Joe Touch wrote: > > Network Working Group E. Rescorla > > Internet-Draft RTFM, Inc. > > Intended status: Informational March 09, 2008 > > Expires: September 10, 2008 > > > > > > Notes on TCP Authentication Architectures > > draft-rescorla-tcp-auth-arch-00.txt > ... > > 1. Introduction > ... > > Note that there is currently two documents > > [I-D.ietf-tcpm-tcp-auth-opt] [I-D.bellovin-tcpsec] that discuss > > additional requirements, but it's not clear to me that these > > requirements have consensus or in fact are correct. > > The documents were presented at the last IETF, where we solicited > comments on those requirements. The requirements were presented as > having the consensus of the TCP-AO design team only at that time. Sure. I was just trying to say that I wasn't taken them as a given for the purposes of this document. > > 3. Keys and Associations > > > > Probably the most important architectural question is the > > relationship of keys to associations. As indicated above, TCP MD5 > > uses a single static key for all associations. This key is > > configured in a pairwise fashion. By contrast, conventional channel > > security protocols such as TLS [RFC4346] or IPsec [RFC4301] establish > > a fresh set of keying material for each association. The proposed > > TCP Authentication Option [I-D.ietf-tcpm-tcp-auth-opt] also requires > > (though does not arrange for) a fresh key for each association. > > TCP-AO is identical to IPsec [i.e., 4301] in that regard; neither > arranges for keys, and both rely on a separate protocol to do so, in the > sense that IPsec relies on IKE. It's similar to IPsec but not identical, in that IPsec's notion of an association spans multiple TCP connections. > > >> New TSAD entries MUST be checked against a table of previously > > used TSAD entries, and key reuse MUST be prohibited. > > > > There are two good (and one not so good) reasons why it's desirable > > to have mechanisms for changing keys: > > Changing keys is not related to the above key reuse issue AFAICT. Well, part of my point in this section is to distinguish these cases in which one might or might not wish to use different keys at different times. > Key changes are to reduce the amount of material signed under a single > key, to reduce the utility of signed packets to a cryptoanalyst. As I indicate in S 3.3, while this is certainly crypto lore for symmetric ciphers, I am unaware of any evidence that having large (but practical) numbers of plaintext/ciphertext pairs is of any significant value in attacking modern algorithms. > Key reuse is critical to preventing replay attacks within a connection > ID (src IP, dst IP, src port, dst port, aka socket pair). It is useful > to avoid keying different ports or even different hosts with the same > key, but only in a general sense (i.e., to again reduce the amount of > material signed with a single key). I'm not sure which issue you're referring to here by "within a socket pair". - With a single connection. - Between connections which happen to share parameters by coincidence. As I indicate in S 3.1, there's no replay issue in the first case except for TCP sequence number rollover, which can be fixed by using extended sequence numbers. The relevant issue is the second case, again discussed in S 3.1, but it's not clear to me how important this actually is. > > o To arrange for different cryptographic keying material to be used > > for each connection, thus preventing cut-and-paste attacks between > > connections. (Good) > > Those don't seem relevant; the ports change, so the signatures would change. Yes, I'm talking about the second of the two issues above. > > o To limit the amount of plaintext/MAC pairs available to the > > attacker (Not-so-good) > > Is that the 'amount of keyed material' kind of stuff above? That was > given by Bellovin as an issue with TCP-MD5. Yes, presumably. As I say, I'm unaware of any cryptographic issue here. > > In TCP, cut-and-paste attacks are also possible within a connection > > due to sequence number rollover. This can be fixed, however, by > > extending the sequence numbers virtually, as done with ESP/AH. > > We definitely do not want to tie the keying directly to the sequence > space for a variety of reasons (we listed some, I believe); this is done > indirectly by bytecounts or packet counts to trigger key changes. The only mention of sequence number in your draft is in S 9: Value (ICV). In TCP-AO, the socket pair performs most of the function of IPsec's SPI, and IPsec's Sequence Number, used to avoid replay attacks, isn't needed due to TCP's Sequence Number, which is used to reorder received segments. Unfortunately, it is not useful to validate TCP's Sequence Number before performing a TCP-AO authentication calculation, because many out-of-window segments still cause TCP protocol actions (e.g., ACK retransmission) [RFC793]. It is similarly not useful to add a separate Sequence Number field to the TCP-AO option, because doing so could cause a change in TCP's behavior even when segments are valid. But this is not what I'm talking about. I'm merely talking about using the ISNs as a diversifier for the per-connection key. Could you elaborate more on issues with this. > > 6.2.1. Internal Key Management Protocol > > > > The traditional approach to this problem would be to build a KMP into > > TCP. This would presumably entail designing a new crypto protocol > > (no small job) which is then carried in a TCP option. > > TCP option space is already consumed by a number of commonly used > options, and we want to retain space for additional options where > possible. Space is most limited in the SYN packet, which is where the > initial key exchange would occur. > > Because there isn't enough TCP option space for this sort of solution, > we excluded it as a possibility. I tend to agree that this is not that attractive an alternative. > > 6.2.3. Layered KMP > > > > Another way to provide a separate KMP is to bind it more tightly to > > the transport protocol by running it over (or next to, as in DTLS- > > SRTP [I-D.ietf-avt-dtls-srtp]) the transport protocol. At the time > > that the association is created, the application initiating the > > association also initiates a KMP exchange over (next to) the > > transport protocol. When the KMP terminates, it outputs keying and > > parameter information and imposes them on the association. In the > > case of TLS over TCP, this would look something like: > > > > TCP Client TCP Server > > ---------- ---------- > > TCP SYN -------------------------------------> > > <---------------------------------- TCP SYN/ACK > > TCP ACK -------------------------------------> > > <--------- TLS Handshake (over TCP) ------> > > Keys to TCP Keys to TCP > > App data (protected with TCP integrity) -----> > > <----- App data (protected with TCP integrity) > > This fails to protect the SYN exchange, which we consider a requirement. I certainly agree that it does not protect the SYN. I noted it as the second major disadvantage. As for whether this is a requirement, I think that's deserving of some discussion. > It also changes state from non-keyed to keyed; it would be very > difficult to introduce that sort of stateful change inside the TCP > protocol in ways that affect the data stream, since no other options > have that kind of effect (i.e., of affecting all data after some point). I'm no expert on TCP options and I'm certainly prepared to believe that no other options have this effect, but I'm not sure I see the issue here as to why this is a problem. The sides can simply place the option in the segment keyed with some null key and algorithm (e.g., all zero MAC) and then start processing when the key is set. As I recall, a similar algorithm is used in SCTP-AUTH. -Ekr From ekr@networkresonance.com Tue Mar 11 07:54:27 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2BBsRDl026403 for ; Tue, 11 Mar 2008 07:54:27 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2BBsI1N004420 for ; Tue, 11 Mar 2008 07:54:18 -0400 (EDT) Received: from kilo.rtfm.com (dhcp-11ec.ietf71.ietf.org [130.129.17.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 9812C1008D01 for ; Tue, 11 Mar 2008 07:53:54 -0400 (EDT) Received: from dhcp-1679.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 17B5F1AB2D2; Tue, 11 Mar 2008 07:53:57 -0400 (EDT) Date: Tue, 11 Mar 2008 07:53:57 -0400 From: Eric Rescorla To: Joe Touch In-Reply-To: <47D5E090.9010608@isi.edu> References: <20080310233304.47E9B1AA4C7@kilo.rtfm.com> <47D5E090.9010608@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080311115357.17B5F1AB2D2@kilo.rtfm.com> X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, tcpm@ietf.org Subject: Re: [saag] [tcpm] Comments on draft-ietf-tcpm-tcp-auth-opt-00 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2008 11:54:28 -0000 At Mon, 10 Mar 2008 18:29:52 -0700, Joe Touch wrote: > Also, I would expect that most of these issues would be useful to > discuss further in TCPM if you're available. Otherwise, we could meet > separately... I do plan to try to attend TCPM. > > GENERAL COMMENTS > > I'm not convinced it's necessary to have a new key for each > > connection. This is primarily useful to prevent inter-connection > > cut-and-paste attacks, and it's not clear how serious those > > are. > > It's there primarily to prevent packets from an old version of a > connection from being used on a new connection, i.e., replay attacks > between a connection and its successor using the same port pair. Right, that's what I mean by "inter-connection cut and paste attacks". I'd like to see some analysis of how serious they are. > > I think it's particularly problematic to levy this > > requirement without providing some mechanism for arranging > > that, since that basically implies having some automatic > > mechanism for establishing fresh per-connection keys, which > > doesn't currently exist. That makes this mechanism distinctly > > less useful than RFC 2385. > > It does imply that for systems that re-establish connections frequently > either a a fresh key generation system is available, or a fairly long > list is preloaded. Right, so absent the definition of such a mechanism, this is less useful than 2385. > > I don't think this API, specification of the TSAD, etc., is > > particularly helpful. IPsec needed the concept of an association > > database because packets corresponding to multiple associations > > got similar treatment. However, TCP has an explicit notion > > of connection so it would be far more convenient to simply > > refer to keys as tied to connections, and then have a set > > of rules for mapping which connections get which keys. > > That's exactly what the TSAD is (or at least is supposed to be). It > might be useful to discuss this offline to figure out what the > disconnect is... Perhaps. I think expressing it as a database isn't particularly helpful. There are structures associated with the connection and it's most useful (IMO) to think of this data as attached to them, just as (for instance) the current window or sequence number is. > > Even if some TSAD-type abstraction is useful, I don't think > > it's appropriate to define things like the size of each > > parameter in the TSAD as opposed to on the wire, > > The TSAD API needs to be specified in detail because the key management > solution needs to rely on that information. > > > or to > > describe the default values of various parameters as in > > S 3. For instance: > > > > iii. Key length. A byte indicating the length of the > > connection key in bytes. > > > > Those are internal implementation issues. Certainly, I might > > want to use a native int in my implementation. Why should > > this document tell me otherwise? > > Again, it's to allow another party - the key management solution - to > load the TSAD. I really don't see this. The other party presumably has some set of API calls/IPC/whatever, that it talks to. It's not our job to specify the interface between those to, other than the contents of the elements. > > S 3. > > >> At least one direction (inbound/outbound) SHOULD have > > a non-NONE MAC in practice, but this MUST NOT be strictly > > required by an implementation. > > > > 1. This seems like a bad idea. It's very hard to analyze the security > > properties of a connection when only one side is protected. To take > > one case that is obviously bad, if you're worried about DoS attacks > > and you use TCP-AO, then forging packets in either direction can > > bring it down. I would reverse this and require MACs in both directions. > > For BGP, this is important. For servers, it's not necessarily feasible - > clients may authenticate the server, but the converse may not > necessarily be true. I don't see why it's not feasible. They share a key, so there's no reason not to have mutual auth. > Yes, this allows attacks in one direction to > succeed, but it also isn't clear that both directions are equally > vulnerable, is it? I don't see this. The relevant attack here is to bring down the connection. An RST in either direction will accomplish that. Thus, ISTM that packets need to be authenticated in both directions. > > 2. Even if we stipulate that this might be an OK idea, it's not > > appropriate to require implementations to support it. > > I'm not sure I understand this; if we say that connections MAY have > unidirectional auth, then it seems like the implementation MUST support > that capability. I don't see that that's true. For instance, TLS stacks MAY support RC4, but we don't require them to support RC4. > > S 4.1. > > >> New TSAD entries MUST be checked against a table of previously > > used TSAD entries, and key reuse MUST be prohibited. > > > > Huh? So, I have to keep a list of every TSAD entry ever and check > > against the table. Seems better to just to do this by construction. > > I'm not sure what "by construction" means, but that's certainly better > if possible. Can you suggest text or explain this off-line? I mean that if you randomly generate keys for the TSAD with an appropriate algorithm then there is no reasonable chance that there will be a collision. > > S 5.1. > > o Number of bytes to be sent/received (two bytes); this is used on > > the send side to trigger bytecount-based KeyID changes, and on the > > receive side only for statistics or length-sensitive KeyID > > selection. > > > > Please explain the cryptographic rationale for why you would want to > > do bytecount based key changes. > > That part of the API is strawman; we expect to need to count either > messages or bytes or both. If message counts are more useful, then we > can change to that. I don't see that you need to count either. > > S 9. > > TCP-AO does not expose the MAC algorithm used to authenticate a > > particular connection; that information is kept in the TSAD at the > > endpoints, and is not indicated in the header. > > > > This seems to be of extremely marginal security benefit. There > > are likely to be <5 algorithms in use. So, searching all of them > > increases the effective key size by <3 bits. > > The other reason to not include it is space; it's not needed, since it's > effectively bound to the active key anyway. That's totally reasonable. I'm not saying it has to be included, just that I don't see not including it as a significant security benefit. -Ekr From touch@ISI.EDU Tue Mar 11 08:23:02 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2BCN0Zc024513 for ; Tue, 11 Mar 2008 08:23:00 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2BCMpp8007542 for ; Tue, 11 Mar 2008 08:22:51 -0400 (EDT) X-ASG-Whitelist: Client Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 66A9076787B for ; Tue, 11 Mar 2008 08:22:51 -0400 (EDT) Received: from [127.0.0.1] ([63.133.180.130]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m2BCISgC014611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Mar 2008 05:18:29 -0700 (PDT) Message-ID: <47D6784B.3030107@isi.edu> Date: Tue, 11 Mar 2008 05:17:15 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Eric Rescorla References: <47D5E09A.5000803@isi.edu> <20080311115220.A85891AB2B9@kilo.rtfm.com> In-Reply-To: <20080311115220.A85891AB2B9@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEB93B1C241DC34622A0B2F1D" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: IETF Security Area WG , tcpm@ietf.org Subject: Re: [saag] discussion of draft-rescorla-tcp-auth-arch-00.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2008 12:23:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEB93B1C241DC34622A0B2F1D Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Eric Rescorla wrote: =2E.. >>> 3. Keys and Associations >>> >>> Probably the most important architectural question is the >>> relationship of keys to associations. As indicated above, TCP MD5= >>> uses a single static key for all associations. This key is >>> configured in a pairwise fashion. By contrast, conventional chann= el >>> security protocols such as TLS [RFC4346] or IPsec [RFC4301] establ= ish >>> a fresh set of keying material for each association. The proposed= >>> TCP Authentication Option [I-D.ietf-tcpm-tcp-auth-opt] also requir= es >>> (though does not arrange for) a fresh key for each association. >> >> TCP-AO is identical to IPsec [i.e., 4301] in that regard; neither=20 >> arranges for keys, and both rely on a separate protocol to do so, in t= he=20 >> sense that IPsec relies on IKE. >=20 > It's similar to IPsec but not identical, in that IPsec's notion of an > association spans multiple TCP connections. There are numerous differences, however, regarding the statement "does=20 not arrange for) a fresh key for each association", they are identical IM= O. >>> >> New TSAD entries MUST be checked against a table of previous= ly >>> used TSAD entries, and key reuse MUST be prohibited. >>> >>> There are two good (and one not so good) reasons why it's desirabl= e >>> to have mechanisms for changing keys: >> >> Changing keys is not related to the above key reuse issue AFAICT. >=20 > Well, part of my point in this section is to distinguish these > cases in which one might or might not wish to use different > keys at different times. Agreed. Unless your doc is intended to be longer term, it's not an issue.= >> Key changes are to reduce the amount of material signed under a single= =20 >> key, to reduce the utility of signed packets to a cryptoanalyst. >=20 > As I indicate in S 3.3, while this is certainly crypto lore for > symmetric ciphers, I am unaware of any evidence that having > large (but practical) numbers of plaintext/ciphertext pairs=20 > is of any significant value in attacking modern algorithms. That lore is expressed in RFC3562,and implied in RFC4107 in the phrase=20 "short term" key. We'd be glad to be advised otherwise; if so, then: - we could note that the key-ID would be used only for deliberate key changes, e.g., due to compromise, or to avoid a key rollover replay attack note: this is also why we need a byte/segment counter; when it hits 2^32, we MUST change keys or there is a clear replay attack - we could ignore the reuse of keys across different connections within the same machine, though we'd still want to avoid reuse within a connection ID due to replay attacks >> Key reuse is critical to preventing replay attacks within a connection= =20 >> ID (src IP, dst IP, src port, dst port, aka socket pair). It is useful= =20 >> to avoid keying different ports or even different hosts with the same = >> key, but only in a general sense (i.e., to again reduce the amount of = >> material signed with a single key). >=20 > I'm not sure which issue you're referring to here by "within a socket > pair". It's defined in RFC793 as [srcIP, dstIP, srcport, dstport]; it defines a = TCP connection, and noted as such in sec 3 of the tcp-auth I-D. > - With a single connection. > - Between connections which happen to share parameters by coincidence. >=20 > As I indicate in S 3.1, there's no replay issue in the first case > except for TCP sequence number rollover, which can be fixed by > using extended sequence numbers.=20 TCP does not have extended sequence numbers. Adding that=20 cross-connection information, and including it in every tcp-opt header,=20 was explored but is decided against for numerous reasons. > The relevant issue is the > second case, again discussed in S 3.1, but it's not clear to > me how important this actually is. That's why we believe it's sufficient to address this at the TSAD,=20 requiring keys to change when connections end and new ones start with=20 the same port numbers. That can be accomplished in various ways, e.g., by= : - forcing a TSAD key change - keeping a cache of previous TSAD keys for that connection etc. The first one above might be sufficient - and simple to implement - if=20 this is not a severe concern. =2E.. >>> In TCP, cut-and-paste attacks are also possible within a connectio= n >>> due to sequence number rollover. This can be fixed, however, by >>> extending the sequence numbers virtually, as done with ESP/AH. >> >> We definitely do not want to tie the keying directly to the sequence=20 >> space for a variety of reasons (we listed some, I believe); this is do= ne=20 >> indirectly by bytecounts or packet counts to trigger key changes. >=20 > The only mention of sequence number in your draft is in S 9: >=20 > Value (ICV). In TCP-AO, the socket pair performs most of the functio= n=20 > of IPsec's SPI, and IPsec's Sequence Number, used to avoid replay=20 > attacks, isn't needed due to TCP's Sequence Number, which is used to= =20 > reorder received segments. Unfortunately, it is not useful to=20 > validate TCP's Sequence Number before performing a TCP-AO=20 > authentication calculation, because many out-of-window segments stil= l=20 > cause TCP protocol actions (e.g., ACK retransmission) [RFC793]. It i= s=20 > similarly not useful to add a separate Sequence Number field to the = > TCP-AO option, because doing so could cause a change in TCP's=20 > behavior even when segments are valid.=20 Thanks for rechecking; we can add text to capture our previous thoughts=20 on this, though, as you note below, that's not important here. > But this is not what I'm talking about. I'm merely talking about > using the ISNs as a diversifier for the per-connection key. > Could you elaborate more on issues with this. Are you suggesting instead to retain the ISN for a connection and use it = in the crypto alg? TCP doesn't currently require any specific entropy in = the ISN change; if it's sufficient that it change, this might be a way=20 to achieve the lack of key reuse. >>> 6.2.3. Layered KMP >>> >>> Another way to provide a separate KMP is to bind it more tightly t= o >>> the transport protocol by running it over (or next to, as in DTLS-= >>> SRTP [I-D.ietf-avt-dtls-srtp]) the transport protocol. At the tim= e >>> that the association is created, the application initiating the >>> association also initiates a KMP exchange over (next to) the >>> transport protocol. When the KMP terminates, it outputs keying an= d >>> parameter information and imposes them on the association. In the= >>> case of TLS over TCP, this would look something like: >>> >>> TCP Client TCP Server >>> ---------- ---------- >>> TCP SYN -------------------------------------> >>> <---------------------------------- TCP SYN/ACK >>> TCP ACK -------------------------------------> >>> <--------- TLS Handshake (over TCP) ------> >>> Keys to TCP Keys to T= CP >>> App data (protected with TCP integrity) -----> >>> <----- App data (protected with TCP integrity) >> This fails to protect the SYN exchange, which we consider a requiremen= t.=20 >=20 > I certainly agree that it does not protect the SYN. I noted it as > the second major disadvantage. As for whether this is a requirement, > I think that's deserving of some discussion. >=20 >=20 >> It also changes state from non-keyed to keyed; it would be very=20 >> difficult to introduce that sort of stateful change inside the TCP=20 >> protocol in ways that affect the data stream, since no other options=20 >> have that kind of effect (i.e., of affecting all data after some point= ). >=20 > I'm no expert on TCP options and I'm certainly prepared to believe > that no other options have this effect, but I'm not sure I see > the issue here as to why this is a problem. The sides can simply > place the option in the segment keyed with some null key and > algorithm (e.g., all zero MAC) and then start processing when > the key is set. As I recall, a similar algorithm is used in > SCTP-AUTH. We'll raise that today at TCPM, but I expect that all state associated=20 with a TCP connection will continue to be negotiated solely at SYN time. = Agreed that this is not the case for other stateful protocols. Joe --------------enigEB93B1C241DC34622A0B2F1D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH1nhLE5f5cImnZrsRAkkXAJ98fO1wHOTR360hYZnpo/jPRBK2hACdG6Zu 2zkgm++bPMHUvTpFcYKJFC8= =l86h -----END PGP SIGNATURE----- --------------enigEB93B1C241DC34622A0B2F1D-- From Manuel.A.Offenberg@seagate.com Tue Mar 11 08:31:39 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2BCVdhN028070 for ; Tue, 11 Mar 2008 08:31:39 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m2BCVUht029446 for ; Tue, 11 Mar 2008 08:31:30 -0400 (EDT) Received: from pps0.sv-ext.mailhost.seagate.com (pps0.sv-ext.mailhost.seagate.com [192.55.4.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 389CC7722A5 for ; Tue, 11 Mar 2008 08:30:57 -0400 (EDT) Received: from sv-gw1.notes.seagate.com (sv-gw1.stsj.seagate.com [10.5.132.29]) by pps0.sv-ext.mailhost.seagate.com (8.13.7/8.13.7) with ESMTP id m2BCUuVA030142 for ; Tue, 11 Mar 2008 05:30:56 -0700 From: Manuel.A.Offenberg@seagate.com To: saag@mit.edu Message-ID: Date: Tue, 11 Mar 2008 04:30:51 -0800 X-MIMETrack: Serialize by Router on SV-GW1/Seagate Internet(Release 7.0.1 HF29|March 07, 2006) at 03/11/2008 04:30:56 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Proofpoint-FWRule: outbound2 X-Spam-Score: 0.55 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Manuel A Offenberg/Seagate is out of office X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2008 12:31:39 -0000 I will be out of the office starting 03/10/2008 and will not return until 03/13/2008. May have intermittent access to email. For emergencies, please contact me on my cell (415) 235 8917 or Jim Dykes at (720) 684-2601. Kind regards, Manuel Offenberg From touch@ISI.EDU Tue Mar 11 08:34:30 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2BCYUvt029446 for ; Tue, 11 Mar 2008 08:34:30 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2BCYKcw026395 for ; Tue, 11 Mar 2008 08:34:20 -0400 (EDT) X-ASG-Whitelist: Client Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id D4B8AD28B71 for ; Tue, 11 Mar 2008 08:34:19 -0400 (EDT) Received: from [127.0.0.1] ([63.133.180.130]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m2BCX2xm019868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Mar 2008 05:33:04 -0700 (PDT) Message-ID: <47D67BCD.7030508@isi.edu> Date: Tue, 11 Mar 2008 05:32:13 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Eric Rescorla References: <20080310233304.47E9B1AA4C7@kilo.rtfm.com> <47D5E090.9010608@isi.edu> <20080311115357.17B5F1AB2D2@kilo.rtfm.com> In-Reply-To: <20080311115357.17B5F1AB2D2@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE5DDAAD1A38E1B3593A26CDE" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, tcpm@ietf.org Subject: Re: [saag] [tcpm] Comments on draft-ietf-tcpm-tcp-auth-opt-00 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2008 12:34:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE5DDAAD1A38E1B3593A26CDE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, Eric, Eric Rescorla wrote: =2E.. >>> GENERAL COMMENTS >>> I'm not convinced it's necessary to have a new key for each >>> connection. This is primarily useful to prevent inter-connection >>> cut-and-paste attacks, and it's not clear how serious those >>> are.=20 >> It's there primarily to prevent packets from an old version of a=20 >> connection from being used on a new connection, i.e., replay attacks=20 >> between a connection and its successor using the same port pair. >=20 > Right, that's what I mean by "inter-connection cut and paste attacks". > I'd like to see some analysis of how serious they are.=20 They would be obvious opportunities for on-path attackers. As per my=20 other reply this AM, using the ISN in the hash might avoid this issue=20 entirely. >>> I think it's particularly problematic to levy this >>> requirement without providing some mechanism for arranging >>> that, since that basically implies having some automatic >>> mechanism for establishing fresh per-connection keys, which >>> doesn't currently exist. That makes this mechanism distinctly >>> less useful than RFC 2385. >> >> It does imply that for systems that re-establish connections frequentl= y=20 >> either a a fresh key generation system is available, or a fairly long = >> list is preloaded. >=20 > Right, so absent the definition of such a mechanism, this is less > useful than 2385. Absolutely. We agree that an auto key mechanism is critical; we feel=20 that, like IPsec, it's not integral. >>> I don't think this API, specification of the TSAD, etc., is >>> particularly helpful. IPsec needed the concept of an association >>> database because packets corresponding to multiple associations >>> got similar treatment. However, TCP has an explicit notion >>> of connection so it would be far more convenient to simply >>> refer to keys as tied to connections, and then have a set >>> of rules for mapping which connections get which keys. >> That's exactly what the TSAD is (or at least is supposed to be). It=20 >> might be useful to discuss this offline to figure out what the=20 >> disconnect is... >=20 > Perhaps. I think expressing it as a database isn't particularly > helpful. There are structures associated with the connection > and it's most useful (IMO) to think of this data as attached > to them, just as (for instance) the current window or sequence > number is. Agreed, and that information is deliberately not accessible. Expression=20 of the info as a dbase is equivalent to how TCP describes a "control=20 block". The important issue is the info in each entry, and the index by=20 which they're differentiated. >>> Even if some TSAD-type abstraction is useful, I don't think >>> it's appropriate to define things like the size of each >>> parameter in the TSAD as opposed to on the wire,=20 >> >> The TSAD API needs to be specified in detail because the key managemen= t=20 >> solution needs to rely on that information. >> >>> or to >>> describe the default values of various parameters as in >>> S 3. For instance: >>> >>> iii. Key length. A byte indicating the length of the=20 >>> connection key in bytes. =20 >>> >>> Those are internal implementation issues. Certainly, I might >>> want to use a native int in my implementation. Why should >>> this document tell me otherwise? >> >> Again, it's to allow another party - the key management solution - to = >> load the TSAD. >=20 > I really don't see this. The other party presumably has some set of > API calls/IPC/whatever, that it talks to. It's not our job to > specify the interface between those to, other than the contents > of the elements.=20 That's basically all we do - contents, order, and size of each element=20 in each direction. >>> S 3. >>> >> At least one direction (inbound/outbound) SHOULD ha= ve=20 >>> a non-NONE MAC in practice, but this MUST NOT be stric= tly=20 >>> required by an implementation. =20 >>> >>> 1. This seems like a bad idea. It's very hard to analyze the security= >>> properties of a connection when only one side is protected. To take >>> one case that is obviously bad, if you're worried about DoS attacks >>> and you use TCP-AO, then forging packets in either direction can >>> bring it down. I would reverse this and require MACs in both directio= ns. >> >> For BGP, this is important. For servers, it's not necessarily feasible= -=20 >> clients may authenticate the server, but the converse may not=20 >> necessarily be true. >=20 > I don't see why it's not feasible. They share a key, so there's > no reason not to have mutual auth. There are cases I can think of - akin to well-known CAs used by web=20 browsers used over wireless channels (see below). >> Yes, this allows attacks in one direction to=20 >> succeed, but it also isn't clear that both directions are equally=20 >> vulnerable, is it? >=20 > I don't see this. The relevant attack here is to bring down the > connection. An RST in either direction will accomplish that. The question is whether a RST in either direction is as easy to inject.=20 There are media with dedicated uplinks and shared downlinks for which=20 this is the case, e.g., some wireless nets. Note that this is all just my playing devils' advocate about whether=20 this is needed; if we agree that we should always require bidirectional=20 auth, then it's a trivial patch to the doc to do so. >>> 2. Even if we stipulate that this might be an OK idea, it's not >>> appropriate to require implementations to support it. >> >> I'm not sure I understand this; if we say that connections MAY have=20 >> unidirectional auth, then it seems like the implementation MUST suppor= t=20 >> that capability. >=20 > I don't see that that's true. For instance, TLS stacks MAY support > RC4, but we don't require them to support RC4. I understand now. I am thinking of this as a required feature; again, if = the TCPM WG and/or SAAG thinks this is either MUST NOT or MAY, then it's = an easy change. >>> S 4.1. >>> >> New TSAD entries MUST be checked against a table of previously = >>> used TSAD entries, and key reuse MUST be prohibited.=20 >>> >>> Huh? So, I have to keep a list of every TSAD entry ever and check >>> against the table. Seems better to just to do this by construction. >> >> I'm not sure what "by construction" means, but that's certainly better= =20 >> if possible. Can you suggest text or explain this off-line? >=20 > I mean that if you randomly generate keys for the TSAD with an > appropriate algorithm then there is no reasonable chance that there > will be a collision. That requires the TSAD only ever be loaded by an automatic key manager,=20 AND that only one such manager ever exist. We don't want to require=20 either for all implementations, thus the TSAD must enforce whatever is=20 needed in this regard. Again, the other email of this AM might suggest a simpler way out using=20 ISNs in the hash. >>> S 5.1. >>> o Number of bytes to be sent/received (two bytes); this is used o= n=20 >>> the send side to trigger bytecount-based KeyID changes, and on = the=20 >>> receive side only for statistics or length-sensitive KeyID=20 >>> selection.=20 >>> >>> Please explain the cryptographic rationale for why you would want to >>> do bytecount based key changes. >> >> That part of the API is strawman; we expect to need to count either=20 >> messages or bytes or both. If message counts are more useful, then we = >> can change to that. >=20 > I don't see that you need to count either.=20 I recalled this; it's for sequence number rollover. There are TCP=20 connections that send more than 2^32 bytes. We MUST rollover keys when=20 that happens, and we do not want to tie the key system to internal TCP=20 state. >>> S 9. >>> TCP-AO does not expose the MAC algorithm used to authenticate a=20 >>> particular connection; that information is kept in the TSAD at the= =20 >>> endpoints, and is not indicated in the header.=20 >>> >>> This seems to be of extremely marginal security benefit. There >>> are likely to be <5 algorithms in use. So, searching all of them >>> increases the effective key size by <3 bits.=20 >> >> The other reason to not include it is space; it's not needed, since it= 's=20 >> effectively bound to the active key anyway. >=20 > That's totally reasonable. I'm not saying it has to be included, just t= hat > I don't see not including it as a significant security benefit. It's not significant, agreed. We might omit that from the doc as a=20 result if others agree. Joe --------------enigE5DDAAD1A38E1B3593A26CDE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH1nvNE5f5cImnZrsRAk5+AKC4hRqj2XfVL3fyN31jfyXQjVHClACfe1Rz uYoJ/WXm39+osLvdfq4fozA= =FjWK -----END PGP SIGNATURE----- --------------enigE5DDAAD1A38E1B3593A26CDE-- From ekr@networkresonance.com Tue Mar 11 08:39:04 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2BCd3PZ031405 for ; Tue, 11 Mar 2008 08:39:03 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m2BCcsBl014124 for ; Tue, 11 Mar 2008 08:38:54 -0400 (EDT) Received: from kilo.rtfm.com (dhcp-11ec.ietf71.ietf.org [130.129.17.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id A47607D9BB1 for ; Tue, 11 Mar 2008 08:38:52 -0400 (EDT) Received: from dhcp-1679.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 9CF841AB60F; Tue, 11 Mar 2008 08:38:51 -0400 (EDT) Date: Tue, 11 Mar 2008 08:38:51 -0400 From: Eric Rescorla To: Joe Touch In-Reply-To: <47D6784B.3030107@isi.edu> References: <47D5E09A.5000803@isi.edu> <20080311115220.A85891AB2B9@kilo.rtfm.com> <47D6784B.3030107@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080311123851.9CF841AB60F@kilo.rtfm.com> X-Spam-Score: 3.635 X-Spam-Level: *** (3.635) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: IETF Security Area WG , tcpm@ietf.org Subject: Re: [saag] discussion of draft-rescorla-tcp-auth-arch-00.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2008 12:39:04 -0000 At Tue, 11 Mar 2008 05:17:15 -0700, Joe Touch wrote: > Eric Rescorla wrote: > >> Key changes are to reduce the amount of material signed under a single > >> key, to reduce the utility of signed packets to a cryptoanalyst. > > > > As I indicate in S 3.3, while this is certainly crypto lore for > > symmetric ciphers, I am unaware of any evidence that having > > large (but practical) numbers of plaintext/ciphertext pairs > > is of any significant value in attacking modern algorithms. > > That lore is expressed in RFC3562,and implied in RFC4107 in the phrase > "short term" key. We'd be glad to be advised otherwise; if so, then: > > - we could note that the key-ID would be used only for > deliberate key changes, e.g., due to compromise, or to > avoid a key rollover replay attack > > note: this is also why we need a byte/segment > counter; when it hits 2^32, we MUST change > keys or there is a clear replay attack As I stated in my original document, this is not correct. You simply treat the sequence number as 64 bits long with only the low order 32-bits represented on the wire, but include the entire sequence number in the MAC. The relevant technique is described in RFC 4304. > > - With a single connection. > > - Between connections which happen to share parameters by coincidence. > > > > As I indicate in S 3.1, there's no replay issue in the first case > > except for TCP sequence number rollover, which can be fixed by > > using extended sequence numbers. > > TCP does not have extended sequence numbers. Adding that > cross-connection information, and including it in every tcp-opt header, > was explored but is decided against for numerous reasons. As noted above, this is not included on the wire. > > The relevant issue is the > > second case, again discussed in S 3.1, but it's not clear to > > me how important this actually is. > > That's why we believe it's sufficient to address this at the TSAD, > requiring keys to change when connections end and new ones start with > the same port numbers. That can be accomplished in various ways, e.g., by: > - forcing a TSAD key change > - keeping a cache of previous TSAD keys for that connection > etc. > > The first one above might be sufficient - and simple to implement - if > this is not a severe concern. Well, you're assuming that it's something we need to do at all. Given that it comes at some cost, I think it should be discussed first. > > But this is not what I'm talking about. I'm merely talking about > > using the ISNs as a diversifier for the per-connection key. > > Could you elaborate more on issues with this. > > Are you suggesting instead to retain the ISN for a connection and use it > in the crypto alg? See S 6.1.2. K_connection = HMAC(K_static, ISN_client || ISN_server) -Ekr From ekr@networkresonance.com Tue Mar 11 08:47:02 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2BCl230002681 for ; Tue, 11 Mar 2008 08:47:02 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2BCkq3p017976 for ; Tue, 11 Mar 2008 08:46:52 -0400 (EDT) Received: from kilo.rtfm.com (dhcp-11ec.ietf71.ietf.org [130.129.17.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 5A1EEE3B9BC for ; Tue, 11 Mar 2008 08:46:32 -0400 (EDT) Received: from dhcp-1679.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id AFB0C1AB68D; Tue, 11 Mar 2008 08:46:31 -0400 (EDT) Date: Tue, 11 Mar 2008 08:46:31 -0400 From: Eric Rescorla To: Joe Touch In-Reply-To: <47D67BCD.7030508@isi.edu> References: <20080310233304.47E9B1AA4C7@kilo.rtfm.com> <47D5E090.9010608@isi.edu> <20080311115357.17B5F1AB2D2@kilo.rtfm.com> <47D67BCD.7030508@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080311124631.AFB0C1AB68D@kilo.rtfm.com> X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, tcpm@ietf.org Subject: Re: [saag] [tcpm] Comments on draft-ietf-tcpm-tcp-auth-opt-00 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2008 12:47:02 -0000 Information is getting spread over two threads here, so I will be repeating myself a bit. At Tue, 11 Mar 2008 05:32:13 -0700, Joe Touch wrote: > >>> I don't think this API, specification of the TSAD, etc., is > >>> particularly helpful. IPsec needed the concept of an association > >>> database because packets corresponding to multiple associations > >>> got similar treatment. However, TCP has an explicit notion > >>> of connection so it would be far more convenient to simply > >>> refer to keys as tied to connections, and then have a set > >>> of rules for mapping which connections get which keys. > >> That's exactly what the TSAD is (or at least is supposed to be). It > >> might be useful to discuss this offline to figure out what the > >> disconnect is... > > > > Perhaps. I think expressing it as a database isn't particularly > > helpful. There are structures associated with the connection > > and it's most useful (IMO) to think of this data as attached > > to them, just as (for instance) the current window or sequence > > number is. > > Agreed, and that information is deliberately not accessible. Expression > of the info as a dbase is equivalent to how TCP describes a "control > block". The important issue is the info in each entry, and the index by > which they're differentiated. I think we're going to have to disagree on this one. > > I really don't see this. The other party presumably has some set of > > API calls/IPC/whatever, that it talks to. It's not our job to > > specify the interface between those to, other than the contents > > of the elements. > > That's basically all we do - contents, order, and size of each element > in each direction. Well "contents" != "contents, order, and size" and I haven't heard a clear demonstration that "order and size" are required". > > I don't see why it's not feasible. They share a key, so there's > > no reason not to have mutual auth. > > There are cases I can think of - akin to well-known CAs used by web > browsers used over wireless channels (see below). Well, I think any case in which you have public key is fundamentally different: shared keys imply an opportunity for utual authentication. > >>> >> New TSAD entries MUST be checked against a table of previously > >>> used TSAD entries, and key reuse MUST be prohibited. > >>> > >>> Huh? So, I have to keep a list of every TSAD entry ever and check > >>> against the table. Seems better to just to do this by construction. > >> > >> I'm not sure what "by construction" means, but that's certainly better > >> if possible. Can you suggest text or explain this off-line? > > > > I mean that if you randomly generate keys for the TSAD with an > > appropriate algorithm then there is no reasonable chance that there > > will be a collision. > > That requires the TSAD only ever be loaded by an automatic key manager, > AND that only one such manager ever exist. We don't want to require > either for all implementations, thus the TSAD must enforce whatever is > needed in this regard. No, I don't agree with this. Rather, implementors must ensure that they don't duplicate entry. If they have two management processes, they need to somehow coordinate (or use independent algorithms). That does not mean that the TSAD needs to verify that. Note that verifying it means retaining records of every key. That seems impractical. > >>> S 5.1. > >>> o Number of bytes to be sent/received (two bytes); this is used on > >>> the send side to trigger bytecount-based KeyID changes, and on the > >>> receive side only for statistics or length-sensitive KeyID > >>> selection. > >>> > >>> Please explain the cryptographic rationale for why you would want to > >>> do bytecount based key changes. > >> > >> That part of the API is strawman; we expect to need to count either > >> messages or bytes or both. If message counts are more useful, then we > >> can change to that. > > > > I don't see that you need to count either. > > I recalled this; it's for sequence number rollover. There are TCP > connections that send more than 2^32 bytes. We MUST rollover keys when > that happens, and we do not want to tie the key system to internal TCP > state. See my previous note for how to do this without rollover using ESNs. -Ekr From leiba@watson.ibm.com Tue Mar 11 11:14:35 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2BFEZmw001129 for ; Tue, 11 Mar 2008 11:14:35 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m2BFEJvk007136 for ; Tue, 11 Mar 2008 11:14:21 -0400 (EDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 6C674782126 for ; Tue, 11 Mar 2008 11:04:09 -0400 (EDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m2BF48eu030180 for ; Tue, 11 Mar 2008 11:04:08 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m2BF3rD3234324 for ; Tue, 11 Mar 2008 11:03:54 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m2BF3rXr020650 for ; Tue, 11 Mar 2008 11:03:53 -0400 Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m2BF3rdX020640 for ; Tue, 11 Mar 2008 11:03:53 -0400 Received: from wecm-9-67-175-178.wecm.ibm.com ([9.67.175.178]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1205247832.2941; Tue, 11 Mar 2008 10:03:53 -0400 Date: Tue, 11 Mar 2008 11:03:52 -0400 From: Barry Leiba To: saag@mit.edu Message-ID: <1C0560A379B9B2B7ED1EA22A@Uranus.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.13 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] IETF 71: DKIM working group summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2008 15:14:35 -0000 [Sorry; I mis-posted this to secdir; reposting to saag.] IETF 71 DKIM meeting summary The DKIM working group met on Monday, 10 March 2008, from 1740-1950 in the Franklin 5 room. The main goal of the meeting was to discuss and close issues on the Author Signing Policy document and move toward WGLC on that document. The meeting opened with a review of the informational documents, "DKIM Service Overview"[1] and "DKIM Service Deployment"[2]. The former is mostly done, but for some editorial comments. WGLC on the content started at the close of the meeting, and will end on 24 March. The latter is still under development. The authors solicited reviews and contributions from those developing software for DKIM, deploying it, or operating mail systems with it. Ellen Siegel, who works for an email marketing company, had comments about the timing of the documents, and the importance of having some early advice on the deployment of signing practices. Tony Hansen met with a few people after the meeting. The bulk of the meeting was then spent going through the open issues on the signing practices document, now called "Author Signing Practices"[3] ("Author" replacing "Sender", and there was some discussion on the name, with one WG chair preferring "From Domain", shortened to "FroDo"). Jim Fenton discussed the history of the recent changes (which involved a significant restructuring of the document, a restructuring that resolved a number of issues), and then divided the open issues into three groups, roughly "easy", "medium", and "hard" -- more specifically, "We should close these," "These might be ready to close," and "These probably need more discussion." The result of the issue run-through and discussion related to the latest (-03) draft was that, pending confirmation on the mailing list, we can close all but two of the "easy" issues, all but two of the "medium" ones, and all but one of the "hard" issues (but see below). Most of the "hard" discussion was on issue 1519, user vs domain granularity of signing practices. Consensus was to leave it at domain granularity only, leaving any extension to user granularity for a protocol extension. We'll leave this issue open for two weeks, to allow further discussion. Some issues remaining open: 1519 - user vs domain granularity of signing practices 1535 - clarify need for domain existence check in the decision tree (step 2) 1543 - remove [FWS]; there's a significant move to keep it, just for consistency with the base spec 1547 - require existence of MX records; leave open awaiting follow-up from Peter Koch 1550 - the name of the document (remains open *briefly*); there's still disagreement on "Author" In addition, Phill Hallam-Baker agreed to review the security considerations and add any appropriate text about security threats. Peter Koch will post a message to the list about his concerns about DNS queries (which may open a new issue). And we will open a new issue to replace 1520, which will address only the *name* of the "Discardable" feature -- there's significant dislike of the name, but it's not clear that we'll find a better one. This issue will be open for two weeks only, to avoid having it turn into an interminable discussion. --- [1] Slides at http://www3.ietf.org/proceedings/08mar/slides/dkim-1.pdf Document at http://tools.ietf.org/html/draft-ietf-dkim-overview [2] Slides at http://www3.ietf.org/proceedings/08mar/slides/dkim-2.pdf Document at http://tools.ietf.org/html/draft-ietf-dkim-deployment [3] Slides at http://www3.ietf.org/proceedings/08mar/slides/dkim-0.pdf Document at http://tools.ietf.org/html/draft-ietf-dkim-ssp -- Barry Leiba, DKIM working group chair (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam From tim.polk@nist.gov Wed Mar 12 08:30:52 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2CCUqXU008211 for ; Wed, 12 Mar 2008 08:30:52 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m2CCUf8m012096 for ; Wed, 12 Mar 2008 08:30:42 -0400 (EDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 4E246E2F352 for ; Wed, 12 Mar 2008 08:30:21 -0400 (EDT) Received: from [129.6.222.23] ([129.6.222.23]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m2CCUEG4025151; Wed, 12 Mar 2008 08:30:15 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tim Polk Date: Wed, 12 Mar 2008 08:30:14 -0400 To: saag@mit.edu X-Mailer: Apple Mail (2.752.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] reminder:kmart bof X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2008 12:30:52 -0000 Folks, Just wanted to remind everyone that we will be continuing our discussions from the Vancouver SAAG in the KMART BOF today from 1 - 3 PM. I hope to se you all there! Thanks, Tim Polk From ekr@networkresonance.com Wed Mar 12 09:09:00 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2CD90N4023945 for ; Wed, 12 Mar 2008 09:09:00 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m2CD8oNS001045 for ; Wed, 12 Mar 2008 09:08:50 -0400 (EDT) Received: from kilo.rtfm.com (dhcp-11ec.ietf71.ietf.org [130.129.17.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 97A41E30603 for ; Wed, 12 Mar 2008 09:08:29 -0400 (EDT) Received: from dhcp-11ec.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 773171AEFB0 for ; Wed, 12 Mar 2008 09:08:29 -0400 (EDT) Date: Wed, 12 Mar 2008 09:08:29 -0400 From: Eric Rescorla To: saag@mit.edu User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080312130829.773171AEFB0@kilo.rtfm.com> X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Summary of TLS WG X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2008 13:09:00 -0000 $Id$ TLS met Monday at 1520-1420 for an hour. Don Eastlake presented RFC 4366-bis, which is the separate draft for TLS extensions. This is mostly editorial but there are two technical issues about certificate URL hashing. The general consensus was (1) to mandate the hash and (2) deal with hash agility by defining a new code point if we need to. Pasi Eronen presented the DES/IDEA cipher suite document, which breaks those cipher suites out of the main TLS draft. There was discussion about what kind of disclaimer to use and general consensus that in future we need to put clear applicability statements on cipher suites. Pascal Urien presented ECDHE_PSK, a new WG item. This hasn't had enough review to advance yet. We commissioned two reviews. Eric Rescorla presented plans for DTLS 1.1. The intention is simply to rev the version to align with TLS 1.2 and fix ambiguities in the original spec. There was substantial support for adopting this as a WG item--needs to be confirmed on list. Kato Akihiro presented Camellia cipher suites with SHA-256. Camellia is already in TLS, but with SHA-1. -Ekr From ekr@networkresonance.com Wed Mar 12 09:27:05 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2CDR5ED031550 for ; Wed, 12 Mar 2008 09:27:05 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2CDQuQc029001 for ; Wed, 12 Mar 2008 09:26:56 -0400 (EDT) Received: from kilo.rtfm.com (dhcp-11ec.ietf71.ietf.org [130.129.17.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 2F618E32472 for ; Wed, 12 Mar 2008 09:26:31 -0400 (EDT) Received: from dhcp-11ec.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 4569A1AF112; Wed, 12 Mar 2008 09:26:30 -0400 (EDT) Date: Wed, 12 Mar 2008 09:26:30 -0400 From: Eric Rescorla To: Lakshminath Dondeti In-Reply-To: <47D7D9AB.2060005@qualcomm.com> References: <20080312130829.773171AEFB0@kilo.rtfm.com> <47D7D9AB.2060005@qualcomm.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080312132630.4569A1AF112@kilo.rtfm.com> X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Summary of TLS WG X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2008 13:27:05 -0000 At Wed, 12 Mar 2008 06:24:59 -0700, Lakshminath Dondeti wrote: > > > > On 3/12/2008 6:08 AM, Eric Rescorla wrote: > > $Id$ > > > > TLS met Monday at 1520-1420 for an hour. > > > > Ekr, > > I know you speak fast, but didn't realize it was fast enough for time > travel. > > This is a great achievement! I was there at the meeting, but failed to > notice clocks turning back in time. I was not wearing a watch at that > time; perhaps that was why. Well, it's a Schrodinger's cat thing. If you had been looking at your watch, then it wouldn't have happened. -Ekr From ldondeti@qualcomm.com Wed Mar 12 09:39:03 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2CDd3MA004016 for ; Wed, 12 Mar 2008 09:39:03 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2CDcqU1023505 for ; Wed, 12 Mar 2008 09:38:53 -0400 (EDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id C1FB878A9D9 for ; Wed, 12 Mar 2008 09:25:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1205328320; x=1236864320; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<47D7D9AB.2060005@qualcomm.com>|Date:=20We d,=2012=20Mar=202008=2006:24:59=20-0700|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Thun derbird=202.0.0.12=20(Windows/20080213)|MIME-Version:=201 .0|To:=20Eric=20Rescorla=20|CC: =20saag@mit.edu|Subject:=20Re:=20[saag]=20Summary=20of=20 TLS=20WG|References:=20<20080312130829.773171AEFB0@kilo.r tfm.com>|In-Reply-To:=20<20080312130829.773171AEFB0@kilo. rtfm.com>|Content-Type:=20text/plain=3B=20charset=3DISO-8 859-15=3B=20format=3Dflowed|Content-Transfer-Encoding:=20 7bit|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,5249" =3B=20a=3D"1056052"; bh=UwSKyv60net1tnlZXKxNn3EqjRDDuSvgVyuestEwCNI=; b=OHbQfM1yWRCJWBMnqInraCccFjpu9/UoTlYySffZjGJ8wMBWMhsFTGlq 0VTb85uR7QCMClXCsfX55pTjrckgyvmlAmt8YWYyM0Gj1YiE85A6H9pkj jfkO8kmqpu29ZUKnYC9WD0mnbFiXvKQ8gJjlQ4TtLUw/FIpu2545I/tlN s=; X-IronPort-AV: E=McAfee;i="5200,2160,5249"; a="1056052" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Mar 2008 06:24:59 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2CDP1ju004130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Mar 2008 06:25:02 -0700 Received: from [10.50.72.188] (qconnect-10-50-72-188.qualcomm.com [10.50.72.188]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2CDOxTK009395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Mar 2008 06:25:00 -0700 (PDT) Message-ID: <47D7D9AB.2060005@qualcomm.com> Date: Wed, 12 Mar 2008 06:24:59 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Eric Rescorla References: <20080312130829.773171AEFB0@kilo.rtfm.com> In-Reply-To: <20080312130829.773171AEFB0@kilo.rtfm.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Summary of TLS WG X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2008 13:39:03 -0000 On 3/12/2008 6:08 AM, Eric Rescorla wrote: > $Id$ > > TLS met Monday at 1520-1420 for an hour. > Ekr, I know you speak fast, but didn't realize it was fast enough for time travel. This is a great achievement! I was there at the meeting, but failed to notice clocks turning back in time. I was not wearing a watch at that time; perhaps that was why. :) regards, Lakshminath From shanna@juniper.net Wed Mar 12 13:30:41 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2CHUd1W004342 for ; Wed, 12 Mar 2008 13:30:41 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2CHUTTs026480 for ; Wed, 12 Mar 2008 13:30:29 -0400 (EDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 58945799E6F for ; Wed, 12 Mar 2008 13:30:08 -0400 (EDT) Received: from source ([66.129.224.36]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Wed, 12 Mar 2008 10:28:34 PDT Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Mar 2008 10:29:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Mar 2008 13:29:21 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 71 NEA WG summary Thread-Index: AciEZpuoeg7JgsfETEyZkkHI8rGOcg== From: "Stephen Hanna" To: X-OriginalArrivalTime: 12 Mar 2008 17:29:50.0344 (UTC) FILETIME=[ACF6B880:01C88466] X-Spam-Score: 3.5 X-Spam-Level: *** (3.5) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m2CHUd1W004342 Subject: [saag] IETF 71 NEA WG summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2008 17:30:41 -0000 The Network Endpoint Assessment (NEA) WG met at IETF 71 on Tuesday, March 11, 2008 from 9 AM to 11:30 AM EDT. We reviewed changes made in draft-ietf-nea-requirements-06.txt in response to IESG COMMENTs and DISCUSSes. No issues were identified with those changes. They will be reviewed further on the NEA WG email list. The bulk of the meeting was spent reviewing the PB-TNC, PA-TNC, and PA-TNC Security proposals. These were the only responses to our request for protocol proposals that meet the NEA requirements. After a good discussion of the proposals, a consensus check showed a clear consensus in the room to accept PB-TNC and PA-TNC as WG drafts. For PA-TNC Security, the consensus was to defer action for now. These decisions will be confirmed on the NEA WG email list. A new set of NEA WG milestones was reviewed. These have previously been reviewed on the WG list and are almost identical to the version reviewed at IETF 70. No concerns have been raised so they will be submitted. From tim.polk@nist.gov Wed Mar 12 17:20:30 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2CLKUgn016486 for ; Wed, 12 Mar 2008 17:20:30 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m2CLKLAQ028762 for ; Wed, 12 Mar 2008 17:20:22 -0400 (EDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id D984A80BD4F for ; Wed, 12 Mar 2008 17:20:08 -0400 (EDT) Received: from [129.6.222.92] ([129.6.222.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m2CLJvq9007936; Wed, 12 Mar 2008 17:20:00 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3EBD71AC-EC1B-4D48-8011-B63D28C84072@nist.gov> Content-Transfer-Encoding: 7bit From: Tim Polk Date: Wed, 12 Mar 2008 17:19:03 -0400 To: saag@mit.edu X-Mailer: Apple Mail (2.752.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] call for wg co-chair nominations: emu; tls; and msec X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2008 21:20:30 -0000 Pasi and I would appreciate nominations for co-chair positions for three working groups within the Security Area. The positions are co- chair for emu, tls, and msec. The emu working group has been operating with a single chair, Joe Salowey, for a long time now. Emu is currently considering significant charter revisions, and this prospective new work could increase the workload beyond that appropriate for a single chair. The tls working group has been co-chaired by Eric Rescorla and Pasi Eronen. As part of AD transition, we have decided that Pasi should become the responsible AD for tls, creating the second vacancy. The msec working group has been co-chaired by Lakshminath Dondeti and Ran Canetti. Ran no longer has the time and is stepping down, so msec will be needing a new chair as well. If you would like to be considered for one of these position, or wish to nominate someone else, please contact Pasi or me directly. From Shawn.Emery@Sun.COM Wed Mar 12 15:46:43 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2CJkhoI001514 for ; Wed, 12 Mar 2008 15:46:43 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m2CJkYrg007711 for ; Wed, 12 Mar 2008 15:46:34 -0400 (EDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by mit.edu (Spam Firewall) with ESMTP id AE38B79699F for ; Wed, 12 Mar 2008 15:46:12 -0400 (EDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2CJkC5F019121 for ; Wed, 12 Mar 2008 19:46:12 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXM00L01U9PEV00@mail-amer.sun.com> (original mail from Shawn.Emery@Sun.COM) for saag@mit.edu; Wed, 12 Mar 2008 13:46:12 -0600 (MDT) Received: from dhcp-15a7.ietf71.ietf.org ([129.150.66.199]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXM00JMSUWOVNB0@mail-amer.sun.com>; Wed, 12 Mar 2008 13:46:01 -0600 (MDT) Date: Wed, 12 Mar 2008 13:42:55 -0600 From: "Shawn M. Emery" Sender: Shawn.Emery@Sun.COM To: saag@mit.edu Message-id: <47D8323F.5070405@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) X-Spam-Score: 0.001 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Wed, 12 Mar 2008 17:20:54 -0400 Cc: Alexey Melnikov Subject: [saag] IETF 71 Kitten Working Group Summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2008 19:46:43 -0000 The kitten-wg met Tuesday, 3/11/08, during the last afternoon session. Co-chairs: Alexey Melnikov and Shawn Emery The goals of the meeting were to go over the active working items and Milestones. Important developments included both domain-based drafts: draft-ietf-kitten-gssapi-domain-based-names draft-ietf-kitten-gssapi-krb5-domain-based-names clearing DISCUSS issues and are now in the RFC editor's queue. IANA extension draft: draft-ietf-kitten-gssapi-extensions-iana-02 has made progress, but still needs more guidance for IANA. One solution provided would be to create an appendix with examples from existing mechanisms. Editor will make these changes and we have volunteer reviewers before WGLC. The channel-bindings clarification draft: draft-ietf-kitten-gssapi-channel-bindings-03 is close to starting WGLC after normative reference update to RFC5056. Currently needs Introduction and IANA Considerations sections before submitting. New editor has volunteered to take over naming extensions ID: draft-ietf-kitten-gssapi-naming-exts-02 which needs the most work compared to the other drafts in the WG. We have decided to spread out the work load by submitting WGLC on the Java bindings draft: draft-ietf-kitten-rfc2853bis-03. after the IANA, channel bindings, and the naming extensions draft. Milestones have been pushed out. Co-chairs will update with the new time lines shortly. Shawn and Alexey. -- From Pasi.Eronen@nokia.com Thu Mar 13 10:53:06 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2DEr5fB020597 for ; Thu, 13 Mar 2008 10:53:06 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2DEqxqX016688 for ; Thu, 13 Mar 2008 10:52:59 -0400 (EDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 3CAE3E37306 for ; Thu, 13 Mar 2008 10:52:37 -0400 (EDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m2DEqSrg005817; Thu, 13 Mar 2008 16:52:34 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Mar 2008 16:51:51 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Mar 2008 16:51:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Mar 2008 16:51:50 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB7218393D@vaebe104.NOE.Nokia.com> In-Reply-To: <3EBD71AC-EC1B-4D48-8011-B63D28C84072@nist.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] call for wg co-chair nominations: emu; tls; and msec Thread-Index: AciEh9uhYu+OYImUReKgrcEm6s7ZiwAkW1QA References: <3EBD71AC-EC1B-4D48-8011-B63D28C84072@nist.gov> From: To: , X-OriginalArrivalTime: 13 Mar 2008 14:51:51.0766 (UTC) FILETIME=[C5B43F60:01C88519] X-Nokia-AV: Clean X-Spam-Score: 0.69 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m2DEr5fB020597 Subject: Re: [saag] call for wg co-chair nominations: emu; tls; and msec X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 14:53:08 -0000 I'd like to add that we're also open to considering new blood; i.e., someone who hasn't been a WG chair before. If you know someone you think would be interested, drop us a note. Best regards, Pasi > -----Original Message----- > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On > Behalf Of ext Tim Polk > Sent: 12 March, 2008 23:19 > To: saag@mit.edu > Subject: [saag] call for wg co-chair nominations: emu; tls; and msec > > > Pasi and I would appreciate nominations for co-chair positions for > three working groups within the Security Area. The > positions are co- > chair for emu, tls, and msec. > > The emu working group has been operating with a single chair, Joe > Salowey, for a long time now. Emu is currently considering > significant charter revisions, and this prospective new work could > increase the workload beyond that appropriate for a single chair. > > The tls working group has been co-chaired by Eric Rescorla and Pasi > Eronen. As part of AD transition, we have decided that Pasi should > become the responsible AD for tls, creating the second vacancy. > > The msec working group has been co-chaired by Lakshminath > Dondeti and > Ran Canetti. Ran no longer has the time and is stepping down, so > msec will be needing a new chair as well. > > If you would like to be considered for one of these position, > or wish > to nominate someone else, please contact Pasi or me directly. > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag > From kent@bbn.com Thu Mar 13 11:27:20 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2DFRKn7002322 for ; Thu, 13 Mar 2008 11:27:20 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2DFRABv000837 for ; Thu, 13 Mar 2008 11:27:10 -0400 (EDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by mit.edu (Spam Firewall) with ESMTP id 4EA20101B6BC for ; Thu, 13 Mar 2008 11:26:48 -0400 (EDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.16.169]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JZpKS-0002in-52 for saag@mit.edu; Thu, 13 Mar 2008 11:26:48 -0400 Mime-Version: 1.0 Message-Id: Date: Thu, 13 Mar 2008 11:27:00 -0400 To: saag@mit.edu From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 2.29 X-Spam-Level: ** (2.29) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] (no subject) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 15:27:20 -0000 PKIX met once for 2.5 hours on Monday, 3.10.08, with about 60 attendees. Four PKIX documents have received IESG approval since the last IETF meeting (3 of these were approved this week): 3280bis and the CMC trio. There were five presentations on WG items, and five on related items. Two existing PKIX RFCs (3279 and 4055), to align with our newly adopted approach to representing public key algorithms with parameters, are undergoing minor revisions and should be completed soon. The effort to update PKIX specs to use the 1998/2002 version of ASN.1 is progressing. Jim Schaad described the merits of one of the new constructs in this version of ASN.1, objects. The trust anchor management effort was the topic of two presentations. The first reviewed the current version of the problem statement I-D, and noted the plan to abandon this document and transition much of the text into a requirements statement I-D. Questions were raised on the list about about the relationship between the TAM data structures and SCVP, so the speaker presented an analysis of the two. Although there is an overlap, there are enough differences to suggest that it makes sense to continue development of the TAM data structures without trying to adopt the SCVP structure in toto. The second presentation described a directory-based approach to TA management, and compared it to the request/response protocol approach that has been put forth so far. Both approaches can benefit from a common data structure model, but each approach offers somewhat different functionality. The PKI Resource Query Protocol (PRQP) was briefed for a third time. This protocol is slated to be an experimental RFC. and was accepted as a WG item (with that stipulation) as the result of a straw poll conducted in December. It may be close to a WG last call. A discussion of the use of wildcards in DSN names in certs concluded with an agreement that this topic is adequately addressed in 3280bis; processing semantics beyond what 3280bis describes are best handled in the WGs responsible for the secruity protocols that allow use of this convention. There was a second presentation on a proposed extension to allow a cert to carry pointers to other certs that have been issued to the same subject. Additional text in the I-D is needed to clarify some issues raised during Q&A, before the WG can decide if it wants to adopt this as a new work item. There was a presentation on a model for issuing Traceable Anonymous Certificates (TACs). The model is compatible with the PKIX/X.509 cert format and with PKIX cert request protocols. Validation of a TAC is also compatible with PKIX standards. The motivation for TACs is to allow issuance of (EE) certs that contain a Subject name that does not disclose the real name of the Subject, but which can be traced to the real user if needed, e.g., in case of abuse by the user. The speaker requested feedback from PKIX members and solicited a co-author for the document. Scott Rea (Dartmouth) made a very brief appeal for assistance from IETF PKI experts. His work is exploring how to improve the usability of PKIs by "ordinary" users. The final presentation was on a proposed extension to represent subject clearance (of processing authorization, for devices) information in PK certs (vs. attribute certs). The format is one already defined for attribute certs by ITU-T (and thus is in RFC 3281), and is is used in SMIME ESS (RFC 3851). Adpproval for adoption of this as a WG item will be pursued on the list. From tlyu@MIT.EDU Thu Mar 13 12:28:46 2008 Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2DGSiD7002557 for ; Thu, 13 Mar 2008 12:28:46 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2DGSh2U003651 for ; Thu, 13 Mar 2008 12:28:43 -0400 (EDT) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id m2DGSg8j022620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Mar 2008 12:28:43 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id m2DGSgHr001326; Thu, 13 Mar 2008 12:28:42 -0400 (EDT) To: saag@MIT.EDU From: Tom Yu Date: Thu, 13 Mar 2008 12:28:42 -0400 Message-ID: Lines: 52 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Subject: [saag] IETF71 SASL WG summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 16:28:46 -0000 Simple Authentication And Security Layer (SASL) IETF71, Philadelphia, PA Tuesday, March 11, 2008 at 13:00-15:00 ====================================== Chairs: Tom Yu Kurt Zeilenga ==================== Thanks to Cyrus Daboo for scribing. IESG discussion on recharter proposal results in a desire to have additional details on the requirements for the DIGEST-MD5 successor. Some text was proposed on mailing list; we will work on a shorter summary for the actual charter text and send the longer version for additional explanation to the IESG if needed. Block digest-to-historic behind SCRAM? Various strategies proposed, including putting a normative reference to SCRAM. We decide that we will ask Pasi what works best for him in terms of document workflow. Tangential discussion about moving http-digest to historic; conclude that the question is not for this working group to decide. Is SCRAM what we have consensus on for the DIGEST-MD5 successor? Eventually Simon Josefsson, Chris Newman, and Alexey Melnikov agree to merge Simon's doc with SCRAM. They will also produce a comparison of Simon's doc and SCRAM. Block GS2 behind SCRAM? Simon wants to wait until it's in rfc editor queue. Alexey would rather at least one additional GS2 mech prior to implementing GS2. We want to avoid yet another previously-general mechanism family that only supports GSS-API/Kerberos. Postpone decision until IETF72 (Dublin). Frank Ellerman made a WGLC comment on digest-to-historic, detailing the http-digest incompatibility with DIGEST-MD5. Alexey will respond to Frank's comment re digest-to-historic by the end of the week. Kurt to coordinate interop testing in dublin ACTION ITEMS: Alexey will respond to Frank's comment on digest-to-historic by the end of the week. Simon, Alexey, Chris will produce a merged document for DIGEST-MD5 successor by May 1st, including a comparison of Simon's mech and SCRAM. From clancy@ltsnet.net Thu Mar 13 13:16:15 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2DHGFEf027777 for ; Thu, 13 Mar 2008 13:16:15 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2DHG3wS014477 for ; Thu, 13 Mar 2008 13:16:03 -0400 (EDT) Received: from bacon.cs.umd.edu (server-nat-2.cs.umd.edu [128.8.127.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id E89F7E29D90 for ; Thu, 13 Mar 2008 13:15:39 -0400 (EDT) Received: from [127.0.0.1] (dhcp-108d.ietf71.ietf.org [130.129.16.141]) (authenticated bits=0) by bacon.cs.umd.edu (8.13.1/8.12.5) with ESMTP id m2DHFXR1007813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Mar 2008 13:15:34 -0400 Message-ID: <47D96130.80003@ltsnet.net> Date: Thu, 13 Mar 2008 13:15:28 -0400 From: Charles Clancy User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: saag@mit.edu Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more information X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.399, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.00, BAYES_00 -2.60) X-CSD-MailScanner-From: clancy@ltsnet.net X-Spam-Status: No X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] HOKEY WG Summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 17:16:15 -0000 HOKEY met Wednesday morning. Most of the discussion related to the HOKEY key management draft, which describes how to distribute EAP session keys to various network entities. Discussion resulted in consensus and a specific plan for how to move the document forward within the working group. Specifically, the proposal involves simplifying the protocol to a single RT between the key recipient and the home AAA server, and relying on AAA security rather than implementing our own. Document status: HOKEY Re-authentication Problem Statement draft-ietf-hokey-key-mgm RFC Editor's Queue EAP Reauthentication Extensions (ERX) draft-ietf-hokey-erx IESG Evaluation EMSK Keying Hierarchy draft-ietf-hokey-emsk-hierarchy IETF Last Call HOKEY Key Management draft-ietf-hokey-key-mgm Still under construction Pre-authentication Problem Statement draft-ietf-hokey-preauth-ps WGLC to start soon -- Dr. Charles Clancy www.ltsnet.net/~clancy Senior Researcher, Laboratory for Telecommunications Sciences From jsalowey@cisco.com Thu Mar 13 13:23:21 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2DHNL1Q030803 for ; Thu, 13 Mar 2008 13:23:21 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2DHN94j027580 for ; Thu, 13 Mar 2008 13:23:10 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 4E058E47867 for ; Thu, 13 Mar 2008 13:22:49 -0400 (EDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 13 Mar 2008 10:22:48 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m2DHMmhx018266 for ; Thu, 13 Mar 2008 10:22:48 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m2DHMX5s029439 for ; Thu, 13 Mar 2008 17:22:48 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Mar 2008 10:22:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Mar 2008 10:23:24 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EMU Working group summary Thread-Index: AciFLvF/FGAGDxcCQ9GxkNbm5C2Gjw== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 13 Mar 2008 17:22:38.0800 (UTC) FILETIME=[D6281500:01C8852E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=486; t=1205428968; x=1206292968; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20EMU=20Working=20group=20summary |Sender:=20; bh=GduGQ9r+JQqrgrbiRNvqcjIDXR6hmv0PGUCs+a1US48=; b=azhMJ2EROyihqvAoyQl8qa4QAxrJXB9KYyI29+5U1lIyf/L1x4K/OAgttQ qpx/kPgkI2sxt54oDbKRAzteu0yBX3zpmcLucqDxrddYcmiIBzmbN6OoMuiz QeMrsAgnCy; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m2DHNL1Q030803 Subject: [saag] EMU Working group summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 17:23:22 -0000 EAP Method Update (EMU) working group met Thursday morning. Discussion primarily focused on revising the charter to include tunnel method and the definition of EAP Channel Bindings. Next steps are finalizing the charter and requirements for the tunnel method. We also had a presentation on a secure password only method (draft-harkins-emu-eap-pwd-01). There was some interest in this type of method, but the working group was not ready to take this work on at this time. From jhutz@cmu.edu Thu Mar 13 13:38:01 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2DHc1wJ005555 for ; Thu, 13 Mar 2008 13:38:01 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2DHbpAn027839 for ; Thu, 13 Mar 2008 13:37:51 -0400 (EDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id AB447D164CB for ; Thu, 13 Mar 2008 13:37:30 -0400 (EDT) Received: from dhcp-162c.ietf71.ietf.org (dhcp-162c.ietf71.ietf.org [130.129.22.44]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m2DHbSnZ007810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 13:37:29 -0400 (EDT) Date: Thu, 13 Mar 2008 13:37:28 -0400 From: Jeffrey Hutzelman To: ietf-krb-wg@anl.gov, saag@mit.edu Message-ID: X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Kerberos WG IETF71 meeting summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 17:38:02 -0000 This is a SUMMARY of the Kerberos WG meeting held this week in Philadelphia as part of the 71st IETF meeting. Full minutes will be posted on a later date. -- Jeff Kerberos Working Group - IETF 71 meeting summary ACTION ITEMS: * Nicolas Williams - send an updated version of set-change password * Chairs - finish review and writeup of cross-realm problem statement * Larry Zhu - prepare an example for naming of how unintended access could be granted if authentication succeedes with an unsupported well-known name. * Chairs - ask folks commenting that the data model might be incomplete to come up with specific examples of things that are missing. * Larry Zhu, Shawn Emery, others - examine the data model with respect to their specific implementations. DECISIONS (to be validated): * The data model document should not cover operations. * OTP perhaps does not need a mandatory-to-implement mechanism SESSION SUMMARY: We reviewed the status of several documents that are working their way through the queue, and discussed several documents which have recently concluded IETF or Working Group Last Call. The set-change password document is waiting for an updated version which the author didn't quite get in before the meeting, and then it will go to Tim and the IESG. We reviewed the status of several documents that are working their way through the queue. The set-change password document is waiting for an updated version which the author didn't quite get in before the meeting, and then it will go to Tim and the IESG. The cross-realm problem statement document finished WG last call some time ago, and has been waiting for the chairs to finish their review and writeup. We also discussed several documents which have recently concluded IETF or Working Group Last Call. The PKINIT ECC document has received no notable comments in IETF LC, and hopefully will move along smoothly. There were some comments in a security directorate review of naming, which will be addressed in an upcoming revision. The data model document just finished WGLC. Leif will do some updates to reflect comments received. Sam Hartman reviewed recent updates to the Preauth Framework document, Gareth Richards went over some open issues related to the OTP document. There was discussion as to whether it was necessary to have a particular mandatory-to-implement OTP mechanism; the conclusion in the room seemed to be that it was not. Gareth also described an issue relating to the need to come up with OTP algorithm identifiers: apparently keyprov has the same problem, and a joint solution may be appropriate. The chairs would like to see the group consider possible directions and next steps now that the cross-realm problem statement document is done. This could include rechartering to pick up new work to address one or more of the problems described there. To that end, Kamada Ken'ichi gave a presentation on the Client-Friendly Cross Realm work he's been doing. We will continue to consider where to go next, and possibly have another presentation in Dublin. Interested parties should contact the chairs and/or bring up their proposals on the mailing list. There was a discussion relating to the intended status of the STARTTLS document. Before we send this document to the IESG, the chairs would like to see us come to conclusion on whether it should be Informational or Standards Track. Tim is investigating whether there is precedent for possible actions when the technical aspects of a document are complete and it is blocked only on intended status. At the open mic, Shoichi Sakane mentioned a proposal he is bringing to the dhc working group to create a DHCPv6 option for identifying a KDC. From ldondeti@qualcomm.com Thu Mar 13 13:42:15 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2DHgFRW008136 for ; Thu, 13 Mar 2008 13:42:15 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2DHg37T009734 for ; Thu, 13 Mar 2008 13:42:04 -0400 (EDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id A4D4D1014CE4 for ; Thu, 13 Mar 2008 13:41:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1205430102; x=1236966102; h=message-id:date:from:user-agent:mime-version:to:cc: subject:content-type:content-transfer-encoding: x-ironport-av; z=Message-ID:=20<47D9673E.9040602@qualcomm.com>|Date:=20Th u,=2013=20Mar=202008=2010:41:18=20-0700|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Thun derbird=202.0.0.12=20(Windows/20080213)|MIME-Version:=201 .0|To:=20saag@mit.edu|CC:=20msec@ietf.org|Subject:=20MSEC =20summary|Content-Type:=20text/plain=3B=20charset=3DISO- 8859-15=3B=20format=3Dflowed|Content-Transfer-Encoding: =207bit|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,5251 "=3B=20a=3D"1086028"; bh=Z3QoEOtDW+iqT6uOReW+eGK8zmhheugNfpXelJ9jvDk=; b=CUcQSLH+XDkshb7mwbXxyF8YdPqvewT/P4UkrIWgm/qHgjH/BbXVN1Qr AE6WK8HP+ZsvVoZTbOlUHvPXlIYLPW8+a6GjdiOrb8fvWJaPTFn5zVefe G7v+WA3NBirE+tJFoT6FwYW6ogizm+XNI4ohHSiir7y16oHgHT24IZO3z o=; X-IronPort-AV: E=McAfee;i="5200,2160,5251"; a="1086028" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Mar 2008 10:41:21 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2DHfKNl002426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Mar 2008 10:41:21 -0700 Received: from [10.50.68.106] (qconnect-10-50-68-106.qualcomm.com [10.50.68.106]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2DHfIUS030336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Mar 2008 10:41:19 -0700 Message-ID: <47D9673E.9040602@qualcomm.com> Date: Thu, 13 Mar 2008 10:41:18 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: saag@mit.edu Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: msec@ietf.org Subject: [saag] MSEC summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 17:42:15 -0000 We spent 1 hour on Wednesday discussing new work items. There are requirements related to a signaling protocol (RSVP) and routing protocols (e.g., OSPF, NLS) which point to the need for group key management protocols. There are indications that the work needs to happen in MSEC; although there is caution from the TSV ADs that the requirements do not imply that a particular protocol can be adopted as a MSEC work item. The direction would have been to extend GDOI to satisfy these requirements. As it stands now, we see no urgency for that work to happen. It appears that may be a longer term goal and so we agreed to proceed with the current GDOI extensions work (unrelated to the new requirements, and related to hash algorithm agility and other minor changes based on implementation experience). The authors are advised to continue the work as individual work. Next, Dan Wing presented his SRTP key transport work which works over DTLS. MSEC has a work item on group keying for SRTP, GDOI-SRTP. Sheela Rowles compared to the two approaches and after some discussion the conclusion was to pursue optimization of GDOI-SRTP for large groups and DTLS-SRTP-Key transport for small groups. As a side note, Dan was asked to study if there are indeed difficulties in using the TLS-based solution for large groups. TESLA-for-alc-norm is ready for WGLC. There was also a presentation on extending MIKEY to support mode negotiation. regards, Lakshminath From Donald.Eastlake@motorola.com Thu Mar 13 13:45:29 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2DHjTN7010626 for ; Thu, 13 Mar 2008 13:45:29 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2DHjJPI019226 for ; Thu, 13 Mar 2008 13:45:19 -0400 (EDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by mit.edu (Spam Firewall) with SMTP id D8E7478CAEA for ; Thu, 13 Mar 2008 13:44:57 -0400 (EDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1205430295!1770263!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 27695 invoked from network); 13 Mar 2008 17:44:56 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-5.tower-128.messagelabs.com with SMTP; 13 Mar 2008 17:44:56 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m2DHitTI009833 for ; Thu, 13 Mar 2008 10:44:55 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id m2DHiswg025924 for ; Thu, 13 Mar 2008 12:44:54 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id m2DHiqiU025907 for ; Thu, 13 Mar 2008 12:44:53 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Mar 2008 13:44:50 -0400 Message-ID: <3870C46029D1F945B1472F170D2D979003997154@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Report on the KMART BoF Thread-Index: AciFMe/TotFQ9H5/Qui3h3vz9wiV2w== From: "Eastlake III Donald-LDE008" To: X-CFilter-Loop: Reflected X-Spam-Score: 3.7 X-Spam-Level: *** (3.7) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m2DHjTN7010626 Subject: [saag] Report on the KMART BoF X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 17:45:30 -0000 The Key MAnagement for RouTing protocols (KMART) BOF was Wednesday afternoon. It's primary goal was to improve mutual understanding between the Routing and Security Areas on the operational and protocol realities of routing security, threats against routing security, and what automated key management is and can do for you. It succeeded and seemed to presage improved cooperation between the areas. A number of excellent presentations were made on requirements, existing routing security problems and a history of attacks, operational characteristics of BGP, and key management. The BoF was well attended and the Routing and Security ADs were there. Some ISP people came to the mike and told us what problems they felt were the most pressing to solve. A list of four problems with link state routing was presented, with no disagreement, in which it was thought that the first three were reasonably soluble and the fourth more problematic: (1) weak algorithms, (2) poor key rollover / lack of key IDs, (3) lack of replay protection, and (4) multicast security. There was a desire for the Security Area to revisit RFC 3365 with respect to the routing protocol environment and for the Routing Area to pursue completion of some of the authentication work in the pipeline with renewed vigor. The TCP Authentication Option which is proceeding in parallel was cited several times. Donald (co-chair with Acee Lindem) ==================================================== Donald E. Eastlake 3rd +1-508-786-7554 (work) Motorola Laboratories 111 Locke Drive Marlborough, MA 01752 USA Donald.Eastlake@motorola.com From pekkas@netcore.fi Thu Mar 13 18:38:38 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2DMccmJ025349 for ; Thu, 13 Mar 2008 18:38:38 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2DMcV2U023464 for ; Thu, 13 Mar 2008 18:38:31 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 8C682E49AAD for ; Thu, 13 Mar 2008 18:38:10 -0400 (EDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m2DMc6KE007228; Fri, 14 Mar 2008 00:38:06 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m2DMc6Rq007225; Fri, 14 Mar 2008 00:38:06 +0200 Date: Fri, 14 Mar 2008 00:38:06 +0200 (EET) From: Pekka Savola To: Eastlake III Donald-LDE008 In-Reply-To: <3870C46029D1F945B1472F170D2D979003997154@de01exm64.ds.mot.com> Message-ID: References: <3870C46029D1F945B1472F170D2D979003997154@de01exm64.ds.mot.com> User-Agent: Alpine 1.00 (LRH 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Status: Clean X-Spam-Status: No, score=-3.7 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on otso.netcore.fi X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Report on the KMART BoF X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 22:38:39 -0000 On Thu, 13 Mar 2008, Eastlake III Donald-LDE008 wrote: > There was a desire for the Security > Area to revisit RFC 3365 with respect to the routing protocol > environment and for the Routing Area to pursue completion of > some of the authentication work in the pipeline with renewed > vigor. The TCP Authentication Option which is proceeding in > parallel was cited several times. I thought Dave Ward was referrng to RFC 4107 (BCP 107) on automatic key management requirements. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From Donald.Eastlake@motorola.com Fri Mar 14 00:44:01 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2E4i182006349 for ; Fri, 14 Mar 2008 00:44:01 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2E4hnFi017332 for ; Fri, 14 Mar 2008 00:43:50 -0400 (EDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by mit.edu (Spam Firewall) with SMTP id 54517E451B6 for ; Fri, 14 Mar 2008 00:43:29 -0400 (EDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1205469807!813074!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 12364 invoked from network); 14 Mar 2008 04:43:28 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-128.messagelabs.com with SMTP; 14 Mar 2008 04:43:28 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m2E4hRds023965 for ; Thu, 13 Mar 2008 21:43:27 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id m2E4hR0v003302 for ; Thu, 13 Mar 2008 23:43:27 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id m2E4hQx1003298 for ; Thu, 13 Mar 2008 23:43:26 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Mar 2008 00:43:24 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790039CFE5D@de01exm64.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Report on the KMART BoF Thread-Index: AciFWvoU+p0v8tT9SFCeIimULVbNOwAMqsHw References: <3870C46029D1F945B1472F170D2D979003997154@de01exm64.ds.mot.com> From: "Eastlake III Donald-LDE008" To: "Pekka Savola" X-CFilter-Loop: Reflected X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m2E4i182006349 Cc: saag@mit.edu Subject: Re: [saag] Report on the KMART BoF X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2008 04:44:01 -0000 You're correct. Consider "3365" replaced by "4107" in my message. Sorry, Donald -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Thursday, March 13, 2008 6:38 PM To: Eastlake III Donald-LDE008 Cc: saag@mit.edu Subject: Re: [saag] Report on the KMART BoF On Thu, 13 Mar 2008, Eastlake III Donald-LDE008 wrote: > There was a desire for the Security > Area to revisit RFC 3365 with respect to the routing protocol > environment and for the Routing Area to pursue completion of > some of the authentication work in the pipeline with renewed > vigor. The TCP Authentication Option which is proceeding in > parallel was cited several times. I thought Dave Ward was referrng to RFC 4107 (BCP 107) on automatic key management requirements. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From Nicolas.Williams@sun.com Fri Mar 14 03:50:43 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2E7ohRR002898 for ; Fri, 14 Mar 2008 03:50:43 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2E7oX8M016943 for ; Fri, 14 Mar 2008 03:50:33 -0400 (EDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 0E7D2E246AE for ; Fri, 14 Mar 2008 03:50:12 -0400 (EDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2E7oBLH023182 for ; Fri, 14 Mar 2008 07:50:11 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m2E7oBip051648 for ; Fri, 14 Mar 2008 01:50:11 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2E7oBcM013153 for ; Fri, 14 Mar 2008 02:50:11 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2E7oBGI013152 for saag@mit.edu; Fri, 14 Mar 2008 02:50:11 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 14 Mar 2008 02:50:11 -0500 From: Nicolas Williams To: saag@mit.edu Message-ID: <20080314075010.GC986@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Thank you, Sam X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2008 07:50:43 -0000 Sam, First, I want to thank you for all your work as AD these past three years, to say nothing of your friendship for the past six. At today's SAAG meeting I was slightly confused by one of your slides, the one where you labelled BTNS IPsec interfaces work and channel bindings "successes." My first reaction was "but we're not done!" But as a hall conversation following SAAG showed me, we have indeed succeeded in some key respects: many now understand channel binding and its value and seek to apply it, and many understand that IPsec requires APIs, and simple APIs mind you, to be truly useful for end-to-end security. And then I think about how hard it was just to get the BTNS WG spun up. And I recall that you first suggested channel binding to IPsec as the solution for the NFS w/ RDDP security XOR performance issues, way back in March 2003, five years ago, almost to the day, at Connectathon '03. Now we're almost done with the relevant specs. No, we're not yet done with running code, but we'll get there too. Therefore I'm no longer confused, I believe you're correct, those have been successes, both, in merely getting started, and in getting them to be taken seriously. And I must say, none of that would have happened without your help for the past five years. But for my temporary confusion I would have stood up and said all this at the mic. Thank you so very much. I wish you all the best in your new endeavours, and look forward to seeing you again. Nico -- From housley@vigilsec.com Thu Mar 20 17:06:15 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2KL6EqC026683 for ; Thu, 20 Mar 2008 17:06:14 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m2KL64Fw007008 for ; Thu, 20 Mar 2008 17:06:04 -0400 (EDT) Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by mit.edu (Spam Firewall) with SMTP id 79663E39EF0 for ; Thu, 20 Mar 2008 17:05:43 -0400 (EDT) Received: (qmail 16774 invoked by uid 0); 20 Mar 2008 21:05:36 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.129.167) by woodstock.binhost.com with SMTP; 20 Mar 2008 21:05:36 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 20 Mar 2008 16:30:16 -0400 To: saag@mit.edu From: Russ Housley In-Reply-To: <1205980033.23519.6.camel@localhost> References: <1205980033.23519.6.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20080320210543.79663E39EF0@mit.edu> X-Spam-Score: 0.84 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Fwd: Proposed W3C Charter: XML Security Working Group (until 2008-05-02) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2008 21:06:16 -0000 What, if anything, does this mean for the XMLDSig work that was done in the IETF? At 10:27 PM 3/19/2008, Ian B. Jacobs wrote: >Hello, > >Today W3C Advisory Committee Representatives received a Proposal >to revise the Security Activity [0] (see the W3C Process >Document description of Activity Proposals [1]). This proposal >includes a draft charter for the XML Security Working Group: > http://www.w3.org/2008/02/xmlsec-charter > >As part of ensuring that the community is aware of proposed work >at W3C, this draft charter is public during the Advisory >Committee review period. > >W3C invites public comments through 2008-05-02 on the >proposed charter. Please send comments to >public-new-work-comments@w3.org, which has a public archive: > http://lists.w3.org/Archives/Public/public-new-work-comments/ > >Other than comments sent in formal responses by W3C Advisory >Committee Representatives, W3C cannot guarantee a response to >comments. If you work for a W3C Member [2], please coordinate >your comments with your Advisory Committee Representative. For >example, you may wish to make public comments via this list and >have your Advisory Committee Representative refer to it from his >or her formal review comments. > >If you should have any questions or need further information, please >contact Thomas Roessler, Security Activity Lead . > >Thank you, > >Ian Jacobs, Head of W3C Communications > >[0] http://www.w3.org/Security/ >[1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation >[2] http://www.w3.org/Consortium/Member/List > >-- >Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ >Tel: +1 718 260-9447 From tlr+bounce@w3.org Fri Mar 21 09:40:40 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2LDee43032628 for ; Fri, 21 Mar 2008 09:40:40 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2LDeV7B005675 for ; Fri, 21 Mar 2008 09:40:31 -0400 (EDT) Received: from homer.w3.org (ssh.w3.org [128.30.52.60]) by mit.edu (Spam Firewall) with ESMTP id 25430E6167C for ; Fri, 21 Mar 2008 09:40:09 -0400 (EDT) Received: from iCoaster.does-not-exist.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 709CA4F2A5; Fri, 21 Mar 2008 09:40:09 -0400 (EDT) Received: from tlr by iCoaster.does-not-exist.org with local (Exim 4.66) (envelope-from ) id JY31YW-001MMG-PZ; Fri, 21 Mar 2008 14:40:08 +0100 Date: Fri, 21 Mar 2008 14:40:08 +0100 From: Thomas Roessler To: Russ Housley Message-ID: <20080321134008.GZ577@iCoaster.does-not-exist.org> References: <1205980033.23519.6.camel@localhost> <20080320210543.79663E39EF0@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080320210543.79663E39EF0@mit.edu> User-Agent: Mutt/1.5.17 (2007-11-01) X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Fwd: Proposed W3C Charter: XML Security Working Group (until 2008-05-02) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2008 13:40:41 -0000 On 2008-03-20 16:30:16 -0400, Russ Housley wrote: > What, if anything, does this mean for the XMLDSig work that was > done in the IETF? It mostly means that there seemed to be critical mass for sorting out some referencing and transform model related issues at the W3C workshop last September, and that the community seems to agree that the current canonicalization model is really due for an overhaul. http://www.w3.org/2007/xmlsec/ws/report.html That workshop was announced on the saag list and at the Security Area meeting in Chicago; in fact, we deliberately aligned the position paper deadline so people could write and submit some *after* that meeting. I don't think many actually made use of that possibility. The workshop report was announced on saag in October. Note that the charter calls out close coordination with the IETF as an explicit requirement: The XML Signature specification was produced in a joint effort between W3C and the IETF. It is expected that the XML Security Working Group will liaise closely with the IETF Security and Application Areas in developing its deliverables. That said, if there are IETF participants who are specifically interested in this work and can't go the usual way through member companies, or if there are specific comments about the charter, please drop me a line. Regards, -- Thomas Roessler, W3C +33-4-89063488 > At 10:27 PM 3/19/2008, Ian B. Jacobs wrote: > > >Hello, > > > >Today W3C Advisory Committee Representatives received a Proposal > >to revise the Security Activity [0] (see the W3C Process > >Document description of Activity Proposals [1]). This proposal > >includes a draft charter for the XML Security Working Group: > > http://www.w3.org/2008/02/xmlsec-charter > > > >As part of ensuring that the community is aware of proposed work > >at W3C, this draft charter is public during the Advisory > >Committee review period. > > > >W3C invites public comments through 2008-05-02 on the > >proposed charter. Please send comments to > >public-new-work-comments@w3.org, which has a public archive: > > http://lists.w3.org/Archives/Public/public-new-work-comments/ > > > >Other than comments sent in formal responses by W3C Advisory > >Committee Representatives, W3C cannot guarantee a response to > >comments. If you work for a W3C Member [2], please coordinate > >your comments with your Advisory Committee Representative. For > >example, you may wish to make public comments via this list and > >have your Advisory Committee Representative refer to it from his > >or her formal review comments. > > > >If you should have any questions or need further information, please > >contact Thomas Roessler, Security Activity Lead . > > > >Thank you, > > > >Ian Jacobs, Head of W3C Communications > > > >[0] http://www.w3.org/Security/ > >[1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation > >[2] http://www.w3.org/Consortium/Member/List > > > >-- > >Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ > >Tel: +1 718 260-9447 > > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag > From Donald.Eastlake@motorola.com Fri Mar 28 09:10:32 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2SDAVFR024153 for ; Fri, 28 Mar 2008 09:10:31 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2SDAONW022191 for ; Fri, 28 Mar 2008 09:10:24 -0400 (EDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by mit.edu (Spam Firewall) with SMTP id 2FB72850FF9 for ; Fri, 28 Mar 2008 09:10:22 -0400 (EDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1206709821!3262344!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 29524 invoked from network); 28 Mar 2008 13:10:21 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-5.tower-128.messagelabs.com with SMTP; 28 Mar 2008 13:10:21 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m2SDAKiN003738 for ; Fri, 28 Mar 2008 06:10:20 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id m2SDAJGb027692 for ; Fri, 28 Mar 2008 08:10:20 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id m2SDAINq027674 for ; Fri, 28 Mar 2008 08:10:19 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Mar 2008 09:10:16 -0400 Message-ID: <3870C46029D1F945B1472F170D2D979003A56F7C@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: KMART Minutes Uploaded Thread-Index: AciQ1RDVps99zuVdR/K2UPWkmbMQFQ== From: "Eastlake III Donald-LDE008" To: , X-CFilter-Loop: Reflected X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m2SDAVFR024153 Subject: [saag] KMART Minutes Uploaded X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2008 13:10:32 -0000 Hi, Minutes have been uploaded to the IETF-71 Meeting Materials page for the KMART BoF. Thanks, Donald & Acee ==================================================== Donald E. Eastlake 3rd Motorola Laboratories 111 Locke Drive Marlborough, MA 01752 USA From max.rythmos@yahoo.com Sun Mar 30 06:37:23 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2UAbMOA015664 for ; Sun, 30 Mar 2008 06:37:23 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m2UAbAZC025157 for ; Sun, 30 Mar 2008 06:37:10 -0400 (EDT) Received: from web32906.mail.mud.yahoo.com (web32906.mail.mud.yahoo.com [209.191.69.83]) by mit.edu (Spam Firewall) with SMTP id 787AAD88276 for ; Sun, 30 Mar 2008 06:36:46 -0400 (EDT) Received: (qmail 72974 invoked by uid 60001); 30 Mar 2008 10:36:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=ZDANjgCFKoxRN3rmR34ROwDXeEbeDodTWIuk4k7wBTR5HXDbq8OPfhbklctaFqcZcutMOfnTLWjBgfaJ4wvLkgs0MJWGhj2o/QjNOmoV/fjKiA2L8Y+JOxda2Qy6sNY9PsrCDYoJWB8xLl2j8XY3776K1YzxoPI4or/4h78pfA4=; X-YMail-OSG: AnpJYKMVM1kVWhcPY1q8N6sCbms0ipgkK1SuVtMuzYJQ14t.LcRFFxnRGxBoKV6ZnmCDksoxC4mscw8KzJvNtFiKywAhIcZxw.eG9xqlsj8F1HkWmGegswx8qEf7oQ-- Received: from [80.126.106.22] by web32906.mail.mud.yahoo.com via HTTP; Sun, 30 Mar 2008 03:36:45 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 Date: Sun, 30 Mar 2008 03:36:45 -0700 (PDT) From: MARZIO VENEMAN To: saag@mit.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1503521000-1206873405=:72963" Message-ID: <594504.72963.qm@web32906.mail.mud.yahoo.com> X-Spam-Score: 0.14 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Fw: Earth Science webliography and utmost recommended social network USA (facebook - myspace) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2008 10:37:23 -0000 --0-1503521000-1206873405=:72963 Content-Type: text/plain; charset=us-ascii Rythmomachy is a member of GotoMy.com and is inviting you to join our new community site! Rythmomachy Says: WELCOM Join GotoMy.com and you will instantly be connected to the community of the future. Click here to visit my profile! http://rythmomachy.gotomy.com What is GotoMy.com? ========================== Is the online community web site of the future. GotoMy.com offers every member an affilaite system that lets them get a % of every ad they see, and every ad their friends see. Click here for more information! http://www.gotomy.com/affiliate/?memberid=804&tarid=Rythmomachy Join today and get! >> Your own custom profile >> create your own photo albums >> upload unlimited number of photos >> Easily created skins >> Edit your layout >> Stay connected with te community >> Write and recieve comments with friends >> Create unlimited blogs >> Join a club, or create your own >> And Much More... Get started today! http://www.gotomy.com/affiliate/?memberid=Rythmomachy You received this email because someone who knows you sent you an invitation to join them on GotoMy.com If you feel this is spam please contact us at admin@GotoMy.com Thank you ______________________ http://lists.tldp.org/ ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ --0-1503521000-1206873405=:72963 Content-Type: text/html; charset=us-ascii
Rythmomachy is a member of GotoMy.com and is inviting you to join our new community site!
                                            
                                            Rythmomachy Says:
                                           
                                            WELCOM
                                           
                                            Join GotoMy.com and you will instantly be connected to the community of the future.
                                           
                                            Click here to visit my profile!
                                            http://rythmomachy.gotomy.com
                                           
                                            What is GotoMy.com?
                                            ==========================
                                            Is the online community web site of the future.
                                            GotoMy.com offers every member an affilaite system that lets them
                                            get a % of every ad they see, and every ad their friends see.
                                           
                                            Click here for more information!
                                            http://www.gotomy.com/affiliate/?memberid=804&tarid=Rythmomachy 
                                            
                                            Join today and get!
                                            >> Your own custom profile
                                            >> create your own photo albums
                                            >> upload unlimited number of photos
                                            >> Easily created skins
                                            >> Edit your layout
                                            >> Stay connected with te community
                                            >> Write and recieve comments with friends
                                            >> Create unlimited blogs
                                            >> Join a club, or create your own
                                            >> And Much More...
                                           
                                            Get started today!
                                            http://www.gotomy.com/affiliate/?memberid=Rythmomachy 
                                            
                                            You received this email because someone who knows you
                                            sent you an invitation to join them on GotoMy.com

                                            If you feel this is spam please contact us at admin@GotoMy.com
                                            Thank you
     


______________________
http://lists.tldp.org/


Looking for last minute shopping deals? Find them fast with Yahoo! Search. --0-1503521000-1206873405=:72963-- From turners@ieca.com Tue Apr 1 11:58:11 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m31FwBLm023923 for ; Tue, 1 Apr 2008 11:58:11 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m31Fw1WP018056 for ; Tue, 1 Apr 2008 11:58:01 -0400 (EDT) Received: from smtp105.biz.mail.re2.yahoo.com (smtp105.biz.mail.re2.yahoo.com [206.190.52.174]) by mit.edu (Spam Firewall) with SMTP id A292CE9C038 for ; Tue, 1 Apr 2008 11:57:40 -0400 (EDT) Received: (qmail 73798 invoked from network); 1 Apr 2008 15:57:40 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@71.191.12.181 with login) by smtp105.biz.mail.re2.yahoo.com with SMTP; 1 Apr 2008 15:57:39 -0000 X-YMail-OSG: 3bSWDjwVM1nvWSbjWV5G6jiVdXXZVCb50r73fR_9IKw.9Nuv0Qx8CAKJotPcqu1F0JAyxh5nYg-- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: Date: Tue, 1 Apr 2008 11:56:02 -0400 Organization: IECA, Inc. Message-ID: <022601c89410$e2c72a30$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciUEOJZYEgR/wvfTSeBF42BXw903Q== X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] SMIME WG summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2008 15:58:12 -0000 This is a summary of the SMIME WG meeting held in Philadelphia as part of IETF 71. The S/MIME WG met immediately after SAAG on Thursday, March 13 2008. Mr. Turner provided a status overview of the WG: - There has been one new RFC since the last IETF: CAdES was published as RFC5126 - There is one ID with the RFC editor: draft-ietf-smime-symkeydist - There are two drafts working out IESG comments: draft-ietf-smime-ibarch and draft-ietf-smime-bfibecms - There are two drafts working out IETF LC comments: draft-ietf-smime-sha2 and draft-ietf-smime-multsig - There is one draft working out an IPR statement: draft-ietf-smime-rsa-kem - There are four active IDs in the working group: S/MIME MSG and CERT v3.2, an ASN.1 modules update, and an Update to ECC use with CMS. Mr. Turner presented the status of the S/MIME v3.2 IDs. The big change was to remove the ECC algorithms: ECDSA and ECDH from both IDs. The rationale was that they are IPR issues and they are better situated in an informational ID rather than the base IDs. The one remaining issue in the S/MIME v3.2 IDs is to settle on the key size text. The key size text will be discussed on the mailing list. Mr. Turner presented the status of the Update to ECC use with CMS ID. Updates to RFC 3278 include allowing the use of the SHA2 family of hash algorithms, adding the OIDS for these algorithms, and adding the OIDs for ECDSA with these algorithms. Comments are encourages as the ID is quite short. Mr. Schaad presented the status of the ASN.1 modules update ID. He indicated that no comments have been received since Vancouver and that more comments are requested. Mr. Shaad also gave presentation in PKIX on algorithm classes that applies to both PKIX and S/MIME. Ms..Shanin and Mr. Gennai, both from the Institute of Information Science and Technologies at the Italian National Research Council, presented Posta Elettronica Certificate (PEC). PEC, which is equivalent to Registered Mail service with a return receipt, was designed to address the Italian Government's decision to adopt electronic exchange of documents between its Public Administrations. Their presentation provided details on the message flow, transport message, and receipts. The WG suggested that the current state of affairs be drafted as an individual submission. From magnus.westerlund@ericsson.com Mon Apr 7 11:10:04 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m37FA4Xt009681 for ; Mon, 7 Apr 2008 11:10:04 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m37F9nRo018174 for ; Mon, 7 Apr 2008 11:09:49 -0400 (EDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 13518EA8028 for ; Mon, 7 Apr 2008 11:09:25 -0400 (EDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D4D2E210B5 for ; Mon, 7 Apr 2008 17:09:23 +0200 (CEST) X-AuditID: c1b4fb3e-b019cbb000004ec0-cc-47fa3923ecb9 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B9FDB21087 for ; Mon, 7 Apr 2008 17:09:23 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 17:09:23 +0200 Received: from [127.0.0.1] ([147.214.183.239]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 17:09:23 +0200 Message-ID: <47FA3922.1040101@ericsson.com> Date: Mon, 07 Apr 2008 17:09:22 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: SAAG X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 07 Apr 2008 15:09:23.0166 (UTC) FILETIME=[5CB6E7E0:01C898C1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] TSVWG last call on "UDP Usage Guidelines for Application Designers" to BCP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2008 15:10:04 -0000 Hi, I would like to inform that currently TSVWG has started the WG last call on "UDP Usage Guidelines for Application Designers" (draft-ietf-tsvwg-udp-guidelines-06) with the intended status of BCP. It runs until the 21st of April. If you like to provide any comments please send them to the TSVWG mailing list (tsvwg@ietf.org). Abstract: The User Datagram Protocol (UDP) provides a minimal, message-passing transport that has no inherent congestion control mechanisms. Because congestion control is critical to the stable operation of the Internet, applications and upper-layer protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and establish some degree of fairness with concurrent traffic. This document provides guidelines on the use of UDP for the designers of such applications and upper-layer protocols. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums and middlebox traversal. http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp-guidelines-06.txt Best Regards Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Färögatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From Manuel.A.Offenberg@seagate.com Mon Apr 7 12:27:36 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m37GRap8013300 for ; Mon, 7 Apr 2008 12:27:36 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m37GRQEJ006648 for ; Mon, 7 Apr 2008 12:27:27 -0400 (EDT) Received: from pps0.ok-ext.mailhost.seagate.com (pps0.ok-ext.mailhost.seagate.com [192.55.20.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 45D291018CEB for ; Mon, 7 Apr 2008 12:27:06 -0400 (EDT) Received: from sv-gw1.notes.seagate.com (sv-gw1.stsj.seagate.com [10.5.132.29]) by pps0ok.ok-ext.mailhost.seagate.com (8.13.7/8.13.7) with ESMTP id m37GR4js018219 for ; Mon, 7 Apr 2008 09:27:05 -0700 From: Manuel.A.Offenberg@seagate.com To: saag@mit.edu Message-ID: Date: Mon, 7 Apr 2008 09:27:00 -0700 X-MIMETrack: Serialize by Router on SV-GW1/Seagate Internet(Release 7.0.1 HF29|March 07, 2006) at 04/07/2008 09:27:05 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Proofpoint-FWRule: outbound2 X-Spam-Score: 0.776 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Manuel A Offenberg has limited access to email. X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2008 16:27:36 -0000 I will be out of the office starting 04/07/2008 and will not return until 04/11/2008. May have intermittent access to email. For emergencies, please contact me on my cell (415) 235 8917 or Jim Dykes at (720) 684-2601. Kind regards, Manuel Offenberg From hoepi42@gmail.com Wed Apr 16 17:55:56 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m3GLtuaR005515 for ; Wed, 16 Apr 2008 17:55:56 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m3GLtirG008769 for ; Wed, 16 Apr 2008 17:55:44 -0400 (EDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by mit.edu (Spam Firewall) with ESMTP id D47D9EDA546 for ; Wed, 16 Apr 2008 17:55:20 -0400 (EDT) Received: by wf-out-1314.google.com with SMTP id 23so3416181wfg.21 for ; Wed, 16 Apr 2008 14:55:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=shFojc8bnVHAqUXWM13ruqouj727/1qxPf+3tw8TRPY=; b=f89BWq0dcFCoDhhbxUe4Db7QT5UUohvSvoYmLQNF/8Tz7VjkI3Frg/hDPZEF9toDtko5OQWwpVgiKjsdubt+bd0wub2yfu0l0fWPZ9Pc+Q+AkGf40lz6hI0UJAZVJRrGVgf2ST8Y+AN8LguaRKsziGj6LX1xmwsLznqbOeXowUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=bJlUZnPVKdiB6S9yHjkwiArslVMbV9Wjv5AMDHyjvzepVWmt5m+cWd1ZlkASqBamGwTAtCex997NhQ9TWkYp8wd5wGqRRVJQ1SA38iS5cTqCsKYPKnC54hpQX8ONpRfleEWpZk0aohd3Rn5WbnNgkNYabWgBk9n/qxVsPkR8m0E= Received: by 10.142.68.14 with SMTP id q14mr155214wfa.290.1208382919969; Wed, 16 Apr 2008 14:55:19 -0700 (PDT) Received: by 10.142.232.11 with HTTP; Wed, 16 Apr 2008 14:55:19 -0700 (PDT) Message-ID: <98f5f260804161455v2ce83569l6e97fc9752d24c98@mail.gmail.com> Date: Wed, 16 Apr 2008 17:55:19 -0400 From: "=?ISO-8859-1?Q?Katrin_H=F6per?=" To: emu@ietf.org, hokey@ietf.org, saag@mit.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_24521_32487092.1208382919967" X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Invitation to subscribe to IETF proxy mailing list X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2008 21:55:56 -0000 ------=_Part_24521_32487092.1208382919967 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Security problems related to network proxies persistently come up in several IETF WGs and may affect the security of existing IETF network solutions while slowing down the progress of some current Internet Drafts. For this reason, Tim Polk and I organized an informal meeting in Philadelphia at IETF 71 to discuss these so-called "proxy problems" and their implications. As a result of our meeting, a proxy email list was created to further investigate the proxy problems. This email serves as an invitation to anybody interested to join our discussions on the list. Please subscribe at: https://www.ietf.org/mailman/listinfo/proxies Best regards, Katrin Hoeper ______________________________________________ Katrin Hoeper Computer Security Division National Institute of Standards and Technology (NIST) 100 Bureau Dr. Mail stop: 8930 Gaithersburg, MD 20878 (301) 975 - 4024 ------=_Part_24521_32487092.1208382919967 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Hi,

 

Security problems related to network proxies persistently come up in several IETF WGs and may affect the security of existing IETF network solutions while slowing down the progress of some current Internet Drafts.

 

For this reason, Tim Polk and I organized an informal meeting in Philadelphia at IETF 71 to discuss these so-called "proxy problems" and their implications. As a result of our meeting, a proxy email list was created to further investigate the proxy problems.

 

This email serves as an invitation to anybody interested to join our discussions on the list. Please subscribe at: https://www.ietf.org/mailman/listinfo/proxies

 

Best regards,

Katrin Hoeper

 ______________________________________________

Katrin Hoeper
Computer Security Division
National Institute of Standards and Technology (NIST)
100 Bureau Dr. Mail stop: 8930
Gaithersburg, MD 20878
(301) 975 - 4024

------=_Part_24521_32487092.1208382919967-- From rbarnes@bbn.com Wed Apr 16 22:22:23 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m3H2MNKe005935 for ; Wed, 16 Apr 2008 22:22:23 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m3H2M807007739 for ; Wed, 16 Apr 2008 22:22:08 -0400 (EDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by mit.edu (Spam Firewall) with ESMTP id BB67A107612D for ; Wed, 16 Apr 2008 22:21:44 -0400 (EDT) Received: from [128.89.255.16] (helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JmJkt-0000XD-6I; Wed, 16 Apr 2008 22:21:44 -0400 Message-ID: <4806B436.7030006@bbn.com> Date: Wed, 16 Apr 2008 22:21:42 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Katrin_H=F6per?= References: <98f5f260804161455v2ce83569l6e97fc9752d24c98@mail.gmail.com> In-Reply-To: <98f5f260804161455v2ce83569l6e97fc9752d24c98@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Invitation to subscribe to IETF proxy mailing list X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2008 02:22:23 -0000 Katrin, Could you clarify what type of "proxies" are being discussed on this list? What layers of the stack are you looking at? Network: Mobile IP Home Agents Transport: TURN servers Application: HTTP proxies, SIP proxies Or are you looking at the concept of proxying in general? The text of both messages in the list archive seemed pretty agnostic, but there were attachments discussing AAA proxies. Is AAA the focus of this list? --Richard Katrin Höper wrote: > Hi, > > > > Security problems related to network proxies persistently come up > in several IETF WGs and may affect the security of existing IETF network > solutions while slowing down the progress of some current Internet Drafts. > > > > For this reason, Tim Polk and I organized an informal meeting in > Philadelphia at IETF 71 to discuss these so-called "proxy problems" and > their implications. As a result of our meeting, a proxy email list was > created to further investigate the proxy problems. > > > > This email serves as an invitation to anybody interested to join > our discussions on the list. Please subscribe at: > https://www.ietf.org/mailman/listinfo/proxies > > > > Best regards, > > Katrin Hoeper > > ______________________________________________ > > Katrin Hoeper > Computer Security Division > National Institute of Standards and Technology (NIST) > 100 Bureau Dr. Mail stop: 8930 > Gaithersburg, MD 20878 > (301) 975 - 4024 > > > ------------------------------------------------------------------------ > > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag From aboba@internaut.com Thu Apr 17 01:58:33 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m3H5wXE1009271 for ; Thu, 17 Apr 2008 01:58:33 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m3H5wPdt016387 for ; Thu, 17 Apr 2008 01:58:26 -0400 (EDT) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 3DB2D107714B for ; Thu, 17 Apr 2008 01:58:05 -0400 (EDT) Received: from c-24-18-147-115.hsd1.mn.comcast.net ([24.18.147.115] helo=internaut.com) by mho-02-bos.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1JmN8G-00071N-Oy for saag@mit.edu; Thu, 17 Apr 2008 05:58:04 +0000 Received: by internaut.com (Postfix, from userid 1001) id BDA1D70D17; Wed, 16 Apr 2008 22:58:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id B012870B65 for ; Wed, 16 Apr 2008 22:58:03 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.18.147.115 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19jwaoL+FLtMP/wbs7ht8XU Date: Wed, 16 Apr 2008 22:58:03 -0700 (PDT) From: Bernard Aboba To: saag@mit.edu In-Reply-To: <4806B436.7030006@bbn.com> Message-ID: References: <98f5f260804161455v2ce83569l6e97fc9752d24c98@mail.gmail.com> <4806B436.7030006@bbn.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Invitation to subscribe to IETF proxy mailing list X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2008 05:58:33 -0000 > The text of both messages in the list archive seemed pretty agnostic, > but there were attachments discussing AAA proxies. Is AAA the focus of > this list? If so, why isn't this being handled in the O&M Area? From Manuel.A.Offenberg@seagate.com Thu Apr 17 13:22:49 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m3HHMnrm011004 for ; Thu, 17 Apr 2008 13:22:49 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m3HHMdGK010948 for ; Thu, 17 Apr 2008 13:22:40 -0400 (EDT) Received: from pps0.ok-ext.mailhost.seagate.com (pps0.ok-ext.mailhost.seagate.com [192.55.20.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 3ECF8DD15E1 for ; Thu, 17 Apr 2008 13:22:19 -0400 (EDT) Received: from sv-gw1.notes.seagate.com (sv-gw1.stsj.seagate.com [10.5.132.29]) by pps0ok.ok-ext.mailhost.seagate.com (8.13.7/8.13.7) with ESMTP id m3HHMHkc004748 for ; Thu, 17 Apr 2008 10:22:18 -0700 From: Manuel.A.Offenberg@seagate.com To: saag@mit.edu Message-ID: Date: Thu, 17 Apr 2008 10:22:09 -0700 X-MIMETrack: Serialize by Router on SV-GW1/Seagate Internet(Release 7.0.1 HF29|March 07, 2006) at 04/17/2008 10:22:18 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Proofpoint-FWRule: outbound2 X-Spam-Score: 0.962 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Manuel A Offenberg has limited access to email. X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2008 17:22:49 -0000 I will be out of the office starting 04/15/2008 and will not return until 04/18/2008. May have intermittent access to email. For emergencies, please contact me on my cell (415) 235 8917 or Jim Dykes at (720) 684-2601. Kind regards, Manuel Offenberg From hoepi42@gmail.com Thu Apr 17 15:31:15 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m3HJVFIT025756 for ; Thu, 17 Apr 2008 15:31:15 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m3HJV6QE019536 for ; Thu, 17 Apr 2008 15:31:06 -0400 (EDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by mit.edu (Spam Firewall) with ESMTP id 7F713DCD106 for ; Thu, 17 Apr 2008 15:30:40 -0400 (EDT) Received: by wf-out-1314.google.com with SMTP id 23so188074wfg.21 for ; Thu, 17 Apr 2008 12:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=W4yqnKIRW9rsU1LYb4zcImSWu0crda7cUPXCPFJMffw=; b=QswNj2qOyYbdGuyrjNAgLFC860Lq7dQuNpWt5Y/W1yIM3QLqVZrjLH9OF9fx37K/cjpiItwCE5mSvAcB9TVV1N7Ee43pynmD1pkr+UIFI2hvcoe5toK9cE4Hcbkm+Qo0ntRI4S/M+Ev7j4ppZa770gRinkmdZ0Z3eOa/xOHrpkc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=O3Ksx0mtWRro0Pv3UDAhZr58kshSNtVOI96GGdoSOjLIWva6/V3evpqMIbpE5tJFOYpVxQ1LC3+9GSeLIsJJsApPNGNR3mJv//lGY9hiaAeh6hmqBXKlWVmKbVOxJREjPaTChhMXq889hNjNXn9XsLR45s9uHJsD6AJTA9uIlM8= Received: by 10.142.246.8 with SMTP id t8mr527020wfh.31.1208460639817; Thu, 17 Apr 2008 12:30:39 -0700 (PDT) Received: by 10.142.232.11 with HTTP; Thu, 17 Apr 2008 12:30:39 -0700 (PDT) Message-ID: <98f5f260804171230j730a731fl8b877980ada635a1@mail.gmail.com> Date: Thu, 17 Apr 2008 15:30:39 -0400 From: "=?ISO-8859-1?Q?Katrin_H=F6per?=" To: "Richard Barnes" In-Reply-To: <4806B436.7030006@bbn.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1255_5721420.1208460639815" References: <98f5f260804161455v2ce83569l6e97fc9752d24c98@mail.gmail.com> <4806B436.7030006@bbn.com> X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Invitation to subscribe to IETF proxy mailing list X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2008 19:31:15 -0000 ------=_Part_1255_5721420.1208460639815 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello Richard, We decided to use AAA proxies as a starting point for our discussion for simplicity. In addition, people present at the initial meeting were most familar with these type of proxies and the security issues they introduce. The long-term (and ideal) goal of the list could be to extend the results o= f the AAA discussion in order to adress proxy-related security issues in general. However, for now we will focus on AAA proxies. Katrin On Wed, Apr 16, 2008 at 10:21 PM, Richard Barnes wrote: > Katrin, > > Could you clarify what type of "proxies" are being discussed on this list= ? > What layers of the stack are you looking at? > Network: Mobile IP Home Agents > Transport: TURN servers > Application: HTTP proxies, SIP proxies > Or are you looking at the concept of proxying in general? > > The text of both messages in the list archive seemed pretty agnostic, but > there were attachments discussing AAA proxies. Is AAA the focus of this > list? > > --Richard > > > > Katrin H=F6per wrote: > > > Hi, > > > > > > Security problems related to network proxies persistently come up in > > several IETF WGs and may affect the security of existing IETF network > > solutions while slowing down the progress of some current Internet Draf= ts. > > > > > > For this reason, Tim Polk and I organized an informal meeting in > > Philadelphia at IETF 71 to discuss these so-called "proxy problems" and > > their implications. As a result of our meeting, a proxy email list was > > created to further investigate the proxy problems. > > > > > > This email serves as an invitation to anybody interested to join our > > discussions on the list. Please subscribe at: > > https://www.ietf.org/mailman/listinfo/proxies > > > > > > Best regards, > > > > Katrin Hoeper > > > > ______________________________________________ > > > > Katrin Hoeper > > Computer Security Division > > National Institute of Standards and Technology (NIST) > > 100 Bureau Dr. Mail stop: 8930 > > Gaithersburg, MD 20878 > > (301) 975 - 4024 > > > > > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > saag mailing list > > saag@mit.edu > > http://mailman.mit.edu/mailman/listinfo/saag > > > > ------=_Part_1255_5721420.1208460639815 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hello Richard,
 
We decided to use AAA proxies as a starting point for our discussion f= or simplicity. In addition, people present at the initial meeting were most= familar with these type of proxies and the security issues they introduce.=
The long-term (and ideal) goal of the list could be to extend the= results of the AAA discussion in order to adress proxy-related security is= sues in general. However, for now we will focus on AAA proxies.
 
Katrin
On Wed, Apr 16, 2008 at 10:21 PM, Richard Barnes= <rbarnes@bbn.com> wrote:
Katrin,

Could you clarify= what type of "proxies" are being discussed on this list?  W= hat layers of the stack are you looking at?
Network: Mobile IP Home Agents
Transport: TURN servers
Application: H= TTP proxies, SIP proxies
Or are you looking at the concept of proxying i= n general?

The text of both messages in the list archive seemed pret= ty agnostic, but there were attachments discussing AAA proxies.  Is AA= A the focus of this list?

--Richard



Katrin H=F6per wrote:
Hi,

 
Security problems related to net= work proxies persistently come up in several IETF WGs and may affect the se= curity of existing IETF network solutions while slowing down the progress o= f some current Internet Drafts.

 
For this reason, Tim Polk and I organized an informal meeting= in Philadelphia at IETF 71 to discuss these so-called "proxy problems= " and their implications. As a result of our meeting, a proxy email li= st was created to further investigate the proxy problems.

 
This email serves as an invitation to anybody interested to j= oin our discussions on the list. Please subscribe at: https://www.ietf.org= /mailman/listinfo/proxies

 
Best regards,

Katrin Hoeper

 _____________= _________________________________

Katrin Hoeper
Computer Security= Division
National Institute of Standards and Technology (NIST)
100 B= ureau Dr. Mail stop: 8930
Gaithersburg, MD 20878
(301) 975 - 4024


---------= ---------------------------------------------------------------

____= ___________________________________________
saag mailing list
saag@mit.edu
= http://mailman.mit.edu/mailman/listinfo/saag


------=_Part_1255_5721420.1208460639815-- From paul.hoffman@vpnc.org Thu Apr 17 16:33:29 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m3HKXTem010987 for ; Thu, 17 Apr 2008 16:33:29 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m3HKXKds029668 for ; Thu, 17 Apr 2008 16:33:21 -0400 (EDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id CEC4F10955BD for ; Thu, 17 Apr 2008 16:32:31 -0400 (EDT) Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3HKWFUP099804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Apr 2008 13:32:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <98f5f260804171230j730a731fl8b877980ada635a1@mail.gmail.com> References: <98f5f260804161455v2ce83569l6e97fc9752d24c98@mail.gmail.com> <4806B436.7030006@bbn.com> <98f5f260804171230j730a731fl8b877980ada635a1@mail.gmail.com> Date: Thu, 17 Apr 2008 13:32:13 -0700 To: "Katrin Höper" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Barracuda-Header-Alert: BAD HEADER Non-encoded 8-bit data (char F6 hex) in message header 'To' To: "Katrin H\366per" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2008 20:33:29 -0000 >We decided to use AAA proxies as a starting point for our discussion >for simplicity. I don't remember the last time I read a sentence that contained both "AAA proxies" and "simplicity". >The long-term (and ideal) goal of the list could be to extend the >results of the AAA discussion in order to adress proxy-related >security issues in general. However, for now we will focus on AAA >proxies. Lots of application proxies have *very* different properties than AAA proxies. It will be interesting to see how much of the AAA work will be applicable. --Paul Hoffman, Director --VPN Consortium From Pasi.Eronen@nokia.com Tue Apr 22 05:00:12 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m3M90C0e025731 for ; Tue, 22 Apr 2008 05:00:12 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m3M9035h003748 for ; Tue, 22 Apr 2008 05:00:03 -0400 (EDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id C4DC188F971 for ; Tue, 22 Apr 2008 04:59:39 -0400 (EDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3M91tND002952; Tue, 22 Apr 2008 04:02:08 -0500 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Apr 2008 11:59:38 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Apr 2008 11:59:38 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 22 Apr 2008 11:59:37 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB726E051E@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Discussions about IPsec maintenance/extensions WG Thread-index: AcikVzD4A9afoy4RRI6lOoDeI+kviw== From: To: , X-OriginalArrivalTime: 22 Apr 2008 08:59:38.0792 (UTC) FILETIME=[31FE5280:01C8A457] X-Nokia-AV: Clean X-Spam-Score: 0.69 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m3M90C0e025731 Subject: [saag] Discussions about IPsec maintenance/extensions WG X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2008 09:00:12 -0000 Hi all, We're starting a discussion about the possibility of forming an IPsec maintenance/extensions working group. If you're interested, join the IPsec mailing list. Joining the list: http://www.ietf.org/mailman/listinfo/ipsec List archive: http://www.ietf.org/mail-archive/web/ipsec/current/maillist.html Best regards, Pasi From tim.polk@nist.gov Fri Apr 25 10:20:45 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m3PEKhdE022177 for ; Fri, 25 Apr 2008 10:20:43 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m3PEKZXp029220 for ; Fri, 25 Apr 2008 10:20:35 -0400 (EDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id B0B1A8F16F5; Fri, 25 Apr 2008 10:19:59 -0400 (EDT) Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m3PEJWjs020384; Fri, 25 Apr 2008 10:19:32 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0229AD28-4007-4DAA-A098-7201A7F81C41@nist.gov> Content-Transfer-Encoding: 7bit From: Tim Polk Date: Fri, 25 Apr 2008 10:19:40 -0400 To: emu@ietf.org, msec@ietf.org X-Mailer: Apple Mail (2.752.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: Lakshminath Dondeti , saag@mit.edu, "secdir@MIT.EDU" , Ran Canetti , Alan DeKok Subject: [saag] new co-chairs for emu and msec X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2008 14:20:46 -0000 Folks, Pasi and I are very pleased to announce that two of our co-chair vacancies have been filled. Alan Dekok has agreed to co-chair the EAP Method Update (emu) working group with Joe Salowey, who has been flying solo for some time now. Brian Weis will be co- chairing the Multicast Security (msec) working group; he is taking over for Ran Canetti. Lakshminath Dondeti has agreed to continue with msec for a bit longer, which we greatly appreciate. This will certainly smooth the transition, and it gives Pasi and I a bit more time to finalize things with a second co-chair for msec. We are really delighted that Alan and Brian have accepted these leadership positions, and are looking forward to working closely with them in the future. We also would like to thank everyone that threw their name into the hat. Pasi and I had the luxury of choosing between multiple highly qualified candidates. It is great to see how many people have the ability and desire to contribute in IETF leadership positions. Finally, we would like to thank everyone in the community that submitted nominations. Please stay tuned for future co-chair announcements for tls and msec. Thanks, Tim Polk and Pasi Eronen From gogwim@unijos.edu.ng Fri Apr 25 11:43:36 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m3PFhXME014578 for ; Fri, 25 Apr 2008 11:43:33 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m3PFhNRU004101 for ; Fri, 25 Apr 2008 11:43:24 -0400 (EDT) Received: from smtp.unijos.edu.ng (mail.unijos.edu.ng [82.206.136.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id C150D8B9E25; Fri, 25 Apr 2008 11:42:54 -0400 (EDT) Received: from localhost (smtp.unijos.edu.ng [127.0.0.1]) by smtp.unijos.edu.ng (Postfix) with ESMTP id 9DE9B6816D; Fri, 25 Apr 2008 16:37:37 +0100 (WAT) X-Spam-Score: 0.12 X-Spam-Status: No, score=-4.031 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.8, AWL=0.368, BAYES_00=-2.599] Received: from smtp.unijos.edu.ng ([127.0.0.1]) by localhost (smtp.unijos.edu.ng [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lg7tDfI5O4lT; Fri, 25 Apr 2008 16:37:28 +0100 (WAT) Received: from imap.unijos.edu.ng (imap.unijos.edu.ng [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.unijos.edu.ng (Postfix) with ESMTP id 3034768161; Fri, 25 Apr 2008 16:37:28 +0100 (WAT) Received: from mail.unijos.edu.ng (localhost [127.0.0.1]) by imap.unijos.edu.ng (Postfix) with ESMTP id 1CA1C28106; Fri, 25 Apr 2008 16:44:47 +0100 (WAT) Received: from 192.168.192.232 (SquirrelMail authenticated user gogwim) by mail.unijos.edu.ng with HTTP; Fri, 25 Apr 2008 16:44:47 +0100 (WAT) Message-ID: <51428.192.168.192.232.1209138287.squirrel@mail.unijos.edu.ng> In-Reply-To: <0229AD28-4007-4DAA-A098-7201A7F81C41@nist.gov> References: <0229AD28-4007-4DAA-A098-7201A7F81C41@nist.gov> Date: Fri, 25 Apr 2008 16:44:47 +0100 (WAT) From: "GOGWIM, JOEL GODWIN" To: "Tim Polk" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: msec@ietf.org, Lakshminath Dondeti , emu@ietf.org, saag@mit.edu, "secdir@MIT.EDU" , Ran Canetti , Alan DeKok Subject: Re: [saag] new co-chairs for emu and msec X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: gogwim@unijos.edu.ng List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2008 15:43:36 -0000 You are welcome on the chairs and big congratulations while anticipating your able leadership. Thank you, ^^Gogwim,Joel. On Fri, April 25, 2008 3:19 pm, Tim Polk said: > Folks, > > Pasi and I are very pleased to announce that two of our co-chair > vacancies have been filled. > > Alan Dekok has agreed to co-chair the EAP Method Update (emu) working > group with Joe Salowey, > who has been flying solo for some time now. Brian Weis will be co- > chairing the Multicast Security > (msec) working group; he is taking over for Ran Canetti. > Lakshminath Dondeti has agreed to continue > with msec for a bit longer, which we greatly appreciate. This will > certainly smooth the transition, and > it gives Pasi and I a bit more time to finalize things with a second > co-chair for msec. > > We are really delighted that Alan and Brian have accepted these > leadership positions, and are looking > forward to working closely with them in the future. We also would > like to thank everyone that threw their > name into the hat. Pasi and I had the luxury of choosing between > multiple highly qualified candidates. > It is great to see how many people have the ability and desire to > contribute in IETF leadership positions. > Finally, we would like to thank everyone in the community that > submitted nominations. > > Please stay tuned for future co-chair announcements for tls and msec. > > Thanks, > > Tim Polk and Pasi Eronen > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag > From ldondeti@qualcomm.com Fri Apr 25 12:14:55 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m3PGEtie024831 for ; Fri, 25 Apr 2008 12:14:55 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m3PGEiCx001295 for ; Fri, 25 Apr 2008 12:14:44 -0400 (EDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 54E2F8F3417; Fri, 25 Apr 2008 12:14:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1209140075; x=1240676075; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<48120367.8090307@qualcomm.com>|Date:=20Fr i,=2025=20Apr=202008=2009:14:31=20-0700|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Thun derbird=202.0.0.12=20(Windows/20080213)|MIME-Version:=201 .0|To:=20Alan=20DeKok=20,=20Br ian=20Weis=20|CC:=20Tim=20Polk=20,=20emu@ietf.org,=20msec@ietf.org,=0D=0A=20=20 =20=20=20=20=20=20"secdir@MIT.EDU"=20,=20 saag@mit.edu,=0D=0A=20=20=20=20=20=20=20=20Pasi=20Eronen =20,=0D=0A=20=20=20=20=20=20=20=20 Ran=20Canetti=20|Subject:=20Re: =20new=20co-chairs=20for=20emu=20and=20msec|References: =20<0229AD28-4007-4DAA-A098-7201A7F81C41@nist.gov> |In-Reply-To:=20<0229AD28-4007-4DAA-A098-7201A7F81C41@nis t.gov>|Content-Type:=20text/plain=3B=20charset=3DISO-8859 -15=3B=20format=3Dflowed|Content-Transfer-Encoding:=207bi t|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,5282"=3B=20 a=3D"2699423"; bh=foj0P28z/Z4uuNmaP7fEqfTVVBbdlmjRyL6+V1cwrT8=; b=I3SRsvBniR9bR4mAKAhhx9iEvXDSU9AiuZ326vhjwQKCJKvKEr9/D82N 4gn+T7b+ISFp8c6FMlHtm3CSnFXrArp6eF1x2cjegS8b7McI3yTHu1UOB LVYfaEtHe7Ls841uW3GziaLqzRsqpKfPbqDD4YJhGCBorPHYGbzVIgtug U=; X-IronPort-AV: E=McAfee;i="5100,188,5282"; a="2699423" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Apr 2008 09:14:33 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m3PGEX8J011300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Apr 2008 09:14:33 -0700 Received: from [10.50.64.103] (qconnect-10-50-64-103.qualcomm.com [10.50.64.103]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m3PGEV3A025356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 25 Apr 2008 09:14:32 -0700 Message-ID: <48120367.8090307@qualcomm.com> Date: Fri, 25 Apr 2008 09:14:31 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Alan DeKok , Brian Weis References: <0229AD28-4007-4DAA-A098-7201A7F81C41@nist.gov> In-Reply-To: <0229AD28-4007-4DAA-A098-7201A7F81C41@nist.gov> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: msec@ietf.org, emu@ietf.org, saag@mit.edu, Tim Polk , "secdir@MIT.EDU" , Ran Canetti Subject: Re: [saag] new co-chairs for emu and msec X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2008 16:14:55 -0000 Congratulations to Alan and Brian. Thanks for taking on these responsibilities. best wishes, Lakshminath On 4/25/2008 7:19 AM, Tim Polk wrote: > Folks, > > Pasi and I are very pleased to announce that two of our co-chair > vacancies have been filled. > > Alan Dekok has agreed to co-chair the EAP Method Update (emu) working > group with Joe Salowey, > who has been flying solo for some time now. Brian Weis will be > co-chairing the Multicast Security > (msec) working group; he is taking over for Ran Canetti. Lakshminath > Dondeti has agreed to continue > with msec for a bit longer, which we greatly appreciate. This will > certainly smooth the transition, and > it gives Pasi and I a bit more time to finalize things with a second > co-chair for msec. > > We are really delighted that Alan and Brian have accepted these > leadership positions, and are looking > forward to working closely with them in the future. We also would like > to thank everyone that threw their > name into the hat. Pasi and I had the luxury of choosing between > multiple highly qualified candidates. > It is great to see how many people have the ability and desire to > contribute in IETF leadership positions. > Finally, we would like to thank everyone in the community that submitted > nominations. > > Please stay tuned for future co-chair announcements for tls and msec. > > Thanks, > > Tim Polk and Pasi Eronen > From tim.polk@nist.gov Tue Apr 29 15:16:26 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m3TJGQHv007603 for ; Tue, 29 Apr 2008 15:16:26 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m3TJGEI2000137 for ; Tue, 29 Apr 2008 15:16:14 -0400 (EDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id F07068BFD64 for ; Tue, 29 Apr 2008 15:15:43 -0400 (EDT) Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m3TJFlWu019436; Tue, 29 Apr 2008 15:15:47 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <05449595-C56F-4B1F-867C-CBE4FFD00EC5@nist.gov> Content-Transfer-Encoding: 7bit From: Tim Polk Date: Tue, 29 Apr 2008 15:15:51 -0400 To: saag@mit.edu X-Mailer: Apple Mail (2.752.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov X-Spam-Score: 0.13 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Minutes for SAAG session uploaded X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2008 19:16:26 -0000 Folks, I finally got minutes for the SAAG session from IETF 71 completed and uploaded. I'm afraid that leaves just 24 hours to review and submit comments. If I have misrepresented anyone, please let me know by noon tomorrow (Eastern) and I will correct the mistakes. The draft minutes are available at http://www.ietf.org/proceedings/ 08mar/minutes/saag.txt Thanks, Tim Polk From sandy@tislabs.com Wed Apr 30 15:44:50 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m3UJioF4019313 for ; Wed, 30 Apr 2008 15:44:50 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m3UJieL5021205 for ; Wed, 30 Apr 2008 15:44:40 -0400 (EDT) Received: from nutshell.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by mit.edu (Spam Firewall) with ESMTP id E7FFBDFC7AD for ; Wed, 30 Apr 2008 15:44:08 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id m3UJfHff005781; Wed, 30 Apr 2008 15:41:17 -0400 (EDT) Received: from nodnsquery(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAJvaGsl; Wed, 30 Apr 08 15:41:17 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 4A3323F477; Wed, 30 Apr 2008 15:44:11 -0400 (EDT) To: saag@mit.edu, tim.polk@nist.gov In-Reply-To: <05449595-C56F-4B1F-867C-CBE4FFD00EC5@nist.gov> Message-Id: <20080430194411.4A3323F477@pecan.tislabs.com> Date: Wed, 30 Apr 2008 15:44:11 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: sandy@tislabs.com Subject: Re: [saag] Minutes for SAAG session uploaded X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2008 19:44:50 -0000 >I'm afraid that leaves just 24 hours to review and submit >comments. And to respond to comments, unfortunately. In the discussion of the kmart bof, the following paragraph is cut off abruptly: There were good presentations by Routing and Security Area Directors, discussions of link state routing, threats, and key management. There seems to be agreement that there are four problems and three are probably pretty easy. The fourth is a multicast problem, and is generally generally ... considered more difficult? ignored? not handled well? I'm trying to listen to the audio archives to figure out what this was supposed to be. Or Donald could tell us what he remembers saying. --Sandy From Donald.Eastlake@motorola.com Wed Apr 30 16:00:54 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m3UK0sk8024651 for ; Wed, 30 Apr 2008 16:00:54 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m3UK0jFj017377 for ; Wed, 30 Apr 2008 16:00:45 -0400 (EDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by mit.edu (Spam Firewall) with SMTP id 5EC718B078C for ; Wed, 30 Apr 2008 16:00:12 -0400 (EDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1209585618!9405748!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 1438 invoked from network); 30 Apr 2008 20:00:18 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-153.messagelabs.com with SMTP; 30 Apr 2008 20:00:18 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m3UK0HdV025636 for ; Wed, 30 Apr 2008 13:00:17 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id m3UK0HKL014646 for ; Wed, 30 Apr 2008 15:00:17 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id m3UK0GOn014639 for ; Wed, 30 Apr 2008 15:00:16 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 30 Apr 2008 16:00:15 -0400 Message-ID: <3870C46029D1F945B1472F170D2D979003C166A0@de01exm64.ds.mot.com> In-Reply-To: <20080430194411.4A3323F477@pecan.tislabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Minutes for SAAG session uploaded thread-index: Aciq/Bsw82oETpaJSxGEhTezkvnHkwAAJdcQ References: <05449595-C56F-4B1F-867C-CBE4FFD00EC5@nist.gov> <20080430194411.4A3323F477@pecan.tislabs.com> From: "Eastlake III Donald-LDE008" To: "Sandy Murphy" X-CFilter-Loop: Reflected X-Spam-Score: 3.7 X-Spam-Level: *** (3.7) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m3UK0sk8024651 Cc: saag@mit.edu Subject: Re: [saag] Minutes for SAAG session uploaded X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2008 20:00:54 -0000 Well, I send in the following minor tweak to fix that: >>>> Donald Eastlake presenting for KMART > > The KMART BOF was anticipated to be very interesting, as in very > controversial. In fact, the BOF was more successful than anticipated > which led to it being less exciting perhaps. > > There were good presentations by Routing and Security Area Directors, > discussions of link state routing, threats, and key management. There > seems to be agreement that there are four problems and three are > probably pretty easy. The fourth is a multicast problem, and is > generally considered a research topic. > > Tim Polk thanked Don for taking the lead. He was very encouraged that > many people thought there should have been a charter discussion. > While > Tim felt that was premature, and that we really needed that exchange > of background ideas instead of charter work, but he considered it a > very good sign for long range work. Donald -----Original Message----- From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of Sandy Murphy Sent: Wednesday, April 30, 2008 3:44 PM To: saag@mit.edu; tim.polk@nist.gov Cc: sandy@tislabs.com Subject: Re: [saag] Minutes for SAAG session uploaded >I'm afraid that leaves just 24 hours to review and submit >comments. And to respond to comments, unfortunately. In the discussion of the kmart bof, the following paragraph is cut off abruptly: There were good presentations by Routing and Security Area Directors, discussions of link state routing, threats, and key management. There seems to be agreement that there are four problems and three are probably pretty easy. The fourth is a multicast problem, and is generally generally ... considered more difficult? ignored? not handled well? I'm trying to listen to the audio archives to figure out what this was supposed to be. Or Donald could tell us what he remembers saying. --Sandy _______________________________________________ saag mailing list saag@mit.edu http://mailman.mit.edu/mailman/listinfo/saag From sandy@tislabs.com Wed Apr 30 16:09:24 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m3UK9O1r027207 for ; Wed, 30 Apr 2008 16:09:24 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m3UK994a015609 for ; Wed, 30 Apr 2008 16:09:09 -0400 (EDT) Received: from nutshell.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by mit.edu (Spam Firewall) with ESMTP id DF71EEF482B for ; Wed, 30 Apr 2008 16:08:37 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id m3UK5kvu005821; Wed, 30 Apr 2008 16:05:46 -0400 (EDT) Received: from nodnsquery(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAH7aGxl; Wed, 30 Apr 08 16:05:46 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 194C13F46C; Wed, 30 Apr 2008 16:08:40 -0400 (EDT) To: Donald.Eastlake@motorola.com In-Reply-To: <3870C46029D1F945B1472F170D2D979003C166A0@de01exm64.ds.mot.com> Message-Id: <20080430200840.194C13F46C@pecan.tislabs.com> Date: Wed, 30 Apr 2008 16:08:40 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Minutes for SAAG session uploaded X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2008 20:09:25 -0000 >Well, I send in the following minor tweak to fix that: Sorry, I didn't know. Apologies for the unnecessary bother-age. --Sandy From llchen@nist.gov Fri May 2 11:32:31 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m42FWVKY031386 for ; Fri, 2 May 2008 11:32:31 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m42FWJT4006522 for ; Fri, 2 May 2008 11:32:19 -0400 (EDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 653B79254D9 for ; Fri, 2 May 2008 11:32:13 -0400 (EDT) Received: from chamber.nist.gov (spock.ncsl.nist.gov [129.6.54.37]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m42FW8QB004276 for ; Fri, 2 May 2008 11:32:08 -0400 Message-Id: <7.0.1.0.2.20080502112647.0254ac90@nist.gov> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 02 May 2008 11:32:07 -0400 To: saag@mit.edu From: Lily Chen Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_357600828==.ALT" X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: llchen@nist.gov X-Spam-Score: 0.14 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Fri, 02 May 2008 14:18:30 -0400 Subject: [saag] NIST Draft SP 800-108 for public comments X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2008 15:32:32 -0000 --=====================_357600828==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear Colleagues: I apologize if you have received this e-mail multiple times. NIST announces the release of draft Special Publication 800-108, Recommendation for Key Derivation Using Pseudorandom Functions. This Recommendation specifies techniques for key derivation from a secret key using pseudorandom functions (PRF). Please submit comments to draft-SP800-108-comment@nist.gov with "Comments on SP800-108" in the subject line. The comment period closes on June 28, 2008. You can find the draft at http://csrc.nist.gov/publications/drafts/800-108/Draft_SP-800-108_April-2008.pdf Regards, Lily Lily Chen Computer Security Division National Institute of Standards and Technology (NIST) 100 Bureau Dr. Mail stop: 8930 Gaithersburg, MD 20878 (301) 975 - 6974 --=====================_357600828==.ALT Content-Type: text/html; charset="us-ascii" Dear Colleagues:

I apologize if you have received this e-mail multiple times. 

NIST announces the release of draft Special Publication 800-108, Recommendation for Key Derivation Using Pseudorandom Functions. This Recommendation specifies techniques for key derivation from a secret key using pseudorandom functions (PRF). Please submit comments to draft-SP800-108-comment@nist.gov with "Comments on SP800-108" in the subject line. The comment period closes on June 28, 2008.

You can find the draft at http://csrc.nist.gov/publications/drafts/800-108/Draft_SP-800-108_April-2008.pdf

Regards,

Lily

Lily Chen
Computer Security Division
National Institute of Standards and Technology (NIST)
100 Bureau Dr. Mail stop: 8930
Gaithersburg, MD 20878
(301) 975 - 6974
 --=====================_357600828==.ALT-- From Pasi.Eronen@nokia.com Wed May 7 05:13:02 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m479D2Cg018958 for ; Wed, 7 May 2008 05:13:02 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m479CqvZ002046 for ; Wed, 7 May 2008 05:12:53 -0400 (EDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id E7AF5E0C13B; Wed, 7 May 2008 05:12:31 -0400 (EDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m479CLrx018792; Wed, 7 May 2008 12:12:25 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 May 2008 12:12:22 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 May 2008 12:12:21 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 7 May 2008 12:12:24 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB728D59D7@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New co-chair for TLS Thread-index: AciwInbTASwjoLygSnGzlAcxOy52xg== From: To: , , X-OriginalArrivalTime: 07 May 2008 09:12:21.0680 (UTC) FILETIME=[74E80B00:01C8B022] X-Nokia-AV: Clean X-Spam-Score: 0.57 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m479D2Cg018958 Subject: [saag] New co-chair for TLS X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2008 09:13:02 -0000 Folks, Tim and I are happy to announce that Joe Salowey has agreed to co-chair the Transport Layer Security (TLS) working group. Joe takes over from Pasi, who will in turn take over Tim's role as the responsible AD for TLS WG. We had a number of qualified candidates, and we would like to thank everyone in the community who volunteered or submitted nominations. Pasi Eronen & Tim Polk From tim.polk@nist.gov Wed May 7 10:01:20 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m47E1K7m011772 for ; Wed, 7 May 2008 10:01:20 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m47E16WJ026819 for ; Wed, 7 May 2008 10:01:06 -0400 (EDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id EA72BF1E5B7 for ; Wed, 7 May 2008 10:00:41 -0400 (EDT) Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m47E0WpT018739; Wed, 7 May 2008 10:00:32 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) References: <7.0.1.0.2.20080506160054.0251ad30@nist.gov> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <89EDB6AD-61F0-4D14-9AF7-F4A79AE2481F@nist.gov> Content-Transfer-Encoding: 7bit From: Tim Polk Date: Wed, 7 May 2008 10:00:36 -0400 To: saag@mit.edu, S-MIME / IETF X-Mailer: Apple Mail (2.752.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov X-Spam-Score: 0.13 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Fwd: NIST Identity-Based Encryption Workshop- Registration Deadline Approaching X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2008 14:01:20 -0000 Folks, My apologies for a brief advertisement... I am forwarding this workshop announcement since IBE documents are currently progressing through one of the security area working groups, and because I am always anxious to see the needs of the Internet community considered by NIST in our standardization activities. Attendance is one way to ensure your voice is heard. If you have a strong opinion about IBE and are unable to attend, please let me know so I can pass it along! Note that the early registration fee is only available through the end of the week. Thanks, Tim Polk Begin forwarded message: > From: Andrew Regenscheid > Date: May 6, 2008 4:08:35 PM EDT > To: Multiple recipients of list > Subject: NIST Identity-Based Encryption Workshop- Registration > Deadline Approaching > Reply-To: ibe@nist.gov > > > Applications of Pairing-Based Cryptography: Identity-Based > Encryption and Beyond > June 3-4, 2008 > NIST, Gaithersburg, MD > > The early registration deadline is approaching! Please join us at > the workshop and help NIST direct its future work on identity-based > encryption. > > This workshop brings together academia, government and industry to > explore innovative and practical applications of pairing-based > cryptography. Pairings have been used to create identity-based > encryption schemes, but are also a powerful tool for solving other > cryptographic problems. We hope to encourage the development of > new security applications and communication between researchers, > developers and users. In addition to presentations, the workshop > will facilitate panel discussions among invited experts and > workshop participants. NIST will seek guidance from workshop > presenters, panelists and attendees to direct its future work in > this area of cryptography, including possible standards work. > > Dr. Matt Franklin, co-inventor of one of the original identity- > based encryption schemes, will be presenting a keynote address > entitled "An Introduction to Identity Based Encryption." Dr. Brent > Waters will be presenting a keynote address entitled "Functional > Encryption: Beyond Public Key Cryptography." The workshop program > also includes two panel discussions and 13 presentations from > researchers from around the world. The complete agenda has been > posted at http://www.nist.gov/ibe. > > The early registration deadline for the NIST Applications of > Pairing Based Cryptography workshop is quickly approaching. The > registration fee is $110 until May 10th, and $145 until May 27th. > Please note that these fees have been reduced due to NIST no longer > being able to provide food and beverages. Voltage Security and > Trend Micro will be sponsoring the morning and afternoon breaks. > However, each attendee will be responsible for his/her own lunch. > NIST has a full-service cafeteria adjacent to the Green Auditorium. > Please note the cafeteria does not take any credit or debit cards. > Please be prepared with cash. > > More details on the workshop are available at http://www.nist.gov/ibe > > > From paul.hoffman@vpnc.org Wed May 7 10:59:17 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m47ExHZ8029425 for ; Wed, 7 May 2008 10:59:17 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m47Ex6pT024414 for ; Wed, 7 May 2008 10:59:06 -0400 (EDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 1E91BE2772F for ; Wed, 7 May 2008 10:58:39 -0400 (EDT) Received: from [165.227.249.202] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m47Ewa3B073128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 May 2008 07:58:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <89EDB6AD-61F0-4D14-9AF7-F4A79AE2481F@nist.gov> References: <7.0.1.0.2.20080506160054.0251ad30@nist.gov> <89EDB6AD-61F0-4D14-9AF7-F4A79AE2481F@nist.gov> Date: Wed, 7 May 2008 07:58:34 -0700 To: saag@mit.edu From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.65 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Fwd: NIST Identity-Based Encryption Workshop- Registration Deadline Approaching X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2008 14:59:17 -0000 At 10:00 AM -0400 5/7/08, Tim Polk wrote: > > Applications of Pairing-Based Cryptography: Identity-Based >> Encryption and Beyond >> June 3-4, 2008 >> NIST, Gaithersburg, MD I already sent this to the S/MIME WG, but of related interest to this topic is a recent IPR statement: --Paul Hoffman, Director --VPN Consortium From housley@vigilsec.com Wed May 7 11:57:00 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m47Fv0Ea014260 for ; Wed, 7 May 2008 11:57:00 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m47FumH8028540 for ; Wed, 7 May 2008 11:56:48 -0400 (EDT) Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by mit.edu (Spam Firewall) with SMTP id 9F5F4F05863 for ; Wed, 7 May 2008 11:56:24 -0400 (EDT) Received: (qmail 11119 invoked by uid 0); 7 May 2008 15:56:20 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.129.167) by woodstock.binhost.com with SMTP; 7 May 2008 15:56:20 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 07 May 2008 11:56:18 -0400 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Message-Id: <20080507155624.9F5F4F05863@mit.edu> X-Spam-Score: 2.736 X-Spam-Level: ** (2.736) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] NIST requests public comments X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2008 15:57:00 -0000

Date: Wed, 07 May 2008 08:30:40 -0400
To: llchen@nist.gov
From: Elaine Barker <elaine.barker@nist.gov>
Subject: NIST requests public comments

NIST announces the release of draft Special Publication 800-108, Recommendation for Key Derivation Using Pseudorandom Functions. This Recommendation specifies techniques for key derivation from a secret key using pseudorandom functions (PRF). Please submit comments to draft-SP800-108-comment@nist.gov with "Comments on SP800-108" in the subject line. The comment period closes on June 28, 2008.

You can access the draft at http://csrc.nist.gov/publications/drafts/800-108/Draft_SP-800-108_April-2008.pdf

Elaine Barker
National Institute of Standards and Technology
100 Bureau Drive, Stop 8930
Gaithersburg, MD 20899-8930
From tlr+bounce@w3.org Mon Jun 2 09:27:54 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m52DRshp021347 for ; Mon, 2 Jun 2008 09:27:54 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m52DRiju003453 for ; Mon, 2 Jun 2008 09:27:44 -0400 (EDT) Received: from homer.w3.org (ssh.w3.org [128.30.52.60]) by mit.edu (Spam Firewall) with ESMTP id 9BCFE92E56F for ; Mon, 2 Jun 2008 09:27:17 -0400 (EDT) Received: from iCoaster.does-not-exist.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 243AF4F4CF; Mon, 2 Jun 2008 09:27:17 -0400 (EDT) Received: from tlr by iCoaster.does-not-exist.org with local (Exim 4.66) (envelope-from ) id K1U81G-001LGQ-HM; Mon, 02 Jun 2008 15:27:16 +0200 Date: Mon, 2 Jun 2008 15:27:16 +0200 From: Thomas Roessler To: saag@mit.edu Message-ID: <20080602132716.GF553@iCoaster.does-not-exist.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: frederick.hirsch@nokia.com Subject: [saag] W3C charters XML Security Working Group X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 13:27:54 -0000 Hello, the W3C has chartered a new XML Security Working Group: http://www.w3.org/2008/xmlsec http://www.w3.org/2008/02/xmlsec-charter The Group is tasked to take next steps with the XML Signature and XML Encryption family of specifications, as discussed at the workshop last September: http://www.w3.org/2007/xmlsec/ws/ If you're interested in this work and work for a W3C member organization, please contact your Advisory Committee Representative. If you don't know who that is, I'll be happy to make introductions. If you're interested, but don't work for a W3C member organization, please contact Frederick Hirsch (chair) and myself. Thanks, -- Thomas Roessler, W3C +33-4-89063488 From Craemer@isoc.org Mon Jun 2 14:33:30 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m52IXUlQ016804 for ; Mon, 2 Jun 2008 14:33:30 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m52IXFBK001074 for ; Mon, 2 Jun 2008 14:33:17 -0400 (EDT) Received: from smtp140.iad.emailsrvr.com (smtp140.iad.emailsrvr.com [207.97.245.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 6057DF687C5 for ; Mon, 2 Jun 2008 14:32:51 -0400 (EDT) Received: from relay4.r5.iad.mlsrvr.com (localhost [127.0.0.1]) by relay4.r5.iad.mlsrvr.com (SMTP Server) with ESMTP id E7C1DDF14 for ; Mon, 2 Jun 2008 14:32:50 -0400 (EDT) Received: by relay4.r5.iad.mlsrvr.com (Authenticated sender: craemer-AT-isoc.org) with ESMTP id D41F3DF04 for ; Mon, 2 Jun 2008 14:32:50 -0400 (EDT) From: "Kevin Craemer" To: Date: Mon, 2 Jun 2008 14:32:50 -0400 Message-ID: <000b01c8c4df$0ff896c0$e501a8c0@ISOC.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjE3w9WBebyC+wFRv+5IUpLiXq0uQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.14 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Mon, 02 Jun 2008 14:50:54 -0400 Subject: [saag] Network & Distributed System Security Symposium - Call for Papers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 18:33:30 -0000 Please consider responding to this Call for Papers. Kevin Craemer Internet Society = = = = = = = = = CALL FOR PAPERS Network and Distributed System Security Symposium (NDSS '09) The Catamaran Resort Hotel and Spa San Diego, California February 8-11, 2009 Submissions due: September 12, 2008 NDSS fosters information exchange among research scientists and practitioners of network and distributed system security services. The target audience includes those interested in practical aspects of network and distributed system security, with a focus on actual system design and implementation (rather than theory). A major goal is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. The proceedings are published by the Internet Society. Submissions are solicited in, but not limited to, the following areas: - Security of Web-based applications and services. - Anti-malware techniques: detection, analysis, prevention. - Intrusion prevention, detection, and response. - Security for electronic voting. - Combating cyber-crime: anti-phishing, anti-spam, anti-fraud techniques. - Privacy and anonymity technologies. - Network perimeter controls: firewalls, packet filters, application gateways. - Security for emerging technologies: sensor networks, wireless/mobile (and ad hoc) networks, personal communication systems. - Security for peer-to-peer and overlay network systems. - Security for electronic commerce: e.g., payment, barter, EDI, notarization, timestamping, endorsement, and licensing. - Implementation, deployment and management of network security policies. - Intellectual property protection: protocols, implementations, metering, watermarking, digital rights management. - Integrating security services with system and application security facilities and protocols. - Public key infrastructures, key management, certification, and revocation. - Special problems and case studies: e.g., tradeoffs between security and efficiency, usability, reliability and cost. - Security for collaborative applications: teleconferencing and video-conferencing. - Software hardening: e.g., detecting and defending against software bugs (overflows, etc.) - Security for large-scale systems and critical infrastructures. - Integrating security in Internet protocols: routing, naming, network management. For more information, please see http://www.isoc.org/isoc/conferences/ndss/09/ From Pasi.Eronen@nokia.com Wed Jun 18 06:09:57 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m5IA9ugd005368 for ; Wed, 18 Jun 2008 06:09:56 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m5IA9jaU020536 for ; Wed, 18 Jun 2008 06:09:45 -0400 (EDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 7ABF3F9CC08 for ; Wed, 18 Jun 2008 06:09:24 -0400 (EDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5IA98Y6006533 for ; Wed, 18 Jun 2008 13:09:22 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Jun 2008 13:09:13 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Jun 2008 13:09:07 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 18 Jun 2008 13:09:06 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72F38710@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mailing list move Thread-Index: AcjRK1e1VYBvV6bRR2GRw/p70bpR/A== From: To: X-OriginalArrivalTime: 18 Jun 2008 10:09:07.0307 (UTC) FILETIME=[582AFBB0:01C8D12B] X-Nokia-AV: Clean X-Spam-Score: 2.469 X-Spam-Level: ** (2.469) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m5IA9ugd005368 Subject: [saag] Mailing list move X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 10:09:57 -0000 Hi all, The SAAG mailing list will be moved from mit.edu to ietf.org in the near future. Current subscribers will be automatically subscribed to the new list (and you'll get a message from Mailman when this has happened). Depending on how you've configured your mail filters/procmail rules, you may have to update them. We'll provide more information when we know the exact cutoff date, new archive location, etc. Best regards, Pasi (& Tim)