From pekkas@netcore.fi Tue Jan 4 13:52:01 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j04Ipt5j026828 for ; Tue, 4 Jan 2005 13:51:59 -0500 (EST) Received: from netcore.fi (netcore.fi [193.94.160.1])j04IppAQ010435 for ; Tue, 4 Jan 2005 13:51:52 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j04Ipmi28737; Tue, 4 Jan 2005 20:51:48 +0200 Date: Tue, 4 Jan 2005 20:51:48 +0200 (EET) From: Pekka Savola To: saag@mit.edu, ipsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.403436 cc: Tschofenig Hannes Subject: [saag] Requesting review of draft-tschofenig-v6ops-secure-tunnels-03.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 04 Jan 2005 18:52:01 -0000 FYI -- The first version of this draft was briefly discussed on thist list half a year or so ago. Now would be the perfect time to read and send feedback, especially to ensure that the IPsec parts are good. Please send the feedback to the authors (Cc:'ed), v6ops mailing list (v6ops@ops.ietf.org) or a forum of your choosing. Abstract This document gives guidance on securing IPv6-in-IPv4 tunnels using IPsec. No additional protocol extensions are described beyond those available with the IPsec framework. This document describes packet formats, IPsec security policy database for various scenarios, address configuration procedures, and the usage of the Extensible Authentication Procotol. ---------- Forwarded message ---------- Date: Mon, 03 Jan 2005 15:53:15 +0200 From: "Soininen Jonne (Nokia-NET/Helsinki)" To: ext Pekka Savola Cc: v6ops@ops.ietf.org Subject: Interest to have as an WG item: draft-tschofenig-v6ops-secure-tunnels-03.txt Hello v6ops WG, first of all, happy new year to everybody, and it is time to get back to work. (Chair hat on) The authors of draft-tschofenig-v6ops-secure-tunnels have requested the draft to be adopted as a WG item. I would like to give two (2) weeks of time for the discussion, putting the deadline to 18.1.2005. The draft can be found at http://www.ietf.org/internet-drafts/draft-tschofenig-v6ops-secure-tunnels-03.txt (Chair hat off) Cheers, Jonne -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From housley@vigilsec.com Wed Jan 5 16:53:11 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j05LrA5j004807 for ; Wed, 5 Jan 2005 16:53:10 -0500 (EST) Received: from woodstock.binhost.com ([144.202.240.3])j05Lr8Ga029706 for ; Wed, 5 Jan 2005 16:53:08 -0500 (EST) Received: (qmail 30767 invoked by uid 0); 5 Jan 2005 21:52:42 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.157.78) by woodstock.binhost.com with SMTP; 5 Jan 2005 21:52:42 -0000 Message-Id: <6.2.0.14.2.20050105133928.075eb790@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 05 Jan 2005 16:52:44 -0500 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000001 Spam-Alum-Time: 0.545594 Subject: [saag] People needed for a security review X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 05 Jan 2005 21:53:11 -0000 At IETF 60, we held the MASS BoF. The minutes are available at: http://www.ietf.org/proceedings/04aug/index.html. Since then, two proposals have seemed to gain some acceptance. Internet-Drafts are available for both: http://www.ietf.org/internet-drafts/draft-fenton-identified-mail-01.txt http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-01.txt There is also a feature summary of these two available at: http://mipassoc.org/mass/crocker-features-iim-dkeys-06dc.htm I am trying to gather a few people to do a review of security review of these two proposals. I see this a very short effort, and I would hope to post the results by the end of next week. The goal is to help the people working on the MASS effort understand the security offered by each proposal. Please send me a note if you want to be involved. Russ From fw@deneb.enyo.de Fri Jan 7 10:21:51 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j07FLo5j016661 for ; Fri, 7 Jan 2005 10:21:50 -0500 (EST) Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) j07FLlu1007628 for ; Fri, 7 Jan 2005 10:21:47 -0500 (EST) Received: from deneb.enyo.de ([212.9.189.171]) by albireo.enyo.de with esmtp id 1Cmvvt-0001kD-Tt; Fri, 07 Jan 2005 16:21:45 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.43) id 1Cmvvs-0002gb-M5; Fri, 07 Jan 2005 16:21:44 +0100 From: Florian Weimer To: Russ Housley Subject: Re: [saag] People needed for a security review References: <6.2.0.14.2.20050105133928.075eb790@mail.binhost.com> Date: Fri, 07 Jan 2005 16:21:44 +0100 In-Reply-To: <6.2.0.14.2.20050105133928.075eb790@mail.binhost.com> (Russ Housley's message of "Wed, 05 Jan 2005 16:52:44 -0500") Message-ID: <87vfa9cliv.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.800067 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 07 Jan 2005 15:21:52 -0000 * Russ Housley: > Since then, two proposals have seemed to gain some > acceptance. Internet-Drafts are available for both: > > http://www.ietf.org/internet-drafts/draft-fenton-identified-mail-01.txt > > http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-01.txt > > There is also a feature summary of these two available at: > > http://mipassoc.org/mass/crocker-features-iim-dkeys-06dc.htm > > I am trying to gather a few people to do a review of security review of > these two proposals. What's your threat model? Unfortunately, the introductory sections of these proposals are not very helpful in this regard. From fw@deneb.enyo.de Fri Jan 7 10:32:04 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j07FW25j016747 for ; Fri, 7 Jan 2005 10:32:02 -0500 (EST) Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) j07FVxu1008568 for ; Fri, 7 Jan 2005 10:31:59 -0500 (EST) Received: from deneb.enyo.de ([212.9.189.171]) by albireo.enyo.de with esmtp id 1Cmw5l-0001oe-P7; Fri, 07 Jan 2005 16:31:57 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.43) id 1Cmw5k-0002it-E5; Fri, 07 Jan 2005 16:31:56 +0100 From: Florian Weimer To: Pekka Savola Subject: Re: [saag] Requesting review of draft-tschofenig-v6ops-secure-tunnels-03.txt References: Date: Fri, 07 Jan 2005 16:31:56 +0100 In-Reply-To: (Pekka Savola's message of "Tue, 4 Jan 2005 20:51:48 +0200 (EET)") Message-ID: <87mzvlcl1v.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.009181 cc: Tschofenig Hannes cc: saag@mit.edu cc: ipsec@ietf.org X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 07 Jan 2005 15:32:05 -0000 * Pekka Savola: > Now would be the perfect time to read and send feedback, especially to > ensure that the IPsec parts are good. Please send the feedback to the > authors (Cc:'ed), v6ops mailing list (v6ops@ops.ietf.org) or a forum > of your choosing. > > Abstract > This document gives guidance on securing IPv6-in-IPv4 tunnels using > IPsec. No additional protocol extensions are described beyond those > available with the IPsec framework. This document describes packet > formats, IPsec security policy database for various scenarios, > address configuration procedures, and the usage of the Extensible > Authentication Procotol. The draft does not mention RFC 3068 tunnels. This might be intentional oversight, but should be stated nevertheless. I think the two threats (IP address spoofing) are not the ones you want to protect against. You seem to be interested in payload integrity and confidentiality, too, which is a completely different matter. It's also confusing that you run IPsec at the IPv4 layer and not at the encapsulated IPv6 layer. Wouldn't the latter reduce complexity significantly? From pekkas@netcore.fi Fri Jan 7 10:50:48 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j07Fok5j016885 for ; Fri, 7 Jan 2005 10:50:46 -0500 (EST) Received: from netcore.fi (netcore.fi [193.94.160.1])j07Fodu1006309 for ; Fri, 7 Jan 2005 10:50:39 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j07FoX220399; Fri, 7 Jan 2005 17:50:33 +0200 Date: Fri, 7 Jan 2005 17:50:33 +0200 (EET) From: Pekka Savola To: Florian Weimer Subject: Re: [saag] Requesting review of draft-tschofenig-v6ops-secure-tunnels-03.txt In-Reply-To: <87mzvlcl1v.fsf@deneb.enyo.de> Message-ID: References: <87mzvlcl1v.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.610449 cc: Tschofenig Hannes cc: saag@mit.edu cc: ipsec@ietf.org X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 07 Jan 2005 15:50:49 -0000 On Fri, 7 Jan 2005, Florian Weimer wrote: >> Now would be the perfect time to read and send feedback, especially to >> ensure that the IPsec parts are good. Please send the feedback to the >> authors (Cc:'ed), v6ops mailing list (v6ops@ops.ietf.org) or a forum >> of your choosing. >> >> Abstract >> This document gives guidance on securing IPv6-in-IPv4 tunnels using >> IPsec. No additional protocol extensions are described beyond those >> available with the IPsec framework. This document describes packet >> formats, IPsec security policy database for various scenarios, >> address configuration procedures, and the usage of the Extensible >> Authentication Procotol. > > The draft does not mention RFC 3068 tunnels. This might be > intentional oversight, but should be stated nevertheless. This should be discussed, I think. However, you can (practically) only protect the protocol-41 traffic from you to your relay router, not all the relay routers in the world to you. So, in practice, it is unfeasible to use IPsec here, except possibly for one direction only (and that is likely not worth the trouble, and the anycast relay operator is unlikely to go for it) > I think the two threats (IP address spoofing) are not the ones you > want to protect against. You seem to be interested in payload > integrity and confidentiality, too, which is a completely different > matter. These are different, yes. I guess this boils down to two options: 1) protect all tunneled v6 traffic between tunnel encapsulator E1 and decapsulator E2, or 2) protect just the link-local messaging between the tunnel endpoints, but not the data payload. These obviously have different properties. 1) is more like "tunnel mode", possibly for road warrior VPN -like scenarios, and 2) aims to only protect the special link-local messaging which could otherwise be spoofed. IP spoofing prevention is indeed mostly orthogonal, but using IPsec also eliminates that threat to a degree. > It's also confusing that you run IPsec at the IPv4 layer and not at > the encapsulated IPv6 layer. Wouldn't the latter reduce complexity > significantly? If you assume you would like to build a tunnel between two routers, or a host and a router (not host-to-host, where v6 IPsec would be fine), you'll have a keying problem if you'd need to set up keying between all the v6 hosts. Using v4 IPsec only protects a certain part of the end-to-end path, but at least doing so is keying-wise feasible. Obviously, v6 IPsec can be used in addition to v4 IPsec to secure some communication. -- 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 fw@deneb.enyo.de Fri Jan 7 11:32:25 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j07GWO5j017105 for ; Fri, 7 Jan 2005 11:32:24 -0500 (EST) Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) j07GWLu1023780 for ; Fri, 7 Jan 2005 11:32:21 -0500 (EST) Received: from deneb.enyo.de ([212.9.189.171]) by albireo.enyo.de with esmtp id 1Cmx2C-0002FB-82; Fri, 07 Jan 2005 17:32:20 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.43) id 1Cmx2A-00032L-Om; Fri, 07 Jan 2005 17:32:18 +0100 From: Florian Weimer To: Pekka Savola Subject: Re: [saag] Requesting review of draft-tschofenig-v6ops-secure-tunnels-03.txt References: <87mzvlcl1v.fsf@deneb.enyo.de> Date: Fri, 07 Jan 2005 17:32:18 +0100 In-Reply-To: (Pekka Savola's message of "Fri, 7 Jan 2005 17:50:33 +0200 (EET)") Message-ID: <87llb5b3ot.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.651947 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id j07GWO5j017105 cc: Tschofenig Hannes cc: saag@mit.edu cc: ipsec@ietf.org X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 07 Jan 2005 16:32:26 -0000 * Pekka Savola: >> The draft does not mention RFC 3068 tunnels. This might be >> intentional oversight, but should be stated nevertheless. > > This should be discussed, I think. However, you can (practically) > only protect the protocol-41 traffic from you to your relay router, > not all the relay routers in the world to you. So, in practice, it is > unfeasible to use IPsec here, except possibly for one direction only > (and that is likely not worth the trouble, and the anycast relay > operator is unlikely to go for it) Yes, doing something about it would most likely lose statelessness. There's also significant asymmetry in typical configurations, so it would be quite hard to get it to work. >> It's also confusing that you run IPsec at the IPv4 layer and not at >> the encapsulated IPv6 layer. Wouldn't the latter reduce complexity >> significantly? > > If you assume you would like to build a tunnel between two routers, or > a host and a router (not host-to-host, where v6 IPsec would be fine), > you'll have a keying problem if you'd need to set up keying between > all the v6 hosts. Forget it, the thing I had on my mind is actually described in section 2.2. By the way, there's a typo, "IPV6-TEP2" is mentioned only once. From housley@vigilsec.com Fri Jan 7 14:31:01 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j07JUx5j018128 for ; Fri, 7 Jan 2005 14:30:59 -0500 (EST) Received: from woodstock.binhost.com ([144.202.240.3])j07JUuoD012518 for ; Fri, 7 Jan 2005 14:30:56 -0500 (EST) Received: (qmail 9028 invoked by uid 0); 7 Jan 2005 19:25:10 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.216.188) by woodstock.binhost.com with SMTP; 7 Jan 2005 19:25:10 -0000 Message-Id: <6.2.0.14.2.20050107142010.09929e60@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 07 Jan 2005 14:25:11 -0500 To: Florian Weimer From: Russ Housley Subject: Re: [saag] People needed for a security review In-Reply-To: <87vfa9cliv.fsf@deneb.enyo.de> References: <6.2.0.14.2.20050105133928.075eb790@mail.binhost.com> <87vfa9cliv.fsf@deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.468703 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 07 Jan 2005 19:31:03 -0000 This is a good question. The MASS effort is supposed to support the automated reduction of phishing attacks and SPAM. The idea is that the message can be automatically filtered if the advertised source of the message is not part of the domain that signed the message. Of course, this does nothing for messages that are not signed by their domain, but that is a transition issue. You can find a proposed (not approved, and probably not even a final draft) charter for this work at: http://mipassoc.org/mass/mass-charter-01dc.txt Russ At 10:21 AM 1/7/2005, Florian Weimer wrote: >* Russ Housley: > > > Since then, two proposals have seemed to gain some > > acceptance. Internet-Drafts are available for both: > > > > http://www.ietf.org/internet-drafts/draft-fenton-identified-mail-01.txt > > > > http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-01.txt > > > > There is also a feature summary of these two available at: > > > > http://mipassoc.org/mass/crocker-features-iim-dkeys-06dc.htm > > > > I am trying to gather a few people to do a review of security review of > > these two proposals. > >What's your threat model? > >Unfortunately, the introductory sections of these proposals are not >very helpful in this regard. From smb@cs.columbia.edu Fri Jan 7 15:44:21 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j07KiJ5j018507 for ; Fri, 7 Jan 2005 15:44:19 -0500 (EST) Received: from machshav.com (machshav.com [147.28.0.16]) j07KiD5r002302 for ; Fri, 7 Jan 2005 15:44:13 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id A8FA3FB282; Fri, 7 Jan 2005 20:44:12 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 354A5FB262; Fri, 7 Jan 2005 20:44:12 +0000 (UTC) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 3CE4A3C00FD; Fri, 7 Jan 2005 15:44:10 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Russ Housley Subject: Re: [saag] People needed for a security review In-Reply-To: Your message of "Fri, 07 Jan 2005 14:25:11 EST." <6.2.0.14.2.20050107142010.09929e60@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Jan 2005 15:44:10 -0500 Sender: smb@cs.columbia.edu Message-Id: <20050107204410.3CE4A3C00FD@berkshire.machshav.com> X-Spam-Score: 0.142 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000005 Spam-Alum-Time: 0.675749 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 07 Jan 2005 20:44:22 -0000 In message <6.2.0.14.2.20050107142010.09929e60@mail.binhost.com>, Russ Housley writes: >This is a good question. The MASS effort is supposed to support the >automated reduction of phishing attacks and SPAM. The idea is that the >message can be automatically filtered if the advertised source of the >message is not part of the domain that signed the message. Of course, this >does nothing for messages that are not signed by their domain, but that is >a transition issue. > For a dissenting view, on why I don't think such approaches will do much good, see my "Inside RISKS" column from last month's CACM at http://www1.cs.columbia.edu/~smb/papers/phish-risks.ps or http://www1.cs.columbia.edu/~smb/papers/phish-risks.pdf --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb From fw@deneb.enyo.de Fri Jan 7 17:15:54 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j07MFq5j019023 for ; Fri, 7 Jan 2005 17:15:53 -0500 (EST) Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) j07MFo6o017740 for ; Fri, 7 Jan 2005 17:15:50 -0500 (EST) Received: from deneb.enyo.de ([212.9.189.171]) by albireo.enyo.de with esmtp id 1Cn2Ob-0004Sn-6F; Fri, 07 Jan 2005 23:15:49 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.43) id 1Cn2OY-0004Pg-VB; Fri, 07 Jan 2005 23:15:46 +0100 From: Florian Weimer To: Russ Housley Subject: Re: [saag] People needed for a security review References: <6.2.0.14.2.20050105133928.075eb790@mail.binhost.com> <87vfa9cliv.fsf@deneb.enyo.de> <6.2.0.14.2.20050107142010.09929e60@mail.binhost.com> Date: Fri, 07 Jan 2005 23:15:46 +0100 In-Reply-To: <6.2.0.14.2.20050107142010.09929e60@mail.binhost.com> (Russ Housley's message of "Fri, 07 Jan 2005 14:25:11 -0500") Message-ID: <87llb451il.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.672 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.791328 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 07 Jan 2005 22:15:55 -0000 * Russ Housley: [Threat model for email authentication] > This is a good question. And it really needs an answer, because otherwise we cannot decide if the protocol is any good. > The MASS effort is supposed to support the automated reduction of > phishing attacks and SPAM. The idea is that the message can be > automatically filtered if the advertised source of the message is > not part of the domain that signed the message. Of course, this > does nothing for messages that are not signed by their domain, but > that is a transition issue. ro1ex.com (look closely at the domain name!) was active from 2004-10-26 to 2005-01-03. I'm sure Rolex tried very hard to get this one shut down, yet it took over two months. And there still is rolextime.info and a couple of others. None of the proposed schemes would have prevented the attacker from sending messages with a @ro1ex.com sender. But back to my question. Some things are rather trivial to do. For example, if you just want more input data for mail scoring (this is listed as a motivation for the DomainKeys proposals), it doesn't really matter if you use good or bad security. You can do pretty decent statistics even with no security, all you need ist some complex protocol, preferably with an ambiguous specification, which leads to significant variance in implementation behavior. If we want to jump on the threat model bandwagon, we could claim that the threat is one of the following ones, and try to provide convincing arguments that these the proposal addresses them. "An attacker can forge the sender address of the victim's domain in messages he sends." "An attacker can hide his or her identity." However, these are not the problems we are dealing with. These threats look a bit like an afterthought, defined narrowly enough to make claims that the protocols are effective. The following is still not the real thing (an actual threat model would be quite complex and is a significant research project[1]), but it is closer, IMHO. "An attacker can send messages which look as if they were sent by the victim." "Traditional law enforcement does not deter most attackers." I can't think about any opt-in mail authentication scheme that addresses these problems because they are located at a completely different level. Furthermore, identification schemes that are tied to domain names implicitly assume a scarcity of domain names which just isn't there. What's worse, we have some data which suggests that even companies which are hit by phishing hesitate to publish strict SPF records. This means that companies probably will continue using weak opt-in schemes, which doesn't make much difference in the end because the user experience is inconsistent. And of course, we already have the IP address of the sender, which unfortunately often belongs to a compromised machine---but there already is some identity to traceback from. Domain-based authentication gives us another identity, but the domain name holder is very likely an innocent person whose identity has been used without permission (or, worse even, whose credit card data has been compromised). I wouldn't even bother to call this "identity theft" because the registrars usually do not try very hard to determine identity. Unfortunately, the message became much longer than I want, and it doesn't provide the confirmation you probably were after. On the other hand, I'm sure neither of the two proposals will have a significant effect on spam in the long run, even if one of them is widely deployed. You can't standardize away the spam problem, as there is sufficient incentive to work around any standard. -------------------- 1. For example, I have a huch that most the losses attributed to phishing are fictional. Furthermore I'm not sure if society as a whole should bear the cost of law enforcement because someone deployed broken protocols that impede business of few (the "Ebay effect"). From dhc2@dcrocker.net Fri Jan 7 20:29:22 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j081TK5j019920 for ; Fri, 7 Jan 2005 20:29:21 -0500 (EST) Received: from sb7.songbird.com (sb7.songbird.com [208.184.79.137]) j081TGYS001979 for ; Fri, 7 Jan 2005 20:29:17 -0500 (EST) Received: from bbprime (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id j081PCQi024038; Fri, 7 Jan 2005 17:25:13 -0800 From: Dave Crocker To: "Steven M. Bellovin" , Russ Housley X-Mailer: PocoMail 3.2 (2004) - Licensed Version X-URL: bbiw.net Date: Fri, 7 Jan 2005 17:25:12 -0800 Message-ID: <200517172512.518374@bbprime> In-Reply-To: <20050107204410.3CE4A3C00FD@berkshire.machshav.com> Subject: Re: [saag] People needed for a security review Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.527506 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: Dave Crocker List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 08 Jan 2005 01:29:23 -0000 On Fri, 07 Jan 2005 16:21:44 +0100, Florian Weimer wrote: >  > I am trying to gather a few people to do a review of security review of >  > these two proposals. > >  What's your threat model? Let's see if I can respond with anything useful, however personal an opinion: An email server, receiving a message at an administrative boundary, wishes to make assessments of that nessage, such as whether it is spam. One line of effort is based on a valid determinination of who is accountable for that message. Accountability means that there is possible recourse in case of problems. It also can provide accreditation/reputation information to include in the assessment process. So, we want to have a signature of the message (body and relevant headers) that is used during transit, and consumed by receive-side filtering processes. (Some folks worry about presentation issues to the recipient, by I've come to view that as a distraction.) Reference to "transit" might mean that the signature can be considerably weaker than for longer-term signatures. It also means that processing cost is sensitive, as is cross-net query overhead. Email technical design typically tries to avoid extra round-trips. On Fri, 07 Jan 2005 15:44:10 -0500, Steven M. Bellovin wrote: >  For a dissenting view, on why I don't think such approaches will do >  much good, see my "Inside RISKS" column from last month's CACM at In the world of anti-spam technical work, there has been previous little *serious* discussion about threats, strategic aspects of different approaches, systems impact, user impacts, or any of the other components typically present in work seeking to modify a global infrastructure in respond to perceived attacks. In fact, it is difficult to converge even on consistent terminology. Consequently, an article like Steve's is useful as a discussion point. It might, in fact, be productive to have some of that serious discussion among Steve and similarly experienced security folk, with some anti-spam workers who are at least *trying* to do careful design. I know that at least some of them take exception to the points in Steve's articles. (For example, I think that the concerns he raises are quite reasonable, but disagree with some/most of his conclusions, at least for some mechanisms being considered.) d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker  a t ... WE'VE MOVED to:  www.bbiw.net From pekkas@netcore.fi Sat Jan 8 04:57:52 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j089vp5j022006 for ; Sat, 8 Jan 2005 04:57:51 -0500 (EST) Received: from netcore.fi (netcore.fi [193.94.160.1])j089vm5R013221 for ; Sat, 8 Jan 2005 04:57:49 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j089vbc07046; Sat, 8 Jan 2005 11:57:37 +0200 Date: Sat, 8 Jan 2005 11:57:37 +0200 (EET) From: Pekka Savola To: Florian Weimer Subject: Re: [saag] People needed for a security review In-Reply-To: <87llb451il.fsf@deneb.enyo.de> Message-ID: References: <6.2.0.14.2.20050105133928.075eb790@mail.binhost.com> <6.2.0.14.2.20050107142010.09929e60@mail.binhost.com> <87llb451il.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.586526 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 08 Jan 2005 09:57:53 -0000 On Fri, 7 Jan 2005, Florian Weimer wrote: > If we want to jump on the threat model bandwagon, we could claim that > the threat is one of the following ones, and try to provide convincing > arguments that these the proposal addresses them. > > "An attacker can forge the sender address of the victim's domain in > messages he sends." [...] This is a good point, which Steve also brings up. This may have already occurred to many people, but in case it has not, let me try to phrase it somehow. The above threat model accurately describes the scenario/problem statement where we want to ensure that the holder of domain X does not get "virus received" etc. bounce messages except from the messages the domain has actually sent. Whether this is the best way to solve the annoying bounces problem can be debated. If the WG would be chartered to fight _THAT_ problem, it would likely be solving a more critical problem. The merits of being able to ensure that no one could forge a domain name, in the world where many recipients would not support the mechanism (transition issue) and where phishing etc. attacks have other avenues are debatable as Steve's article and Florian point out. In other words, you can obtain an assurance on the real originator domain of an email, but how does that benefit the end users? It won't stop or likely even significantly lower the amount of phishing attacks. What problem (except the technical one, being assured of the originator domain) would this actually solve? -- 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 fw@deneb.enyo.de Sat Jan 8 07:10:20 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j08CAJ5j022581 for ; Sat, 8 Jan 2005 07:10:19 -0500 (EST) Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) j08CAHMI011617 for ; Sat, 8 Jan 2005 07:10:17 -0500 (EST) Received: from deneb.enyo.de ([212.9.189.171]) by albireo.enyo.de with esmtp id 1CnFQ6-0007MB-KN; Sat, 08 Jan 2005 13:10:14 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.43) id 1CnFQ6-0001Nc-0R; Sat, 08 Jan 2005 13:10:14 +0100 From: Florian Weimer To: Pekka Savola Subject: Re: [saag] People needed for a security review References: <6.2.0.14.2.20050105133928.075eb790@mail.binhost.com> <87vfa9cliv.fsf@deneb.enyo.de> <6.2.0.14.2.20050107142010.09929e60@mail.binhost.com> <87llb451il.fsf@deneb.enyo.de> Date: Sat, 08 Jan 2005 13:10:14 +0100 In-Reply-To: (Pekka Savola's message of "Sat, 8 Jan 2005 11:57:37 +0200 (EET)") Message-ID: <87acrk6s0p.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.121133 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 08 Jan 2005 12:10:21 -0000 * Pekka Savola: >> "An attacker can forge the sender address of the victim's domain in >> messages he sends." > [...] > The above threat model accurately describes the scenario/problem > statement where we want to ensure that the holder of domain X does not > get "virus received" etc. bounce messages except from the messages the > domain has actually sent. > > Whether this is the best way to solve the annoying bounces problem can > be debated. If the WG would be chartered to fight _THAT_ problem, it > would likely be solving a more critical problem. I agree. To some degree, this is a technical problem, and at least we have a concise description. There are several variants, though: - The number of bounce messages for messages not actually sent makes the whole bounce message concept unusable for end users because they will no longer notice messages indicating a real delivery problem. - The bounce message traffic or its storage requirements (especially large virus-infected message bodies) are troublesome for service providers. (This assumes that the bounce message is addressed to an existing mailbox.) - The rate of MTA connections and RCPT TO:s commands resulting from bounce messages causes operational problems. It does not matter if the target mailbox exists on the system. - Pseudo-bounces sent to header adresses (or with non-empty sender address), broken OOONs, and so on. (The area of RFC 3834, probably not the root of the problem, but of course annoying.) Addressing the third item requires a weak form of sender authentication (not necessarily cryptography). The others don't. For example, the first item on this list can be resolved by better client software (adherence to DSN-related RFCs in the SMTP transport network would be helpful, but it only makes the job of software authors easier). > In other words, you can obtain an assurance on the real originator > domain of an email, but how does that benefit the end users? It won't > stop or likely even significantly lower the amount of phishing > attacks. What problem (except the technical one, being assured of the > originator domain) would this actually solve? Yes, a very valid question. I tried to give an explanation (an assumption of scarcity of domain names, which would mean that blocking identified domains works, in contrast to blocking individual IP addresses), but it would be good to know the real motivation. From mouse@Sparkle.Rodents.Montreal.QC.CA Sat Jan 8 07:30:51 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j08CUo5j022686 for ; Sat, 8 Jan 2005 07:30:50 -0500 (EST) Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7])j08CUlF6008196 for ; Sat, 8 Jan 2005 07:30:47 -0500 (EST) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id HAA05870; Sat, 8 Jan 2005 07:30:44 -0500 (EST) From: der Mouse Message-Id: <200501081230.HAA05870@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Sat, 8 Jan 2005 07:27:00 -0500 (EST) To: saag@mit.edu Subject: Re: [saag] People needed for a security review In-Reply-To: <87acrk6s0p.fsf@deneb.enyo.de> References: <6.2.0.14.2.20050105133928.075eb790@mail.binhost.com> <87vfa9cliv.fsf@deneb.enyo.de> <6.2.0.14.2.20050107142010.09929e60@mail.binhost.com> <87llb451il.fsf@deneb.enyo.de> <87acrk6s0p.fsf@deneb.enyo.de> X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.650768 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 08 Jan 2005 12:30:52 -0000 > There are several variants, though: > [snipped 1 and 2; 3 is:] > - The rate of MTA connections and RCPT TO:s commands resulting from > bounce messages causes operational problems. It does not matter > if the target mailbox exists on the system. > [snipped 4] > Addressing the third item requires a weak form of sender > authentication (not necessarily cryptography). Actually, no. One possible way of addressing the third requires etc. Another way of addressing it is to make MTA connections, and more generally SMTP sessions with no valid recipients, lightweight enough to tolerate them in large number. Yes, it's a way of withstanding the problem, rather than fixing it, but it *is* something that a receiving site can do unilaterally. In fact, I did it for an ISP who was getting crushed by bounce blowback, back most of a year ago. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From fw@deneb.enyo.de Sat Jan 8 07:34:20 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j08CYJ5j022725 for ; Sat, 8 Jan 2005 07:34:19 -0500 (EST) Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) j08CYHF6011886 for ; Sat, 8 Jan 2005 07:34:17 -0500 (EST) Received: from deneb.enyo.de ([212.9.189.171]) by albireo.enyo.de with esmtp id 1CnFn0-0007TR-PJ; Sat, 08 Jan 2005 13:33:54 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.43) id 1CnFn0-0001RI-5f; Sat, 08 Jan 2005 13:33:54 +0100 From: Florian Weimer To: Dave Crocker Subject: Re: [saag] People needed for a security review References: <200517172512.518374@bbprime> Date: Sat, 08 Jan 2005 13:33:54 +0100 In-Reply-To: <200517172512.518374@bbprime> (Dave Crocker's message of "Fri, 7 Jan 2005 17:25:12 -0800") Message-ID: <873bxc6qx9.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.954724 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 08 Jan 2005 12:34:22 -0000 --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable * Dave Crocker: > On Fri, 07 Jan 2005 16:21:44 +0100, Florian Weimer wrote: >>=A0 >=A0I am trying to gather a few people to do a review of security rev= iew of >>=A0 >=A0these two proposals. >> >>=A0 What's your threat model? > > Let's see if I can respond with anything useful, however personal an opin= ion: > > An email server, receiving a message at an > administrative boundary, wishes to make assessments of > that nessage, such as whether it is spam. One line of > effort is based on a valid determinination of who is > accountable for that message. Accountability means > that there is possible recourse in case of problems. > It also can provide accreditation/reputation > information to include in the assessment process. Unfortunately, a domain name does not imply accountability. Who's accountable for ro1ex.com? 0tw1fy2xls.mryx.com? l0s6dg1lht.deov.com? Apparently, it's the same person or group of persons because the DNS servers are the same, but would any of the two proposals be able to see this connection? (In total, I found 98 related second-level domains using passive DNS replication. I've attached them below.) If you are after accountability for repeated mail transmission, we are already there now, even without cryptographically authenticated senders. If you don't expect messages from strangers, most of the spam problem is solvable at the receiver side. Unfortunately, service providers are reluctant to talk about details because it's a business asset. 8-> > So, we want to have a signature of the message (body > and relevant headers) that is used during transit, and > consumed by receive-side filtering processes. Repudiation is a desirable property of Internet mail. Is it really necessary to sign the message body? The header is not so problematic because you can hardly disclaim sending a message whose transmission is recorded in several independent server logs, but the body is a different story. --=-=-= Content-Disposition: attachment 0megas.net 0riginals.net 65dns11.com 6790dns.com aaiy.com aclum.com afeet.com aiev.com ayyc.com bazra.com beill.com beud.com bfear.com bfey.com bhex.com blackmarketmoney.com cahla.com cmik.com deov.com deuf.com dimur.com dlur.com dns434.com dns4432.com dns4883.com dns55789.com dns889.com ealz.com eank.com evif.com fdav.com felna.com fogw.com ghoy.com gruj.com hedj.com hensi.com hents.com hokz.com icors.com jeou.com jhex.com jteq.com jugr.com kabet.com keej.com kelhi.com kikv.com kuev.com kvvb.com ltalian.net mecei.com mejc.com mryx.com neata.com nepel.com nteri.com oatsy.com okiez.com online-replica-store.com onlinereplicastore.com onrix.com pjat.com quoir.com qwild.com ranei.com raoy.com rekz.com rep1icas.com ro1ex.com roiex.com royal-replicas.com sadyr.com selyn.com simply-rx.com swlss.com tefty.com tegli.com teitt.com tnoy.com toels.com tzig.com uloh.com vanai.com vdif.com veeza.com vievv.com vvatch.com wauy.com woxr.com xantz.com xonc.com yect.com yeft.com yomoi.com yoqa.com zowk.com --=-=-=-- From sommerfeld@sun.com Sat Jan 8 08:04:58 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j08D4u5j022981 for ; Sat, 8 Jan 2005 08:04:56 -0500 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) j08D4sF6015392 for ; Sat, 8 Jan 2005 08:04:54 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j08D4odt002756; Sat, 8 Jan 2005 06:04:50 -0700 (MST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) ESMTP id j08D4n8p026270; Sat, 8 Jan 2005 08:04:50 -0500 (EST) Subject: Re: [saag] People needed for a security review From: Bill Sommerfeld To: Pekka Savola In-Reply-To: References: <6.2.0.14.2.20050105133928.075eb790@mail.binhost.com> <6.2.0.14.2.20050107142010.09929e60@mail.binhost.com> <87llb451il.fsf@deneb.enyo.de> Content-Type: text/plain Message-Id: <1105189481.18196.636.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.324 Date: Sat, 08 Jan 2005 08:04:42 -0500 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.262394 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 08 Jan 2005 13:04:58 -0000 On Sat, 2005-01-08 at 04:57, Pekka Savola wrote: > In other words, you can obtain an assurance on the real originator > domain of an email, but how does that benefit the end users? It won't > stop or likely even significantly lower the amount of phishing > attacks. What problem (except the technical one, being assured of the > originator domain) would this actually solve? 1) reduction of misdirected spam backscatter from bounces, virus warnings, etc., 2) reduction of misdirected complaints about spam. we need to speak with folks with large-isp operational experience about the costs of both of these before we can dismiss these as unimportant concerns. the RO1EX problem has to be solved some other way. - Bill From pbaker@verisign.com Sat Jan 8 09:31:06 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j08EV45j023446 for ; Sat, 8 Jan 2005 09:31:04 -0500 (EST) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) j08EV2F6024327 for ; Sat, 8 Jan 2005 09:31:02 -0500 (EST) Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54])j08EUq9T010798; Sat, 8 Jan 2005 06:30:52 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sat, 8 Jan 2005 06:30:52 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Steven M. Bellovin'" , Russ Housley Subject: RE: [saag] People needed for a security review Date: Sat, 8 Jan 2005 06:30:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.006405 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 08 Jan 2005 14:31:07 -0000 > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On > Behalf Of Steven M. Bellovin > For a dissenting view, on why I don't think such approaches will do > much good, see my "Inside RISKS" column from last month's CACM at > http://www1.cs.columbia.edu/~smb/papers/phish-risks.ps or > http://www1.cs.columbia.edu/~smb/papers/phish-risks.pdf Just as Bruce had got out of this habbit somebody else starts the drive by. At least Bruce thought he owed people a full explanation of his objections rather than providing only a precis. The point of authentication has nothing to do with identifying spam. The point is to identify the legitimate email and reduce the probability that the legitimate email is caught in spam filters. That in turn allows the spam filters to be rather more aggressive without reaching unacceptably high false positive rates, it also gives senders who are being unfairly affected by false positives a means of reducing this problem. The spam reduction strategy is an accountability strategy. In an accountability scheme the objective is not attempt to prevent the security issue from ever occurring, the objective is to deter the undesirable behavior by ensuring that consequences are faced by the perpetrator who causes the bad behavior to occur. The accountability scheme has three components, authentication, accreditation and consequences. The paper does a poor job of articulating the privacy concerns. It seems to suggest that if everyone uses authentication and it becomes impossible to impersonate a domain name that free speech is lost. The paper confuses anonymity with pseudonymity. The proposal does nothing to make it harder to obtain a pseudonym anonymously, that will be just as easy in the future as it is today. The only difference is that it will not be possible for another party to impersonate that pseudonymous identity. Authentication is only ever an enabler for other authentication methods. That is how it is used against spam and that is how it is used against phishing. We are entirely aware of the fact that a clever criminal can find countermeasures, this is an opening move in the chess game, it is not expected to result in a swift checkmate against those parties. Fortunately most real criminals are pretty stupid, especially the ones that get caught. The ones who are not stupid tend to be lazy which is just as good. The priority at this stage is to raise the barriers to entry into the phishing game to prevent new entrants. We are not going to take out the well resourced incumbents with this particular tactic. The way we are going to deal with them is mostly through law enforcement, following the money through the carding cycle to identify the gangs. We can also expect some attrition from the incumbents themselves forcing their competition out. Folk who think its smart to get into this business should be made to think about the tactics the same gangs have used to protect their prostitution and protection rackets. From pbaker@verisign.com Sat Jan 8 10:27:45 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j08FRh5j023735 for ; Sat, 8 Jan 2005 10:27:43 -0500 (EST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) j08FRfUY016586 for ; Sat, 8 Jan 2005 10:27:41 -0500 (EST) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id j08FRcHZ010992; Sat, 8 Jan 2005 07:27:38 -0800 (PST) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sat, 8 Jan 2005 07:27:38 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Bill Sommerfeld'" , Pekka Savola Subject: RE: [saag] People needed for a security review Date: Sat, 8 Jan 2005 07:27:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.632865 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id j08FRh5j023735 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 08 Jan 2005 15:27:47 -0000 > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On > Behalf Of Bill Sommerfeld > On Sat, 2005-01-08 at 04:57, Pekka Savola wrote: > > > In other words, you can obtain an assurance on the real originator > > domain of an email, but how does that benefit the end > users? It won't > > stop or likely even significantly lower the amount of phishing > > attacks. What problem (except the technical one, being > assured of the > > originator domain) would this actually solve? > > 1) reduction of misdirected spam backscatter from bounces, > virus warnings, etc., > 2) reduction of misdirected complaints about spam. I believe that it is simply common sense that the only party that should be able to send email that appears to come from verisign.com is VeriSign Inc., which owns the domain. Even if this did not solve phishing or spam it is simply common sense to align the actual security of the system with the level of security that a naïve user would reasonably expect. It might well be the case that we do not in the end provide this feature quickly enough to deal with the phishing problem. But I know that if the we had had this in place it would have been much harder for phishing to get started. Phishing is only one criminal tactic that can be used by criminals to make money, I do not want to give a list in a public forum but there are many, many ways to exploit the lack of authentication. To give an example that has got into the public domain already, there is a hilarious Web site that describes a prank where a guy socialy engineered some low level clerk who had just joined Starbucks that he was the CEO. Its pretty funny, but someone is probably now going to use exactly the same strategy to socially engineer insider trading information out of people. One of the big myths we need to get away from here is that bad security is worse than no security. The valid position is that it is a really bad for the actual level of security to be less than the percieve level. Telling users that the Internet is not secure does not alter the level of security that familiarity leads them to assume. Bad cryptography is empirically not worse than no cryptography. SSL 1.0 was so bad I broke it in ten minutes. SSL 2.0 was not that hot either, but SSL 3.0 is very robust and is the best deployed crypto system we have. WEP was dreadful but has been fixed. If there are real problems with a crypto system that are discovered after it is deployed and used they get fixed. That is not a license for negligent design but it does mean that we should not allow the great and the good to block deployment realistic security schemes because they have some bad feeling about them or don't feel sufficiently confident. Three years ago Steve made a big mistake when he blocked the changes to DNSSEC that would have allowed it to be deployed then, not because he could identify an actual problem but because he could not convince himself that no problem existed. The direct result of listening to Steve then is that DNS security today is no better than it was three years ago. We are still waiting for Moore's law to make the 1994 proposal practical. We lost a unique deployment opportunity because of that. Do nothing security is not an option in this case. Phill From pbaker@verisign.com Sat Jan 8 10:30:21 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j08FUI5j023781 for ; Sat, 8 Jan 2005 10:30:18 -0500 (EST) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) j08FUFoJ001847 for ; Sat, 8 Jan 2005 10:30:16 -0500 (EST) Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54])j08FUCgf013014; Sat, 8 Jan 2005 07:30:12 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sat, 8 Jan 2005 07:30:12 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "Hallam-Baker, Phillip" , "'Steven M. Bellovin'" , Russ Housley Subject: RE: [saag] People needed for a security review Date: Sat, 8 Jan 2005 07:30:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 2.012879 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 08 Jan 2005 15:30:22 -0000 I should have said that authentication is only an enabler for other security mechanisms, not other authentication mechanisms, sorry typo. > -----Original Message----- > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On > Behalf Of Hallam-Baker, Phillip > Sent: Saturday, January 08, 2005 9:31 AM > To: 'Steven M. Bellovin'; Russ Housley > Cc: saag@mit.edu > Subject: RE: [saag] People needed for a security review > > > > > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On > > Behalf Of Steven M. Bellovin > > > For a dissenting view, on why I don't think such approaches will do > > much good, see my "Inside RISKS" column from last month's CACM at > > http://www1.cs.columbia.edu/~smb/papers/phish-risks.ps or > > http://www1.cs.columbia.edu/~smb/papers/phish-risks.pdf > > > Just as Bruce had got out of this habbit somebody else starts > the drive by. > At least Bruce thought he owed people a full explanation of > his objections > rather than providing only a precis. > > > The point of authentication has nothing to do with > identifying spam. The > point is to identify the legitimate email and reduce the > probability that > the legitimate email is caught in spam filters. That in turn > allows the spam > filters to be rather more aggressive without reaching > unacceptably high > false positive rates, it also gives senders who are being > unfairly affected > by false positives a means of reducing this problem. > > The spam reduction strategy is an accountability strategy. In an > accountability scheme the objective is not attempt to prevent > the security > issue from ever occurring, the objective is to deter the undesirable > behavior by ensuring that consequences are faced by the > perpetrator who > causes the bad behavior to occur. > > The accountability scheme has three components, authentication, > accreditation and consequences. > > The paper does a poor job of articulating the privacy > concerns. It seems to > suggest that if everyone uses authentication and it becomes > impossible to > impersonate a domain name that free speech is lost. The paper confuses > anonymity with pseudonymity. The proposal does nothing to > make it harder to > obtain a pseudonym anonymously, that will be just as easy in > the future as > it is today. The only difference is that it will not be > possible for another > party to impersonate that pseudonymous identity. > > > Authentication is only ever an enabler for other > authentication methods. > That is how it is used against spam and that is how it is used against > phishing. > > We are entirely aware of the fact that a clever criminal can find > countermeasures, this is an opening move in the chess game, it is not > expected to result in a swift checkmate against those parties. > > Fortunately most real criminals are pretty stupid, especially > the ones that > get caught. The ones who are not stupid tend to be lazy which > is just as > good. > > > The priority at this stage is to raise the barriers to entry into the > phishing game to prevent new entrants. We are not going to > take out the well > resourced incumbents with this particular tactic. The way we > are going to > deal with them is mostly through law enforcement, following the money > through the carding cycle to identify the gangs. We can also > expect some > attrition from the incumbents themselves forcing their > competition out. Folk > who think its smart to get into this business should be made > to think about > the tactics the same gangs have used to protect their prostitution and > protection rackets. > > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag > From dhc2@dcrocker.net Sat Jan 8 11:03:54 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j08G3r5j024021 for ; Sat, 8 Jan 2005 11:03:53 -0500 (EST) Received: from sb7.songbird.com (sb7.songbird.com [208.184.79.137]) j08G3ooJ008062 for ; Sat, 8 Jan 2005 11:03:50 -0500 (EST) Received: from bbprime (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id j08G3j1A022914; Sat, 8 Jan 2005 08:03:46 -0800 From: Dave Crocker To: Pekka Savola , Florian Weimer X-Mailer: PocoMail 3.2 (2004) - Licensed Version X-URL: bbiw.net Date: Sat, 8 Jan 2005 08:03:44 -0800 Message-ID: <2005188344.110713@bbprime> In-Reply-To: Subject: Re: [saag] People needed for a security review Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.003092 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: Dave Crocker List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 08 Jan 2005 16:03:55 -0000 On Sat, 8 Jan 2005 11:57:37 +0200 (EET), Pekka Savola wrote: >  Whether this is the best way to solve the annoying bounces problem can MASS has nothing to do with bounces (RFC2821.MailFrom) Mass has to do with message origination (RFC2822.From and RFC2822.Sender) The bounce address is set by the RFC2822.Sender. However a particular bounce address may have no substring in common with From or Sender. SPF attempts to deal with bounce addresses. So does BATV. (BATV is also documented at the mipassoc.org site.) MASS is about message content origination. On Sat, 08 Jan 2005 13:33:54 +0100, Florian Weimer wrote: >  Unfortunately, a domain name does not imply accountability.  Who's >  accountable for ro1ex.com? There are two answers. 1. From Whois: smith a 588, Seocho-dong, Seocho-gu Seoul, 137070 KR 2. The domain name is the accountable entity, itself. A domain name provides a relatively stable reference string. Far more stable than IP Addresses. One approach to accreditation/reputation simply needs is a stable reference upon which a pattern of behavior can be documented. The other approach needs proactive effort by the domain name administrator to be vetted as a good guy. I should add that I see two different lines of accountability being useful for anti-spam efforts. One involves the "author" (this includes the rfc2822.sender). The other involves the latest-hop operator, as asserted in RFC2821.HELO. For accountability of the operator, see CSV (also documented at mipassoc.org.) SPF has also added a HELO-based mechanism. On Sat, 08 Jan 2005 13:33:54 +0100, Florian Weimer wrote: >  Repudiation is a desirable property of Internet mail.  Is it really >  necessary to sign the message body?   If the body is not signed, then a spammer can do a replay attack, using signed headers but different content. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker  a t ... WE'VE MOVED to:  www.bbiw.net From mcr@sandelman.ottawa.on.ca Sat Jan 8 14:04:59 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j08J4w5j024931 for ; Sat, 8 Jan 2005 14:04:58 -0500 (EST) Received: from pike.sandelman.ca (pike.sandelman.ca [205.150.200.164]) j08J4uLR015521 for ; Sat, 8 Jan 2005 14:04:56 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by pike.sandelman.ca (Postfix) with ESMTP id 0B15D63B31 for ; Sat, 8 Jan 2005 14:04:56 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 9B8F8BDDA for ; Sat, 8 Jan 2005 14:04:55 -0500 (EST) To: saag@mit.edu Subject: Re: [saag] People needed for a security review In-Reply-To: Message from "Hallam-Baker, Phillip" References: X-Mailer: MH-E 7.82; nmh 1.0.4+dev; XEmacs 21.4 (patch 15) Date: Sat, 08 Jan 2005 14:04:55 -0500 Message-ID: <4401.1105211095@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.546664 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 08 Jan 2005 19:05:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Hallam-Baker," == Hallam-Baker, Phillip writes: Hallam-Baker> The point of authentication has nothing to do with Hallam-Baker> identifying spam. The point is to identify the Hallam-Baker> legitimate email and reduce the probability that the Hallam-Baker> legitimate email is caught in spam filters. That in What he said. Hallam-Baker> criminal can find countermeasures, this is an opening Hallam-Baker> move in the chess game, it is not expected to result Hallam-Baker> in a swift checkmate against those parties. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQeAu1oqHRg3pndX9AQEKhAQA4AYZnwJlQAvdbA5/VvaUJbJzoa4o3qhY V+7+qicdYGijSR7J0iS7ook5Az+hNEXiR+WeINotgP2w2KjnvMlxVdWvLII5viX7 9JPNPMu08t7Y/V/Av0ptktf6bL1C6iQslW9KQZrCk/aO+J946Sd9VQ6YrXEaZd9U m02SiFs45lU= =S9hW -----END PGP SIGNATURE----- From hartmans@MIT.EDU Sat Jan 8 19:05:42 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0905e5j026286 for ; Sat, 8 Jan 2005 19:05:40 -0500 (EST) Received: from cz.mit.edu (STRATTON-FOUR-FORTY-TWO.MIT.EDU [18.187.6.187]) j0905c2b022482 for ; Sat, 8 Jan 2005 19:05:38 -0500 (EST) Received: by cz.mit.edu (Postfix, from userid 8042) id 905FCE0063; Sat, 8 Jan 2005 19:06:46 -0500 (EST) To: Florian Weimer Subject: Re: [saag] People needed for a security review References: <6.2.0.14.2.20050105133928.075eb790@mail.binhost.com> <87vfa9cliv.fsf@deneb.enyo.de> From: Sam Hartman Date: Sat, 08 Jan 2005 19:06:46 -0500 In-Reply-To: <87vfa9cliv.fsf@deneb.enyo.de> (Florian Weimer's message of "Fri, 07 Jan 2005 16:21:44 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.886923 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 09 Jan 2005 00:05:43 -0000 >>>>> "Florian" == Florian Weimer writes: Florian> * Russ Housley: >> Since then, two proposals have seemed to gain some acceptance. >> Internet-Drafts are available for both: >> >> http://www.ietf.org/internet-drafts/draft-fenton-identified-mail-01.txt >> >> http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-01.txt >> >> There is also a feature summary of these two available at: >> >> http://mipassoc.org/mass/crocker-features-iim-dkeys-06dc.htm >> >> I am trying to gather a few people to do a review of security >> review of these two proposals. Florian> What's your threat model? I'm happy if we come up with something that we can standardize and that people will use that breaks the Internet less than SPF. For example, it would be nice to avoid SRS and schemes that break mail forwarding. It seems like a requirement that whatever we propose be at least as effective at solving spam as SPF if it is as widely adopted. If on top of that it actually solves some security problem, that would be great too. More seriously, even if MASS has marginal value, it may still be worth standardizing. Personally I think that MASS may end up having some significant beneficial features. It may provide sufficient authentication that white-lists become more useful. --Sam From pekkas@netcore.fi Sun Jan 9 07:10:31 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j09CAT5j029973 for ; Sun, 9 Jan 2005 07:10:29 -0500 (EST) Received: from netcore.fi (netcore.fi [193.94.160.1])j09CAOVS028835; Sun, 9 Jan 2005 07:10:24 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j09CAN907645; Sun, 9 Jan 2005 14:10:23 +0200 Date: Sun, 9 Jan 2005 14:10:23 +0200 (EET) From: Pekka Savola To: Sam Hartman Subject: Re: [saag] People needed for a security review In-Reply-To: Message-ID: References: <6.2.0.14.2.20050105133928.075eb790@mail.binhost.com> <87vfa9cliv.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.139892 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 09 Jan 2005 12:10:31 -0000 On Sat, 8 Jan 2005, Sam Hartman wrote: [...] > More seriously, even if MASS has marginal value, it may still be worth > standardizing. Personally I think that MASS may end up having some > significant beneficial features. It may provide sufficient > authentication that white-lists become more useful. Can you justify how MASS would cause white-lists to become more useful? You certainly cannot use "if origin domain authenticates, it's on a white list or gets extra points", because then the spammers would just start using domain authentication and the spam problems would get worse. Of course, very specific white-lists (user@example.com, or *@example.com) that are manually configured by the user would get slightly more useful, but how much does this actually help? Many have no whitelists at all, and a lot only whitelist a couple of addresses -- spoofing those addresses may or may not be a significant issue. -- 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 pbaker@verisign.com Sun Jan 9 10:40:36 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j09FeZ5j001404 for ; Sun, 9 Jan 2005 10:40:35 -0500 (EST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) j09FeUbb022289; Sun, 9 Jan 2005 10:40:31 -0500 (EST) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id j09FeS64010091; Sun, 9 Jan 2005 07:40:28 -0800 (PST) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sun, 9 Jan 2005 07:40:28 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Pekka Savola'" , Sam Hartman Subject: RE: [saag] People needed for a security review Date: Sun, 9 Jan 2005 07:40:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.131299 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 09 Jan 2005 15:40:37 -0000 > Behalf Of Pekka Savola > Can you justify how MASS would cause white-lists to become more > useful? Well lets start by stating that 'white-list' could refer to any stateful system that uses the domain name as a key. It could be a global whitelist compiled from information collected from the entire Internet or it could simply be a list generated locally. For example if we have a way to be sure that all the email purporting to come from netcore.fi comes from the same source we can imagine any number of ways that we could arrive at a local rule to allow all mail from netcore.fi to bypass spam filtering. Bypassing the spam filters is not just about avoiding false positives. For the large ISPs and hosted spam filter companies it results in measurable savings in electricity. The big ISPs have football field sized server rooms dealling with spam. To answer Sam's point, SPF has problems, MASS has problems, fortunately they are different problems, the schemes break under different circumstances. That is a major advantage for deployment. From jari.arkko@piuha.net Sun Jan 9 10:41:05 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j09Few5j001417 for ; Sun, 9 Jan 2005 10:41:03 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) j09Fetbb022760; Sun, 9 Jan 2005 10:40:56 -0500 (EST) Received: from piuha.net (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 336E6898A0; Sun, 9 Jan 2005 17:40:51 +0200 (EET) Message-ID: <41E1504F.8010705@piuha.net> Date: Sun, 09 Jan 2005 17:39:59 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Subject: Re: [saag] People needed for a security review References: <6.2.0.14.2.20050105133928.075eb790@mail.binhost.com> <87vfa9cliv.fsf@deneb.enyo.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.907366 cc: saag@mit.edu cc: Sam Hartman X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 09 Jan 2005 15:41:06 -0000 Pekka Savola wrote: >> More seriously, even if MASS has marginal value, it may still be worth >> standardizing. Personally I think that MASS may end up having some >> significant beneficial features. It may provide sufficient >> authentication that white-lists become more useful. > > Can you justify how MASS would cause white-lists to become more useful? > > You certainly cannot use "if origin domain authenticates, it's on a > white list or gets extra points", because then the spammers would just > start using domain authentication and the spam problems would get worse. > > Of course, very specific white-lists (user@example.com, or > *@example.com) that are manually configured by the user would get > slightly more useful, but how much does this actually help? Many have > no whitelists at all, and a lot only whitelist a couple of addresses -- > spoofing those addresses may or may not be a significant issue. Sender or sender-domain authentication makes white listing possible in a reliable manner. It doesn't help with blacklisting, because spammers move to new addresses frequently, and it doesn't help in deciding whether e-mail from a previously unknown domain is spam or just a new contact. (Some network-wide mechanisms might assist in that too, if the sender's identity was somehow asserted in a reliable manner.) There might also be other ways to make sender domain more trustworthy, such as some challenge schemes. Anyway, from the 10.000ft point of view, if there was an easy solution to spam we would already have it. Looks like a number of different techniques need to be combined. This may involve more trustworthy sender or sender-domain information, to be used together with other techniques. I don't know whether that solves 1% or 50% of the problem, however. --Jari From pekkas@netcore.fi Sun Jan 9 11:03:58 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j09G3v5j001662 for ; Sun, 9 Jan 2005 11:03:57 -0500 (EST) Received: from netcore.fi (netcore.fi [193.94.160.1])j09G3rGp013424; Sun, 9 Jan 2005 11:03:53 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j09G3pS11667; Sun, 9 Jan 2005 18:03:51 +0200 Date: Sun, 9 Jan 2005 18:03:51 +0200 (EET) From: Pekka Savola To: Jari Arkko Subject: Re: [saag] People needed for a security review In-Reply-To: <41E1504F.8010705@piuha.net> Message-ID: References: <6.2.0.14.2.20050105133928.075eb790@mail.binhost.com> <87vfa9cliv.fsf@deneb.enyo.de> <41E1504F.8010705@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.543281 cc: saag@mit.edu cc: Sam Hartman X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 09 Jan 2005 16:04:00 -0000 On Sun, 9 Jan 2005, Jari Arkko wrote: >> Of course, very specific white-lists (user@example.com, or *@example.com) >> that are manually configured by the user would get slightly more useful, >> but how much does this actually help? Many have no whitelists at all, and >> a lot only whitelist a couple of addresses -- spoofing those addresses may >> or may not be a significant issue. > > Sender or sender-domain authentication makes white listing > possible in a reliable manner. It doesn't help with blacklisting, > because spammers move to new addresses frequently, and it > doesn't help in deciding whether e-mail from a previously > unknown domain is spam or just a new contact. (Some > network-wide mechanisms might assist in that too, if > the sender's identity was somehow asserted in a reliable > manner.) Yes, sender authentication adds reliability to white listing. However, my point is how useful that function is because: 1) a lot of *legitimate* mail comes from unknown domains so you can't just throw those away, 2) people don't really use all that many whitelists AFAICS, and those who do can already deal with it, and 3) hosts get broken into and turn to spam zombies, and you'll get spam from whitelisted domains as well, so whitelisting won't really help you all that much anymore... I fail to see how exactly MASS-like approaches would reduce the rate of spam. Those might make the email system work in more expected manner (easier tracing, elimination of some annoying bounce messages, maybe something else), but this would have little effect on the spam rates. -- 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 rja@extremenetworks.com Sun Jan 9 11:41:36 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j09GfY5j001841 for ; Sun, 9 Jan 2005 11:41:34 -0500 (EST) Received: from gnat.inet.org (rrcs-24-172-58-252.midsouth.biz.rr.com [24.172.58.252])j09GfWGp025581 for ; Sun, 9 Jan 2005 11:41:32 -0500 (EST) Received: from [10.30.20.60] (unknown [10.30.20.60]) by gnat.inet.org (Postfix) with ESMTP id 0340367105; Sun, 9 Jan 2005 11:35:52 -0500 (EST) In-Reply-To: References: <6.2.0.14.2.20050105133928.075eb790@mail.binhost.com> <87vfa9cliv.fsf@deneb.enyo.de> <41E1504F.8010705@piuha.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <62C21D82-625D-11D9-B0C9-000D93B505E6@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [saag] People needed for a security review Date: Sun, 9 Jan 2005 11:42:01 -0500 To: Pekka Savola X-Mailer: Apple Mail (2.619) X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.853036 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 09 Jan 2005 16:41:37 -0000 On Jan 9, 2005, at 11:03, Pekka Savola wrote: > Yes, sender authentication adds reliability to white listing. > > However, my point is how useful that function is because: > 1) a lot of *legitimate* mail comes from unknown domains so you can't > just throw those away, > 2) people don't really use all that many whitelists AFAICS, and those > who do can already deal with it, and > 3) hosts get broken into and turn to spam zombies, and you'll get > spam from whitelisted domains as well, so whitelisting won't really > help you all that much anymore... Not speaking about any particular technology approach, but commenting only on the general question (raised above) of whether "white list reliability" is really useful... I would find it very useful. 1) It would mean my systems could spend less CPU time processing traffic that can be authenticated as coming from a source I consider to be good. 2) It would also mean that the potential false positive issue, which I am not currently encountering btw, could go away for authenticated sources that are on my whitelist. If nothing else, those two are sufficient benefits to make it worth specifying openly. Whether folks choose to deploy any open specification is up to them, as it should be. There are things of benefit to mail processing that have nothing to do with reducing the amount of offered spam showing up on public interfaces. Reducing offered spam is useful and good, but it is not the only worthwhile objective in the mail processing arena. IMHO, Ran From dhc2@dcrocker.net Mon Jan 10 01:07:29 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0A67R5j006163 for ; Mon, 10 Jan 2005 01:07:27 -0500 (EST) Received: from sb7.songbird.com (sb7.songbird.com [208.184.79.137]) j0A67L3t012764; Mon, 10 Jan 2005 01:07:22 -0500 (EST) Received: from bbfujip7 (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id j0A67B5Z002994; Sun, 9 Jan 2005 22:07:14 -0800 From: Dave Crocker To: Pekka Savola , Sam Hartman X-Mailer: PocoMail 3.2 (2004) - Licensed Version X-URL: bbiw.net Date: Sun, 9 Jan 2005 22:07:17 -0800 Message-ID: <20051922717.915477@bbfujip7> In-Reply-To: Subject: Re: [saag] People needed for a security review Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.074984 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: Dave Crocker List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 10 Jan 2005 06:07:30 -0000 On Sun, 9 Jan 2005 14:10:23 +0200 (EET), Pekka Savola wrote: >  Can you justify how MASS would cause white-lists to become more >  useful? if i believe that your note really came from netcore.fi, then i can develop an assessment of mail from that domain, such as whether it is "likely" to be spam. mass is intended to provide a means of deciding reliably and accurately that mail really did come from the asserted domain, where the "from" relates to authoriship, rather than MTA administration. As noted, a mass mechanism is more likely to help with whitelisting than with blacklisting. The one exception is with mail from compromised machines that uses the domain name of that machine. On Sun, 9 Jan 2005 18:03:51 +0200 (EET), Pekka Savola wrote: >  However, my point is how useful that function is because: >    1) a lot of *legitimate* mail comes from unknown domains so you >  can't just throw those away, Any useful mechanism is likely provide incremental benefit, rather than a magic bullet that puts a stake into the heart (sorry for the mix metaphor) of spam. We need a variety of mechanisms. THe model for using them is to produce a set of scores that are combined into a final assessment. >    2) people don't really use all that many whitelists AFAICS, and those actually, there is often very significant use of whitelists. and a mechanism like mass will make it easier to use them more effectively. >    3) hosts get broken into and turn to spam zombies, and you'll get >  spam from whitelisted domains as well, so whitelisting won't really help >  you all that much anymore... and then they won't be whitelisted... On Sun, 9 Jan 2005 11:42:01 -0500, RJ Atkinson wrote: >  1) It would mean my systems could spend less CPU time processing traffic >          that can be authenticated as coming from a source I consider to be >  good. >  2) It would also mean that the potential false positive issue, >          which I am not currently encountering btw, could go away for >          authenticated sources that are on my whitelist. yes. exactly right. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker  a t ... WE'VE MOVED to:  www.bbiw.net From galvin+ietf@elistx.com Mon Jan 10 10:23:21 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0AFNJ5j009029 for ; Mon, 10 Jan 2005 10:23:19 -0500 (EST) Received: from one.elistx.com (one.elistx.com [216.0.178.29]) j0AFMpQR006406 for ; Mon, 10 Jan 2005 10:22:51 -0500 (EST) Received: from localhost (one.elistx.com [209.116.252.130]) <0IA300K4IXECVY@elistx.com> for saag@mit.edu; Mon, 10 Jan 2005 10:23:01 -0500 (EST) Date: Mon, 10 Jan 2005 10:22:55 -0500 From: James M Galvin Subject: Re: [saag] People needed for a security review In-reply-to: <20051922717.915477@bbfujip7> To: Dave Crocker , Pekka Savola Message-id: MIME-version: 1.0 X-Mailer: Mulberry/4.0.0a4 (Win32) Content-type: text/plain; format=flowed; charset=utf-8 Content-disposition: inline References: <20051922717.915477@bbfujip7> X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.964383 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id j0AFNJ5j009029 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 10 Jan 2005 15:23:22 -0000 --On Sunday, January 09, 2005 10:07 PM -0800 Dave Crocker wrote: > On Sun, 9 Jan 2005 14:10:23 +0200 (EET), Pekka Savola wrote: > >   Can you justify how MASS would cause white-lists to become more > >   useful? > > if i believe that your note really came from netcore.fi, then i can > develop an assessment of mail from that domain, such as whether it is > "likely" to be spam. > > mass is intended to provide a means of deciding reliably and accurately > that mail really did come from the asserted domain, where the "from" > relates to authoriship, rather than MTA administration. And it is because of this point that I have trouble supporting MASS. With a focus on authorship the service is pushed to the "ends", which thus makes MASS look an awful lot like S/MIME, PGP, PEM, or whatever your favorite email security protocol is. Yes, perhaps the scope is somewhat smaller insofar as you only want a signature to protect authorship, and perhaps the service is to be supported by MTAs and not necessarily the clients, but the service is still end-to-end. I think it's wrong to develop yet another email security protocol or any kind of look-alike. If we can not even use what we have to achieve the desired goal I have a lot of trouble believing that optimizing it is going to help. In contrast, I think CVS is pretty close to something that would be extremely useful. Jim From dhc2@dcrocker.net Mon Jan 10 11:08:26 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0AG8O5j009268 for ; Mon, 10 Jan 2005 11:08:24 -0500 (EST) Received: from sb7.songbird.com (sb7.songbird.com [208.184.79.137]) j0AG82HJ028991 for ; Mon, 10 Jan 2005 11:08:18 -0500 (EST) Received: from bbprime (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id j0AG6LSE025951; Mon, 10 Jan 2005 08:06:47 -0800 From: Dave Crocker To: James M Galvin , Pekka Savola X-Mailer: PocoMail 3.2 (2004) - Licensed Version X-URL: bbiw.net Date: Mon, 10 Jan 2005 08:06:21 -0800 Message-ID: <20051108621.979370@bbprime> In-Reply-To: Subject: Re: [saag] People needed for a security review Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.657875 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: Dave Crocker List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 10 Jan 2005 16:08:27 -0000 On Mon, 10 Jan 2005 10:22:55 -0500, James M Galvin wrote: >  With a focus on authorship the service is pushed to the "ends", which >  thus makes MASS look an awful lot like S/MIME, PGP, PEM, or whatever your >  favorite email security protocol is. 1. There are significant low-level technical differences between iim/dkeys and smime/pgp/pem. Not the least of these is the nature of key certification. The pronounced failure of the earlier efforts to gain adoption means that *similarities* to iim/dkeys call for extremely careful consideration of those differences, lest this be yet-another failure. However it does not render the new efforts merely redundant. 2. The architectural venue(s) for use of dkeys/iim and the duration of that use make their implementation and use likely to be quite different from earlier efforts, even though there were experiments with the earlier ones as mta/mta protocols. 3. The term "end to end" is flexible. For ever end-point, there is a use that renders it an intermediary. We need to be careful how we use the term. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker  a t ... WE'VE MOVED to:  www.bbiw.net From jaltman@columbia.edu Mon Jan 10 11:32:48 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0AGWl5j009418 for ; Mon, 10 Jan 2005 11:32:47 -0500 (EST) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5])j0AGWjHJ012067 for ; Mon, 10 Jan 2005 11:32:45 -0500 (EST) Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0)j0AGWiEA012271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 10 Jan 2005 11:32:45 -0500 (EST) Message-ID: <41E2AEF1.5060300@columbia.edu> Date: Mon, 10 Jan 2005 11:36:01 -0500 From: Jeffrey Altman Organization: Not Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: saag@mit.edu Subject: Re: [saag] People needed for a security review References: <20051108621.979370@bbprime> In-Reply-To: <20051108621.979370@bbprime> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090405030208060002090508" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.48 on 128.59.206.19 X-Spam-Score: -4.9 X-Spam-Flag: NO Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.591571 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 10 Jan 2005 16:32:49 -0000 This is a cryptographically signed message in MIME format. --------------ms090405030208060002090508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit It seems to me that what we really desire is for the existing client authentication protocols such as S/MIME and PGP to be used and then allow the receiver to query the sender's domain to obtain the certificates/keys necessary to validate the sender's signature. If the sender's domain does not have a certificate or public key registered with it, then the e-mail can be considered a bit more suspicious. It should not matter which path the e-mail travels and whether or not it originates in the sending domain. I think many of us with multiple accounts tend to send e-mails from one domain through a different one. For some of the larger e-mail hosting sites such as hotmail, yahoo, gmail, aol which keep their users in a captive environment, adding S/MIME or PGP to the accounts and signing messages would be easy to implement without involving the end users. The end users do not even need to know that S/MIME or PGP are even being used. Jeffrey Altman --------------ms090405030208060002090508 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwMTEwMTYzNjAxWjAjBgkqhkiG9w0BCQQxFgQU5ILCYgsqe8G2f5/Jas0hMkcWv+Qw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEA1IwU5z0XcJ63411RR3MdxH9l2KZP91ZXltGx65ua OyNNru9wllg3ew4kkt1DALBlUeFw/dB6hKEZv9/mt0+YH8HDW/HHbqqImCZzoglqfTg6sqSY fFHm7PdouT+Pdy+1No2ztQNRPy1mdRNwXd22/2wYTUyAyQvLVRmpmYO6bDTmUrKPSB/abeQn ua7hsqWApn/OZHkpmfI154U76fTKdl8mINJx7l4blh0W2Ly/DP+mdF0aX5CsDfhV+4+M0YJa ZO79mIfZmeIQF6tkjh/8oVRWV4eyAVlDUNG7pYG/WUxBHuwcTw5Y1/+hl26VfEYei30IBBs6 Epu5ZIylNF+PzQAAAAAAAA== --------------ms090405030208060002090508-- From hartmans@MIT.EDU Mon Jan 10 11:40:34 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0AGeW5j009491 for ; Mon, 10 Jan 2005 11:40:32 -0500 (EST) Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) j0AGeUHJ027927 for ; Mon, 10 Jan 2005 11:40:30 -0500 (EST) Received: by cz.mit.edu (Postfix, from userid 8042) id 438CFE0063; Mon, 10 Jan 2005 11:41:41 -0500 (EST) To: James M Galvin Subject: Re: [saag] People needed for a security review References: <20051922717.915477@bbfujip7> From: Sam Hartman Date: Mon, 10 Jan 2005 11:41:40 -0500 In-Reply-To: (James M. Galvin's message of "Mon, 10 Jan 2005 10:22:55 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.326405 cc: Dave Crocker cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 10 Jan 2005 16:40:35 -0000 >>>>> "James" == James M Galvin writes: James> --On Sunday, January 09, 2005 10:07 PM -0800 Dave Crocker James> wrote: >> On Sun, 9 Jan 2005 14:10:23 +0200 (EET), Pekka Savola wrote: > >>   Can you justify how MASS would cause white-lists to >> become more >   useful? >> >> if i believe that your note really came from netcore.fi, then i >> can develop an assessment of mail from that domain, such as >> whether it is "likely" to be spam. >> >> mass is intended to provide a means of deciding reliably and >> accurately that mail really did come from the asserted domain, >> where the "from" relates to authoriship, rather than MTA >> administration. James> And it is because of this point that I have trouble James> supporting MASS. It seems like your comments would better be directed at ietf-mailsigs@imc.org. While having a discussion of security properties of MASS proposals here is useful, rehashing an ongoing discussion about whether MASS is a good idea at all is counter-productive. Things that do seem useful on this list: discussing the security properties of specific MASS proposals and discussing the threat model of MASS. Things that are better discussed elsewhere include whether MASS should be chartered, whether we want to create a security solution for the MASS threat model once it is identified, and so forth. --Sam From galvin+ietf@elistx.com Mon Jan 10 13:33:09 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0AIX85j010172 for ; Mon, 10 Jan 2005 13:33:08 -0500 (EST) Received: from one.elistx.com (one.elistx.com [67.154.239.218]) j0AIWwJc015767; Mon, 10 Jan 2005 13:32:59 -0500 (EST) Received: from localhost (one.elistx.com [209.116.252.130]) by elistx.com (PMDF V6.0-025 #44856) with ESMTP id <0IA400L8L6795S@elistx.com>; Mon, 10 Jan 2005 13:33:09 -0500 (EST) Date: Mon, 10 Jan 2005 13:33:03 -0500 From: James M Galvin Subject: Re: [saag] People needed for a security review In-reply-to: To: Sam Hartman Message-id: <706EC19768288AEF8BA50EDE@[10.0.0.7]> MIME-version: 1.0 X-Mailer: Mulberry/4.0.0a4 (Win32) Content-type: text/plain; format=flowed; charset=utf-8 Content-disposition: inline References: <20051922717.915477@bbfujip7> X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.852704 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id j0AIX85j010172 cc: Dave Crocker cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 10 Jan 2005 18:33:10 -0000 I apologize for being opaque. My comment is probably in the context of this point from you: Things that are better discussed elsewhere include ... whether we want to create a security solution for the MASS threat model once it is identified ... I assumed that in the security area we would be concerned about "re-inventing the wheel." I was only asserting that the security properties of MASS are at best a subset of those available from existing IETF protocols, i.e., S/MIME, PGP, or PEM. I think it's important to ask how this "security protocol" distinguishes itself from existing security protocols. The threat model is only part of the answer. We should compare the threat model to that of other security protocols. However, if you don't want that discussion here that is fine. Can we get some volunteers to join me on ietf-mailsig@imc.org, even if it's after the threat model is decided? Jim --On Monday, January 10, 2005 11:41 AM -0500 Sam Hartman wrote: > >>>>> "James" == James M Galvin writes: > > James> --On Sunday, January 09, 2005 10:07 PM -0800 Dave Crocker > James> wrote: > > >> On Sun, 9 Jan 2005 14:10:23 +0200 (EET), Pekka Savola wrote: > > >>   Can you justify how MASS would cause white-lists to > >> become more >   useful? > >> > >> if i believe that your note really came from netcore.fi, then i > >> can develop an assessment of mail from that domain, such as > >> whether it is "likely" to be spam. > >> > >> mass is intended to provide a means of deciding reliably and > >> accurately that mail really did come from the asserted domain, > >> where the "from" relates to authoriship, rather than MTA > >> administration. > > James> And it is because of this point that I have trouble > James> supporting MASS. > > It seems like your comments would better be directed at > ietf-mailsigs@imc.org. While having a discussion of security > properties of MASS proposals here is useful, rehashing an ongoing > discussion about whether MASS is a good idea at all is > counter-productive. > > Things that do seem useful on this list: discussing the security > properties of specific MASS proposals and discussing the threat model > of MASS. Things that are better discussed elsewhere include whether > MASS should be chartered, whether we want to create a security > solution for the MASS threat model once it is identified, and so > forth. > > --Sam > From pbaker@verisign.com Mon Jan 10 13:54:23 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0AIsM5j010370 for ; Mon, 10 Jan 2005 13:54:22 -0500 (EST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) j0AIsFSJ018575 for ; Mon, 10 Jan 2005 13:54:15 -0500 (EST) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id j0AIrAf6023941; Mon, 10 Jan 2005 10:53:10 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Jan 2005 10:53:10 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'James M Galvin'" , Dave Crocker , Pekka Savola Subject: RE: [saag] People needed for a security review Date: Mon, 10 Jan 2005 10:53:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.277954 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 10 Jan 2005 18:54:24 -0000 > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On > Behalf Of James M Galvin > With a focus on authorship the service is pushed to the "ends", which > thus makes MASS look an awful lot like S/MIME, PGP, PEM, or > whatever your > favorite email security protocol is. If people take a look in the drafts area they will see that I made an effort to sell S/MIME in this context taking into account the various objections that I saw raised. The problem is that Jon Callas at PGP has already developed and deployed an S/MIME mailer that implements the proposed scheme and it does not work as well as you might expect. We are not talking about end to end solutions here. I think that we have to get away from the idea that we can build Internet security without using any scafolding. I am quite happy with the idea of deploying Domain Keys into the existing infrastructure, I see it as an enabler for S/MIME, not a competitor. From sommerfeld@sun.com Mon Jan 10 14:27:00 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0AJQw5j010607 for ; Mon, 10 Jan 2005 14:26:58 -0500 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) j0AJQrJc011818 for ; Mon, 10 Jan 2005 14:26:53 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j0AJPmVu024057; Mon, 10 Jan 2005 12:25:48 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) ESMTP id j0AJPl8p000119; Mon, 10 Jan 2005 14:25:47 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) j0AJPlxe024187; Mon, 10 Jan 2005 14:25:47 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.1+Sun/8.13.1/Submit) id j0AJPkuT024185; Mon, 10 Jan 2005 14:25:46 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: [saag] People needed for a security review From: Bill Sommerfeld To: Dave Crocker In-Reply-To: <20051108621.979370@bbprime> References: <20051108621.979370@bbprime> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1105385145.23485.170.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.324 Date: Mon, 10 Jan 2005 14:25:46 -0500 X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.621826 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 10 Jan 2005 19:27:01 -0000 On Mon, 2005-01-10 at 11:06, Dave Crocker wrote: > 3. The term "end to end" is flexible. For ever end-point, there is a use > that renders it an intermediary. We need to be careful how we use the term. well, in the specific case of mail, i think we'll be in a much better position if we can make the intermediary relationships "first class citizens" -- making the MTA's and MUA's aware of subscriptions and forwarding. That way the "delete as spam" buttons can report back "no, I have a record that you really did subscribe to this two years ago. sending unsubscribe request". It occurred to me that one of the holes in the mail-related documents I've seen is the notion that, in a properly configured mail system, for any given (recipient,message) tuple wandering through the mail system, the MTA's it traverses at each stage ought to be clearly identifiable as acting as an agent of either the sender (S-MTA), the recipient (R-MTA), or both. Ideally, S-MTA's know for sure who the sender is. R-MTA's know for sure *where* the message is going. I think this property has been retrofitted into many of the implementations (as a result of closing open relays) but to the best of my knowledge it hasn't really made it into the protocols or specs (please correct me if I'm wrong..) one ought to then be able to document appropriate behavior for policy enforcement tools (spam filters, virus filters, etc,) which may differ based on whether a message delivery attempt is S-S, S-R, or R-R. One also ought to be able to go on and document services that an S-MTA provides to senders, and services (particularly policy enforcement) which R-MTA's provide to recipients. Note that with mail forwarding the first .forward or equivalent is the start of the R-MTA chain, and R-MTA's further down the chain which do complex policy enforcement really ought to be aware that this aliasing/forwarding is going on. - Bill From jon@callas.org Tue Jan 11 17:08:34 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0BM8V5j018222 for ; Tue, 11 Jan 2005 17:08:32 -0500 (EST) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) j0BM8QCU024907 for ; Tue, 11 Jan 2005 17:08:27 -0500 (EST) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.5); Tue, 11 Jan 2005 13:37:49 -0800 Received: from [192.168.2.164] ([63.251.255.85]) by keys.merrymeet.com (PGP Universal service); Tue, 11 Jan 2005 13:37:48 -0800 X-PGP-Universal: processed In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <11684D4A-6419-11D9-B343-000D9344F9D6@callas.org> Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: [saag] People needed for a security review Date: Tue, 11 Jan 2005 13:38:01 -0800 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.619) X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.358262 cc: saag@mit.edu cc: Dave Crocker X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 11 Jan 2005 22:08:35 -0000 > The problem is that Jon Callas at PGP has already developed and > deployed an > S/MIME mailer that implements the proposed scheme and it does not work > as > well as you might expect. > > We are not talking about end to end solutions here. > I think I need to clarify here. My automatic mailing mail (called PGP Universal) system does OpenPGP and S/MIME and works just fine, thank you. Please do not say things about my product like "it does not work as well as you might expect" glibly like that. I have no idea what you're talking about. There are too many pronouns there without antecedents. However, neither OpenPGP nor S/MIME are adequate solutions for the problem that Domain Keys / Identified Internet Mail is designed to solve. They're solving different problems. I've written my own long assessments on why they are different. I can drag one out if someone wants to see it. Jon From hartmans@MIT.EDU Tue Jan 11 17:23:08 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0BMN65j018314 for ; Tue, 11 Jan 2005 17:23:06 -0500 (EST) Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) j0BMMXCU020219 for ; Tue, 11 Jan 2005 17:22:33 -0500 (EST) Received: by cz.mit.edu (Postfix, from userid 8042) id 55567E0063; Tue, 11 Jan 2005 17:23:47 -0500 (EST) To: Jon Callas Subject: Re: [saag] People needed for a security review References: <11684D4A-6419-11D9-B343-000D9344F9D6@callas.org> From: Sam Hartman Date: Tue, 11 Jan 2005 17:23:47 -0500 In-Reply-To: <11684D4A-6419-11D9-B343-000D9344F9D6@callas.org> (Jon Callas's message of "Tue, 11 Jan 2005 13:38:01 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.473699 cc: Dave Crocker cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 11 Jan 2005 22:23:09 -0000 >>>>> "Jon" == Jon Callas writes: Jon> However, neither OpenPGP nor S/MIME are adequate solutions Jon> for the problem that Domain Keys / Identified Internet Mail Jon> is designed to solve. They're solving different problems. Jon> I've written my own long assessments on why they are Jon> different. I can drag one out if someone wants to see it. Please do. It would be useful to a lot of discussions. From jon@callas.org Tue Jan 11 18:13:02 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0BNCx5j018554 for ; Tue, 11 Jan 2005 18:12:59 -0500 (EST) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) j0BNCmVf002963; Tue, 11 Jan 2005 18:12:48 -0500 (EST) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.5); Tue, 11 Jan 2005 15:12:25 -0800 Received: from [192.168.2.164] ([63.251.255.85]) by keys.merrymeet.com (PGP Universal service); Tue, 11 Jan 2005 15:12:23 -0800 X-PGP-Universal: processed In-Reply-To: References: <11684D4A-6419-11D9-B343-000D9344F9D6@callas.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <01362669-6426-11D9-B343-000D9344F9D6@callas.org> From: Jon Callas Subject: Re: [saag] People needed for a security review Date: Tue, 11 Jan 2005 15:10:37 -0800 To: Sam Hartman X-Mailer: Apple Mail (2.619) X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 2.180523 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id j0BNCx5j018554 cc: Dave Crocker cc: saag@MIT.EDU X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 11 Jan 2005 23:13:02 -0000 On 11 Jan 2005, at 2:23 PM, Sam Hartman wrote: > > Please do. It would be useful to a lot of discussions. > > Original is at: Given as how I'm incapable of leaving well enough alone, I'm going to add in a few comments and perhaps the occasional small rant. I'll put square brackets where I add in data. -------- • From: Jon Callas • Date: Mon, 4 Oct 2004 14:02:58 -0700 > I too have yet to hear a cogent explaination why S/MIME with > appropriate > header information included under the signature would not handle this > problem. If I'm beating a dead horse, plz let me know where this > thrashing has been archived (I acknowledge that I'm new to this list). Allow me to try to give one. Let me say up front that I am a provider of both OpenPGP and S/MIME systems. I have a commitment to support in my systems whatever MASS produces as well as whatever MARID finally ends up with (or failing that, SPF). None of the RFC 1847-based systems (both S/MIME and OpenPGP/MIME build on 1847) are sufficient for these purposes. Here's why: * They solve different problems. 1847 is a content-security system. It is specifically not designed to handle header security, and if anything header security is an anti-goal. Protecting subjects, from lines, dates, and so on are things that 1847+ simply does not address. While MASS must handle the security of some of the content (to compensate for replay attacks), it is primarily dealing with the security of the headers and can apply a less-strict security policy to the body (and in fact must, because there are many parts of the body that do get modified and MASS must compensate for this). Lastly, 1847 doesn't work for fake users. MASS must. For example, MASS has to work for the case of . In fact, it is *more* important that it work for virtual addresses like this than for "real" users. [Lately, my experiences with working with a work-related newsletter that gets managed through an outsourced bureau has made me even more convinced of the importance of this wrinkle.] * The security models are different. S/MIME and OpenPGP are designed for user-to-user security. The problem MASS is solving is a different problem, that of server authentication. For example, Yahoo wants to know if a message really came from eBay. It doesn't care any more than that. That is all it needs to know. Furthermore, one of the anti-goals of MASS is for it to be a privacy-violating system. For example, both Domain Keys and Identified Mail are very carefully construct to be as privacy-friendly as possible. If MASS gets a rep for being privacy-unfriendly, it's going to fail. Also, it is vital for the system to work at all that is be a server-authentication system. I wrote an article on how an organized gang of spammers can launch an attack of an end-user authentication system and bring about its collapse. Take a look at: . [Perhaps the great unsolved problem in digital signature systems today is the semantic issue of what signatures mean. In OpenPGP and S/MIME, we glibly ignore this (but that was and is the right thing for them to do). Domain Keys / IIM takes this very seriously, and handles it well.] * We need simplicity. As someone who's got to implement all this, let me tell you that OpenPGP and S/MIME are hard enough to do as it is without complexifying them further. I would rather implement four (relatively) simple protocols than two more complex ones. Shoehorning MASS into S/MIME makes as much sense as advocating getting rid of SMTP and putting it all in IMAP. * It requires MUA changes. If you add in a new MIME part, it requires not only changes in every MTA, but in every MUA, too. Furthermore, MIME-handling is one of those things that the existing MUAs don't do very well at all. This is the dirty secret of MIME. MIME works flawlessly when it is a form of file transfer. If I "email you a document" -- that's what MIME does best. It works nearly perfectly when you use it as transport for rich text email (think of an HTML body and a few pictures riding along). [Unless you want to forward the message, in which all hell breaks loose. This makes it really difficult to email travel arrangements to people who want to read them. My present solution is to print-to-PDF and then mail the PDF when I need to forward an important pretty email.] It works mostly kinda okay with security multiparts. I don't know of a single MUA that can handle a message with rich text, pictures, attached files, and some combination of signing and encrypting. Adding in a new dialect of security multiparts is going to require that every MUA, from Outlook to Notes to Eudora to Mutt to Hushmail to Gmail to handle this. It isn't going to happen on the schedule it needs to. Even if you wave a magic wand have everything supporting it tomorrow, there will be user pushback. They won't want to install it without testing, they won't want to pay for the upgrades, and on and on. One of the advantages that header-based systems like Domain Keys and Identified Mail have is that MUAs are *really* good at hiding the users from scary headers. It thus has very good backwards compatibility features. It is my opinion that any system that requires an MUA change will fail. It's as simple as that. I can tell you that *I'm* not going to change my MUA. Furthermore, when a large ISP starts getting support calls about "these funny attachments" they're more likely to turn it off than continue to use it. Email is such a critical part of the infrastructure that requiring a flag day on it will doom an otherwise good system. * MASS (along with all other authentication systems including but not limited to MARID) is necessary but not sufficient. It needs some semantic processing, too. You have to know that when the domain 'mafia.ru' sends you an email, that you have to know whether or not you are going to be accepting mail from that domain at all. This is a subtle and very important point because it adds to friction on any of the above points. It means that the objections people have to any sort of inconvenience will be magnified by this fact. They will over-simplify this fact with the phrase, "...and it doesn't actually work." If, for example, MASS requires someone to upgrade their MUA, people will say, "This is an excuse to pry money out of you for a spam-fighting system that doesn't actually stop spam." You'll see newspaper articles that say, "What are those funny attachments? They're part of a new Internet spam-fighting system that clutters your mailbox, but doesn't actually stop spam." This is why S/MIME and OpenPGP aren't going to work. This is why we need a new system. Jon -- Jon Callas CTO, CSO PGP Corporation Tel: +1 (650) 319-9016 3460 West Bayshore Fax: +1 (650) 319-9001 Palo Alto, CA 94303 PGP: ed15 5bdf cd41 adfc 00f3 USA 28b6 52bf 5a46 bc98 e63d From pbaker@verisign.com Tue Jan 11 19:53:30 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0C0rT5j018979 for ; Tue, 11 Jan 2005 19:53:29 -0500 (EST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) j0C0rR39015558 for ; Tue, 11 Jan 2005 19:53:27 -0500 (EST) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id j0C0q0qO002317; Tue, 11 Jan 2005 16:52:00 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 11 Jan 2005 16:52:00 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Jon Callas'" , "Hallam-Baker, Phillip" Subject: RE: [saag] People needed for a security review Date: Tue, 11 Jan 2005 16:52:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.084647 cc: saag@mit.edu cc: Dave Crocker X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 12 Jan 2005 00:53:32 -0000 > From: Jon Callas [mailto:jon@callas.org] > > The problem is that Jon Callas at PGP has already developed and > > deployed an > > S/MIME mailer that implements the proposed scheme and it > does not work > > as > > well as you might expect. > > > > We are not talking about end to end solutions here. > > > > I think I need to clarify here. My automatic mailing mail (called PGP > Universal) system does OpenPGP and S/MIME and works just fine, thank > you. Please do not say things about my product like "it does not work > as well as you might expect" glibly like that. I have no idea what > you're talking about. There are too many pronouns there without > antecedents. Absolutely, I was not attempting to imply that the mailer does not work. The problem is that tweaking S/MIME or PGP and trying to get them to work in ways that are well outside the original design scenarios does not work as well as you would want when you are trying to deal with a complex multi-vendor deployed infrastructure. Domain Keys / IIM are trying to solve a different problem and be used in a different way to the 1990s era schemes. The fundamental objective of DK is to be transparent and have no negative impact on infrastructure that does not understand the format. The starting point for S/MIME and PGP was that everyone would be using encrypted email and that that signature thing comes for free. It might sound like a great idea to try to make use of what we have already, if email had been designed to be secure from the very start that might have been an option. Given where we are we need to be willing to look at different approaches even if long term all that Domain Keys does is to lower the learning/barrier-to-entry curve and can be dispensed with after that work is complete it will have done an important job and more than justified itself. I think it important to make sure we do not orphan the S/MIME or PGP communities. But if this is done right then we can be an enabler for the legacy protocols and provide a killer application that drives deployment of the missing infrastructure that has stopped either from really succeeding as it could. Phill From dhc2@dcrocker.net Tue Jan 11 19:54:54 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0C0sr5j019004 for ; Tue, 11 Jan 2005 19:54:53 -0500 (EST) Received: from sb7.songbird.com (sb7.songbird.com [208.184.79.137]) j0C0sf39019248 for ; Tue, 11 Jan 2005 19:54:41 -0500 (EST) Received: from bbprime (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id j0C0sd32005515; Tue, 11 Jan 2005 16:54:40 -0800 From: Dave Crocker To: Bill Sommerfeld X-Mailer: PocoMail 3.2 (2004) - Licensed Version X-URL: bbiw.net Date: Tue, 11 Jan 2005 16:54:39 -0800 Message-ID: <2005111165439.847314@bbprime> In-Reply-To: <1105385145.23485.170.camel@thunk> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-5107-1" Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.838491 cc: saag@mit.edu Subject: [saag] security-related mail infrastructure enhancement X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: Dave Crocker List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 12 Jan 2005 00:54:55 -0000 (this line of messages does not have to do with the mass documents, so i've changed the subject line. ) On Mon, 10 Jan 2005 14:25:46 -0500, Bill Sommerfeld wrote: >  well, in the specific case of mail, i think we'll be in a much better position >  if we can make the intermediary relationships "first class citizens" -- making >  the MTA's and MUA's aware of subscriptions and forwarding. mta's??? in the form you state this, i hope you do not really mean it. you want mtas to know what is the possible benefit of moving end-system details into the infrastructure? think about applying similar logic to ip and transport services, for routers. >  That way the "delete as >  spam" buttons can report back "no, I have a record that you really did subscribe to this >  two years ago. sending unsubscribe request". there is discussion about such a mechanism. i think it will prove useful, but it has nothing to do with mta's. >  It occurred to me that one of the holes in the mail-related >  documents I've seen is the notion that, in a properly configured mail system, >  for any given (recipient,message) tuple wandering through the mail system, the >  MTA's it traverses at each stage ought to be clearly identifiable as acting as an >  agent of either the sender (S-MTA), the recipient (R-MTA), or both. interesting thought. in general you are suggesting a formal trust model for email. the latest email-arch draft does try to discuss responsibilities and trust for the MSA and MDA roles, but MTA's are no so obvious to identify. Ned Freed has suggested paying attention to 'administrative domains', given the variety of things done to a message by intermediaries within the origin or destination administrative domains, and I'm trying to find a way to add that to the architecture draft. Sure seems like you are suggesting walking down the same path. >  Ideally, S-MTA's know for sure who the sender is.  R-MTA's know for sure *where* >  the message is going. Although there are some SMTP options that have hop-by-hop enforcement, I think that none of the mechanism rise to the level of security-related trust that you are suggesting here. They are entirely cooperative, with no protections against abuse. That does not mean it's not a useful path to explore, but rather that it probably is not a straightforward incremental enhancement (or, at least, not obviously so.) >  I think this property has been retrofitted into many of the >  implementations (as a result of closing open relays) my question would be whether those existing mechanisms would satisfy serious review by the security community. they might work fine in small, scale, informal situations, but would they work as more generalized Internet standards mechanisms? >  one ought to then be able to document appropriate behavior for policy >  enforcement tools (spam filters, virus filters, etc,) which may differ >  based on whether a message delivery attempt is S-S, S-R, or R-R. i'm not quite following you, here. deliveries are done by MDAs. please elaborate/clarify. >  Note that with mail forwarding the first .forward or equivalent is the start of the >  R-MTA chain, and R-MTA's further down the chain which do complex policy enforcement >  really ought to be aware that this aliasing/forwarding is going on. yup. there is, at least, some discussion about adding a parameter to the Received header, to note this type of forwarding event. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker  a t ... WE'VE MOVED to:  www.bbiw.net From hartmans@MIT.EDU Wed Jan 12 00:17:43 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0C5Hf5j020287 for ; Wed, 12 Jan 2005 00:17:41 -0500 (EST) Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) j0C5HbLJ025091 for ; Wed, 12 Jan 2005 00:17:37 -0500 (EST) Received: by luminous.mit.edu (Postfix, from userid 1000) id 77C3576AF3; Wed, 12 Jan 2005 00:17:36 -0500 (EST) To: saag@mit.edu From: Sam Hartman Date: Wed, 12 Jan 2005 00:17:35 -0500 Message-ID: <87brbvgr9s.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.185939 Subject: [saag] SAML 2.0: review of ietf technologies X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 12 Jan 2005 05:17:44 -0000 --=-=-= Hi, folks. I was sitting down to do a review of SAML 2.0, and to my surprise it refers to a significant number of IETF technologies. I don't know about other technologies, but I'm fairly sure no one who has been active in the Kerberos working group has reviewed their Kerberos stuff. I notice they also seem to interact with PGP, something called sslcert, X.509, SRP and several others. I'd appreciate it if as many people as possible could take a look at this. The review period ends on January 14. Needless to say, had I realized how much IETF technology was referenced, I would likely have been following the SAML development more closely and certainly would have dedicated more time to the review. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.16-IPv6-Debian-2.1.16-10) with LMTP; Thu, 30 Dec 2004 14:16:00 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from south-station-annex.mit.edu (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by suchdamage.org (Postfix) with ESMTP id 18CE913252 for ; Thu, 30 Dec 2004 14:16:00 -0500 (EST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76])iBUJFxLn013920 for ; Thu, 30 Dec 2004 14:15:59 -0500 (EST) Received: from hoemail1.lucent.com (hoemail1.lucent.com [192.11.226.161]) iBUJDt5H029373 for ; Thu, 30 Dec 2004 14:13:55 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iBUJDq4L000018 for ; Thu, 30 Dec 2004 13:13:53 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 30 Dec 2004 20:13:51 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550604F0F8@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Russ Housley (E-mail)" , "Sam Hartman (E-mail)" Subject: FW: [members] Public Review of SAML 2.0 Date: Thu, 30 Dec 2004 20:13:43 +0100 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: -4.9 X-Scanned-By: MIMEDefang 2.42 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 MIME-Version: 1.0 Are you guys aware of this? Is it something you want to check/review? Bert -----Original Message----- From: Mary McRae [mailto:mary.mcrae@oasis-open.org] Sent: Wednesday, December 15, 2004 18:38 To: 'Wijnen, Bert (Bert)' Subject: RE: [members] Public Review of SAML 2.0 Hi Bert, Yes; public review is not limited in any way to OASIS members only; oftentimes the notice will also be posted to other lists at the request of the TC chair(s). Anyone can provide comments through the TC's public page via the comment button. I would ask that they download the files directly either from the links given in this email or from the TC's public page (rather than you downloading/forwarding them) to ensure that they have the proper information set. Regards, Mary -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Wednesday, December 15, 2004 7:43 AM To: 'mary.mcrae@oasis-open.org' Subject: RE: [members] Public Review of SAML 2.0 Mary, if I wanted some of my IETF peers to take a look at this, would that be OK (even though they are not necessarily (employed by) members of OASIS) ?? Thanks, Bert > -----Original Message----- > From: Mary McRae [mailto:mary.mcrae@oasis-open.org] > Sent: Wednesday, December 15, 2004 12:13 > To: tc-announce@lists.oasis-open.org; members@lists.oasis-open.org > Subject: [members] Public Review of SAML 2.0 > > > To: OASIS members, public announce lists > > The OASIS Security Services TC has recently approved the Security > Assertion Markup Language (SAML) v2.0 specification as a Committee > Draft and approved it for public review. The public review starts > today, 15 December 2004 and ends 14 January 2005. > > Public review from potential users, developers and stakeholders is an > important part of the OASIS process to assure interoperability and > quality. > Comments are solicited from all interested parties. Comments may be > submitted to the TC by any person via a web form found on the TC's web > page at http://www.oasis-open.org/committees/security. Click the > button for "Send A Comment" at the top of the page. > > Submitted comments (for this work as well as other works of that TC) > are publicly archived and can be viewed at > http://lists.oasis-open.org/archives/security-services-comment/. > > > The files are available here: > > 1. A Zip file is available that contains all SAML V2.0 specification > PDF files and all schemas. Note that there are 2 versions of each PDF > file; one for the spec and one for reference purposes containing all > differences since the CD-01 files were released. The ZIP file is > located at: > > http://www.oasis-open.org/committees/download.php/10683/sstc-s > aml-2.0-cd-03-pdf-xsd.zip > > > 2. The 8 individual SAML V2.0 PDF files (with no diff's) are publicly > available at: > > http://www.oasis-open.org/committees/download.php/10624/sstc-s > aml-conformanc > e-2.0-cd-03.pdf > > http://www.oasis-open.org/committees/download.php/10627/sstc-s > aml-core-2.0-c > d-03.pdf > > http://www.oasis-open.org/committees/download.php/10618/sstc-s > aml-bindings-2 > .0-cd-03.pdf > > http://www.oasis-open.org/committees/download.php/10636/sstc-s > aml-profiles-2 > .0-cd-03.pdf > > http://www.oasis-open.org/committees/download.php/10619/sstc-s > aml-authn-cont > ext-2.0-cd-03.pdf > > http://www.oasis-open.org/committees/download.php/10633/sstc-s > aml-metadata-2 > .0-cd-03.pdf > > http://www.oasis-open.org/committees/download.php/10639/sstc-s > aml-sec-consid > er-2.0-cd-03.pdf > > http://www.oasis-open.org/committees/download.php/10630/sstc-s > aml-glossary-2 > .0-cd-03.pdf > > > > 3. The 7 individual main SAML V2.0 schema files are publicly available > at: > > http://www.oasis-open.org/committees/download.php/10642/sstc-s > aml-schema-ass > ertion-2.0.xsd > > http://www.oasis-open.org/committees/download.php/10646/sstc-s > aml-schema-pro > tocol-2.0.xsd > > http://www.oasis-open.org/committees/download.php/10645/sstc-s > aml-schema-met > adata-2.0.xsd > > http://www.oasis-open.org/committees/download.php/10644/sstc-s > aml-schema-ecp > -2.0.xsd > > http://www.oasis-open.org/committees/download.php/10647/sstc-s > aml-schema-x50 > 0-2.0.xsd > > http://www.oasis-open.org/committees/download.php/10648/sstc-s > aml-schema-xac > ml-2.0.xsd > > http://www.oasis-open.org/committees/download.php/10643/sstc-s > aml-schema-dce > -2.0.xsd > > > > 4. The 2 individual core SAML V2.0 Authentication Context schema files > are publicly available at: > > http://www.oasis-open.org/committees/download.php/10650/sstc-s > aml-schema-aut > hn-context-2.0.xsd > > http://www.oasis-open.org/committees/download.php/10675/sstc-s > aml-schema-aut > hn-context-types-2.0.xsd > > > > 5. The 24 individual SAML V2.0-defined Authentication Context Class > schema files are publicly available at: > > http://www.oasis-open.org/committees/download.php/10651/sstc-s > aml-schema-aut > hn-context-auth-telephony-2.0.xsd > > http://www.oasis-open.org/committees/download.php/10653/sstc-s > aml-schema-aut > hn-context-ip-2.0.xsd > > http://www.oasis-open.org/committees/download.php/10654/sstc-s > aml-schema-aut > hn-context-ippword-2.0.xsd > > http://www.oasis-open.org/committees/download.php/10655/sstc-s > aml-schema-aut > hn-context-kerberos-2.0.xsd > > http://www.oasis-open.org/committees/download.php/10657/sstc-s > aml-schema-aut > hn-context-mobileonefactor-reg-2.0.xsd > > http://www.oasis-open.org/committees/download.php/10658/sstc-s > aml-schema-aut > hn-context-mobileonefactor-unreg-2.0.xsd > > http://www.oasis-open.org/committees/download.php/10659/sstc-s > aml-schema-aut > hn-context-mobiletwofactor-reg-2.0.xsd > > http://www.oasis-open.org/committees/download.php/10660/sstc-s > aml-schema-aut > hn-context-mobiletwofactor-unreg-2.0.xsd > > http://www.oasis-open.org/committees/download.php/10661/sstc-s > aml-schema-aut > hn-context-nomad-telephony-2.0.xsd > > http://www.oasis-open.org/committees/download.php/10662/sstc-s > aml-schema-aut > hn-context-personal-telephony-2.0.xsd > > http://www.oasis-open.org/committees/download.php/10663/sstc-s aml-schema-aut hn-context-pgp-2.0.xsd http://www.oasis-open.org/committees/download.php/10664/sstc-saml-schema-aut hn-context-ppt-2.0.xsd http://www.oasis-open.org/committees/download.php/10665/sstc-saml-schema-aut hn-context-pword-2.0.xsd http://www.oasis-open.org/committees/download.php/10666/sstc-saml-schema-aut hn-context-session-2.0.xsd http://www.oasis-open.org/committees/download.php/10667/sstc-saml-schema-aut hn-context-smartcard-2.0.xsd http://www.oasis-open.org/committees/download.php/10668/sstc-saml-schema-aut hn-context-smartcardpki-2.0.xsd http://www.oasis-open.org/committees/download.php/10669/sstc-saml-schema-aut hn-context-softwarepki-2.0.xsd http://www.oasis-open.org/committees/download.php/10670/sstc-saml-schema-aut hn-context-spki-2.0.xsd http://www.oasis-open.org/committees/download.php/10671/sstc-saml-schema-aut hn-context-srp-2.0.xsd http://www.oasis-open.org/committees/download.php/10672/sstc-saml-schema-aut hn-context-sslcert-2.0.xsd http://www.oasis-open.org/committees/download.php/10673/sstc-saml-schema-aut hn-context-telephony-2.0.xsd http://www.oasis-open.org/committees/download.php/10674/sstc-saml-schema-aut hn-context-timesync-2.0.xsd http://www.oasis-open.org/committees/download.php/10676/sstc-saml-schema-aut hn-context-x509-2.0.xsd http://www.oasis-open.org/committees/download.php/10677/sstc-saml-schema-aut hn-context-xmldsig-2.0.xsd Mary Mary P McRae OASIS Manager of TC Administration email: mary.mcrae@oasis-open.org web: www.oasis-open.org _______________________________________________________________ This email list is used solely by OASIS for official consortium communications. Opt-out requests may be sent to member_services@oasis-open.org, however, all members are strongly encouraged to maintain a subscription to this list. --=-=-=-- From sommerfeld@sun.com Wed Jan 12 06:47:04 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0CBl45j022212 for ; Wed, 12 Jan 2005 06:47:04 -0500 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) j0CBl14A021566 for ; Wed, 12 Jan 2005 06:47:01 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0CBkldt007994; Wed, 12 Jan 2005 04:46:47 -0700 (MST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) ESMTP id j0CBkl8p021311; Wed, 12 Jan 2005 06:46:47 -0500 (EST) From: Bill Sommerfeld To: Dave Crocker In-Reply-To: <2005111165439.847314@bbprime> References: <2005111165439.847314@bbprime> Content-Type: text/plain; charset=ASCII Message-Id: <1105530394.28612.1790.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.324 Date: Wed, 12 Jan 2005 06:46:35 -0500 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000001 Spam-Alum-Time: 0.521226 cc: saag@mit.edu Subject: [saag] Re: security-related mail infrastructure enhancement X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 12 Jan 2005 11:47:06 -0000 On Tue, 2005-01-11 at 19:54, Dave Crocker wrote: > interesting thought. in general you are suggesting a formal trust model > for email. I guess I am. part of the problem now is that in the absence of a common model, everyone evaluating these various proposed security mechanisms does so with reference to their personal ad-hoc trust model, with the net result that we have no chance of reaching consensus on whether these mechanisms actually do any good.. From hartmans@MIT.EDU Wed Jan 12 07:21:54 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0CCLr5j022412 for ; Wed, 12 Jan 2005 07:21:53 -0500 (EST) Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) j0CCLoG4006728 for ; Wed, 12 Jan 2005 07:21:50 -0500 (EST) Received: by luminous.mit.edu (Postfix, from userid 1000) id D80D976B9A; Wed, 12 Jan 2005 07:21:48 -0500 (EST) To: Tschofenig Hannes Subject: Re: [saag] SAML 2.0: review of ietf technologies References: <2A8DB02E3018D411901B009027FD3A3F0550BD04@mchp905a.mch.sbs.de> From: Sam Hartman Date: Wed, 12 Jan 2005 07:21:48 -0500 In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F0550BD04@mchp905a.mch.sbs.de> (Tschofenig Hannes's message of "Wed, 12 Jan 2005 10:55:58 +0100") Message-ID: <877jmihm77.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.586542 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 12 Jan 2005 12:21:55 -0000 >>>>> "Tschofenig" == Tschofenig Hannes writes: Tschofenig> hi sam, review deadline is january 14th. today is the Tschofenig> 12th. the documents are huge. it might be difficult Tschofenig> todo a serious review in two days. is this a hard Tschofenig> deadline? I'm not an OASIS member so I don't know what their process is, but it looks like ballots are issued shortly after the review period ends. It turns out though that most of the references to IETF specifications come from the sstc-saml-2.0-authn-context specification. This specification provides assertions of what method is used to authenticate the subject of an assertion. So, for example, when looking at the PGP class you'd want to make sure they could properly identify all PGP keys, but there will not be uses of PGP protocol messages you have to validate. I do realize that the documents are huge; I've been alternating slogging through the core spec and the authn-context spec. As I begin to understand how this all fits together, I'm less concerned than I was when I wrote the message last night. Any problems that are discovered in the authn-context document seem like they will show up as an inability to express some authentication or confusing spec language than as a security compromise because of a bug in how our technology is used. Another thing I was potentially worried about--use of our technology in ways that might make it hard for us to extend--seems to be a non-issue. That said, I'm sure they would appreciate any comments you have time to discover and write. From dhc2@dcrocker.net Wed Jan 12 10:38:20 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0CFcJ5j023546 for ; Wed, 12 Jan 2005 10:38:19 -0500 (EST) Received: from sb7.songbird.com (sb7.songbird.com [208.184.79.137]) j0CFcFCr014107 for ; Wed, 12 Jan 2005 10:38:16 -0500 (EST) Received: from bbprime (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id j0CFcEDG002379; Wed, 12 Jan 2005 07:38:14 -0800 From: Dave Crocker To: Bill Sommerfeld X-Mailer: PocoMail 3.2 (2004) - Licensed Version X-URL: bbiw.net Date: Wed, 12 Jan 2005 07:38:14 -0800 Message-ID: <200511273814.446488@bbprime> In-Reply-To: <1105530394.28612.1790.camel@unknown.hamachi.org> Subject: Re: [saag] Re: security-related mail infrastructure enhancement Mime-Version: 1.0 Content-Type: text/plain; charset="ASCII" Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.606137 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: Dave Crocker List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 12 Jan 2005 15:38:22 -0000 > > interesting thought.  in general you are suggesting a formal trust model > > for email. .... >  part of the problem now is that in the absence of a common model, everyone >  evaluating these various proposed security mechanisms does so with reference >  to their personal ad-hoc trust model, yup. I started work on the email-arch I-D when it became clear that the current community working on anti-spam email modifications had no common view of Internet mail's architecture (or even terminology.) The effort to document the existing architecture has been unexpectedly challenging -- and even enlightening (to me, at least.) In general, I think that Internet technical work tends to miss the issue of administrative boundaries. That's why I was delighted to see the discussion of "Tussle" boundaries. The discussion needs to continue. We think of IP as solving an interconnect problem between different network technologies. And my understanding is that that, certainly, was how it was originally motivated. But I tend to view the more important motivating factor as connecting different administrations. After all, the the technical need flowed from the observation that existing network operations were not going to agree on a common network technology. It was the independence of the administrations that created the need. The distinction between interior and exterior routing services is an extremely clean and distinct example of seeing and dealing with this tussle boundary. We need similar distinctions in the rest of the Internet service, certainly including email. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker  a t ... WE'VE MOVED to:  www.bbiw.net From nw141292@binky.central.sun.com Wed Jan 12 12:15:27 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0CHFO5j024195 for ; Wed, 12 Jan 2005 12:15:25 -0500 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) j0CHFGCr027475; Wed, 12 Jan 2005 12:15:17 -0500 (EST) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j0CHFGVu020487; Wed, 12 Jan 2005 10:15:16 -0700 (MST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) with ESMTP id j0CHFCkS016692; Wed, 12 Jan 2005 10:15:12 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) j0CHDvWZ352184; Wed, 12 Jan 2005 11:13:57 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id j0CHDvNs352183; Wed, 12 Jan 2005 11:13:57 -0600 (CST) Date: Wed, 12 Jan 2005 11:13:56 -0600 From: Nicolas Williams To: Sam Hartman Subject: Re: [saag] SAML 2.0: review of ietf technologies Message-ID: <20050112171356.GX184117@binky.central.sun.com> References: <87brbvgr9s.fsf@luminous.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87brbvgr9s.fsf@luminous.mit.edu> User-Agent: Mutt/1.4.1i X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.831314 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 12 Jan 2005 17:15:27 -0000 On Wed, Jan 12, 2005 at 12:17:35AM -0500, Sam Hartman wrote: > > Hi, folks. I was sitting down to do a review of SAML 2.0, and to my > surprise it refers to a significant number of IETF technologies. > > I don't know about other technologies, but I'm fairly sure no one who has been active in the Kerberos working group has reviewed their Kerberos stuff. I notice that the SAML core refers to Kerberos principal names as having the old Kerberos IV syntax, yet it references RFC1510! > 8.3.5 Kerberos Principal Name > > URI:urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos > > Indicates that the content of the element is in the form of a > Kerberos principal name using the format name [/instance ]@REALM. > The syntax,format and characters allowed for the name,instance,and > realm are described in [RFC 1510 ]. > I notice they also seem to interact with PGP, something called > sslcert, X.509, SRP and several others. > > I'd appreciate it if as many people as possible could take a look at > this. The review period ends on January 14. Needless to say, had I > realized how much IETF technology was referenced, I would likely have > been following the SAML development more closely and certainly would > have dedicated more time to the review. January 14?! Nico -- From jwkckid1@ix.netcom.com Wed Jan 12 23:17:40 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0D4Hc5j028122 for ; Wed, 12 Jan 2005 23:17:38 -0500 (EST) Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25])j0D4HW61008928 for ; Wed, 12 Jan 2005 23:17:32 -0500 (EST) Received: from 1cust178.tnt36.dfw9.da.uu.net ([67.234.81.178] helo=ix.netcom.com) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1CowQ7-0004Zv-00; Wed, 12 Jan 2005 23:17:16 -0500 Message-ID: <41E6116E.8D196FC8@ix.netcom.com> Date: Wed, 12 Jan 2005 22:13:02 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Bill Sommerfeld Subject: Re: [saag] Re: security-related mail infrastructure enhancement References: <2005111165439.847314@bbprime> <1105530394.28612.1790.camel@unknown.hamachi.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.779497 cc: Dave Crocker cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 13 Jan 2005 04:17:41 -0000 Bill and all, Such a formal trust model is very unlikely to be achieved on a global basis. This idea has been floated several times of the past several years, including some from Dave. Bill Sommerfeld wrote: > On Tue, 2005-01-11 at 19:54, Dave Crocker wrote: > > > interesting thought. in general you are suggesting a formal trust model > > for email. > > I guess I am. > > part of the problem now is that in the absence of a common model, everyone > evaluating these various proposed security mechanisms does so with reference > to their personal ad-hoc trust model, with the net result that we have no > chance of reaching consensus on whether these mechanisms actually do any > good.. > > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From hartmans@MIT.EDU Thu Jan 13 12:03:17 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0DH3F5j002207 for ; Thu, 13 Jan 2005 12:03:15 -0500 (EST) Received: from cz.mit.edu (STRATTON-FOUR-FORTY-TWO.MIT.EDU [18.187.6.187]) j0DH39ZI002187 for ; Thu, 13 Jan 2005 12:03:09 -0500 (EST) Received: by cz.mit.edu (Postfix, from userid 8042) id 4988BE0063; Thu, 13 Jan 2005 12:04:25 -0500 (EST) To: Tschofenig Hannes Subject: Re: [saag] SAML 2.0: review of ietf technologies References: <2A8DB02E3018D411901B009027FD3A3F05649A4C@mchp905a.mch.sbs.de> From: Sam Hartman Date: Thu, 13 Jan 2005 12:04:24 -0500 In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F05649A4C@mchp905a.mch.sbs.de> (Tschofenig Hannes's message of "Thu, 13 Jan 2005 16:33:06 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.793546 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 13 Jan 2005 17:03:18 -0000 >>>>> "Tschofenig" == Tschofenig Hannes writes: Tschofenig> hi sam, the authn-context related documents and xml Tschofenig> files are certainly important and deal with ietf Tschofenig> protocols. Tschofenig> the core, profile and binding specs are the important Tschofenig> onces. to me it seems that the saml work is of Tschofenig> interest also for ietf protocols. therefore a review Tschofenig> and a better understanding of how they fit into the Tschofenig> ietf picture is certainly helpful. We're in agreement on all points. From pbaker@verisign.com Thu Jan 13 14:53:34 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0DJrX5j003167 for ; Thu, 13 Jan 2005 14:53:33 -0500 (EST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) j0DJrVLi010376 for ; Thu, 13 Jan 2005 14:53:31 -0500 (EST) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id j0DJrHwB017228; Thu, 13 Jan 2005 11:53:17 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 13 Jan 2005 11:53:17 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Jeff Williams'" , Bill Sommerfeld Subject: RE: [saag] Re: security-related mail infrastructure enhancement Date: Thu, 13 Jan 2005 11:53:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.558793 cc: Dave Crocker cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 13 Jan 2005 19:53:35 -0000 > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of Jeff Williams > Bill and all, > > Such a formal trust model is very unlikely to be achieved on > a global basis. This idea has been floated several times of > the past several years, including some from Dave. The idea of the Web was proposed decades before Tim by Ted Nelson. The ideas are the easy part, making them happen is what is hard. Most people don't know the first thing about how to make change happen. The fact that such people fail to make their ideas reality does not mean that they are impossible, or even that they are particularly difficult. All we can conclude is that they are impossible for them. The world has many global trust systems. They are complex and evolve over many years and cost money to maintain. I suspect that what a lot of people mean when they say that building such a system is impossible that what they really mean is that it is impossible to build one that is entirely 'free'. From jwkckid1@ix.netcom.com Thu Jan 13 23:22:44 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0E4Mg5j006042 for ; Thu, 13 Jan 2005 23:22:42 -0500 (EST) Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60])j0E4MekQ003393 for ; Thu, 13 Jan 2005 23:22:40 -0500 (EST) Received: from 1cust154.tnt36.dfw9.da.uu.net ([67.234.81.154] helo=ix.netcom.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1CpIyV-0005F1-00; Thu, 13 Jan 2005 23:22:15 -0500 Message-ID: <41E76417.97B0F22D@ix.netcom.com> Date: Thu, 13 Jan 2005 22:18:04 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: "Hallam-Baker, Phillip" Subject: Re: [saag] Re: security-related mail infrastructure enhancement References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.237409 cc: Dave Crocker cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 14 Jan 2005 04:22:45 -0000 Phillip and all, Thank you for making my point better than I did. Indeed, making a idea a reality is much more difficult than developing the idea itself... Hence why I said that a global formal trust model is unlikely. I would add, that declaring such a model exists would also not be trusted in today's world. Maybe in the distant future... Hallam-Baker, Phillip wrote: > > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of Jeff > Williams > > > Bill and all, > > > > Such a formal trust model is very unlikely to be achieved on > > a global basis. This idea has been floated several times of > > the past several years, including some from Dave. > > The idea of the Web was proposed decades before Tim by Ted Nelson. > > The ideas are the easy part, making them happen is what is hard. Most people > don't know the first thing about how to make change happen. The fact that > such people fail to make their ideas reality does not mean that they are > impossible, or even that they are particularly difficult. All we can > conclude is that they are impossible for them. > > The world has many global trust systems. They are complex and evolve over > many years and cost money to maintain. > > I suspect that what a lot of people mean when they say that building such a > system is impossible that what they really mean is that it is impossible to > build one that is entirely 'free'. -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From djb-dsn-1105685916.57336@cr.yp.to Fri Jan 14 01:58:15 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0E6wE5j006968 for ; Fri, 14 Jan 2005 01:58:14 -0500 (EST) Received: from stoneport.math.uic.edu (stoneport.math.uic.edu [131.193.178.160])j0E6wC3J006149 for ; Fri, 14 Jan 2005 01:58:12 -0500 (EST) Received: (qmail 57337 invoked by uid 1016); 14 Jan 2005 06:58:36 -0000 Date: 14 Jan 2005 06:58:36 -0000 Message-ID: <20050114065836.57336.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: saag@mit.edu, cfrg@ietf.org References: <151A63B4E33B4F49896AC6D1BA788A6E15C57F@EXCHVS2.louisville.stortek.com> <20040926155422.1F55F1AE84@berkshire.research.att.com> <20040926195031.59299.qmail@cr.yp.to> <20041102205520.89918.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.874130 Subject: [saag] Re: [Cfrg] Re: universal MACs X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 14 Jan 2005 06:58:16 -0000 I wrote, a couple of months ago: > I've just posted http://cr.yp.to/papers.html#poly1305, introducing and > analyzing Poly1305-AES, a 128-bit MAC. As a followup: The Poly1305-AES paper will appear in the Fast Software Encryption 2005 proceedings. Today I've posted http://cr.yp.to/mac.html with C API details, a reference implementation, and some tests. The main piece missing from the web page at this point is my optimized implementation; stay tuned. In the meantime, I'll be happy to answer any questions that people have about security, the API, protocol use, etc. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From onq@indigo.ie Mon Jan 17 06:56:49 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0HBug5j029656 for ; Mon, 17 Jan 2005 06:56:47 -0500 (EST) Received: from mail02.svc.cra.dublin.eircom.net (mail02.svc.cra.dublin.eircom.net [159.134.118.18])j0HBudZw014179 for ; Mon, 17 Jan 2005 06:56:40 -0500 (EST) Received: (qmail 281 messnum 1885705 invoked from network[83.70.242.68/83-70-242-68.b-ras1.prp.dublin.eircom.net]); 17 Jan 2005 11:56:38 -0000 Received: from 83-70-242-68.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.242.68) by mail02.svc.cra.dublin.eircom.net (qp 281) with SMTP; 17 Jan 2005 11:56:38 -0000 Message-ID: <41EBA767.5060801@indigo.ie> Date: Mon, 17 Jan 2005 11:54:15 +0000 From: "Michael O'Neill" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hallam-Baker, Phillip" Subject: Re: [saag] Re: security-related mail infrastructure enhancement References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050907080608020700080001" X-Spam-Score: -4.681 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.034460 cc: Dave Crocker cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 17 Jan 2005 11:56:50 -0000 This is a multi-part message in MIME format. --------------050907080608020700080001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: > > >>From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of Jeff >> >> >Williams > > > >>Bill and all, >> >> Such a formal trust model is very unlikely to be achieved on >>a global basis. This idea has been floated several times of >>the past several years, including some from Dave. >> >> > >The idea of the Web was proposed decades before Tim by Ted Nelson. > >The ideas are the easy part, making them happen is what is hard. Most people >don't know the first thing about how to make change happen. The fact that >such people fail to make their ideas reality does not mean that they are >impossible, or even that they are particularly difficult. All we can >conclude is that they are impossible for them. > >The world has many global trust systems. They are complex and evolve over >many years and cost money to maintain. > >I suspect that what a lot of people mean when they say that building such a >system is impossible that what they really mean is that it is impossible to >build one that is entirely 'free'. >_______________________________________________ >saag mailing list >saag@mit.edu >https://jis.mit.edu/mailman/listinfo/saag > > > > Hi all, Apologies if this goes to the wrong people, its my first time posting IIRC. Just a small contribution from a relative layman who has enjoyed reading the work of others posting to the mailing list over the years. I hope this link can be reviewed in the spirit of support and encouragement in which it is offered.; - http://www.crypto.com/papers/safelocks.pdf Unlike other contributions to this mailing list, it offers no concrete advice and no advice of my own, but rather points to the development of a fault tolerant security regime, focussing on delaying what is assumed to be the inevitable. In this regard I am indebted to reading Bruce Schneier, whose employee I am not, nor am I his relation, colleague or friend. For those unfamiliar with his work, the following links refer. schneier@counterpane.com Not all may agree with Schneier's point of view, many may disagree, but when I need a reality check on some design security matter I read an article or two by him. As a security man he discusses the trade off between usability/ convenience and the level of security actually needed, as opposed to the stated level or level required for peace of mind and some lowering of risk. As an architect I deal with the trade off between building access and convenience and, with more difficulty, Design for Routes for Escape of Occupants from Fire versus Perimeter Security and Safety in High Buildings. Keep up the excellent work and thanks for the food for thought. Regards, Michael O'Neill --------------050907080608020700080001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: 
  
From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of Jeff
    
Williams

  
Bill and all,

 Such a formal trust model is very unlikely to be achieved on 
a global basis.  This idea has been floated several times of 
the past several years, including some from Dave.
    

The idea of the Web was proposed decades before Tim by Ted Nelson.

The ideas are the easy part, making them happen is what is hard. Most people
don't know the first thing about how to make change happen. The fact that
such people fail to make their ideas reality does not mean that they are
impossible, or even that they are particularly difficult. All we can
conclude is that they are impossible for them.

The world has many global trust systems. They are complex and evolve over
many years and cost money to maintain.

I suspect that what a lot of people mean when they say that building such a
system is impossible that what they really mean is that it is impossible to
build one that is entirely 'free'.
_______________________________________________
saag mailing list
saag@mit.edu
https://jis.mit.edu/mailman/listinfo/saag
Hi all,

Apologies if this goes to the wrong people, its my first time posting IIRC.

Just a small contribution from a relative layman who has enjoyed reading the work of others posting to the mailing list over the years.

I hope this link can be reviewed in the spirit of support and encouragement in which it is offered.; -

http://www.crypto.com/papers/safelocks.pdf

Unlike other contributions to this mailing list, it offers no concrete advice and no advice of my own, but rather points to the development of a fault tolerant security regime, focussing on delaying what is assumed to be the inevitable.

In this regard I am indebted to reading Bruce Schneier, whose employee I am not, nor am I his relation, colleague or friend.

For those unfamiliar with his work, the following links refer.

           schneier@counterpane.com
           <http://www.schneier.com>
          <http://www.counterpane.com>

Not all may agree with Schneier's point of view, many may disagree, but when I need a reality check on some design security matter I read an article or two by him.

As a security man he discusses the trade off  between usability/ convenience and the level of security actually needed, as opposed to the stated level or level required for peace of mind and some lowering of risk.

As an architect I deal with the trade off between building access and convenience and, with more difficulty, Design for Routes for Escape of Occupants from Fire versus Perimeter Security and Safety in High Buildings.

Keep up the excellent work and thanks for the food for thought.

Regards,

Michael O'Neill
--------------050907080608020700080001-- From Jeff.Hodges@KingsMountain.com Tue Jan 18 16:14:23 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0ILEM5j010659 for ; Tue, 18 Jan 2005 16:14:22 -0500 (EST) Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.67.16.123]) j0ILEDpq013452 for ; Tue, 18 Jan 2005 16:14:13 -0500 (EST) Received: from networking.Stanford.EDU (networking.Stanford.EDU [171.64.20.23]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j0ILECn5007684 for ; Tue, 18 Jan 2005 13:14:12 -0800 Received: from networking.Stanford.EDU (hodges@localhost) by networking.Stanford.EDU (8.11.7/8.11.6) with ESMTP id j0ILEBf17528 for ; Tue, 18 Jan 2005 13:14:11 -0800 (PST) Message-Id: <200501182114.j0ILEBf17528@networking.Stanford.EDU> X-Authentication-Warning: networking.Stanford.EDU: hodges owned process doing -bs X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Subject: Re: [saag] SAML 2.0: review of ietf technologies To: saag@mit.edu In-reply-to: Sam Hartman 's message of Wed, 12 Jan 2005 07:21:48 -0500 From: Jeff.Hodges@KingsMountain.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Jan 2005 13:14:11 -0800 X-Spam-Score: -3.074 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.053460 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: Jeff.Hodges@KingsMountain.com List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 18 Jan 2005 21:14:25 -0000 Thanks for taking a look at the SAMLv2 spec set. Nicolas did indeed get some comments in before the deadline. that thread is here.. http://lists.oasis-open.org/archives/security-services/200501/msg00067.html Some comments on Sam's msg of Wed, 12 Jan 2005 07:21:48 -0500, somewhat reordered.. > It turns out though that most of the references to IETF specifications > come from the sstc-saml-2.0-authn-context specification. This > specification provides assertions of what method is used to > authenticate the subject of an assertion. > > So, for example, when looking at the PGP class you'd want to make sure > they could properly identify all PGP keys, but there will not be uses > of PGP protocol messages you have to validate. > ... > As I begin to understand how this all fits together, I'm less > concerned than I was when I wrote the message last night. Any > problems that are discovered in the authn-context document seem like > they will show up as an inability to express some authentication or > confusing spec language than as a security compromise because of a bug > in how our technology is used. correct. > Another thing I was potentially > worried about--use of our technology in ways that might make it hard > for us to extend--seems to be a non-issue. good. Something to point out here, wrt your use of the phrase "..our technology.." above, is that these days, several "new-ish" orgs have emerged onto the Internet protocol specification scene (in addition to W3C) -- OASIS[1], Liberty Alliance [2], WS-I [3], and OMA [4] being key examples (that I'm aware of). All of those above orgs have created specs with dependencies on IETF specs - some more than others. And, in many cases, there've been folks involved who are in involved to some (variable) extent in two or more of said orgs. So, to a fair extent these days, "them is us / us is them". A canonical example being the IETF/W3C xmldsig effort, of course. But in any case, there are and will be (increasing) inter-organizational spec dependencies and we all need to be aware of this, more or less, and do what we can to smooth out any rough edges we discover/cause/anticipate. In terms of security specs from external-to-IETF orgs that folks here may be innarested in perusing (in addition to SAML), and providing feedback on if necessary/appropriate, are... OASIS Web Services Security http://www.oasis-open.org/committees/wss/ especially.. Web Services Security: SOAP Message Security V1.0 (work on a v1.1 underway) http://docs.oasis-open.org/wss/2004/01 /oasis-200401-wss-soap-message-security-1.0.pdf Liberty Alliance Project http://www.projectliberty.org/specs/ especially.. Liberty ID-WSF Authentication Service Specification (SASL-based) https://www.projectliberty.org/specs/liberty-idwsf-authn-svc-v1.0.pdf WS-I Basic Security Profile http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicsecurity especially.. Basic Security Profile Working Group Draft http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html Basic Security Profile Security Scenarios http://www.ws-i.org/Profiles/BasicSecurity /SecurityScenarios-1.0-20040614.pdf Open Mobile Alliance (OMA) http://www.openmobilealliance.org/release_program/ [several/many specs on that page likely ref IETF work] Oh, just to keep life innaresting, there's of course the IETF sip-saml I-D in the IETF that has dependencies on the SAML specs. > I'm not an OASIS member so I don't know what their process is, but it > looks like ballots are issued shortly after the review period ends. OASIS Policies and Bylaws http://www.oasis-open.org/who/policies_procedures.php hope this helps, JeffH http://www.stanford.edu/~hodges/ [1] OASIS http://www.oasis-open.org/ [2] Liberty Alliance Project http://www.projectliberty.org/ [3] Web Services Interoperability http://www.ws-i.org/ [4] Open Mobile Alliance (OMA) http://www.openmobilealliance.org/ --- end From hartmans@MIT.EDU Tue Jan 18 17:14:56 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0IMEs5j011019 for ; Tue, 18 Jan 2005 17:14:54 -0500 (EST) Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) j0IMElTD015265 for ; Tue, 18 Jan 2005 17:14:47 -0500 (EST) Received: by cz.mit.edu (Postfix, from userid 8042) id D2B12E0063; Tue, 18 Jan 2005 17:14:45 -0500 (EST) To: Jeff.Hodges@KingsMountain.com Subject: Re: [saag] SAML 2.0: review of ietf technologies References: <200501182114.j0ILEBf17528@networking.Stanford.EDU> From: Sam Hartman Date: Tue, 18 Jan 2005 17:14:45 -0500 In-Reply-To: <200501182114.j0ILEBf17528@networking.Stanford.EDU> (Jeff Hodges's message of "Tue, 18 Jan 2005 13:14:11 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000001 Spam-Alum-Time: 1.321869 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 18 Jan 2005 22:14:57 -0000 I expect more dependencies within the IETF on SAML and other technologies. I did read a good chunk of the SAML specs, but didn't find anything that needed comments this late in the process. The specs were clearly written. --Sam From cchander@ida.org Tue Jan 18 19:12:43 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0J0Cf5j011666 for ; Tue, 18 Jan 2005 19:12:41 -0500 (EST) Received: from exim2-out.ida.org (exim2-out.ida.org [129.246.101.14]) j0J0CcQN024014 for ; Tue, 18 Jan 2005 19:12:38 -0500 (EST) Received: by exim2-out.ida.org with local-smtp for ; Tue, 18 Jan 2005 19:12:30 -0500 Received: by exim2-out.ida.org with esmtp ; Tue, 18 Jan 2005 19:12:30 -0500 Received: from exch2k2.ida.org ([129.246.101.116]) by ex2kmail.ida.org with Microsoft SMTPSVC(5.0.2195.5329); Tue, 18 Jan 2005 19:12:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [saag] SAML 2.0: review of ietf technologies Date: Tue, 18 Jan 2005 19:12:29 -0500 Message-ID: <2E1083C796A3E04BA25BB38ED5EF4E74C1AB23@exch2k2.ida.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] SAML 2.0: review of ietf technologies Thread-Index: AcT9ouADmrrIWk5CTFuFv7svd2k5ygAGD41Q From: "Chandersekaran, Coimbatore" To: , X-OriginalArrivalTime: 19 Jan 2005 00:12:29.0860 (UTC) FILETIME=[90858E40:01C4FDBB] X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.706965 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id j0J0Cf5j011666 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 19 Jan 2005 00:12:45 -0000 After reviewing SAML V2.0 I came to the conclusion that SAML does not solve any new problems that are not solved by PKI and Attribute certificates for which we have a well defined structure already. There are various corresponding details that SAML still does not address. If I am missing anything here perhaps I can be educated. Sekar Chandersekaran AF-CIO/P 703-845-4399 -----Original Message----- From: Jeff.Hodges@KingsMountain.com [mailto:Jeff.Hodges@KingsMountain.com] Sent: Tuesday, January 18, 2005 4:14 PM To: saag@mit.edu Subject: Re: [saag] SAML 2.0: review of ietf technologies Thanks for taking a look at the SAMLv2 spec set. Nicolas did indeed get some comments in before the deadline. that thread is here.. http://lists.oasis-open.org/archives/security-services/200501/msg00067.h tml Some comments on Sam's msg of Wed, 12 Jan 2005 07:21:48 -0500, somewhat reordered.. > It turns out though that most of the references to IETF specifications > come from the sstc-saml-2.0-authn-context specification. This > specification provides assertions of what method is used to > authenticate the subject of an assertion. > > So, for example, when looking at the PGP class you'd want to make sure > they could properly identify all PGP keys, but there will not be uses > of PGP protocol messages you have to validate. > ... > As I begin to understand how this all fits together, I'm less > concerned than I was when I wrote the message last night. Any > problems that are discovered in the authn-context document seem like > they will show up as an inability to express some authentication or > confusing spec language than as a security compromise because of a bug > in how our technology is used. correct. > Another thing I was potentially > worried about--use of our technology in ways that might make it hard > for us to extend--seems to be a non-issue. good. Something to point out here, wrt your use of the phrase "..our technology.." above, is that these days, several "new-ish" orgs have emerged onto the Internet protocol specification scene (in addition to W3C) -- OASIS[1], Liberty Alliance [2], WS-I [3], and OMA [4] being key examples (that I'm aware of). All of those above orgs have created specs with dependencies on IETF specs - some more than others. And, in many cases, there've been folks involved who are in involved to some (variable) extent in two or more of said orgs. So, to a fair extent these days, "them is us / us is them". A canonical example being the IETF/W3C xmldsig effort, of course. But in any case, there are and will be (increasing) inter-organizational spec dependencies and we all need to be aware of this, more or less, and do what we can to smooth out any rough edges we discover/cause/anticipate. In terms of security specs from external-to-IETF orgs that folks here may be innarested in perusing (in addition to SAML), and providing feedback on if necessary/appropriate, are... OASIS Web Services Security http://www.oasis-open.org/committees/wss/ especially.. Web Services Security: SOAP Message Security V1.0 (work on a v1.1 underway) http://docs.oasis-open.org/wss/2004/01 /oasis-200401-wss-soap-message-security-1.0.pdf Liberty Alliance Project http://www.projectliberty.org/specs/ especially.. Liberty ID-WSF Authentication Service Specification (SASL-based) https://www.projectliberty.org/specs/liberty-idwsf-authn-svc-v1.0.pdf WS-I Basic Security Profile http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicsecurity especially.. Basic Security Profile Working Group Draft http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html Basic Security Profile Security Scenarios http://www.ws-i.org/Profiles/BasicSecurity /SecurityScenarios-1.0-20040614.pdf Open Mobile Alliance (OMA) http://www.openmobilealliance.org/release_program/ [several/many specs on that page likely ref IETF work] Oh, just to keep life innaresting, there's of course the IETF sip-saml I-D in the IETF that has dependencies on the SAML specs. > I'm not an OASIS member so I don't know what their process is, but it > looks like ballots are issued shortly after the review period ends. OASIS Policies and Bylaws http://www.oasis-open.org/who/policies_procedures.php hope this helps, JeffH http://www.stanford.edu/~hodges/ [1] OASIS http://www.oasis-open.org/ [2] Liberty Alliance Project http://www.projectliberty.org/ [3] Web Services Interoperability http://www.ws-i.org/ [4] Open Mobile Alliance (OMA) http://www.openmobilealliance.org/ --- end _______________________________________________ saag mailing list saag@mit.edu https://jis.mit.edu/mailman/listinfo/saag From pbaker@verisign.com Wed Jan 19 01:42:15 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0J6gD5j013602 for ; Wed, 19 Jan 2005 01:42:13 -0500 (EST) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) j0J6g9DU029931 for ; Wed, 19 Jan 2005 01:42:09 -0500 (EST) Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54])j0J6g5T0003875; Tue, 18 Jan 2005 22:42:05 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Jan 2005 22:42:05 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Chandersekaran, Coimbatore'" , Jeff.Hodges@KingsMountain.com, saag@mit.edu Subject: RE: [saag] SAML 2.0: review of ietf technologies Date: Tue, 18 Jan 2005 22:42:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.972888 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 19 Jan 2005 06:42:16 -0000 I don't believe that there is any analogue in PKIX to the SAML authentication statement, so I disagree with the claim. It is however possible to encode every PKIX data structure using just the SAML assertion format. This is hardly surprising since one of the starting points for SAML was XTASS which began in 2000 when I was given a design brief to design an XML based PKI that encoded certificates, attribute certificates, CRLs, OCSP &ct in a single structure with a single unified processing model. I believe that there are important details that are addressed in SAML that are not addressed in PKIX. I do not believe that it makes much sense to transport semantic web assertions in the form of X.509 Attribute certs. It does make a lot of sense to use SAML as a packaging format. Phill > -----Original Message----- > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On > Behalf Of Chandersekaran, Coimbatore > Sent: Tuesday, January 18, 2005 7:12 PM > To: Jeff.Hodges@KingsMountain.com; saag@mit.edu > Subject: RE: [saag] SAML 2.0: review of ietf technologies > > > After reviewing SAML V2.0 I came to the conclusion that SAML > does not solve any new problems that are not solved by PKI > and Attribute certificates for which we have a well defined > structure already. There are various corresponding details > that SAML still does not address. > > If I am missing anything here perhaps I can be educated. > > Sekar Chandersekaran > AF-CIO/P > 703-845-4399 > > -----Original Message----- > From: Jeff.Hodges@KingsMountain.com > [mailto:Jeff.Hodges@KingsMountain.com] > Sent: Tuesday, January 18, 2005 4:14 PM > To: saag@mit.edu > Subject: Re: [saag] SAML 2.0: review of ietf technologies > > Thanks for taking a look at the SAMLv2 spec set. Nicolas did > indeed get some > comments in before the deadline. that thread is here.. > > http://lists.oasis-open.org/archives/security-services/200501/ > msg00067.h > tml > > Some comments on Sam's msg of Wed, 12 Jan 2005 07:21:48 > -0500, somewhat > reordered.. > > > It turns out though that most of the references to IETF > specifications > > come from the sstc-saml-2.0-authn-context specification. This > > specification provides assertions of what method is used to > > authenticate the subject of an assertion. > > > > So, for example, when looking at the PGP class you'd want > to make sure > > they could properly identify all PGP keys, but there will > not be uses > > of PGP protocol messages you have to validate. ... > > As I begin to understand how this all fits together, I'm less > > concerned than I was when I wrote the message last night. Any > > problems that are discovered in the authn-context document seem like > > they will show up as an inability to express some authentication or > > confusing spec language than as a security compromise > because of a bug > > in how our technology is used. > > > correct. > > > > Another thing I was potentially > > worried about--use of our technology in ways that might > make it hard > > for us to extend--seems to be a non-issue. > > > good. > > > Something to point out here, wrt your use of the phrase > "..our technology.." > above, is that these days, several "new-ish" orgs have > emerged onto the > Internet protocol specification scene (in addition to W3C) -- > OASIS[1], > > Liberty Alliance [2], WS-I [3], and OMA [4] being key > examples (that I'm aware > of). > > All of those above orgs have created specs with dependencies > on IETF specs - > some more than others. And, in many cases, there've been > folks involved who > are in involved to some (variable) extent in two or more of said orgs. > > So, to a fair extent these days, "them is us / us is them". A > canonical > example being the IETF/W3C xmldsig effort, of course. But in > any case, there > are and will be (increasing) inter-organizational spec > dependencies and we all > need to be aware of this, more or less, and do what we can to > smooth out any > rough edges we discover/cause/anticipate. > > In terms of security specs from external-to-IETF orgs that > folks here may be > innarested in perusing (in addition to SAML), and providing > feedback on if > necessary/appropriate, are... > > > OASIS Web Services Security > http://www.oasis-open.org/committees/wss/ > > especially.. > > Web Services Security: SOAP Message Security V1.0 (work on a v1.1 > underway) > http://docs.oasis-open.org/wss/2004/01 > /oasis-200401-wss-soap-message-security-1.0.pdf > > > > Liberty Alliance Project > http://www.projectliberty.org/specs/ > > especially.. > > Liberty ID-WSF Authentication Service Specification (SASL-based) > > https://www.projectliberty.org/specs/liberty-idwsf-authn-svc-v1.0.pdf > > > > WS-I Basic Security Profile > http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicsecurity > > especially.. > > Basic Security Profile Working Group Draft > http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html > > Basic Security Profile Security Scenarios > http://www.ws-i.org/Profiles/BasicSecurity > /SecurityScenarios-1.0-20040614.pdf > > > > Open Mobile Alliance (OMA) > http://www.openmobilealliance.org/release_program/ > [several/many specs on that page likely ref IETF work] > > > Oh, just to keep life innaresting, there's of course the IETF > sip-saml I-D in > the IETF that has dependencies on the SAML specs. > > > > > I'm not an OASIS member so I don't know what their process > is, but it > > looks like ballots are issued shortly after the review period ends. > > OASIS Policies and Bylaws > http://www.oasis-> open.org/who/policies_procedures.php > > > hope > this helps, > > > JeffH > http://www.stanford.edu/~hodges/ > > > [1] OASIS > http://www.oasis-open.org/ > > [2] Liberty Alliance Project > http://www.projectliberty.org/ > > [3] Web Services Interoperability > http://www.ws-i.org/ > > [4] Open Mobile Alliance (OMA) http://www.openmobilealliance.org/ > > > --- > end > > > > > > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag > > > > > > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag > From nw141292@binky.central.sun.com Wed Jan 19 11:46:56 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0JGkt5j016086 for ; Wed, 19 Jan 2005 11:46:55 -0500 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) j0JGklGd015295 for ; Wed, 19 Jan 2005 11:46:48 -0500 (EST) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0JGkldt018430 for ; Wed, 19 Jan 2005 09:46:47 -0700 (MST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) with ESMTP id j0JGkkwk017203 for ; Wed, 19 Jan 2005 09:46:47 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) j0JGjUw2356173; Wed, 19 Jan 2005 10:45:30 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id j0JGjSoC356172; Wed, 19 Jan 2005 10:45:28 -0600 (CST) Date: Wed, 19 Jan 2005 10:45:28 -0600 From: Nicolas Williams To: "Hallam-Baker, Phillip" Subject: Re: [saag] SAML 2.0: review of ietf technologies Message-ID: <20050119164528.GP352984@binky.central.sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.914580 cc: Jeff.Hodges@KingsMountain.com cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 19 Jan 2005 16:46:57 -0000 On Tue, Jan 18, 2005 at 10:42:04PM -0800, Hallam-Baker, Phillip wrote: > I don't believe that there is any analogue in PKIX to the SAML > authentication statement, so I disagree with the claim. > > It is however possible to encode every PKIX data structure using just the > SAML assertion format. This is hardly surprising since one of the starting > points for SAML was XTASS which began in 2000 when I was given a design > brief to design an XML based PKI that encoded certificates, attribute > certificates, CRLs, OCSP &ct in a single structure with a single unified > processing model. I thought so. > I believe that there are important details that are addressed in SAML that > are not addressed in PKIX. And vice versa, I'm sure. > I do not believe that it makes much sense to transport semantic web > assertions in the form of X.509 Attribute certs. It does make a lot of sense > to use SAML as a packaging format. I disagree. The extent of deployment of systems like PKIX and Kerberos V makes it worthwhile to pursue authorization extensions to those using a common assertion language, and gee, SAML fits. Nico -- From Jeff.Hodges@KingsMountain.com Wed Jan 19 12:08:24 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0JH8N5j016247 for ; Wed, 19 Jan 2005 12:08:23 -0500 (EST) Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.138]) j0JH8K6H001648 for ; Wed, 19 Jan 2005 12:08:21 -0500 (EST) Received: from networking.Stanford.EDU (networking.Stanford.EDU [171.64.20.23]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j0JH8JV0010490 for ; Wed, 19 Jan 2005 09:08:20 -0800 Received: from networking.Stanford.EDU (hodges@localhost) by networking.Stanford.EDU (8.11.7/8.11.6) with ESMTP id j0JH8Jj01712 for ; Wed, 19 Jan 2005 09:08:19 -0800 (PST) Message-Id: <200501191708.j0JH8Jj01712@networking.Stanford.EDU> X-Authentication-Warning: networking.Stanford.EDU: hodges owned process doing -bs X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Subject: Re: [saag] SAML 2.0: review of ietf technologies To: saag@mit.edu In-reply-to: Sam Hartman 's message of Tue, 18 Jan 2005 17:14:45 -0500 From: Jeff.Hodges@KingsMountain.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Jan 2005 09:08:19 -0800 X-Spam-Score: -3.074 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.523850 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: Jeff.Hodges@KingsMountain.com List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 19 Jan 2005 17:08:25 -0000 hartmans-ietf@mit.edu said: > I expect more dependencies within the IETF on SAML and other > technologies. good to know. > I did read a good chunk of the SAML specs, but didn't find anything > that needed comments this late in the process. The specs were clearly > written. Thanks for taking the time to go over them. JeffH From jwkckid1@ix.netcom.com Wed Jan 19 22:53:32 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0K3rU5j019710 for ; Wed, 19 Jan 2005 22:53:30 -0500 (EST) Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157])j0K3rSYc018327 for ; Wed, 19 Jan 2005 22:53:28 -0500 (EST) Received: from 1cust120.tnt36.dfw9.da.uu.net ([67.234.81.120] helo=ix.netcom.com) by tisch.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1CrTNu-0003FO-00; Wed, 19 Jan 2005 22:53:26 -0500 Message-ID: <41EF4650.EA3807F0@ix.netcom.com> Date: Wed, 19 Jan 2005 21:49:04 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: aba isc list Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.129567 cc: james tierney cc: Linda Risinger cc: saag Subject: [saag] DHS and Justice Dept. Plan Annual Computer Security Survey X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 20 Jan 2005 03:53:33 -0000 All, I am glad that some of the recommendations we had made are finally getting addressed, all be it if a weak form. It would have been better for DOJ and DHS to have made this a security audit, rather than just a survey. But better only a survey than nothing... [ See story below ] (13 January 2005) Homeland Security and Justice Department officials plan to conduct an annual Computer Security Survey to assess the type and frequency of cyber security incidents. The departments plan to survey 36,000 companies across the country this spring. The data collected could help in the development of policy and resource allocation both for the government and for the private sector. The survey is being reviewed by a number of groups, including the FBI and the President's Information Technology Advisory Committee, before it is used. http://www.fcw.com/fcw/articles/2005/0110/web-survey-01-13-05.asp Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From hartmans@MIT.EDU Thu Jan 20 12:48:36 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0KHmY5j023447 for ; Thu, 20 Jan 2005 12:48:35 -0500 (EST) Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) j0KHmX7R025265 for ; Thu, 20 Jan 2005 12:48:33 -0500 (EST) Received: by cz.mit.edu (Postfix, from userid 8042) id 63108E0063; Thu, 20 Jan 2005 12:48:36 -0500 (EST) To: "Chandersekaran, Coimbatore" Subject: Re: [saag] SAML 2.0: review of ietf technologies References: <2E1083C796A3E04BA25BB38ED5EF4E74C1AB23@exch2k2.ida.org> From: Sam Hartman Date: Thu, 20 Jan 2005 12:48:36 -0500 In-Reply-To: <2E1083C796A3E04BA25BB38ED5EF4E74C1AB23@exch2k2.ida.org> (Coimbatore Chandersekaran's message of "Tue, 18 Jan 2005 19:12:29 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.207658 cc: Jeff.Hodges@KingsMountain.com cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 20 Jan 2005 17:48:38 -0000 >>>>> "Chandersekaran," == Chandersekaran, Coimbatore writes: Chandersekaran,> After reviewing SAML V2.0 I came to the Chandersekaran,> conclusion that SAML does not solve any new Chandersekaran,> problems that are not solved by PKI and Attribute Chandersekaran,> certificates for which we have a well defined Chandersekaran,> structure already. There are various Chandersekaran,> corresponding details that SAML still does not Chandersekaran,> address. PKI is only a useful solution if you have a PKI or believe you want a PKI. I do agree there is a significant overlap between SAML and attribute certificates. From pbaker@verisign.com Thu Jan 20 23:21:21 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0L4LK5j026380 for ; Thu, 20 Jan 2005 23:21:20 -0500 (EST) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) j0L4LHob016523; Thu, 20 Jan 2005 23:21:17 -0500 (EST) Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54])j0L4LBhv001466; Thu, 20 Jan 2005 20:21:11 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 20 Jan 2005 20:21:11 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Sam Hartman'" , "Chandersekaran, Coimbatore" Subject: RE: [saag] SAML 2.0: review of ietf technologies Date: Thu, 20 Jan 2005 20:21:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.017135 cc: Jeff.Hodges@KingsMountain.com cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 21 Jan 2005 04:21:23 -0000 > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On > Behalf Of Sam Hartman > > >>>>> "Chandersekaran," == Chandersekaran, Coimbatore > > >>>>> writes: > > Chandersekaran,> After reviewing SAML V2.0 I came to the > Chandersekaran,> conclusion that SAML does not solve any new > Chandersekaran,> problems that are not solved by PKI and Attribute > Chandersekaran,> certificates for which we have a well defined > Chandersekaran,> structure already. There are various > Chandersekaran,> corresponding details that SAML still does not > Chandersekaran,> address. > > PKI is only a useful solution if you have a PKI or believe > you want a PKI. There is another condition, you need a transition strategy to manage conversion from using username & password. The SAML concept is not attempting to compete with PKI, it is providing a framework that is authentication mechanism neutral. Phill From housley@vigilsec.com Sun Jan 30 14:42:15 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0UJgE5j002934 for ; Sun, 30 Jan 2005 14:42:14 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) j0UJgBS2000585 for ; Sun, 30 Jan 2005 14:42:11 -0500 (EST) Received: (qmail 13956 invoked by uid 0); 30 Jan 2005 19:42:05 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.93.113) by woodstock.binhost.com with SMTP; 30 Jan 2005 19:42:05 -0000 Message-Id: <6.2.0.14.2.20050130144035.067626a0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sun, 30 Jan 2005 14:42:07 -0500 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -4.585 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.726931 Subject: [saag] Mobil SpeedPass and anti-theft immobilizers spoofed X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 30 Jan 2005 19:42:17 -0000 Does anyone have more details? = = = = = = = = Auto, Gas Security Chips Vulnerable, Study Finds Sat Jan 29, 2005 08:00 PM ET WASHINGTON (Reuters) - Tiny radio-transmitter chips that make possible high-security car keys and swipe-by gasoline passes can be cracked using cheap technology, U.S. computer experts said on Saturday. The radio-frequency ID, or RFID, system uses a relatively simple code that criminals can easily decipher, making it easier to steal a car or get a free tankful of gasoline, the team at Johns Hopkins University in Baltimore and RSA Laboratories said. "We've found that the security measures built into these devices are inadequate," said Avi Rubin, technical director of the Johns Hopkins Information Security Institute. "Millions of tags that are currently in use by consumers have an encryption function that can be cracked without requiring direct contact. An attacker who cracks the secret key in an RFID tag can then bypass security measures and fool tag readers in cars or at gas stations," Rubin said in a statement. Made by Texas Instruments (TXN.N: Quote, Profile, Research) , the RFID system studied for the report uses a device that prevents a car from starting unless both the right key and the correctly coded RFID chip are used. "The devices have been credited with significant reductions in auto theft rates, as much as 90 percent," the researchers wrote. They cited Texas Instruments, which had been told about the problem, as saying the company had received no reports of thefts due to the vulnerability. The fuel-purchase system uses a reader inside the gas pump that recognizes a key-chain tag waved nearby and automatically charges a designated credit card. More than 150 million of the Texas Instruments transponders are embedded in keys for newer vehicles built by at least three leading makers, and in more than 6 million key-chain gas tags, the researchers said. The problem is that the mathematical key used to code the verification system is too short, they said. They bought a commercial microchip costing less than $200 and programmed it to find the key for a gasoline-purchase tag. They linked 16 such chips together and cracked the key in about 15 minutes. The researchers said a metal sheath could help prevent the problem. Texas Instruments representatives were unavailable for comment. The RFID system they used is called a Digital Signature Transponder, and is distinct from the Electronic Product Code used by retailers and pharmacies for inventory control. RSA Laboratories, based in Bedford, Massachusetts, is a division of RSA Security (RSAS.O: Quote, Profile, Research). From smb@cs.columbia.edu Sun Jan 30 15:01:18 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0UK1G5j003086 for ; Sun, 30 Jan 2005 15:01:16 -0500 (EST) Received: from machshav.com (machshav.com [147.28.0.16]) j0UK1AXc011030 for ; Sun, 30 Jan 2005 15:01:10 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 84CB8FB27C; Sun, 30 Jan 2005 20:01:07 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1C51AFB246; Sun, 30 Jan 2005 20:01:07 +0000 (UTC) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 082FE3BFECD; Sun, 30 Jan 2005 15:01:06 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Russ Housley Subject: Re: [saag] Mobil SpeedPass and anti-theft immobilizers spoofed In-Reply-To: Your message of "Sun, 30 Jan 2005 14:42:07 EST." <6.2.0.14.2.20050130144035.067626a0@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 30 Jan 2005 15:01:05 -0500 Sender: smb@cs.columbia.edu Message-Id: <20050130200106.082FE3BFECD@berkshire.machshav.com> X-Spam-Score: -3.234 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000001 Spam-Alum-Time: 0.630919 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 30 Jan 2005 20:01:19 -0000 In message <6.2.0.14.2.20050130144035.067626a0@mail.binhost.com>, Russ Housley writes: >Does anyone have more details? > The researchers' web page is at http://www.rfidanalysis.org; it has a link to the draft paper. Note that the paper deliberately omits some details of the cryptanalysis. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb From pbaker@verisign.com Mon Jan 31 11:20:26 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0VGKO5j008635 for ; Mon, 31 Jan 2005 11:20:24 -0500 (EST) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) j0VGKLtC022685 for ; Mon, 31 Jan 2005 11:20:22 -0500 (EST) Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53])j0VGKLLZ016341; Mon, 31 Jan 2005 08:20:21 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 31 Jan 2005 08:20:21 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Russ Housley'" , saag@mit.edu Subject: RE: [saag] Mobil SpeedPass and anti-theft immobilizers spoofed Date: Mon, 31 Jan 2005 08:20:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: -4.585 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.381520 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 31 Jan 2005 16:20:27 -0000 I read in slashdot that they have a 40 bit key and a challenge/response scheme. Given the vintage of the system and the choice of 40 bits I would strongly suspect that this is not a result of incompetent design, it is simply a left over legacy from the Louis Freeh crypto wars. If someone was going to choose a key size at random they would have choosen a round number lile 32 or 64 bits or the DES key size. I would not have serious worries about the practical security of the system if they had choosen 56 bits. Not a choice I would choose but acceptable. Incidentally, folk are calling this RFID, my understanding is that the RFID tags sold as such have no security at all. This is an RF authentication token. That is all water under the bridge. Understanding how we got here is all very well. I am more interested in how we can move on. Since this is SAAG it is worthwhile pointing out that there is a proposal in IETF already t5hat would provide a basis to move on. There is a real problem upgrading from an insecure system to a secure one. All the legacy pumps would need to be upgraded to the new spec. The only practical way to manage that is to move to a new industry-wide standard with at least 128 bit security that we can be confident of (I accept that we could probably get by with less but we would never agree on any less). The OATH authentication scheme could probably be used as a drop in replacement. The gas pump authentication scheme is going to require a call back for credit authentication and so the counter auth mode works well. I would probably do the car door lock scheme using local shared keys, challenge response and no counter. http://www.ietf.org/internet-drafts/draft-mraihi-oath-hmac-otp-01.txt > -----Original Message----- > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On > Behalf Of Russ Housley > Sent: Sunday, January 30, 2005 2:42 PM > To: saag@mit.edu > Subject: [saag] Mobil SpeedPass and anti-theft immobilizers spoofed > > > Does anyone have more details? > > = = = = = = = = > > Auto, Gas Security Chips Vulnerable, Study Finds > Sat Jan 29, 2005 08:00 PM ET > > WASHINGTON (Reuters) - Tiny radio-transmitter chips that make > possible high-security car keys and swipe-by gasoline passes > can be cracked using cheap technology, U.S. computer experts > said on Saturday. > > The radio-frequency ID, or RFID, system uses a relatively > simple code that criminals can easily decipher, making it > easier to steal a car or get a free tankful of gasoline, the > team at Johns Hopkins University in Baltimore and RSA > Laboratories said. > > "We've found that the security measures built into these > devices are inadequate," said Avi Rubin, technical director > of the Johns Hopkins Information Security Institute. > > "Millions of tags that are currently in use by consumers have > an encryption function that can be cracked without requiring > direct contact. An attacker who cracks the secret key in an > RFID tag can then bypass security measures and fool tag > readers in cars or at gas stations," Rubin said in a statement. > > Made by Texas Instruments (TXN.N: Quote, Profile, Research) , > the RFID system studied for the report uses a device that > prevents a car from starting unless both the right key and > the correctly coded RFID chip are used. > > "The devices have been credited with significant reductions > in auto theft rates, as much as 90 percent," the researchers > wrote. They cited Texas Instruments, which had been told > about the problem, as saying the company had received no > reports of thefts due to the vulnerability. > > The fuel-purchase system uses a reader inside the gas pump > that recognizes a key-chain tag waved nearby and > automatically charges a designated credit card. > > More than 150 million of the Texas Instruments transponders > are embedded in keys for newer vehicles built by at least > three leading makers, and in more than 6 million key-chain > gas tags, the researchers said. > > The problem is that the mathematical key used to code the > verification system is too short, they said. > > They bought a commercial microchip costing less than $200 and > programmed it to find the key for a gasoline-purchase tag. > They linked 16 such chips together and cracked the key in > about 15 minutes. > > The researchers said a metal sheath could help prevent the > problem. Texas Instruments representatives were unavailable > for comment. > > The RFID system they used is called a Digital Signature > Transponder, and is distinct from the Electronic Product Code > used by retailers and pharmacies for inventory control. > > RSA Laboratories, based in Bedford, Massachusetts, is a > division of RSA > Security (RSAS.O: Quote, Profile, Research). > > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag > From aramp@qualcomm.com Mon Jan 31 11:39:35 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0VGdX5j008756 for ; Mon, 31 Jan 2005 11:39:33 -0500 (EST) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) j0VGdQid008941 for ; Mon, 31 Jan 2005 11:39:26 -0500 (EST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) j0VGdNhP006270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 31 Jan 2005 08:39:24 -0800 (PST) Received: from [129.46.159.211] (dhcp29.qualcomm.com [129.46.159.211]) j0VGdLfr010621 for ; Mon, 31 Jan 2005 08:39:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7eb90154c9e7ff47e2830f76fcde45f1@qualcomm.com> Content-Transfer-Encoding: 7bit From: Aram Perez Subject: Re: [saag] Mobil SpeedPass and anti-theft immobilizers spoofed Date: Mon, 31 Jan 2005 08:39:21 -0800 To: SAAG X-Mailer: Apple Mail (2.619.2) X-PMX-Version: 4.7.0.111621 X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.546392 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 31 Jan 2005 16:39:36 -0000 Hi Phillip, > I read in slashdot that they have a 40 bit key and a challenge/response > scheme. > > Given the vintage of the system and the choice of 40 bits I would > strongly > suspect that this is not a result of incompetent design, it is simply > a left > over legacy from the Louis Freeh crypto wars. If someone was going to > choose > a key size at random they would have choosen a round number lile 32 or > 64 > bits or the DES key size. > > I would not have serious worries about the practical security of the > system > if they had choosen 56 bits. Not a choice I would choose but > acceptable. > > Incidentally, folk are calling this RFID, my understanding is that the > RFID > tags sold as such have no security at all. This is an RF authentication > token. Even in the days of the Louis Freeh crypto wars, devices that were used for only authentication could use "strong" crypto keys. So the use of 40 bit keys by the designers of the system seems very short-sighted (pardon the pun ;-). Respectfully, Aram Perez From jhutz@cmu.edu Mon Jan 31 12:55:11 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0VHtA5j009274 for ; Mon, 31 Jan 2005 12:55:10 -0500 (EST) Received: from liandra.pc.cs.cmu.edu (JHUTZ-DYN5.PC.CS.CMU.EDU [128.2.200.141])j0VHt7tC003773 for ; Mon, 31 Jan 2005 12:55:08 -0500 (EST) Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa15951; 31 Jan 2005 12:54 EST Date: Mon, 31 Jan 2005 12:54:57 -0500 From: Jeffrey Hutzelman To: "Hallam-Baker, Phillip" , "'Russ Housley'" , saag@mit.edu Subject: RE: [saag] Mobil SpeedPass and anti-theft immobilizers spoofed Message-ID: <148940000.1107194097@liandra.pc.cs.cmu.edu> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (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: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.163651 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 31 Jan 2005 17:55:13 -0000 On Monday, January 31, 2005 08:20:20 -0800 "Hallam-Baker, Phillip" wrote: > The OATH authentication scheme could probably be used as a drop in > replacement. The gas pump authentication scheme is going to require a call > back for credit authentication and so the counter auth mode works well. I > would probably do the car door lock scheme using local shared keys, > challenge response and no counter. Bear in mind that SpeedPass tokens are _not_ involved in credit card authorization. The oil company has your credit card number and authorization-to-charge on file; the SpeedPass token just identifies a particular database record. And, it can only be used without a signature to purchase gas at the pump (you can use these tags to buy things in the attached convenience store, but they require a signature). So yes, the system is weak, but it's not like someone can incur massive credit card charges by breaking the authentication on a SpeedPass tag. > Incidentally, folk are calling this RFID, my understanding is that the > RFID tags sold as such have no security at all. This is an RF > authentication token. Correct on both counts. I tend to think of "RFID tags" as fairly passive identifiers, with no security at all. Good for inventory tracking and the like, and nice and cheap, but totally useless for authentication. Actually, I'm somewhat surprised to find out that SpeedPass tags are authentication tokens. That's considerably more effort than I would have expended given the risk. -- Jeff From pbaker@verisign.com Mon Jan 31 13:01:43 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0VI1g5j009342 for ; Mon, 31 Jan 2005 13:01:42 -0500 (EST) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) j0VI1dtC016283 for ; Mon, 31 Jan 2005 13:01:40 -0500 (EST) Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53])j0VI1d6j023441; Mon, 31 Jan 2005 10:01:39 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 31 Jan 2005 10:01:39 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Aram Perez'" , SAAG Subject: RE: [saag] Mobil SpeedPass and anti-theft immobilizers spoofed Date: Mon, 31 Jan 2005 10:01:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.006839 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 31 Jan 2005 18:01:45 -0000 > Behalf Of Aram Perez > Even in the days of the Louis Freeh crypto wars, devices that > were used > for only authentication could use "strong" crypto keys. So > the use of > 40 bit keys by the designers of the system seems very short-sighted > (pardon the pun ;-). Its water under the bridge. We can spend our time beating up the designers of a system that is 20 years old without any appreciation for the design constraints they were operating under at the time or we can work out a plan from getting from where we are to where we want to be. This is fixable. We have a proposal on the table that is close to fixing it. I would rather spend time on that than discussing why we are all so much better at crypto two decades later. From pbaker@verisign.com Mon Jan 31 13:09:12 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0VI9B5j009393 for ; Mon, 31 Jan 2005 13:09:11 -0500 (EST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) j0VI99id009071 for ; Mon, 31 Jan 2005 13:09:09 -0500 (EST) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id j0VI98KA028382; Mon, 31 Jan 2005 10:09:08 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 31 Jan 2005 10:09:08 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Jeffrey Hutzelman'" , "Hallam-Baker, Phillip" , "'Russ Housley'" , saag@mit.edu Subject: RE: [saag] Mobil SpeedPass and anti-theft immobilizers spoofed Date: Mon, 31 Jan 2005 10:09:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.892971 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 31 Jan 2005 18:09:13 -0000 > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Bear in mind that SpeedPass tokens are _not_ involved in credit card > authorization. The oil company has your credit card number and > authorization-to-charge on file; the SpeedPass token just > identifies a > particular database record. And, it can only be used without > a signature > to purchase gas at the pump (you can use these tags to buy > things in the > attached convenience store, but they require a signature). There is still an authorization step though, the speed pass needs to connect up to the speedpass payments infrastructure which in turn will process the payment. The point is that it is practical use a system that uses a separate secret per token with multiple payment terminals. > So yes, the system is weak, but it's not like someone can > incur massive > credit card charges by breaking the authentication on a SpeedPass tag. The system is probably adequate to mitigate risk to an acceptable level in the context of current day hacker capabilities. I would not be very happy if we were planning to use the same system indefinitely. The publication of the paper probably means that ther vulnerability will be exploited at some point out if nothing is done. There is time to put a fix in place. From hannes.tschofenig@siemens.com Thu Jan 13 10:33:13 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0DFXC5j001584 for ; Thu, 13 Jan 2005 10:33:12 -0500 (EST) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) j0DFX9ZI029984; Thu, 13 Jan 2005 10:33:09 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j0DFX8Yq023022; Thu, 13 Jan 2005 16:33:08 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j0DFX83r031224; Thu, 13 Jan 2005 16:33:08 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 13 Jan 2005 16:33:08 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F05649A4C@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Sam Hartman Subject: RE: [saag] SAML 2.0: review of ietf technologies MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.604961 X-Mailman-Approved-At: Mon, 31 Jan 2005 13:57:10 -0500 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Date: Thu, 13 Jan 2005 15:33:15 -0000 X-Original-Date: Thu, 13 Jan 2005 16:33:06 +0100 X-List-Received-Date: Thu, 13 Jan 2005 15:33:15 -0000 hi sam, the authn-context related documents and xml files are certainly important and deal with ietf protocols. the core, profile and binding specs are the important onces. to me it seems that the saml work is of interest also for ietf protocols. therefore a review and a better understanding of how they fit into the ietf picture is certainly helpful. ciao hannes > >>>>> "Tschofenig" == Tschofenig Hannes > writes: > > Tschofenig> hi sam, review deadline is january 14th. today is the > Tschofenig> 12th. the documents are huge. it might be difficult > Tschofenig> todo a serious review in two days. is this a hard > Tschofenig> deadline? > > I'm not an OASIS member so I don't know what their process > is, but it looks like ballots are issued shortly after the > review period ends. > > It turns out though that most of the references to IETF > specifications come from the sstc-saml-2.0-authn-context > specification. This specification provides assertions of > what method is used to authenticate the subject of an assertion. > > So, for example, when looking at the PGP class you'd want to > make sure they could properly identify all PGP keys, but > there will not be uses of PGP protocol messages you have to validate. > > I do realize that the documents are huge; I've been > alternating slogging through the core spec and the authn-context spec. > > > As I begin to understand how this all fits together, I'm less > concerned than I was when I wrote the message last night. > Any problems that are discovered in the authn-context > document seem like they will show up as an inability to > express some authentication or confusing spec language than > as a security compromise because of a bug in how our > technology is used. Another thing I was potentially worried > about--use of our technology in ways that might make it hard > for us to extend--seems to be a non-issue. > > That said, I'm sure they would appreciate any comments you > have time to discover and write. > From mleech@nortel.com Mon Jan 31 13:25:41 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j0VIPd5j009539 for ; Mon, 31 Jan 2005 13:25:39 -0500 (EST) Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56])j0VIOjtC003726 for ; Mon, 31 Jan 2005 13:24:46 -0500 (EST) Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) id j0VIOg320471; Mon, 31 Jan 2005 13:24:43 -0500 (EST) Received: from nortelnetworks.com (wcary0w4.ca.nortel.com [47.129.148.152]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W14F5CK2; Mon, 31 Jan 2005 13:24:43 -0500 Message-ID: <41FE77EA.4040609@nortelnetworks.com> Date: Mon, 31 Jan 2005 13:24:42 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Marcus Leech User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman , saag@mit.edu Subject: Re: [saag] Mobil SpeedPass and anti-theft immobilizers spoofed References: <148940000.1107194097@liandra.pc.cs.cmu.edu> In-Reply-To: <148940000.1107194097@liandra.pc.cs.cmu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000004 Spam-Alum-Time: 0.736089 X-Mailman-Approved-At: Mon, 31 Jan 2005 13:57:10 -0500 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 31 Jan 2005 18:25:42 -0000 Jeffrey Hutzelman wrote: > > So yes, the system is weak, but it's not like someone can incur > massive credit card charges by breaking the authentication on a > SpeedPass tag. > Depending, of course, on how good the fraud detection system is. I think that SpeedPass fraud would be an amusing way to fund a gasoline market arbitrage scheme-- leveraging regional differences in retail gasoline prices--or even a scheme based on stockpiling. Buy low, sell high, with the capital provided by large-scale SpeedPass fraud :-) From hartmans@MIT.EDU Mon Feb 7 10:28:31 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j17FST5j005924 for ; Mon, 7 Feb 2005 10:28:30 -0500 (EST) Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) j17FSJfi004709; Mon, 7 Feb 2005 10:28:19 -0500 (EST) Received: by luminous.mit.edu (Postfix, from userid 1000) id C4BD576D12; Mon, 7 Feb 2005 10:29:00 -0500 (EST) To: Alessandro Armando References: <200502071111.j17BBMba004740@armando.mrg.dist.unige.it> From: Sam Hartman Date: Mon, 07 Feb 2005 10:29:00 -0500 In-Reply-To: <200502071111.j17BBMba004740@armando.mrg.dist.unige.it> (Alessandro Armando's message of "Mon, 07 Feb 2005 12:11:22 +0100") Message-ID: <878y60v16r.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000854 Spam-Alum-Time: 0.637176 cc: secdir@mit.edu cc: saag@mit.edu Subject: [saag] Re: IETF Meeting Minneapolis, saag: slot for AVISPA X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 07 Feb 2005 15:28:32 -0000 In the interests of scheduling, it would be useful to know how much time you need. How much time would you like ideally? What is the minimum time for your presentation to be useful? --Sam From smb@cs.columbia.edu Mon Feb 7 20:02:57 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j1812t5j009497 for ; Mon, 7 Feb 2005 20:02:55 -0500 (EST) Received: from machshav.com (machshav.com [147.28.0.16]) j1812n52010243 for ; Mon, 7 Feb 2005 20:02:49 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id CB1C2FB266; Tue, 8 Feb 2005 01:02:48 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0698AFB246 for ; Tue, 8 Feb 2005 01:02:48 +0000 (UTC) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id BA17F3BFEE9 for ; Mon, 7 Feb 2005 20:02:46 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: saag@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 07 Feb 2005 20:02:46 -0500 Sender: smb@cs.columbia.edu Message-Id: <20050208010246.BA17F3BFEE9@berkshire.machshav.com> X-Spam-Score: -3.234 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.523172 Subject: [saag] NIST moves to stronger hashing (Forwarded) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 08 Feb 2005 01:02:58 -0000 ------- Forwarded Message Date: Mon, 7 Feb 2005 12:39:36 -0500 To: cryptography@metzdowd.com, cypherpunks@al-qaeda.net From: "R.A. Hettinga" Subject: NIST moves to stronger hashing Federal Computer Week Monday, February 7, 2005 NIST moves to stronger hashing BY Florence Olsen Published on Feb. 7, 2005 Federal agencies have been put on notice that National Institute of Standards and Technology officials plan to phase out a widely used cryptographic hash function known as SHA-1 in favor of larger and stronger hash functions such as SHA-256 and SHA-512. The change will affect many federal cryptographic functions that incorporate hashes, particularly digital signatures, said William Burr, manager of NIST's security technology group, which advises federal agencies on electronic security standards. "There's really no emergency here," Burr said. "But you should be planning how you're going to transition - whether you're a vendor or a user - so that you can do better cryptography by the next decade." Hashing is used to prevent tampering with electronic messages. A hash is a numerical code generated from a string of text when a message is sent. The receiving system checks it against a hash it creates from the same text, and if they match, the message was sent intact. Speaking at a recent meeting of the federal Public Key Infrastructure Technical Working Group at NIST, Burr said some critics have questioned the security of the government-developed SHA-1 after some researchers managed to break a variant of the SHA-1 hash function last year. But Burr said no complete implementation of the SHA-1 function has been successfully attacked. "SHA-1 is not broken," he said, "and there is not much reason to suspect that it will be soon." But advances in computer processing capability make it prudent to phase out SHA-1 by 2010, he said. Burr said other widely used hash functions such as MD5 are vulnerable to attack and their use should be discontinued. "If by some chance you are still using MD5 in certificates or for digital signatures, you should stop," he said. - -- - ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com ------- End of Forwarded Message --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb From hartmans@MIT.EDU Wed Feb 9 15:24:29 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j19KOQ5j023900 for ; Wed, 9 Feb 2005 15:24:26 -0500 (EST) Received: from cz.mit.edu (STRATTON-THREE-NINETY-EIGHT.MIT.EDU [18.187.6.143]) j19KOKss015412; Wed, 9 Feb 2005 15:24:20 -0500 (EST) Received: by cz.mit.edu (Postfix, from userid 8042) id 4C79AE0063; Wed, 9 Feb 2005 15:24:26 -0500 (EST) To: Alessandro Armando References: <200502071600.j17G0r0V005383@armando.mrg.dist.unige.it> From: Sam Hartman Date: Wed, 09 Feb 2005 15:24:26 -0500 In-Reply-To: <200502071600.j17G0r0V005383@armando.mrg.dist.unige.it> (Alessandro Armando's message of "Mon, 07 Feb 2005 17:00:53 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000121 Spam-Alum-Time: 1.019835 cc: secdir@mit.edu cc: saag@mit.edu Subject: [saag] Re: IETF Meeting Minneapolis, saag: slot for AVISPA X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Feb 2005 20:24:30 -0000 >>>>> "Alessandro" == Alessandro Armando writes: Alessandro> Sam, >> In the interests of scheduling, it would be useful to know how >> much time you need. How much time would you like ideally? >> What is the minimum time for your presentation to be useful? Alessandro> I would say: Alessandro> Minimum: 20min Ideally: 30min Alessandro> alessandro > I don't anticipate having a problem giving you 30 minutes. From jorge.cuellar@siemens.com Thu Feb 10 17:00:26 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j1AM0O5j001079 for ; Thu, 10 Feb 2005 17:00:24 -0500 (EST) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) j1AM0HTR003535 for ; Thu, 10 Feb 2005 17:00:17 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j1AM0BJH012809; Thu, 10 Feb 2005 23:00:11 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j1AM0BiQ017449; Thu, 10 Feb 2005 23:00:11 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <1ATG2BPR>; Thu, 10 Feb 2005 23:00:11 +0100 Message-ID: From: Cuellar Jorge To: "'saag@mit.edu'" , "'eap@frascone.com'" Date: Thu, 10 Feb 2005 23:00:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.840799 Subject: [saag] RE: EAP and AVISPA (Was: Re: IETF Meeting Minneapolis, saag: slot for AVISPA) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 10 Feb 2005 22:00:26 -0000 Hi, Within our AVISPA Project (for details, see the last mail appended), we have modelled and verified the following EAP-Methods: EAP-AKA EAP-SIM EAP-TLS EAP-TTLS-Chap EAP-Archie EAP-IKEv2 Until now we have found no errors in any of them. We would very much like to discuss if the modelling is correct. We have discussed that within Siemens and elsewhere, but still it may be that some important aspects of those protocols could be overlooked. We will have the models and results presented at saag at the next IETF. For further information contact me. What is still missing anyway is the EAP-Keying framework and the relation of EAP to other protocols like 802.1x or PANA and DIAMETER. This will probably be a task for a further project in which we want to focus on compositionality questions. Best regards, Jorge ----------------------------------------------------------- Jorge R Cuellar Tel: +49 89 636 47 585 Siemens CT IC 3 Mobile: +49 173 96 03 527 Jorge.Cuellar@siemens.com -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Donnerstag, 10. Februar 2005 20:37 To: Alessandro Armando Cc: Bernard Aboba; Cuellar Jorge; Luca Compagna Subject: Re: EAP and AVISPA (Was: Re: [secdir]IETF Meeting Minneapolis, saag: slot for AVISPA) Sounds great! [Although I have the feeling that you may have missed something if you didn't find any errors in this set ;-) ] Would it be possible for us to send a note about your work to the EAP list? Better yet, send it there yourself. At least I don't recall seeing the information there. --Jari -----Original Message----- From: Alessandro Armando Subject: IETF Meeting Minneapolis, saag: slot for AVISPA Russ, Sam, this is a request to obtain a slot during the next open directorate meeting at the 62nd IETF in Minneapolis to present the current status of the results of the EU-Project AVISPA (Automated Validation of Internet Security Protocols and Applications), see http://www.avispa-project.org/. This will be in a sense a continuation of our presentation at the IETF-59 Seoul meeting, where we proposed to verify the security of Internet Protocols (with focus IETF) and to provide free tools for formal verification. I include the link to the draft versions of three key deliverables of AVISPA describing the current results of the project plus a short paper describing the AVISPA Tool. We think that they will also of interest for the general Internet community: http://www.avispa-project.org/Internal/IETF/ User Name: avispa-ietf Pwd: d61list The AVISPA Tool can be freely tried at the URL: http://www.avispa-project.org/software.html There are still several things that must be done in AVISPA: the user interface must become simpler, the semantics of the formal language must be clearer for non-specialists, we might need to change our specification of some protocols (for this we need feedback from protocol designers or implementers about if our modelling of the single protocols is correct or we have overseen something). We have to make our tools readily available to the designer of a protocol so that he can use a simple push-button, industrial-strength technology to search for attacks on his design. This is our commitment with the EU. This is why we need the need the discussion with the IETF security community. At the same time we sincerely believe that it will be of interest to you and of help to the Internet community in general. Best regards, Alessandro Armando -- Alessandro Armando e-mail: armando@dist.unige.it Associate Professor http://www.ai.dist.unige.it/armando DIST - Universita' di Genova, phone: +39-0103532216 viale Causa 13, fax: +39-0103532948 16145 GENOVA, ITALY mobile: +39-3281003201 From jis@jis.tzo.com Fri Feb 11 17:50:34 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j1BMoX5j010082 for ; Fri, 11 Feb 2005 17:50:33 -0500 (EST) Received: from jis.tzo.com (JISVPN.MIT.EDU [18.100.101.102]) j1BMoR82020366 for ; Fri, 11 Feb 2005 17:50:27 -0500 (EST) Received: (from jis@localhost) by jis.tzo.com (8.12.8p2/8.12.8) id j1BMnf8V000972; Fri, 11 Feb 2005 17:49:41 -0500 Date: Fri, 11 Feb 2005 17:49:40 -0500 From: "Jeffrey I. Schiller" To: iesg@ietf.org Message-ID: <20050211174940.B863@mit.edu> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from iesg-secretary@ietf.org on Fri, Feb 11, 2005 at 04:35:43PM -0500 X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.605937 cc: saag@mit.edu cc: ietf-sasl@imc.org Subject: [saag] Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 11 Feb 2005 22:50:35 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I object to this document being made a proposed standard. It effectively permits the use of plain text passwords over an insecure mechanism. I thought we were trying to eliminate such things in IETF protocols. Although the document purports to be used only when an underlying transport is providing security (aka TLS) it provides an escape clause. Namely the phrase "or backwards compatibility dictates otherwise." This phrase appears twice in the document. In section 1 and again in the Security Considerations Section. To wit: =46rom Section 1: The PLAIN SASL mechanism does not provide a security layer. This mechanism MUST NOT be used without adequate security protection as the mechanism affords no integrity nor confidentiality protection itself. The PLAIN SASL mechanism MUST NOT be advertised unless a strong encryption layer, such as provided by Transport Layer Security ([TLS]), is active or backwards compatibility dictates otherwise. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ =2E.. 6. Security Considerations The PLAIN mechanism relies on the TLS encryption layer for security. When used without TLS, it is vulnerable to a common network eavesdropping attack. Therefore PLAIN MUST NOT be advertised or used unless a suitable TLS encryption layer is active or backwards ^^^^^^^^^ compatibility dictates otherwise. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I will withdraw my objection if this "escape clause" is removed (and an equivalent one isn't substituted...). -Jeff -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFCDTaE8CBzV/QUlSsRAi02AKDww6n3OrW18wsNA+yCP+cEq4xXnwCfT7AC YRXYSxflup0p5xXq5sW42I0= =YoFc -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From smb@cs.columbia.edu Wed Feb 16 00:14:15 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j1G5ED5j014998 for ; Wed, 16 Feb 2005 00:14:14 -0500 (EST) Received: from machshav.com (machshav.com [147.28.0.16]) j1G5E66q021234 for ; Wed, 16 Feb 2005 00:14:06 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 0D8B6FB24A; Wed, 16 Feb 2005 00:14:06 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 970CBFB240 for ; Wed, 16 Feb 2005 00:14:05 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id C4F3C3C03BD for ; Wed, 16 Feb 2005 00:14:01 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: saag@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Feb 2005 00:14:01 -0500 Sender: smb@cs.columbia.edu Message-Id: <20050216051401.C4F3C3C03BD@berkshire.machshav.com> X-Spam-Score: -0.113 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000009 Spam-Alum-Time: 0.845032 Subject: [saag] SHA-1 collisions found X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 16 Feb 2005 05:14:16 -0000 http://www.schneier.com/blog/archives/2005/02/sha1_broken.html It's 2^69 work factor, and presumably of limited practical importance now. Of course, as Schneier has noted, attacks never get worse; they only improve. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb From pbaker@verisign.com Wed Feb 16 11:49:21 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j1GGnK5j019491 for ; Wed, 16 Feb 2005 11:49:20 -0500 (EST) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) j1GGnCHA009818 for ; Wed, 16 Feb 2005 11:49:13 -0500 (EST) Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53])j1GGnCOK014769 for ; Wed, 16 Feb 2005 08:49:12 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 16 Feb 2005 08:49:12 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3703812B@MOU1WNEXMB04.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" To: saag@mit.edu Subject: RE: [saag] SHA-1 collisions found Date: Wed, 16 Feb 2005 08:49:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.633178 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 16 Feb 2005 16:49:22 -0000 Bruce does not mention in his blog that this was announced at the RSA conference by Adi Shamir in the cryptography panel. The attack uses a modification of Biham's neutral bit technique which is probably why the Chinese group asked Adi to make the announcement for them. > -----Original Message----- > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On > Behalf Of Steven M. Bellovin > Sent: Tuesday, February 15, 2005 9:14 PM > To: saag@mit.edu > Subject: [saag] SHA-1 collisions found > > > http://www.schneier.com/blog/archives/2005/02/sha1_broken.html > > It's 2^69 work factor, and presumably of limited practical importance > now. Of course, as Schneier has noted, attacks never get worse; they > only improve. > > --Prof. Steven M. Bellovin, > http://www.cs.columbia.edu/~smb > > > > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag > From mcr@sandelman.ottawa.on.ca Wed Feb 16 13:32:09 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j1GIW65j020364 for ; Wed, 16 Feb 2005 13:32:06 -0500 (EST) Received: from pike.sandelman.ca (pike.sandelman.ca [205.150.200.164]) j1GIW0C9002287 for ; Wed, 16 Feb 2005 13:32:00 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by pike.sandelman.ca (Postfix) with ESMTP id 4BF406447B for ; Wed, 16 Feb 2005 13:31:59 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id E1762BE20 for ; Wed, 16 Feb 2005 13:31:58 -0500 (EST) To: saag@mit.edu Subject: Re: [saag] SHA-1 collisions found In-Reply-To: Message from "Hallam-Baker, Phillip" <198A730C2044DE4A96749D13E167AD3703812B@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3703812B@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-Mailer: MH-E 7.82; nmh 1.0.4+dev; XEmacs 21.4 (patch 16) Date: Wed, 16 Feb 2005 13:31:58 -0500 Message-ID: <18225.1108578718@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: -1.524 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.820364 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 16 Feb 2005 18:32:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Bruce writes: > It pretty much puts a bullet into SHA-1 as a hash function for digital > signatures (although it doesn't affect applications such as HMAC where > collisions aren't important). so IPsec and SSL are in a nice position where the bulk cryptographic operations still don't have to change. So, no replacement of hardware. Thank you to Hugo, who I think originally made IPsec use HMAC. The things that are at risk, the digital signatures, are "fortunately" in the control plane, and therefore easier to upgrade. Still, 2^69. We have a bit of breathing room here. The thing that concerns me most is DNSSEC and OpenPGP. (Well, okay, SSL as well, but I personally never built much trust in it). In particular, we seem to conclude that it was major pain to introduce new algorithms in DNSSEC. - -- ] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [ ] mcr @ xelerance.com Now doing IPsec training, see |net architect[ ] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQhORnYqHRg3pndX9AQFHuQP+ISb9YeJo86ZoUAMW3hwdUCZKblArNf0J acV0Z/AfMnCYXukXlrJbssus8sX3DhozLhwh+Oz39wnOg9ifHXd+7U686tq7VEtH Mnb7uyaV4/qaiaAsDTjXNlx8WOI8LQCsqtOHhcd/jfY3cxF38gfxbLZM6S50XY4s CqzRv2XcspU= =wJzR -----END PGP SIGNATURE----- From jwn2@qualcomm.com Wed Feb 16 14:00:16 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j1GJ0E5j020532 for ; Wed, 16 Feb 2005 14:00:14 -0500 (EST) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) j1GJ06C9004512 for ; Wed, 16 Feb 2005 14:00:07 -0500 (EST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) j1GJ04eD001830; Wed, 16 Feb 2005 11:00:04 -0800 (PST) Received: from [10.30.11.22] (vpn-10-50-16-40.qualcomm.com [10.50.16.40]) j1GIxtfv002010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 Feb 2005 11:00:00 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <198A730C2044DE4A96749D13E167AD3703812B@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3703812B@MOU1WNEXMB04.vcorp.ad.vrsn.com> User-Agent: eudora62carbon-0203050812 X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Wed, 16 Feb 2005 10:55:12 -0800 To: "Hallam-Baker, Phillip" From: John W Noerenberg II Subject: RE: [saag] SHA-1 collisions found Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-PMX-Version: 4.7.0.111621 X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.139814 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 16 Feb 2005 19:00:17 -0000 At 8:49 AM -0800 2/16/05, Phillip Hallam-Baker wrote: >Bruce does not mention in his blog that this was announced at the RSA >conference by Adi Shamir in the cryptography panel. > >The attack uses a modification of Biham's neutral bit technique which is >probably why the Chinese group asked Adi to make the announcement for them. Any word on when and where the paper will be published? -- john noerenberg ---------------------------------------------------------------------- Statt des törichten Ignorabimus heiße im Gegenteil unsere Lösung: Wir müssen wissen, Wir werden wissen. -- David Hilbert, "Logic and the Understanding of Nature, Sep 1930 ---------------------------------------------------------------------- From weiler@tislabs.com Wed Feb 16 14:47:14 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j1GJlD5j021009 for ; Wed, 16 Feb 2005 14:47:13 -0500 (EST) Received: from nutshell.tislabs.com (nutshell.tislabs.com [192.94.214.100]) j1GJl5C9010280 for ; Wed, 16 Feb 2005 14:47:06 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j1GJhXH8024598 for ; Wed, 16 Feb 2005 14:43:33 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAZVa4bW; Wed, 16 Feb 05 14:43:29 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j1GJjHJt022735; Wed, 16 Feb 2005 14:45:17 -0500 (EST) Date: Wed, 16 Feb 2005 14:45:16 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: saag@mit.edu Subject: Re: [saag] SHA-1 collisions found Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.606448 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 16 Feb 2005 19:47:14 -0000 On Wed, 16 Feb 2005, Michael Richardson wrote: > In particular, we seem to conclude that it was major pain to > introduce new algorithms in DNSSEC. I'm curious as to why you think that. >From an operational perspective, a DNS zone can choose to sign with a new algorithm[1] with the only downside being that old validators won't be able to get secured answers from that zone -- they'll still see the data, but the zone will appear to be unsigned, just like very other unsigned zone (e.g. the root). The zone could also use both a new algorithm and an older (broken?) one, which would still provide some protection for those older validators. Newer validators can choose to ignore the broken algorithm (or ignore it in zones where a better algorithm is in use), making them immune to attacks that use it. As far as the protocol, there was an issue around the introduction of new algorithms, but I believe we fixed it a year and a half ago. For a detailed discussion of the problem, see the namedroppers archives from 13 August 2003, subject "DNSSECbis Q-2: degradation attack". http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01539.html Discussion on the list ended about a month later: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01773.html David Blacka recently uncovered a (potentially) similar problem with the handling of private algorithms, and the working group quickly figured out how to work around that one. -- Sam [1] DNSSEC uses a single algorithm number to select both a public key algorithm and a hash function. For example, algorithm 1 is RSA/MD5, and algorithm 5 is RSA/SHA-1. A separate number is used to select a message digest for DS resource records, with SHA-1 being the only one currently defined. To facilitate introduction of new DS message digest algorithms, the logic in the "degradation attack" thread needs to be applied to those algorithms, too. That's not documented in the DNSSECbis docs, but it should be pretty obvious, and I'm sure it will be in an upcoming clarification doc. From mcr@sandelman.ottawa.on.ca Wed Feb 16 14:53:31 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j1GJrT5j021070 for ; Wed, 16 Feb 2005 14:53:29 -0500 (EST) Received: from pike.sandelman.ca (pike.sandelman.ca [205.150.200.164]) j1GJrLC9022339 for ; Wed, 16 Feb 2005 14:53:21 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by pike.sandelman.ca (Postfix) with ESMTP id 30D4D6457C; Wed, 16 Feb 2005 14:53:21 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id A405BBE20; Wed, 16 Feb 2005 14:53:20 -0500 (EST) To: Sam Weiler Subject: Re: [saag] SHA-1 collisions found In-Reply-To: Message from Sam Weiler References: X-Mailer: MH-E 7.82; nmh 1.0.4+dev; XEmacs 21.4 (patch 16) Date: Wed, 16 Feb 2005 14:53:20 -0500 Message-ID: <18805.1108583600@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.593087 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 16 Feb 2005 19:53:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Sam" == Sam Weiler writes: Sam> On Wed, 16 Feb 2005, Michael Richardson wrote: >> In particular, we seem to conclude that it was major pain to >> introduce new algorithms in DNSSEC. Sam> I'm curious as to why you think that. ... Sam> As far as the protocol, there was an issue around the Sam> introduction of new algorithms, but I believe we fixed it a Sam> year and a half ago. For a detailed discussion of the problem, my mistake. I thought it was unsolved -- I understood that if only unknown algorithms were seen to a resolver, that it could not reach a conclusion, and that resolvers might prefer to say "bad data". I'm still concerned. - -- ] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [ ] mcr @ xelerance.com Now doing IPsec training, see |net architect[ ] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQhOkr4qHRg3pndX9AQF3SwQA2JEd3iFuKW56vKIn2K2f+7DrlKZW7rjx aJSWOVo4xFPvNRMCiWVbYDDI0wZmMy6DsIUih3Scp1qbfvSTMfTQGIr5pkMMSVBt 2UKFpYvB+tWj7OyI48Ih32Ejv+I/REKPg+EsWk4302Bnw6mu0JS8DWqTOpWWWpEX SlHZU97DvC4= =zn+N -----END PGP SIGNATURE----- From jwkckid1@ix.netcom.com Thu Feb 17 00:22:17 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j1H5MF5j025468 for ; Thu, 17 Feb 2005 00:22:15 -0500 (EST) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243])j1H5M82c010636 for ; Thu, 17 Feb 2005 00:22:09 -0500 (EST) Received: from 1cust19.tnt36.dfw9.da.uu.net ([67.234.81.19] helo=ix.netcom.com) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1D1e74-0005Kv-00; Thu, 17 Feb 2005 00:22:06 -0500 Message-ID: <421444D1.B52E6951@ix.netcom.com> Date: Wed, 16 Feb 2005 23:16:37 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Michael Richardson Subject: Re: [saag] SHA-1 collisions found References: <198A730C2044DE4A96749D13E167AD3703812B@MOU1WNEXMB04.vcorp.ad.vrsn.com> <18225.1108578718@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.739023 cc: aba isc list cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 17 Feb 2005 05:22:18 -0000 Michael and all, I would agree. Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > Bruce writes: > > > It pretty much puts a bullet into SHA-1 as a hash function for digital > > signatures (although it doesn't affect applications such as HMAC where > > collisions aren't important). > > so IPsec and SSL are in a nice position where the bulk cryptographic > operations still don't have to change. So, no replacement of hardware. > > Thank you to Hugo, who I think originally made IPsec use HMAC. > > The things that are at risk, the digital signatures, are "fortunately" > in the control plane, and therefore easier to upgrade. > Still, 2^69. We have a bit of breathing room here. > > The thing that concerns me most is DNSSEC and OpenPGP. > (Well, okay, SSL as well, but I personally never built much trust in it). > > In particular, we seem to conclude that it was major pain to introduce > new algorithms in DNSSEC. > > - -- > ] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [ > ] mcr @ xelerance.com Now doing IPsec training, see |net architect[ > ] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[ > ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > Comment: Finger me for keys > > iQCVAwUBQhORnYqHRg3pndX9AQFHuQP+ISb9YeJo86ZoUAMW3hwdUCZKblArNf0J > acV0Z/AfMnCYXukXlrJbssus8sX3DhozLhwh+Oz39wnOg9ifHXd+7U686tq7VEtH > Mnb7uyaV4/qaiaAsDTjXNlx8WOI8LQCsqtOHhcd/jfY3cxF38gfxbLZM6S50XY4s > CqzRv2XcspU= > =wJzR > -----END PGP SIGNATURE----- > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From ekr@rtfm.com Thu Feb 17 10:21:29 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j1HFLR5j000845 for ; Thu, 17 Feb 2005 10:21:27 -0500 (EST) Received: from sierra.rtfm.com (sierra.rtfm.com [198.144.203.251]) j1HFLHrY026462 for ; Thu, 17 Feb 2005 10:21:18 -0500 (EST) Received: from rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id 466502850B for ; Thu, 17 Feb 2005 07:45:25 -0800 (PST) To: saag@mit.edu X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Thu, 17 Feb 2005 07:25:20 -0800 From: Eric Rescorla Message-Id: <20050217154525.466502850B@sierra.rtfm.com> X-Spam-Score: -4.397 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.338832 Subject: [saag] Another bad day at the hash function factory X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 17 Feb 2005 15:21:30 -0000 According to Bruce Schneier, Wang, Yin, and Yu have made some very substantial progress in attacking SHA-1. http://www.schneier.com/blog/archives/2005/02/sha1_broken.html The headline claim is the ability to find a collision in SHA-1 in 2^69 operations. Here's a somewhat revised version of my post after the MD5 attacks last year. USES OF HASH FUNCTIONS We use hash algorithms in a bunch of different contexts. At minimum: 1. Digital signatures (you sign the hash of a message). (a) On messages (e.g. S/MIME). (b) On certificates. (c) In authentication primitives (e.g., SSH) 2. As MAC functions (e.g. HMAC) 3. As authentication functions (e.g. CRAM-MD5) 4. As key generation functions (e.g. SSL or IPsec PRF) THE POTENTIAL ATTACKS The only situation in which the current attacks definitely apply is (1). The general problem is illustrated by the following scenario. Alice and Bob are negotiating a contract. Alice generates two messages: M = "Alice will pay Bob $500/hr" M' = "Alice will pay Bob $50/hr" [0] Where H(M) = H(M'). She gets Bob to sign M (and maybe signs it herself). Then when it comes time to pay Bob, she whips out M' and says "I only owe $50/hr", which Bob has also signed (remember that you sign the hash of the message). So, this attack threatens non-repudiation or any kind of third party verifiability. Another, slightly more esoteric, case is certificates. Remember that a certificate is a signed message from the CA containing the identity of the user. So, Alice generates two certificate requests: R = "Alice.com, Key=X" R' = "Bob.com, Key=Y" Such that H(R) = H(R') (I'm simplifying here). When the CA signs R, it's also signing R', so Alice can present her new "Bob" certificate and pose as Bob. It's not clear that this attack can work in practice because Alice doesn't control the entire cert: the CA specifies the serial number. This attack is especially difficult to mount at the current security level of SHA-1 because you have to know the contents of the certificate at the time you start generating the colliding pair. Because that process takes 2^69 operations, you're probably talking days to weeks and predicting the exact next serial number over that time span is not going to be easy. If VeriSign and other CAs add just a very small bit of randomness to their certs, they should be able to defend against it. Remember, also, that there are other ways to get false certs if you're willing to expend the amount of money represented by 2^69 operations. WHAT'S SAFE? First, anything that's already been signed should be safe. If you stop using MD5 today, nothing you signed already puts you at risk. There is probably no risk to two party SSH/SSL-style authentication handshakes. It's believed that HMAC is secure against this attack (according to Hugo Krawczyk, the designer) so the modern MAC functions should all be secure. When this happened to MD5, I worried a bit about CRAM-MD5 and HTTP Digest. They're not as well designed as HMAC. I've done a little thinking about how to attack them and not come up with anything, but there's no guarantee. But again, you'd need to expend a truly enormous amount of CPU power. The key generation PRFs should be safe. NEXT STEPS This isn't a catastrophe, but we need to start planning for the future. (warning, slightly heavy sledding ahead). The bad news is that there is no standard function that is guaranteed to be more secure. In particular, we can't really be confident that SHA-256 is going to be stronger. Here are a few alternatives: Randomized hashing: The whole reason why this attack works is that the attacker knows the exact message you're going to hash. If you prefix the message with a random value, this effectively defeats the attack. So, when you sign a message you would sign H(random || message) instead of H(message). In particular, CAs should immediately start using unpredictable serial numbers. [1] Note, however, that this simple variant only works against the attack where the relying party generates the colliding pairs. If the attesting party does then they can shoose whatever randomness they want. However, a variant in which the parties jointly choose the random seed does work. A non-MDx-based hash function: All of the major standard hash functions ultimately derive from MD4. It's possible to design hash functions based on block ciphers (see http://dimacs.rutgers.edu/Workshops/Practice/slides/shrimpton.ppt) for an overview. Unfortunately, as I understand it you can't prove security for these constructions in a realistic model of the underlying algorithm. However, there's some hope that you would have to make a pretty serious dent in that block cipher in order to break the hash. Strangely enough, it's actually easier to specify a new hash function than it is to move to randomized hashing. At the end of the day, we'll probably want to do both because randomized hashing provides protection against this kind of attack in general, regardless of the status of the hash function. Here's one non-alternative: Concatenation: The obvious thing to do is to take a SHA-1 and an MD5 and concatenate them on the theory that this makes things harder. Unfortunately, Joux's CRYPTO 2004 paper on multicollisions suggests that this doesn't make things anywhere near as much harder as you would expect. -Ekr [0] In practice, the messages might not be this similar, but there turn out to be lots of opportunities to make subtle changes in any text message. [1] It's easy to make these monotonically increasing. Just use Counter || random From mleech@nortel.com Thu Feb 17 11:36:29 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j1HGaR5j001447 for ; Thu, 17 Feb 2005 11:36:27 -0500 (EST) Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56])j1HGaKk9018889 for ; Thu, 17 Feb 2005 11:36:21 -0500 (EST) Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) id j1HGaBh01431; Thu, 17 Feb 2005 11:36:11 -0500 (EST) Received: from nortelnetworks.com (wcary0w4.ca.nortel.com [47.129.148.152]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1XL5PBTZ; Thu, 17 Feb 2005 11:36:12 -0500 Message-ID: <4214C7FA.10809@nortelnetworks.com> Date: Thu, 17 Feb 2005 11:36:10 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Marcus Leech User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [saag] Another bad day at the hash function factory References: <20050217154525.466502850B@sierra.rtfm.com> In-Reply-To: <20050217154525.466502850B@sierra.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000006 Spam-Alum-Time: 0.551860 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 17 Feb 2005 16:36:30 -0000 I haven't seen the paper, so I don't know how long it took for them to find a collision, and using what magnitude of computing resources. But it would be interesting to calibrate this attack against what EFF/Deep Crack were able to do 7 years ago. My gut feeling is that collision finding is somewhat more complex (from a number of gates in a FPGA point of view) than key finding, and that hash functions like SHA-1 require more resources (again in terms of gates in a FPGA). Comments? From smb@cs.columbia.edu Thu Feb 17 12:20:45 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j1HHKi5j001734 for ; Thu, 17 Feb 2005 12:20:44 -0500 (EST) Received: from machshav.com (machshav.com [147.28.0.16]) j1HHKbk9009678 for ; Thu, 17 Feb 2005 12:20:38 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 458F2FB24A; Thu, 17 Feb 2005 12:20:37 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id ECD08FB240; Thu, 17 Feb 2005 12:20:34 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 5CC5D3C03BD; Thu, 17 Feb 2005 12:20:36 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Marcus Leech Subject: Re: [saag] Another bad day at the hash function factory In-Reply-To: Your message of "Thu, 17 Feb 2005 11:36:10 EST." <4214C7FA.10809@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Feb 2005 12:20:36 -0500 Sender: smb@cs.columbia.edu Message-Id: <20050217172036.5CC5D3C03BD@berkshire.machshav.com> X-Spam-Score: -2.79 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.606514 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 17 Feb 2005 17:20:47 -0000 In message <4214C7FA.10809@nortelnetworks.com>, Marcus Leech writes: >I haven't seen the paper, so I don't know how long it took for them to > find a collision, and using what magnitude of computing resources. > >But it would be interesting to calibrate this attack against what > EFF/Deep Crack were able to do 7 years ago. My gut feeling > is that collision finding is somewhat more complex (from a > number of gates in a FPGA point of view) than key finding, and > that hash functions like SHA-1 require more resources (again > in terms of gates in a FPGA). > >Comments? Finding a collision by brute force is inherently harder, because it requires some communication: two widely-separated machines may have produced matching outputs, but they need to know about the other one. That said, van Oorschot and Wiener published a paper in 1994 on how to do it. They estimated then that an MD5-cracker could be built for $10,000,000 with an expected runtime of 24 days. The SHA1 attack is a 2^69 problem; MD5 collisions are 2^64; the difference is pretty close to the Moore's Law gain since 1994. I haven't followed the literature on that subject; I don't know if there are better designs or, for that matter, if they got it wrong. I should note, though, that this is a meaningless discussion -- no technical details have been released about the new attack, so we don't know how easily it parallelizes. As for gates -- from a naive level, SHA1 has 80 rounds; DES has 16. If you want high throughput (again, for a brute force style of attack), you need a pipeline and replication of the core logic; that alone would imply a 5-fold increase in the gate count. Beyond that, SHA1 has a 160-bit data path; DES uses a 32-bit path. I won't try to estimate the relative complexities of the mixing functions at each round. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb From sommerfeld@sun.com Thu Feb 17 12:28:52 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j1HHSp5j001816 for ; Thu, 17 Feb 2005 12:28:51 -0500 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) j1HHSik9025623 for ; Thu, 17 Feb 2005 12:28:44 -0500 (EST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j1HHShnK002841; Thu, 17 Feb 2005 10:28:43 -0700 (MST) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) ESMTP id j1HHSgOp024993; Thu, 17 Feb 2005 12:28:42 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j1HHSgim023325; Thu, 17 Feb 2005 12:28:42 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j1HHSgCt023324; Thu, 17 Feb 2005 12:28:42 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: [saag] Another bad day at the hash function factory From: Bill Sommerfeld To: Eric Rescorla In-Reply-To: <20050217154525.466502850B@sierra.rtfm.com> References: <20050217154525.466502850B@sierra.rtfm.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1108661321.20616.27.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Thu, 17 Feb 2005 12:28:42 -0500 X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000001 Spam-Alum-Time: 0.542015 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 17 Feb 2005 17:28:54 -0000 On Thu, 2005-02-17 at 10:25, Eric Rescorla wrote: > According to Bruce Schneier, Wang, Yin, and Yu have made some > very substantial progress in attacking SHA-1. > > http://www.schneier.com/blog/archives/2005/02/sha1_broken.html > > The headline claim is the ability to find a collision in > SHA-1 in 2^69 operations. Here's a somewhat revised version > of my post after the MD5 attacks last year. Another "don't panic just yet" observation I haven't yet seen elsewhere: With this attack, SHA1 is still stronger against collisions than an unbroken 128-bit hash function. (2^69 > 2^64). - Bill From jari.arkko@piuha.net Thu Feb 17 16:37:07 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j1HLb55j003574 for ; Thu, 17 Feb 2005 16:37:06 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) j1HLavVX022291 for ; Thu, 17 Feb 2005 16:36:58 -0500 (EST) Received: from piuha.net (p130 [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8394789883; Thu, 17 Feb 2005 23:36:54 +0200 (EET) Message-ID: <42150E1E.4000701@piuha.net> Date: Thu, 17 Feb 2005 23:35:26 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: saag@mit.edu Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.798793 Subject: [saag] Icos BoF -- security for IP configuration X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 17 Feb 2005 21:37:08 -0000 I'm not sure if this is an appropriate day to worry about protocols when algorithms may have problems :-( ... But we are planning to run a BoF in the next IETF about the security issues in IP layer configuration. The BoF was initiated due to the recent interest in various groups to use EAP as a means for securing configuration functions or bootstrap phases in other protocols (something that has got the EAP co-chairs a bit worried). The focus of the BoF is slightly more general, however; we intend to look at this from an architectural perspective and talk about the different needs and types of solutions that are possible. We have a mailing list set up, please join & participate in the discussions. See below for the URL to subscribe. ---- IP Configuration Security BoF Chairs: Bernard Aboba Jari Arkko Area Directors: Thomas Narten Margaret Wasserman Mailing list: https://www.machshav.com/mailman/listinfo.cgi/icos This BoF will provide an overview of secure Internet layer configuration needs, discussing the architectural issues, areas of applicability and potential solutions under discussion in different areas of the IETF. The purpose of the BoF is to discuss a common topic that touches several existing Working Groups, and it is not expected that a new working group will be formed as a result. The BoF will also not replace ongoing process in existing WGs, though it is hoped that the discussion gives additional insights to the participants to deal with these issues. The need for this BoF has came up in the context of expanding EAP usage, including the use of EAP for configuration in different IETF WGs. However, the BoF will discuss this issue from a general point of view, as the issue is not related to just a single protocol. Examples of specific issues in IP layer protocols are brought forward, however, as are examples of solutions in order make it easier to understand the concrete implications of the issues. Internet layer configuration is defined as the configuration required to support the operation at the Internet layer. This includes IP address configuration, default gateway(s), name server configuration, boot configuration (TFTP, NFS), service location and directory configuration, mobility configuration, and time server configuration (NTP). Configuration is typically performed insecurely today. For example, DHCP is rarely secured for a variety of reasons, even though a security mechanism has been defined in RFC 3118. In other cases, such as in Mobile IPv6, the use of security tools is mandatory in the protocols, but there are deployment barriers. As a result, Internet Area working groups are exploring alternative solutions. These include use of EAP for use for key derivation, and configuration. For example, the DHC WG has considered employment of EAP-derived keys for use with DHCP security, as defined in RFC 3118 and 3315. The MIPv6 WG, in investigating the bootstrapping problem, has considered proposals involving use of IKEv2 with EAP, as well as utilization of link layer EAP exchanges for configuration. IPv6 uses Router Advertisements for address autoconfiguration; however, a mechanism is needed to secure them. The SEND working group defined a zero-configuration mechanism for secure IP address configuration, based on Cryptographically Generated Addresses (CGAs). It also defined a certificate-based authorization for routers, where hosts can use a router that has a certificate traceable to a trusted root configured for the host. All these configuration tasks have delay constraints, because they typically need to be performed before a node that just moved can resume communications. Reading list: [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [RFC3315] Droms, R., Ed., Bound, J., Volz,, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [RFC3818] Schryver, V., "IANA Considerations for Point-to-Point Protocol", RFC 3818, June 2004. [ANYCAST] Hagino, J., and K. Ettikan, "An Analysis of IPv6 Anycast", draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt, Internet draft (work in progress), June 2003. [DHCPv4Threat] Hibbs, R., Smith, C., Volz, B., Zohar, M., "Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis", draft-ietf-dhc-v4-threat-analysis-02.txt, Internet draft (work in progress), April 2004. [DHCPv6Threat] Prigent, N., Marchand, J., Dupont, F., Cousin, B., Laurent- Maknavicius, M. and J. Bournelle, "DHCPv6 Threats", draft- prigent-dhcpv6-threats-00.txt, March 2001. [DNSConfv6] Jeong, J. (ed.), "IPv6 Host Configuration of DNS Server Information Approaches", draft-ietf-dnsop-ipv6-dns- configuration-04.txt, Internet draft (work in progress), September 2004. [EAP3118] Yegin, A., Tschofenig, H. and D. Forsberg, "Bootstrapping RFC 3118 Delayed DHCP AUthentication Using EAP-based Network Access Authentication", draft-yegin-eap-boot-rfc3118-01.txt, Internet draft (work in progress), January 2005. [EAPIKE] Tschofenig, H., Kroeselberg, D., Ohba, Y. and F. Bersani, "EAP IKEv2 Method (EAP-IKEv2)", draft-tschofenig-eap-ikev2-05.txt, Internet draft (work in progress), October 2004. [IKEv2] Kaufman, C., (ed.), "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-17.txt, Internet draft (work in progress), September 2004. [IPCPMIPv6] Song, J., Chong, C. and D. Leigh, "MIPv6 IPCP configuration option for PPP IPv6CP", draft-song-pppext-mipv6-ppp- support-01.txt, Internet draft (work in progress), October 2001. [SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, "SEcure Neighbor Discovery (SEND)", draft-ietf-send- ndopt-06.txt, Internet draft (work in progress), January 2005. [SEND-CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", draft-ietf-send-cga-06.txt, Internet draft (work in progress), October 2004. [MIPv6-BOOT] A. Patel, "Problem Statement for bootstrapping Mobile IPv6, draft-ietf-mip6-bootstrap-ps-01.txt, Internet draft (work in progress), October 2004. [MIPv6-IKEv2] Devarapalli, V., "Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture", draft-ietf-mip6-ikev2-ipsec-00.txt, Internet draft (work in progress), October 2004. [MIPv6-EAP] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., and M. Laurent-Maknavicius, "MIPv6 Authorization and Configuration based on EAP", draft-giaretta-mip6-authorization-eap-02.txt, Internet draft (work in progress), October 2004. [MIPv6-AAA] Yegin, A., "AAA Mobile IPv6 Application Framework", draft-yegin-mip6-aaa-fwk-00.txt, Internet draft (work in progress), August 2004. [MIPv6-BOOT2] J. Kempf, E. Nordmark, S. Chakrabarti, "Bootstrapping Mobile IPv6", draft-chakrabarti-mip6-bmip-00.txt, Internet draft (work in progress), December 2004. ---- IP Configuration Security BOF Agenda Time and Date: Monday, March 7, 2005, 1530-1730 (Tentative - have asked to be moved to Wed-Thu!) Preliminaries: (5 minutes) - Minute Takers - Bluesheets IP Configuration Security Problem, Bernard Aboba (10 minutes) http://www.drizzle.com/~aboba/IETF62/icos.ppt Why do we care, TBD (10 minutes) Credential Reuse, TBD (10 minutes) EAP and its Applicability, Bernard Aboba (15 minutes) http://www.drizzle.com/~aboba/IETF62/icos.ppt http://www.ietf.org/rfc/rfc3748.txt http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-04.txt Overview of The MIPv6 Bootstrap Problem, James Kempf (20 minutes) http://www.ietf.org/internet-drafts/draft-ietf-mipv6-bootstrap-ps-01.txt http://www.ietf.org/internet-drafts/draft-giaretta-mip6-authorization-eap-02.txt http://www.ietf.org/internet-drafts/draft-chakrabarti-mip6-bmip-00.txt http://www.ietf.org/internet-drafts/draft-ietf-mipv6-ikev2-ipsec-00.txt (more documents in the reading list) Overview of DHCP Security, Mark Stapp/Ralph Droms (20 minutes) http://www.ietf.org/rfc/rfc3118.txt http://www.ietf.org/rfc/rfc3315.txt http://www.ietf.org/internet-drafts/draft-ietf-dhc-v4-threat-analysis-03.txt http://www.ietf.org/internet-drafts/draft-yegin-eap-boot-rfc3118-01.txt http://bgp.potaroo.net/ietf/all-ids/draft-ietf-dhc-auth-sigzero-00.txt http://www.drizzle.com/~aboba/IETF62/draft-stapp-dhc-eap-00.txt (To Be Provided) Overview of Secure Configuration in SEND, Jari Arkko (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-send-cga-06.txt http://www.ietf.org/internet-drafts/draft-ietf-send-ndopt-06.txt Overview of Other IP Layer Needs, TBD (5 min) - Mobile IPv4 - PANA - IKEv2 Discussion and Wrapup (20 minutes) From phoffman@imc.org Thu Feb 17 23:04:09 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j1I4475j005835 for ; Thu, 17 Feb 2005 23:04:07 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) j1I440bb008033 for ; Thu, 17 Feb 2005 23:04:01 -0500 (EST) Received: from [10.20.30.249] (dsl2-63-249-109-246.cruzio.com [63.249.109.246]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I43wdO033657; Thu, 17 Feb 2005 20:04:00 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050217154525.466502850B@sierra.rtfm.com> References: <20050217154525.466502850B@sierra.rtfm.com> Date: Thu, 17 Feb 2005 20:03:30 -0800 To: Eric Rescorla , saag@mit.edu From: Paul Hoffman Subject: Re: [saag] Another bad day at the hash function factory Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.755044 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 18 Feb 2005 04:04:10 -0000 At 7:25 AM -0800 2/17/05, Eric Rescorla wrote: >THE POTENTIAL ATTACKS >The only situation in which the current attacks definitely apply is >(1). The general problem is illustrated by the following scenario. >Alice and Bob are negotiating a contract. Alice generates two >messages: > >M = "Alice will pay Bob $500/hr" >M' = "Alice will pay Bob $50/hr" [0] > >Where H(M) = H(M'). > >She gets Bob to sign M (and maybe signs it herself). Then when it >comes time to pay Bob, she whips out M' and says "I only owe >$50/hr", which Bob has also signed (remember that you sign the >hash of the message). > >So, this attack threatens non-repudiation or any kind of third >party verifiability. General question: do we have any protocols in the IETF where this is relevant? We seem to take on the world's burdens, including non-repudiation, but we don't have those burdens in our own protocols. > Another, slightly more esoteric, case is >certificates. Remember that a certificate is a signed message >from the CA containing the identity of the user. So, Alice >generates two certificate requests: > >R = "Alice.com, Key=X" >R' = "Bob.com, Key=Y" > >Such that H(R) = H(R') (I'm simplifying here). > >When the CA signs R, it's also signing R', so Alice can present >her new "Bob" certificate and pose as Bob. It's not clear that >this attack can work in practice because Alice doesn't control >the entire cert: the CA specifies the serial number. > >This attack is especially difficult to mount at the current >security level of SHA-1 because you have to know the contents >of the certificate at the time you start generating the colliding >pair. Because that process takes 2^69 operations, you're >probably talking days to weeks and predicting the exact >next serial number over that time span is not going to be easy. >If VeriSign and other CAs add just a very small bit of randomness >to their certs, they should be able to defend against it. Some CAs, including VeriSign, already do this. The serial number of modern certs aren't a monotonically increasing number: they are often based on the hash of the public key (often with other stuff in the cert, and sometimes a random number, mixed in). For example, Amazon.com's serial number from VeriSign is 0E:A5:09:3E:35:7E:74:DB:8A:D3:7D:44:83:20:F9:DD. Of course, other CAs don't do this. For example, the IETF's serial number from Thawte (which is 0wned by VeriSign) is 3E:9D:69. >A non-MDx-based hash function: All of the major standard hash functions >ultimately derive from MD4. It's possible to design hash functions >based on block ciphers (see >http://dimacs.rutgers.edu/Workshops/Practice/slides/shrimpton.ppt) >for an overview. Unfortunately, as I understand it >you can't prove security for these constructions in a realistic >model of the underlying algorithm. However, there's some hope >that you would have to make a pretty serious dent in that block >cipher in order to break the hash. This seems to sound promising for using an AES as hash function. After all, if a big dent is made in AES, the non-repudiation and multiple-cert scenarios will be infinitely much less important than "all my secrets are gone". >Strangely enough, it's actually easier to specify a new hash function >than it is to move to randomized hashing. At the end of the day, >we'll probably want to do both because randomized hashing provides >protection against this kind of attack in general, regardless of >the status of the hash function. Note that the protocol cost of randomized hashing is high, namely that all the protocols will need to carry an additional value with each hash. Major yuck. --Paul Hoffman, Director --Internet Mail Consortium From sommerfeld@sun.com Fri Feb 18 00:02:17 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j1I52G5j006241 for ; Fri, 18 Feb 2005 00:02:16 -0500 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) j1I528Kk022499 for ; Fri, 18 Feb 2005 00:02:09 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j1I525hl029756; Thu, 17 Feb 2005 22:02:06 -0700 (MST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) ESMTP id j1I525Qp017763; Fri, 18 Feb 2005 00:02:05 -0500 (EST) Subject: Re: [saag] Another bad day at the hash function factory From: Bill Sommerfeld To: Paul Hoffman In-Reply-To: References: <20050217154525.466502850B@sierra.rtfm.com> Content-Type: text/plain Message-Id: <1108702868.51832.1163.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Fri, 18 Feb 2005 00:01:10 -0500 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000007 Spam-Alum-Time: 0.531102 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 18 Feb 2005 05:02:19 -0000 On Thu, 2005-02-17 at 23:03, Paul Hoffman wrote: > >So, this attack threatens non-repudiation or any kind of third > >party verifiability. > > General question: do we have any protocols in the IETF where this is > relevant? yes. third party verifiability is key to most uses of certificates. if you can find a collision like: M = "Key X belongs to asra42fcxaafs51ijax.com" and M' = "Key X belongs to paypal.com and asdlfadskjasdfipoupds.com" (encoded as X.509 certs) register the garbage domain names in M, get a trusted CA with predictable serial numbers to sign them, and poof you're in business as paypal.com ... - Bill From jwkckid1@ix.netcom.com Fri Feb 18 01:44:25 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j1I6iN5j007033 for ; Fri, 18 Feb 2005 01:44:23 -0500 (EST) Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60])j1I6iGIl027577 for ; Fri, 18 Feb 2005 01:44:16 -0500 (EST) Received: from 1cust223.tnt36.dfw9.da.uu.net ([67.234.81.223] helo=ix.netcom.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1D21s4-0003oI-00; Fri, 18 Feb 2005 01:44:12 -0500 Message-ID: <4215A98F.64CAFF85@ix.netcom.com> Date: Fri, 18 Feb 2005 00:38:41 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [saag] Another bad day at the hash function factory References: <20050217154525.466502850B@sierra.rtfm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -4.397 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.271169 cc: aba isc list cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 18 Feb 2005 06:44:26 -0000 Eric and all, Well done review and short analysis, Eric. Others should consider this short analysis of yours. Well done! >;) My concern is that with computing power increasing rapidly and methods of finding collisions becoming much more efficient as a factor of computing power required, SHA-1, SHA-256 and SHA-512 will be hacked to oblivion in much shorter time, and a far less cost. As such, the exposure becomes more attractive to concerted efforts of those whom may find use for the potentially extracted information, if you catch my drift... ???? I agree that there is as of now only a increase in level of concern, but certainly no need to panic yet. However the longer no concerted effort in addressing this now increased level of concern as I have been haring from some in the legal circles, the larger the exposure and impact becomes sooner rather than later. Eric Rescorla wrote: > According to Bruce Schneier, Wang, Yin, and Yu have made some > very substantial progress in attacking SHA-1. > > http://www.schneier.com/blog/archives/2005/02/sha1_broken.html > > The headline claim is the ability to find a collision in > SHA-1 in 2^69 operations. Here's a somewhat revised version > of my post after the MD5 attacks last year. > > USES OF HASH FUNCTIONS > We use hash algorithms in a bunch of different contexts. At minimum: > > 1. Digital signatures (you sign the hash of a message). > (a) On messages (e.g. S/MIME). > (b) On certificates. > (c) In authentication primitives (e.g., SSH) > 2. As MAC functions (e.g. HMAC) > 3. As authentication functions (e.g. CRAM-MD5) > 4. As key generation functions (e.g. SSL or IPsec PRF) > > THE POTENTIAL ATTACKS > The only situation in which the current attacks definitely apply is > (1). The general problem is illustrated by the following scenario. > Alice and Bob are negotiating a contract. Alice generates two > messages: > > M = "Alice will pay Bob $500/hr" > M' = "Alice will pay Bob $50/hr" [0] > > Where H(M) = H(M'). > > She gets Bob to sign M (and maybe signs it herself). Then when it > comes time to pay Bob, she whips out M' and says "I only owe > $50/hr", which Bob has also signed (remember that you sign the > hash of the message). > > So, this attack threatens non-repudiation or any kind of third > party verifiability. Another, slightly more esoteric, case is > certificates. Remember that a certificate is a signed message > from the CA containing the identity of the user. So, Alice > generates two certificate requests: > > R = "Alice.com, Key=X" > R' = "Bob.com, Key=Y" > > Such that H(R) = H(R') (I'm simplifying here). > > When the CA signs R, it's also signing R', so Alice can present > her new "Bob" certificate and pose as Bob. It's not clear that > this attack can work in practice because Alice doesn't control > the entire cert: the CA specifies the serial number. > > This attack is especially difficult to mount at the current > security level of SHA-1 because you have to know the contents > of the certificate at the time you start generating the colliding > pair. Because that process takes 2^69 operations, you're > probably talking days to weeks and predicting the exact > next serial number over that time span is not going to be easy. > If VeriSign and other CAs add just a very small bit of randomness > to their certs, they should be able to defend against it. > > Remember, also, that there are other ways to get false certs > if you're willing to expend the amount of money represented > by 2^69 operations. > > WHAT'S SAFE? > First, anything that's already been signed should be safe. If you > stop using MD5 today, nothing you signed already puts you at risk. > > There is probably no risk to two party SSH/SSL-style authentication > handshakes. > > It's believed that HMAC is secure against this attack (according to Hugo > Krawczyk, the designer) so the modern MAC functions should all be > secure. > > When this happened to MD5, I worried a bit about CRAM-MD5 and HTTP Digest. > They're not as well designed as HMAC. I've done a little thinking about how > to attack them and not come up with anything, but there's no guarantee. > But again, you'd need to expend a truly enormous amount of CPU power. > > The key generation PRFs should be safe. > > NEXT STEPS > This isn't a catastrophe, but we need to start planning for the future. > (warning, slightly heavy sledding ahead). > > The bad news is that there is no standard function that is guaranteed > to be more secure. In particular, we can't really be confident that > SHA-256 is going to be stronger. > > Here are a few alternatives: > Randomized hashing: The whole reason why this attack works is that > the attacker knows the exact message you're going to hash. If you > prefix the message with a random value, this effectively defeats > the attack. So, when you sign a message you would sign > H(random || message) instead of H(message). In particular, > CAs should immediately start using unpredictable serial numbers. [1] > Note, however, that this simple variant only works against the > attack where the relying party generates the colliding pairs. > If the attesting party does then they can shoose whatever > randomness they want. However, a variant in which the parties > jointly choose the random seed does work. > > A non-MDx-based hash function: All of the major standard hash functions > ultimately derive from MD4. It's possible to design hash functions > based on block ciphers (see http://dimacs.rutgers.edu/Workshops/Practice/slides/shrimpton.ppt) for an overview. Unfortunately, as I understand it > you can't prove security for these constructions in a realistic > model of the underlying algorithm. However, there's some hope > that you would have to make a pretty serious dent in that block > cipher in order to break the hash. > > Strangely enough, it's actually easier to specify a new hash function > than it is to move to randomized hashing. At the end of the day, > we'll probably want to do both because randomized hashing provides > protection against this kind of attack in general, regardless of > the status of the hash function. > > Here's one non-alternative: > Concatenation: The obvious thing to do is to take a SHA-1 and an > MD5 and concatenate them on the theory that this makes things > harder. Unfortunately, Joux's CRYPTO 2004 paper on multicollisions > suggests that this doesn't make things anywhere near as much harder > as you would expect. > > -Ekr > > [0] In practice, the messages might not be this similar, but there > turn out to be lots of opportunities to make subtle changes in any > text message. > > [1] It's easy to make these monotonically increasing. Just use > Counter || random > > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From phoffman@imc.org Fri Feb 18 11:32:03 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j1IGW15j010636 for ; Fri, 18 Feb 2005 11:32:01 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) j1IGVsLZ008429 for ; Fri, 18 Feb 2005 11:31:54 -0500 (EST) Received: from [10.20.30.249] (dsl2-63-249-109-246.cruzio.com [63.249.109.246]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1IGVlti038000; Fri, 18 Feb 2005 08:31:53 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1108702868.51832.1163.camel@unknown.hamachi.org> References: <20050217154525.466502850B@sierra.rtfm.com> <1108702868.51832.1163.camel@unknown.hamachi.org> Date: Fri, 18 Feb 2005 08:31:45 -0800 To: Bill Sommerfeld From: Paul Hoffman Subject: Re: [saag] Another bad day at the hash function factory Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.144288 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 18 Feb 2005 16:32:04 -0000 At 12:01 AM -0500 2/18/05, Bill Sommerfeld wrote: >On Thu, 2005-02-17 at 23:03, Paul Hoffman wrote: >> >So, this attack threatens non-repudiation or any kind of third >> >party verifiability. >> >> General question: do we have any protocols in the IETF where this is >> relevant? > >yes. third party verifiability is key to most uses of certificates. > >if you can find a collision like: > > M = "Key X belongs to asra42fcxaafs51ijax.com" >and > M' = "Key X belongs to paypal.com and asdlfadskjasdfipoupds.com" > >(encoded as X.509 certs) > >register the garbage domain names in M, get a trusted CA with >predictable serial numbers >to sign them, and poof you're in business as paypal.com ... That's a valid concern, but it is not a non-repduiation concern. That comes under Eric's second category, which could be titled "trust of third-party who didn't sign correctly". --Paul Hoffman, Director --Internet Mail Consortium From Mailer-Daemon@adelaidebank.com.au Fri Feb 18 12:00:55 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j1IH0s5j010858 for ; Fri, 18 Feb 2005 12:00:54 -0500 (EST) Received: from mail.adelaidebank.com.au (wwwproxy.adelaidebank.com.au [203.33.102.2])j1IH0iPl014709 for ; Fri, 18 Feb 2005 12:00:45 -0500 (EST) X-SEF-NDR-A4CDD3E6-186A-4406-A61E-2779D86E16D1: 1 X-SEF-A4CDD3E6-186A-4406-A61E-2779D86E16D1: 1 Received: from Unknown [172.17.5.100] by mail.adelaidebank.com.au - SurfControl E-mail Filter (5.0); Sat, 19 Feb 2005 03:30:43 +1130 Received: from ABDOMAIN-MTA by adelaidebank.com.au with Novell_GroupWise; Sat, 19 Feb 2005 03:30:43 +1030 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Date: Sat, 19 Feb 2005 03:30:24 +1030 From: "Paul DEWSNAP" Sender: Postmaster@adelaidebank.com.au Errors-To: Postmaster@adelaidebank.com.au To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.721386 Subject: [saag] Re: saag Digest, Vol 25, Issue 10 (Out of Office) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: pdewsnap@adelaidebank.com.au List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 18 Feb 2005 17:00:56 -0000 I am out of the office until Wednesday 23 Feb 05. Your email has not been forwarded. If this matter is urgent please contact Rob McKeon ext. 6738. Regards, Paul >>> saag 02/19/05 03:30 >>> Send saag mailing list submissions to saag@mit.edu To subscribe or unsubscribe via the World Wide Web, visit https://jis.mit.edu/mailman/listinfo/saag or, via email, send a message with subject or body 'help' to saag-request@mit.edu You can reach the person managing the list at saag-owner@mit.edu When replying, please edit your Subject line so it is more specific than "Re: Contents of saag digest..." ____________________________________________________________________ This e-mail and any files transmitted with it are confidential and are only for the use of the person to whom they are addressed. If you are not the intended recipient, you are hereby notified that any use, dissemination, forwarding, printing, copying or dealing in any way whatsoever with this e-mail is strictly prohibited. If you have received this e-mail in error, please reply to us immediately and delete the document. It is the recipient's duty to virus scan and otherwise test the enclosed information before using the information or loading attached files onto any computer system. Adelaide Bank Ltd does not warrant that the information contained in this e-mail is free from viruses, defects, errors, interception or interference. Any views expressed in this message are those of the individual sender, except where that sender specifically states them to be the views of Adelaide Bank Ltd. ____________________________________________________________________ From phoffman@imc.org Fri Feb 18 15:59:28 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j1IKxR5j012743 for ; Fri, 18 Feb 2005 15:59:27 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) j1IKxKxr012033 for ; Fri, 18 Feb 2005 15:59:21 -0500 (EST) Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1IKxJ47060667 for ; Fri, 18 Feb 2005 12:59:19 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20050217154525.466502850B@sierra.rtfm.com> Date: Fri, 18 Feb 2005 12:59:12 -0800 To: saag@mit.edu From: Paul Hoffman Subject: Re: [saag] Another bad day at the hash function factory Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000001 Spam-Alum-Time: 0.924297 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 18 Feb 2005 20:59:30 -0000 [[ Replying to my own message ]] >>So, this attack threatens non-repudiation or any kind of third >>party verifiability. > >General question: do we have any protocols in the IETF where this is >relevant? We seem to take on the world's burdens, including >non-repudiation, but we don't have those burdens in our own >protocols. It was pointed out to me offline that the IETF has at least one such protocol: EDIINT. One embodiment is RFC 3335, another is draft-ietf-ediint-as2, in the RFC Editor's queue. --Paul Hoffman, Director --Internet Mail Consortium From djb-dsn-1108764566.57187@cr.yp.to Fri Feb 18 17:09:09 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j1IM975j013186 for ; Fri, 18 Feb 2005 17:09:07 -0500 (EST) Received: from stoneport.math.uic.edu (stoneport.math.uic.edu [131.193.178.160])j1IM8xVe007189 for ; Fri, 18 Feb 2005 17:08:59 -0500 (EST) Received: (qmail 57188 invoked by uid 1016); 18 Feb 2005 22:09:26 -0000 Date: 18 Feb 2005 22:09:26 -0000 Message-ID: <20050218220926.57187.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: saag@mit.edu, cfrg@ietf.org Subject: Re: [saag] Re: [Cfrg] Re: universal MACs References: <151A63B4E33B4F49896AC6D1BA788A6E15C57F@EXCHVS2.louisville.stortek.com> <20040926155422.1F55F1AE84@berkshire.research.att.com> <20040926195031.59299.qmail@cr.yp.to> <20041102205520.89918.qmail@cr.yp.to> <20050114065836.57336.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.222498 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 18 Feb 2005 22:09:09 -0000 I wrote, a month ago: > As a followup: The Poly1305-AES paper will appear in the Fast Software > Encryption 2005 proceedings. Today I've posted http://cr.yp.to/mac.html > with C API details, a reference implementation, and some tests. As a further followup: I've posted my poly1305aes library, a very fast public-domain implementation of Poly1305-AES, including tuning for the Athlon, Pentium, PowerPC, and UltraSPARC. Sample timings: Poly1305(16-byte message): 693 Athlon cycles HMAC-MD5(16-byte message): openssl speed hmac says ~2700 Athlon cycles Poly1305(16-byte message): 800 UltraSPARC-III cycles HMAC-MD5(16-byte message): ~2200 UltraSPARC-III cycles Poly1305(1024-byte message): 3824 Athlon cycles HMAC-MD5(1024-byte message): ~12400 Athlon cycles Poly1305(1024-byte message): 5541 UltraSPARC-III cycles HMAC-MD5(1024-byte message): ~8600 UltraSPARC-III cycles You can find the library at http://cr.yp.to/mac.html, along with comprehensive benchmarks. If you're interested in further announcements, join the poly1305 mailing list. I should note that the library includes new AES code that achieves state-of-the-art speed while resisting L1-cache timing attacks. The code is limited to the case I care about in Poly1305-AES (no precomputation, no decryption) but should still be of interest to other AES users. It might even reduce my speed advantage over other secure CW MACs. :-) ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From armando@armando.mrg.dist.unige.it Mon Feb 7 06:11:35 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j17BBY5j004499 for ; Mon, 7 Feb 2005 06:11:34 -0500 (EST) Received: from armando.mrg.dist.unige.it (armandobook.mrg.dist.unige.it [130.251.7.211])j17BBNmp020406; Mon, 7 Feb 2005 06:11:24 -0500 (EST) Received: from armando.mrg.dist.unige.it (armando [127.0.0.1]) j17BBNbR004745; Mon, 7 Feb 2005 12:11:23 +0100 Received: from armando (armando@localhost)j17BBMba004740; Mon, 7 Feb 2005 12:11:22 +0100 Message-Id: <200502071111.j17BBMba004740@armando.mrg.dist.unige.it> To: Sam Hartman , Russell Housley X-Mailer: MH-E 7.4.3; nmh 1.0.4; GNU Emacs 21.2.1 From: Alessandro Armando X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.894166 X-Mailman-Approved-At: Sun, 27 Feb 2005 01:15:25 -0500 cc: secdir@mit.edu cc: saag@mit.edu Subject: [saag] IETF Meeting Minneapolis, saag: slot for AVISPA X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: Alessandro Armando List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Date: Mon, 07 Feb 2005 11:11:36 -0000 X-Original-Date: Mon, 07 Feb 2005 12:11:22 +0100 X-List-Received-Date: Mon, 07 Feb 2005 11:11:36 -0000 Russ, Sam, this is a request to obtain a slot during the next open directorate meeting at the 62nd IETF in Minneapolis to present the current status of the results of the EU-Project AVISPA (Automated Validation of Internet Security Protocols and Applications), see http://www.avispa-project.org/. This will be in a sense a continuation of our presentation at the IETF-59 Seoul meeting, where we proposed to verify the security of Internet Protocols (with focus IETF) and to provide free tools for formal verification. I include the link to the draft versions of three key deliverables of AVISPA describing the current results of the project plus a short paper describing the AVISPA Tool. We think that they will also of interest for the general Internet community: http://www.avispa-project.org/Internal/IETF/ User Name: avispa-ietf Pwd: d61list The AVISPA Tool can be freely tried at the URL: http://www.avispa-project.org/software.html There are still several things that must be done in AVISPA: the user interface must become simpler, the semantics of the formal language must be clearer for non-specialists, we might need to change our specification of some protocols (for this we need feedback from protocol designers or implementers about if our modelling of the single protocols is correct or we have overseen something). We have to make our tools readily available to the designer of a protocol so that he can use a simple push-button, industrial-strength technology to search for attacks on his design. This is our commitment with the EU. This is why we need the need the discussion with the IETF security community. At the same time we sincerely believe that it will be of interest to you and of help to the Internet community in general. Best regards, Alessandro Armando -- Alessandro Armando e-mail: armando@dist.unige.it Associate Professor http://www.ai.dist.unige.it/armando DIST - Universita' di Genova, phone: +39-0103532216 viale Causa 13, fax: +39-0103532948 16145 GENOVA, ITALY mobile: +39-3281003201 From armando@armando.mrg.dist.unige.it Mon Feb 7 11:01:05 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j17G135j006144 for ; Mon, 7 Feb 2005 11:01:03 -0500 (EST) Received: from armando.mrg.dist.unige.it (armandobook.mrg.dist.unige.it [130.251.7.211])j17G0sH5000718; Mon, 7 Feb 2005 11:00:54 -0500 (EST) Received: from armando.mrg.dist.unige.it (armando [127.0.0.1]) j17G0rbR005388; Mon, 7 Feb 2005 17:00:53 +0100 Received: from armando (armando@localhost)j17G0r0V005383; Mon, 7 Feb 2005 17:00:53 +0100 Message-Id: <200502071600.j17G0r0V005383@armando.mrg.dist.unige.it> To: Sam Hartman In-Reply-To: Message from Sam Hartman of "Mon, 07 Feb 2005 10:29:00 EST." <878y60v16r.fsf@luminous.mit.edu> X-Mailer: MH-E 7.4.3; nmh 1.0.4; GNU Emacs 21.2.1 From: Alessandro Armando X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.006950 Spam-Alum-Time: 0.980598 X-Mailman-Approved-At: Sun, 27 Feb 2005 01:15:25 -0500 cc: secdir@mit.edu cc: saag@mit.edu Subject: [saag] Re: IETF Meeting Minneapolis, saag: slot for AVISPA X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: Alessandro Armando List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Date: Mon, 07 Feb 2005 16:01:06 -0000 X-Original-Date: Mon, 07 Feb 2005 17:00:53 +0100 X-List-Received-Date: Mon, 07 Feb 2005 16:01:06 -0000 Sam, > In the interests of scheduling, it would be useful to know how much > time you need. How much time would you like ideally? What is the > minimum time for your presentation to be useful? I would say: Minimum: 20min Ideally: 30min alessandro -- Alessandro Armando e-mail: armando@dist.unige.it Associate Professor http://www.ai.dist.unige.it/armando DIST - Universita' di Genova, phone: +39-0103532216 viale Causa 13, fax: +39-0103532948 16145 GENOVA, ITALY mobile: +39-3281003201 From housley@vigilsec.com Tue Mar 1 18:24:14 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j21NOC5j014756 for ; Tue, 1 Mar 2005 18:24:12 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) j21NO4pb018554 for ; Tue, 1 Mar 2005 18:24:05 -0500 (EST) Received: (qmail 30563 invoked by uid 0); 1 Mar 2005 23:23:57 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.140.140) by woodstock.binhost.com with SMTP; 1 Mar 2005 23:23:57 -0000 Message-Id: <6.2.0.14.2.20050301182119.03da5a30@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 01 Mar 2005 18:24:00 -0500 To: saag@mit.edu, ietf-pkix@imc.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000002 Spam-Alum-Time: 1.392057 Subject: [saag] X.509 certificate collision, via MD5 collisions X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 01 Mar 2005 23:24:15 -0000 I have not had an opportunity to review this document yet, but the findings need to be shared with the whole Internet security community. >We announce a method for the construction of pairs of valid X.509 >certificates in which the "to >be signed" parts form a collision for the MD5 hash function. As a result >the issuer signatures >in the certificates will be the same when the issuer uses MD5 as its hash >function. http://eprint.iacr.org/2005/067 From phoffman@imc.org Tue Mar 1 19:08:46 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2208i5j015029 for ; Tue, 1 Mar 2005 19:08:44 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) j2208boY026646 for ; Tue, 1 Mar 2005 19:08:37 -0500 (EST) Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2208XKs045568; Tue, 1 Mar 2005 16:08:36 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.0.14.2.20050301182119.03da5a30@mail.binhost.com> References: <6.2.0.14.2.20050301182119.03da5a30@mail.binhost.com> Date: Tue, 1 Mar 2005 16:08:30 -0800 To: Russ Housley , saag@mit.edu, ietf-pkix@imc.org From: Paul Hoffman Subject: Re: [saag] X.509 certificate collision, via MD5 collisions Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.552671 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 02 Mar 2005 00:08:47 -0000 At 6:24 PM -0500 3/1/05, Russ Housley wrote: >I have not had an opportunity to review this document yet, but the >findings need to be shared with the whole Internet security >community. > >>We announce a method for the construction of pairs of valid X.509 >>certificates in which the "to >>be signed" parts form a collision for the MD5 hash function. As a >>result the issuer signatures >>in the certificates will be the same when the issuer uses MD5 as >>its hash function. > >http://eprint.iacr.org/2005/067 From the description in the paper, it appears that step 1 requires that the template for the certificate must be known before you create the two RSA keys. If that is true, then a CA who uses long serial numbers either randomly or based on a secret would automatically foil this attack. (I could be misreading the requirement, of course.) --Paul Hoffman, Director --Internet Mail Consortium From crawdad@fnal.gov Wed Mar 2 10:28:15 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j22FSD5j020659 for ; Wed, 2 Mar 2005 10:28:13 -0500 (EST) Received: from mailgw1.fnal.gov (mailgw1.fnal.gov [131.225.111.11]) j22FS6QZ007004 for ; Wed, 2 Mar 2005 10:28:07 -0500 (EST) Received: from mailav2.fnal.gov (mailav2.fnal.gov [131.225.111.20]) by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with SMTP id <0ICQ00C2OCHLGR@mailgw1.fnal.gov> for saag@mit.edu; Wed, 02 Mar 2005 09:03:25 -0600 (CST) Received: from mailgw2.fnal.gov ([131.225.111.12]) by mailav2.fnal.gov (SAVSMTP 3.1.7.47) with SMTP id M2005030209032503690 for ; Wed, 02 Mar 2005 09:03:25 -0600 Received: from conversion-daemon.mailgw2.fnal.gov by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) id <0ICQ00I01C7X53@mailgw2.fnal.gov> (original mail from crawdad@fnal.gov) for saag@mit.edu; Wed, 02 Mar 2005 09:03:24 -0600 (CST) Received: from [131.225.88.29] (skuld.dhcp.fnal.gov [131.225.88.29]) by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0ICQ00JANCHMP4@mailgw2.fnal.gov>; Wed, 02 Mar 2005 09:03:23 -0600 (CST) Date: Wed, 02 Mar 2005 09:03:21 -0600 From: Matt Crawford Subject: Re: [saag] X.509 certificate collision, via MD5 collisions In-reply-to: To: saag@mit.edu, ietf-pkix@imc.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <6.2.0.14.2.20050301182119.03da5a30@mail.binhost.com> X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.929122 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 02 Mar 2005 15:28:16 -0000 On Mar 1, 2005, at 18:08, Paul Hoffman wrote: >> http://eprint.iacr.org/2005/067 > > From the description in the paper, it appears that step 1 requires > that the template for the certificate must be known before you create > the two RSA keys. If that is true, then a CA who uses long serial > numbers either randomly or based on a secret would automatically foil > this attack. (I could be misreading the requirement, of course.) What's more, the two certificates are identical in every field before the public RSA modulus -- including the SubjectDN. This is less interesting than it might be. But clearly it would be foolish to believe that collisions with different SubjectDNs won't follow soon. From ekr@rtfm.com Wed Mar 2 10:42:38 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j22Fga5j020794 for ; Wed, 2 Mar 2005 10:42:36 -0500 (EST) Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) j22FgSQZ001203 for ; Wed, 2 Mar 2005 10:42:29 -0500 (EST) Received: by romeo.rtfm.com (Postfix, from userid 1001) id C6E2817050; Wed, 2 Mar 2005 07:46:37 -0800 (PST) To: Matt Crawford Subject: Re: [saag] X.509 certificate collision, via MD5 collisions References: <6.2.0.14.2.20050301182119.03da5a30@mail.binhost.com> From: Eric Rescorla Date: Wed, 02 Mar 2005 07:46:37 -0800 In-Reply-To: (Matt Crawford's message of "Wed, 02 Mar 2005 09:03:21 -0600") Message-ID: <868y563vaa.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.453434 cc: ietf-pkix@imc.org cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: EKR List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 02 Mar 2005 15:42:39 -0000 Matt Crawford writes: > On Mar 1, 2005, at 18:08, Paul Hoffman wrote: > >>> http://eprint.iacr.org/2005/067 >> >> From the description in the paper, it appears that step 1 requires >> that the template for the certificate must be known before you >> create the two RSA keys. If that is true, then a CA who uses long >> serial numbers either randomly or based on a secret would >> automatically foil this attack. (I could be misreading the >> requirement, of course.) > > What's more, the two certificates are identical in every field before > the public RSA modulus -- including the SubjectDN. This is less > interesting than it might be. But clearly it would be foolish to > believe that collisions with different SubjectDNs won't follow soon. That's probably true, but they're likely to be basically random. In Wang attack is that the colliding values aren't very controllable... -Ekr From jwkckid1@ix.netcom.com Wed Mar 2 23:37:34 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j234bX5j025687 for ; Wed, 2 Mar 2005 23:37:33 -0500 (EST) Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226])j234bQR8010315 for ; Wed, 2 Mar 2005 23:37:26 -0500 (EST) Received: from 1cust185.tnt59.dfw5.da.uu.net ([67.203.43.185] helo=ix.netcom.com) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1D6i5U-0007cr-00; Wed, 02 Mar 2005 23:37:24 -0500 Message-ID: <4226AF2A.F04117A5@ix.netcom.com> Date: Wed, 02 Mar 2005 22:31:10 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Matt Crawford Subject: Re: [saag] X.509 certificate collision, via MD5 collisions References: <6.2.0.14.2.20050301182119.03da5a30@mail.binhost.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.590544 cc: aba isc list cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 03 Mar 2005 04:37:35 -0000 Matt and all, I completely agree with youc conclusion, below. Thanks for beating me to it. Matt Crawford wrote: > On Mar 1, 2005, at 18:08, Paul Hoffman wrote: > > >> http://eprint.iacr.org/2005/067 > > > > From the description in the paper, it appears that step 1 requires > > that the template for the certificate must be known before you create > > the two RSA keys. If that is true, then a CA who uses long serial > > numbers either randomly or based on a secret would automatically foil > > this attack. (I could be misreading the requirement, of course.) > > What's more, the two certificates are identical in every field before > the public RSA modulus -- including the SubjectDN. This is less > interesting than it might be. But clearly it would be foolish to > believe that collisions with different SubjectDNs won't follow soon. > > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From hartmans@MIT.EDU Mon Mar 7 11:04:46 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j27G4j5j004508 for ; Mon, 7 Mar 2005 11:04:45 -0500 (EST) Received: from cz.mit.edu (m1f3e36d0.tmodns.net [208.54.62.31]) j27G4dul013614 for ; Mon, 7 Mar 2005 11:04:41 -0500 (EST) Received: by cz.mit.edu (Postfix, from userid 8042) id CB634E0063; Mon, 7 Mar 2005 10:58:50 -0500 (EST) To: ietf@ietf.org From: Sam Hartman Date: Mon, 07 Mar 2005 10:58:50 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: message/rfc822 Content-Disposition: inline X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.746647 cc: saag@mit.edu Subject: [saag] [Russ Housley] MD5 and SHA-1 Status X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 07 Mar 2005 16:04:48 -0000 Two significant announcements have been made in the past month. MIME-Version: 1.0 First, at the RSA Conference last month, an attack against SHA-1 was announced. See http://www.schneier.com/blog/archives/2005/02/sha1_broken.html for a summary of the announcement. The attack, if it is every written up, published, and verified, is a 2^69 work factor. SHA-1 was designed to have a 2^80 work factor, so this is a significant reduction, but we have time to figure out the best course of action. Second, Lenstra et al announced a method for the construction of pairs of valid X.509 certificates in which the "to be signed" parts form a collision for the MD5 hash function. As a result the issuer signatures in the certificates will be the same when the issuer uses MD5 as its hash function. See http://eprint.iacr.org/2005/067 This work builds on an attack on MD5 that was announced about a year ago. Several working groups depend on one-way hash functions. Yet, we do not think that this topic should consume huge amounts of time in every one of these working groups. Therefore, we will be discussing this topic at SAAG on Thursday. While it is clear that this topic will require some IETF action, it is not yet a crisis. That is, we can walk to a solution, there is no need to run. If you are interested in this topic, please join the SAAG discussion on Thursday. IETF Security Area Directors, Russ Housley Sam Hartman From ben@algroup.co.uk Wed Mar 2 07:39:07 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j22Cd65j019671 for ; Wed, 2 Mar 2005 07:39:06 -0500 (EST) Received: from mail.links.org (mail.links.org [217.155.92.109]) j22CcwPg028304 for ; Wed, 2 Mar 2005 07:38:59 -0500 (EST) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 3927C33C33; Wed, 2 Mar 2005 12:38:58 +0000 (GMT) Message-ID: <4225B36D.8080406@algroup.co.uk> Date: Wed, 02 Mar 2005 12:37:01 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman Subject: Re: [saag] X.509 certificate collision, via MD5 collisions References: <6.2.0.14.2.20050301182119.03da5a30@mail.binhost.com> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.905712 X-Mailman-Approved-At: Wed, 09 Mar 2005 12:20:18 -0500 cc: ietf-pkix@imc.org cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 02 Mar 2005 12:39:08 -0000 Paul Hoffman wrote: > > At 6:24 PM -0500 3/1/05, Russ Housley wrote: > >> I have not had an opportunity to review this document yet, but the >> findings need to be shared with the whole Internet security community. >> >>> We announce a method for the construction of pairs of valid X.509 >>> certificates in which the "to >>> be signed" parts form a collision for the MD5 hash function. As a >>> result the issuer signatures >>> in the certificates will be the same when the issuer uses MD5 as its >>> hash function. >> >> >> http://eprint.iacr.org/2005/067 > > > From the description in the paper, it appears that step 1 requires that > the template for the certificate must be known before you create the two > RSA keys. If that is true, then a CA who uses long serial numbers either > randomly or based on a secret would automatically foil this attack. (I > could be misreading the requirement, of course.) I believe that is correct. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 rgm-sec@htt-consult.com Thu Mar 10 14:00:08 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2AJ065j005669 for ; Thu, 10 Mar 2005 14:00:06 -0500 (EST) Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) j2AIxxhW025170 for ; Thu, 10 Mar 2005 13:59:59 -0500 (EST) Received: from port3490-new.htt-consult.com ([65.84.78.209]) by htt-consult.com ; Thu, 10 Mar 2005 13:59:55 -0500 Message-Id: <6.2.1.2.2.20050310125728.03abdb80@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 10 Mar 2005 12:59:33 -0600 To: saag@mit.edu From: Robert Moskowitz In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_631107134==.ALT" X-Rcpt-To: X-Spam-Score: -4.075 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000059 Spam-Alum-Time: 1.134378 Subject: [saag] France puts a damper on flaw hunting X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 10 Mar 2005 19:00:09 -0000 --=====================_631107134==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed http://news.com.com/France%20puts%20a%20damper%20on%20flaw-hunting/2100-7350_3-5606306.html Researchers who reverse-engineer software to discover programming flaws can no longer legally publish their findings in France, after a court fined a security expert on Tuesday. Probably France will only prosecute against desclosures published in French? :) Robert Moskowitz ICSAlabs/A Division of TruSecure Corporation Security Interest EMail: rgm-sec@htt-consult.com --=====================_631107134==.ALT Content-Type: text/html; charset="us-ascii" http://news.com.com/France%20puts%20a%20damper%20on%20flaw-hunting/2100-7350_3-5606306.html

Researchers who reverse-engineer software to discover programming flaws can no longer legally publish their findings in France, after a court fined a security expert on Tuesday.

Probably France will only prosecute against desclosures published in French?   :)


Robert Moskowitz
ICSAlabs/A Division of TruSecure Corporation
Security Interest EMail: rgm-sec@htt-consult.com --=====================_631107134==.ALT-- From eludom@gmail.com Thu Mar 10 14:58:12 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2AJwB5j006056 for ; Thu, 10 Mar 2005 14:58:11 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) j2AJvrhW008683 for ; Thu, 10 Mar 2005 14:57:53 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 40so505060wri for ; Thu, 10 Mar 2005 11:57:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=hVHyubS3iHUIaEkK7GAROdOR7ZzgI94bcjih1HkkhbYyeDFXAosTQiVG5r6iaJv4b9KgM2SjGdrf7G14DzICEZ4/k3zmqWQ8vze6gKtXK8jleojas3gb3IVYRQuqbHIcjBT+TFNM3g5DTcmzw4cPU/EWLNdPLrTbR9XKJOfK0MY= Received: by 10.54.17.19 with SMTP id 19mr408264wrq; Thu, 10 Mar 2005 11:57:53 -0800 (PST) Received: by 10.54.20.78 with HTTP; Thu, 10 Mar 2005 11:57:53 -0800 (PST) Message-ID: Date: Thu, 10 Mar 2005 13:57:53 -0600 From: George Jones To: Robert Moskowitz Subject: Re: [saag] France puts a damper on flaw hunting In-Reply-To: <6.2.1.2.2.20050310125728.03abdb80@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <6.2.1.2.2.20050310125728.03abdb80@localhost> X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.547689 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: gmj@pobox.com List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 10 Mar 2005 19:58:13 -0000 On Thu, 10 Mar 2005 12:59:33 -0600, Robert Moskowitz wrote: > http://news.com.com/France%20puts%20a%20damper%20on%20flaw-hunting/2100-7350_3-5606306.html > > Researchers who reverse-engineer software to discover programming flaws can > no longer legally publish their findings in France, after a court fined a > security expert on Tuesday. Methinks this could be a problem for nessus :-( ---George Jones From wpolk@nist.gov Thu Mar 10 17:21:17 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2AMLG5j007038 for ; Thu, 10 Mar 2005 17:21:16 -0500 (EST) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) j2AML83M020308 for ; Thu, 10 Mar 2005 17:21:08 -0500 (EST) Received: from real1.localdomain ([192.168.2.10]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j2AML5D1025570 for ; Thu, 10 Mar 2005 17:21:05 -0500 Received: from real1.localdomain (real1.localdomain [127.0.0.1]) by real1.localdomain (8.12.8/8.12.8) with ESMTP id j2AML5iq001747 for ; Thu, 10 Mar 2005 17:21:05 -0500 Received: (from apache@localhost) by real1.localdomain (8.12.8/8.12.8/Submit) id j2AML5AH001745 for saag@mit.edu; Thu, 10 Mar 2005 17:21:05 -0500 Received: from wireless-130-129-131-249.ietf62.ietf.org (wireless-130-129-131-249.ietf62.ietf.org [130.129.131.249]) by webmail.nist.gov (IMP) with HTTP for ; Thu, 10 Mar 2005 17:21:05 -0500 Message-ID: <1110493265.4230c85174c85@webmail.nist.gov> Date: Thu, 10 Mar 2005 17:21:05 -0500 From: wpolk@nist.gov To: saag@mit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 130.129.131.249 X-NIST-MailScanner: Found to be clean X-MailScanner-From: wpolk@nist.gov X-Spam-Score: -4.74 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.535933 Subject: [saag] FYI: NIST posts CMAC for public comment X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 10 Mar 2005 22:21:18 -0000 FYI, The Draft NIST Special Publication 800-38B "Recommendation for Block Cipher Modes of Operation: the CMAC Mode for Authentication" was posted for public review today at: http://csrc.nist.gov/publications/drafts.html#sp800-38B This Recommendation specifies the CMAC mode of operation for symmetric block ciphers. CMAC is a cipher-based message authentication code algorithm based on an approved block cipher such as the AES algorithm or TDEA. Additional information on this document, related publications, and the development of modes of operation in general is available at the modes home page: http://nist.gov/modes Comments on SP 800-38B should be submitted to . NIST will be accepting comments on SP 800-38B until April 25, 2005. Thanks, Tim From Mailer-Daemon@adelaidebank.com.au Fri Mar 11 12:01:58 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2BH1u5j013821 for ; Fri, 11 Mar 2005 12:01:57 -0500 (EST) Received: from mail.adelaidebank.com.au (wwwproxy.adelaidebank.com.au [203.33.102.2])j2BH1l0U027822 for ; Fri, 11 Mar 2005 12:01:48 -0500 (EST) X-SEF-NDR-A4CDD3E6-186A-4406-A61E-2779D86E16D1: 1 X-SEF-A4CDD3E6-186A-4406-A61E-2779D86E16D1: 1 Received: from Unknown [172.17.5.100] by mail.adelaidebank.com.au - SurfControl E-mail Filter (5.0); Sat, 12 Mar 2005 03:31:07 +1130 Received: from ABDOMAIN-MTA by adelaidebank.com.au with Novell_GroupWise; Sat, 12 Mar 2005 03:31:06 +1030 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Date: Sat, 12 Mar 2005 03:30:44 +1030 From: "Paul DEWSNAP" Sender: Postmaster@adelaidebank.com.au Errors-To: Postmaster@adelaidebank.com.au To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -1.524 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.780795 Subject: [saag] Re: saag Digest, Vol 26, Issue 5 (Out of Office) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: pdewsnap@adelaidebank.com.au List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 11 Mar 2005 17:01:59 -0000 I am out of the office until Wednesday 16 March 05. Your email has not been forwarded. If this matter is urgent please contact James Schulze ext. 6285. Regards, Paul >>> saag 03/12/05 03:30 >>> Send saag mailing list submissions to saag@mit.edu To subscribe or unsubscribe via the World Wide Web, visit https://jis.mit.edu/mailman/listinfo/saag or, via email, send a message with subject or body 'help' to saag-request@mit.edu You can reach the person managing the list at saag-owner@mit.edu When replying, please edit your Subject line so it is more specific than "Re: Contents of saag digest..." ____________________________________________________________________ This e-mail and any files transmitted with it are confidential and are only for the use of the person to whom they are addressed. If you are not the intended recipient, you are hereby notified that any use, dissemination, forwarding, printing, copying or dealing in any way whatsoever with this e-mail is strictly prohibited. If you have received this e-mail in error, please reply to us immediately and delete the document. It is the recipient's duty to virus scan and otherwise test the enclosed information before using the information or loading attached files onto any computer system. Adelaide Bank Ltd does not warrant that the information contained in this e-mail is free from viruses, defects, errors, interception or interference. Any views expressed in this message are those of the individual sender, except where that sender specifically states them to be the views of Adelaide Bank Ltd. ____________________________________________________________________ From housley@vigilsec.com Wed Mar 16 11:07:26 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2GG7N5j023112 for ; Wed, 16 Mar 2005 11:07:23 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) j2GG7E7V004008 for ; Wed, 16 Mar 2005 11:07:14 -0500 (EST) Received: (qmail 15449 invoked by uid 0); 16 Mar 2005 16:04:55 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (63.148.158.5) by woodstock.binhost.com with SMTP; 16 Mar 2005 16:04:55 -0000 Message-Id: <6.2.0.14.2.20050316075639.04b07020@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 16 Mar 2005 07:59:38 -0500 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -4.481 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 2.388318 Subject: [saag] Draft IETF 62 SAAG Mnutes X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 16 Mar 2005 16:07:26 -0000 Here are the draft minutes. Please review them, and tell me about any corrections that are needed. Many thanks to Sean Turner for taking notes during the meeting. Russ = = = = = = = = = = Security Area Advisory Group (SAAG) IETF 62, Minneapolis, MN Minutes compiled by Sean Turner and Russ Housley Introduction Russ Housley presented the agenda: WG Reports BoF Reports Invited Presentations - AVISPA - OATH HOTP - MD5 and SHA-1 Status Open Microphone Working Group and BoF Reports Each working group or BoF that had a meeting at IETF 62 gave a very brief summary of the session. Please see the minutes for each of these sessions. The highlights are not repeated here. Reports were given by: INCH Enroll ISMS Kitten KINK KRB-WG MOBIKE MSEC OpenPGP PKI4IPsec PKIX SASL SecSH BTNS BoF AVISPA (See Armando-AVISPA.ppt) Alessandro Armando, from AI-Lab, DIST - University of Genova, Italy, gave a presentation on Automated Validation of Internet Security Protocols and Applications (AVISPA). It is a project funded by the EU. He covered: - The development of security protocols is out-pacing human ability to analyze them. - Tools are needed to support the analysis of these protocols. - Some protocol analyzers exist, but they do not support large protocols and each one has a unique language and user interface. - Want to develop a rich specification language, advanced techniques, integrated developer tools, and standard AVISPA Library. - Want to assess the practicality using AVISPA Tool. - There are four "backends" to do checks on protocols. - The High Level Protocol Specification Language (HLPSL) is role based language. - Tool can be accessed at www.avispa-project.org/web-interface. - AVISPA Library tested against a set of security problems with protocols that have been recently standardized by the IETF, uncovering 112 problems in 33 protocols. - There are four universities working together on the development. Comments and Questions/Answers C: Support for LINT-like applications, but there is a problem. The HLPSL representation of the protocol may not represent all of the English language details. The mathematical form may not actually capture the full protocol, especially checks. C: Found tool useful to apply different modeling tool. Interesting to make sure others can understand it. Formal methods and IETF standard writers use different styles. Bouncing it across both is helpful to make language more understandable. Q: TLS is a list of protocols that were checked with the tool; did you find the CBC attack to the Million-Message attack? A: No. Currently crypto operators are assumed to be flawless. Q: Are implementations being analyzed? A: No. The tool works on the protocol description, not an implementation of the protocol. Q: Does tool confirm that it is a correct implementation of the protocol using the test vectors in the specification? A: No, but that is an interesting thought. The One Time Password algorithm from OATH (the initiative for Open AuTHentication) (See dmraihi-oath-hotp.ppt) David M'Raihi, from Verisign, gave a presentation on the OATH one-time password algorithm. He covered: - Why? One-time passwords (OTP) are more secure than static passwords. OTP is easy, like two-factor authentication. - Several algorithms exist, but they are proprietary, so information is not available for peer review. - An open algorithm makes it possible for anyone to analyze. There is a freely available description and a reference implementation. - Requirements: usable, secure, implementation flexible, and economic. - Algorithm uses HMAC and SHA-1, which are both open and public. - Algorithm description: HOTP (Counter, Key) = Truncate (HMAC-SHA-1 (Counter, Key)) - The recently announced SHA-1 attacks cause no concerns in this algorithm. - About ten companies have implemented the algorithm, including software tokens, hardware tokens, and SIM cards. - Next Step: an open standard. Comments and Questions/Answers Q: How does this compare to RFC 2289, which specifies S/KEY? S/KEY is IETF standard, where an attack on the server does not allow the attacker to masquerade as the user. A: The OATH OTP does not have this property. If an attacker gets the key stored on the client or the server, then it can masquerade. However, S/KEY was not selected because of usability concerns. The amount of data that the user must type in an hardware token implementation is unacceptable. C: S/KEY and this have different UI. MD5 and SHA-1 Status (See ekr-digest-status.pdf) Eric Rescorla, from Network Resonance, gave a presentation on MD5 and SHA-1 and the recent attacks against them. He covered: - Terminology: -- Collision: Find M, M' such that H(M) = H(M') -- 1st preimage: Given X, find M such that H(M) = X -- 2nd preimage: Given M, find M' such that H(M') = H(M) - MD5 collision (practical). - SHA-1 in 2^69 operations (theory); when it should be 2^80 operations. - Certificates - Lenstra et al. demonstrate a pair of certificates with different public keys but the same hash. - None of these attacks allow you to compute preimage. - The collisions are not totally controllable; where the changed bits will be located depends on current hash state. - DO NOT panic! - These attacks do not affect key derivation functions (PRF), peer authentication protocols with non-repudiation (SSL, IPsec, SSH), message authentication (HMAC), challenge-response. - These attacks do affect non-repudiation, certificate issuance (only in special instances), and timestamps (maybe). - Since the CA has control over some of the fields in the certificate there are ways to thwart attacks based on these hash collision attacks. - DO NOT Panic, but we do need to create a plan for the future: -- SHA-224, something new? -- New randomized hash algorithms; in ASN.1 protocols one needs a random value in the algorithm identifier parameter. -- As a stop gap measure, randomize certificate serial numbers (or dates in the validity period). Comments and Questions/Answers C: Primitives should work without special rules. Better to use new functions or randomize SHA-1. C: CRL size increases if you increase size of serial numbers. C: Can add randomness buy adding a GUID to the subject name. C: NIST wants people to move beyond 80-bit strength by 2010. Given these new attacks, that transition may need to move forward. Q: Why SHA-224 and not SHA-256. A: It's just the next one on the list. Any larger one could be used. Q: Do we have new problems where we use a key for both encryption and signatures? Should we move it to dual keys? A: These attacks do not make matters any worse. Open Microphone Q: Need algorithm independence in all protocols. A: Yes. However, need to ensure there is not any multi-layer negotiation. Q: Some are proposing to use hash function to produce long-lived IDs. HIP is one example. What are the implications? A: There might not be a problem with this usage because there is not a third party. From hartmans@MIT.EDU Fri Mar 18 13:36:43 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2IIag5j010247 for ; Fri, 18 Mar 2005 13:36:42 -0500 (EST) Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) j2IIaZgV005373 for ; Fri, 18 Mar 2005 13:36:35 -0500 (EST) Received: by cz.mit.edu (Postfix, from userid 8042) id 301E5E0063; Fri, 18 Mar 2005 13:36:30 -0500 (EST) To: saag@mit.edu From: Sam Hartman Date: Fri, 18 Mar 2005 13:36:30 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.854052 Subject: [saag] media types for javascript X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 18 Mar 2005 18:36:43 -0000 --=-=-= Hi. I seem to recall years ago there was a strong objection to a media type request for Unix shell scripts. Today we're seeing a last call for the javascript media types. Personally I think the world has changed and that we actually probably do need media types for things like shell scripts, javascript, etc. But I thought I would forward this last call here so that people with different opinions could speak up. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.16-IPv6-Debian-2.1.16-10) with LMTP; Tue, 15 Mar 2005 16:33:57 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 8F0CD13259 for ; Tue, 15 Mar 2005 16:33:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBJWR-0007YO-Mc; Tue, 15 Mar 2005 16:24:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBJWP-0007YJ-Pb for ietf-announce@megatron.ietf.org; Tue, 15 Mar 2005 16:24:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20754 for ; Tue, 15 Mar 2005 16:24:11 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBJaJ-0000SV-2G for ietf-announce@ietf.org; Tue, 15 Mar 2005 16:28:16 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DBJWO-0005uG-9h for ietf-announce@ietf.org; Tue, 15 Mar 2005 16:24:12 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Tue, 15 Mar 2005 16:24:12 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: Last Call: 'Scripting Media Types' to Informational RFC X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-announce-bounces@ietf.org Errors-To: ietf-announce-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 MIME-Version: 1.0 The IESG has received a request from an individual submitter to consider the following document: - 'Scripting Media Types ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-04-12. The file can be obtained via http://www.ietf.org/internet-drafts/draft-hoehrmann-script-types-02.txt _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --=-=-=-- From sommerfeld@sun.com Fri Mar 18 14:43:29 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2IJhS5j010634 for ; Fri, 18 Mar 2005 14:43:28 -0500 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) j2IJhDgV021285; Fri, 18 Mar 2005 14:43:13 -0500 (EST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j2IJhCNV024119; Fri, 18 Mar 2005 11:43:12 -0800 (PST) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) ESMTP id j2IJhCOp018665; Fri, 18 Mar 2005 14:43:12 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2IJhB1f023982; Fri, 18 Mar 2005 14:43:11 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2IJhBxH023981; Fri, 18 Mar 2005 14:43:11 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: [saag] media types for javascript From: Bill Sommerfeld To: Sam Hartman In-Reply-To: References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1111174990.22852.234.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Fri, 18 Mar 2005 14:43:10 -0500 X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.555463 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 18 Mar 2005 19:43:31 -0000 On Fri, 2005-03-18 at 13:36, Sam Hartman wrote: > Hi. I seem to recall years ago there was a strong objection to a > media type request for Unix shell scripts. I may be misremembering but I have this vague recollection that what was objected to was not a media type for 'shell script' but the notion that an appropriate way to render such a media type was to feed it to a shell for immediate execution. You may think this is so obvious that nobody would try to do this. The IT department of a former employer of mine anctually *deployed* something along those lines to the employee base. They had even done a security review of the application they were deploying this way and completely failed to consider the threat to the clients running web browsers... - Bill From hartmans@MIT.EDU Fri Mar 18 14:47:44 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2IJlh5j010709 for ; Fri, 18 Mar 2005 14:47:43 -0500 (EST) Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) j2IJlagV026609 for ; Fri, 18 Mar 2005 14:47:36 -0500 (EST) Received: by cz.mit.edu (Postfix, from userid 8042) id 31B04E0077; Fri, 18 Mar 2005 14:47:30 -0500 (EST) To: Bill Sommerfeld Subject: Re: [saag] media types for javascript References: <1111174990.22852.234.camel@thunk> From: Sam Hartman Date: Fri, 18 Mar 2005 14:47:30 -0500 In-Reply-To: <1111174990.22852.234.camel@thunk> (Bill Sommerfeld's message of "Fri, 18 Mar 2005 14:43:10 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.717293 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 18 Mar 2005 19:47:45 -0000 >>>>> "Bill" == Bill Sommerfeld writes: Bill> On Fri, 2005-03-18 at 13:36, Sam Hartman wrote: >> Hi. I seem to recall years ago there was a strong objection to >> a media type request for Unix shell scripts. Bill> I may be misremembering but I have this vague recollection Bill> that what was objected to was not a media type for 'shell Bill> script' but the notion that an appropriate way to render Bill> such a media type was to feed it to a shell for immediate Bill> execution. I suspect people believe that a reasonable way of rendering the javascript media type is to run it. From pbaker@verisign.com Fri Mar 18 18:56:29 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2INuS5j011930 for ; Fri, 18 Mar 2005 18:56:28 -0500 (EST) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) j2INuG4t024577; Fri, 18 Mar 2005 18:56:17 -0500 (EST) Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53])j2INuGDR015032; Fri, 18 Mar 2005 15:56:16 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 18 Mar 2005 15:56:16 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD372500A1@MOU1WNEXMB04.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" To: "'Bill Sommerfeld'" , Sam Hartman Subject: RE: [saag] media types for javascript Date: Fri, 18 Mar 2005 15:56:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.765757 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 18 Mar 2005 23:56:30 -0000 > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On > Behalf Of Bill Sommerfeld > On Fri, 2005-03-18 at 13:36, Sam Hartman wrote: > > Hi. I seem to recall years ago there was a strong objection to a > > media type request for Unix shell scripts. > > I may be misremembering but I have this vague recollection > that what was objected to was not a media type for 'shell > script' but the notion that an appropriate way to render such > a media type was to feed it to a shell for immediate execution. > > You may think this is so obvious that nobody would try to do this. On the contrary. People did early on in the Web, some of them were so proud of themselves they applied for patents. I thought it was essential to have media types for Java and Javascript so that firewalls know that it is content they want to exclude. From smb@cs.columbia.edu Sat Mar 19 11:41:13 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2JGfB5j017387 for ; Sat, 19 Mar 2005 11:41:11 -0500 (EST) Received: from machshav.com (machshav.com [147.28.0.16]) j2JGf3lt003060; Sat, 19 Mar 2005 11:41:03 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id B70DBFB262; Sat, 19 Mar 2005 11:41:02 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 18B9EFB246; Sat, 19 Mar 2005 11:41:02 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 96C853C02A1; Sat, 19 Mar 2005 11:40:28 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Sam Hartman Subject: Re: [saag] media types for javascript In-Reply-To: Your message of "Fri, 18 Mar 2005 13:36:30 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Mar 2005 11:40:27 -0500 Sender: smb@cs.columbia.edu Message-Id: <20050319164028.96C853C02A1@berkshire.machshav.com> X-Spam-Score: -3.489 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.253712 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 19 Mar 2005 16:41:13 -0000 In message , Sam Hartman writes: >--=-=-= > > > > >Hi. I seem to recall years ago there was a strong objection to a >media type request for Unix shell scripts. > >Today we're seeing a last call for the javascript media types. > >Personally I think the world has changed and that we actually probably >do need media types for things like shell scripts, javascript, etc. >But I thought I would forward this last call here so that people with >different opinions could speak up. I think the right thing to do is point to Section 5 RFC 3514 in the Security Considerations -- but then again, I'm known to refer to the technology as Evilscript, and I keep it disabled on my browser unless I *really* need it. More seriously -- I don't like Javascript and I avoid it if I can. That said, it's better if it's marked explicitly, since that permits easier filtering. The trick is to get a decent security considerations section. In particular, I'd look for a reference to a document that spelled out the Javascript security model. It's that latter that would sink a shell script media type -- there is no such thing. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb From Mailer-Daemon@adelaidebank.com.au Sat Mar 19 12:01:05 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2JH135j017551 for ; Sat, 19 Mar 2005 12:01:04 -0500 (EST) Received: from mail.adelaidebank.com.au (wwwproxy.adelaidebank.com.au [203.33.102.2])j2JH0smJ012193 for ; Sat, 19 Mar 2005 12:00:55 -0500 (EST) X-SEF-NDR-A4CDD3E6-186A-4406-A61E-2779D86E16D1: 1 X-SEF-A4CDD3E6-186A-4406-A61E-2779D86E16D1: 1 Received: from Unknown [172.17.5.100] by mail.adelaidebank.com.au - SurfControl E-mail Filter (5.0); Sun, 20 Mar 2005 03:30:49 +1130 Received: from ABDOMAIN-MTA by adelaidebank.com.au with Novell_GroupWise; Sun, 20 Mar 2005 03:30:48 +1030 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Date: Sun, 20 Mar 2005 03:30:26 +1030 From: "Paul DEWSNAP" Sender: Postmaster@adelaidebank.com.au Errors-To: Postmaster@adelaidebank.com.au To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.335035 Subject: [saag] Re: saag Digest, Vol 26, Issue 8 (Out of Office) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: pdewsnap@adelaidebank.com.au List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 19 Mar 2005 17:01:07 -0000 I am out of the office until Tuesday 22 March 05. Your email has not been forwarded. If this matter is urgent please contact James Schulze ext. 6285. Regards, Paul >>> saag 03/20/05 03:30 >>> Send saag mailing list submissions to saag@mit.edu To subscribe or unsubscribe via the World Wide Web, visit https://jis.mit.edu/mailman/listinfo/saag or, via email, send a message with subject or body 'help' to saag-request@mit.edu You can reach the person managing the list at saag-owner@mit.edu When replying, please edit your Subject line so it is more specific than "Re: Contents of saag digest..." ____________________________________________________________________ This e-mail and any files transmitted with it are confidential and are only for the use of the person to whom they are addressed. If you are not the intended recipient, you are hereby notified that any use, dissemination, forwarding, printing, copying or dealing in any way whatsoever with this e-mail is strictly prohibited. If you have received this e-mail in error, please reply to us immediately and delete the document. It is the recipient's duty to virus scan and otherwise test the enclosed information before using the information or loading attached files onto any computer system. Adelaide Bank Ltd does not warrant that the information contained in this e-mail is free from viruses, defects, errors, interception or interference. Any views expressed in this message are those of the individual sender, except where that sender specifically states them to be the views of Adelaide Bank Ltd. ____________________________________________________________________ From delise_palumbo@verizon.net Sat Mar 19 13:09:25 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2JI9O5j017978 for ; Sat, 19 Mar 2005 13:09:24 -0500 (EST) Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) j2JI9Hlt013845 for ; Sat, 19 Mar 2005 13:09:17 -0500 (EST) Received: from thecompaq ([4.4.18.132])0.04 <0IDM008KX2F7DLB0@vms044.mailsrvcs.net> for saag@mit.edu; Sat, 19 Mar 2005 12:09:17 -0600 (CST) Date: Sat, 19 Mar 2005 10:09:04 -0800 From: "delise_palumbo" In-reply-to: <200503191700.j2JH065l017532@jis.mit.edu> To: Message-id: <0IDM008LF2FGDLB0@vms044.mailsrvcs.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcUspTddkDVMkeUtT7azY4MwkOhF+QACDnXQ X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.933609 Subject: [saag] RE:Media types X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 19 Mar 2005 18:09:27 -0000 Would anyone have a web reference on media type security issues? I am a student, and read the postings regularly for information. In fact reference links on any topic of discussion are appreciated! Thank you. DeLise Marylhurst, OR -----Original Message----- From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of saag-request@mit.edu Sent: Saturday, March 19, 2005 9:00 AM To: saag@mit.edu Subject: saag Digest, Vol 26, Issue 8 Send saag mailing list submissions to saag@mit.edu To subscribe or unsubscribe via the World Wide Web, visit https://jis.mit.edu/mailman/listinfo/saag or, via email, send a message with subject or body 'help' to saag-request@mit.edu You can reach the person managing the list at saag-owner@mit.edu When replying, please edit your Subject line so it is more specific than "Re: Contents of saag digest..." From ben@algroup.co.uk Mon Mar 21 06:56:49 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2LBul5j002450 for ; Mon, 21 Mar 2005 06:56:47 -0500 (EST) Received: from mail.links.org (mail.links.org [217.155.92.109]) j2LBueVa007226 for ; Mon, 21 Mar 2005 06:56:40 -0500 (EST) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 05EE433C33; Mon, 21 Mar 2005 11:56:40 +0000 (GMT) Message-ID: <423EB67C.1000004@algroup.co.uk> Date: Mon, 21 Mar 2005 11:56:44 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cryptography , saag@mit.edu X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.662770 Subject: [saag] Propping up SHA-1 (or MD5) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 21 Mar 2005 11:56:50 -0000 It was suggested at the SAAG meeting at the Minneapolis IETF that a way to deal with weakness in hash functions was to create a new hash function from the old like so: H'(x)=Random || H(Random || x) However, this allows an attacker to play with Random (the advice I've seen is that if one is going to use an IV with a hash function, then one should transfer the IV with integrity checks to deny attackers this freedom). Another objection is that this construction changes the API at the sender end, which could lead to a great deal of complexity when the use of the hash API is deeply embedded. A third is that the length of the hash is changed, which could break existing protocols. Musing on these points, I wondered about the construction: H'(x)=H(H(x) || H(H(x) || x)) which doesn't allow an attacker any choice, doesn't change APIs and doesn't change the length of the hash. Does this have any merit? Note that this is essentially an HMAC where the key is H(x). I omitted the padding because it seems to me that this actually makes HMAC weaker against the current attacks. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 nw141292@binky.Central.Sun.COM Mon Mar 21 21:13:11 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2M2D95j007551 for ; Mon, 21 Mar 2005 21:13:09 -0500 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) j2M2D1oK014949 for ; Mon, 21 Mar 2005 21:13:01 -0500 (EST) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j2M2D0ZO026592 for ; Mon, 21 Mar 2005 18:13:00 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) with ESMTP id j2M2Cwae009055 for ; Mon, 21 Mar 2005 19:13:00 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) j2M2B8Q3009363; Mon, 21 Mar 2005 20:11:08 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j2M2B7am009362; Mon, 21 Mar 2005 20:11:07 -0600 (CST) Date: Mon, 21 Mar 2005 20:11:07 -0600 From: Nicolas Williams To: Ben Laurie Subject: Re: [saag] Propping up SHA-1 (or MD5) Message-ID: <20050322021107.GH1007@binky.Central.Sun.COM> References: <423EB67C.1000004@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423EB67C.1000004@algroup.co.uk> User-Agent: Mutt/1.4.1i X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.167499 cc: saag@mit.edu cc: Cryptography X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 22 Mar 2005 02:13:12 -0000 On Mon, Mar 21, 2005 at 11:56:44AM +0000, Ben Laurie wrote: > It was suggested at the SAAG meeting at the Minneapolis IETF that a way > to deal with weakness in hash functions was to create a new hash > function from the old like so: > > H'(x)=Random || H(Random || x) Eric proposed sending Random, Signature(H(Random || M)) and I then proposed sending Random || Signature(H(Random || M)) to avoid having to add a slot in existing protocols for Random. Another alternative: send Random-Key || Signature(HMAC(H(), Random-Key, M). > However, this allows an attacker to play with Random (the advice I've > seen is that if one is going to use an IV with a hash function, then one > should transfer the IV with integrity checks to deny attackers this > freedom). This proposal is specific to the use of hashes in signatures. > Another objection is that this construction changes the API at the > sender end, which could lead to a great deal of complexity when the use > of the hash API is deeply embedded. Yes. > A third is that the length of the hash is changed, which could break > existing protocols. Tie this to new algorithm OIDs and this problem goes away. You still have to figure out how to deploy new software. > Musing on these points, I wondered about the construction: > > H'(x)=H(H(x) || H(H(x) || x)) Note that this is not on-line. > which doesn't allow an attacker any choice, doesn't change APIs and > doesn't change the length of the hash. Does this have any merit? Note > that this is essentially an HMAC where the key is H(x). I omitted the > padding because it seems to me that this actually makes HMAC weaker > against the current attacks. Yes. Now that we know that the attack is a differential cryptanalysis where the attacker has to control the first pair of blocks of the original message anything that makes it hard for the attacker to do this helps. H'(x) = H(H(x))) might do that trick, and on-line, but surely there's problems with that too (IANAC). Note that the attack implies that there exist weak messages, and Wang et. al. explicitly mention this in the paper on breaking MD4, and they mention the use of weak messages in second pre-image computation -- if a given message begins with a weak block pair then you can construct second pre-images. It'd be nice to know what the weak message distribution is for MD5 and SHA-1... Nico -- From ben@algroup.co.uk Tue Mar 22 04:50:36 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2M9oY5j010134 for ; Tue, 22 Mar 2005 04:50:34 -0500 (EST) Received: from mail.links.org (mail.links.org [217.155.92.109]) j2M9oQdv017885 for ; Tue, 22 Mar 2005 04:50:27 -0500 (EST) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 25BEA33C45; Tue, 22 Mar 2005 09:50:26 +0000 (GMT) Message-ID: <423FEA62.8070005@algroup.co.uk> Date: Tue, 22 Mar 2005 09:50:26 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Kaminsky References: <423EB67C.1000004@algroup.co.uk> <423F2406.5080604@doxpara.com> In-Reply-To: <423F2406.5080604@doxpara.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.471769 cc: saag@mit.edu cc: Cryptography Subject: [saag] Re: Propping up SHA-1 (or MD5) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 22 Mar 2005 09:50:37 -0000 Dan Kaminsky wrote: > Ben, > > x can equal either test vector released by Wang, and H(x) will be > identical. With H(x) identical, the rest of the HMAC stays identical too. This does not appear to be correct - in my construction, i.e. without padding, then the fact that x and x' differ means that the first blocks are different, but not the colliding kind of different (since the first blocks will be 20 bytes of H(x) and blocksize-20 bytes of x or x' [or, to be pedantic, the first 20 bytes of the next block will be different]). Even if padding were included, x and x' would still not collide, because the chaining values would not be as needed at the start of the second block. > As a couple people pointed out, it's OK that HMAC is "vulnerable" to > the Wang attack, since in order to execute the attack the key is > required (and like AES, if the key is compromised, all bets are off). > But you're not using HMAC as a MAC; you're using it to prop up a broken > hash. > > Regarding the "Random" appendage, people don't seem to realize how > important syncronized initial states are to many hashing algorithms. > One of the major uses of a hashing algorithm is to act as an > *exchangable* handle to data, in other words, you and I can both hash > our respective datasets and see if they're identical. If we're each > using different initial states, that process fails utterly. Obviously. But I don't understand your point. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 ben@algroup.co.uk Tue Mar 22 11:51:22 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2MGpL5j012789 for ; Tue, 22 Mar 2005 11:51:21 -0500 (EST) Received: from mail.links.org (mail.links.org [217.155.92.109]) j2MGpCBU028474 for ; Tue, 22 Mar 2005 11:51:13 -0500 (EST) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 8410B33C5F; Tue, 22 Mar 2005 16:51:12 +0000 (GMT) Message-ID: <42404D00.6030001@algroup.co.uk> Date: Tue, 22 Mar 2005 16:51:12 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Barney Wolff References: <423EB67C.1000004@algroup.co.uk> <20050321212642.GA95604@pit.databus.com> In-Reply-To: <20050321212642.GA95604@pit.databus.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.556699 cc: saag@mit.edu cc: Cryptography Subject: [saag] Re: Propping up SHA-1 (or MD5) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 22 Mar 2005 16:51:24 -0000 Barney Wolff wrote: > On Mon, Mar 21, 2005 at 11:56:44AM +0000, Ben Laurie wrote: > >>Musing on these points, I wondered about the construction: >> >>H'(x)=H(H(x) || H(H(x) || x)) >> >>which doesn't allow an attacker any choice, doesn't change APIs and >>doesn't change the length of the hash. Does this have any merit? Note >>that this is essentially an HMAC where the key is H(x). I omitted the >>padding because it seems to me that this actually makes HMAC weaker >>against the current attacks. > > > I believe the fatal flaw here is not the crypto, but losing the ability > to hash a stream without keeping all of it. Both the hashes and HMAC > have this sometimes-vital property. This can be fixed quite easily: H'(x)=H(H(x || H(x)) || H(x)) Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 raeburn@MIT.EDU Tue Mar 22 12:15:35 2005 Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2MHFY5j012997 for ; Tue, 22 Mar 2005 12:15:34 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) j2MHFFTh020068; Tue, 22 Mar 2005 12:15:15 -0500 (EST) Received: from [18.101.0.226] ([18.101.0.226]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.12.4/8.12.4) with ESMTP id j2MHF60a016622 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 22 Mar 2005 12:15:07 -0500 (EST) In-Reply-To: <42404D00.6030001@algroup.co.uk> References: <423EB67C.1000004@algroup.co.uk> <20050321212642.GA95604@pit.databus.com> <42404D00.6030001@algroup.co.uk> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ken Raeburn Subject: Re: [saag] Re: Propping up SHA-1 (or MD5) Date: Tue, 22 Mar 2005 12:15:05 -0500 To: Ben Laurie X-Mailer: Apple Mail (2.619.2) X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.961527 cc: Cryptography cc: Barney Wolff cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 22 Mar 2005 17:15:37 -0000 On Mar 22, 2005, at 11:51, Ben Laurie wrote: > This can be fixed quite easily: > > H'(x)=H(H(x || H(x)) || H(x)) Doesn't this take us back to the original problem, by factoring in x only at the start of hash computations, so H'(x') will generate the same H(x') and the same internal state for H(x'||...) as for H(x||...) and thus the same H(x'||H(x')) etc, resulting in the same final value? Ken From ben@algroup.co.uk Tue Mar 22 12:31:54 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2MHVq5j013115 for ; Tue, 22 Mar 2005 12:31:52 -0500 (EST) Received: from mail.links.org (mail.links.org [217.155.92.109]) j2MHViBU012251 for ; Tue, 22 Mar 2005 12:31:45 -0500 (EST) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 5F59F33C73; Tue, 22 Mar 2005 17:31:44 +0000 (GMT) Message-ID: <42405680.5090708@algroup.co.uk> Date: Tue, 22 Mar 2005 17:31:44 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams Subject: Re: [saag] Propping up SHA-1 (or MD5) References: <423EB67C.1000004@algroup.co.uk> <20050322021107.GH1007@binky.Central.Sun.COM> In-Reply-To: <20050322021107.GH1007@binky.Central.Sun.COM> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.847264 cc: saag@mit.edu cc: Cryptography X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 22 Mar 2005 17:31:54 -0000 Nicolas Williams wrote: > On Mon, Mar 21, 2005 at 11:56:44AM +0000, Ben Laurie wrote: > >>It was suggested at the SAAG meeting at the Minneapolis IETF that a way >>to deal with weakness in hash functions was to create a new hash >>function from the old like so: >> >>H'(x)=Random || H(Random || x) > > > Eric proposed sending Random, Signature(H(Random || M)) and I then > proposed sending Random || Signature(H(Random || M)) to avoid having to > add a slot in existing protocols for Random. > > Another alternative: send Random-Key || Signature(HMAC(H(), Random-Key, M). > > >>However, this allows an attacker to play with Random (the advice I've >>seen is that if one is going to use an IV with a hash function, then one >>should transfer the IV with integrity checks to deny attackers this >>freedom). > > > This proposal is specific to the use of hashes in signatures. > > >>Another objection is that this construction changes the API at the >>sender end, which could lead to a great deal of complexity when the use >>of the hash API is deeply embedded. > > > Yes. > > >>A third is that the length of the hash is changed, which could break >>existing protocols. > > > Tie this to new algorithm OIDs and this problem goes away. You still > have to figure out how to deploy new software. > > >>Musing on these points, I wondered about the construction: >> >>H'(x)=H(H(x) || H(H(x) || x)) > > > Note that this is not on-line. > > >>which doesn't allow an attacker any choice, doesn't change APIs and >>doesn't change the length of the hash. Does this have any merit? Note >>that this is essentially an HMAC where the key is H(x). I omitted the >>padding because it seems to me that this actually makes HMAC weaker >>against the current attacks. > > > Yes. > > Now that we know that the attack is a differential cryptanalysis where > the attacker has to control the first pair of blocks of the original > message anything that makes it hard for the attacker to do this helps. > > H'(x) = H(H(x))) might do that trick, and on-line, but surely there's > problems with that too (IANAC). This construction cannot solve the problem since H(x)=H(x') => H(H(x))=H(H(x')). > Note that the attack implies that there exist weak messages, and Wang > et. al. explicitly mention this in the paper on breaking MD4, and they > mention the use of weak messages in second pre-image computation -- if a > given message begins with a weak block pair then you can construct > second pre-images. It'd be nice to know what the weak message > distribution is for MD5 and SHA-1... Wouldn't it? -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 ben@algroup.co.uk Tue Mar 22 12:48:58 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2MHmu5j013272 for ; Tue, 22 Mar 2005 12:48:56 -0500 (EST) Received: from mail.links.org (mail.links.org [217.155.92.109]) j2MHmkiJ020753; Tue, 22 Mar 2005 12:48:46 -0500 (EST) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id C41E333C45; Tue, 22 Mar 2005 17:48:45 +0000 (GMT) Message-ID: <42405A7E.908@algroup.co.uk> Date: Tue, 22 Mar 2005 17:48:46 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Raeburn Subject: Re: [saag] Re: Propping up SHA-1 (or MD5) References: <423EB67C.1000004@algroup.co.uk> <20050321212642.GA95604@pit.databus.com> <42404D00.6030001@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.130354 cc: Cryptography cc: Barney Wolff cc: saag@MIT.EDU X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 22 Mar 2005 17:48:59 -0000 Ken Raeburn wrote: > On Mar 22, 2005, at 11:51, Ben Laurie wrote: > >> This can be fixed quite easily: >> >> H'(x)=H(H(x || H(x)) || H(x)) > > > Doesn't this take us back to the original problem, by factoring in x > only at the start of hash computations, so H'(x') will generate the same > H(x') and the same internal state for H(x'||...) as for H(x||...) and > thus the same H(x'||H(x')) etc, resulting in the same final value? Doh. Yes. Slightly less elegantly, then: H'(x)=H(H(x || H(0 || x) || H(0 || x)) Then you need two hashes running in parallel, but at least it is still online. Or, with three parallel streams: H'(x)=H(H(x || H(0 || x) || H(1 || x)) I don't feel as comfortable with either as the original construction, though. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 nw141292@binky.Central.Sun.COM Tue Mar 22 14:11:18 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2MJBG5j013991 for ; Tue, 22 Mar 2005 14:11:16 -0500 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) j2MJB75Q022117 for ; Tue, 22 Mar 2005 14:11:07 -0500 (EST) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j2MJB6X8000358 for ; Tue, 22 Mar 2005 12:11:07 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) with ESMTP id j2MJB5f0027557 for ; Tue, 22 Mar 2005 12:11:06 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) j2MJ9EFK009721; Tue, 22 Mar 2005 13:09:14 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j2MJ9Cj0009720; Tue, 22 Mar 2005 13:09:12 -0600 (CST) Date: Tue, 22 Mar 2005 13:09:12 -0600 From: Nicolas Williams To: Ben Laurie Subject: Re: [saag] Propping up SHA-1 (or MD5) Message-ID: <20050322190912.GD9676@binky.Central.Sun.COM> References: <423EB67C.1000004@algroup.co.uk> <20050322021107.GH1007@binky.Central.Sun.COM> <42405680.5090708@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42405680.5090708@algroup.co.uk> User-Agent: Mutt/1.4.1i X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.788447 cc: saag@mit.edu cc: Cryptography X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 22 Mar 2005 19:11:18 -0000 On Tue, Mar 22, 2005 at 05:31:44PM +0000, Ben Laurie wrote: > Nicolas Williams wrote: > >Now that we know that the attack is a differential cryptanalysis where > >the attacker has to control the first pair of blocks of the original > >message anything that makes it hard for the attacker to do this helps. > > > >H'(x) = H(H(x))) might do that trick, and on-line, but surely there's > >problems with that too (IANAC). > > This construction cannot solve the problem since H(x)=H(x') => > H(H(x))=H(H(x')). But it changes the attacker's problem. Currently the attacker has to find a first block of a weak message, then find the second block of the same, then he can generate collisions at will. The weak message generation requires some effort, and surely -- huge assumption here -- it takes more effort to find a weak message whose hash is also a weak message. Now, perhaps this assumption is utterly wrong, but I suspect it's correct, for the published hash function cryptanalysis anyways, though I make no assertions as to any other strengths or weaknesses of such H'() constructions. Nico -- From ben@algroup.co.uk Tue Mar 22 14:34:38 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2MJYb5j014235 for ; Tue, 22 Mar 2005 14:34:37 -0500 (EST) Received: from mail.links.org (mail.links.org [217.155.92.109]) j2MJYTSx011394 for ; Tue, 22 Mar 2005 14:34:30 -0500 (EST) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 1484533C33; Tue, 22 Mar 2005 19:34:29 +0000 (GMT) Message-ID: <42407345.9030206@algroup.co.uk> Date: Tue, 22 Mar 2005 19:34:29 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams Subject: Re: [saag] Propping up SHA-1 (or MD5) References: <423EB67C.1000004@algroup.co.uk> <20050322021107.GH1007@binky.Central.Sun.COM> <42405680.5090708@algroup.co.uk> <20050322190912.GD9676@binky.Central.Sun.COM> In-Reply-To: <20050322190912.GD9676@binky.Central.Sun.COM> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.019747 cc: saag@mit.edu cc: Cryptography X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 22 Mar 2005 19:34:39 -0000 Nicolas Williams wrote: > On Tue, Mar 22, 2005 at 05:31:44PM +0000, Ben Laurie wrote: > >>Nicolas Williams wrote: >> >>>Now that we know that the attack is a differential cryptanalysis where >>>the attacker has to control the first pair of blocks of the original >>>message anything that makes it hard for the attacker to do this helps. >>> >>>H'(x) = H(H(x))) might do that trick, and on-line, but surely there's >>>problems with that too (IANAC). >> >>This construction cannot solve the problem since H(x)=H(x') => >>H(H(x))=H(H(x')). > > > But it changes the attacker's problem. > > Currently the attacker has to find a first block of a weak message, then > find the second block of the same, then he can generate collisions at > will. The weak message generation requires some effort, and surely -- > huge assumption here -- it takes more effort to find a weak message > whose hash is also a weak message. The hash does not need to be weak, since the two hashes are the same, and so their hashes are also the same. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 nw141292@binky.Central.Sun.COM Tue Mar 22 14:40:26 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2MJeO5j014288 for ; Tue, 22 Mar 2005 14:40:24 -0500 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) j2MJeHSx022626 for ; Tue, 22 Mar 2005 14:40:18 -0500 (EST) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j2MJeHRr022808 for ; Tue, 22 Mar 2005 12:40:17 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) with ESMTP id j2MJeGf0013528 for ; Tue, 22 Mar 2005 12:40:17 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) j2MJcQmR009744; Tue, 22 Mar 2005 13:38:26 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j2MJcQB7009743; Tue, 22 Mar 2005 13:38:26 -0600 (CST) Date: Tue, 22 Mar 2005 13:38:26 -0600 From: Nicolas Williams To: Ben Laurie Subject: Re: [saag] Propping up SHA-1 (or MD5) Message-ID: <20050322193826.GF9676@binky.Central.Sun.COM> References: <423EB67C.1000004@algroup.co.uk> <20050322021107.GH1007@binky.Central.Sun.COM> <42405680.5090708@algroup.co.uk> <20050322190912.GD9676@binky.Central.Sun.COM> <42407345.9030206@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42407345.9030206@algroup.co.uk> User-Agent: Mutt/1.4.1i X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.427115 cc: saag@mit.edu cc: Cryptography X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 22 Mar 2005 19:40:27 -0000 On Tue, Mar 22, 2005 at 07:34:29PM +0000, Ben Laurie wrote: > Nicolas Williams wrote: > >On Tue, Mar 22, 2005 at 05:31:44PM +0000, Ben Laurie wrote: > > > >>Nicolas Williams wrote: > >> > >>>Now that we know that the attack is a differential cryptanalysis where > >>>the attacker has to control the first pair of blocks of the original > >>>message anything that makes it hard for the attacker to do this helps. > >>> > >>>H'(x) = H(H(x))) might do that trick, and on-line, but surely there's > >>>problems with that too (IANAC). > >> > >>This construction cannot solve the problem since H(x)=H(x') => > >>H(H(x))=H(H(x')). > > > > > >But it changes the attacker's problem. > > > >Currently the attacker has to find a first block of a weak message, then > >find the second block of the same, then he can generate collisions at > >will. The weak message generation requires some effort, and surely -- > >huge assumption here -- it takes more effort to find a weak message > >whose hash is also a weak message. > > The hash does not need to be weak, since the two hashes are the same, > and so their hashes are also the same. I knew I was missing something. Which gets us back to the matter of how to construct H'() such that it is harder for the attacker to generate collisions but without making H'() not on-line, which has been discussed here plenty enough. For many uses of digital signatures it may not matter that a hash function is not on-line though. Nico -- From fw@deneb.enyo.de Wed Mar 23 11:36:05 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2NGa35j024188 for ; Wed, 23 Mar 2005 11:36:04 -0500 (EST) Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) j2NGZuFw005844 for ; Wed, 23 Mar 2005 11:35:57 -0500 (EST) Received: from deneb.enyo.de ([212.9.189.171]) by albireo.enyo.de with esmtp id 1DE8pk-0002Cm-85; Wed, 23 Mar 2005 17:35:52 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.50) id 1DE8pi-00030D-IV; Wed, 23 Mar 2005 17:35:50 +0100 From: Florian Weimer To: Ben Laurie References: <423EB67C.1000004@algroup.co.uk> Date: Wed, 23 Mar 2005 17:35:50 +0100 In-Reply-To: <423EB67C.1000004@algroup.co.uk> (Ben Laurie's message of "Mon, 21 Mar 2005 11:56:44 +0000") Message-ID: <878y4ewc9l.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000012 Spam-Alum-Time: 0.523249 cc: saag@mit.edu cc: Cryptography Subject: [saag] Re: Propping up SHA-1 (or MD5) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 23 Mar 2005 16:36:06 -0000 * Ben Laurie: > Musing on these points, I wondered about the construction: > > H'(x)=H(H(x) || H(H(x) || x)) > > which doesn't allow an attacker any choice, doesn't change APIs Unfortunately, it does, in a rather fundamental way: streamed processing is no longer possible. From ben@algroup.co.uk Thu Mar 24 05:38:49 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2OAck5j002907 for ; Thu, 24 Mar 2005 05:38:46 -0500 (EST) Received: from mail.links.org (mail.links.org [217.155.92.109]) j2OAcdGP025447 for ; Thu, 24 Mar 2005 05:38:39 -0500 (EST) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 9264833C33; Thu, 24 Mar 2005 10:38:38 +0000 (GMT) Message-ID: <424298B0.5060900@algroup.co.uk> Date: Thu, 24 Mar 2005 10:38:40 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charlie Kaufman References: In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 2.001711 cc: saag@mit.edu cc: Cryptography Subject: [saag] Re: Propping up SHA-1 (or MD5) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 24 Mar 2005 10:38:50 -0000 Charlie Kaufman wrote: > All hash functions I'm aware of consist of an inner compression function > that hashes a fixed size block of data into a smaller fixed size block > and an outer composition function that applies the inner function > iteratively to the variable length data to be hashed. Essentially you're > proposing a modification to the outer layer of the hash construction. > > All of the standard hash functions since MD4 have been constructed so > that a collision in the inner compression function is likely to lead to > a collision in the hash function. MD2 did not have that property. It > computed a cheap checksum of the variable length data in parallel with > the digesting process and digested the checksum following the data. I > have often wondered whether such a cheap addition would strengthen the > newer hashes. (It would fix the suffixing attacks that motivated the > development of HMAC). > > It's not obvious whether this would make the functions more secure or > just make them harder to analyze. Perhaps someone from the research > community could comment on why the checksum was removed in the evolution > from MD2 to MD4. > > Your proposed encoding has the disadvantage that it would require two > passes over the message being digested. This would be bad news for > hardware implementations and should be avoided if possible. I suggested in a later version these two constructions: H'(x)=H(H(x || H(0 || x) || H(0 || x)) or: H'(x)=H(H(x || H(0 || x) || H(1 || x)) which only require a single pass (but, unfortunately, two or three different instances of the hash). This seems similar to the mechanism used in MD2, except the checksum is expensive. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 uri.blumenthal@intel.com Thu Mar 24 08:11:15 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2ODBE5j003735 for ; Thu, 24 Mar 2005 08:11:14 -0500 (EST) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) j2ODB6Lf026035 for ; Thu, 24 Mar 2005 08:11:06 -0500 (EST) Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) 2004/09/17 17:50:56 root Exp $) with ESMTP id j2ODA6dx009233; Thu, 24 Mar 2005 13:10:06 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) 2004/09/17 18:05:01 root Exp $) with SMTP id j2OD9qPK031362; Thu, 24 Mar 2005 13:10:06 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) M2005032405100515800 ; Thu, 24 Mar 2005 05:10:05 -0800 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Mar 2005 05:10:05 -0800 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Mar 2005 05:10:05 -0800 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Mar 2005 08:10:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [saag] Re: Propping up SHA-1 (or MD5) Date: Thu, 24 Mar 2005 08:09:50 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929DE0F8C@pysmsx401.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Re: Propping up SHA-1 (or MD5) Thread-Index: AcUwXh+d94b+gmANS+m+21nxEgXiIQAFDLGg From: "Blumenthal, Uri" To: , "Cryptography" X-OriginalArrivalTime: 24 Mar 2005 13:10:04.0182 (UTC) FILETIME=[CB1A2360:01C53072] X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: -4.9 X-Spam-Flag: NO Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.901052 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id j2ODBE5j003735 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 24 Mar 2005 13:11:17 -0000 Ernie Brickell suggested the following construct: H'(x) = H( H(x) || H(0 || x) ) Like him, I see no reason in going (H(x) || H(0||x) || ... || H(n||x)). -----Original Message----- From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of Ben Laurie Sent: Thursday, March 24, 2005 5:39 AM To: Charlie Kaufman Cc: saag@mit.edu; Cryptography Subject: [saag] Re: Propping up SHA-1 (or MD5) Charlie Kaufman wrote: > All hash functions I'm aware of consist of an inner compression function > that hashes a fixed size block of data into a smaller fixed size block > and an outer composition function that applies the inner function > iteratively to the variable length data to be hashed. Essentially you're > proposing a modification to the outer layer of the hash construction. > > All of the standard hash functions since MD4 have been constructed so > that a collision in the inner compression function is likely to lead to > a collision in the hash function. MD2 did not have that property. It > computed a cheap checksum of the variable length data in parallel with > the digesting process and digested the checksum following the data. I > have often wondered whether such a cheap addition would strengthen the > newer hashes. (It would fix the suffixing attacks that motivated the > development of HMAC). > > It's not obvious whether this would make the functions more secure or > just make them harder to analyze. Perhaps someone from the research > community could comment on why the checksum was removed in the evolution > from MD2 to MD4. > > Your proposed encoding has the disadvantage that it would require two > passes over the message being digested. This would be bad news for > hardware implementations and should be avoided if possible. I suggested in a later version these two constructions: H'(x)=H(H(x || H(0 || x) || H(0 || x)) or: H'(x)=H(H(x || H(0 || x) || H(1 || x)) which only require a single pass (but, unfortunately, two or three different instances of the hash). This seems similar to the mechanism used in MD2, except the checksum is expensive. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 https://jis.mit.edu/mailman/listinfo/saag From ben@algroup.co.uk Thu Mar 24 13:19:45 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2OIJh5j005734 for ; Thu, 24 Mar 2005 13:19:43 -0500 (EST) Received: from mail.links.org (mail.links.org [217.155.92.109]) j2OIJZOr000019 for ; Thu, 24 Mar 2005 13:19:35 -0500 (EST) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id E092A33C33; Thu, 24 Mar 2005 18:19:34 +0000 (GMT) Message-ID: <424304B8.3060402@algroup.co.uk> Date: Thu, 24 Mar 2005 18:19:36 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Blumenthal, Uri" Subject: Re: [saag] Re: Propping up SHA-1 (or MD5) References: <3DEC199BD7489643817ECA151F7C5929DE0F8C@pysmsx401.amr.corp.intel.com> In-Reply-To: <3DEC199BD7489643817ECA151F7C5929DE0F8C@pysmsx401.amr.corp.intel.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.897657 cc: Cryptography cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 24 Mar 2005 18:19:46 -0000 Blumenthal, Uri wrote: > Ernie Brickell suggested the following construct: > > H'(x) = H( H(x) || H(0 || x) ) > > Like him, I see no reason in going (H(x) || H(0||x) || ... || H(n||x)). Sorry, I got my parentheses wrong. I meant... H'(x)=H(H(x || H(0 || x)) || H(0 || x)) or: H'(x)=H(H(x || H(0 || x)) || H(1 || x)) the former being almost the same construction as suggested, except that H(0 || x) is appended to the first inner hash. I used this construction because nested keyed hashes have provable security properties (which is why HMAC is made the way it is). The second form is the one required to get those properties, I should point out. I will confess that I have punted on whether those properties are actually useful. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 lionel2@enorth.com.cn Fri Mar 25 16:33:39 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2PLXb5j015735 for ; Fri, 25 Mar 2005 16:33:37 -0500 (EST) Received: from mail.enorth.com.cn ([211.148.164.144])j2PLXJ3N029422 for ; Fri, 25 Mar 2005 16:33:27 -0500 (EST) Received: from [221.233.11.19] (unknown [221.233.11.19]) by mail.enorth.com.cn (ecMail) with ESMTP id D2E3210508EB for ; Sat, 26 Mar 2005 05:24:29 +0800 (CST) Message-ID: <4244838A.3090507@enorth.com.cn> Date: Sat, 26 Mar 2005 05:32:58 +0800 From: =?UTF-8?B?5ZGo56uL?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: zh-cn,zh MIME-Version: 1.0 To: saag@mit.edu Content-Type: multipart/mixed; boundary="------------070007050002010005030702" X-Spam-Score: 0.29 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000029 Spam-Alum-Time: 1.230865 Subject: [saag] On Demand Staffing for Information Technology Projects X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: lionel2@enorth.com.cn List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 25 Mar 2005 21:33:39 -0000 This is a multi-part message in MIME format. --------------070007050002010005030702 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Rent-A-Pro.com offers on demand staffing and service delivery for information technology projects. It is convenient for small businesses as well as individual developers to get temporary help, consulting service and outsourcing service from independent contractors around the world through our site. We provide functions for posting project requirements, bidding for projects and rating between buyers and sellers. Buyers and sellers are protected from fraud by an escrow system and a dispute resolution system. http://www.rent-a-pro.com/ --------------070007050002010005030702 Content-Type: text/x-vcard; charset=utf-8; name="lionel2.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="lionel2.vcf" YmVnaW46dmNhcmQNCmZuO3F1b3RlZC1wcmludGFibGU6PUU3PUFCPThCID1FNT05MT1BOA0K bjtxdW90ZWQtcHJpbnRhYmxlO3F1b3RlZC1wcmludGFibGU6PUU1PTkxPUE4Oz1FNz1BQj04 Qg0KYWRyO3F1b3RlZC1wcmludGFibGU6Ozs7Ozs7PUU0PUI4PUFEPUU1PTlCPUJEDQplbWFp bDtpbnRlcm5ldDpsaW9uZWwyQGVub3J0aC5jb20uY24NCnVybDpodHRwOi8vd3d3LnJlbnQt YS1wcm8uY29tLw0KdmVyc2lvbjoyLjENCmVuZDp2Y2FyZA0KDQo= --------------070007050002010005030702-- From james.jaques@ngc.com Fri Mar 25 17:28:27 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2PMSP5j016126 for ; Fri, 25 Mar 2005 17:28:25 -0500 (EST) Received: from xcgca810.northgrum.com (xcgca810.northgrum.com [208.12.122.34]) j2PMSH3N024535 for ; Fri, 25 Mar 2005 17:28:18 -0500 (EST) Received: from xcgca800.northgrum.com ([157.127.103.70]) by xcgca810.northgrum.com with InterScan Messaging Security Suite; Fri, 25 Mar 2005 14:27:51 -0800 Received: from xcgca101.northgrum.com ([157.127.103.42]) by xcgca800.northgrum.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 25 Mar 2005 14:27:48 -0800 Received: from xcgca206.northgrum.com ([157.127.218.103]) by xcgca101.northgrum.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 25 Mar 2005 14:27:49 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [saag] On Demand Staffing for Information Technology Projects Date: Fri, 25 Mar 2005 14:27:45 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] On Demand Staffing for Information Technology Projects Thread-Index: AcUxhJZKjhuuqGf4Qk2A0ZmxwYhz3AABRC3g From: "Jaques, James III" To: , X-OriginalArrivalTime: 25 Mar 2005 22:27:49.0495 (UTC) FILETIME=[E0656870:01C53189] X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.186477 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by jis.mit.edu id j2PMSP5j016126 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 25 Mar 2005 22:28:28 -0000 I do not appreciate this type of email from the saag mail box. I treat that mail very specially and feel it unfair to have someone spam the mailbox. Jim Jaques Research Engineer Northrop Grumman (Newport News Shipbuilding) Remote office at NGIS (Air Combat Systems) El Segundo Ca. 90245 310-332-9160 (O) 562-881-3256 (Mobile) 310-332-6185 FAX james.jaques@ngc.com -----Original Message----- From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu]On Behalf Of lionel2@enorth.com.cn Sent: Friday, March 25, 2005 1:33 PM To: saag@mit.edu Subject: [saag] On Demand Staffing for Information Technology Projects Rent-A-Pro.com offers on demand staffing and service delivery for information technology projects. It is convenient for small businesses as well as individual developers to get temporary help, consulting service and outsourcing service from independent contractors around the world through our site. We provide functions for posting project requirements, bidding for projects and rating between buyers and sellers. Buyers and sellers are protected from fraud by an escrow system and a dispute resolution system. http://www.rent-a-pro.com/ From jwkckid1@ix.netcom.com Sun Mar 27 03:07:36 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2R87Z5j029302 for ; Sun, 27 Mar 2005 03:07:35 -0500 (EST) Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226])j2R87SaB019024 for ; Sun, 27 Mar 2005 03:07:28 -0500 (EST) Received: from 1cust229.tnt36.dfw9.da.uu.net ([67.234.81.229] helo=ix.netcom.com) by blount.mail.mindspring.net with esmtp (Exim 3.36 #1) id 1DFSnv-0008V5-00 for saag@mit.edu; Sun, 27 Mar 2005 03:07:28 -0500 Message-ID: <4246842E.8248577B@ix.netcom.com> Date: Sun, 27 Mar 2005 02:00:14 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: saag Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -1.524 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.622106 Subject: [saag] RSA Conference surprise - Did MS buy the report? X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 27 Mar 2005 08:07:37 -0000 All, http://seattlepi.nwsource.com/business/217538_msftstudy25.html Two researchers, from the Florida Institute of Technology and Boston-based Security Innovation Inc., 'surprised the audience at a computer-security convention last month with their finding that a version of Microsoft Windows was more secure than a competing Linux operating system' according to the Seattle Post-Intelligencer. 'This week, the researchers released their finished report, and it included another surprise: Microsoft was funding the project all along.' When will they ever learn? Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From housley@vigilsec.com Mon Mar 28 15:16:53 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2SKGn5j012032 for ; Mon, 28 Mar 2005 15:16:49 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) j2SKGdRB001522 for ; Mon, 28 Mar 2005 15:16:39 -0500 (EST) Received: (qmail 2499 invoked by uid 0); 28 Mar 2005 20:15:21 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.93.47) by woodstock.binhost.com with SMTP; 28 Mar 2005 20:15:21 -0000 Message-Id: <6.2.0.14.2.20050328144810.06b94830@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 28 Mar 2005 15:14:56 -0500 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000228 Spam-Alum-Time: 0.980136 cc: kurtis@kurtis.pp.se cc: psavola@funet.fi cc: bwijnen@lucent.com cc: fred@cisco.com cc: alvaro.vives@consulintel.es cc: jonne.Soininen@nokia.com cc: david.kessens@nokia.com Subject: [saag] draft-vives-v6ops-ipv6-security-ps X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 28 Mar 2005 20:16:54 -0000 At the last IETF meeting, the v6ops working group discussed this document. The sense of the meeting was that it might be more interesting to the security area than to v6ops. So, I am asking the SAAG list for their thoughts? The people on the CC list may not be on the SAAG mail list. Please join if you want to be involved in the discussion. Russ From paul.hoffman@vpnc.org Tue Mar 29 15:30:14 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2TKUC5j020439 for ; Tue, 29 Mar 2005 15:30:13 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) j2TKU5AS010408 for ; Tue, 29 Mar 2005 15:30:05 -0500 (EST) Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2TKU3Jm079434 for ; Tue, 29 Mar 2005 12:30:04 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 29 Mar 2005 12:27:03 -0800 To: saag@mit.edu From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.043165 Subject: [saag] Attacks on Cryptographic Hashes in Internet Protocols X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 29 Mar 2005 20:30:15 -0000 Greetings again. Bruce Schneier and I have written a draft on the status of hashes in protocols based on the recent attacks. The -00 version can be found at . Our intent is to help lay out the currently-known facts in one place so that protocol developers can decide how to respond to the new information. As you can see from Section 6, we do not agree on what to do with those facts; maybe the SAAG list can help weigh the alternatives. We welcome comments on the draft. --Paul Hoffman, Director --VPN Consortium From mouse@Sparkle.Rodents.Montreal.QC.CA Wed Mar 30 02:46:30 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2U7kQ5j025134 for ; Wed, 30 Mar 2005 02:46:26 -0500 (EST) Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7])j2U7kJtx000306 for ; Wed, 30 Mar 2005 02:46:19 -0500 (EST) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id CAA04076; Wed, 30 Mar 2005 02:46:18 -0500 (EST) From: der Mouse Message-Id: <200503300746.CAA04076@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Wed, 30 Mar 2005 02:40:42 -0500 (EST) To: saag@mit.edu Subject: Re: [saag] Attacks on Cryptographic Hashes in Internet Protocols In-Reply-To: References: X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.834627 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 30 Mar 2005 07:46:31 -0000 > . > We welcome comments on the draft. One thing does come to mind upon reading it. It's something that's vaguely bothered me about a bunch of stuff that's been said recently about hash functions; in saynig this in response to you, I'm singling you out only in that you happened to be the item that provoked me to say something. I keep seeing references to SHA-256 and suchlike, with nothing referenced but some FIPS publication number. This strikes me as singularly unhelpful. If the publications are not online, there is comparatively little point referencing them; I certainly know that *I* would simply implement something else, probably even something significantly less secure, rather than bothering to obtain a paper document. And if the publications *are* online, why not include a pointer to where they can be obtained? If FIPS - or more precisely the body behind it - prohibits making the algorithm descriptions available online, I have to question how appropriate those algorithms are for IETF work, even if they *are* the best available algorithms from a cryptographic standpoint. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From michaelslists@gmail.com Wed Mar 30 07:14:40 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2UCEd5j026919 for ; Wed, 30 Mar 2005 07:14:39 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) j2UCEWJq020014 for ; Wed, 30 Mar 2005 07:14:32 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 57so87654wri for ; Wed, 30 Mar 2005 04:14:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Vm68FzKFi3h+ZAfqP6IJSeq9nE+/2oRU9F/rxNyksT0DGsCbtxV818+kK8UlaMjmMOaRFbIS19FPv9mT64iY9bHWAjB2DY5xBmIk1I2PYLudTVFE8FhL7PD1wBkzpz4zf1AO+0iIzG8P2CUMhC1TaNZHsJbC2CmbvD9VZNiFmio= Received: by 10.54.37.69 with SMTP id k69mr378705wrk; Wed, 30 Mar 2005 04:14:31 -0800 (PST) Received: by 10.54.35.54 with HTTP; Wed, 30 Mar 2005 04:14:30 -0800 (PST) Message-ID: <5e01c29a05033004149c6b940@mail.gmail.com> Date: Wed, 30 Mar 2005 04:14:30 -0800 From: Michael Silk To: saag@mit.edu Subject: Re: [saag] Attacks on Cryptographic Hashes in Internet Protocols In-Reply-To: <200503300746.CAA04076@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <200503300746.CAA04076@Sparkle.Rodents.Montreal.QC.CA> X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.903835 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: michaelslists@gmail.com List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 30 Mar 2005 12:14:41 -0000 In 2.1 paragraph 2 you say: " It is also important to note that the current collision attacks require at least one of the two messages to have a fair amount of structure in the bits of the message. This means that finding two messages that both have the same hash value *and* are useful in a real-world attack is more difficult than just finding two messages with the same hash value." But as discussed in [1] by Ondrej Mikle and [2] by Dan Kaminsky, _ANY_ two colliding blocks can be useful in a real-world attack, it doesn't matter that they are virtually equal. -- Michael [1] http://cryptography.hyperlink.cz/2004/collisions.htm [2] http://www.doxpara.com/md5_someday.pdf On Wed, 30 Mar 2005 02:40:42 -0500 (EST), der Mouse wrote: > . > > We welcome comments on the draft. From rja@extremenetworks.com Wed Mar 30 07:53:49 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2UCrl5j027269 for ; Wed, 30 Mar 2005 07:53:47 -0500 (EST) Received: from smtp1.extremenetworks.com (smtp1.extremenetworks.com [216.52.8.6])j2UCrY0K014566 for ; Wed, 30 Mar 2005 07:53:35 -0500 (EST) Received: from [10.30.20.60] (unknown [10.30.20.60]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 156BF7941; Wed, 30 Mar 2005 04:53:28 -0800 (PST) In-Reply-To: <200503300746.CAA04076@Sparkle.Rodents.Montreal.QC.CA> References: <200503300746.CAA04076@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1935a32d0b07305c67cc46a461c1633c@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [saag] Attacks on Cryptographic Hashes in Internet Protocols Date: Wed, 30 Mar 2005 07:54:26 -0500 To: der Mouse X-Mailer: Apple Mail (2.619.2) X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.154939 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 30 Mar 2005 12:53:49 -0000 On Mar 30, 2005, at 02:40, der Mouse wrote: > I keep seeing references to SHA-256 and suchlike, with nothing > referenced but some FIPS publication number. This strikes me as > singularly unhelpful. If the publications are not online, there is > comparatively little point referencing them; I certainly know that *I* > would simply implement something else, probably even something > significantly less secure, rather than bothering to obtain a paper > document. FIPS documents are online. Google tells me that the SHA-* specs are at: http://csrc.nist.gov/CryptoToolkit/tkhash.html > And if the publications *are* online, why not include a > pointer to where they can be obtained? Because web sites (including NIST's) get reorganised from time to time, which means that any provided URL will become stale in the course of time. By contrast, giving enough of a bibliographic reference to feed into Google (or Yahoo) will yield a good URL every time. > If FIPS - or more precisely the body behind it - prohibits making the > algorithm descriptions available online, I have to question how > appropriate those algorithms are for IETF work, even if they *are* the > best available algorithms from a cryptographic standpoint. FIPS == Federal Information Processing Standard FIPS documents are produced by the (US) National Institute of Standards and Technology, which is a component of the US Department of Commerce. Among other things, NIST is the official source for correct weights and measures within the USA. NIST's algorithms are fully available online. Further, their recent process whereby the RIJNDAEL proposed encryption algorithm from Europe became the US Advanced Encryption Standard (AES) was as transparent a process as I've seen. The process not only permitted anyone to submit an algorithm proposal, but also permitted anyone to submit comments or evaluations of any of the proposals, with these various submissions being kept in the public view. In this particular case, your concerns are misplaced. We agree about the general principle of openness, which is being more than fully met in this case. Yours, Ran rja@extremenetworks.com From smb@cs.columbia.edu Wed Mar 30 09:29:56 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2UETt5j028090 for ; Wed, 30 Mar 2005 09:29:55 -0500 (EST) Received: from machshav.com (machshav.com [147.28.0.16]) j2UETk0K019441 for ; Wed, 30 Mar 2005 09:29:46 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 0C1BCFB294; Wed, 30 Mar 2005 09:29:46 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 74D44FB28B; Wed, 30 Mar 2005 09:29:45 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id AF4263C02A6; Wed, 30 Mar 2005 09:29:42 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: der Mouse Subject: Re: [saag] Attacks on Cryptographic Hashes in Internet Protocols In-Reply-To: Your message of "Wed, 30 Mar 2005 02:40:42 EST." <200503300746.CAA04076@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Mar 2005 09:29:42 -0500 Sender: smb@cs.columbia.edu Message-Id: <20050330142942.AF4263C02A6@berkshire.machshav.com> X-Spam-Score: -3.489 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.672285 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 30 Mar 2005 14:29:57 -0000 In message <200503300746.CAA04076@Sparkle.Rodents.Montreal.QC.CA>, der Mouse wr ites: >I keep seeing references to SHA-256 and suchlike, with nothing >referenced but some FIPS publication number. This strikes me as >singularly unhelpful. If the publications are not online, there is >comparatively little point referencing them; I certainly know that *I* >would simply implement something else, probably even something >significantly less secure, rather than bothering to obtain a paper >document. And if the publications *are* online, why not include a >pointer to where they can be obtained? > Of course they're onlne. Did you even try to find it? Go to google, type "fips 180-2", and click "I'm feeling lucky". Hardly obscure. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb From pbaker@verisign.com Wed Mar 30 12:32:31 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2UHWU5j029650 for ; Wed, 30 Mar 2005 12:32:30 -0500 (EST) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) j2UHWKJ0014803 for ; Wed, 30 Mar 2005 12:32:20 -0500 (EST) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35])j2UHWF8G003288; Wed, 30 Mar 2005 09:32:16 -0800 (PST) Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Mar 2005 09:32:15 -0800 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.7226.0 Subject: RE: [saag] Attacks on Cryptographic Hashes in Internet Protocols Date: Wed, 30 Mar 2005 09:32:15 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD372500F5@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Attacks on Cryptographic Hashes in Internet Protocols Thread-Index: AcU1JnBz49WdZbJDTSm7tFGq/6WtOwAJw/6w From: "Hallam-Baker, Phillip" To: , X-OriginalArrivalTime: 30 Mar 2005 17:32:15.0811 (UTC) FILETIME=[6A5CB930:01C5354E] X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.229391 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id j2UHWU5j029650 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 30 Mar 2005 17:32:32 -0000 The situation with the SHA-1 hash function is this: We have a bridge that is used almost exclusively for pedestrian traffic and is perfectly sound for that purpose. We also have an engineering report that suggest that at some point in the future it is going to become unsafe for heavy goods vehicles. If we do nothing then it is inevitable that at some point someone will attempt to drive a truck across that is too heavy and the bridge which will fail. We need to start building a bridge now so that it is ready in time even though the bridge is sound for most purposes. And since we have no effective way to make sure that nobody takes a truck onto the bridge marked 'pedestrians only' the safest thing to do will be to close the old bridge entirely in time, even though there are certain conditions and certain loads which it is still capable of carrying safely. > -----Original Message----- > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On > Behalf Of Michael Silk > Sent: Wednesday, March 30, 2005 7:15 AM > To: saag@mit.edu > Subject: Re: [saag] Attacks on Cryptographic Hashes in > Internet Protocols > > > In 2.1 paragraph 2 you say: > " It is also important to note that the current collision attacks > require at least one of the two messages to have a fair amount of > structure in the bits of the message. This means that finding two > messages that both have the same hash value *and* are useful in a > real-world attack is more difficult than just finding two messages > with the same hash value." > > But as discussed in [1] by Ondrej Mikle and [2] by Dan > Kaminsky, _ANY_ two colliding blocks can be useful in a > real-world attack, it doesn't matter that they are virtually equal. > > -- Michael > > [1] http://cryptography.hyperlink.cz/2004/collisions.htm > [2] http://www.doxpara.com/md5_someday.pdf > > > On Wed, 30 Mar 2005 02:40:42 -0500 (EST), der Mouse > wrote: > > > hoffman-hash-attacks-00.txt > > >. > > > > We welcome comments on the draft. > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag > From michaelslists@gmail.com Wed Mar 30 12:51:58 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2UHpv5j029846 for ; Wed, 30 Mar 2005 12:51:57 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) j2UHpnw4014238 for ; Wed, 30 Mar 2005 12:51:49 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 57so168718wri for ; Wed, 30 Mar 2005 09:51:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=jNdmkgAQb9U6CJSA6COLOgj0aa5FRJnftox3oEVarMNwx7fu0h6HXkDjVuFqLaWOpArF01Zy9ihaXJXkhBxwHfFLgkjq/9MixdZWQ3VpV7LV5dn0wGuZ0Lb46jwtQ6sX7ohsrC9Hd4nHRIJt3Gv7zt3wz6kjZuGPm9f7vTiYXC8= Received: by 10.54.98.14 with SMTP id v14mr562828wrb; Wed, 30 Mar 2005 09:51:49 -0800 (PST) Received: by 10.54.35.54 with HTTP; Wed, 30 Mar 2005 09:51:48 -0800 (PST) Message-ID: <5e01c29a05033009514fd265d1@mail.gmail.com> Date: Wed, 30 Mar 2005 09:51:48 -0800 From: Michael Silk To: "Hallam-Baker, Phillip" Subject: Re: [saag] Attacks on Cryptographic Hashes in Internet Protocols In-Reply-To: <198A730C2044DE4A96749D13E167AD372500F5@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <198A730C2044DE4A96749D13E167AD372500F5@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.644453 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: michaelslists@gmail.com List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 30 Mar 2005 17:51:59 -0000 Huh? What are you responding to? My comment or the document? If it's my comment, I have no idea what your point is ... if it's to the document, I guess you are saying that 'action' needs to be taken. But we all know that ... I think (and I'm sure everyone agrees) that's it's probably better to act cautiously... ... I know I will be eagerly waiting on future documents coming from Wang et al advising us on, not only problems, but solutions :) -- Michael On Wed, 30 Mar 2005 09:32:15 -0800, Hallam-Baker, Phillip wrote: > The situation with the SHA-1 hash function is this: > > We have a bridge that is used almost exclusively for pedestrian traffic > and is perfectly sound for that purpose. We also have an engineering > report that suggest that at some point in the future it is going to > become unsafe for heavy goods vehicles. > > If we do nothing then it is inevitable that at some point someone will > attempt to drive a truck across that is too heavy and the bridge which > will fail. We need to start building a bridge now so that it is ready in > time even though the bridge is sound for most purposes. And since we > have no effective way to make sure that nobody takes a truck onto the > bridge marked 'pedestrians only' the safest thing to do will be to close > the old bridge entirely in time, even though there are certain > conditions and certain loads which it is still capable of carrying > safely. > > > > -----Original Message----- > > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On > > Behalf Of Michael Silk > > Sent: Wednesday, March 30, 2005 7:15 AM > > To: saag@mit.edu > > Subject: Re: [saag] Attacks on Cryptographic Hashes in > > Internet Protocols > > > > > > In 2.1 paragraph 2 you say: > > " It is also important to note that the current collision attacks > > require at least one of the two messages to have a fair amount of > > structure in the bits of the message. This means that finding two > > messages that both have the same hash value *and* are useful in a > > real-world attack is more difficult than just finding two messages > > with the same hash value." > > > > But as discussed in [1] by Ondrej Mikle and [2] by Dan > > Kaminsky, _ANY_ two colliding blocks can be useful in a > > real-world attack, it doesn't matter that they are virtually equal. > > > > -- Michael > > > > [1] http://cryptography.hyperlink.cz/2004/collisions.htm > > [2] http://www.doxpara.com/md5_someday.pdf > > > > > > On Wed, 30 Mar 2005 02:40:42 -0500 (EST), der Mouse > > wrote: > > > > > > hoffman-hash-attacks-00.txt > > > >. > > > > > > We welcome comments on the draft. > > _______________________________________________ > > saag mailing list > > saag@mit.edu > > https://jis.mit.edu/mailman/listinfo/saag > > > From pbaker@verisign.com Wed Mar 30 13:14:21 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2UIEJ5j000049 for ; Wed, 30 Mar 2005 13:14:19 -0500 (EST) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) j2UIEBJ0027896 for ; Wed, 30 Mar 2005 13:14:12 -0500 (EST) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34])j2UIE6F4007400; Wed, 30 Mar 2005 10:14:06 -0800 (PST) Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Mar 2005 10:14:06 -0800 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.7226.0 Subject: RE: [saag] Attacks on Cryptographic Hashes in Internet Protocols Date: Wed, 30 Mar 2005 10:14:06 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD372500F8@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Attacks on Cryptographic Hashes in Internet Protocols Thread-Index: AcU1USj7vTVbZ+HFQ+KPo7AWzMcoxwAAlffg From: "Hallam-Baker, Phillip" To: X-OriginalArrivalTime: 30 Mar 2005 18:14:06.0667 (UTC) FILETIME=[42F2F1B0:01C53554] X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.827976 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id j2UIEJ5j000049 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 30 Mar 2005 18:14:23 -0000 Like many on the list I have been having to explain to people why there is no need to panic but there is a need to make a response. I think we all understand the situation. The difficult part is how to explain the situation to others. My email inbox is still getting questions on this and I bet everyone else is as well. To return to the analogy. We do not want to create a second bridge only to discover that it suffers from the same design defect as the first. We are in the mode of the builders of the ancient cathederals. The approach to building them was that they built something and watched it to see if it fell down. If it did they would try to work out how to avoid that defect in the next. We are so used to dealling with engineering problems that are informed by the scientific approach that it comes as a shock to discover that there are still areas where the engineering is the experiment. > -----Original Message----- > From: Michael Silk [mailto:michaelslists@gmail.com] > Sent: Wednesday, March 30, 2005 12:52 PM > To: Hallam-Baker, Phillip > Cc: saag@mit.edu > Subject: Re: [saag] Attacks on Cryptographic Hashes in > Internet Protocols > > > Huh? What are you responding to? My comment or the document? > If it's my comment, I have no idea what your point is ... if > it's to the document, I guess you are saying that 'action' > needs to be taken. > > But we all know that ... I think (and I'm sure everyone > agrees) that's it's probably better to act cautiously... > > ... I know I will be eagerly waiting on future documents > coming from Wang et al advising us on, not only problems, but > solutions :) > > -- Michael > > > On Wed, 30 Mar 2005 09:32:15 -0800, Hallam-Baker, Phillip > wrote: > > The situation with the SHA-1 hash function is this: > > > > We have a bridge that is used almost exclusively for pedestrian > > traffic and is perfectly sound for that purpose. We also have an > > engineering report that suggest that at some point in the > future it is > > going to become unsafe for heavy goods vehicles. > > > > If we do nothing then it is inevitable that at some point > someone will > > attempt to drive a truck across that is too heavy and the > bridge which > > will fail. We need to start building a bridge now so that > it is ready > > in time even though the bridge is sound for most purposes. > And since > > we have no effective way to make sure that nobody takes a > truck onto > > the bridge marked 'pedestrians only' the safest thing to do > will be to > > close the old bridge entirely in time, even though there > are certain > > conditions and certain loads which it is still capable of carrying > > safely. > > > > > > > -----Original Message----- > > > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] > On Behalf > > > Of Michael Silk > > > Sent: Wednesday, March 30, 2005 7:15 AM > > > To: saag@mit.edu > > > Subject: Re: [saag] Attacks on Cryptographic Hashes in Internet > > > Protocols > > > > > > > > > In 2.1 paragraph 2 you say: > > > " It is also important to note that the current > collision attacks > > > require at least one of the two messages to have a > fair amount of > > > structure in the bits of the message. This means that > finding two > > > messages that both have the same hash value *and* are > useful in a > > > real-world attack is more difficult than just finding > two messages > > > with the same hash value." > > > > > > But as discussed in [1] by Ondrej Mikle and [2] by Dan Kaminsky, > > > _ANY_ two colliding blocks can be useful in a real-world > attack, it > > > doesn't matter that they are virtually equal. > > > > > > -- Michael > > > > > > [1] http://cryptography.hyperlink.cz/2004/collisions.htm > > > [2] http://www.doxpara.com/md5_someday.pdf > > > > > > > > > On Wed, 30 Mar 2005 02:40:42 -0500 (EST), der Mouse > > > wrote: > > > > > > > > > hoffman-hash-attacks-00.txt > > > > >. > > > > > > > > We welcome comments on the draft. > > > _______________________________________________ > > > saag mailing list > > > saag@mit.edu > > > https://jis.mit.edu/mailman/listinfo/saag > > > > > > From smb@cs.columbia.edu Wed Mar 30 14:30:58 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2UJUt5j000792 for ; Wed, 30 Mar 2005 14:30:55 -0500 (EST) Received: from machshav.com (machshav.com [147.28.0.16]) j2UJUjN8012552 for ; Wed, 30 Mar 2005 14:30:46 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 6D387FB2A3; Wed, 30 Mar 2005 14:30:45 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 97466FB294; Wed, 30 Mar 2005 14:30:43 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 9212C3BFDA9; Wed, 30 Mar 2005 14:30:40 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: saag From: "Steven M. Bellovin" To: Paul Hoffman Subject: Re: [saag] Attacks on Cryptographic Hashes in Internet Protocols In-Reply-To: Your message of "Tue, 29 Mar 2005 12:27:03 PST." Mime-Version: 1.0 Content-Type: text/plain Date: Wed, 30 Mar 2005 14:30:40 -0500 Sender: smb@cs.columbia.edu Message-Id: <20050330193040.9212C3BFDA9@berkshire.machshav.com> X-Spam-Score: -3.489 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 2.052187 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 30 Mar 2005 19:30:59 -0000 In message , Paul Hoffman writes: >Greetings again. Bruce Schneier and I have written a draft on the >status of hashes in protocols based on the recent attacks. The -00 >version can be found at >. > >Our intent is to help lay out the currently-known facts in one place >so that protocol developers can decide how to respond to the new >information. As you can see from Section 6, we do not agree on what >to do with those facts; maybe the SAAG list can help weigh the >alternatives. > >We welcome comments on the draft. > The draft is pretty good, though I'd add a sentence or two clarifying the difference between first and second pre-image attacks -- the former might turn on an output value of a particular form, and hence not be worrisome unless extended. On to the big question: I think you're both right -- and wrong... We should not switch our real algorithm requirements from SHA-1 to SHA-256 today. There's no emergency; even if the attack were close to feasible -- and it's not -- the consequences in practice seem very low. Even [PKIX-MD5-attack] isn't particularly relevant, since the party who can carry out that attack has no particular incentive to do so -- they own the private keys to both certificates, and the rest of the content is the same. (Btw, the URLs in the bibliography for [PKKX-MD5-attack] and [Preimaging-attack] appear to be swapped.) That gives us a bit of time to figure out which direction to jump -- I've heard suggestions for SHA-256 (Bruce, among others), SHA-512 (it's allegedly faster on 64-bit processors than SHA-256, and has more margin), and Whirlpool since its structure is so different. From one perspective, going to SHA-256 might be wasted effort, if the attacks on that *class* of function get sufficiently better. I think we can safely wait 1-2 years for the crypto theory community to figure out what sorts of hash functions we want. But that only tells us what we'll want in the future. The trick is getting there. Of course, the IETF itself should definitely not try to pick its own winner here, nor should it decide by itself on new signing modes -- that's the sort of thing we've traditionally left to the crypto community. The hard challenge for the IETF is not in making sure that our protocols are algorithm-agile -- I think we've done a good job engineering them for that, especially in recent years. The challenge is in figuring how to make new hash algorithms usable. Right now, even if there were easy second pre-image attacks on SHA-1, we'd be utterly unable to deal with the problem, because virtually none of the installed base of PKI software supports anything stronger. OpenSSL, in particular, does not support Whirlpool or SHA-256/384/512, nor (I believe) does Windows XP. That means that no root certificates can use any stronger hash functions, because virtually no clients will recognize the certificates. Nor can that change for about five years -- most machines are never upgraded, so they can't support the new hash algorithm. We have to wait until the current machines are largely replaced. (It would be nice if stronger hash function support were part of a Microsoft Critical Update within the next few years, bt that won't help the people who don't have auto-update turned on -- say, 90% of users of XP SP1 and earlier. If NIST (or whomever) were to start a hash function competition today, it would almost certainly take at least two years for designs, conferences, evaluations, etc. Assuming that Microsoft can code and test in 0 time, and that the Windows release cycle coincides with selection of the new algorithm, we're talking 7 years at a minimum before we can build a PKI based on some new hash function. Given that no new competition has been organized yet, and given the realities of coding, testing, and release cycles, 8-9 years is more likely as a conservative estimate. It can't really be less than 5, given how recently XP SP2 came out. And of course, we're going to have this problem again in the future, every time we need new hash functions. The most critical area is PKIs, because there's no negotiation possible at that layer -- when someone presents a certificate, you can either understand the algorithms the trust anchor uses, or you don't. In other words, even though the current algorithms are safe we don't have time to wait before new algorithms are designed; we have to mandate new ones now. A conservative strategy would be to make all of the candidates -- SHA256/384/512 and Whirlpool -- mandatory-to-implement. But we aren't going to stick with that; we're likely to downgrade one or more of them over the next few years. The interesting question for the IETF, then, is whether and how our protocols can be changed to ease the transition in the future. We can't help this transition; the same arguments about upgrade timings apply to new protocols. Should protocols that offer certificate chains offer a choice of several, where each chain contains the "same" identity but with different cryptoparameters? (Note: I'm *not* suggesting a web of trust; that's a different issue entirely.) Should receivers of certificate chains indicate what sorts of crypto parameters they accept? (A recent change to TLS permits clients to tell servers what certificate name they're expecting; should that mechanism be strengthened?) From sommerfeld@sun.com Wed Mar 30 17:29:52 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2UMTo5j002079 for ; Wed, 30 Mar 2005 17:29:50 -0500 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) j2UMTgOS024638 for ; Wed, 30 Mar 2005 17:29:43 -0500 (EST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j2UMTaZO004147; Wed, 30 Mar 2005 14:29:40 -0800 (PST) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) ESMTP id j2UMTaOp007772; Wed, 30 Mar 2005 17:29:36 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2UMTZAc022783; Wed, 30 Mar 2005 17:29:35 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2UMTZUw022782; Wed, 30 Mar 2005 17:29:35 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: RE: [saag] Attacks on Cryptographic Hashes in Internet Protocols From: Bill Sommerfeld To: "Hallam-Baker, Phillip" In-Reply-To: <198A730C2044DE4A96749D13E167AD372500F8@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD372500F8@MOU1WNEXMB04.vcorp.ad.vrsn.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1112221773.20951.590.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Wed, 30 Mar 2005 17:29:34 -0500 X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.280969 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 30 Mar 2005 22:29:53 -0000 On Wed, 2005-03-30 at 13:14, Hallam-Baker, Phillip wrote: > We are in the mode of the builders of the ancient cathederals. The > approach to building them was that they built something and watched it > to see if it fell down. If it did they would try to work out how to > avoid that defect in the next. I think you overstate how far structural engineering has evolved; that mode of learning is still present. See in particular, Petroski's "To Engineer is Human: The role of failure in successful design.". Buildings still fall down occasionally; it's just that, with more failures behind them already they've gotten better at learning from the failures. In this instance, I really hope we learn what we can from the partial "collapse" of MD5/SHA1 and use that as input to new hash functions not yet designed... - Bill From mcr@sandelman.ottawa.on.ca Wed Mar 30 18:55:04 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2UNsx5j002580 for ; Wed, 30 Mar 2005 18:55:03 -0500 (EST) Received: from pike.sandelman.ca (pike.sandelman.ca [205.150.200.164]) j2UNsoPB008475 for ; Wed, 30 Mar 2005 18:54:52 -0500 (EST) Received: from sandelman.ottawa.on.ca (wlan232.sandelman.ca [205.150.200.232]) by pike.sandelman.ca (Postfix) with ESMTP id 75B6F64C62; Wed, 30 Mar 2005 18:54:44 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id E9C34BD7B; Wed, 30 Mar 2005 18:54:43 -0500 (EST) To: Bill Sommerfeld Subject: Re: [saag] Attacks on Cryptographic Hashes in Internet Protocols In-Reply-To: Message from Bill Sommerfeld of "Wed, 30 Mar 2005 17:29:34 EST." <1112221773.20951.590.camel@thunk> References: <198A730C2044DE4A96749D13E167AD372500F8@MOU1WNEXMB04.vcorp.ad.vrsn.com> <1112221773.20951.590.camel@thunk> X-Mailer: MH-E 7.82; nmh 1.0.4+dev; XEmacs 21.4 (patch 17) Date: Wed, 30 Mar 2005 18:54:43 -0500 Message-ID: <2968.1112226883@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.695917 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 30 Mar 2005 23:55:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bill" == Bill Sommerfeld writes: >> We are in the mode of the builders of the ancient >> cathederals. The approach to building them was that they built >> something and watched it to see if it fell down. If it did they >> would try to work out how to avoid that defect in the next. Bill> I think you overstate how far structural engineering has Bill> evolved; that mode of learning is still present. Bill> See in particular, Petroski's "To Engineer is Human: The role Bill> of failure in successful design.". Buildings still fall down Bill> occasionally; it's just that, with more failures behind them Bill> already they've gotten better at learning from the failures. Perhaps, more to the point, all of the buildings that are up, are not of a mere two designs. - -- ] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [ ] mcr @ xelerance.com Now doing IPsec training, see |net architect[ ] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQks8QoqHRg3pndX9AQETjwP8Ce1yAlMJkur9kcWJi36BRBp8givrka18 +U6kh54d01x+GpQRq+I18ZuawjrLg5fDXcdlsarswMYAS9LUSw1/wH1C5NzqBGNF Oo/nybvDSvKMrPzcGYsDUq6tdZppxszXxL5QGdre4DbKhiLotiSWgP12AhTwD35B MFr/7WTXWEU= =cgi2 -----END PGP SIGNATURE----- From pbaker@verisign.com Wed Mar 30 19:38:39 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2V0cc5j002903 for ; Wed, 30 Mar 2005 19:38:38 -0500 (EST) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) j2V0cN8r007277 for ; Wed, 30 Mar 2005 19:38:23 -0500 (EST) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35])j2V0cI2v028035; Wed, 30 Mar 2005 16:38:22 -0800 (PST) Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Mar 2005 16:38:18 -0800 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.7226.0 Subject: RE: [saag] Attacks on Cryptographic Hashes in Internet Protocols Date: Wed, 30 Mar 2005 16:38:17 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD37250103@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Attacks on Cryptographic Hashes in Internet Protocols Thread-Index: AcU0o/SRjBFCH5dQTXCmC/Sk7V+STAA4ugUQ From: "Hallam-Baker, Phillip" To: "Paul Hoffman" , X-OriginalArrivalTime: 31 Mar 2005 00:38:18.0339 (UTC) FILETIME=[EED0F330:01C53589] X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.914892 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id j2V0cc5j002903 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 31 Mar 2005 00:38:41 -0000 > > Greetings again. Bruce Schneier and I have written a draft on the > status of hashes in protocols based on the recent attacks. The -00 > version can be found at > . I agree with Steve's comments on shifting to SHA-256. At the RSA show I asked Adi Shamir whether he thought we should switch immediately or wait to see the effect on SHA-256, he said wait as did every other cryptographer I asked in private. The design parameters used for hashes are very conservative. It is worth noting that SHA-1 is still more secure than the designed level of security for MD5. We reject a hash function when it provides less than the theoretical level of security. So what do we do if SHA-56 turns out to only provide say 200 bits worth of security? Another point that the paper should consider is that a trusted third party can prevent a lot of the attacks against certificates by ensuring that the serial number in the certificate is not guessable. Attacks where a CA deliberately created a pair of certs of this type do not need to be considered since they can issue any cert they choose. Phill From phoffman@imc.org Wed Mar 30 20:29:43 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2V1Tg5j003215 for ; Wed, 30 Mar 2005 20:29:42 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) j2V1TYwM021380 for ; Wed, 30 Mar 2005 20:29:35 -0500 (EST) Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2V1TWTe044320 for ; Wed, 30 Mar 2005 17:29:33 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <198A730C2044DE4A96749D13E167AD37250103@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD37250103@MOU1WNEXMB04.vcorp.ad.vrsn.com> Date: Wed, 30 Mar 2005 17:29:29 -0800 To: From: Paul Hoffman Subject: RE: [saag] Attacks on Cryptographic Hashes in Internet Protocols Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.764723 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 31 Mar 2005 01:29:44 -0000 At 4:38 PM -0800 3/30/05, Hallam-Baker, Phillip wrote: >Another point that the paper should consider is that a trusted third >party can prevent a lot of the attacks against certificates by ensuring >that the serial number in the certificate is not guessable. In Section 5.1, the first bullet point is: o making part of the certificate serial number unpredictable to the attacker Please suggest text to make that clearer. --Paul Hoffman, Director --Internet Mail Consortium From ben@algroup.co.uk Thu Mar 31 04:29:29 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2V9TS5j006745 for ; Thu, 31 Mar 2005 04:29:28 -0500 (EST) Received: from mail.links.org (mail.links.org [217.155.92.109]) j2V9TKPf024630 for ; Thu, 31 Mar 2005 04:29:21 -0500 (EST) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 265E833C5F; Thu, 31 Mar 2005 10:29:20 +0100 (BST) Message-ID: <424BC276.4020809@algroup.co.uk> Date: Thu, 31 Mar 2005 10:27:18 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: michaelslists@gmail.com Subject: Re: [saag] Attacks on Cryptographic Hashes in Internet Protocols References: <200503300746.CAA04076@Sparkle.Rodents.Montreal.QC.CA> <5e01c29a05033004149c6b940@mail.gmail.com> In-Reply-To: <5e01c29a05033004149c6b940@mail.gmail.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.796596 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 31 Mar 2005 09:29:30 -0000 Michael Silk wrote: > In 2.1 paragraph 2 you say: > " It is also important to note that the current collision attacks > require at least one of the two messages to have a fair amount of > structure in the bits of the message. This means that finding two > messages that both have the same hash value *and* are useful in a > real-world attack is more difficult than just finding two messages > with the same hash value." > > But as discussed in [1] by Ondrej Mikle and [2] by Dan Kaminsky, _ANY_ > two colliding blocks can be useful in a real-world attack, it doesn't > matter that they are virtually equal. There was a huge discussion resulting from [2], and the conclusion was not that these attacks were obviously worrying. > [1] http://cryptography.hyperlink.cz/2004/collisions.htm > [2] http://www.doxpara.com/md5_someday.pdf -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 genious_2k1@yahoo.co.in Mon Apr 11 16:44:32 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j3BKiT5j002249 for ; Mon, 11 Apr 2005 16:44:29 -0400 (EDT) Received: from web8403.mail.in.yahoo.com (web8403.mail.in.yahoo.com [202.43.219.151])j3BKiJIo000557 for ; Mon, 11 Apr 2005 16:44:20 -0400 (EDT) Received: (qmail 93246 invoked by uid 60001); 11 Apr 2005 20:44:19 -0000 Message-ID: <20050411204419.93244.qmail@web8403.mail.in.yahoo.com> Received: from [210.7.64.187] by web8403.mail.in.yahoo.com via HTTP; Mon, 11 Apr 2005 13:44:18 PDT Date: Mon, 11 Apr 2005 13:44:18 -0700 (PDT) From: Vishal Gupta To: saag@mit.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1189824828-1113252258=:93242" X-Spam-Score: -3.585 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.810927 Subject: [saag] New to this mailing list X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 11 Apr 2005 20:44:32 -0000 --0-1189824828-1113252258=:93242 Content-Type: text/plain; charset=us-ascii Hi, A very good morning to all members. My name is Vishal Gupta. I'm an Indian & I aspire to someday provide for a secure internet for all. I'm a BSC graduate in IT. I have also done MCP along with CCNA. As such I have a bit of experience in the network field but i'm quite new to most technical terminologies I got to read on the IETF & RFC websites. Well you'll must be thinking what a novice like me is doing on a professional mailing list. So here's why : While doing my graduation course when i was learning all kinds of various languages apart from other stuff I realised how unsecure the web was. Actually i'm sure a very few people know about this. Well the point is I started doing my R & D on my computer & find that first of all I can change my identity on the internet. By identity i mean the IP as well as the MAC address of my system. So i can do anything on the web without anyone else knowing i did it. I also know that the system keeps quite a record of where we go & what we do on the internet. But there is a pretty simple workaround to that. There are plenty of softwares available on the internet that help us accomplish just that. In my case i prefer doing that manually. That way I know what's where. Well I dont know if any of you noticed this or not but the softwares that are available on the internet let them be firewalls or antivirus softwares all of them just protect individual systems & not the information that's go! ing out from the system. So the above two things combined I have a cracker who has access to the "NETWORK" spying on whatever i do. Come to think of it isnt the vulnerability built into our system so that it can be cracked?? For a week i struggled on this one but finally i seem to have a few points that could be considered to improve security : 1> What if no one couldnt configure a ip address or a mac address on his/her system. Thinking logically no one actually needs to do that. All we require is a DHCP server to be mandatory on all netwoks. This will do two things (1) No one can forge his/her identity on the network. (2) No one can use any kind of mitm attacks to forge network configs. 2> The TCP/IP protocol needs to be redone completely. It's just to slow for today's networks & not much security either. I thought alot about this also & here's what I have : What we are aiming at is security on the network & not on the system alone so we obviiously need to encrypt the data that we send at all times. It does get encrypted but people are able to break that encryption too. A workaround for this could be if we were to use a random encryption which would be decided upon in the first handshake. Also along with this we need to reduce the amount of overhead TCP/IP causes on the network possibly something like a byte value where the first bit would say what encryption to use, the second would say if the data is compressed or not & so on. Just one or two bytes do the job for which TCP/IP takes a multiple of 32 bytes. Well you might say its a processing overhead for a PC but with the kind of systems available today that should not be a problem. Well this is my first venture into a technical mailing list in a true sense. Please write to me any suggestions/comments that you may have for me. Thanks --------------------------------- Do you Yahoo!? Yahoo! Small Business - Try our new resources site! --0-1189824828-1113252258=:93242 Content-Type: text/html; charset=us-ascii
Hi,
    A very good morning to all members. My name is Vishal Gupta. I'm an Indian & I aspire to someday provide for a secure internet for all. I'm a BSC graduate in IT. I have also done MCP along with CCNA. As such I have a bit of experience in the network field but i'm quite new to most technical terminologies I got to read on the IETF & RFC websites. Well you'll must be thinking what a novice like me is doing on a professional mailing list. So here's why :
 While doing my graduation course when i was learning all kinds of various languages apart from other stuff I realised how unsecure the web was. Actually i'm sure a very few people know about this. Well the point is I started doing my R & D on my computer & find that first of all I can change my identity on the internet. By identity i mean the IP as well as the MAC address of my system. So i can do anything on the web without anyone else knowing i did it. I also know that the system keeps quite a record of where we go & what we do on the internet. But there is a pretty simple workaround to that. There are plenty of softwares available on the internet that help us accomplish just that. In my case i prefer doing that manually. That way I know what's where. Well I dont know if any of you noticed this or not but the softwares that are available on the internet let them be firewalls or antivirus softwares all of them just! protect individual systems & not the information that's going out from the system.
    So the above two things combined I have a cracker who has access to the "NETWORK" spying on whatever i do. Come to think of it isnt the vulnerability built into our system so that it can be cracked??
   For a week i struggled on this one but finally i seem to have a few points that could be considered to improve security :
1> What if no one couldnt configure a ip address or a mac address on his/her system. Thinking logically no one actually needs to do that. All we require is a DHCP server to be mandatory on all netwoks. This will do two things (1) No one can forge his/her identity on the network. (2) No one can use any kind of mitm attacks to forge network configs.
2> The TCP/IP protocol needs to be redone completely. It's just to slow for today's networks & not much security either. I thought alot about this also & here's what I have :
   What we are aiming at is security on the network & not on the system alone so we obviiously need to encrypt the data that we send at all times. It does get encrypted but people are able to break that encryption too. A workaround for this could be if we were to use a random encryption which would be decided upon in the first handshake. Also along with this we need to reduce the amount of overhead TCP/IP causes on the network possibly something like a byte value where the first bit would say what encryption to use, the second would say if the data is compressed or not & so on. Just one or two bytes do the job for which TCP/IP takes a multiple of 32 bytes. Well you might say its a processing overhead for a PC but with the kind of systems available today that should not be a problem.
 
Well this is my first venture into a technical mailing list in a true sense. Please write to me any suggestions/comments that you may have for me.
 
Thanks

Do you Yahoo!?
Yahoo! Small Business - Try our new resources site! --0-1189824828-1113252258=:93242-- From bew@cisco.com Fri Apr 15 20:17:42 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j3G0He5j001881 for ; Fri, 15 Apr 2005 20:17:40 -0400 (EDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) j3G0HXpg024226 for ; Fri, 15 Apr 2005 20:17:33 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 15 Apr 2005 17:17:33 -0700 Received: from [128.107.178.85] (dhcp-128-107-178-85.cisco.com [128.107.178.85]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3G0HS2w000040; Fri, 15 Apr 2005 17:17:29 -0700 (PDT) Message-ID: <42605996.1060308@cisco.com> Date: Fri, 15 Apr 2005 17:17:26 -0700 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: saag@mit.edu, cfrg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.804471 cc: msec@securemulticast.org Subject: [saag] RSA Signature padding recommendations X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 16 Apr 2005 00:17:43 -0000 When an RSA signature is created, the signature algorithm input encapsulates the hash output with a padding method. RFC 3447 (PKCS #1 v2.1) specifies two methods of padding: EMSA-PKCS1-v1_5 and EMSA-PSS. EMSA-PKCS1-v1_5 is the traditional method of padding, but since attacks have been found on that method PSS was added to PKCS#1 v2.1. Due to its improved security properties, new protocols using RSA signatures are being given the advice to adopt PSS as a MUST. However, there are some complications with using PSS. 1. The base PSS specification has intellectual property claimed on it. Whether or not the construction of PSS specified in RFC 3447 is covered is not clear. (No IPR disclosure has been filed with the IETF. However, the only publicly available statement regarding licensing its use applies to IEEE P1363, not the IETF.) 2. Commonly used crypto toolkits and RSA hardware accelerators that I have investigated do not typically support PSS padding. So while PSS padding is a better security method, specifying it as a required method will likely not result in those standards being adopted until these issues are sorted out. RFC 3447 suggests that no known attacks are known against the EMSA-PKCS-v1_5 encoding method, yet "a gradual transition to EMSA-PSS is recommended as a precaution against future developments". It doesn't seem to me as if such a transition is yet possible, but I'd be interested in other hearing other opinions. Thanks, Brian -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From paul.hoffman@vpnc.org Tue Apr 19 12:33:06 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j3JGX05j029906 for ; Tue, 19 Apr 2005 12:33:05 -0400 (EDT) Received: from above.proper.com (above.proper.com [208.184.76.39]) j3JGWrQc014732 for ; Tue, 19 Apr 2005 12:32:54 -0400 (EDT) Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JGWoYu008867 for ; Tue, 19 Apr 2005 09:32:52 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 19 Apr 2005 09:32:46 -0700 To: saag@mit.edu From: Paul Hoffman Subject: Re: [saag] Attacks on Cryptographic Hashes in Internet Protocols Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.519467 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 19 Apr 2005 16:33:07 -0000 Greetings again. Bruce Schneier and I have updated our draft on the status of hashes in protocols based on the recent attacks. The -02 version can be found at . (The -01 draft had a bad typo in it and was quickly replaced...) We definitely appreciate the comments we received on the -00, and we continue to welcome comments on the draft. --Paul Hoffman, Director --VPN Consortium From genious_2k1@yahoo.co.in Wed Apr 20 13:23:21 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j3KHNK5j007851 for ; Wed, 20 Apr 2005 13:23:20 -0400 (EDT) Received: from web8410.mail.in.yahoo.com (web8410.mail.in.yahoo.com [202.43.219.158])j3KHNARa009053 for ; Wed, 20 Apr 2005 13:23:11 -0400 (EDT) Received: (qmail 79540 invoked by uid 60001); 20 Apr 2005 17:23:09 -0000 Message-ID: <20050420172309.79538.qmail@web8410.mail.in.yahoo.com> Received: from [210.7.64.153] by web8410.mail.in.yahoo.com via HTTP; Wed, 20 Apr 2005 10:23:09 PDT Date: Wed, 20 Apr 2005 10:23:09 -0700 (PDT) From: Vishal Gupta To: saag@mit.edu In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -3.685 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.591674 Subject: [saag] Re: saag Digest, Vol 27, Issue 3 - probable solution X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 20 Apr 2005 17:23:22 -0000 Hi, I read with great admiration of how quickly things are worked out and put into place. Most of us dont even know what goes on behind the scenes. Till date what has been happening is that the complexity of the algos/hashes has increased but the implementation remains the same. So its actually just a matter of how much time a person has before he will give up on trying to break it. Eventually it will break. That is actually the moral of the story that its time that we change the way these algos or hashes are implemented in protocols. What i mean to say is that probably we could use a random hash/algo which only the source & destination would know about. Here the algo/hash traits would be stored on the local computers in an encrypted format using a "user unknown" or in other words "undocumented" hash/algo. The user actually doesnt need to know about this & nor does anyone else. Actually even if talk of a programmer he too needs to be concerned about the functions in the protocols & not how they are being implemented by the functions. The fact is not even we will be able to tell which one is being used here. Also in this there will be a fixed order in which these algos will be stored & only the order will be sent over the internet & the processing & unencrypting part of it will be left to the destination computer. As it is today the average processing power of the computer is sufficient & that should not be a problem. Please do provide me with any comments or feedback regarding this. Thank You __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From hartmans@MIT.EDU Sun Apr 24 11:32:31 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j3OFWS5j014912 for ; Sun, 24 Apr 2005 11:32:28 -0400 (EDT) Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178])j3OFWLrm013776 for ; Sun, 24 Apr 2005 11:32:22 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 2BC3BE0063; Sun, 24 Apr 2005 11:32:17 -0400 (EDT) To: Vishal Gupta Subject: Re: [saag] Re: saag Digest, Vol 27, Issue 3 - probable solution References: <20050420172309.79538.qmail@web8410.mail.in.yahoo.com> From: Sam Hartman Date: Sun, 24 Apr 2005 11:32:17 -0400 In-Reply-To: <20050420172309.79538.qmail@web8410.mail.in.yahoo.com> (Vishal Gupta's message of "Wed, 20 Apr 2005 10:23:09 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.947269 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 24 Apr 2005 15:32:32 -0000 >>>>> "Vishal" == Vishal Gupta writes: Vishal> Hi, I read with great admiration of how quickly things are Vishal> worked out and put into place. Most of us dont even know Vishal> what goes on behind the scenes. Till date what has been Vishal> happening is that the complexity of the algos/hashes has Vishal> increased but the implementation remains the same. So its Vishal> actually just a matter of how much time a person has Vishal> before he will give up on trying to break it. Eventually Vishal> it will break. That is actually the moral of the story Vishal> that its time that we change the way these algos or hashes Vishal> are implemented in protocols. What i mean to say is that Vishal> probably we could use a random hash/algo which only the Vishal> source & destination would know about. Here the algo/hash Vishal> traits would be stored on the local computers in an Vishal> encrypted format using a "user unknown" or in other words Vishal> "undocumented" hash/algo. The user actually doesnt need Vishal> to know about this & nor does anyone else. The security community has a strong and justified bias against closed or undisclosed algorithms. The problem is that without being subject to cryptanalysis in the public community we do not know whether the algorithm is strong enough. Trying all the algorithms available only increases the work factor by the number of algorithms. If you have 5, that's only 5 times harder, which isn't much. If you have 2^128 algorithms to choose from, that's interesting. However you don't have code space for 2^128 unrelated algorithms. One thing you can do which makes excellent cryptographic sense is to choose from a family of hash functions paramaterized on some random variable. This is similar to what people have been talking about when they say randomized hashing. Depending on what you can prove about the particular strategy you are using to randomize a normal hash function and about the hash function that is being randomized, they may end up being the same. --Sam From jwkckid1@ix.netcom.com Mon Apr 25 23:11:41 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j3Q3Bd5j029653 for ; Mon, 25 Apr 2005 23:11:39 -0400 (EDT) Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157])j3Q3BWWa028039 for ; Mon, 25 Apr 2005 23:11:32 -0400 (EDT) Received: from 1cust207.tnt59.dfw5.da.uu.net ([67.203.43.207] helo=ix.netcom.com) by tisch.mail.mindspring.net with esmtp (Exim 3.36 #1) id 1DQGTz-0001JG-00; Mon, 25 Apr 2005 23:11:31 -0400 Message-ID: <426DCB99.EF0B235E@ix.netcom.com> Date: Mon, 25 Apr 2005 22:03:22 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: aba isc list Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.945825 cc: saag Subject: [saag] From: NIST SP 800-53 Errata Sheet (through 04/22/05) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 26 Apr 2005 03:11:42 -0000 All, The following may be of interest to some of you: *** The following message is from the NIST FISMA Implementation Project *** Subject: NIST SP 800-53 Errata Sheet (through 04/22/2005) A listing of minor changes to NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems, February 2005 (including updates through 04-22-2005) is now available at the Computer Security Division website, http://csrc.nist.gov/publications/ . From this site, go to Special Publications and then to 800-53. The errata sheet is on page v of SP 800-53 noting the changes incorporated into the document. The majority of the changes to NIST SP 800-53 in this errata sheet are updates to Appendix G, Security Control Mapping Table for Special Publication 800-26, Security Self-Assessment Guide for Information Technology Systems. As we move towards the implementation of FIPS 200, we may periodically make minor changes to the NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems. Any changes will be documented in an updated errata sheet and an announcement will be posted to this mailing list as well as to the website, http://csrc.nist.gov/sec-cert . Arnold Johnson for Ron Ross FISMA Implementation Project Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From tim.polk@nist.gov Thu Apr 28 17:26:10 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j3SLQ85j003709 for ; Thu, 28 Apr 2005 17:26:08 -0400 (EDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) j3SLPxKR013781 for ; Thu, 28 Apr 2005 17:25:59 -0400 (EDT) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j3SLPSa9006043 for ; Thu, 28 Apr 2005 17:25:28 -0400 Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j3SLPJ9r008141 for ; Thu, 28 Apr 2005 17:25:19 -0400 (EDT) Message-Id: <5.1.0.14.2.20050428170700.03857b08@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 28 Apr 2005 17:26:42 -0400 To: saag@mit.edu From: Tim Polk Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_807180704==_" X-NIST-MailScanner: Found to be clean X-MailScanner-From: tim.polk@nist.gov X-Spam-Score: -3.912 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.277073 Subject: [saag] Fwd: Cryptographic Hash Workshop - Call for Participation X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 28 Apr 2005 21:26:11 -0000 --=====================_807180704==_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Folks,

Based on the traffic on this list over the last two months, I believe this announcement will be of some interest...

NIST has just announced a Cryptographic Hash Workshop this Fall.  This workshop will address a broad range of technical and policy issues ranging from attacks on the NIST approved algorithms to migration strategies.  We will look to the results of this workshop to establish direction for future NIST hash initiatives.  For details, please see Shu-jen Chang's email, below, and the attached call for participation.

I hope that many of you will participate, so that the needs of current and future Internet protocols are adequately represented in this process!

Thanks,

Tim Polk

X-Sieve: CMU Sieve 2.2
X-Sender: sjchang@email.nist.gov
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Thu, 28 Apr 2005 13:54:13 -0400
To: shu-jen.chang@nist.gov
From: Shu-jen Chang <shu-jen.chang@nist.gov>
Subject: Cryptographic Hash Workshop - Call for Participation
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: shu-jen.chang@nist.gov

Cryptographic Hash Workshop
NIST Gaithersburg, MD (Green Auditorium)
Oct. 31-Nov. 1, 2005
Submission Deadline: July 15, 2005 (Workshop without Proceedings)

Recently a team of researchers reported that the SHA-1 function offers significantly less collision resistance than could be expected from a cryptographic hash function of its output size.  NIST plans to host a Cryptographic Hash Workshop on Oct. 31-Nov. 1, 2005 to solicit public input in how best to respond to the current state of research in this area.  The workshop has the following goals:

=B7       Assess the status of the current NIST-approved hash functions, i.e., the SHA-256 and SHA-512 families in        addition to SHA-1;
=B7       Discuss short term actions to mitigate the potential problems with the various applications of the approved     hash functions;
=B7       Discuss the conditions that would warrant an early transition away from any of the approved hash functions;
=B7       Discuss the potential replacement options for any of the approved hash functions;
=B7       Clarify the properties of unkeyed cryptographic hash functions required for different applications such as      digital signatures, key derivation, message authentication, and random number generation.

NIST solicits papers, presentations, case studies, panel proposals, and participation from any interested parties, including researchers, systems architects, vendors, and users.  NIST will post the accepted papers and presentations on the workshop web site and include these in a workshop handout. However, no formal workshop proceedings will be published. NIST encourages presentations and reports on preliminary work that participants plan to publish elsewhere. Topics for submissions are included in the attached document, and details about the workshop will be available at the following web site shortly: http://www.nist.gov/hash-function


Shu-jen Chang
Computer Security Division
NIST
--=====================_807180704==_ Content-Type: application/pdf; name="Cryptographic Hash Workshop CFP.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Cryptographic Hash Workshop CFP.pdf" JVBERi0xLjQNJeLjz9MNCjEzOSAwIG9iajw8L0hbODExIDIzN10vTGluZWFyaXplZCAxL0UgMTg4 NzQvTCAzMTAxMC9OIDIvTyAxNDIvVCAyODE4Mj4+DWVuZG9iag0gICAgICAgICAgICAgICAgICAg DQp4cmVmDQoxMzkgMjUNCjAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDAwMTIyNSAwMDAwMCBuDQow MDAwMDAwODExIDAwMDAwIG4NCjAwMDAwMDE0NjEgMDAwMDAgbg0KMDAwMDAwMTc4MCAwMDAwMCBu DQowMDAwMDAyNDU3IDAwMDAwIG4NCjAwMDAwMDI4ODQgMDAwMDAgbg0KMDAwMDAwMjkyMCAwMDAw MCBuDQowMDAwMDAzMTYwIDAwMDAwIG4NCjAwMDAwMDM0MDYgMDAwMDAgbg0KMDAwMDAwMzQ4MyAw MDAwMCBuDQowMDAwMDA0MTI2IDAwMDAwIG4NCjAwMDAwMDQyNTkgMDAwMDAgbg0KMDAwMDAwNDU1 NyAwMDAwMCBuDQowMDAwMDA1MjQyIDAwMDAwIG4NCjAwMDAwMDU4MjIgMDAwMDAgbg0KMDAwMDAw NjQ3NSAwMDAwMCBuDQowMDAwMDA3MDIyIDAwMDAwIG4NCjAwMDAwMDc1NTMgMDAwMDAgbg0KMDAw MDAwODE2OSAwMDAwMCBuDQowMDAwMDA4NzA3IDAwMDAwIG4NCjAwMDAwMTEzNzcgMDAwMDAgbg0K MDAwMDAxODQ1MSAwMDAwMCBuDQowMDAwMDE4NjgyIDAwMDAwIG4NCjAwMDAwMDEwNDggMDAwMDAg bg0KdHJhaWxlcg0KPDwvU2l6ZSAxNjQvUHJldiAyODE3MC9YUmVmU3RtIDEwNDgvUm9vdCAxNDAg MCBSL0luZm8gMTIgMCBSL0lEWzwyMzI0ZmU4NTdhZWQ5MjQ0MzgwYmM4YjAwNDhkZTU5Mz48ZTBj ZDgzYmU2MTk3NWM0Y2E1NjVjOGMxOGEzZTczMzE+XT4+DQpzdGFydHhyZWYNCjANCiUlRU9GDQog ICAgICAgICAgICANCjE0MSAwIG9iajw8L0xlbmd0aCAxNTAvRmlsdGVyL0ZsYXRlRGVjb2RlL0Mg MTU4L0wgMTQyL1MgNzc+PnN0cmVhbQ0KeNpiYGBgZmBgOcHAysDAmc3Ax4AAfAwsQFEWBo4JDK8y GBjOQYUZJ2g6rgl0C17qAOQIdnQASSaNjg6QEiBgYWAIsgDSokAsDhZRYeDluLHAGWhyGrMHq1I8 M4djq5ASo0n7H9tHLvybJm37w2Pgx1DAvwBiPAcDQ3QFyEwgBhnExsAQLAnhc8SDadatDgABBgAg Zhr6DQplbmRzdHJlYW0NZW5kb2JqDTE2MyAwIG9iajw8L1NpemUgMTM5L0xlbmd0aCAyNy9GaWx0 ZXIvRmxhdGVEZWNvZGUvRGVjb2RlUGFybXM8PC9Db2x1bW5zIDMvUHJlZGljdG9yIDEyPj4vV1sx IDEgMV0vVHlwZS9YUmVmL0luZGV4WzEzIDEyNl0+PnN0cmVhbQ0KeNpiYmJjYGJgYBzFgwUzzqWH PQABBgDDSAIfDQplbmRzdHJlYW0NZW5kb2JqDTE0MCAwIG9iajw8L1BhZ2VzIDEwIDAgUi9UeXBl L0NhdGFsb2cvUGFnZUxhYmVscyA4IDAgUi9TdHJ1Y3RUcmVlUm9vdCAxMyAwIFIvTWV0YWRhdGEg MTEgMCBSL1BpZWNlSW5mbzw8L01hcmtlZFBERjw8L0xhc3RNb2RpZmllZChEOjIwMDUwNDI4MTEx NTUyKT4+Pj4vTGFzdE1vZGlmaWVkKEQ6MjAwNTA0MjgxMTE1NTIpL01hcmtJbmZvPDwvTWFya2Vk IHRydWUvTGV0dGVyc3BhY2VGbGFncyAwPj4+Pg1lbmRvYmoNMTQyIDAgb2JqPDwvQ29udGVudHNb MTQ5IDAgUiAxNTIgMCBSIDE1MyAwIFIgMTU0IDAgUiAxNTUgMCBSIDE1NiAwIFIgMTU3IDAgUiAx NTggMCBSXS9UeXBlL1BhZ2UvUGFyZW50IDEwIDAgUi9Sb3RhdGUgMC9NZWRpYUJveFswIDAgNjEy IDc5Ml0vQ3JvcEJveFswIDAgNjEyIDc5Ml0vUmVzb3VyY2VzPDwvQ29sb3JTcGFjZTw8L0NTMCAx NDUgMCBSPj4vRm9udDw8L1RUMCAxNDMgMCBSL1RUMSAxNDQgMCBSL0MyXzAgMTUwIDAgUj4+L1By b2NTZXRbL1BERi9UZXh0XS9FeHRHU3RhdGU8PC9HUzAgMTQ4IDAgUj4+Pj4vU3RydWN0UGFyZW50 cyAwPj4NZW5kb2JqDTE0MyAwIG9iajw8L1R5cGUvRm9udC9FbmNvZGluZy9XaW5BbnNpRW5jb2Rp bmcvQmFzZUZvbnQvVGltZXNOZXdSb21hblBTTVQvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDIyOS9T dWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDE0NiAwIFIvV2lkdGhzWzI1MCAwIDQwOCAw IDAgMCAwIDAgMzMzIDMzMyAwIDAgMjUwIDMzMyAyNTAgMjc4IDUwMCA1MDAgNTAwIDUwMCAwIDUw MCA1MDAgMCA1MDAgMCAyNzggMjc4IDAgMCAwIDQ0NCAwIDcyMiAwIDY2NyA3MjIgNjExIDU1NiA3 MjIgNzIyIDMzMyAwIDAgNjExIDg4OSA3MjIgNzIyIDU1NiAwIDY2NyA1NTYgNjExIDcyMiAwIDk0 NCAwIDAgMCAwIDAgMCAwIDAgMCA0NDQgNTAwIDQ0NCA1MDAgNDQ0IDMzMyA1MDAgNTAwIDI3OCAw IDUwMCAyNzggNzc4IDUwMCA1MDAgNTAwIDUwMCAzMzMgMzg5IDI3OCA1MDAgNTAwIDcyMiA1MDAg NTAwIDQ0NCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDQ0NF0+Pg1l bmRvYmoNMTQ0IDAgb2JqPDwvVHlwZS9Gb250L0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9CYXNl Rm9udC9UaW1lc05ld1JvbWFuUFMtQm9sZE1UL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAxMjEvU3Vi dHlwZS9UcnVlVHlwZS9Gb250RGVzY3JpcHRvciAxNDcgMCBSL1dpZHRoc1syNTAgMCAwIDAgMCAw IDAgMCAzMzMgMzMzIDAgMCAyNTAgMzMzIDI1MCAwIDUwMCA1MDAgNTAwIDUwMCAwIDUwMCAwIDAg MCAwIDMzMyAwIDAgMCAwIDAgOTMwIDcyMiAwIDAgNzIyIDAgMCAwIDAgMCA1MDAgMCAwIDAgNzIy IDAgNjExIDAgMCA1NTYgMCAwIDAgMTAwMCAwIDAgMCAwIDAgMCAwIDAgMCA1MDAgNTU2IDQ0NCA1 NTYgNDQ0IDMzMyA1MDAgNTU2IDI3OCAwIDU1NiAyNzggODMzIDU1NiA1MDAgNTU2IDAgNDQ0IDM4 OSAzMzMgNTU2IDUwMCA3MjIgMCA1MDBdPj4NZW5kb2JqDTE0NSAwIG9ialsvSUNDQmFzZWQgMTU5 IDAgUl0NZW5kb2JqDTE0NiAwIG9iajw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udEJCb3hbLTU2 OCAtMzA3IDIwMDAgMTAwN10vRm9udE5hbWUvVGltZXNOZXdSb21hblBTTVQvRmxhZ3MgMzQvU3Rl bVYgODIvQ2FwSGVpZ2h0IDY1Ni9YSGVpZ2h0IDAvQXNjZW50IDg5MS9EZXNjZW50IC0yMTYvSXRh bGljQW5nbGUgMC9Gb250RmFtaWx5KFRpbWVzIE5ldyBSb21hbikvRm9udFN0cmV0Y2gvTm9ybWFs L0ZvbnRXZWlnaHQgNDAwPj4NZW5kb2JqDTE0NyAwIG9iajw8L1R5cGUvRm9udERlc2NyaXB0b3Iv Rm9udEJCb3hbLTU1OCAtMzA3IDIwMDAgMTAyNl0vRm9udE5hbWUvVGltZXNOZXdSb21hblBTLUJv bGRNVC9GbGFncyAzNC9TdGVtViAxMzYvQ2FwSGVpZ2h0IDY1Ni9YSGVpZ2h0IDAvQXNjZW50IDg5 MS9EZXNjZW50IC0yMTYvSXRhbGljQW5nbGUgMC9Gb250RmFtaWx5KFRpbWVzIE5ldyBSb21hbikv Rm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNzAwPj4NZW5kb2JqDTE0OCAwIG9iajw8L1R5 cGUvRXh0R1N0YXRlL1NBIGZhbHNlL09QIGZhbHNlL1NNIDAuMDIvb3AgZmFsc2UvT1BNIDE+Pg1l bmRvYmoNMTQ5IDAgb2JqPDwvTGVuZ3RoIDU3My9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0K SImMVF1vmzAUfedX3EcjFccGDHiqKrVJ1Q+p3bQg7WHZAzEm8UZxZMO67tfPdtpGlRJpQoJry5xz 7j0HZl/g/Hz2ML9bAIGLi6vFHKLZfElAWLfhL7BiiCgot3/j9jc2uqqjWV0ToFB3EcGEUFcJ8BXJ XPns36otUOKff92qNm6BeRUA9xUnUBKOK8Y5h/op+o7m5iVOSrSLkxSNcYH0xjS7rXKVgNvGbuGb Nr/sVu8g/lHfR9d1dP3g1R46oG8dfFB4hLngJU6d2mLP/Hi3rOGmUeNWGruezOYMHhawQo76Jk6R kXKAy6lVozZqeoortIpPakiPaghTKvyUkjCm1E/pmLAqxywnNN0L+yxGDBlNHvVvDE4NPYOUxDki 7CR/9pGfHvhJ8eZScZK+pLiqCA2OoOW0flLWKj1AK5u2V4P8BHH906HRrEyZw6IpZWV4spzvoxKo Sv6eiMJzcZwx5mBdFNoI3U/9C1Dmm3GdrNC7sc/OAj2NsDNaSNmqYWNXcWA8RJEE5NAAxzzNGH1F DdKOTCT/71QwjtOKsJCKk3DspMGHAYf+j084L3CRkiLfG/xVCjmMvQt+haCBUTY+XqA7MNLKxgif SFfvtBllC+O2Gd1NwvL2MqHQTYMYvT266/w5qzaD6pRoBo/nYKGX1oLQfa+CjSE0BBKKKcugXjgF jkfZsRlEnORIurR7El8P/jt0705966O3liD/7KTwMjqjPUGQGs6CMKGF1283sPjEk/BjgH8CDABx MBTiDQplbmRzdHJlYW0NZW5kb2JqDTE1MCAwIG9iajw8L1R5cGUvRm9udC9FbmNvZGluZy9JZGVu dGl0eS1IL0Jhc2VGb250L0xLRkFQRStTeW1ib2xNVC9TdWJ0eXBlL1R5cGUwL0Rlc2NlbmRhbnRG b250c1sxNjIgMCBSXS9Ub1VuaWNvZGUgMTUxIDAgUj4+DWVuZG9iag0xNTEgMCBvYmo8PC9MZW5n dGggMjI4L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiVSQsW7DIBCGd57ixkYZIDRVO1gs 6eIhbVW73QmcHaQa0BkPfvsCtRJ1AHT/3Xf3c/zUvrbeJeAfFEyHCQbnLeEcFjIIFxydh4ME60za onqbSUfgGe7WOeHU+iFA0zD+mZNzohUe+v5pL3bA38kiOT9m5Si/vrPSLTH+4IQ+gQClwOLA+Oms 45ueEHgF72K/RgRZ48M2O1icozZI2o8IjRDiUZXn+UUBevs/z+QfdRnMVRO7V0uh2AY1UkipWGa3 qtKl/PDmyixE2XBdQ7VVDDmPt03FEMvsctivAAMAGddtKAoNCmVuZHN0cmVhbQ1lbmRvYmoNMTUy IDAgb2JqPDwvTGVuZ3RoIDYxNS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImEk19P2zAU xd/zKe5jMhFj5382hAQFCSbBJhFpDxOaTOrW3tI4ih2q7dPv3rQFpMF4S+z4nOPfPeGMc55BswVR sUKUuQAOzTL4Htr1KAdtoiJsQUunYTX1rTe2B7sC4x3gjp38EGXhFMVJ6MGZP4oB3F7fNRDdN58D juIiEdC0QI88IZ/4ySgWTOTpzm3oZO/AW9DWeZKWsBh/R3EZDlEsQk9mFAjdtGnhigJ9s+Mvp+0w J+nhS+sZpCK+tY8sykMQR7SR4AnOc5gVSAqc7UxrZpNhesBnMD1+NEwe6Lb9/NFTfl48xS9ryt98 wLjabuFBYVJMPOIh5QbbL+nNo7UmHooM2mkcVY9ovPS4EOchwhuVU3J8diDdvUUxT6JmWVqK+jCJ VlNCRAFeGwdyVBIxN1rB9kAAB4SbCla26+zW9Ov9BXbAD3oEPCPyKBuurezcR4ian8FlE1zeLCA4 /gonJ8c3i+sLKOD09PwC186b4LhpOOChFem1IDirK8zG9081h7xKWVqJpIRmE4RvaZYvNRfJj71o PN+8fk1a8JLVdZ1VkBc1qzNRzg4nyKzCM+kpGr1I9ypMVqR1ekB55pxyO1Q0kslRmemNBkVzxFlR f2M5DKN9VMtD9bEgu/a7IzBMsaOXg767OouTvJhriy2Y0WNNQlrPRQIruTGdUQ7HCHK5NPNfhF2h ffHpLVzVu7jm8f6HWZayKkvS9F1mzxX/F9mFce2EzKi82LURO6/GTVSFIHdA5h28Da3h1dbUdK+p rwoG6xGpkR0MhNc+dGrjYGu8nqk/ytFYHEJ0D38FGABcIy+lDQplbmRzdHJlYW0NZW5kb2JqDTE1 MyAwIG9iajw8L0xlbmd0aCA1MTAvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJpFTBjpsw EL3zFXM0lXBsIBjUKIdN9tCVVuqBW7WqLDCNWwLUkEb7950xSdiqUvawt/F4eDPvvTHlUyC4EFJC WQFFIsHwDOWn4BvTw9DaSk+270bow5Q1oWQwHQzgjev/mDBnNRz0eIDm1FWTDTOGpZ8hfCmfgscy eHzeQbD6CpvN6nn3ZQ8FbLcPe8w9lMFqF38XgM2aIPKNCz8CNZeCFzmG4hJJoXhRFGkOa6m4SmMs PQYbIVROA2/Ln8GqLC9gHkvd6CgPyLOkSAi8Rlp7O1ancfREqr6rLQ6+psExoycM4dyf2hrO2jnd TaA7z8fDxQTs500Tj5xzEasbNITRmhnt2tcwylEq/H60pJ+/0Gc95xvXH1E7TErJdDcn+8YX0VS3 fjJejImpX3RtGEku18nc9eKGtwJhDwjLLo6Qa/cckeKjlqSF5ApHUu95kl6ZSCHvmzKQHn0YxWwy 3WR1C84Mra7MEY/QD/NCLiKJRaTUI2e8SNfpFbrpHXmYMtRZzTpn7M0W13R+s8U91Y5hzO7IJj8s m8p5nCVx9u4qFzdy2f+y7VrtbDMT89I5eoODcZM1I1E9EZlfxlcY5FRDRSWvw0Sr8YNEdno42Gp+ x3h1FWFE1X9jzYlqrEOZSMjaNg0WGUdWLO9ioYx/jn9+HBxCJAV/BRgA+JQhfQ0KZW5kc3RyZWFt DWVuZG9iag0xNTQgMCBvYmo8PC9MZW5ndGggNTgzL0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFt DQpIiXyTS2/bMBCE7/4Ve6SKmBH1sgQEOeQBNAVSFChvRQ+MvLbVyqJA0hH677skbdkGgsAXmRRn dj6OnuXi+fURFrc/4O7u9vXx5QlEBvf3D0+0+CAXt1KmIEBuFinIFkTKmxpS+sWnuuFNU9c5FGXG myIv6NX9gkEi/yyeP5DOP5bmaZqWXj88NSCnT5yKlGd1XlTe6Rf7/vJTgtV913bOwqhGNPYGRoMW k2XBBqdcpwdaalVcAesO6w5pJfktv0XvVTObV8G84ausqgW5yzWZjGrAnkT1qK3q6aga1uRlHLmO wQA2Ru+TmtHOv2S5Yhfi2UlbZMKLL2f1peCizKNFNzikoR0G4WRZMReG7Ia2p3mHLfhIyrQ7DLv2 JthYcqsZHdufDas5zKo5phF5VZ3CWEiWJfNK/mjnsHXk847DWptjtIMlihwgwJ26nrJr6y6BnYIE 4cscboeg2hZHn8QbxSuJxHyE040AQfMvT9r8vb6JCbKUiywVTRyZ2Z0eYcI3sDRtUIpU0AtYpH+g gk540Xcv4BYzhzyCn2X9wMWqFHHkHSnqg0sqxuGrnvAdzQ0MGjba0No+yZnqz/LUghZxnRR0ZVvr rzwAekMYD299RydskrEdrnnEh0OrD0Zt0X5SOPnFt+wKj49pcNTGBVS02Xe+Yd2gTKyYH4kIKHd1 L62nl5Vze9m5qIP/QnpF3PVMKbA59jNQqrmo03xuvs9kd4C9xSlUr2RI+ThIPXbtRSaRnnkXEXfN i3x1xB37Af8FGADl/TflDQplbmRzdHJlYW0NZW5kb2JqDTE1NSAwIG9iajw8L0xlbmd0aCA0Nzcv RmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJpJNRb5swFIXf+RX30Z4KsY0Bs0aR0rRSNq3S pPitmiYazGAjuMJmXf99bRqmrCrLQ1/QkSXOvd+5996hSvdghvsDFqgxptE4zFCHQ4YMmFoPbQkN Tl9e9q1TQ6ku4H6wTkLRK+i0hbYZf7eqBKsvwNYKKt22+rHpfmCOPgL+Jj8HNzK4ud1AsPgKy+Xi dvPpGiiH1erq2j1eyWAhJQEKsgoIyD24zyNQEuXCSXJUIo/yPBMM4pRHseA0A3kIEGD5803/5G3/ iBAS07GKk5T+v1RCo4xxxn2pO7RT+6Fv7BMOBYKdLexgQFewfnjo9W+XwLYwtTLzyOlpSxv2/dhT ODaVz5JTkvl+YohjEcWck9S3syQkEx5m5QJ4BZhMfN7VGUZpnMfevHQU0s2oLawyFnplcMjR4Efc WgfTjRM0R04Pt9viDK1DejmPlb0Xi/EoJzzh57Cyv1jZOaxhwsEJqj3ev1Se0q3xbrsOWZJC0ZXg dUIZVMWhaRs1TrZ2A33hnpblyCI/BKgaur1tdGcuZ3dQnE1mNhSWi0iQxNd8Ryhfml+qfQL1x6rO +F7dlZ5mMgX2mnG6EufHooSnfDI8SdZFWEyb77Ics5oycadvMEN+aeBZgAEAjOsZUw0KZW5kc3Ry ZWFtDWVuZG9iag0xNTYgMCBvYmo8PC9MZW5ndGggNDYxL0ZpbHRlci9GbGF0ZURlY29kZT4+c3Ry ZWFtDQpIiaSTTWvcMBCG7/4Vc7QPq9WHLVuwbGg2gbYQKFTQQwhBtbVrF8cyttz9+x3ZS9LQ3eaw N2k080rzvBr9NbrX0f3DDqL1N9hs1g+7L3fAFGy3t3cYvNXResefKTDQ+2hFCaVUgS6Bgj4Co0QV uKSnFaM5UUoyDrzIiJCZBP0SbSjNC6wTW/0rWmt9Epu18kUsLOWsSKRQIqhX0WOsawvNS1LEvSn9 CMkqi90ePEZb4+3oYbDj1OKJ66Bq9vtExnawnQfT921TGt+4Dg+XEtMnadwP7retoDZjDSF96so5 iUDypM+y4PRvFm+vvwihUMggSwvgOSc5zWQeIMSQYPfn9Nl5fUTC2Cscwf5/lcSsNMtFuOox/l67 wYO2Q2AHn5YWL3fIr3E7VRnwVBJJJRcf2S1fGwrGv7c7/uyOMA2H2b/Bzp6V0zD7WbqutEM3Bobn yaT4AIyePg4cG1+fXF8sR+9Pri+W474bby4zEVczEYIwKfMPmbxNQPbvBPyoDXZfm+5gR/Du/cc2 XQX9gL/Y+dBPmfDYtSPCmtoKgvVNmBjfHHBYoHceSTaYbVqscj9bG1LGm2Sl4ssc0qs5MEVyHAUe OMAfAQYApccWmg0KZW5kc3RyZWFtDWVuZG9iag0xNTcgMCBvYmo8PC9MZW5ndGggNTQ2L0ZpbHRl ci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiaRT22rcMBB991fMowy1V/JNFixbyGahKaQUIuhDCEW1 tWuVjWUsOyZ/35H3kpRk04eCwYMkzsy5zJJSXlJK05X8HSykpMBAbgMaU8oolhX4kmYgJ2BxkYoU KMg6uCc/GjXAbjS1aquwJBpcY8d9Dd9u7sKcSNiZJw2TGRrow4Jo1+lqgPBBfj2Ap2dsxmbwMuac 5uwEP1holGtgO7bVYGyYkdaBamsYGm16UF23N4hbKbxs3ecD8kYGm9s1BIvvsFwubtc315DksFpd XePhlXxNcG4/N6axKLGkx6oUsRBZVkJCeUwLngiQjwGBEAV6D794H98z4+JMsviwFRNZnFGeFr7V PVnbtjYzL9ha5NrCRvX75zDiBGSvUO02jBLi5jeXmfPXk62Tn8fRonkgcVEAhryFSEWBnrCYJpzN Yy0vJ8WzO/L0lP9OCvliJ6iQw2s7kdkvDco5jV89s3S6Gnsv8oyTnBBZcopHwlMmTvEwA8pREuh6 2+l+MNqBG6sGISGMclLZ/d44r06vnXEDZlR/ekkffTEm9+jRGT5iMcvTQ4+u18aDPaLgKkzITs9o /uiE6APZOT3WNuqxtv5pi5w+yGP5367kWSwSzpN/ufImfm/3tzokDRfWWzLNCzz5gPVIZwAFA/6P OVOTer6oIBMxz7Pz9sLWL73fWq8I2FaD3frV9Yvb2yf0HOOAV40PMpo3+GkMmvcAfwQYAKkvK1IN CmVuZHN0cmVhbQ1lbmRvYmoNMTU4IDAgb2JqPDwvTGVuZ3RoIDQ2OC9GaWx0ZXIvRmxhdGVEZWNv ZGU+PnN0cmVhbQ0KSImkU81vmzAUv/NXvKM54Njmy9aiVGpSaasUrZos7ZBWkwtOYCOADOnU/362 m8JWNdthB9Djyfy+3rO8DSIqcJ4mFCKKaRqDLIMd0so0tTYwVqqF4mSMbscmzNBzGOUI+ka1YYJa XV5B+CBvgxsZ3GzXECzuYLlcbNefNsAErFbXG9u8lsFCSgIU5D4gIAuwr59ACRbcluRccYGFiGOg TOCM5DwFeQwQhPL7e/AxeR8eE0Jy4Ulcmf2ViWZYJLlgnumuG63JWjXwRVuDhT7aT/jcj3XXDhdl 0N9lrNm3s47Is4uLZinJrQaWuyrGKeGJF7G04rn9MV5ZureuJlO5R8RZLGKHXgbooxoq2J/a4kXs 68CeQT2pulGPjYZ9Z8BoZ8NhUEYnOObhMswoz17wdsgFULcH6FoNduzd3m6CBtX3prODf7KPDhkq oZqI7SnH/eHiQsTsf6MS9mTGBf1XUvP407dJ7dDXSo3QK6PK+nAcoLO+zmvuHG61+dHoaKOOIUeH +zhJvR0fGZkjSzwuxzlNOX1FNiUUXesuyGCzGc3JTwMcUn1w7SqMbB8e5yB71zEuOjVqGDuY2ZIp kGgimm8oskxDXWpz9cdmwi8BBgCkGvH6DQplbmRzdHJlYW0NZW5kb2JqDTE1OSAwIG9iajw8L0xl bmd0aCAyNTc1L0ZpbHRlci9GbGF0ZURlY29kZS9OIDMvQWx0ZXJuYXRlL0RldmljZVJHQj4+c3Ry ZWFtDQpIiZyWeVRTdxbHf2/JnpCVsMNjDVuAsAaQNWxhkR0EUQhJCAESQkjYBUFEBRRFRISqlTLW bXRGT0WdLq5jrQ7WferSA/Uw6ug4tBbXjp0XOEedTmem0+8f7/c593fv793fvfed8wCgJ6WqtdUw CwCN1qDPSozFFhUUYqQJAAMKIAIRADJ5rS4tOyEH4JLGS7Ba3An8i55eB5BpvSJMysAw8P+JLdfp DQBAGTgHKJS1cpw7ca6qN+hM9hmceaWVJoZRE+vxBHG2NLFqnr3nfOY52sQKjVaBsylnnUKjMPFp nFfXGZU4I6k4d9WplfU4X8XZpcqoUeP83BSrUcpqAUDpJrtBKS/H2Q9nuj4nS4LzAgDIdNU7XPoO G5QNBtOlJNW6Rr1aVW7A3OUemCg0VIwlKeurlAaDMEMmr5TpFZikWqOTaRsBmL/znDim2mJ4kYNF ocHBQn8f0TuF+q+bv1Cm3s7Tk8y5nkH8C29tP+dXPQqAeBavzfq3ttItAIyvBMDy5luby/sAMPG+ Hb74zn34pnkpNxh0Yb6+9fX1Pmql3MdU0Df6nw6/QO+8z8d03JvyYHHKMpmxyoCZ6iavrqo26rFa nUyuxIQ/HeJfHfjzeXhnKcuUeqUWj8jDp0ytVeHt1irUBnW1FlNr/1MTf2XYTzQ/17i4Y68Br9gH sC7yAPK3CwDl0gBStA3fgd70LZWSBzLwNd/h3vzczwn691PhPtOjVq2ai5Nk5WByo75ufs/0WQIC oAIm4AErYA+cgTsQAn8QAsJBNIgHySAd5IACsBTIQTnQAD2oBy2gHXSBHrAebALDYDsYA7vBfnAQ jIOPwQnwR3AefAmugVtgEkyDh2AGPAWvIAgiQQyIC1lBDpAr5AX5Q2IoEoqHUqEsqAAqgVSQFjJC LdAKqAfqh4ahHdBu6PfQUegEdA66BH0FTUEPoO+glzAC02EebAe7wb6wGI6BU+AceAmsgmvgJrgT XgcPwaPwPvgwfAI+D1+DJ+GH8CwCEBrCRxwRISJGJEg6UoiUIXqkFelGBpFRZD9yDDmLXEEmkUfI C5SIclEMFaLhaBKai8rRGrQV7UWH0V3oYfQ0egWdQmfQ1wQGwZbgRQgjSAmLCCpCPaGLMEjYSfiI cIZwjTBNeEokEvlEATGEmEQsIFYQm4m9xK3EA8TjxEvEu8RZEolkRfIiRZDSSTKSgdRF2kLaR/qM dJk0TXpOppEdyP7kBHIhWUvuIA+S95A/JV8m3yO/orAorpQwSjpFQWmk9FHGKMcoFynTlFdUNlVA jaDmUCuo7dQh6n7qGept6hMajeZEC6Vl0tS05bQh2u9on9OmaC/oHLonXUIvohvp6+gf0o/Tv6I/ YTAYboxoRiHDwFjH2M04xfia8dyMa+ZjJjVTmLWZjZgdNrts9phJYboyY5hLmU3MQeYh5kXmIxaF 5caSsGSsVtYI6yjrBmuWzWWL2OlsDbuXvYd9jn2fQ+K4ceI5Ck4n5wPOKc5dLsJ15kq4cu4K7hj3 DHeaR+QJeFJeBa+H91veBG/GnGMeaJ5n3mA+Yv6J+SQf4bvxpfwqfh//IP86/6WFnUWMhdJijcV+ i8sWzyxtLKMtlZbdlgcsr1m+tMKs4q0qrTZYjVvdsUatPa0zreutt1mfsX5kw7MJt5HbdNsctLlp C9t62mbZNtt+YHvBdtbO3i7RTme3xe6U3SN7vn20fYX9gP2n9g8cuA6RDmqHAYfPHP6KmWMxWBU2 hJ3GZhxtHZMcjY47HCccXzkJnHKdOpwOON1xpjqLncucB5xPOs+4OLikubS47HW56UpxFbuWu252 Pev6zE3glu+2ym3c7b7AUiAVNAn2Cm67M9yj3GvcR92vehA9xB6VHls9vvSEPYM8yz1HPC96wV7B XmqvrV6XvAneod5a71HvG0K6MEZYJ9wrnPLh+6T6dPiM+zz2dfEt9N3ge9b3tV+QX5XfmN8tEUeU LOoQHRN95+/pL/cf8b8awAhICGgLOBLwbaBXoDJwW+Cfg7hBaUGrgk4G/SM4JFgfvD/4QYhLSEnI eyE3xDxxhrhX/HkoITQ2tC3049AXYcFhhrCDYX8PF4ZXhu8Jv79AsEC5YGzB3QinCFnEjojJSCyy JPL9yMkoxyhZ1GjUN9HO0YrondH3YjxiKmL2xTyO9YvVx34U+0wSJlkmOR6HxCXGdcdNxHPic+OH 479OcEpQJexNmEkMSmxOPJ5ESEpJ2pB0Q2onlUt3S2eSQ5KXJZ9OoadkpwynfJPqmapPPZYGpyWn bUy7vdB1oXbheDpIl6ZvTL+TIcioyfhDJjEzI3Mk8y9ZoqyWrLPZ3Ozi7D3ZT3Nic/pybuW65xpz T+Yx84ryduc9y4/L78+fXOS7aNmi8wXWBeqCI4WkwrzCnYWzi+MXb1o8XRRU1FV0fYlgScOSc0ut l1Yt/aSYWSwrPlRCKMkv2VPygyxdNiqbLZWWvlc6I5fIN8sfKqIVA4oHyghlv/JeWURZf9l9VYRq o+pBeVT5YPkjtUQ9rP62Iqlie8WzyvTKDyt/rMqvOqAha0o0R7UcbaX2dLV9dUP1JZ2Xrks3WRNW s6lmRp+i31kL1S6pPWLg4T9TF4zuxpXGqbrIupG65/V59Yca2A3ahguNno1rGu81JTT9phltljef bHFsaW+ZWhazbEcr1FraerLNua2zbXp54vJd7dT2yvY/dfh19Hd8vyJ/xbFOu87lnXdXJq7c22XW pe+6sSp81fbV6Gr16ok1AWu2rHndrej+osevZ7Dnh1557xdrRWuH1v64rmzdRF9w37b1xPXa9dc3 RG3Y1c/ub+q/uzFt4+EBbKB74PtNxZvODQYObt9M3WzcPDmU+k8ApAFb/pi4mSSZkJn8mmia1ZtC m6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n 4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSc tRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePC X8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA5 0LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLf Kd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o 7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+ S/7c/23//wIMAPeE8/sKDQplbmRzdHJlYW0NZW5kb2JqDTE2MCAwIG9iajw8L0xlbmd0aCA2OTg5 L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDExMDQwPj5zdHJlYW0NCkiJ3FcLVBNnFp48gURe Dajrov5AUYEkTMCgvKwhBBwXEkxCRGtdkzCQaF7MDCBFhURF0GqpIj6pqK2oSH0UH9uzdfHo+qBC 8VXR9bWybrU+qvUtoPsPVEFbd8/Zc3bPnp05/5m59//u/b//v/fmThAGgiD9kBKEhYxN0mApFwub J0HNcQTx81NpIiLn3b9OwPcrUKcz5lMg7FDHfATxH40gHHa2I8f6ED2UiyCD4qHsnWMpzN46v/4A goTQ+F0mXJ/15/opOIKEXYdytAkqvEUsJ4IMTYXyuyYrNbMgHRsDZQeCMDstdqN+YPxA6GtYJYIw XFb9TAeTxamF9kchHtj0VtxthXowgowYCPFfOAjcMcf7APQfZEEQFuSBMLpv+okIuuDTD+m+BA9R l+Ae1yOsdFzpY0+GG7PGJbgKVZeYDIbEC+3Hde+ZYXI4CDqNywvnMtgM1ygmg12jRtNRYR9NwIYh JQFIfPetQgwIidgRC4IjFBxj6BsFr/tj+yytW3Ctmde5LP5cSt3zeNmhGpf3e6iL2QhHKNNPUN5w YuH12kNfS4+sWVzWNLRJo/sE9XzFlcGGlJyfSoaig7msDDZP0F+HE2aNOccGtEQeSQElThXYiRmS Aag/DeALvF4ChACzGcUSIRrWMxHca2m24kBD6a0Osy0HaHAi32zEgdpupyQj0cgedLhSBVIxWSKW imknAZlcrkjXKpKEYIQxNGYUeH0NdMgAz5hRqFQSiY5C4TUZijGSyCjJz+L//gac6/qeOYODsJyL 4bmXM51O5JQY3DXNEorEzoCd3F21/L2+nhPPa9ry2o9Fhe06/cjj/ZH3b1Q89+jX+pffTv5D8/eP ynZWNy4IuTk704ecPvObXP+uw5mPQusyp1axu0QG30xnQFNu5ZmgzIgzx/0486K/qtzakDb+xp24 oHrdqjmBay2ljeNTVkxv2BR9ptNDdKohZg2TBZP6jZRgQV6xvmvnc8acvFHSUXRmy4NthZ2czuUJ ucFbwkdc/kiAlz8XLmB8PHm1ocm3tuTB3v1+e0/oVs1wNygOb/j8vLSYE3SJELFLObWzPPov85Pf fdw/7Tu3JWt8LJnPedIVTeXrLrMda8Nm65ccuM7PXb35SLYhMWF5ZVDkyqDyhc+y3N99ePIZzN9m OKKZ/sjXvqvPy28HdiRnzitvSi6rCLnjN+3/L4m3SYajIT2Oh/xzGi93yn/rTv8tii/Ph/eL8/FF vekJN4E7ZqNwwoZTqLP6Fym9CEZhAZ3SdfrbDfWLK1IqLjT4TjVf4BUbKriS5pYXZZ8kn8ViK2+c 5r5XXb9h5uRbTzuNCtU+vg39cUN0ncjj8j378DrPCdM4UlVxi1bVuleY2MZvXbxv6os9Ja3tVQ3F QViij+XUyh0M3caD34rXxT4o3py56WwQfu2juplr/3guJdH0vmh2124mg/UrCW2d1rHq95+ZvzxV 5Ag3BA9JAhO2B/sfoZhPsZ+GD5qyrTRX6h7+6ONLV3ZXXV9U+7t28ug4j+od5xed91/axLrmEaLj fq/8LOXzExOTT4/WPQxsPjgsThQS2bLm6p/GpvzQZk3Jv9aIbvQuaSlui5tT83R5mCTc/9lRv9sX d9zIkDmSRcI5qMtjExzeNSwmg8n0Kcyuss3d0bqH8Y6turEBz+3LmAkTWv8rp/72CEWhkp6Ah73K CLndasUJo1lvARp7NlWgJ3CQnmewmEkTTpBALutOydHoSEk0ir5KSVqMjJLGSGMmoy7GB/9xEpJk NKnHKKGgoECcDw1JaCg22q0RsAPbSTNlJwoj5Okaeg074RADQyFQ49liIZ3X4lRtEp3L0ZIxaHyP H2mSOcdMwQWxJCC36EkSRAERSDMbCTsJKfTy0Okt5iw9ZbbbQH6khI960PZcATNDIxGgvrTgLuBN 1JMmWHqU3SbxQb16jsJNjWdZ7bYsyRA0gNaw/Px73cshRzvR7fblPP8t8/CAwZtV5GJ4IlDvznQx GEhDxclhm7P+ftP/4AtrkUzFe2oPy20RD9Rsioy+ctr0V2kX9k5bVSf+rcYP7Gcf+/DhMYe18tbx L7eHoasjM2ft2TIjJGdV49WCHzjXfmyvelzP/82mL+LnOa4+sU9RzbZ7qxUL/c/iF+IApz1hvWVF rBc/RHA78BuwJOZDw1zOseBBnerqbdWpVWfjlZkJrqI7HlLdblNjomJDnGRjR9vyjowjws0bD4aq Wh4su8saWnTPP3bLk63pczlWw91FgrLR59oDvMgD3LFfjTh4s3lp7pH92bvWa4O+4+fMerKgsHxb Nm/rhGddRGBn6QeHH4z3upWpD05r3RmbdUXw6dSj862p/bcnuMFC3ujiXERdnHPd0RksYDNRBOXT r95sNovJqUGdZbTEYDtL0DklPkVVfzsh7zKtvD/6uC3uJ75rvfG/UEguDrMBfhWigTQTNoPxgj0A 9UPpL7/eL7v+LKZbCQKjDSE8NheF5LljURc7ug+GR5u62MFQPbQmtGS4iaIcZGxExL8ojPUu1j6n i9WgNZlJYMQJypxtNuopHJi7C4ZONpykq4bAs3ECtxlxIdDbsoCZIkEeCWEkICnCbKQshTwyzzAd N1KAsgsBZcJB7yG88kvXSzqhN1J0Q4SticKtuI0CIyCTUB6kSdIAiRiFi+TrzRa9wUIzed1b7waA norlvW2jcTRrhcgK3UAcgCuICDw3DycpcuzrODvBg9CXwNdjKgSR0pgoGEY97JCyfBwq0ux5NkoP WenMeIEQhhDEjERHRvEyNDKIcxQS5hwTRTdJSUxM9BvuAJBZLEBNI0j4Q0TCnoxniYFcodbKMCVv okytlim1mEIDkjCNPFWGpSmSgEyZ1KcPp2JpGGzDYh6NVmLKlFigHacAGRoFUCXDV0zT7Q5LxuQy rQJAUaNVY3Jt6iSgyUgcr5BrgVZFm/B0CjUG/1gp++AxlRKkq2VyLSZXQDvoIE2h1ELa9BKYRpMB 1/sH81UeFsWRxV9Vdc/goKIgHmC0FRFQww4eeKBEjuGQU0ZQRF2GUxQY5QoImHFEF1A5PBNEEc8l GIUkKJooQlbUFVdXjGuImogKLqt+JPE2TOcNCrjs7vftX/ttv+mZqep6Ve/3e0dVC06B8zz8AtAW WZeRyi4EgqePv7fnW5sVC/wDFEql0IMKSfB18Q501c/S0ytDu30UAS4e2OxC6RcguHnO89Wru+F/ J8HfCW10CfR2ChD8AwP8/ZSKCZ2LzPf09hZ8/ebJnBWdJHkrOhVc/HyVirmBaLynk/cEVPH1nOcZ 9Fany1g/RBUguDr5OLkrlLaCUqGQ6XHq9wv9HK4KHOWtRKZd1Jj78egydVTvWIyOScSyEBkhxKvj 9WEVFRMZoXyTCE5JmBlhyZhAsshU1O8M7hRVbHKkkLhUhXEQr04SwiKFcDU+iuicRJUoqMLDkxPe ZGCUOiGuM2dkKW+2GxyBkaq3wNPJVrbPXjP5v0nzrv5YdbTaNjomSr7mqL6SCNyaQ3KNXCMxDF3v Qda/UBApIdhhLTHAqsLzWEEHD/+P8yNJ8rDukVQeJDcd3KseyvGwQsxmdXVaJXYyG9OzE3fXFCE2 RhVmK8QmYS788+kSOi/54HcqnTlnIJdgtcNPr3OP/qS2zXtvWmBT0qINlnUHhfbY6i/S3dJ3l6w6 uVLiYWoc2bDY5sVch5yVlU8GTUttyj9iqLEvWOyx4yxMkylrZk8Vc02s4sB98nMPb9uEn+sbV3e4 qkfn/3Vzyd2tj1pFuFD3OGH4d8Us/lhtePrEVFeH3etyX2etn2pt23pw2lTHk7/+orWw03KjsQaP QOjy5P/B/vFvDoN9JQZvSKE8D3vWHJYP62apD7N7d2Ph8IzR0zK067XtyEf2KHJ2xtwA/g+JExt8 Kqovtj07HH+u3zG5/zvD+9o5y2fvGaoZDEpIgzgIAzXEggBR+BsPSaVjNKP10fQ2mOK6DjWd0ZSU kByZlLYi8ne9jjSclsDCcybnlrXuylH9eHLEo4IKWVWxuePDUqchblGR9Xnn1x7XLnbOz31YcGnW j3PWfb5q2NGfig+zV8Gni+PuJl1pbnL5KcK6JvWl37ItQ4779Lt0Lzds0/LPBuwavVT6w6BhaTlj gh9ZZYVZDEtNpty0Eq/ZZjV/UwQ5WvsOlb4XbhW/cNy2vy96lb7ry4QRmWWHnikH7nzaslHbmFNS O2qVUXPb7ZgFoZOKvOhpj08/3p+9/oHDbZ3fzqutTeeaY8ddOxX6Vf3Sa0VWKuvzmY2qe4VBl01j jT1D75E4z0STT3aFmtw5YNG4qj5dqDZZdXCoCCk5DS2Fdy4G5zVrZ17IP5Stu3gy/f6kG+OtS7Xk Cp7qGnp8IbHTklPYdUIfZGuq/+/fX6kpnBpY1OTyaNRrtwVZOX92yy6wfDwotFegBsuHvhunht0N KcEw7X7C2xnpXz3s5PiuIbebMmnywn8J07bCgn7X9soqV28Rn5tsM/LqHVRrNIr01XEhcVOc01O+ u39jxUvTgV6FwdcbMmvFaD/HxKcZN6OmSJdHKgb1N4ePxFenispsilNaqtLEIzMzv1+07cljTWLJ wLI+ZpkbLozKmrhmUO3l+0JWU9vE7JC0OzdE87KthY7a3BDLzbf2PZUbO5euHu2X1cfj15P2Ox2+ /rTRt2VjeaK+qBHuEikAHoAv4idh0/LNL9sDUdS4L+N5QolUQnkp9Lp81PFqmN0utIv8Rp0bmWRg SOo03U/5xWDHe8NIvIezrWAOIN55e9/TBYuP+OVgoVsm3rQywsFfvr3fXCqwhCVgA3OgDtrhNBkH /nBGvALhsIB+CO9jfz4chzNwG1whAiiYkQwQxGLYCGNhLeyB6ZyZWAXe8MDACAbDGJhB1CABU4iG 3eQmeIIXzuEA7pADCfg9F/ufk2n4hIAMFuPqW2EnnIa/wA8wDGe0hevo+ufiV+CCFSUc0uEE3Oad +Q1gAoVwCMqgFu4TW7KftLHHYpXYIP4DtWzADuwhBKtPGGyGUhx3CC5SC7ZPNBPTxT+K52E4Wl+O qGvhLK71jAgkiITTgyxN90qMF8uRh75oM1qP4oRofCEJDuDI6/Ca9EHRUoF+QMN1A8UhIIWRWOHG o32BWPFWQzZsQhRFUAJH4QH5gCwll8hj2o9qaA3vL/WV+vap6fhWdBef4Rp9YRRaOx+WQypqboYt sB01S3GtP6G0QwexJw7EkXiSAJJP1pMD5AUdT7+nr1l/ZsQmsGAWyjJYM3tpwHf46Xboroj+Yipy SZBzGXrSBXHOg0WwAhLhQ8gADVqXh1KA7JWjVCCfNSjfwC24i9ICD+AhxhyPGGVkHIocxYHMJnNI IPk9iSaJZAc5RqrJaXKWtJEndDK1p9OpHw2g0XQFTaIFtIJW0hp6j/6CVs5gCpbIPmLlrI6dZ1dZ EwfcHE7FxXDJ3FaugvuWa+eecDoeeAsUW17F7+nYq/PShYhjRQcxTNwkFqA8QI5HIJqxYIV4/NGr 4bijRCOqFbASJQ25W4eItsNu5E7P3jGohq8xSuvQv/VwBZoQ3y1ohufwEsnR4zMlo8j7xA75nUXc URain1JIBtGQPFKEPFeSKpQz5Cai1CHCIBpMl9AUmkE30R10Jz1Bz9Dr6AmRSdATQ5k782LzWQhb wpLYdvYx+4TtZiWsmp1h9RzlZnD+XAK3livg9nJHuXNcI3eTl/MOfC5KBV/Fn+JbJMYSc8lkiVJS LZUYpBm0GujgCzgHlVDVO/dJNhlAKuEz0so4pqENdAE1pNeJlrtMrNADMwnwebjb/owWvkeu0qlk PgsnC5E/LYkiIbCLDWd72Rxo4OOJkvmTCFByO+BX/htQ8bn0c0b5XNZBXtJyWAp5dHlHmRhM+oOS 7KcHMWIyYSbYcGZwnU7nThBLakNrpEdINThKJWw6m2FghK397C6aqTQwIm2gYr+RX23BTVxn+D+7 q921fEEWxpYtjFYskmPLsrG5+KbakiUZgrBjW4ZqgbS6WNRmKPYkQMelpLQMJRXBo0xmINPLNNNh 0sTJtEcGOnImpX5rX/LEjNspfYBwaR9KyWQInaYY9T8r2dgp0/axM13pO//9/P+ey57dj3H/3MK9 Ncy9jc+Ee+SP0gtY3SL/C/Q5Cd3k0pNyeNegcVGynrtEdi+eXvw9/8PcT0g19zHAYvmij/PjituT m+GuwQO4+OTvwk24xt2APfjUSOg751Pce9/AJ81eeMyV4n4K43Nk0tvT0/0lT1dnR3vbtq1bWls2 Nze5G10N9c/VOR2b1I12xbahdr21ptpSVbmuYq253LSmrLSk2FgkS6JBwLdWaAyqfVGFOqNUcKo7 d7qZrMZQEVuhiFIFVX2rfagS1d2U1Z5e9Dz4BU9v3tO77ElMigc87kYlqCr0o4CqZMm+oQjy5wOq ptD7Ot+v84JTF0pRsNsxQglaxgIKJVElSPuOj6WC0QD2lyk2+lV/0uhuhIyxGNli5GiVOpkhVd1E Z7iqYGeGA7kUq6I1aiBIq9UAK4HyjmBslA4ORYIBq92uuRsp8SfUOAW1l65x6S7g19NQ0U8lPY0y zm4HzimZxvnUa1kTxKOuklF1NHYgQvmYxnKUuzBvgFZ9847lqYidm/2RsyutVj4VtIwrTEylzir0 raHISqudtZqGfWAs5+iLpvow9Ws4iqGwgtm4M1qEkjOYUmF3wu4qf39JNcg00UMKLVJ71bHUoSjO TU2KwvCUfbamxjuXuwk1QSU1ElHttMeqarHA+kwFpIanLld7lerVFndjxlSeH9hM2ZoCU1K6kkku 23ROd2dcaHh5ZAmrSH0eVwRVEgpWElHxntpZk2yHVKId3fDSCEbRUZyRcVrkj6ZMnUzP4qnBYVKV 1GeAK0C9/5fVmlhBIzpMnwFj2TpZXmtoX+Kpy0UbGtgSkfw4p1hjty5vczcez3I+ddKkIMHhg0Ec 25jW2YzDb7ezCT6X9UIcBXpqKJKXFYhbZ8Hb7NIoF2WW+SXLuj3McmrJshweVXElX8HzC2AdlZ3L /zWmyrXBsU5KKv+NOZm3h8JqaGhfRAmmooWxDY2skvL29mVbgaNr/RHeyhU4zsrrVlyUB5admRAp oYID/6K+qEezkoyrUtcQpY+aojvzrWa02//LoGzuExalk6dhhTJpp2u13LVKXlVeSYrHggUnFxrZ l0oZV9qADZpc/KQb271P3nvcJB/Vh3HldU34CE9Vdn0O+GqHmIE7hisQEwAcwigMiTOwQ+yAnfxp 6ETbCMKNttfR5kD/IwX6OteRy6F+F+ITRCMijFAQcYSG2I34FmKI64D3Eecw1sPiGeXPQ4Txht9A hWEvbERqFu5CjXAb6kQr7BSug4o6J+bfYiiBAeQdhpNQIdWymNyfUd4tOtDnr1jDy+AUPoR2jO0y nIFKrH0H2toN9dArHsB8t6ES+/mZ+CdyCOkuQwB1kHsgAP8H7HsE65hC9PEPIYixzwsu2MHvwvu7 Dm7up+BHGkT7OkSL8CO8Jxc8hzyrvw15Dek4+gxgrAvtO3A8fVjrIP8p7EfajP3u538H18kP4BLS BfTfKjyCteRzPa+H4GxhzHYcKxBFmBNFshnp3xCP5L1QL92FEPb/4hLlt8BBNnZ4wo8XxnQK4w9i Hh//czhUGGOGTSyXDHBPuM51yJA7j/euiBdwzk+CG8fmK9Jd8l0cqwEdFyCGtJ8B+2tHtCG6Cug0 XCFGRDHawyjvEochwSDZoBVjmzDXCFsbaNuMdeoo1L+7UL9Osc5mHFffUry4CxowxsWbIbwCsIyH +L7xEL9zdEouYcwxjO/mWvA76CT3dh7g5825N3gz92Kegor8d3SKseQSrPetAzNXhz8n54QJUom7 46t6+4Le9uhtM2u55tlmmy3LNc2+xUjjbG09kk3e4ls1tpY6s81Tx+Qqb9fhetvNmWrbLcR7da22 Vz2tttOIZsRxlJlf3Uy9baJu4usT35s4K7RBZSXOsrlc9mbJ7V/uqSiqKGpLZ8mvvR1S+ldS+rKU /pqUHpXSX5bSfVJ6u5RuktIuKe2Q0pukCtksm+QyuUQ2yrIsyoLMySBXZHM3vS62+StEEyOiwFpB 500ca9lGxycBR2QOv+7oWj7EhcK9tN0Vykq5YdrmClFpcH8kQ8i0hlrKvZolMBLJkhxTnbGyU3sO CMmdOW8tUE0jITqfgFBcoY/CapYY8UFlUHsJNYcgNNJrgcrjPZYec3d5R1/gGU200LqeXhbXyis0 OPUh2Mgx9vFFjl6WbG9ITBtGbVrXppk2rWsttfRCKByhM7UabWVMrlYjl31XvSfYe0BUDSYRUXru +JiFnoorSsZ7tfCC4IzGE2OMxpL0qpoMUK8aUDK+E88wn2BmnxrIwIngSCRzwpsMzPq8vqAaC2hz MEDimYbpVem+v5RuDhpI/F97zJI467KBZRyYfkbGaWYeYBmnWcZplnHAO6BnDI6He0loMJKRoVfD w0enl7liI05V1GrXeitNk936vHXZLa9YPxCAvAPFeBaX4HtdKYKZ3D63j5lwwTBTGXvlK5gsr3TZ rR+QdwomE6rL1V5wHXN94XqZXWAJjgcYsJK53Dx3atZsa3Vp7Jzh2BGEX3+4jXHSurwbRCmBOoOQ 4MEoGhI8z9UUSUKCQLVc325xDZgeevoXPQOmR55+06IHejyLHoaWzfZye7kDG1zb8Fjh5x97DfAP PHHm9VPuOncDn33FYJ8DnlzxlhVJUFMqVpeUPrCzbl0Dd0z3oKf/fstmUiGqG53btm7f0lrJ3Vi4 +ObCwpsXFzhfni7op2Pr/9lP+x/7scsIryy/v3w7/wQDtorWoJTnBeSnC7yI/I/RCkIRSk/g/QJP YAOZKfAclJHfFnge9QsFXkD+YYEXYQNnHpmaTB6MJZLKu8rIWFLpnzgycRRVin/ipcmJl2JHxyeO KJOHE01KIHY09h+cmllnSnji8DGm+WepVM+aMBRFD4IQcLB/oPB20apbaCkNrVIxAYnZS6xpFJ4f 5EUhW/9Lp66dHaS/oIX+gU6dOnatPblax3aQcL/OPfedG7hGdaaca9h2vUrXrClHa+WP41FqlB+Z KFlGQ7fbdnqtSj+bDGbaC/4uESDDHBHuEOKWUeGRFmAkuYcZprR0x1K4ZJUwz31IfCwMRURzvsbs SvDwwJdO9psp9NnRWOw5hliHcavXgM2vjuouawrqcEIz+pyJuUMqUz7fM7QES/ohXHTRJreHFirU yTDBQNQ86ufsmLqa+yX/cA/pbq9zTa2iXGMBR/z/C2afxbIgeb9wj9eX8PmmfPZlHVsCP1yvTvP4 5L69bzbf59aHVWJZ+r38H5+PMswKDQplbmRzdHJlYW0NZW5kb2JqDTE2MSAwIG9iajw8L1R5cGUv Rm9udERlc2NyaXB0b3IvRm9udEZpbGUyIDE2MCAwIFIvRm9udEJCb3hbMCAtMjIwIDExMTMgMTAw NV0vRm9udE5hbWUvTEtGQVBFK1N5bWJvbE1UL0ZsYWdzIDQvU3RlbVYgMC9DYXBIZWlnaHQgMC9B c2NlbnQgMTAwNS9EZXNjZW50IC0yMTkvSXRhbGljQW5nbGUgMC9Gb250RmFtaWx5KFN5bWJvbCkv Rm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNDAwPj4NZW5kb2JqDTE2MiAwIG9iajw8L1db M1syNTBdMTIwWzQ1OV1dL1R5cGUvRm9udC9CYXNlRm9udC9MS0ZBUEUrU3ltYm9sTVQvU3VidHlw ZS9DSURGb250VHlwZTIvQ0lEU3lzdGVtSW5mbzw8L09yZGVyaW5nKElkZW50aXR5KS9SZWdpc3Ry eShBZG9iZSkvU3VwcGxlbWVudCAwPj4vRm9udERlc2NyaXB0b3IgMTYxIDAgUi9EVyAxMDAwPj4N ZW5kb2JqDTEgMCBvYmo8PC9Bbm5vdHMgMiAwIFIvQ29udGVudHMgMyAwIFIvVHlwZS9QYWdlL1Bh cmVudCAxMCAwIFIvUm90YXRlIDAvTWVkaWFCb3hbMCAwIDYxMiA3OTJdL0Nyb3BCb3hbMCAwIDYx MiA3OTJdL1Jlc291cmNlczw8L0NvbG9yU3BhY2U8PC9DUzAgMTQ1IDAgUj4+L0ZvbnQ8PC9UVDAg MTQzIDAgUi9UVDEgMTQ0IDAgUi9DMl8wIDE1MCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dF0vRXh0 R1N0YXRlPDwvR1MwIDE0OCAwIFI+Pj4+L1N0cnVjdFBhcmVudHMgMT4+DWVuZG9iag0yIDAgb2Jq WzUgMCBSXQ1lbmRvYmoNMyAwIG9iajw8L0xlbmd0aCAyMDQ5L0ZpbHRlci9GbGF0ZURlY29kZT4+ c3RyZWFtDQpIiaRX227bSBJ911c09olaWDSbdyZBsJk4mQswA2OteUoGizbZknpDkVxerMx8/Z7q JiVKFqWBnTyYolpVXadOnaq6vWfv3t3++vHnO+aw9+9/uPvIZrcfHxyWNnhB/1mTFjPOFN7/iPfr ZvbDEkfc/ziMs+VqtnBsx3EStkxxeLmjXywbxh36+xe9qvHBTmJtzDxxJ2aRk9hOlCQhW25n7xwn imHFe7/87+x2uexNa8uRMU2PIdnnduglHhnOZl+s5UayQsqMrcqazUNLFKysZMHSclvJVrWqLG6Y yMtizdrN/I/lL8ZosLeZaJuR7cF6b1OyXBWyYeWKLLbw8OHTAyzOF7E1srrCl3jnWjXLZKPWhYKT g4to7yIiF4vex4LbPPDIkSVw8x3biGbDVl2RklWbzYHAp+Xs06+UiENy+JAcAv8A0B71U4jjxE6S xPNZGHt2FOo4tzNryrx73jxuz719HJxf9hQhNJzSGf1i/Vv+r1O13M4TS849q2gbnaPfi29yHlt/ zheRfp8Rxh9r/bmaL7jVEqzrWlQbhaeU/UT4fO7xaQzAZyLwxhFMs/M5FSNcP449FgaRHfG/QchT 7hzx8Q5MqMVjLtlXixi5CKyuyIaXX+dsLQtZi5xVNXhat0rzbJI1X6xjfhgMmzmwS7tatRq2G4IQ xvAV+dsCXlGk8uZARu6PynNg4B2uK4qMKUpRlcutLFrxqHJFGdCG3865NQm4fxXwC1h7QI0nXnAN a3+Agzv8BWAfgUwoGTBHcJ+KS2z7YRIng4ce9rlvNXPX0uBXAgbTLhc1E1WVq1ToxNywpks3TDQj 1OnOvXXfaMBg/qACX6xMrVULRpCECMK+06IiYfKb1Hmgm2eyVk/CKA9lWOI+TSPWkokOElW0/UWg dkWG+7La/C3pMCs6skOPj2Rc1iOhOhTH8p8zy/CTLL2dEovgFZkPEteOgzjmVzLP3QN27vPM/5xR xKuBqFBeCpnYLIu07GqxJvHQoi/BApKUSuoG0TVSc+Ek/L6wNQNC7g5++uKD8XH9VQJAnmWBPVku 4UsEPOYRC2LH5sAuuijg0WAeh73IDRARIAwi/TfwE9PGjW9ufE97DCPbj+LQvegxPg6Ij6rW3Vet O90ytKfAtxMv9rhpGXdSZKb1apXrHreqmS9Qexp5UUsN7olEjLTdhYCj0nTurDdTF09eQ1+f2z4u 7J6j7xiCEx0/Zu+9ABlR3vcocoqPhLcXEaLwPVSrbETesLtOvmG/dPmfjAc3zCWKTvGLO69tgIE7 PF2OjR8q0zsjyh8gR2XdsN9KFKiS2Rv2oVt3Tcs8rhsVokA5XQjkRaOOZhMPbC9JLtOWXxh1nmnO pCcHVPMSNzK8fQBT0UNVY4jabMou13PNI4lPiXCfaLJRGeZUmcu0rcsCipHnh/atCjbdlVzHdtEr B/bcof1/vjE10oIwos7Y7w8sl20r60Wj/oJXYhi6YmwH7LuxvOitjFsPsFZFupHN17nNNCup6oZW QfFQT6WY6LPuS0hkUbZMfk9p6ubB6NrhgfNJf23PI6nvL16hWzW4VAO5Rs9uKkFDSrsrMVvnHXko yAPbzzGeJVq2wx1oCh/11dORdLH3dBTcPxhlRcBMvVaIoSPHTCCZ1CyqlpXUGAh9yPgasa/KosXU QDW4EU9yFJprhjEaBEpKJdvQECvQlGEEvyuBPGvl9xbhSXtt37DDURrOqE8XHV3nEZUPtI3pw4J1 oLeXYIr2on4EMTy+KOpIa8D94+Nn9g/Y9YKAm9nDjwLes2kvNv0GVUGU9oLEdLcrZL5nNShdlGxy k6JMhOE+5bR4ETIb7GUrRZAaMJq3xqye0Iz7oWqmGvNiMD3OMdibdxn4XhJXUXC5NIZVg32DEgnH qshQbcgXhUTNf7e5MHCrdAPGmIsOhjQb0rJYnZuoXSyyiZvsY1b1sPNk/bCoKmGWu2nR86ZF77wK YeHykVI/uSp4/qTgPZt9Jj25oR1DWmOjd/e5FBijqEipSZNUtPRBT1urMs/LHVWaKkApvY1o4NuB NgfWjxqL9o+5w3UGwdDD12LYfP5VIBP2uny6Wg/P4TN0HxXIOZheOtVGScJ87tk+hvz42j5zcSz4 TWyhh2K1wg6GRQCqp+d5qSFU+Q2rNmWBEyA77QsiO+4YMBfaoROGg70MlWzK2kzBaitqdBysA6By K9BFUiwRrV4gynqam+FrJguCB8yxk9BJomtD/+XJ4rOqqfuIYf25Ybk4eaErvgewL3YUshTYzNJy cS3Q6NWBxqEduKDbNR6cqOZxnEuqIgW+b2RmdAiNGWkfCfMN68X6SERRcez+7jOlfIvOKUgBmWhb hE9p3+LXlzQofsngFXke8yLPjkMe+JeFKJkWotOJZ9pVyG035EbzMGzmORskiKYvGl30ENFgbsB3 6FYi/VaUu1xma5lNr2eu8+LgfWyMDkf2LwXvTky150Rh0pMX2AkEMjCx/ygLWeukm3wT38Vj2bVE DKr4XVl/Q1etcOJ0toTSevg3MI6aKCl2q8caVss1xLbuTVJJpamGdktA66eMQDYHpgfAxeDmuGUf dQUFkj5B3QS1bpCW+sjR5XfysVEt9qDj1D2A+gd090O9hm287D6Xl3MYe06CJOII81zPdvs+t2nb 6s3t7W63s4fuc3toSnOtz0e3GpvhdqA7Jg/wBE3uP9Zytjoixr7zX2xq18eCxMGG5djhmWng/wIM AMJz9/sNCmVuZHN0cmVhbQ1lbmRvYmoNNCAwIG9iajw8L1VSSShodHRwOi8vd3d3Lm5pc3QuZ292 L2hhc2hfZnVuY3Rpb24pL1MvVVJJPj4NZW5kb2JqDTUgMCBvYmo8PC9IL0kvVHlwZS9Bbm5vdC9S ZWN0WzMwOS42MDAwMDYgMzE5LjkwOTA1OCA0NjEuMjE1Njk4IDMzNC4zMzY5MTRdL0JvcmRlclsw IDAgMF0vQlM8PC9XIDAvVHlwZS9Cb3JkZXIvUy9TPj4vU3VidHlwZS9MaW5rL0EgNCAwIFIvU3Ry dWN0UGFyZW50IDI+Pg1lbmRvYmoNNiAwIG9iajw8L0xlbmd0aCAxNTk2L0ZpbHRlci9GbGF0ZURl Y29kZS9UeXBlL09ialN0bS9GaXJzdCA4MDQvTiAxMDA+PnN0cmVhbQ0KeNrMWE1vGzcQ/SsEek6W w28CgYHEqVHXaSxY7knwQbG3qRpZK8jrNu6vzxuSkiVrtcIWTdGDzSU5fJyZ9zhLLWkhBRlBUgmy QhsS5IR2GPRCRy8oCM9zUUQjhcI4ySgUzMgroTCjlBVKo/UkFJA0bDFEOhqhHMAt5gFkIsYDdjFa qIg2YiPgOROFBp7nHYHnHQkNvCDZH7Q8D7wINzTwojNCe7gCP3RAa9EHtAQ+u0jGCIShKAZh2EWr BG+pESamlLawg0tGou/QAt8Az8BfAzyL4AyH4JSwwLMhCgs8h8QASjmnhQWeJymwtfLWixRiMMIC LyBlGFIBm1jghQgc4EU4ibyq6JzgEKX0AltoiSABqSUGOTSSQTiETgCFqVaI23FqkDQX0HopHEJX YAePWiPpnlMWpAAl2iDZHngmaOGBZ5FkDzzrMc7cgiw8agcQDzwP3j3wOO+AAIwXAXgBQQbgBeQV UDoiOIRoJGHcosXmwSHVIDV4tMhf4JQj+UiZUehEidSDvIiUaoAhFcaApKjRgh9OuQVuBJ6DmCAJ w34hNOORb6bQIwimNrA4JADZIZJMEuhj4UJZ0IsELRJEEXi1BBIIArLk2IaZI7YBVcowDjgCY4LF jAR5ljUewCcRgVbJAgdvBkl/86a6flrW1bhdPd6216u6vmqatrrgcyPFVXU6nz48/DJd8gHi/mi6 qhfJjs/S7sjH+mt7UT8JXV018zot8mxycoJdLiY+ITBNqfG5CbmJqQFFqaHUcPJTtzTZJmYbotJ1 patyK8ta6Uubd3W5q3LjMobWqbHZROc5nXfTGd7knjG5yZYq72HS1jfVCPUgpWJcjevbNoX7sVnd T+eYCJsMfHy8f5hILjrJMVECUFx4GCcZXT6289kCfCyni+rXxV29eu5mzGpUXSPR75qv1fvZn9XZ anpf5ycQt2jaGnb49+Pi7rkz/n0Kjs9mnx9XdXW+YMidoevLt/g75facH/jfWRk5KyPjx2W9erhd zZZtdmf8+Gmn265mX+rmsXTfr5rl6XS53uG0ub+HTH5Q8qr+rYZibktQZ8183vxV3/0EFXKsX/Lw i+598/er9mv76nbW1u3080MaPTkZrqmQZRIy8yHTGjJKyCjBH1ZdzCgxo8SMEjNKtNuCjBklZpQY ixrlC5WuVatLa3ZU6/O0zwKZqCI/t63lckhU3kEXZWd8rbZ1rjO4LnJ3ParPKKboPKMYffgoKL19 ItJxV2nVur5cvvv5qrr89IcoZeSzoHww+PhkEByfDyC8VAuMlXNRnW6Uv65K483IBocXFTew4Fk+ owKDNZvBtbWq3vJbPTkksr8wez51O+iX1YfpE8ubT9/7+rZZTdtZs0jRPS/ZnTxt5s1qIl/Dg/x3 U6KThcSb6u3Em70wnVsn5F1z9/QySto2zZo4nJEB2dNwxtl9Z6jPGcOLOiJQPYsmdlegnAWn9zBs 7NvYbZtq2RuZH2AbBmQswnEb9h3vo2+Cl7HekG/9/mrTS/4O+7qffRpCP+khxmaIseVI9wk2vQST 41VqPz+yN7u+FKqUXdrf0/fuucO+Uf1hxSGlSQ6qYwOMi5ejclfh0M5LMnKCS8ZK6DfbiB/WGPIQ RnkJdExtCuK4na7ac5TARQtlv5apCJb+Kwqv5X9gfrE+CqNyndtOQz6P5WB1xq/NgcXf3et14p18 6XWuu6WSlmLY6Xy+AXRhlFtBx9T/jDy1Js/5vTTkm4nLUnbuYBq8OoRRLlCdU1rxK3i/Trj92pQP 2j/kmXib/RLowr+4zWCvjtakLV9e3DuOWqtB1nqQtRlkbQdZu0HWHrSS3n+Jk+rVD18zeKHbX6hl /8KYFtqOhdS/kGRaaTpWqt6VE6Lyo+gmIeiOaP2RvXfUENwxpQ2TAw3TAw0TRLqHkOqgSh2hipI6 VAdX6hhXSR6qgyt1jKtYfogmrlQHVxT69969qcSj53xgWeB6S9RxYjYfUQ75pdPKDh7I9OeEv9xK uUkKdRBCRwhRO5qJ8ViUw6qISkKhjt+7MhwJLaw/GqTQZOyAcEdC273GSn2sVA98axTA0fqb3PbL vcS3drLzvV4+knQBfO/3Y1xfn8rnxR3XqXyzofLNhqgrhG8CDABo8BZWDQplbmRzdHJlYW0NZW5k b2JqDTcgMCBvYmo8PC9MZW5ndGggMzQxL0ZpbHRlci9GbGF0ZURlY29kZS9UeXBlL09ialN0bS9G aXJzdCAyMDQvTiAyNi9FeHRlbmRzIDYgMCBSPj5zdHJlYW0NCnja1FHbSsNAEP2V+QG7OzN7BQlU 8KFYUWzBB/Gh2m0pSCohgv69s5um3khBH0QfwsnkXJg5QWTQgGiAgoAF6wTk0SzoAW1mhYryjhGI LCBpIC8zIbDOMwGz6ImBHQoaMFo8ojU28w6sJkEP1kTBALb4IzgWZA3OiY4RXJQcJvCSjZLps54N +Cg7sYVgMu8gRNlLvLH4A8Rg4PhYnYHsqeFKXcq2VN5majqpqo4LQ9yFmi5etk+tmrWLpp3Uy1S3 cstIq3l67ucjDCP9C3JZ1OwXjZ+OuMnty6fSfofUIZbrbrPL9KY+DwfzINIBjoe4P1XYt/sNrr+L wtd+Y9cn73rmXc+865n8YM+BBnMh8AHOHODsEPef/8FP5dfNpt3U6/PtMqlpM7/74NdiP62X76Yc Nn7YrOtOp2aPi/t0klbbJhW+zONVm5q9/M1dVa8CDADR7FnODQplbmRzdHJlYW0NZW5kb2JqDTgg MCBvYmo8PC9OdW1zWzAgOSAwIFJdPj4NZW5kb2JqDTkgMCBvYmo8PC9TL0Q+Pg1lbmRvYmoNMTAg MCBvYmo8PC9Db3VudCAyL0tpZHNbMTQyIDAgUiAxIDAgUl0vVHlwZS9QYWdlcz4+DWVuZG9iag0x MSAwIG9iajw8L0xlbmd0aCAzOTg5L1R5cGUvTWV0YWRhdGEvU3VidHlwZS9YTUw+PnN0cmVhbQ0K PD94cGFja2V0IGJlZ2luPSfvu78nIGlkPSdXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQnPz4KPD9h ZG9iZS14YXAtZmlsdGVycyBlc2M9IkNSTEYiPz4NCjx4OnhtcG1ldGEgeG1sbnM6eD0nYWRvYmU6 bnM6bWV0YS8nIHg6eG1wdGs9J1hNUCB0b29sa2l0IDIuOS4xLTEzLCBmcmFtZXdvcmsgMS42Jz4N CjxyZGY6UkRGIHhtbG5zOnJkZj0naHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3lu dGF4LW5zIycgeG1sbnM6aVg9J2h0dHA6Ly9ucy5hZG9iZS5jb20vaVgvMS4wLyc+DQo8cmRmOkRl c2NyaXB0aW9uIHJkZjphYm91dD0ndXVpZDowNjkzNzZjMi0yOTU5LTQ4NzYtOWUyNy1hNDAxZDc4 NzY4ZjAnIHhtbG5zOnBkZj0naHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4zLycgcGRmOlByb2R1 Y2VyPSdBY3JvYmF0IERpc3RpbGxlciA2LjAgKFdpbmRvd3MpJz48L3JkZjpEZXNjcmlwdGlvbj4N CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOjA2OTM3NmMyLTI5NTktNDg3Ni05ZTI3 LWE0MDFkNzg3NjhmMCcgeG1sbnM6cGRmeD0naHR0cDovL25zLmFkb2JlLmNvbS9wZGZ4LzEuMy8n IHBkZng6Q29tcGFueT0nTklTVCcgcGRmeDpTb3VyY2VNb2RpZmllZD0nRDoyMDA1MDQyODE1MTUx MicvPg0KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6MDY5Mzc2YzItMjk1OS00ODc2 LTllMjctYTQwMWQ3ODc2OGYwJyB4bWxuczpwaG90b3Nob3A9J2h0dHA6Ly9ucy5hZG9iZS5jb20v cGhvdG9zaG9wLzEuMC8nPjxwaG90b3Nob3A6aGVhZGxpbmU+PHJkZjpTZXE+PHJkZjpsaT48L3Jk ZjpsaT48L3JkZjpTZXE+PC9waG90b3Nob3A6aGVhZGxpbmU+PC9yZGY6RGVzY3JpcHRpb24+DQo8 cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0ndXVpZDowNjkzNzZjMi0yOTU5LTQ4NzYtOWUyNy1h NDAxZDc4NzY4ZjAnIHhtbG5zOnhhcD0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLycgeGFw OkNyZWF0b3JUb29sPSdBY3JvYmF0IFBERk1ha2VyIDYuMCBmb3IgV29yZCcgeGFwOk1vZGlmeURh dGU9JzIwMDUtMDQtMjhUMTE6MTU6NTMtMDQ6MDAnIHhhcDpDcmVhdGVEYXRlPScyMDA1LTA0LTI4 VDExOjE1OjI0LTA0OjAwJyB4YXA6TWV0YWRhdGFEYXRlPScyMDA1LTA0LTI4VDExOjE1OjUzLTA0 OjAwJz48L3JkZjpEZXNjcmlwdGlvbj4NCjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlk OjA2OTM3NmMyLTI5NTktNDg3Ni05ZTI3LWE0MDFkNzg3NjhmMCcgeG1sbnM6eGFwTU09J2h0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8nIHhhcE1NOkRvY3VtZW50SUQ9J3V1aWQ6OGQwODRj OTgtMjY4ZC00ZGQ3LWIwOTAtZWI0MTM0NzNkOGYxJz48eGFwTU06VmVyc2lvbklEPjxyZGY6U2Vx PjxyZGY6bGk+MjwvcmRmOmxpPjwvcmRmOlNlcT48L3hhcE1NOlZlcnNpb25JRD48L3JkZjpEZXNj cmlwdGlvbj4NCjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOjA2OTM3NmMyLTI5NTkt NDg3Ni05ZTI3LWE0MDFkNzg3NjhmMCcgeG1sbnM6ZGM9J2h0dHA6Ly9wdXJsLm9yZy9kYy9lbGVt ZW50cy8xLjEvJyBkYzpmb3JtYXQ9J2FwcGxpY2F0aW9uL3BkZic+PGRjOnRpdGxlPjxyZGY6QWx0 PjxyZGY6bGkgeG1sOmxhbmc9J3gtZGVmYXVsdCc+VGhpcyB3b3Jrc2hvcCBjb25zaWRlcnMgdGhl IGZ1bGwgcmFuZ2Ugb2YgcHVibGljIGtleSB0ZWNobm9sb2d5IHVzZWQgZm9yIHNlY3VyaXR5IGRl Y2lzaW9uczwvcmRmOmxpPjwvcmRmOkFsdD48L2RjOnRpdGxlPjxkYzpjcmVhdG9yPjxyZGY6U2Vx PjxyZGY6bGk+Y2Fzd2VsbDwvcmRmOmxpPjwvcmRmOlNlcT48L2RjOmNyZWF0b3I+PGRjOnN1Ympl Y3Q+PHJkZjpTZXE+PHJkZjpsaT48L3JkZjpsaT48L3JkZjpTZXE+PC9kYzpzdWJqZWN0PjwvcmRm OkRlc2NyaXB0aW9uPg0KPC9yZGY6UkRGPg0KPC94OnhtcG1ldGE+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgCjw/eHBhY2tldCBlbmQ9J3cnPz4N CmVuZHN0cmVhbQ1lbmRvYmoNMTIgMCBvYmo8PC9Nb2REYXRlKEQ6MjAwNTA0MjgxMTE1NTMtMDQn MDAnKS9DcmVhdGlvbkRhdGUoRDoyMDA1MDQyODExMTUyNC0wNCcwMCcpL1RpdGxlKFRoaXMgd29y a3Nob3AgY29uc2lkZXJzIHRoZSBmdWxsIHJhbmdlIG9mIHB1YmxpYyBrZXkgdGVjaG5vbG9neSB1 c2VkIGZvciBzZWN1cml0eSBkZWNpc2lvbnMpL0NyZWF0b3IoQWNyb2JhdCBQREZNYWtlciA2LjAg Zm9yIFdvcmQpL1Byb2R1Y2VyKEFjcm9iYXQgRGlzdGlsbGVyIDYuMCBcKFdpbmRvd3NcKSkvQXV0 aG9yKGNhc3dlbGwpL0NvbXBhbnkoTklTVCkvU291cmNlTW9kaWZpZWQoRDoyMDA1MDQyODE1MTUx Mik+Pg1lbmRvYmoNeHJlZg0KMCAxMzkNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAxODg3NCAw MDAwMCBuDQowMDAwMDE5MTQ1IDAwMDAwIG4NCjAwMDAwMTkxNjcgMDAwMDAgbg0KMDAwMDAyMTI4 NSAwMDAwMCBuDQowMDAwMDIxMzQ5IDAwMDAwIG4NCjAwMDAwMjE1MTAgMDAwMDAgbg0KMDAwMDAy MzIwMyAwMDAwMCBuDQowMDAwMDIzNjUzIDAwMDAwIG4NCjAwMDAwMjM2ODYgMDAwMDAgbg0KMDAw MDAyMzcwOSAwMDAwMCBuDQowMDAwMDIzNzY4IDAwMDAwIG4NCjAwMDAwMjc4MzQgMDAwMDAgbg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KdHJhaWxlcg0KPDwvU2l6ZSAxMzk+Pg0Kc3RhcnR4cmVmDQoxMTYNCiUlRU9G DQo= --=====================_807180704==_-- From mleech@nortel.com Mon May 2 11:59:47 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j42Fxk5j006008 for ; Mon, 2 May 2005 11:59:46 -0400 (EDT) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57])j42FxcoU011403 for ; Mon, 2 May 2005 11:59:39 -0400 (EDT) Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) id j42FxbB02601 for ; Mon, 2 May 2005 11:59:37 -0400 (EDT) Received: from nortel.com (wcary0w4.ca.nortel.com [47.129.41.8]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 29WLVAN7; Mon, 2 May 2005 11:59:37 -0400 Message-ID: <42764E68.3040408@nortel.com> Date: Mon, 02 May 2005 11:59:36 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Marcus Leech User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: saag@mit.edu Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.903656 Subject: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 02 May 2005 15:59:49 -0000 One of my colleagues pointed me at this document. Quite apart from whatever problems might exist in the protocol itself, it makes an assumption that it will always run of "some kind of secure channel". It's not clear how that's enforced, and given that this protocol is carrying keying material for SRTP, it makes me nervous. Can others take a look and tell me whether I'm out to lunch or not? [In this specific case, not the more general case of me being out to lunch, since I already know that :-) ]. -- Marcus Leech Mail: Dept 1A12, M/S: 04352P16 Security Standards Advisor Phone: (ESN) 393-9145 +1 613 763 9145 Advanced Technology Research Nortel Networks mleech@nortel.com From fluffy@cisco.com Tue May 3 13:27:35 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j43HRX5j018437 for ; Tue, 3 May 2005 13:27:33 -0400 (EDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) j43HROmW015842 for ; Tue, 3 May 2005 13:27:25 -0400 (EDT) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 03 May 2005 10:27:24 -0700 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j43HRMb4012464; Tue, 3 May 2005 10:27:22 -0700 (PDT) Received: from 10.32.130.175 ([10.32.130.175]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 3 May 2005 17:28:38 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 03 May 2005 10:27:22 -0700 Subject: Re: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt From: Cullen Jennings To: Marcus Leech , Message-ID: In-Reply-To: <42764E68.3040408@nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.105173 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 03 May 2005 17:27:36 -0000 I guess this work could be used by many application protocols but the one I am most interested in is SIP so let me answer your question for that one. The application, a SIP UA, in this case needs to decide how it wants the material to be protected - if it does not care, it could just send it. If it wants to enforce all hops use hop by hop protection, it would use a sips URL, it it wanted to enforce end to end protection, it could use the S/MIME stuff. All these are somewhat described in 3261. I imagine for other application that use this the answer would be similar. Any application that has keying material needs to decide how and when to protect it and not much some lower level thing can do about that. Cullen On 5/2/05 8:59 AM, "Marcus Leech" wrote: > One of my colleagues pointed me at this document. Quite apart from > whatever problems might > exist in the protocol itself, it makes an assumption that it will > always run of "some kind of secure > channel". It's not clear how that's enforced, and given that this > protocol is carrying keying material > for SRTP, it makes me nervous. > > Can others take a look and tell me whether I'm out to lunch or not? [In > this specific case, not > the more general case of me being out to lunch, since I already know > that :-) ]. From uri.blumenthal@intel.com Tue May 3 13:53:37 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j43Hra5j018635 for ; Tue, 3 May 2005 13:53:36 -0400 (EDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) j43HrRmW005311 for ; Tue, 3 May 2005 13:53:27 -0400 (EDT) Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) 2004/09/17 17:50:56 root Exp $) with ESMTP id j43HrQJf011738; Tue, 3 May 2005 17:53:26 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) 2004/09/17 18:05:01 root Exp $) with SMTP id j43HrKZ4006429; Tue, 3 May 2005 17:53:26 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) M2005050310532612734 ; Tue, 03 May 2005 10:53:26 -0700 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 10:53:26 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 10:53:25 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 13:53:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt Date: Tue, 3 May 2005 13:52:55 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C59290115A624@pysmsx401.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt Thread-Index: AcVQBwJlSU0+HVDHSBier3c1ZUzhMQAAQhwQ From: "Blumenthal, Uri" To: "Cullen Jennings" , "Marcus Leech" , X-OriginalArrivalTime: 03 May 2005 17:53:24.0659 (UTC) FILETIME=[00B31030:01C55009] X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: -4.9 X-Spam-Flag: NO Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.309726 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id j43Hra5j018635 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 03 May 2005 17:53:38 -0000 > I guess this work could be used by many application protocols but the one I > am most interested in is SIP so let me answer your question for that one. Most likely it will be used by SIP. > The application, a SIP UA, in this case needs to decide how it wants the > material to be protected - if it does not care, it could just send it. If it > wants to enforce all hops use hop by hop protection, it would use a sips > URL, it it wanted to enforce end to end protection, it could use the S/MIME > stuff. All these are somewhat described in 3261. I haven't touched SIP for quite a while - and I don't think may SIP applications (especially those from 3GPP/3GPP2) support S/MIME. Since this proposal suggests sending keys themselves - unless it is demonstrated how the application will *enforce* end-to-end security, the proposed protocol has a nice hop-to-hop hole in it. > I imagine for other application that use this the answer would be similar. :-) > Any application that has keying material needs to decide how and when to > protect it and not much some lower level thing can do about that. Especially since there is no pre-defined lower-level stuff. On 5/2/05 8:59 AM, "Marcus Leech" wrote: > One of my colleagues pointed me at this document. Quite apart from > whatever problems might exist in the protocol itself, it makes an assumption > that it will always run of "some kind of secure channel". It's not clear > how that's enforced, and given that this protocol is carrying keying material > for SRTP, it makes me nervous. I don't think it can be enforced from within SIP. Also, I question appropriate-ness of hop-to-hop security for keying material, even if it could be enforced (which I think it can't). > Can others take a look and tell me whether I'm out to lunch or not? [In > this specific case, not the more general case of me being out to lunch, > since I already know that :-) ]. Leaving alone the general case - yes this particular draft raises security concerns (IMHO). From jari.arkko@piuha.net Tue May 3 15:23:57 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j43JNt5j019466 for ; Tue, 3 May 2005 15:23:56 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) j43JNmf4016014 for ; Tue, 3 May 2005 15:23:48 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 60E6C89844; Tue, 3 May 2005 22:23:47 +0300 (EEST) Message-ID: <4277CFC8.6090009@piuha.net> Date: Tue, 03 May 2005 22:23:52 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Blumenthal, Uri" Subject: Re: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt References: <3DEC199BD7489643817ECA151F7C59290115A624@pysmsx401.amr.corp.intel.com> In-Reply-To: <3DEC199BD7489643817ECA151F7C59290115A624@pysmsx401.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000001 Spam-Alum-Time: 1.110728 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 03 May 2005 19:23:58 -0000 Just FYI that MMUSIC actually has two drafts that can provide keys for things like media streams: - draft-ietf-mmusic-sdescriptions-09.txt, which more or less tells you to send a key in plaintext, but assumes that there's some underlying transport security (tls or s/mime). - draft-ietf-mmusic-kmgmt-ext-14.txt, which is an integrated key management protocol approach. Basically, you run Mikey (RFC 3830) within an SDP attribute, end-to-end. This includes authentication of the endpoints as well as protection for the negotiated data, independent of the security or lack of it for any of the SIP hops. --Jari From uri.blumenthal@intel.com Tue May 3 17:42:58 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j43Lgu5j020404 for ; Tue, 3 May 2005 17:42:56 -0400 (EDT) Received: from fmsfmr002.fm.intel.com (fmr14.intel.com [192.55.52.68]) j43LgkL9028251 for ; Tue, 3 May 2005 17:42:46 -0400 (EDT) Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) 2004/09/17 17:50:56 root Exp $) with ESMTP id j43Lgjg9000770; Tue, 3 May 2005 21:42:45 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) 2004/09/17 18:05:01 root Exp $) with SMTP id j43Lfu1Q017763; Tue, 3 May 2005 21:42:41 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) M2005050314424018806 ; Tue, 03 May 2005 14:42:40 -0700 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 14:42:40 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 14:42:40 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 17:42:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt Date: Tue, 3 May 2005 17:42:09 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C59290115A8AD@pysmsx401.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt Thread-Index: AcVQFahfnn40V4L/RGOY6nJzRmQuxwAEsXKA From: "Blumenthal, Uri" To: "Jari Arkko" X-OriginalArrivalTime: 03 May 2005 21:42:38.0733 (UTC) FILETIME=[06C433D0:01C55029] X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: -4.9 X-Spam-Flag: NO Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.941830 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id j43Lgu5j020404 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 03 May 2005 21:42:59 -0000 The apparent concern of Marcus and me is that the first of these two methods (sdescriptions) makes unreasonable assumptions (regarding underlying protection level) that it cannot verify, and which are not spelled out explicitly (such as minimum requirements, the consequences of adhering and non-adhering, and means to verify that these requirements are satisfied). I wonder why "mmusic-kmgmt-ext" is not enough for key passing, and "mmusic-sdescriptions" wants to do that. -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Tuesday, May 03, 2005 3:24 PM To: Blumenthal, Uri Cc: Cullen Jennings; Marcus Leech; saag@mit.edu Subject: Re: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt Just FYI that MMUSIC actually has two drafts that can provide keys for things like media streams: - draft-ietf-mmusic-sdescriptions-09.txt, which more or less tells you to send a key in plaintext, but assumes that there's some underlying transport security (tls or s/mime). - draft-ietf-mmusic-kmgmt-ext-14.txt, which is an integrated key management protocol approach. Basically, you run Mikey (RFC 3830) within an SDP attribute, end-to-end. This includes authentication of the endpoints as well as protection for the negotiated data, independent of the security or lack of it for any of the SIP hops. --Jari From mbaugher@cisco.com Tue May 3 17:59:16 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j43LxF5j020532 for ; Tue, 3 May 2005 17:59:15 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) j43Lx7vp001712 for ; Tue, 3 May 2005 17:59:08 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 03 May 2005 14:59:08 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j43Lx4hu008649; Tue, 3 May 2005 14:59:05 -0700 (PDT) Received: from [192.168.0.12] (sjc-vpn5-547.cisco.com [10.21.90.35]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j43LnHHV011349; Tue, 3 May 2005 14:49:18 -0700 In-Reply-To: <3DEC199BD7489643817ECA151F7C59290115A8AD@pysmsx401.amr.corp.intel.com> References: <3DEC199BD7489643817ECA151F7C59290115A8AD@pysmsx401.amr.corp.intel.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5c3858a08678505782fdda89ef2706c9@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt Date: Tue, 3 May 2005 14:59:02 -0700 To: "Blumenthal, Uri" X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1115156958.501100"; x:"432200"; a:"rsa-sha1"; b:"nofws:1794"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"HsFjzikviuYqkdwRuKVrQCM5KChkRY5Cb5jxIW8lEnan/o01vSEiWBDEzyu7/8rgkBiOXWeO" "27JydRai/sYMpYXbnqMh017NGALcTnBY3fhda/4XUgNXMuixjCq7WfoXGtj2hPw9AIP/qWtYOIN" "Le8rDwsewON3kiWU+pWWESTI="; c:"From: Mark Baugher "; draft-ietf-mmusic-sdescriptions-09" ".txt"; c:"Date: Tue, 3 May 2005 14:59:02 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.634861 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 03 May 2005 21:59:17 -0000 On May 3, 2005, at 2:42 PM, Blumenthal, Uri wrote: > The apparent concern of Marcus and me is that the first of these two > methods (sdescriptions) makes unreasonable assumptions (regarding > underlying protection level) that it cannot verify, and which are not Any application that requires a secure connection whether it be TLS or IPsec needs to have a policy, enforce a policy and verify that the policy is enforced. What exactly is the problem? > spelled out explicitly (such as minimum requirements, the consequences > of adhering and non-adhering, and means to verify that these > requirements are satisfied). We do not state a particular policy for the application in the I-D that is true. I see that you return to the problem of being able to verify whether there is a secure connection in place or not. Why do you think that the endsystems cannot determine this? > > I wonder why "mmusic-kmgmt-ext" is not enough for key passing, and > "mmusic-sdescriptions" wants to do that. There exists no infrastructure today to support kmgmt or MIKEY. I think that's fairly obvious, isn't it? Mark > > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Tuesday, May 03, 2005 3:24 PM > To: Blumenthal, Uri > Cc: Cullen Jennings; Marcus Leech; saag@mit.edu > Subject: Re: [saag] Problems with > draft-ietf-mmusic-sdescriptions-09.txt > > Just FYI that MMUSIC actually has two drafts that can provide > keys for things like media streams: > > - draft-ietf-mmusic-sdescriptions-09.txt, which more or less > tells you to send a key in plaintext, but assumes that there's > some underlying transport security (tls or s/mime). > > - draft-ietf-mmusic-kmgmt-ext-14.txt, which is an integrated > key management protocol approach. Basically, you run > Mikey (RFC 3830) within an SDP attribute, end-to-end. > This includes authentication of the endpoints as well > as protection for the negotiated data, independent of > the security or lack of it for any of the SIP hops. > > --Jari > > > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag > From Michael.G.Williams@nokia.com Wed May 4 10:51:14 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j44EpD5j027383 for ; Wed, 4 May 2005 10:51:13 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) j44Ep5Xq018384 for ; Wed, 4 May 2005 10:51:06 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120])j44Emsl29709; Wed, 4 May 2005 17:48:54 +0300 (EET DST) X-Scanned: Wed, 4 May 2005 17:48:14 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j44EmExJ026301; Wed, 4 May 2005 17:48:14 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00REtfhz; Wed, 04 May 2005 17:48:12 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) j44ElWM07061; Wed, 4 May 2005 17:47:33 +0300 (EET DST) Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 4 May 2005 17:47:22 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 May 2005 09:47:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt Date: Wed, 4 May 2005 07:47:16 -0700 Message-ID: <8A76136424391244A5CF0165337085371D6CAB@mvebe101.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt Thread-Index: AcVQLW/TnEinfFfbRYKH5kvVjbjAgAAIiKvg From: To: , X-OriginalArrivalTime: 04 May 2005 14:47:17.0437 (UTC) FILETIME=[2AEDF6D0:01C550B8] X-Spam-Score: -4.74 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.757234 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id j44EpD5j027383 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 04 May 2005 14:51:15 -0000 Colleagues, Picking up on the thread below about secure connections, and applications logic or protocol stack implementations wanting to verify what security is in force.... There is some consideration of the various issues of conveying that information within a stack, and across a connection, within the IEEE for layer 2 secure connections. Discussions include the lack of a standardized "trust model" within a protocol stack (O/S specific, beyond the level of interoperability in specs, part of API, etc) Also, how to indicate any form of security is in place at L2, and should such indications be available to other layers directly, or to a management entity, etc. It would be helpful to hear input from this group about the possible utility of an L2 indication to some arbitrary receiver that security is in effect, and what form that indication might usefully take. Best Regards, Michael G. Williams IEEE 802.21 WG Vice Chair -----Original Message----- From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of Mark Baugher Sent: Tuesday, May 03, 2005 2:59 PM To: Blumenthal, Uri Cc: saag@mit.edu Subject: Re: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt On May 3, 2005, at 2:42 PM, Blumenthal, Uri wrote: > The apparent concern of Marcus and me is that the first of these two > methods (sdescriptions) makes unreasonable assumptions (regarding > underlying protection level) that it cannot verify, and which are not Any application that requires a secure connection whether it be TLS or IPsec needs to have a policy, enforce a policy and verify that the policy is enforced. What exactly is the problem? > spelled out explicitly (such as minimum requirements, the consequences > of adhering and non-adhering, and means to verify that these > requirements are satisfied). We do not state a particular policy for the application in the I-D that is true. I see that you return to the problem of being able to verify whether there is a secure connection in place or not. Why do you think that the endsystems cannot determine this? > > I wonder why "mmusic-kmgmt-ext" is not enough for key passing, and > "mmusic-sdescriptions" wants to do that. There exists no infrastructure today to support kmgmt or MIKEY. I think that's fairly obvious, isn't it? Mark > > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Tuesday, May 03, 2005 3:24 PM > To: Blumenthal, Uri > Cc: Cullen Jennings; Marcus Leech; saag@mit.edu > Subject: Re: [saag] Problems with > draft-ietf-mmusic-sdescriptions-09.txt > > Just FYI that MMUSIC actually has two drafts that can provide keys for > things like media streams: > > - draft-ietf-mmusic-sdescriptions-09.txt, which more or less > tells you to send a key in plaintext, but assumes that there's > some underlying transport security (tls or s/mime). > > - draft-ietf-mmusic-kmgmt-ext-14.txt, which is an integrated > key management protocol approach. Basically, you run > Mikey (RFC 3830) within an SDP attribute, end-to-end. > This includes authentication of the endpoints as well > as protection for the negotiated data, independent of > the security or lack of it for any of the SIP hops. > > --Jari > > > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag > _______________________________________________ saag mailing list saag@mit.edu https://jis.mit.edu/mailman/listinfo/saag From uri.blumenthal@intel.com Wed May 4 11:11:37 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j44FBa5j027570 for ; Wed, 4 May 2005 11:11:36 -0400 (EDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) j44FBSXq007125 for ; Wed, 4 May 2005 11:11:28 -0400 (EDT) Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) 2004/09/17 17:50:56 root Exp $) with ESMTP id j44FBS0l024526; Wed, 4 May 2005 15:11:28 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) 2004/09/17 18:05:01 root Exp $) with SMTP id j44FBRJu010167; Wed, 4 May 2005 15:11:27 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) M2005050408112706333 ; Wed, 04 May 2005 08:11:27 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 May 2005 08:11:17 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 May 2005 08:11:17 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 May 2005 11:11:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt Date: Wed, 4 May 2005 11:10:46 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C59290115ABDD@pysmsx401.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt Thread-Index: AcVQLW/TnEinfFfbRYKH5kvVjbjAgAAIiKvgABrWUGA= From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 04 May 2005 15:11:15.0683 (UTC) FILETIME=[8430E330:01C550BB] X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: -4.9 X-Spam-Flag: NO Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.830569 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id j44FBa5j027570 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 04 May 2005 15:11:38 -0000 The concern wrt. L2 security is that it is hop-by-hop. So even if upper layers could learn useful things about the protection provided by the underlying layers - it would last (for L2) only till the next hop. Having said that - it would be very nice to have a standard way of finding out what's the protection level given and upon what credentials... -----Original Message----- From: Michael.G.Williams@nokia.com [mailto:Michael.G.Williams@nokia.com] Sent: Wednesday, May 04, 2005 10:47 AM To: mbaugher@cisco.com; Blumenthal, Uri Cc: saag@mit.edu Subject: RE: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt Colleagues, Picking up on the thread below about secure connections, and applications logic or protocol stack implementations wanting to verify what security is in force.... There is some consideration of the various issues of conveying that information within a stack, and across a connection, within the IEEE for layer 2 secure connections. Discussions include the lack of a standardized "trust model" within a protocol stack (O/S specific, beyond the level of interoperability in specs, part of API, etc) Also, how to indicate any form of security is in place at L2, and should such indications be available to other layers directly, or to a management entity, etc. It would be helpful to hear input from this group about the possible utility of an L2 indication to some arbitrary receiver that security is in effect, and what form that indication might usefully take. Best Regards, Michael G. Williams IEEE 802.21 WG Vice Chair -----Original Message----- From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of Mark Baugher Sent: Tuesday, May 03, 2005 2:59 PM To: Blumenthal, Uri Cc: saag@mit.edu Subject: Re: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt On May 3, 2005, at 2:42 PM, Blumenthal, Uri wrote: > The apparent concern of Marcus and me is that the first of these two > methods (sdescriptions) makes unreasonable assumptions (regarding > underlying protection level) that it cannot verify, and which are not Any application that requires a secure connection whether it be TLS or IPsec needs to have a policy, enforce a policy and verify that the policy is enforced. What exactly is the problem? > spelled out explicitly (such as minimum requirements, the consequences > of adhering and non-adhering, and means to verify that these > requirements are satisfied). We do not state a particular policy for the application in the I-D that is true. I see that you return to the problem of being able to verify whether there is a secure connection in place or not. Why do you think that the endsystems cannot determine this? > > I wonder why "mmusic-kmgmt-ext" is not enough for key passing, and > "mmusic-sdescriptions" wants to do that. There exists no infrastructure today to support kmgmt or MIKEY. I think that's fairly obvious, isn't it? Mark > > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Tuesday, May 03, 2005 3:24 PM > To: Blumenthal, Uri > Cc: Cullen Jennings; Marcus Leech; saag@mit.edu > Subject: Re: [saag] Problems with > draft-ietf-mmusic-sdescriptions-09.txt > > Just FYI that MMUSIC actually has two drafts that can provide keys for > things like media streams: > > - draft-ietf-mmusic-sdescriptions-09.txt, which more or less > tells you to send a key in plaintext, but assumes that there's > some underlying transport security (tls or s/mime). > > - draft-ietf-mmusic-kmgmt-ext-14.txt, which is an integrated > key management protocol approach. Basically, you run > Mikey (RFC 3830) within an SDP attribute, end-to-end. > This includes authentication of the endpoints as well > as protection for the negotiated data, independent of > the security or lack of it for any of the SIP hops. > > --Jari > > > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag > _______________________________________________ saag mailing list saag@mit.edu https://jis.mit.edu/mailman/listinfo/saag From mleech@nortel.com Wed May 4 11:31:49 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j44FVl5j027847 for ; Wed, 4 May 2005 11:31:47 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56])j44FVeXq028257 for ; Wed, 4 May 2005 11:31:41 -0400 (EDT) Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) j44FPWS24415; Wed, 4 May 2005 11:25:32 -0400 (EDT) Received: from nortel.com (wcary0w4.ca.nortel.com [47.129.41.8]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 29WLVQR9; Wed, 4 May 2005 11:25:54 -0400 Message-ID: <4278E982.8070808@nortel.com> Date: Wed, 04 May 2005 11:25:54 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Marcus Leech User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael.G.Williams@nokia.com Subject: Re: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt References: <8A76136424391244A5CF0165337085371D6CAB@mvebe101.NOE.Nokia.com> In-Reply-To: <8A76136424391244A5CF0165337085371D6CAB@mvebe101.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.786983 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 04 May 2005 15:31:50 -0000 Michael.G.Williams@nokia.com wrote: >Colleagues, > >Picking up on the thread below about secure connections, and >applications logic or protocol stack implementations wanting to verify >what security is in force.... > >There is some consideration of the various issues of conveying that >information within a stack, and across a connection, within the IEEE for >layer 2 secure connections. > >Discussions include the lack of a standardized "trust model" within a >protocol stack (O/S specific, beyond the level of interoperability in >specs, part of API, etc) Also, how to indicate any form of security is >in place at L2, and should such indications be available to other layers >directly, or to a management entity, etc. > >It would be helpful to hear input from this group about the possible >utility of an L2 indication to some arbitrary receiver that security is >in effect, and what form that indication might usefully take. > >Best Regards, >Michael G. Williams >IEEE 802.21 WG Vice Chair > > > If the application is only interested in the security of the first hop, then I suppose that some API to determine that such is being effected by L2 might be useful. But most applications care about security beyond the first hop (with certain exceptions). Most IP-using applications (which, let's face it, pretty-much means ALL of them) will span multiple L2 technologies, some of which may, or may not, provide some kind of security mechanism. But what really matters to IP applications is the presence (and quality) of end-to-end security. I will assert (with some expected flamage) that L2 security technologies, such as they are, are largely designed to protect the *revenue* of the L2 network operator. 802.11i, for example, really only protects the first hop, and because of ARP spoofing, can only reasonably be expected to "lock out" those who haven't paid/registered, but it can't reasonably be expected to provide any meaningful confidentiality guarantees for its end users--since those end-users are all "represented" by L3 and higher protocols. -- Marcus Leech Mail: Dept 1A12, M/S: 04352P16 Security Standards Advisor Phone: (ESN) 393-9145 +1 613 763 9145 Advanced Technology Research Nortel Networks mleech@nortel.com From mcr@sandelman.ottawa.on.ca Wed May 4 14:05:34 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j44I5W5j029068 for ; Wed, 4 May 2005 14:05:32 -0400 (EDT) Received: from pike.sandelman.ca (pike.sandelman.ca [205.150.200.164]) j44I5Lx5000304 for ; Wed, 4 May 2005 14:05:25 -0400 (EDT) Received: from sandelman.ottawa.on.ca (road.marajade.sandelman.ca [205.150.200.163]) by pike.sandelman.ca (Postfix) with ESMTP id A829F63705; Wed, 4 May 2005 14:05:20 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id D909CBD6E; Wed, 4 May 2005 14:05:16 -0400 (EDT) To: Marcus Leech , saag@mit.edu Subject: Re: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt In-Reply-To: Message from Marcus Leech of "Wed, 04 May 2005 11:25:54 EDT." <4278E982.8070808@nortel.com> References: <8A76136424391244A5CF0165337085371D6CAB@mvebe101.NOE.Nokia.com> <4278E982.8070808@nortel.com> X-Mailer: MH-E 7.82; nmh 1.0.4+dev; XEmacs 21.4 (patch 17) Date: Wed, 04 May 2005 14:05:16 -0400 Message-ID: <3955.1115229916@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.211149 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 04 May 2005 18:05:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Marcus" == Marcus Leech writes: Marcus> I will assert (with some expected flamage) that L2 security Marcus> technologies, such as they are, are largely designed to Marcus> protect the *revenue* of the L2 network operator. 802.11i, Marcus> for example, really only protects the first hop, and because Marcus> of ARP spoofing, can only reasonably be expected to "lock Marcus> out" those who haven't paid/registered, but it can't Not only that, it doesn't protect the beacon, so with AP-spoofing is possible. Given a settlement system that permits roaming from wireless network to wireless network, with operators collecting fees, 802.11i doesn't even protect the *revenue* stream. - -- ] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [ ] mcr @ xelerance.com Now doing IPsec training, see |net architect[ ] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQnkOyYqHRg3pndX9AQFV9AQA4WpEUWB9Hpc7KEK5F3A0Tb8HsrCXVfeH 3Rif7UZSlw1zgHYEkcwav7hEAhbmLG8HB2KiOc2MrYTzAxPbW6ViMy8JrSVhNIJ6 xNaZ5PRzckiCRHWWz0IDPazZPZXnBBWLK5abEKhWDK5A3cs+0oE7Qqbi0UZxsN2y PdV82cKLVNQ= =47Yp -----END PGP SIGNATURE----- From mleech@nortel.com Wed May 4 14:24:09 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j44IO85j029283 for ; Wed, 4 May 2005 14:24:08 -0400 (EDT) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57])j44IO0x5002264 for ; Wed, 4 May 2005 14:24:00 -0400 (EDT) Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) id j44INuP29416; Wed, 4 May 2005 14:23:56 -0400 (EDT) Received: from nortel.com (wcary0w4.ca.nortel.com [47.129.41.8]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 29WLVSGR; Wed, 4 May 2005 14:23:56 -0400 Message-ID: <4279133C.2040708@nortel.com> Date: Wed, 04 May 2005 14:23:56 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Marcus Leech User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Richardson Subject: Re: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt References: <8A76136424391244A5CF0165337085371D6CAB@mvebe101.NOE.Nokia.com> <4278E982.8070808@nortel.com> <3955.1115229916@marajade.sandelman.ottawa.on.ca> In-Reply-To: <3955.1115229916@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.575801 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 04 May 2005 18:24:10 -0000 802.16 appears to have a similar problem. In PKM, there's no way to tell that you're talking to the real BS--only the client side is authenticated. Ooops. I expect that 802.16ers would reply that in order to actually mount such an MITM, you'd need to actually get up from your living room, change out of your pajamas, and build some slightly-odd hardware. Like that's a big deal or something... Michael Richardson wrote: > > Not only that, it doesn't protect the beacon, so with AP-spoofing is >possible. Given a settlement system that permits roaming from wireless >network to wireless network, with operators collecting fees, 802.11i >doesn't even protect the *revenue* stream. > > > -- Marcus Leech Mail: Dept 1A12, M/S: 04352P16 Security Standards Advisor Phone: (ESN) 393-9145 +1 613 763 9145 Advanced Technology Research Nortel Networks mleech@nortel.com From ldondeti@qualcomm.com Wed May 4 15:23:38 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j44JNb5j029918 for ; Wed, 4 May 2005 15:23:37 -0400 (EDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) j44JNUJD018137 for ; Wed, 4 May 2005 15:23:30 -0400 (EDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) j44JNQdv000735; Wed, 4 May 2005 12:23:26 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) j44JNLIU007616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 May 2005 12:23:22 -0700 (PDT) Message-ID: <4279212A.4090400@qualcomm.com> Date: Wed, 04 May 2005 15:23:22 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcus Leech Subject: Re: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt References: <8A76136424391244A5CF0165337085371D6CAB@mvebe101.NOE.Nokia.com> <4278E982.8070808@nortel.com> <3955.1115229916@marajade.sandelman.ottawa.on.ca> <4279133C.2040708@nortel.com> In-Reply-To: <4279133C.2040708@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621 X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.661909 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: ldondeti@qualcomm.com List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 04 May 2005 19:23:39 -0000 The revised specification is fixing this particular problem though. In the original spec, there was a line of sight requirement for communication (not that that is a valid justification to not require mutual authentication), but now that there is no such requirement and more importantly since folks (especially, Jesse Walker and David Johnston wrote a paper, published several months ago) have pointed out the various security holes in the original dot16 spec, the revised specifications have turned out to be much better (still have other problems though, with the tendency of cafeteria security if there is such a thing: e.g., we will integrity protect in this case, but not in that case etc.). regards, Lakshminath Marcus Leech wrote: > 802.16 appears to have a similar problem. In PKM, there's no way to > tell that you're > talking to the real BS--only the client side is authenticated. Ooops. > > I expect that 802.16ers would reply that in order to actually mount > such an MITM, > you'd need to actually get up from your living room, change out of your > pajamas, and build some slightly-odd hardware. Like that's a big deal > or something... > > > > Michael Richardson wrote: > >> >> Not only that, it doesn't protect the beacon, so with AP-spoofing is >> possible. Given a settlement system that permits roaming from wireless >> network to wireless network, with operators collecting fees, 802.11i >> doesn't even protect the *revenue* stream. >> >> >> From mcr@sandelman.ottawa.on.ca Wed May 4 16:39:44 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j44Kdf5j000862 for ; Wed, 4 May 2005 16:39:42 -0400 (EDT) Received: from pike.sandelman.ca (pike.sandelman.ca [205.150.200.164]) j44KdVuh013565 for ; Wed, 4 May 2005 16:39:32 -0400 (EDT) Received: from sandelman.ottawa.on.ca (road.marajade.sandelman.ca [205.150.200.163]) by pike.sandelman.ca (Postfix) with ESMTP id AEDE06370C; Wed, 4 May 2005 16:39:30 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 14F95BD6E; Wed, 4 May 2005 16:39:25 -0400 (EDT) To: Marcus Leech , saag@mit.edu Subject: Re: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt In-Reply-To: Message from Marcus Leech of "Wed, 04 May 2005 14:23:56 EDT." <4279133C.2040708@nortel.com> References: <8A76136424391244A5CF0165337085371D6CAB@mvebe101.NOE.Nokia.com> <4278E982.8070808@nortel.com> <3955.1115229916@marajade.sandelman.ottawa.on.ca> <4279133C.2040708@nortel.com> X-Mailer: MH-E 7.82; nmh 1.0.4+dev; XEmacs 21.4 (patch 17) Date: Wed, 04 May 2005 16:39:25 -0400 Message-ID: <4766.1115239165@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 2.151678 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 04 May 2005 20:39:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Marcus" == Marcus Leech writes: Marcus> I expect that 802.16ers would reply that in order to Marcus> actually mount such an MITM, you'd need to actually get up Marcus> from your living room, change out of your pajamas, and build Marcus> some slightly-odd hardware. Like that's a big deal or Marcus> something... The AP-spoofing with revenue stream attack can be done with off-the-shelf systems. They *HAVE* to be able to do this, or anyone who announces the same ESSID would shut the boxes down... We had a conversation in DHC a couple of meetings ago about authenticating things. It went like this: Alice: I'm worried that I might not be on the right logical network. Maybe I listened to the wrong DHCP server. Bob: well, I am getting packets from you, and you are getting packets from me, and we are using end-to-end encryption, so I'm sure of it. Alice: yeah, but maybe someone has hijacked the local network and is routing my packets a different way than I'd expect. Bob: okay, but how you tell the difference between a malicious attacker and intelligent network design? they still can't see our traffic. Alice: but maybe they have spoofed you, and all of the Internet. Bob: but, your root name server DNSSEC key confirmed everything, so if they did replicate the internet, they did a good enough job that you can't tell. Alice: oh. (Kind of a "How do I know I exist" argument) - -- ] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [ ] mcr @ xelerance.com Now doing IPsec training, see |net architect[ ] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQnky+4qHRg3pndX9AQFuAAP/RZEP79geSyD7h1XiLG9buz6ObW4f4vT7 j6KXOckKGzS5pYIR4Qx/LQ6AldoRk4a88YKpKY8FCyeiSce3RJ6tv2AUfErSDlI1 M8nqsiBXHZYlQZae1b7V00FV4MmrtN+adQEGDxze91jNb1viJJYTJfYcUi8NSVMn n5qlAGxE/lg= =0zLK -----END PGP SIGNATURE----- From mleech@nortel.com Wed May 4 19:48:53 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j44Nmq5j002625 for ; Wed, 4 May 2005 19:48:52 -0400 (EDT) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57])j44Nmjc8001164 for ; Wed, 4 May 2005 19:48:45 -0400 (EDT) Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) id j44NmbO18253; Wed, 4 May 2005 19:48:37 -0400 (EDT) Received: from nortel.com (abrw003g.ca.nortel.com [47.9.16.116]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 29WLV4L6; Wed, 4 May 2005 19:48:37 -0400 Sender: mleech@nortel.com Message-ID: <42795F55.64BA8E4@nortel.com> Date: Wed, 04 May 2005 19:48:37 -0400 From: "Marcus D. Leech" X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael Richardson Subject: Re: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt References: <8A76136424391244A5CF0165337085371D6CAB@mvebe101.NOE.Nokia.com> <4278E982.8070808@nortel.com> <3955.1115229916@marajade.sandelman.ottawa.on.ca> <4279133C.2040708@nortel.com> <4766.1115239165@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.747502 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 04 May 2005 23:48:55 -0000 Michael Richardson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > > The AP-spoofing with revenue stream attack can be done with > off-the-shelf systems. They *HAVE* to be able to do this, or anyone > who announces the same ESSID would shut the boxes down... > Drifting, like a log caught in the rapids, we are. But. 802.16 is a slightly different kettle of fish than 802.11. 802.16 started out as fixed wireless broadband, and has inherited much from packet-cable. In such systems, there's a significant bandsplit involved. The end-user hardware generally isn't capable of transmitting on the same frequency as the base station. It's a point-to-multipoint scheme with a bandsplit. So in general, the end-user hardware isn't capable of transmitting on the same band as the basestation. But that's just a matter of hardware (and getting up and getting dressed, as it were). [Based on both my reading of the spec, and being a current pre-802.16 customer for my home broadband internet access]. > We had a conversation in DHC a couple of meetings ago about > authenticating things. It went like this: > > Alice: I'm worried that I might not be on the right logical network. > Maybe I listened to the wrong DHCP server. > > Bob: well, I am getting packets from you, and you are getting packets > from me, and we are using end-to-end encryption, so I'm sure > of it. > > Alice: yeah, but maybe someone has hijacked the local network and is > routing my packets a different way than I'd expect. > > Bob: okay, but how you tell the difference between a malicious attacker > and intelligent network design? they still can't see our traffic. > > Alice: but maybe they have spoofed you, and all of the Internet. > > Bob: but, your root name server DNSSEC key confirmed everything, so if > they did replicate the internet, they did a good enough job that > you can't tell. > > Alice: oh. > Right. With adequate L3+higher secure channels, the fact that L2+below is like partially-set jello is just a minor annoyance, rather than a security showstopper. But if you're going to invest as much *work* as groups like 802.16, 802.11, and 802.1ae/af have in secure communications design for L2, you might as well get it right, rather than ignore some very fundamental aspects of the threat model. -- Marcus Leech Mail: Dept 1A12, M/S: 04352P16 Security Standards Advisor Phone: (ESN) 393-9145 +1 613 763 9145 Advanced Technology Research Nortel Networks mleech@nortel.com From rja@extremenetworks.com Thu May 5 06:57:54 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j45Avl5j007706 for ; Thu, 5 May 2005 06:57:52 -0400 (EDT) Received: from lakermmtao09.cox.net (lakermmtao09.cox.net [68.230.240.30]) j45Avb9O004813 for ; Thu, 5 May 2005 06:57:37 -0400 (EDT) Received: from [10.30.20.60] (really [68.10.199.160]) by lakermmtao09.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050505105737.ZXFO6804.lakermmtao09.cox.net@[10.30.20.60]> for ; Thu, 5 May 2005 06:57:37 -0400 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <42795F55.64BA8E4@nortel.com> References: <8A76136424391244A5CF0165337085371D6CAB@mvebe101.NOE.Nokia.com> <4278E982.8070808@nortel.com> <3955.1115229916@marajade.sandelman.ottawa.on.ca> <4279133C.2040708@nortel.com> <4766.1115239165@marajade.sandelman.ottawa.on.ca> <42795F55.64BA8E4@nortel.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <07862E91-CCD2-4D85-A99B-ED076D882C99@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [saag] Layer-2 issues Date: Thu, 5 May 2005 06:57:35 -0400 To: saag@mit.edu X-Mailer: Apple Mail (2.728) X-Spam-Score: -4.397 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.020708 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 05 May 2005 10:57:55 -0000 On May 4, 2005, at 19:48, Marcus D. Leech wrote: > Drifting, like a log caught in the rapids, we are. So true. [stuff trimmed here] > With adequate L3+higher secure channels, the fact that L2+below > is like partially-set jello is just a minor annoyance, rather than > a security showstopper. > > But if you're going to invest as much *work* as groups like > 802.16, > 802.11, and 802.1ae/af have in secure communications design for > L2, > you might as well get it right, rather than ignore some very > fundamental aspects of the threat model. Another of the ways in which this conversation has drifted is that the thread here has been tremendously IP-centric, which maybe is not surprising for the IETF SAAG list after all. However, if one replaces one's IP 'hat' with one's Ethernet 'hat', one will recall that there is sundry information being passed around only at layer-2 (or directly above layer-2 without using IP) that is actually pretty important to keeping layer-2 working properly. For example, it might be a very fine thing if the bridging traffic (e.g. STP, RSTP) were protected -- at least could be authenticated. None of the IETF's higher-layer security mechanisms are helpful at all in protecting this layer-2 control information, so it is quite reasonable for IEEE to undertake its own efforts to address the layer-2 issues, and the IETF solution set is not adequate for those needs. I agree that if a group is going to undertake work, it is important to be realistic about the threat model and to try to do the best job one can -- within the constraints of building a deployable, operable, and affordable system. IETF has a fair amount of experience with complex, hard to deploy, systems that sought "perfect security" and ended up delivering no risk reduction -- sad to say. In my view, security is about incremental risk reduction, not perfect security. This view is considered misguided in some quarters. Yours, Ran rja@extremenetworks.com From aboba@internaut.com Thu May 5 08:47:53 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j45Clp5j008707 for ; Thu, 5 May 2005 08:47:51 -0400 (EDT) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) j45Cli8a029710 for ; Thu, 5 May 2005 08:47:45 -0400 (EDT) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44) id 1DTflY-0004VA-Ic for saag@mit.edu; Thu, 05 May 2005 08:47:44 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j45Clhk03682 for ; Thu, 5 May 2005 05:47:43 -0700 Date: Thu, 5 May 2005 05:47:43 -0700 (PDT) From: Bernard Aboba To: saag@mit.edu Subject: Re: [saag] Layer-2 issues In-Reply-To: <07862E91-CCD2-4D85-A99B-ED076D882C99@extremenetworks.com> Message-ID: References: <8A76136424391244A5CF0165337085371D6CAB@mvebe101.NOE.Nokia.com> <3955.1115229916@marajade.sandelman.ottawa.on.ca> <4766.1115239165@marajade.sandelman.ottawa.on.ca> <07862E91-CCD2-4D85-A99B-ED076D882C99@extremenetworks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000011 Spam-Alum-Time: 1.095594 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 05 May 2005 12:47:54 -0000 > If you're going to invest as much as 802.16.... > have in secure communications design for L2, you might as well get it > right... The IETF has recently received a liaison letter from IEEE 802.16, requesting IETF review of the 802.16e specification which is currently in sponsor ballot. The letter is available here: http://www.ietf.org/IESG/LIAISON/file116.pdf Participants in SAAG who wish to participate in this review can obtain access to the 802.16e document by sending email to me. From aboba@internaut.com Thu May 5 09:20:56 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j45DKt5j009081 for ; Thu, 5 May 2005 09:20:55 -0400 (EDT) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) j45DKl5V005005 for ; Thu, 5 May 2005 09:20:47 -0400 (EDT) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44) id 1DTgHX-000C3l-0F for saag@mit.edu; Thu, 05 May 2005 09:20:47 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j45DKk405831 for ; Thu, 5 May 2005 06:20:46 -0700 Date: Thu, 5 May 2005 06:20:46 -0700 (PDT) From: Bernard Aboba To: saag@mit.edu Subject: Re: [saag] Layer-2 issues In-Reply-To: Message-ID: References: <8A76136424391244A5CF0165337085371D6CAB@mvebe101.NOE.Nokia.com> <3955.1115229916@marajade.sandelman.ottawa.on.ca> <4766.1115239165@marajade.sandelman.ottawa.on.ca> <07862E91-CCD2-4D85-A99B-ED076D882C99@extremenetworks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.704546 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 05 May 2005 13:20:58 -0000 I should mention that a set of strawman review criteria (based on recommendation by Russ Housley included in RFC 4017) are provided here: http://mail.frascone.com/pipermail/eap/2005-May/003393.html On Thu, 5 May 2005, Bernard Aboba wrote: > > If you're going to invest as much as 802.16.... > > have in secure communications design for L2, you might as well get it > > right... > > The IETF has recently received a liaison letter from IEEE 802.16, > requesting IETF review of the 802.16e specification which is currently in > sponsor ballot. > > The letter is available here: > http://www.ietf.org/IESG/LIAISON/file116.pdf > > Participants in SAAG who wish to participate in this review can obtain > access to the 802.16e document by sending email to me. > > > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag > From hartmans@MIT.EDU Thu May 5 19:45:32 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j45NjV5j014214 for ; Thu, 5 May 2005 19:45:31 -0400 (EDT) Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178])j45NjPnk000796 for ; Thu, 5 May 2005 19:45:25 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 19197E0063; Thu, 5 May 2005 19:45:19 -0400 (EDT) To: Marcus Leech Subject: Re: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt References: <42764E68.3040408@nortel.com> From: Sam Hartman Date: Thu, 05 May 2005 19:45:19 -0400 In-Reply-To: <42764E68.3040408@nortel.com> (Marcus Leech's message of "Mon, 02 May 2005 11:59:36 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.605062 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 05 May 2005 23:45:33 -0000 >>>>> "Marcus" == Marcus Leech writes: Marcus> One of my colleagues pointed me at this document. Quite Marcus> apart from whatever problems might exist in the protocol Marcus> itself, it makes an assumption that it will always run of Marcus> "some kind of secure channel". It's not clear how that's Marcus> enforced, and given that this protocol is carrying keying Marcus> material for SRTP, it makes me nervous. No worse than Iscsi depending on IPsec for its protection or sasl plain depending on TLS. ship long sailed. From jari.arkko@piuha.net Fri May 6 06:24:14 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j46AOC5j018880 for ; Fri, 6 May 2005 06:24:12 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) j46AO5X0026870 for ; Fri, 6 May 2005 06:24:06 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8FA0A89879; Fri, 6 May 2005 13:24:04 +0300 (EEST) Message-ID: <427B45CA.9070408@piuha.net> Date: Fri, 06 May 2005 13:24:10 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Baugher Subject: Re: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt References: <3DEC199BD7489643817ECA151F7C59290115A8AD@pysmsx401.amr.corp.intel.com> <5c3858a08678505782fdda89ef2706c9@cisco.com> In-Reply-To: <5c3858a08678505782fdda89ef2706c9@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.594125 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 06 May 2005 10:24:15 -0000 Hi Mark, >> >> I wonder why "mmusic-kmgmt-ext" is not enough for key passing, and >> "mmusic-sdescriptions" wants to do that. > > > There exists no infrastructure today to support kmgmt or MIKEY. I > think that's fairly obvious, isn't it? > I tend to agree with this, at least partially. The infrastructure you are talking about is user to user key infrastructure, and we do not have that in a global scale. But it doesn't necessarily mean that we don't need user to user security. There are some potential usage scenarios: - Users who actually do have sufficient keys already now - Opportunistic security -- I don't know who you are but at least you are the same guy that I talked to last week. This is already specified for SIP (though not widely implemented). Perhaps we should specify that for media streams too, which IMHO is more interesting than securing SIP signaling beyond what is needed for the providers to get paid. - Attempts to build user to user keying infrastructures based on existing security associations between the users and their company or provider. Anyway, I would note that S/MIME + sdescriptions has the same keying problem than kmgmt draft. But the sdescriptions draft does not have a keying problem when it is being used in hop-by-hop fashion, because such security is more widely in use. I see that as the main applicability area of the sdescriptions draft. (Perhaps even to the extent that I would just focus on it on the draft, nothing else.) --Jari From jari.arkko@piuha.net Fri May 6 06:41:05 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j46Af45j019021 for ; Fri, 6 May 2005 06:41:04 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) j46AerX0012758; Fri, 6 May 2005 06:40:53 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id F122789879; Fri, 6 May 2005 13:40:52 +0300 (EEST) Message-ID: <427B49BB.8050503@piuha.net> Date: Fri, 06 May 2005 13:40:59 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman Subject: Re: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt References: <42764E68.3040408@nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.628994 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 06 May 2005 10:41:06 -0000 Sam Hartman wrote: > >>>>> "Marcus" == Marcus Leech writes: > > Marcus> One of my colleagues pointed me at this document. Quite > Marcus> apart from whatever problems might exist in the protocol > Marcus> itself, it makes an assumption that it will always run of > Marcus> "some kind of secure channel". It's not clear how that's > Marcus> enforced, and given that this protocol is carrying keying > Marcus> material for SRTP, it makes me nervous. > > No worse than Iscsi depending on IPsec for its protection or sasl > plain depending on TLS. > Yeah. Lots of protocols depend on security at an underlying layer. Nevertheless, what we normally try to achieve is to have some kind of a assurance that the underlying security is actually on. The further away the security function is, the harder this gets. For instance, apps have in practise easier time dealing with TLS than IPsec. And figuring out if you have hop-by-hop security three proxy hops away is even harder. In terms of IETF specifications, we normally make security at least mandatory to implement, and we try to formulate our requirements so that compliance to them can actually be observed. This is the case also with the sdescriptions draft, though the text isn't very specific -- it just says to use some security. Perhaps this is something that could be strengthened a bit. For instance, in SIP we have a facility called the SIPS uri which ensures (with some limitations) that all hops employ TLS. Instead of "It is REQUIRED that the application invoke its own security mechanisms (e.g., secure multiparts such as S/MIME [smime]) or alternatively utilize a lower-layer security service (e.g., TLS, or IPSec)." Mark you could say "Applications MUST employ a security mechanism when using this specification. When this specification is used in the context of SIP [RFC3261], the application SHOULD employ either the SIPS URI or S/MIME, to ensure that complete signaling path is protected. The use of transport or IP layer security is NOT RECOMMENDED in situations where the availability of such protection through all intermediate entities such as SIP proxies is not assured, such as when the TLS is employed without the SIPS URI." Would this help? --Jari From rja@extremenetworks.com Fri May 6 08:25:37 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j46CPa5j019794 for ; Fri, 6 May 2005 08:25:36 -0400 (EDT) Received: from lakermmtao02.cox.net (lakermmtao02.cox.net [68.230.240.37]) j46CPSJj020873 for ; Fri, 6 May 2005 08:25:29 -0400 (EDT) Received: from [10.30.20.60] (really [68.10.199.160]) by lakermmtao02.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050506122528.UTUG26223.lakermmtao02.cox.net@[10.30.20.60]>; Fri, 6 May 2005 08:25:28 -0400 In-Reply-To: <427B49BB.8050503@piuha.net> References: <42764E68.3040408@nortel.com> <427B49BB.8050503@piuha.net> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [saag] Problems with SIP security Date: Fri, 6 May 2005 08:25:26 -0400 To: Jari Arkko X-Mailer: Apple Mail (2.728) X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.700137 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 06 May 2005 12:25:39 -0000 On May 6, 2005, at 06:40, Jari Arkko wrote: > Yeah. Lots of protocols depend on security at an underlying layer. > Nevertheless, what we normally try to achieve is to have some kind > of a assurance that the underlying security is actually on. The > further away the security function is, the harder this gets. For > instance, > apps have in practise easier time dealing with TLS than IPsec. And > figuring out if you have hop-by-hop security three proxy hops away > is even harder. I do regret that we did not putting more effort into documenting (e.g. in an RFC) the API extensions for IPsec that we developed back in 1995. Those API extensions let an application request security services from the IPsec subsystem and also let the application learn (with confidence, directly from the trusted computing base) which security services were actually available and in-use on a given socket. There were also both system-wide security policy defaults (configurable) and per-application policy settings (also configurable). In broader terms, I think that the IETF tends to assume that if the protocols are specified clearly that suitable APIs will just happen naturally. As I look back over the past 20 years, those APIs tend not to "just happen naturally" or even in a particularly timely manner. > In terms of IETF specifications, we normally make security at least > mandatory to implement, and we try to formulate our requirements > so that compliance to them can actually be observed. This is the > case also with the sdescriptions draft, though the text isn't very > specific -- it just says to use some security. Perhaps this is > something > that could be strengthened a bit. For instance, in SIP we have a > facility > called the SIPS uri which ensures (with some limitations) that all > hops > employ TLS. Instead of > > "It is REQUIRED that the application invoke > its own security mechanisms (e.g., secure multiparts such as S/MIME > [smime]) or alternatively utilize a lower-layer security service > (e.g., TLS, or IPSec)." > > Mark you could say > > "Applications MUST employ a security mechanism when using this > specification. When this specification is used in the context of > SIP > [RFC3261], the application SHOULD employ either the SIPS URI > or S/MIME, to ensure that complete signaling path is protected. > The use of transport or IP layer security is NOT RECOMMENDED > in situations where the availability of such protection through all > intermediate entities such as SIP proxies is not assured, such as > when the TLS is employed without the SIPS URI." > > Would this help? The original text you quote clearly needs improvement. Most anything would be an improvement. One of my concerns here is that if we create lots of options, then different implementations will choose different subsets to implement and *in practice* end-users won't be able to use any of the security capabilities. For example, if implementation A uses SIPS URI but does not implement S/MIME for SIP & implementation B uses S/MIME but does not implement SIPS URI, then the bottom line is that no secured communication will be possible and the deployments will fall back to using clear-text. I think the SIP WG needs to pick a single mandatory-to-implement mechanism, allowing for other optional-to-implement mechanisms as well if there really is a need for multiple approaches. That way the fallback posture will be to that single mandatory-to-implement mechanism and deployments will always be able to have appropriate security. It isn't obvious to me (I'm not a SIP expert) which of these mechanisms should be the mandatory-to-implement one, but it is clear to me that the first steps to selection involve a documented threat analysis and also some cost/benefit analysis of the various standards-track options that might become the mandatory-to-implement option. Ideally, this threat analysis is generated by the SIP WG (with help from the Security Area) and gets broad review by SAAG (and maybe some specific Security Area WGs, as the ADs think best) before a final selection is made. Yours, Ran rja@extremenetworks.com From jari.arkko@piuha.net Fri May 6 09:17:28 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j46DHQ5j020165 for ; Fri, 6 May 2005 09:17:26 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) j46DHJJj000268 for ; Fri, 6 May 2005 09:17:19 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7CA0B89879; Fri, 6 May 2005 16:17:18 +0300 (EEST) Message-ID: <427B6E64.3000707@piuha.net> Date: Fri, 06 May 2005 16:17:24 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Marcus D. Leech" Subject: Re: [saag] Layer-2 issues References: <8A76136424391244A5CF0165337085371D6CAB@mvebe101.NOE.Nokia.com> <4278E982.8070808@nortel.com> <3955.1115229916@marajade.sandelman.ottawa.on.ca> <4279133C.2040708@nortel.com> <4766.1115239165@marajade.sandelman.ottawa.on.ca> <42795F55.64BA8E4@nortel.com> In-Reply-To: <42795F55.64BA8E4@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.015551 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 06 May 2005 13:17:29 -0000 Hi Marcus >Right. With adequate L3+higher secure channels, the fact that L2+below > is like partially-set jello is just a minor annoyance, rather than > a security showstopper. > > Depends on your point of view. The network access industry may not agree that its a minor annoyance if the technology that their revenues are based on turns to jello. >But if you're going to invest as much *work* as groups like 802.16, 802.11, and > 802.1ae/af have in secure communications design for L2, you might as well > get it right, rather than ignore some very fundamental aspects of the > threat model. > > Yes. And there are many things that remain to be done. While things are improving, there are significant tasks left with regards to, for instance, - better security, particularly dos issues, privacy, trusting the whole network as one entity when you have roaming and many of the devices are nowadays hanging from coffee shop walls - efficiency of the network access stack wrt movements - functionality, e.g., distribution of information about the available networks - interoperability, e.g., many authentication methods are proprietary - new link layers Bernard already advertised 802.16's call for review. But its also important for everyone to realize that this not just some problem that IEEE and 3GPP deal with. The IETF is responsible for a large fraction of the infrastructure components and protocols employed by the network access industry. For instance: - RADIUS (RADEXT WG) - Diameter (AAA WG) - Extensible Authentication Protocol (EAP WG) - PANA (PANA WG ) - IKEv2 (used by several network access related initiatives such as 3G-WLAN interworking and Unlicensed Mobile Access) - DNA (DHC and DNA WGs) Lets get to work and do our part! For instance, in the EAP WG we are working on a document that describes how keys generated as a part of network access authentication can be used for L2 protection, both current usage and enhanced functionality such as fast handovers. This work could use additional contributors with security clue -- let me or Bernard know if you are interested in contributing. --Jari From mbaugher@cisco.com Fri May 6 09:30:20 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j46DUI5j020277 for ; Fri, 6 May 2005 09:30:19 -0400 (EDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) j46DU7tL002537 for ; Fri, 6 May 2005 09:30:08 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 06 May 2005 06:30:08 -0700 X-IronPort-AV: i="3.92,160,1112598000"; d="scan'208"; a="634711415:sNHT30558052" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j46DU3O3001229; Fri, 6 May 2005 06:30:04 -0700 (PDT) Received: from [192.168.0.11] (sjc-vpn1-431.cisco.com [10.21.97.175]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j46DK6ST003584; Fri, 6 May 2005 06:20:06 -0700 In-Reply-To: <427B45CA.9070408@piuha.net> References: <3DEC199BD7489643817ECA151F7C59290115A8AD@pysmsx401.amr.corp.intel.com> <5c3858a08678505782fdda89ef2706c9@cisco.com> <427B45CA.9070408@piuha.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt Date: Fri, 6 May 2005 06:29:59 -0700 To: Jari Arkko X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1115385607.265936"; x:"432200"; a:"rsa-sha1"; b:"nofws:3523"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"LnyQ+b93iZdOmsGzS5BIo0aKGgw5AbTdXGV/bkHaWiR1kTJ7h9zNivPDRkT17C1VvbsnUfLd" "LPMxOuguVdGFi6OwHp8MotG7LgPzAwp96t5YKZUh/LkSvL6+8bOpJqdwXhmadDXffJZP3Yc2tAX" "TZK/otEhCZo4czQ822TFx62A="; c:"From: Mark Baugher "; draft-ietf-mmusic-sdescriptions-09" ".txt"; c:"Date: Fri, 6 May 2005 06:29:59 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.208993 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 06 May 2005 13:30:22 -0000 Jari, On May 6, 2005, at 3:24 AM, Jari Arkko wrote: > Hi Mark, > >>> >>> I wonder why "mmusic-kmgmt-ext" is not enough for key passing, and >>> "mmusic-sdescriptions" wants to do that. >> >> >> There exists no infrastructure today to support kmgmt or MIKEY. I >> think that's fairly obvious, isn't it? >> > I tend to agree with this, at least partially. > > The infrastructure you are talking about is user to user key > infrastructure, and we do not have that in a global scale. > But it doesn't necessarily mean that we don't need user to > user security. There are some potential usage scenarios: > > - Users who actually do have sufficient keys already now > - Opportunistic security -- I don't know who you are but > at least you are the same guy that I talked to last week. > This is already specified for SIP (though not widely > implemented). Perhaps we should specify that for media > streams too, which IMHO is more interesting than > securing SIP signaling beyond what is needed for > the providers to get paid. > - Attempts to build user to user keying infrastructures > based on existing security associations between the > users and their company or provider. > > Anyway, I would note that S/MIME + sdescriptions has > the same keying problem than kmgmt draft. But the > sdescriptions draft does not have a keying problem when > it is being used in hop-by-hop fashion, because such > security is more widely in use. I see that as the main > applicability area of the sdescriptions draft. (Perhaps > even to the extent that I would just focus on it on the > draft, nothing else.) To the extent that voip traffic is protected today, it is often protected by a VPN. In the case of toll-bypass applications where for example two gateways link two PSTNs, it is possible to use SRTP on the bearer channel and realize increased capacity using cRTP while keeping the signaling channel protected by the VPN. In this case, sdescriptions is a relatively cheap and secure way to establish SRTP keys. I estimated that there would be a 5X-10X increase in development and testing costs in deploying kmgmt+MIKEY, which bring no advantage whatsoever to this common voip application. This is also the end-to-end voip case in which a VPN connects two call-signaling proxies across a public network while the other proxies operate without secure hops because they are deemed to be on private "secure" networks. sdescriptions is a straightforward a secure way to transition from VPN protection to SRTP protection by keeping the signaling channel in the VPN and securing the bearer channel with SRTP. The largest case is by far the most problematic: A path of proxies is protected by a set of hop-by-hop VPNs. There is no shared key infrastructure and no PKI that allows a caller to obtain a key for the callee. kmgmt+MIKEY can't be used until this infrastructure is established. sdescriptions can be used, which may be considered either better than no security at all or worse than no security at all. It's worse than no security at all because an end system can't determine whether or not two proxies along the path failed to establish a secure hop - both would need to have failed or have been subverted for this to happen but there's no way to tell. It's better than no security to the extent that the proxies are under secure administration and the operators are executing a transition plan to overcome these limitations. Maybe they are building a PKI. Stranger things have been known to happen. In the PKI case, I think there is an advantage to protecting the keying material with the call signaling information as sdescriptions does, but I think we're a very long way off from having a PKI for public telephony. There are alternative means that involve the user and assume person-to-person voice recognition. A lot of these schemes fail in cases where one of the end systems is a machine and not a person. There is also a lot of resistance to forcing the user to take explicit actions such as typing a key fingerprint. But I am going off on a tangent here. My point is, sdescriptions is applicable to many cases where a VPN is appropriately and securely used to protect IP telephony traffic today and where there is an advantage to changing the bearer channel to use SRTP. Mark > > --Jari > From mbaugher@cisco.com Fri May 6 10:06:06 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j46E655j020543 for ; Fri, 6 May 2005 10:06:05 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) j46E5wJj020800 for ; Fri, 6 May 2005 10:05:58 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 06 May 2005 07:05:46 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j46E5cER026051; Fri, 6 May 2005 07:05:39 -0700 (PDT) Received: from [192.168.0.11] (sjc-vpn1-431.cisco.com [10.21.97.175]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j46DtiFM003754; Fri, 6 May 2005 06:55:44 -0700 In-Reply-To: <42764E68.3040408@nortel.com> References: <42764E68.3040408@nortel.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt Date: Fri, 6 May 2005 07:05:38 -0700 To: Marcus Leech X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1115387744.781640"; x:"432200"; a:"rsa-sha1"; b:"nofws:830"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"J2tYA/Rg0mXg16BWZdcZ6bs96lIK+GftH5tCs4VzNhG2mHyG6OPymwkOXqmjXoF9IlRuLvWm" "Fs+Z2DujcyOa8m4drCAmWGajEvgxIeNsK9ko5581oGvOblMu28UTWqiyJiOXKlPBUrXThXmiIM6" "y1zpSPW8r/IL2KyZ/20SF5qc="; c:"From: Mark Baugher "; draft-ietf-mmusic-sdescriptions-09" ".txt"; c:"Date: Fri, 6 May 2005 07:05:38 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.043548 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 06 May 2005 14:06:08 -0000 On May 2, 2005, at 8:59 AM, Marcus Leech wrote: > One of my colleagues pointed me at this document. Quite apart from > whatever problems might > exist in the protocol itself, it makes an assumption that it will > always run of "some kind of secure > channel". It's not clear how that's enforced, and given that this > protocol is carrying keying material > for SRTP, it makes me nervous. We recommend use of a data security protocol for protecting key establishment exchanges in RFC 4046. Mark > > Can others take a look and tell me whether I'm out to lunch or not? > [In this specific case, not > the more general case of me being out to lunch, since I already know > that :-) ]. > > -- > Marcus Leech Mail: Dept 1A12, M/S: > 04352P16 > Security Standards Advisor Phone: (ESN) 393-9145 +1 613 763 > 9145 > Advanced Technology Research > Nortel Networks mleech@nortel.com > > > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag > From mbaugher@cisco.com Fri May 6 10:44:03 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j46Ei15j020999 for ; Fri, 6 May 2005 10:44:01 -0400 (EDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) j46EhsJj010163 for ; Fri, 6 May 2005 10:43:54 -0400 (EDT) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 06 May 2005 07:43:51 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j46EhmnC011896; Fri, 6 May 2005 07:43:49 -0700 (PDT) Received: from [192.168.0.11] (sjc-vpn1-431.cisco.com [10.21.97.175]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j46EX8Bh004059; Fri, 6 May 2005 07:33:52 -0700 In-Reply-To: References: <42764E68.3040408@nortel.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <639ad31f2a0717237a25639302f3dd0b@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt Date: Fri, 6 May 2005 07:43:46 -0700 To: RJ Atkinson X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1115390032.612832"; x:"432200"; a:"rsa-sha1"; b:"nofws:941"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"VbPP9VV+HDGF6sJAtLu2cbyxjWpIg0jC6xHoNGHOUNbogRKOc8t8pPL2KrZGEVIu1SBNPrZA" "SOo1/PXZCSnF9YYro/JBaFZD3UydWG6NPI2sw1hQt8QcpYpoP0hy8/1j9sFXzJDBi3JENj7TTTH" "D0qEyGzEwcPkqNaiCxffXwb8="; c:"From: Mark Baugher "; draft-ietf-mmusic-sdescriptions-09" ".txt"; c:"Date: Fri, 6 May 2005 07:43:46 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.727283 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 06 May 2005 14:44:05 -0000 On May 6, 2005, at 7:24 AM, RJ Atkinson wrote: > > On May 6, 2005, at 10:05, Mark Baugher wrote: >> We recommend use of a data security protocol for protecting key >> establishment exchanges in RFC 4046. > > Even if the right decisions/recommendations have been made, > which is not clear to me as I haven't been tracking this in detail, > it is pretty clear from this conversation that reasonable people > are not able to figure out what those decisions/recommendations > are and what the overall security strategy actually is from the > current documents. > > One would hope that would be taken by the applicable WGs and > document editors as a hint that the documentation set really needs > to be clarified so that reasonable people won't have any > confusion about such things. That probably involves some combination > of revised text, additional references, and maybe even an extra > document or two. Yes, its a pain, but if interoperability is the goal, > then clear documentation is usually required to achieve success. RFC 4046 is Informational so interoperability is not the near-term goal of this document. Mark > > Cheers, > > Ran > From nw141292@binky.Central.Sun.COM Fri May 6 10:51:03 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j46Ep25j021095 for ; Fri, 6 May 2005 10:51:02 -0400 (EDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) j46EorvK027701 for ; Fri, 6 May 2005 10:50:53 -0400 (EDT) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j46EorjO009853 for ; Fri, 6 May 2005 08:50:53 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) with ESMTP id j46Eoqac005899 for ; Fri, 6 May 2005 08:50:53 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) j46EoqXK012320; Fri, 6 May 2005 09:50:52 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j46Eooco012319; Fri, 6 May 2005 09:50:50 -0500 (CDT) Date: Fri, 6 May 2005 09:50:50 -0500 From: Nicolas Williams To: RJ Atkinson Subject: Abstract APIs are good (Re: [saag] Problems with SIP security) Message-ID: <20050506145049.GA4008@binky.Central.Sun.COM> References: <42764E68.3040408@nortel.com> <427B49BB.8050503@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.969563 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 06 May 2005 14:51:04 -0000 On Fri, May 06, 2005 at 08:25:26AM -0400, RJ Atkinson wrote: > I do regret that we did not putting more effort into documenting > (e.g. in an RFC) the API extensions for IPsec that we developed back > in 1995. Those API extensions let an application request security > services from the IPsec subsystem and also let the application learn > (with confidence, directly from the trusted computing base) which > security services were actually available and in-use on a given socket. > There were also both system-wide security policy defaults (configurable) > and per-application policy settings (also configurable). > > In broader terms, I think that the IETF tends to assume that if the > protocols are specified clearly that suitable APIs will just happen > naturally. As I look back over the past 20 years, those APIs tend > not to "just happen naturally" or even in a particularly timely > manner. Thank you. I've been making this point for a while too. The IETF should not shirk from specifying at least abstract APIs where those are applicable. Does FTP need an abstract API? No. Does IPsec? YES. Nico -- From bill@strahm.net Fri May 6 11:05:37 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j46F5Z5j021224 for ; Fri, 6 May 2005 11:05:35 -0400 (EDT) Received: from smtpout03-03.mesa1.secureserver.net (smtpout03-03.mesa1.secureserver.net [64.202.165.73])j46F5PJj020461 for ; Fri, 6 May 2005 11:05:26 -0400 (EDT) Received: (qmail 14545 invoked from network); 6 May 2005 15:05:25 -0000 Received: from unknown (HELO webmail09.mesa1.secureserver.net) (64.202.189.46) by smtpout03-03.mesa1.secureserver.net with SMTP; 6 May 2005 15:05:25 -0000 Received: (qmail 29960 invoked by uid 99); 6 May 2005 15:05:25 -0000 Message-ID: <20050506150525.29959.qmail@webmail09.mesa1.secureserver.net> Date: Fri, 6 May 2005 08:05:25 -0700 From: bill@strahm.net Subject: RE: Abstract APIs are good (Re: [saag] Problems with SIP security) To: Nicolas Williams MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII X-Spam-Score: -4.74 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.959643 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 06 May 2005 15:05:38 -0000 Abstract APIs are evil. Well - they tend to go under the noun of "Verbs" today - I know the Infiniband folk love their "Verbs" document. What is a verb you might ask - it is a piece of functionality that is exposed, not an API. So you have all the manufacturers out there building their own "Verbs" layers, each with their own quirks - that are totally uninteroperable with each other. Here you have the worst of both worlds, a standardized set of functionality that can't be changed, enhanced, or optimized - AND something that can't be ported (or for that matter applications written to the "Verbs" interface have to be ported to each particular "Verbs implementation") Please stay away from these things - they are dangerous Bill > -------- Original Message -------- > Subject: Abstract APIs are good (Re: [saag] Problems with SIP security) > From: Nicolas Williams > Date: Fri, May 06, 2005 7:50 am > To: RJ Atkinson > Cc: saag@mit.edu > > On Fri, May 06, 2005 at 08:25:26AM -0400, RJ Atkinson wrote: > > I do regret that we did not putting more effort into documenting > > (e.g. in an RFC) the API extensions for IPsec that we developed back > > in 1995. Those API extensions let an application request security > > services from the IPsec subsystem and also let the application learn > > (with confidence, directly from the trusted computing base) which > > security services were actually available and in-use on a given socket. > > There were also both system-wide security policy defaults (configurable) > > and per-application policy settings (also configurable). > > > > In broader terms, I think that the IETF tends to assume that if the > > protocols are specified clearly that suitable APIs will just happen > > naturally. As I look back over the past 20 years, those APIs tend > > not to "just happen naturally" or even in a particularly timely > > manner. > > Thank you. I've been making this point for a while too. The IETF > should not shirk from specifying at least abstract APIs where those are > applicable. Does FTP need an abstract API? No. Does IPsec? YES. > > Nico > -- > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag From nw141292@binky.Central.Sun.COM Fri May 6 11:15:01 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j46FF05j021400 for ; Fri, 6 May 2005 11:15:00 -0400 (EDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) j46FEqJj008835 for ; Fri, 6 May 2005 11:14:52 -0400 (EDT) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j46FEqjO002724 for ; Fri, 6 May 2005 09:14:52 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) with ESMTP id j46FEpac016511 for ; Fri, 6 May 2005 09:14:52 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) j46FEpjo012339; Fri, 6 May 2005 10:14:51 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j46FEo4M012338; Fri, 6 May 2005 10:14:50 -0500 (CDT) Date: Fri, 6 May 2005 10:14:50 -0500 From: Nicolas Williams To: bill@strahm.net Subject: Re: Abstract APIs are good (Re: [saag] Problems with SIP security) Message-ID: <20050506151450.GC4008@binky.Central.Sun.COM> References: <20050506150525.29959.qmail@webmail09.mesa1.secureserver.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050506150525.29959.qmail@webmail09.mesa1.secureserver.net> User-Agent: Mutt/1.5.7i X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.581633 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 06 May 2005 15:15:03 -0000 On Fri, May 06, 2005 at 08:05:25AM -0700, bill@strahm.net wrote: > Abstract APIs are evil. > > Well - they tend to go under the noun of "Verbs" today - I know the > Infiniband folk love their "Verbs" document. > > What is a verb you might ask - it is a piece of functionality that is > exposed, not an API. So you have all the manufacturers out there > building their own "Verbs" layers, each with their own quirks - that > are totally uninteroperable with each other. Doesn't sound like a good abstract API underlies those implementations' concrete APIs. > Here you have the worst of both worlds, a standardized set of > functionality that can't be changed, enhanced, or optimized - AND > something that can't be ported (or for that matter applications written > to the "Verbs" interface have to be ported to each particular "Verbs > implementation") Are you saying that concrete APIs are better? If so, I should point out that abstract APIs are a good first step. If you're saying APIs are bad, then I must admit to being puzzled by your complaining about non-portability. Nico -- From uri.blumenthal@intel.com Fri May 6 11:44:39 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j46Fib5j021755 for ; Fri, 6 May 2005 11:44:37 -0400 (EDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) j46FiTJj026455 for ; Fri, 6 May 2005 11:44:29 -0400 (EDT) Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) 2004/09/17 17:50:56 root Exp $) with ESMTP id j46FiTmO025287; Fri, 6 May 2005 15:44:29 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) 2004/09/17 18:05:01 root Exp $) with SMTP id j46FiC90025336; Fri, 6 May 2005 15:44:29 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) M2005050608442622480 ; Fri, 06 May 2005 08:44:26 -0700 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 May 2005 08:44:26 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 May 2005 08:44:26 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 May 2005 11:44:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Abstract APIs are good (Re: [saag] Problems with SIP security) Date: Fri, 6 May 2005 11:43:52 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C592901195DAE@pysmsx401.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Abstract APIs are good (Re: [saag] Problems with SIP security) Thread-Index: AcVSTxrN6gPA8n4aRuq1K5+9hI2QyQAAwZHg From: "Blumenthal, Uri" To: "Nicolas Williams" , X-OriginalArrivalTime: 06 May 2005 15:44:24.0923 (UTC) FILETIME=[7AB252B0:01C55252] X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: -4.9 X-Spam-Flag: NO Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.737870 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id j46Fib5j021755 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 06 May 2005 15:44:41 -0000 Nico, I'm 100% with you on this. In fact, even though it's somewhat too late and IPsec mostly has missed the train - perhaps we can specify the abstract APIs (and then maybe even the actual API that would be implemented by OpenSWAN)... Bill, I'm disappointed to hear this from you. -----Original Message----- From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of Nicolas Williams Sent: Friday, May 06, 2005 11:15 AM To: bill@strahm.net Cc: saag@mit.edu Subject: Re: Abstract APIs are good (Re: [saag] Problems with SIP security) On Fri, May 06, 2005 at 08:05:25AM -0700, bill@strahm.net wrote: > Abstract APIs are evil. > > Well - they tend to go under the noun of "Verbs" today - I know the > Infiniband folk love their "Verbs" document. > > What is a verb you might ask - it is a piece of functionality that is > exposed, not an API. So you have all the manufacturers out there > building their own "Verbs" layers, each with their own quirks - that > are totally uninteroperable with each other. Doesn't sound like a good abstract API underlies those implementations' concrete APIs. > Here you have the worst of both worlds, a standardized set of > functionality that can't be changed, enhanced, or optimized - AND > something that can't be ported (or for that matter applications written > to the "Verbs" interface have to be ported to each particular "Verbs > implementation") Are you saying that concrete APIs are better? If so, I should point out that abstract APIs are a good first step. If you're saying APIs are bad, then I must admit to being puzzled by your complaining about non-portability. Nico -- _______________________________________________ saag mailing list saag@mit.edu https://jis.mit.edu/mailman/listinfo/saag From rja@extremenetworks.com Fri May 6 12:00:54 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j46G0q5j021938 for ; Fri, 6 May 2005 12:00:52 -0400 (EDT) Received: from lakermmtao12.cox.net (lakermmtao12.cox.net [68.230.240.27]) j46G0jJj025076 for ; Fri, 6 May 2005 12:00:45 -0400 (EDT) Received: from [10.30.20.60] (really [68.10.199.160]) by lakermmtao12.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050506160044.VZTZ10612.lakermmtao12.cox.net@[10.30.20.60]>; Fri, 6 May 2005 12:00:44 -0400 In-Reply-To: <3DEC199BD7489643817ECA151F7C592901195DAE@pysmsx401.amr.corp.intel.com> References: <3DEC199BD7489643817ECA151F7C592901195DAE@pysmsx401.amr.corp.intel.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: Abstract APIs are good (Re: [saag] Problems with SIP security) Date: Fri, 6 May 2005 12:00:41 -0400 To: "Blumenthal, Uri" X-Mailer: Apple Mail (2.728) X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.059670 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 06 May 2005 16:00:55 -0000 On May 6, 2005, at 11:43, Blumenthal, Uri wrote: > Nico, I'm 100% with you on this. In fact, even though it's somewhat > too > late and IPsec mostly has missed the train - perhaps we can specify > the > abstract APIs (and then maybe even the actual API that would be > implemented by OpenSWAN)... I think (most of) the NRL IPsec extensions to BSD Sockets are in the KAME and other BSD releases already. Maybe the set of IPsec implementers who support a BSD Sockets interface could get together, work out any differences, add any missing pieces, and publish an Informational RFC...better late than never. To their credit, the other folks at NRL did manage to get the PF_KEY API documented (after I was gone and it was their work anyway). That seems to be reasonably widely available today. Yours, Ran rja@extremenetworks.com From barney@databus.com Mon Mar 21 16:29:22 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2LLTL5j005765 for ; Mon, 21 Mar 2005 16:29:21 -0500 (EST) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) j2LLSe9k003478 for ; Mon, 21 Mar 2005 16:28:41 -0500 (EST) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.13.1/8.13.1) with ESMTP id j2LLQgEk096653; Mon, 21 Mar 2005 16:26:42 -0500 (EST) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.13.1/8.13.1/Submit) id j2LLQgeW096652; Mon, 21 Mar 2005 16:26:42 -0500 (EST) (envelope-from barney) From: Barney Wolff To: Ben Laurie Message-ID: <20050321212642.GA95604@pit.databus.com> References: <423EB67C.1000004@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423EB67C.1000004@algroup.co.uk> User-Agent: Mutt/1.5.8i X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.51 on 66.114.72.185 X-Spam-Score: -4.9 X-Spam-Flag: NO Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.983020 X-Mailman-Approved-At: Fri, 06 May 2005 13:23:40 -0400 cc: saag@mit.edu cc: Cryptography Subject: [saag] Re: Propping up SHA-1 (or MD5) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Date: Mon, 21 Mar 2005 21:29:24 -0000 X-Original-Date: Mon, 21 Mar 2005 16:26:42 -0500 X-List-Received-Date: Mon, 21 Mar 2005 21:29:24 -0000 On Mon, Mar 21, 2005 at 11:56:44AM +0000, Ben Laurie wrote: > > Musing on these points, I wondered about the construction: > > H'(x)=H(H(x) || H(H(x) || x)) > > which doesn't allow an attacker any choice, doesn't change APIs and > doesn't change the length of the hash. Does this have any merit? Note > that this is essentially an HMAC where the key is H(x). I omitted the > padding because it seems to me that this actually makes HMAC weaker > against the current attacks. I believe the fatal flaw here is not the crypto, but losing the ability to hash a stream without keeping all of it. Both the hashes and HMAC have this sometimes-vital property. -- Barney Wolff http://www.databus.com/bwresume.pdf I never met a computer I didn't like. From michaelslists@gmail.com Mon Mar 21 20:34:33 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2M1YV5j007259 for ; Mon, 21 Mar 2005 20:34:31 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) j2M1YNw6024104 for ; Mon, 21 Mar 2005 20:34:23 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 50so1264722wri for ; Mon, 21 Mar 2005 17:34:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=NnwDDiaSI/x9t2kWt9y0xiMqfOQKOATF9tR1KUb/N7wdpjcsKh9qrF7g2QN0qlhnLFJUQ4zx5cYgdDyFl6KaG1ifYRTtZuHoV1WCDx1Iwc9e/5JV/Z4b9WGhxQ0/r3Djof+7tPOurJ4zqgngdgILMa/lC6R9JyWWBZMm3YGfbvI= Received: by 10.54.30.77 with SMTP id d77mr918893wrd; Mon, 21 Mar 2005 17:34:23 -0800 (PST) Received: by 10.54.35.54 with HTTP; Mon, 21 Mar 2005 17:34:23 -0800 (PST) Message-ID: <5e01c29a05032117346894521c@mail.gmail.com> From: Michael Silk To: Ben Laurie In-Reply-To: <423EB67C.1000004@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <423EB67C.1000004@algroup.co.uk> X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.973649 X-Mailman-Approved-At: Fri, 06 May 2005 13:23:40 -0400 cc: saag@mit.edu cc: Cryptography Subject: [saag] Re: Propping up SHA-1 (or MD5) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: michaelslists@gmail.com List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Date: Tue, 22 Mar 2005 01:34:34 -0000 X-Original-Date: Tue, 22 Mar 2005 12:34:23 +1100 X-List-Received-Date: Tue, 22 Mar 2005 01:34:34 -0000 If it's just HMAC with K = h(m) then it's currently (or just recently) been discussed on cfrg: http://www.irtf.org/cfrg/, starting here: http://www1.ietf.org/mail-archive/web/cfrg/current/msg00708.html. -- Michael On Mon, 21 Mar 2005 11:56:44 +0000, Ben Laurie wrote: > It was suggested at the SAAG meeting at the Minneapolis IETF that a way > to deal with weakness in hash functions was to create a new hash > function from the old like so: > > H'(x)=Random || H(Random || x) > > However, this allows an attacker to play with Random (the advice I've > seen is that if one is going to use an IV with a hash function, then one > should transfer the IV with integrity checks to deny attackers this > freedom). > > Another objection is that this construction changes the API at the > sender end, which could lead to a great deal of complexity when the use > of the hash API is deeply embedded. > > A third is that the length of the hash is changed, which could break > existing protocols. > > Musing on these points, I wondered about the construction: > > H'(x)=H(H(x) || H(H(x) || x)) > > which doesn't allow an attacker any choice, doesn't change APIs and > doesn't change the length of the hash. Does this have any merit? Note > that this is essentially an HMAC where the key is H(x). I omitted the > padding because it seems to me that this actually makes HMAC weaker > against the current attacks. > > Cheers, > > Ben. > > -- > http://www.apache-ssl.org/ben.html http://www.thebunker.net/ > > "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 > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com > From dan@doxpara.com Tue Mar 22 05:05:31 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2MA5H5j010283 for ; Tue, 22 Mar 2005 05:05:30 -0500 (EST) Received: from weekly.org (local.doxpara.com [64.81.64.164]) j2LJiOCS019983 for ; Mon, 21 Mar 2005 14:44:25 -0500 (EST) Received: from [127.0.0.1] (fire [127.0.0.1]) by weekly.org (Postfix) with ESMTP id 2690183CDB; Mon, 21 Mar 2005 11:44:09 -0800 (PST) Message-ID: <423F2406.5080604@doxpara.com> From: Dan Kaminsky User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Laurie References: <423EB67C.1000004@algroup.co.uk> In-Reply-To: <423EB67C.1000004@algroup.co.uk> X-Enigmail-Version: 0.90.1.1 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.851436 X-Mailman-Approved-At: Fri, 06 May 2005 13:23:40 -0400 cc: saag@mit.edu cc: Cryptography Subject: [saag] Re: Propping up SHA-1 (or MD5) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Date: Tue, 22 Mar 2005 10:05:32 -0000 X-Original-Date: Mon, 21 Mar 2005 11:44:06 -0800 X-List-Received-Date: Tue, 22 Mar 2005 10:05:32 -0000 Ben, x can equal either test vector released by Wang, and H(x) will be identical. With H(x) identical, the rest of the HMAC stays identical too. As a couple people pointed out, it's OK that HMAC is "vulnerable" to the Wang attack, since in order to execute the attack the key is required (and like AES, if the key is compromised, all bets are off). But you're not using HMAC as a MAC; you're using it to prop up a broken hash. Regarding the "Random" appendage, people don't seem to realize how important syncronized initial states are to many hashing algorithms. One of the major uses of a hashing algorithm is to act as an *exchangable* handle to data, in other words, you and I can both hash our respective datasets and see if they're identical. If we're each using different initial states, that process fails utterly. --Dan P.S. Your construction *will* work if you replace H(x) with H(x xor ipad) and H(x xor opad), with ipad and opad as defined in the HMAC spec. (We can collide against either permutation of our block data, but not both simultaneously.) This does end up rather significantly reducing throughput though. Ben Laurie wrote: > It was suggested at the SAAG meeting at the Minneapolis IETF that a > way to deal with weakness in hash functions was to create a new hash > function from the old like so: > > H'(x)=Random || H(Random || x) > > However, this allows an attacker to play with Random (the advice I've > seen is that if one is going to use an IV with a hash function, then > one should transfer the IV with integrity checks to deny attackers > this freedom). > > Another objection is that this construction changes the API at the > sender end, which could lead to a great deal of complexity when the > use of the hash API is deeply embedded. > > A third is that the length of the hash is changed, which could break > existing protocols. > > Musing on these points, I wondered about the construction: > > H'(x)=H(H(x) || H(H(x) || x)) > > which doesn't allow an attacker any choice, doesn't change APIs and > doesn't change the length of the hash. Does this have any merit? Note > that this is essentially an HMAC where the key is H(x). I omitted the > padding because it seems to me that this actually makes HMAC weaker > against the current attacks. > > Cheers, > > Ben. > From charliek@microsoft.com Wed Mar 23 20:12:01 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2O1Bx5j028707 for ; Wed, 23 Mar 2005 20:11:59 -0500 (EST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) j2O1Bn5U007044 for ; Wed, 23 Mar 2005 20:11:50 -0500 (EST) Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 17:11:38 -0800 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 17:11:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Propping up SHA-1 (or MD5) Thread-Index: AcUuR9SlUXUOKCR7TDGpbY+V/IXGgABwWa4w From: "Charlie Kaufman" To: "Ben Laurie" , "Cryptography" , X-OriginalArrivalTime: 24 Mar 2005 01:11:49.0213 (UTC) FILETIME=[747FB8D0:01C5300E] X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.527366 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id j2O1Bx5j028707 X-Mailman-Approved-At: Fri, 06 May 2005 13:23:40 -0400 Subject: [saag] RE: Propping up SHA-1 (or MD5) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Date: Thu, 24 Mar 2005 01:12:02 -0000 X-Original-Date: Wed, 23 Mar 2005 17:11:47 -0800 X-List-Received-Date: Thu, 24 Mar 2005 01:12:02 -0000 All hash functions I'm aware of consist of an inner compression function that hashes a fixed size block of data into a smaller fixed size block and an outer composition function that applies the inner function iteratively to the variable length data to be hashed. Essentially you're proposing a modification to the outer layer of the hash construction. All of the standard hash functions since MD4 have been constructed so that a collision in the inner compression function is likely to lead to a collision in the hash function. MD2 did not have that property. It computed a cheap checksum of the variable length data in parallel with the digesting process and digested the checksum following the data. I have often wondered whether such a cheap addition would strengthen the newer hashes. (It would fix the suffixing attacks that motivated the development of HMAC). It's not obvious whether this would make the functions more secure or just make them harder to analyze. Perhaps someone from the research community could comment on why the checksum was removed in the evolution from MD2 to MD4. Your proposed encoding has the disadvantage that it would require two passes over the message being digested. This would be bad news for hardware implementations and should be avoided if possible. You note with the construction: H'(x)=Random || H(Random || x) (reminiscent of the salted hash calculation for UNIX passwords) that the hash gets longer. The hash need not get longer. If you have 40 random bits and the first 120 bits of H(Random || x), you match the size of SHA-1 and get improved security against most practical attacks. If your system depends on a fixed length hash, you're in trouble already because the fixed length is probably 128 bits and the world is headed toward 256. A problem that does exist with this construction is that some uses of hash functions assume that if you hash the same data you get the same hash (or indirectly, that if you sign the same data you get the same signature). In particular, you now need separate functions for generating a hash and for checking one. --Charlie Kaufman -----Original Message----- From: owner-cryptography@metzdowd.com [mailto:owner-cryptography@metzdowd.com] On Behalf Of Ben Laurie Sent: Monday, March 21, 2005 3:57 AM To: Cryptography; saag@mit.edu Subject: Propping up SHA-1 (or MD5) It was suggested at the SAAG meeting at the Minneapolis IETF that a way to deal with weakness in hash functions was to create a new hash function from the old like so: H'(x)=Random || H(Random || x) However, this allows an attacker to play with Random (the advice I've seen is that if one is going to use an IV with a hash function, then one should transfer the IV with integrity checks to deny attackers this freedom). Another objection is that this construction changes the API at the sender end, which could lead to a great deal of complexity when the use of the hash API is deeply embedded. A third is that the length of the hash is changed, which could break existing protocols. Musing on these points, I wondered about the construction: H'(x)=H(H(x) || H(H(x) || x)) which doesn't allow an attacker any choice, doesn't change APIs and doesn't change the length of the hash. Does this have any merit? Note that this is essentially an HMAC where the key is H(x). I omitted the padding because it seems to me that this actually makes HMAC weaker against the current attacks. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com From charliek@microsoft.com Thu Mar 24 13:59:18 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j2OIxF5j005985 for ; Thu, 24 Mar 2005 13:59:15 -0500 (EST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) j2OIx78o014121 for ; Thu, 24 Mar 2005 13:59:08 -0500 (EST) Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Thu, 24 Mar 2005 10:59:07 -0800 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Mar 2005 10:59:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Propping up SHA-1 (or MD5) Thread-Index: AcUwXXxkCGbSfRZvQO+J4ZLxdhWgBAAQ2CCw From: "Charlie Kaufman" To: "Ben Laurie" X-OriginalArrivalTime: 24 Mar 2005 18:59:07.0347 (UTC) FILETIME=[8E338230:01C530A3] X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.387706 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id j2OIxF5j005985 X-Mailman-Approved-At: Fri, 06 May 2005 13:23:40 -0400 cc: saag@mit.edu cc: Cryptography Subject: [saag] RE: Propping up SHA-1 (or MD5) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Date: Thu, 24 Mar 2005 18:59:19 -0000 X-Original-Date: Thu, 24 Mar 2005 10:59:03 -0800 X-List-Received-Date: Thu, 24 Mar 2005 18:59:19 -0000 Whether these various tricks help depends on the technical details of the attacks found. I hope that the bit twiddling crypto types who are finding the attacks are going to propose something to fix them. There are probably cheaper fixes than the 2x or 3x performance loss of your algorithm down in the inner loops of these algorithms (such as the change from SHA to SHA-1) and that these will come out. I'm reluctant to jump on the SHA-256 bandwagon or to come up with some ad hoc fix until a more thorough analysis is done. SHA-256 was designed before these attacks were known and probably has related flaws (though they are even less likely to be practically exploitable). We have the luxury of having the current break being largely theoretical, so waiting even a year for the mathematicians is probably OK. But it's never too early to start preparing for a new algorithm - perhaps with a new hash size - in our protocols. Further, given that lots of attacks (past and present) are not exploitable if every hashed quantity includes some value chosen by a trusted party and unpredictable by an attacker, it seems reasonable to consider that as a desirable characteristic as we design our protocols. --Charlie Kaufman p.s. Your formulae below have unbalanced parentheses, but I can guess what you probably meant. -----Original Message----- From: Ben Laurie [mailto:ben@algroup.co.uk] Sent: Thursday, March 24, 2005 2:39 AM To: Charlie Kaufman Cc: Cryptography; saag@mit.edu Subject: Re: Propping up SHA-1 (or MD5) Charlie Kaufman wrote: > All hash functions I'm aware of consist of an inner compression function > that hashes a fixed size block of data into a smaller fixed size block > and an outer composition function that applies the inner function > iteratively to the variable length data to be hashed. Essentially you're > proposing a modification to the outer layer of the hash construction. > > All of the standard hash functions since MD4 have been constructed so > that a collision in the inner compression function is likely to lead to > a collision in the hash function. MD2 did not have that property. It > computed a cheap checksum of the variable length data in parallel with > the digesting process and digested the checksum following the data. I > have often wondered whether such a cheap addition would strengthen the > newer hashes. (It would fix the suffixing attacks that motivated the > development of HMAC). > > It's not obvious whether this would make the functions more secure or > just make them harder to analyze. Perhaps someone from the research > community could comment on why the checksum was removed in the evolution > from MD2 to MD4. > > Your proposed encoding has the disadvantage that it would require two > passes over the message being digested. This would be bad news for > hardware implementations and should be avoided if possible. I suggested in a later version these two constructions: H'(x)=H(H(x || H(0 || x) || H(0 || x)) or: H'(x)=H(H(x || H(0 || x) || H(1 || x)) which only require a single pass (but, unfortunately, two or three different instances of the hash). This seems similar to the mechanism used in MD2, except the checksum is expensive. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 jis@MIT.EDU Fri May 6 13:28:36 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j46HSY5j022901 for ; Fri, 6 May 2005 13:28:34 -0400 (EDT) Received: from osiris.mit.edu (OSIRIS.MIT.EDU [18.7.21.141]) j46HSQrj010396; Fri, 6 May 2005 13:28:26 -0400 (EDT) Received: from localhost (osiris.mit.edu [127.0.0.1]) by osiris.mit.edu (8.12.8p2/8.12.8) with ESMTP id j46HSQCr003250; Fri, 6 May 2005 13:28:26 -0400 From: "Jeffrey I. Schiller" To: Security Group Content-Type: text/plain Message-Id: <1115400506.13956.9.camel@jis.tzo.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-9) Date: Fri, 06 May 2005 13:28:26 -0400 Content-Transfer-Encoding: 7bit Received-SPF: pass (osiris.mit.edu: domain of jis@mit.edu designates 127.0.0.1 as permitted sender); receiver=osiris.mit.edu; client_ip=127.0.0.1; envelope-from=jis@mit.edu; X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.394431 Subject: [saag] Some old messages from March and other list administrivia X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 06 May 2005 17:28:37 -0000 Beware, some old messages from March will be hitting the list. They got stuck in a spam filter. Unfortunately the Saag list gets TONS for spam, hundreds a day on good days! The list is set to automatically accept messages from members. If you send from an e-mail address that isn't subscribed, your message will be held. I'm pretty good at approving them (and adding the address you used to a the "accept" list so I don't have to approve messages from that address again) but I do mess up sometimes (and detect it when I do a more serious pass over the spam before I toss it for good). Today the list is run from jis.mit.edu, I will shortly be moving it to MIT's production mailman server (mailman.mit.edu). The address for the list will remain saag@mit.edu (and saag-request@mit.edu), but the URL for managing subscriptions and whatnot will move to mailman.mit.edu. I'll likely be able to leave a forwarding link in the old location, but I'll also send a note to the list. -Jeff -- ============================================================================= Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu ============================================================================ From bill@strahm.net Fri May 6 15:14:58 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j46JEv5j023877 for ; Fri, 6 May 2005 15:14:57 -0400 (EDT) Received: from smtpout03-03.mesa1.secureserver.net (smtpout03-03.mesa1.secureserver.net [64.202.165.73])j46JEnrj025436 for ; Fri, 6 May 2005 15:14:49 -0400 (EDT) Received: (qmail 18517 invoked from network); 6 May 2005 19:14:49 -0000 Received: from unknown (HELO webmail10.mesa1.secureserver.net) (64.202.189.47) by smtpout03-03.mesa1.secureserver.net with SMTP; 6 May 2005 19:14:49 -0000 Received: (qmail 9599 invoked by uid 99); 6 May 2005 19:14:49 -0000 Message-ID: <20050506191449.9598.qmail@webmail10.mesa1.secureserver.net> Date: Fri, 6 May 2005 12:14:49 -0700 From: bill@strahm.net Subject: RE: Abstract APIs are good (Re: [saag] Problems with SIP security) To: "Blumenthal,Uri" MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII X-Spam-Score: -4.74 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.962208 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 06 May 2005 19:14:59 -0000 I think we just need to be really careful about things being described as "Verbs" documents. Where I have seen them proposed (the IBTA, and a couple times in the IETF) it has come about because the organizations have policies that they do not (or WILL NOT in the case of the IBTA charter) define APIs. Well, when you can't define an API - you create something called Verbs... which is an API - but without a binding that an implementation can depend on without at least a shim layer. An example is one vendor turned each IBTA verb into an API call (there is a send verb - there is a send API call) another decided to turn it into an arguement to their doVerb API (ret = doVerb(send, data)). Yes, you can shim software on top of this stuff - but yeach. If you need an API - define an API that will exist across platforms (see BSD sockets) - if you don't, let the implementers create solutions that are optimized for their needs since they will do that anyway. > -------- Original Message -------- > Subject: RE: Abstract APIs are good (Re: [saag] Problems with SIP > security) > From: "Blumenthal, Uri" > Date: Fri, May 06, 2005 8:43 am > To: "Nicolas Williams" , > Cc: > > Nico, I'm 100% with you on this. In fact, even though it's somewhat too > late and IPsec mostly has missed the train - perhaps we can specify the > abstract APIs (and then maybe even the actual API that would be > implemented by OpenSWAN)... > > Bill, I'm disappointed to hear this from you. > > > -----Original Message----- > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of > Nicolas Williams > Sent: Friday, May 06, 2005 11:15 AM > To: bill@strahm.net > Cc: saag@mit.edu > Subject: Re: Abstract APIs are good (Re: [saag] Problems with SIP > security) > > On Fri, May 06, 2005 at 08:05:25AM -0700, bill@strahm.net wrote: > > Abstract APIs are evil. > > > > Well - they tend to go under the noun of "Verbs" today - I know the > > Infiniband folk love their "Verbs" document. > > > > What is a verb you might ask - it is a piece of functionality that is > > exposed, not an API. So you have all the manufacturers out there > > building their own "Verbs" layers, each with their own quirks - that > > are totally uninteroperable with each other. > > Doesn't sound like a good abstract API underlies those implementations' > concrete APIs. More like a symantic difference in how to call the "Verbs". yes they can be mapped, but if I have to map - why bother. A new vendor comes out with a new implementation - I still have to rewrite code. How would you like it if the send() function was named something different on each platform... ick. > > > Here you have the worst of both worlds, a standardized set of > > functionality that can't be changed, enhanced, or optimized - AND > > something that can't be ported (or for that matter applications > written > > to the "Verbs" interface have to be ported to each particular "Verbs > > implementation") > > Are you saying that concrete APIs are better? > > If so, I should point out that abstract APIs are a good first step. I can implement on a concrete API - and yes - we need to find out abstractly what the interface needs to do. But when it comes time for me to implement - I want to call send() and not have to deal with well Microsoft calls it WSAsend() with some extra options, Solaris calls it SunSend(), Linux decided on PenguinSend() with some extra options that are diffent from Microsoft, and BSD stuck with send(). Oh and while we are at it... Microsoft decided on an AIO socket strategy, Linux picked another, and Posix has a third, each relatively incompatable with each other in interestingly enough ways to make porting around hard. How would you like to maintain that mess - and, oh while you are at it Product marketting comes to you and says AIX/HP-UX support is needed. > > If you're saying APIs are bad, then I must admit to being puzzled by > your complaining about non-portability. > APIs are good - abstract definitions are not APIs, at best they are an attempt at standardization when you know you don't have concensus to reach a standard. Abstract APIs are good for internal APIs (remember the internal APIs for SNMP) where they spell out the expected behavior between modules. However as I remember from 5-6 years ago - only a single implementation implemented those APIs, a master students thesis... everyone else in the real world did something better... Expect that to happen if we go down the definition of external "Verbs" interfaces. > Nico > -- > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag From nw141292@binky.Central.Sun.COM Fri May 6 15:40:02 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j46Je05j024116 for ; Fri, 6 May 2005 15:40:00 -0400 (EDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) j46JdpJx022835 for ; Fri, 6 May 2005 15:39:51 -0400 (EDT) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j46JdoQ1017286 for ; Fri, 6 May 2005 12:39:50 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) with ESMTP id j46Jdnew021611 for ; Fri, 6 May 2005 13:39:50 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) j46JdmUh017889; Fri, 6 May 2005 14:39:48 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j46Jdk8u017888; Fri, 6 May 2005 14:39:46 -0500 (CDT) Date: Fri, 6 May 2005 14:39:46 -0500 From: Nicolas Williams To: bill@strahm.net Subject: Re: Abstract APIs are good (Re: [saag] Problems with SIP security) Message-ID: <20050506193946.GG4008@binky.Central.Sun.COM> References: <20050506191449.9598.qmail@webmail10.mesa1.secureserver.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050506191449.9598.qmail@webmail10.mesa1.secureserver.net> User-Agent: Mutt/1.5.7i X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.333426 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 06 May 2005 19:40:04 -0000 On Fri, May 06, 2005 at 12:14:49PM -0700, bill@strahm.net wrote: > I think we just need to be really careful about things being described > as "Verbs" documents. Where I have seen them proposed (the IBTA, and a > couple times in the IETF) it has come about because the organizations > have policies that they do not (or WILL NOT in the case of the IBTA > charter) define APIs. Who said *anything* about verbs?! (Besides you :) If you want to know what I meant by abstract APIs go look at RFC2743 for a good example. And consumers of it: RPCSEC_GSS (RFC2203), GSS-TSIG (RFC3645), FTP (RFC2228), SSHv2 (draft-ietf-secsh-gsskeyex-07.txt), SASL, SOCKS, and so on, that are specified in terms of the *abstract* GSS-API. IMO the GSS-API sets a very good example of what can be achieved with an abstract API. Concrete APIs may not always be easily specified at the IETF, but we can go very far with just abstract APIs. > Well, when you can't define an API - you create something called > Verbs... which is an API - but without a binding that an implementation For IPsec we can define an abstract API. > can depend on without at least a shim layer. An example is one vendor > turned each IBTA verb into an API call (there is a send verb - there is > a send API call) another decided to turn it into an arguement to their > doVerb API (ret = doVerb(send, data)). Yes, you can shim software on > top of this stuff - but yeach. IB is certainly not what I had in mind. Designing an API around IB verbs would be like designing an API around NFSv4 operations -- it would not make much sense as NFSv4 ops are meant to be used in to create composite operations that more closely correspond to the operations that clients' actually need, and the whole point of NFSv4 is to use existing POSIX and Windows filesystem APIs. Similarly, a good abstract API for IPsec would not deal in individual packets, indivual IKE exchanges or anything of the sort, but in what information is needed where, by what piece of the stack and what supplies it, a native (as opposed to BITS) processing model, and so on. > If you need an API - define an API that will exist across platforms (see > BSD sockets) - if you don't, let the implementers create solutions that > are optimized for their needs since they will do that anyway. See the GSS-API. RFCs 2743, 2744 and 2853. See the KITTEN WG's charter and work items. See applications of the GSS-API (see above). Of course, for IPsec the variety of platform- and language-specific TCP/IP APIs means that concrete APIs to IPsec will be difficult to specify -- perhaps a concrete BSD-based sockets API, a TLI/XTI-based API and/or a Winsock/Win32 API. Times N (C, C++, Java, C#, Perl5, Perl6, Tcl, Python, Ruby, ...) languages. So you see that for IPsec we'll have to start with abstract APIs... and maybe stop there. [...] > > > What is a verb you might ask - it is a piece of functionality that is > > > exposed, not an API. So you have all the manufacturers out there > > > building their own "Verbs" layers, each with their own quirks - that > > > are totally uninteroperable with each other. > > > > Doesn't sound like a good abstract API underlies those implementations' > > concrete APIs. > > More like a symantic difference in how to call the "Verbs". yes they > can be mapped, but if I have to map - why bother. A new vendor comes > out with a new implementation - I still have to rewrite code. How > would you like it if the send() function was named something different > on each platform... ick. You're stuck on IB, I'm afraid :/ [...] > Abstract APIs are good for internal APIs (remember the internal APIs for > SNMP) where they spell out the expected behavior between modules. > However as I remember from 5-6 years ago - only a single implementation > implemented those APIs, a master students thesis... everyone else in the > real world did something better... Expect that to happen if we go down > the definition of external "Verbs" interfaces. Yes, stuck on IB :) Cheers, Nico -- From aboba@internaut.com Thu May 19 11:24:21 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j4JFOK5j004633 for ; Thu, 19 May 2005 11:24:20 -0400 (EDT) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) j4JFOCqh002709 for ; Thu, 19 May 2005 11:24:12 -0400 (EDT) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DYmse-000Ir5-8B for saag@mit.edu; Thu, 19 May 2005 11:24:12 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4JFO7H03569 for ; Thu, 19 May 2005 08:24:11 -0700 Date: Thu, 19 May 2005 08:24:07 -0700 (PDT) From: Bernard Aboba To: saag@mit.edu In-Reply-To: Message-ID: References: <8A76136424391244A5CF0165337085371D6CAB@mvebe101.NOE.Nokia.com> <3955.1115229916@marajade.sandelman.ottawa.on.ca> <4766.1115239165@marajade.sandelman.ottawa.on.ca> <07862E91-CCD2-4D85-A99B-ED076D882C99@extremenetworks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000059 Spam-Alum-Time: 0.536794 Subject: [saag] IEEE 802.16e Security Review group X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 19 May 2005 15:24:22 -0000 The IETF has recently received a liaison letter from IEEE 802.16, requesting IETF review of the 802.16e specification which is currently in sponsor ballot. The letter is available here: http://www.ietf.org/IESG/LIAISON/file116.pdf In order to go over the comments, we are going to be having weekly conference calls with the 802.16 liaison to IETF, Jeff Mandin. Participants in SAAG who wish to participate in this review or attend the conference calls (first one is this Friday at 8 AM Pacific), send email to me. From housley@vigilsec.com Fri May 27 14:32:09 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j4RIW85j003817 for ; Fri, 27 May 2005 14:32:08 -0400 (EDT) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) j4RIW1sM013009 for ; Fri, 27 May 2005 14:32:02 -0400 (EDT) Received: (qmail 8309 invoked by uid 0); 27 May 2005 18:31:56 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.171.60) by woodstock.binhost.com with SMTP; 27 May 2005 18:31:56 -0000 Message-Id: <6.2.1.2.2.20050527142856.05aae1c0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 27 May 2005 14:31:58 -0400 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.6 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000272 Spam-Alum-Time: 0.526717 cc: fenner@research.att.com cc: zinin@psg.com Subject: [saag] RPSEC X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 27 May 2005 18:32:10 -0000 The RPSEC (Routing Protocol Security) WG hopes to be ready for Last Call of the BGP Security Requirements document shortly after the meeting in Paris. To date, there have been very few people from the Security Area involved in this effort. I am writing to strongly encourage your review and participation. Thanks in advance for any cycles that you can provide, Russ From Mailer-Daemon@adelaidebank.com.au Sat May 28 12:01:14 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j4SG1D5j010907 for ; Sat, 28 May 2005 12:01:14 -0400 (EDT) Received: from mail.adelaidebank.com.au (wwwproxy.adelaidebank.com.au [203.33.102.2])j4SG1288024960 for ; Sat, 28 May 2005 12:01:03 -0400 (EDT) X-SEF-NDR-A4CDD3E6-186A-4406-A61E-2779D86E16D1: 1 X-SEF-A4CDD3E6-186A-4406-A61E-2779D86E16D1: 1 Received: from Unknown [172.17.5.100] by mail.adelaidebank.com.au - SurfControl E-mail Filter (5.0); Sun, 29 May 2005 01:31:01 +1030 Received: from ABDOMAIN-MTA by adelaidebank.com.au with Novell_GroupWise; Sun, 29 May 2005 01:31:01 +0930 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Date: Sun, 29 May 2005 01:30:39 +0930 From: "Paul DEWSNAP" Sender: Postmaster@adelaidebank.com.au Errors-To: Postmaster@adelaidebank.com.au To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -0.999 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.595611 Subject: [saag] Re: saag Digest, Vol 28, Issue 10 (Out of Office) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: pdewsnap@adelaidebank.com.au List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 28 May 2005 16:01:15 -0000 I am out of the office until Monday 30 May 05. Your email has not been forwarded. If this matter is urgent please contact Sanya Dolibasic on ext. 6248. Regards, Paul >>> saag 05/29/05 01:30 >>> Send saag mailing list submissions to saag@mit.edu To subscribe or unsubscribe via the World Wide Web, visit https://jis.mit.edu/mailman/listinfo/saag or, via email, send a message with subject or body 'help' to saag-request@mit.edu You can reach the person managing the list at saag-owner@mit.edu When replying, please edit your Subject line so it is more specific than "Re: Contents of saag digest..." ____________________________________________________________________ This e-mail and any files transmitted with it are confidential and are only for the use of the person to whom they are addressed. If you are not the intended recipient, you are hereby notified that any use, dissemination, forwarding, printing, copying or dealing in any way whatsoever with this e-mail is strictly prohibited. If you have received this e-mail in error, please reply to us immediately and delete the document. It is the recipient's duty to virus scan and otherwise test the enclosed information before using the information or loading attached files onto any computer system. Adelaide Bank Ltd does not warrant that the information contained in this e-mail is free from viruses, defects, errors, interception or interference. Any views expressed in this message are those of the individual sender, except where that sender specifically states them to be the views of Adelaide Bank Ltd. ____________________________________________________________________ From hartmans@MIT.EDU Wed Jun 1 15:04:25 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j51J4O5j008120 for ; Wed, 1 Jun 2005 15:04:24 -0400 (EDT) Received: from carter-zimmerman.mit.edu (STRATTON-THREE-SIXTY-NINE.MIT.EDU [18.187.6.114])j51J4CSi018866 for ; Wed, 1 Jun 2005 15:04:12 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 91C4EE0063; Wed, 1 Jun 2005 15:04:07 -0400 (EDT) To: ietf-ssh@netbsd.org, saag@mit.edu From: Sam Hartman mail-followups-to: ietf@ietf.org Date: Wed, 01 Jun 2005 15:04:07 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 1.041 X-Spam-Level: * (1.041) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.634532 Subject: [saag] [Sam Hartman] draft-harris-ssh-arcfour-fixes-02: informational or proposed? X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: ietf@ietf.org List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 01 Jun 2005 19:04:25 -0000 --=-=-= Hi. I believe the following request is of interest to secsh and saag. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.16-IPv6-Debian-2.1.16-10) with LMTP; Wed, 01 Jun 2005 14:37:25 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 581AA1383D for ; Wed, 1 Jun 2005 14:37:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdY3t-00074x-D9; Wed, 01 Jun 2005 14:35:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdY3r-00073R-2v; Wed, 01 Jun 2005 14:35:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13323; Wed, 1 Jun 2005 14:35:23 -0400 (EDT) Received: from stratton-three-sixty-nine.mit.edu ([18.187.6.114] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdYNe-0002lY-42; Wed, 01 Jun 2005 14:55:59 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 36E3DE0063; Wed, 1 Jun 2005 14:35:07 -0400 (EDT) To: ietf@ietf.org From: Sam Hartman Date: Wed, 01 Jun 2005 14:35:07 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: iesg@ietf.org Subject: draft-harris-ssh-arcfour-fixes-02: informational or proposed? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on solipsist-nation.suchdamage.org X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 MIME-Version: 1.0 Hi, folks. The IESG has received a last call comment recommending that the new rc4 cipher for ssh be published as informational rather than as a proposed standard because of weaknesses in rc4. It would be inappropriate to make a decision based on one comment so I am soliciting comments on this point. The argument in favor of publishing this document at proposed is that the existing arcfour cipher is part of a standard and that many other IETF protocols use rc4 in standards track documents. Please submit comments to ietf@ietf.org or iesg@ietf.org on this issue by 2005-06-28. Included below is a partial bibliography of RC4 attacks provided to the IESG by the person making the original comment. S. Fluhrer, I. Mantin, & A. Shamir, "Weaknesses in the Key Scheduling Algorithm of RC4", Proceedings of 8th Annual International Workshop on Selected areas in Cryptography (SAC 2001), Toronto, ON, CA, August 2001. J. D. Golic, "Linear Statistical Weakness of RC4 Key Generator", Procedings of EuroCrypt 1997, Konstanz, DE, May 1997. S. Fluhrer & D. McGrew, "Statistical Analysis of the RC4 Key Generator", Proceedings of 7th International Workshop on Fast Software Encryption (FSE 2000), New York, NY, US, April 2000. S. Mister & S.E. Tavares, "Cryptanalysis of RC4-like Ciphers", Proceedings of 5th Annual International Workshop on Selected Areas in Cryptography (SAC 1998), Kingston, ON, CA, August 1998. L. Knudsen, W. Meier, B. Preneel, V. Rijmen, & S. Verdoolaege, "Analysis Method for RC4", Proceedings of AsiaCrypt 1998. R. Wash, "Lecture Notes on Stream Ciphers and RC4", unpublished, Case Western Reserve University, OH, US http://acm.cwru.edu/files/2002%20Spring/talks/latex_samp2_4_09_02.pdf S. Paul & B. Preneel, "Analysis of Non-fortuitous Predictive States of the RC4 Key Generator", Proceedings of 4th International Conference on Cryptology in India (IndoCrypt 2003), New Delhi, IN, December 2003. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --=-=-=-- From jaltman@columbia.edu Wed Jun 1 15:38:39 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j51Jcc5j008325 for ; Wed, 1 Jun 2005 15:38:38 -0400 (EDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) j51JcRSi029034 for ; Wed, 1 Jun 2005 15:38:28 -0400 (EDT) Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0)j51JcLN9005492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Jun 2005 15:38:22 -0400 (EDT) Message-ID: <429E0F70.6040708@columbia.edu> Date: Wed, 01 Jun 2005 15:41:36 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: [saag] [Sam Hartman] draft-harris-ssh-arcfour-fixes-02: informational or proposed? References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060001060407000208000200" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: -2.601 X-Spam-Flag: NO Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.729605 cc: saag@mit.edu cc: ietf-ssh@netbsd.org X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 01 Jun 2005 19:38:39 -0000 This is a cryptographically signed message in MIME format. --------------ms060001060407000208000200 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit My personal opinion is that if there is a protocol that has been widely deployed but which for whatever reason the IETF does not want to encourage its adoption, the RFC should be published immediately as HISTORIC. Jeffrey Altman Sam Hartman wrote: > > Hi. I believe the following request is of interest to secsh and saag. > > > > ------------------------------------------------------------------------ > > Subject: > draft-harris-ssh-arcfour-fixes-02: informational or proposed? > From: > Sam Hartman > Date: > Wed, 01 Jun 2005 14:35:07 -0400 > To: > ietf@ietf.org > > To: > ietf@ietf.org > CC: > iesg@ietf.org > > Return-Path: > > Received: > from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus > v2.1.16-IPv6-Debian-2.1.16-10) with LMTP; Wed, 01 Jun 2005 14:37:25 -0400 > X-Sieve: > CMU Sieve 2.2 > Return-Path: > > Received: > from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by > suchdamage.org (Postfix) with ESMTP id 581AA1383D for > ; Wed, 1 Jun 2005 14:37:23 -0400 (EDT) > Received: > from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by > megatron.ietf.org with esmtp (Exim 4.32) id 1DdY3t-00074x-D9; Wed, 01 > Jun 2005 14:35:29 -0400 > Received: > from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org > with esmtp (Exim 4.32) id 1DdY3r-00073R-2v; Wed, 01 Jun 2005 14:35:27 -0400 > Received: > from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org > (8.9.1a/8.9.1a) with ESMTP id OAA13323; Wed, 1 Jun 2005 14:35:23 -0400 (EDT) > Received: > from stratton-three-sixty-nine.mit.edu ([18.187.6.114] > helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim > 4.33) id 1DdYNe-0002lY-42; Wed, 01 Jun 2005 14:55:59 -0400 > Received: > by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 36E3DE0063; > Wed, 1 Jun 2005 14:35:07 -0400 (EDT) > Message-ID: > > User-Agent: > Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) > X-Scan-Signature: > c1c65599517f9ac32519d043c37c5336 > X-BeenThere: > ietf@ietf.org > X-Mailman-Version: > 2.1.5 > Precedence: > list > List-Id: > IETF-Discussion > List-Unsubscribe: > , > > List-Post: > > List-Help: > > List-Subscribe: > , > > Sender: > ietf-bounces@ietf.org > Errors-To: > ietf-bounces@ietf.org > X-Spam-Checker-Version: > SpamAssassin 3.0.2 (2004-11-16) on solipsist-nation.suchdamage.org > X-Spam-Status: > No, score=-1.7 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 > MIME-Version: > 1.0 > > > > Hi, folks. The IESG has received a last call comment recommending > that the new rc4 cipher for ssh be published as informational rather > than as a proposed standard because of weaknesses in rc4. It would be > inappropriate to make a decision based on one comment so I am > soliciting comments on this point. > > The argument in favor of publishing this document at proposed is that > the existing arcfour cipher is part of a standard and that many other > IETF protocols use rc4 in standards track documents. > > > Please submit comments to ietf@ietf.org or iesg@ietf.org on this issue > by 2005-06-28. > > Included below is a partial bibliography of RC4 attacks provided to > the IESG by the person making the original comment. > > > > S. Fluhrer, I. Mantin, & A. Shamir, "Weaknesses in the Key Scheduling > Algorithm of RC4", Proceedings of 8th Annual International Workshop > on Selected areas in Cryptography (SAC 2001), Toronto, ON, CA, > August 2001. > > J. D. Golic, "Linear Statistical Weakness of RC4 Key Generator", > Procedings of EuroCrypt 1997, Konstanz, DE, May 1997. > > S. Fluhrer & D. McGrew, "Statistical Analysis of the RC4 Key > Generator", Proceedings of 7th International Workshop on Fast > Software Encryption (FSE 2000), New York, NY, US, April 2000. > > S. Mister & S.E. Tavares, "Cryptanalysis of RC4-like Ciphers", > Proceedings of 5th Annual International Workshop on Selected > Areas in Cryptography (SAC 1998), Kingston, ON, CA, August 1998. > > L. Knudsen, W. Meier, B. Preneel, V. Rijmen, & S. Verdoolaege, > "Analysis Method for RC4", Proceedings of AsiaCrypt 1998. > > R. Wash, "Lecture Notes on Stream Ciphers and RC4", unpublished, > Case Western Reserve University, OH, US > http://acm.cwru.edu/files/2002%20Spring/talks/latex_samp2_4_09_02.pdf > > S. Paul & B. Preneel, "Analysis of Non-fortuitous Predictive States > of the RC4 Key Generator", Proceedings of 4th International Conference > on Cryptology in India (IndoCrypt 2003), New Delhi, IN, December 2003. > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag --------------ms060001060407000208000200 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwNjAxMTk0MTM2WjAjBgkqhkiG9w0BCQQxFgQUA4rxfb6dA8vHnb8BbzBzgXoVYJIw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAnl3KL7kJHNRO8frpZ6XKUZO6kM2zIEqjWS6I298v XC+XP79QOJitPZNjDKKfsFMxQyyysbI1Ws+psN0XoD9QgM0VfY4t4IUQby0beC2xaaYGEFm/ KCEiEEh6eTc9SienZZwd4kT1MFVM1gpaIU3S15uUHwr4k1DBdaMyVyzxPtXUC+DWqlXI2V8m bh6fwqGHH2lXcQcsTuEBfW4QA2W4kkQYHkyneNsbm7yANXSPXLqoE+QKGB0vr45K1q2CnhbX R0uL0PRpjTVYEUKmNAOl4mKHCQLarrXk2GV6tT3eHRuajNu8Ge8GLBynrW1V06AP5OgxiUS9 B/d8XPfDBXNyJgAAAAAAAA== --------------ms060001060407000208000200-- From housley@vigilsec.com Fri Jun 3 16:34:53 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j53KYq5j022986 for ; Fri, 3 Jun 2005 16:34:52 -0400 (EDT) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) j53KYf1d018730 for ; Fri, 3 Jun 2005 16:34:42 -0400 (EDT) Received: (qmail 11981 invoked by uid 0); 3 Jun 2005 20:33:48 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.39.133) by woodstock.binhost.com with SMTP; 3 Jun 2005 20:33:48 -0000 Message-Id: <6.2.1.2.2.20050603163253.05876cb0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 03 Jun 2005 16:33:51 -0400 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.635674 Subject: [saag] Hash BoF X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 03 Jun 2005 20:34:53 -0000 This is a brief note to let the members of the SAAG mail list know about the Hash BoF that will take place in Paris at IETF 63. We have a mailing list, and we respectfully ask for people to join that list for any discussion. I have attached the proposed charter for the Hash WG. Thanks, Russ Housley IETF Security Area Director = = = = = = = = = = One-way Hash Function BoF (hash) Security Area Director: Sam Hartman Russ Housley Security Area Advisor: Russ Housley Mailing Lists: General Discussion: hash@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/hash Archive: http://www.ietf.org/mail-archive/web/hash/index.html Description of Proposed Working Group: Recently, a team of researchers reported that the SHA-1 one-way hash function offers significantly less collision resistance than could be expected from a cryptographic hash function with an output of 160 bits. This result has inspired significant research activities in government and academia. Additional information regarding the security of current one-way hash functions, as well as proposals for new one-way hash functions, are expected. The proposed working group responds to the current state of research in this area. However, additional research is likely to provide new insights as the working group progresses. A three-phase approach is envisioned. The second and third phases will be pursued only if it is clear that the international cryptographic community is actively participating in the working group. The first phase of the working group will specify one or more standards- track mechanism replace or strengthen SHA-1. At least two approaches will be considered: 1) Truncate a larger one-way hash function output so that it can be used as a secure replacement of a shorter one-way hash function output. For example, as an alternative to SHA-1, the truncation mechanism could be used create a 160-bit result from the output of the SHA-256 one-way hash function. 2) Including a random value in the hash function computation. The random block used is transferred as a parameter in the algorithm identifier. This approach is sometimes called a "salted" or "randomized" hash function. The first phase may also consider other potential solutions, and one or more standards-track mechanism will be selected. The second phase will consider the suitability of one-way hash functions for use with IETF protocols. These requirements will be published as one or more BCP documents which specify the features and characteristics for standards-track one-way hash functions. The BCP documents will also identify information that must be included in any request for a hash function to be approved on the standards track. The third phase will identify one or more standards-track one-way hash functions that fulfill the requirements stated in the BCP documents developed in phase two. Guidance will also be developed to assist protocol developers in the selection among the standards-track one-way hash functions. Goals and Milestones: September 2005: Charter to authorize phase one. October 2005: Submit initial draft of truncation mechanism. February 2006: WG Last Call on truncation mechanism. April 2006: Submit truncation mechanism as Proposed Standard. June 2006: Recharter to authorize phase two. From aboba@internaut.com Mon Jun 6 13:06:36 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j56H6Z5j008593 for ; Mon, 6 Jun 2005 13:06:35 -0400 (EDT) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) j56H6WgE029678 for ; Mon, 6 Jun 2005 13:06:32 -0400 (EDT) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DfL3Y-000DaJ-0V for saag@mit.edu; Mon, 06 Jun 2005 13:06:32 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j56H6Uj26036 for ; Mon, 6 Jun 2005 10:06:30 -0700 X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Mon, 6 Jun 2005 10:06:30 -0700 (PDT) From: Bernard Aboba To: saag@mit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.6 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.537814 Subject: [saag] Response to 802.16 Liaison request to IETF X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 06 Jun 2005 17:06:36 -0000 In the following liaison letters, Roger Marks, Chair of IEEE 802.16, requested IETF review of IEEE 802.16e: http://ieee802.org/16/liaison/docs/L80216-05_025.pdf http://ieee802.org/16/liaison/docs/L80216-05_039.pdf The EAP WG, working with a team from Prof. Mitchell's group at Stanford University has completed a draft of its review, available here: http://www.drizzle.com/~aboba/EAP/review.txt Note that in addition to focussing on EAP usage and a general security analysis, the review also uncovered issues relating to use of IPv6 on 802.16. From rja@extremenetworks.com Mon Jun 6 19:32:05 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j56NW45j010776 for ; Mon, 6 Jun 2005 19:32:04 -0400 (EDT) Received: from smtp1.extremenetworks.com (smtp1.extremenetworks.com [216.52.8.6])j56NVsWt006919 for ; Mon, 6 Jun 2005 19:31:55 -0400 (EDT) Received: from [10.30.20.60] (unknown [10.30.20.60]) by smtp1.extremenetworks.com (Postfix) with ESMTP id A7FB17941 for ; Mon, 6 Jun 2005 16:31:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8BCE0D83-2958-4713-A5B6-EF37CD37D480@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [saag] Response to 802.16 Liaison request to IETF Date: Mon, 6 Jun 2005 19:31:51 -0400 To: saag@mit.edu X-Mailer: Apple Mail (2.730) X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.583185 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 06 Jun 2005 23:32:05 -0000 All, An aside, with a different, but somewhat related, tidbit: Several large users outside the US are asking their implementers to ensure that any cryptographically-enabled protocols have passed the NIST FIPS 140-2 approvals. Within the US, this has been true for some time now. The shift is that folks overseas are starting to ask for the FIPS 140-2 approvals much more frequently than in the past. So from an implementer perspective, it is desirable that neither IETF EAP specifications (as they evolve) nor any related IEEE (802.11, 802.16, other) link-layer specifications (as they evolve) preclude an implementer from complying with EAP/IEEE specs and also complying with NIST FIPS 140-2 requirements at the same time with the same implementation. Myself, I'm agnostic about cryptographic algorithms or such like; I'm happy to implement a wide range of choices and let users configure what they will. That said, I do try pretty hard to listen to and accommodate large end users when it is clear that one particular configuration is widely desired. Ran rja@extremenetworks.com Disclaimer: speaking for myself only, not my employer. From aboba@internaut.com Thu Jun 9 02:13:27 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j596DQ5j026452 for ; Thu, 9 Jun 2005 02:13:26 -0400 (EDT) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) j596DH1R015017 for ; Thu, 9 Jun 2005 02:13:17 -0400 (EDT) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DgGI1-000EUP-89 for saag@mit.edu; Thu, 09 Jun 2005 02:13:17 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j596DFH22812 for ; Wed, 8 Jun 2005 23:13:15 -0700 X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Wed, 8 Jun 2005 23:13:15 -0700 (PDT) From: Bernard Aboba To: saag@mit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.6 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000290 Spam-Alum-Time: 0.533808 Subject: [saag] Discussion of IEEE 802.16e Security Issues X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 09 Jun 2005 06:13:27 -0000 In response to the IETF review of IEEE 802.16e security, a forum has been established for discussing the review and how to address the comments: http://dot16.org/forum/index.php?board=6.0 Anyone in SAAG who cares about the topic is invited to participate. The review is available here: http://www.drizzle.com/~aboba/EAP/review.txt http://www.drizzle.com/~aboba/EAP/802.16eNotes.pdf From jwkckid1@ix.netcom.com Sat Jun 11 00:32:11 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j5B4WA5j010143 for ; Sat, 11 Jun 2005 00:32:10 -0400 (EDT) Received: from pop03.mail.atl.earthlink.net (pop03.mail.atl.earthlink.net [207.69.200.48])j5B4W0Eq006801 for ; Sat, 11 Jun 2005 00:32:00 -0400 (EDT) Received: from 1cust23.tnt36.dfw9.da.uu.net ([67.234.81.23] helo=ix.netcom.com) by pop03.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1Dgxf4-0003Xq-00; Sat, 11 Jun 2005 00:31:59 -0400 Message-ID: <42AA8315.8B1B022A@ix.netcom.com> Date: Fri, 10 Jun 2005 23:22:14 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: aba isc list Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.6 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.586567 cc: saag Subject: [saag] Meaningful MD5 Collisions X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 11 Jun 2005 04:32:11 -0000 All, http://www.cits.rub.de/MD5Collisions/ http://en.wikipedia.org/wiki/Cryptographic_hash_function#Merkle-Damg.E5rd_hash_functions http://www.cs.ucl.ac.uk/staff/mrogers/ Researchers at Ruhr-Universität Bochum have found a way to produce MD5 collisions between human-meaningful documents. This could be used to obtain a digital signature on one document and then transfer it to another. The same technique is theoretically applicable to other hash functions based on the Merkle-Damgård structure, such as SHA-1." From the article: "Recently, the world of cryptographic hash functions has turned into a mess. A lot of researchers announced algorithms ("attacks") to find collisions for common hash functions such as MD5 and SHA-1 (see [B+, WFLY, WY, WYY-a, WYY-b]). For cryptographers, these results are exciting - but many so-called 'practitioners' turned them down as 'practically irrelevant. Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From housley@vigilsec.com Mon Jun 13 15:42:26 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j5DJgP5j025539 for ; Mon, 13 Jun 2005 15:42:25 -0400 (EDT) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) j5DJgFax020697 for ; Mon, 13 Jun 2005 15:42:15 -0400 (EDT) Received: (qmail 13339 invoked by uid 0); 13 Jun 2005 19:42:09 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.2.72) by woodstock.binhost.com with SMTP; 13 Jun 2005 19:42:09 -0000 Message-Id: <6.2.1.2.2.20050613154023.05675b90@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 13 Jun 2005 15:42:08 -0400 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.6 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.002279 Spam-Alum-Time: 0.519749 Subject: [saag] AAA Key Management X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 13 Jun 2005 19:42:27 -0000 Please take a look at the AAA Key Management guidance document that I have co-authored with Bernard Aboba. My goal is to publish this document as a BCP. http://www.ietf.org/internet-drafts/draft-housley-aaa-key-mgmt-00.txt Thanks, Russ From alper.yegin@samsung.com Wed Jun 15 14:36:25 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j5FIaN5j009333 for ; Wed, 15 Jun 2005 14:36:24 -0400 (EDT) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) j5FIaCkj028939 for ; Wed, 15 Jun 2005 14:36:12 -0400 (EDT) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0II500A6W2CBZL@mailout2.samsung.com> for saag@mit.edu; Thu, 16 Jun 2005 03:36:11 +0900 (KST) Received: from Alperyegin ([105.144.29.41])Jun 23saag@mit.edu; Thu, 16 Jun 2005 03:36:11 +0900 (KST) Date: Wed, 15 Jun 2005 11:34:41 -0700 From: Alper Yegin To: "'Russ Housley'" , "'Bernard Aboba'" Message-id: <003f01c571d8$e8698030$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.614297 cc: saag@mit.edu Subject: [saag] AAA Key Management X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 15 Jun 2005 18:36:25 -0000 Hi Russ and Bernard, Thanks a lot for putting together this I-D. I've just read it and have some comments and questions. [1] This document provides guidance to designers of AAA key management protocols. I think this document's scope is not limited to "protocols." The stated recommendations have impact on the systems and architectures as well. [2] Authenticator The end of the link initiating EAP authentication. Characterizing the "authenticator" as the end of the link is too limiting, especially when we consider EAP/IKEv2. In that case, the authenticator may be across the Internet. [3] Should the document discuss that a typical NAS hosts an EAP peer + a AAA client? [4] Let's add PANA to other EAP lower layers mentioned in the document. [5] What's the difference between the key scope and key context? A party has access to a particular key if it has access to all of the secret information needed to derive it. I didn't understand this. For example, when the NAS is provided with the AAA-Key from the AAA server at the end of the EAP authentication, what are the secrets owned by the NAS to "derive" that key? Btw, I guess RADIUS does not meet this requirement either as the intermediate AAA proxies learn the AAA-Key in transit. [6] Compromise of a single authenticator MUST NOT compromise any other part of the system, especially session keys and long-term keys. I think the document should expand on the term "system." Some specific examples from well-known architectures like WiFi, 3GPP2, DSL, etc. would be useful. [7] "Supplicant", as the 802.1X-specific "peer" is not used in the document. I think it can be removed. Thanks. Alper -----Original Message----- From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of Bernard Aboba Sent: Monday, June 13, 2005 1:03 PM To: eap@frascone.com Subject: [eap] AAA Key Management During various discussions in EAP WG, questions have arisen about the "Housley Criteria". Russ has now issued a draft that clarifies some of the criteria, which were originally published in RFC 4017. The goal is to publish this document as a BCP: http://www.ietf.org/internet-drafts/draft-housley-aaa-key-mgmt-00.txt Comments should be sent to saag@mit.edu _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From jsalowey@cisco.com Thu Jun 23 14:04:21 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j5NI4K5j009595 for ; Thu, 23 Jun 2005 14:04:20 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) j5NI4B2Z005183 for ; Thu, 23 Jun 2005 14:04:11 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 23 Jun 2005 11:04:11 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5NI48VX015656; Thu, 23 Jun 2005 11:04:09 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Thu, 23 Jun 2005 11:08:22 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905668FD9@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SECMECH list announcement Thread-Index: AcV4HfKjfilgW2qqTWu/fGuVNvxdbw== From: "Salowey, Joe" To: , , , X-Spam-Score: -2.601 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.613399 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id j5NI4K5j009595 Subject: [saag] SECMECH list announcement X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 23 Jun 2005 18:04:21 -0000 This is a brief note to announce a the creation of a mailing list for discussing security mechanisms. The current scope is security mechanisms for the GSS-API, EAP and SASL frameworks. There will most likely be a BOF on this topic at IETF 63. Please join the mailing list if you have interest in this topic. General Discussion: secmech@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/secmech Archive: http://www.ietf.org/mail-archive/web/secmech/index.html Description ------------------- There exists a disconnect between the IETF's security frameworks. Although these frameworks have very similar goals, the set of mechanisms available depends upon the choice of framework. There are a number of issues that make a compelling case for converging the way we develop mechanisms for these frameworks. - There is a desire to standardized EAP mechanisms and there currently is no working group with this on its charter. It would be desirable to work on this in conjunction with other efforts in the security area including work on GSS-API enhancements in KITTEN working group and SASL enhancements in the SASL working group. - The actual mechanisms in each of these frameworks have very similar goals of authentication and establishing a cryptographic context. In many cases frameworks are developing new functionality that bring them closer together. An example of this is the addition of a PRF API to access key material from GSS-API. - There is pressure to adopt a particular framework because of the set of mechanisms available not because of the capabilities and upper-layer interface of the framework. This recently was an issue with ISMS, but there has also been a desire to use EAP to authenticate other applications. We should be in a situation where the choice on mechanism was dictated by the deployment requirements and the choice of framework dictated by protocol design and implementation simplicity. - There is a duplication of effort in the development of security mechanism that support similar credential types and infrastructures. This is problematic because the development of security mechanisms is both difficult and time consuming. It would be good to leverage the work and expertise required for developing a mechanism across all the frameworks. - Often the cost of deploying a security mechanism is in the infrastructure and not the implementation of the mechanism itself. There limited set of mechanisms available to particular frameworks makes the coordination and administration of security between applications that use different frameworks more difficult. The first tasks of a SECMECH working group would be to document a set of evaluation criteria/guidelines explaining what standards-track security mechanisms need to do and how we will evaluate them and to document how we're going to go about specifying a security mechanism for use in the frameworks that are in scope. The working group would also be chartered to define a set of standards track mechanisms. The mechanism work would complete after the first two tasks have completed. From housley@vigilsec.com Thu Jun 23 15:34:55 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j5NJYr5j010059 for ; Thu, 23 Jun 2005 15:34:53 -0400 (EDT) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) j5NJYk2Z014439 for ; Thu, 23 Jun 2005 15:34:46 -0400 (EDT) Received: (qmail 1423 invoked by uid 0); 23 Jun 2005 19:32:58 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.3.80) by woodstock.binhost.com with SMTP; 23 Jun 2005 19:32:58 -0000 Message-Id: <6.2.1.2.2.20050623151423.081664d0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 23 Jun 2005 15:33:00 -0400 To: Alper Yegin From: Russ Housley In-Reply-To: <003f01c571d8$e8698030$291d9069@sisa.samsung.com> References: <003f01c571d8$e8698030$291d9069@sisa.samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.6 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.615667 cc: saag@mit.edu Subject: [saag] Re: AAA Key Management X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 23 Jun 2005 19:34:55 -0000 Alper: >I've just read it and have some comments and questions. > >[1] > > This document provides guidance to designers of AAA key management > protocols. > >I think this document's scope is not limited to "protocols." The stated >recommendations have impact on the systems and architectures as well. Yes. Are the "systems and architectures" things that the IETF BCP should cover? >[2] > Authenticator > The end of the link initiating EAP authentication. > >Characterizing the "authenticator" as the end of the link is too >limiting, especially when we consider EAP/IKEv2. In that case, the >authenticator may be across the Internet. How about "end of a link or tunnel"? >[3] Should the document discuss that a typical NAS hosts an EAP peer + a >AAA client? How does this impact the guidance that is being offered? >[4] Let's add PANA to other EAP lower layers mentioned in the document. I'm not sure where you want this to go. >[5] What's the difference between the key scope and key context? > > A party has access to a particular key if it has > access to all of the secret information needed to derive it. > >I didn't understand this. For example, when the NAS is provided with the >AAA-Key from the AAA server at the end of the EAP authentication, what >are the secrets owned by the NAS to "derive" that key? In the IEEE 802.11i environment, this key is used to derive all of the other keys that are used. The point is that a party that has access to the secrets values that go into a key derivation function must be presumed to have access to all of the resulting keys, even if they are not explicit recipients of any public values that are inputs to the key derivation function. >Btw, I guess RADIUS does not meet this requirement either as the >intermediate AAA proxies learn the AAA-Key in transit. This violates the principle of least privilege. >[6] > > Compromise of a single authenticator MUST NOT compromise any > other part of the system, especially session keys and long-term > keys. > >I think the document should expand on the term "system." Some specific >examples from well-known architectures like WiFi, 3GPP2, DSL, etc. would >be useful. How about: For example, if one IEEE 802.11 Access Point (AP) is compromised, then one must assume that all of the keying material known to that AP has been disclosed. This damaging event should not in turn lead to the compromise of keying material know to other APs in the same system. >[7] "Supplicant", as the 802.1X-specific "peer" is not used in the >document. I think it can be removed. Thanks. Will do. Russ From alper.yegin@samsung.com Fri Jun 24 15:04:17 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j5OJ4G5j017677 for ; Fri, 24 Jun 2005 15:04:16 -0400 (EDT) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) j5OJ45wE021083 for ; Fri, 24 Jun 2005 15:04:06 -0400 (EDT) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IIL00CNDRMS4D@mailout1.samsung.com> for saag@mit.edu; Sat, 25 Jun 2005 04:04:04 +0900 (KST) Received: from Alperyegin ([105.144.29.41])14 2004)) with ESMTPA id <0IIL000FLRMQ6C@mmp1.samsung.com> for saag@mit.edu; Sat, 25 Jun 2005 04:04:04 +0900 (KST) Date: Fri, 24 Jun 2005 12:02:35 -0700 From: Alper Yegin In-reply-to: <6.2.1.2.2.20050623151423.081664d0@mail.binhost.com> To: "'Russ Housley'" Message-id: <008801c578ef$49596780$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.676137 cc: saag@mit.edu Subject: [saag] RE: AAA Key Management X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 24 Jun 2005 19:04:17 -0000 Russ, > >[1] > > > > This document provides guidance to designers of AAA key management > > protocols. > > > >I think this document's scope is not limited to "protocols." The stated > >recommendations have impact on the systems and architectures as well. > > Yes. Are the "systems and architectures" things that the IETF BCP should > cover? I think it can. It is really hard to provide security guidelines by looking at the protocols in isolation. AAA key management is complete when we look at a complete set of protocols and how they interact (e.g., EAP, EAP methods, EAP lower layers, RADIUS, secure association, etc.) > >[2] > > Authenticator > > The end of the link initiating EAP authentication. > > > >Characterizing the "authenticator" as the end of the link is too > >limiting, especially when we consider EAP/IKEv2. In that case, the > >authenticator may be across the Internet. > > How about "end of a link or tunnel"? I think it is best if we avoid the use of link or tunnel. In IKE, EAP is executed even before the tunnel is established. And now we are also talking about multihop PANA, and there doesn't have to be any tunnel even after the completion of EAP. > >[3] Should the document discuss that a typical NAS hosts an EAP peer + a > >AAA client? > > How does this impact the guidance that is being offered? I'm not 100% sure... Isn't there any significance of EAP authenticator and RADIUS client being on the same node as far as delivery of AAA-Key or channel binding is concerned? (correction: I should have said "an EAP authenticator + a AAA client") > >[4] Let's add PANA to other EAP lower layers mentioned in the document. > > I'm not sure where you want this to go. The very first few sentences of the Section 3 enumerates where EAP is being utilized. .11i, .16e, and IKEv2 are the only examples given. > >[5] What's the difference between the key scope and key context? You missed the above question. > > > > A party has access to a particular key if it has > > access to all of the secret information needed to derive it. > > > >I didn't understand this. For example, when the NAS is provided with the > >AAA-Key from the AAA server at the end of the EAP authentication, what > >are the secrets owned by the NAS to "derive" that key? > > In the IEEE 802.11i environment, this key is used to derive all of the > other keys that are used. The point is that a party that has access to > the > secrets values that go into a key derivation function must be presumed to > have access to all of the resulting keys, even if they are not explicit > recipients of any public values that are inputs to the key derivation > function. I understand now. > > >Btw, I guess RADIUS does not meet this requirement either as the > >intermediate AAA proxies learn the AAA-Key in transit. > > This violates the principle of least privilege. > > >[6] > > > > Compromise of a single authenticator MUST NOT compromise any > > other part of the system, especially session keys and long-term > > keys. > > > >I think the document should expand on the term "system." Some specific > >examples from well-known architectures like WiFi, 3GPP2, DSL, etc. would > >be useful. > > How about: > For example, if one IEEE 802.11 Access Point (AP) is compromised, then one > must assume that all of the keying material known to that AP has been > disclosed. This damaging event should not in turn lead to the compromise > of keying material know to other APs in the same system. OK, in this example, the APs are peers in terms of the AAA key management hierarchy. If we had a centralized NAS that perceived the associated APs as its ports, then I think we'd be OK if compromise of NAS led to compromise of all the associated APs. Can we say this "system" in this example is the collection of NAS and its associated APs? > >[7] "Supplicant", as the 802.1X-specific "peer" is not used in the > >document. I think it can be removed. > > Thanks. Will do. Thank you. Alper From housley@vigilsec.com Fri Jun 24 16:23:57 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j5OKNu5j018105 for ; Fri, 24 Jun 2005 16:23:56 -0400 (EDT) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) j5OKNmwE022258 for ; Fri, 24 Jun 2005 16:23:48 -0400 (EDT) Received: (qmail 8307 invoked by uid 0); 24 Jun 2005 20:23:40 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.180.239) by woodstock.binhost.com with SMTP; 24 Jun 2005 20:23:40 -0000 Message-Id: <6.2.1.2.2.20050624160251.069c3780@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 24 Jun 2005 16:23:40 -0400 To: Alper Yegin From: Russ Housley In-Reply-To: <008801c578ef$49596780$291d9069@sisa.samsung.com> References: <6.2.1.2.2.20050623151423.081664d0@mail.binhost.com> <008801c578ef$49596780$291d9069@sisa.samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.6 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.716703 cc: saag@mit.edu Subject: [saag] RE: AAA Key Management X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 24 Jun 2005 20:23:58 -0000 Alper: Thanks for your review. I think this discussion is making the document better. > > >[1] > > > > > > This document provides guidance to designers of AAA key >management > > > protocols. > > > > > >I think this document's scope is not limited to "protocols." The >stated > > >recommendations have impact on the systems and architectures as well. > > > > Yes. Are the "systems and architectures" things that the IETF BCP >should > > cover? > >I think it can. It is really hard to provide security guidelines by >looking at the protocols in isolation. AAA key management is complete >when we look at a complete set of protocols and how they interact (e.g., >EAP, EAP methods, EAP lower layers, RADIUS, secure association, etc.) How about: This document provides architectural guidance to designers of AAA key management protocols. The guidance is also useful to designers of systems and solutions that include AAA key management protocols. > > >[2] > > > Authenticator > > > The end of the link initiating EAP authentication. > > > > > >Characterizing the "authenticator" as the end of the link is too > > >limiting, especially when we consider EAP/IKEv2. In that case, the > > >authenticator may be across the Internet. > > > > How about "end of a link or tunnel"? > >I think it is best if we avoid the use of link or tunnel. In IKE, EAP is >executed even before the tunnel is established. And now we are also >talking about multihop PANA, and there doesn't have to be any tunnel >even after the completion of EAP. How about: The party initiating EAP authentication. The term authenticator is used in [IEEE-802.1X], and authenticator has the same meaning in this document. > > >[3] Should the document discuss that a typical NAS hosts an EAP peer + a > > >AAA client? > > > > How does this impact the guidance that is being offered? > >I'm not 100% sure... Isn't there any significance of EAP authenticator >and RADIUS client being on the same node as far as delivery of AAA-Key >or channel binding is concerned? > >(correction: I should have said "an EAP authenticator + a AAA client") If one designs for separate machines for each party, then the fact that some of the parties end up on the same machine in some deployment scenarios does not seem to be a problem, as long as the fact that some parties have the same addresses does not confuse the key naming. This probably deserves some discussion in the security considerations. How about: In some deployment scenarios, more than one party in the AAA key management protocol can reside on the same host. For example, an EAP authenticator and a AAA client might be on the same host. If the design anticipates separate hosts for each party, and then some of the parties end up on the same host does not seem to be a problem, as long as the fact that some parties have the same addresses does not introduce ambiguity into the key naming. > > >[4] Let's add PANA to other EAP lower layers mentioned in the >document. > > > > I'm not sure where you want this to go. > >The very first few sentences of the Section 3 enumerates where EAP is >being utilized. .11i, .16e, and IKEv2 are the only examples given. Okay, I'll add PANA. > > >[5] What's the difference between the key scope and key context? > >You missed the above question. Actually, the discussion below was intended to help answer that question. I guess it didn't achieve that goal. Key scope - which parties have access to the key (or are able to derive it). Key context - how the parties will make use of the key. Note that the key scope is part of the context. > > > > > > A party has access to a particular key if it has > > > access to all of the secret information needed to derive >it. > > > > > >I didn't understand this. For example, when the NAS is provided with >the > > >AAA-Key from the AAA server at the end of the EAP authentication, >what > > >are the secrets owned by the NAS to "derive" that key? > > > > In the IEEE 802.11i environment, this key is used to derive all of the > > other keys that are used. The point is that a party that has access >to > > the > > secrets values that go into a key derivation function must be presumed >to > > have access to all of the resulting keys, even if they are not >explicit > > recipients of any public values that are inputs to the key derivation > > function. > >I understand now. > > > > > >Btw, I guess RADIUS does not meet this requirement either as the > > >intermediate AAA proxies learn the AAA-Key in transit. > > > > This violates the principle of least privilege. > > > > >[6] > > > > > > Compromise of a single authenticator MUST NOT compromise >any > > > other part of the system, especially session keys and >long-term > > > keys. > > > > > >I think the document should expand on the term "system." Some >specific > > >examples from well-known architectures like WiFi, 3GPP2, DSL, etc. >would > > >be useful. > > > > How about: > > For example, if one IEEE 802.11 Access Point (AP) is compromised, then >one > > must assume that all of the keying material known to that AP has been > > disclosed. This damaging event should not in turn lead to the >compromise > > of keying material know to other APs in the same system. > >OK, in this example, the APs are peers in terms of the AAA key >management hierarchy. If we had a centralized NAS that perceived the >associated APs as its ports, then I think we'd be OK if compromise of >NAS led to compromise of all the associated APs. Can we say this >"system" in this example is the collection of NAS and its associated >APs? In my view, the system also includes the peers. > > >[7] "Supplicant", as the 802.1X-specific "peer" is not used in the > > >document. I think it can be removed. > > > > Thanks. Will do. > >Thank you. Russ From stephen.farrell@cs.tcd.ie Mon Jun 27 07:47:44 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j5RBlg5j008801 for ; Mon, 27 Jun 2005 07:47:42 -0400 (EDT) Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) j5RBlVCM005581 for ; Mon, 27 Jun 2005 07:47:31 -0400 (EDT) Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id D7E1E680FB; Mon, 27 Jun 2005 12:47:30 +0100 (IST) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A02EF5A8C17; Mon, 27 Jun 2005 12:47:30 +0100 Received: from [127.0.0.1] (sfarrel2.dsg.cs.tcd.ie [134.226.36.26]) by imx2.tcd.ie (Postfix) with ESMTP id 96825680FB; Mon, 27 Jun 2005 12:47:30 +0100 (IST) Message-ID: <42BFE87D.6030906@cs.tcd.ie> Date: Mon, 27 Jun 2005 12:52:29 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: saag@mit.edu Content-Type: multipart/mixed; boundary="------------000402090701020508090701" X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.774) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: MessageID = A12EF5A8C17 X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.872402 cc: "Nystrom, Magnus" Subject: [saag] [Fwd: New work for sacred working group?] X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 27 Jun 2005 11:47:44 -0000 This is a multi-part message in MIME format. --------------000402090701020508090701 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Folks, We're trying to find out if there's interest in reviving the sacred WG to look at SPEKE (and related things) again (see the attached mail). Turns out we've got a totally underwhelming response, but its quite possible that no one reads that list anymore. If you do care, please (re-)subscribe to the sacred list [1] and say there what you think, Thanks, Stephen. [1] http://www.imc.org/ietf-sacred/index.html --------------000402090701020508090701 Content-Type: message/rfc822; name="New work for sacred working group?" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="New work for sacred working group?" >From - Mon Jun 20 17:25:40 2005 Return-Path: X-Original-To: stephen.farrell@cs.tcd.ie Delivered-To: stephen.farrell@cs.tcd.ie Received: from smtp.cs.tcd.ie (localhost [127.0.0.1]) by relay.cs.tcd.ie (Postfix) with ESMTP id 95E5C386 for ; Mon, 20 Jun 2005 17:20:27 +0100 (IST) Received: from xmx2.tcd.ie (xmx2.tcd.ie [134.226.1.152]) by smtp.cs.tcd.ie (Postfix) with ESMTP id 8102D348 for ; Mon, 20 Jun 2005 17:20:25 +0100 (IST) Received: from Vams.xmx2 (xmx2 [134.226.1.152]) by xmx2.tcd.ie (Postfix) with SMTP id 3E90115C018 for ; Mon, 20 Jun 2005 17:20:25 +0100 (IST) (envelope-from owner-ietf-sacred@mail.imc.org) Received: from xmx2.tcd.ie ([134.226.1.152]) by xmx2 ([134.226.1.152]) with SMTP (gateway) id A070C131DC5; Mon, 20 Jun 2005 17:20:25 +0100 Received: by xmx2.tcd.ie (Postfix, from userid 405) id 2D6B915C036; Mon, 20 Jun 2005 17:20:25 +0100 (IST) Received: from above.proper.com (above.proper.com [208.184.76.39]) by xmx2.tcd.ie (Postfix) with ESMTP id 4097415C018 for ; Mon, 20 Jun 2005 17:20:23 +0100 (IST) (envelope-from owner-ietf-sacred@mail.imc.org) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5KGExnE059841; Mon, 20 Jun 2005 09:14:59 -0700 (PDT) (envelope-from owner-ietf-sacred@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5KGExdc059840; Mon, 20 Jun 2005 09:14:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sacred@mail.imc.org using -f Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5KGEvlY059682 for ; Mon, 20 Jun 2005 09:14:58 -0700 (PDT) (envelope-from stephen.farrell@cs.tcd.ie) Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id 29E4F14C013; Mon, 20 Jun 2005 17:14:45 +0100 (IST) Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A00C17EF6F0; Mon, 20 Jun 2005 17:14:44 +0100 Received: from [134.226.36.26] (sfarrel2.dsg.cs.tcd.ie [134.226.36.26]) by smtp3.tcd.ie (Postfix) with ESMTP id D27AF14C013; Mon, 20 Jun 2005 17:14:44 +0100 (IST) Message-ID: <42B6EC96.7070303@cs.tcd.ie> Date: Mon, 20 Jun 2005 17:19:34 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sacred@imc.org Cc: magnus@rsasecurity.com Subject: New work for sacred working group? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.768) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: smtp3.tcd.ie X-AntiVirus-Status: MessageID = A10C17EF6F0 Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.768) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: xmx2.tcd.ie X-AntiVirus-Status: MessageID = A170C131DC5 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on relay.cs.tcd.ie X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 Dear sacred WG, Magnus and I have requested a slot for the sacred WG at the upcoming Paris IETF meeting [1]. There are three things to discuss (see below). One possible outcome is that we reawaken this WG to do some work. Formally, this would probably require a charter update. The outcome of the discussions could also be a decision not to take on any further SACRED work at this point. In all likelihood, this would mean that the SACRED working group will be shut down. Hopefully, we can come to consensus on this between now and a few weeks after the Paris meeting. Regardless of whether or not you intend coming to Paris, We'd encourage you to let the list know how you think we ought proceed, so that we are able to start that meeting with some idea of the level of interest and the range of opinions, (or else, we can cancel the meeting if there's no interest), So, read on...and comment to the list! Stephen & Magnus. Item 1: SACRED has always been in need of a strong password- based mechanism for download of credentials. Early on, the WG considered [2] using SPEKE for this. However, there was no concensus for this approach, at least partly due to the, at the time, unclear IPR situation. Over the last couple of months, Magnus and I have been in touch with the holders of the SPEKE patent, Phoenix Technologies [3], who have now made a generic IPR declaration to the IETF [4]. Phoenix would like the opportunity to present their technology and discuss its use in sacred. Note that while the current, generic declation is basically RAND, this does not necessarily imply that the terms for the use of SPEKE for sacred would be exactly the same. In our discussions with Phoenix so far, they appear to have made serious attempts to learn how to be "IETF-friendly" and they are coming to the meeting to explain their technology and position and to learn whether and/or how they can make use of SPEKE attractive in IETF-concensus terms. - If there is WG concensus then we could work to improve the sacred protocol [5] by incorporating SPEKE. Item 2: Independently of the discussions with Phoenix Technologues, Radia Perlman and Charlie Kaufman, who where also deeply involved in the early stages of this working group, have suggested a scheme they themselves invented which pre-dates SPEKE. Their email below summarises their scheme and its history. - If there is WG concensus then we could work to improve the sacred protocol by incorporating Radia and Charlie's scheme. Item 3: RSA Security has drafted a description [6] of how to (more or less) run the current sacred protocol using HTTP instead of BEEP as a substrate. - Were there to be WG concensus on doing work on items 1 or 2, then the WG might consider improving the protocol by changing the substrate from BEEP to HTTP. Note that in our opinion, item 3 alone is not sufficient reason to re-charter the WG. Here's a suggested 1-hour meeting agenda (we may get an additional 30 minutes in which case each item would get proportionally longer time): - Introductions (5) - Item 3: HTTP as a SACRED substrate (10) - Item 2: Radia's & Charlie's scheme (15) - Item 1: Phoenix presentation on SPEKE (15) - Discussion on new work, possible re-chartering (15) References: [1] http://www.ietf.org/meetings/IETF-63.html [2] http://www.ietf.org/proceedings/02mar/203.htm [3] http://www.phoenix.com/ [4] https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=587 [5] http://www.ietf.org/rfc/rfc3767.txt [6] ftp://ftp.rsasecurity.com/pub/rsalabs/ietf/sacred/draft-richards-sacred-http-XX.txt Charlie Kaufman wrote: > I agree with this technical and historical summary. > [...] > > --Charlie > > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman@sun.com] > Sent: Wednesday, June 15, 2005 9:49 AM > To: magnus@rsasecurity.com; stephen.farrell@cs.tcd.ie > Cc: Charlie Kaufman > Subject: A possible credentials download protocol > > Charlie...correct me if I get any of the technical or historical details > > wrong here. Perhaps you should > reply to all, even if there are no errors, saying "I agree". > > *************** > In the first edition of the book "Network Security" published in March > 1995, on page 252, there > is a protocol that although we claim in the book it is "Bellovin and > Merritt's Second Scheme" was actually > a protocol Charlie inadvertently invented, because he had misremembered > augmented EKE. > > The diagram in the book of Charlie's protocol does two things: it does > mutual authentication, and also > downloads Alice's credential (her private key). > > For the sacred WG, we could do just the credential download portion of > the protocol. That means removing > messages 3 and 5 (the ones in which the client Alice authenticates to > Bob), and we can certainly also > remove the challenge field from message 2 (where Bob sends Alice a > challenge to authenticate with). > > We are left with a 2 message protocol that does no authentication by > Alice to Bob. Bob has no idea, after > the exchange, whether the true Alice, knowing the password, has > successfully downloaded the credential. > If it is an imposter, the imposter will obtain garbage. Bob can't tell > the difference. > > However, for the purpose of the sacred WG, we do not need an > authentication protocol. All we need is > a credential download protocol. > > Anyway, the protocol I'm proposing is a 2-message protocol that looks > like this: > > Bob (the server) has the following two pieces of information: > > . W=hash of Alice's password > . Y=credential (which is Alice's private key encrypted with her > password). > > In the protocol, Alice and Bob do a Diffie-Hellman exchange, encrypted > with W, and Bob sends > Y encrypted with the resulting Diffie-Hellman key. So the protocol is: > > Alice and Bob each choose a random number A, and B, respectively. The > Diffie-Hellman parameters > are g and p. > > Alice to Bob: {g^A mod p}encrypted with W > Bob to Alice: {g^B mod p} encrypted with W, {Y} encrypted with g^AB > > ********* > The protocol in the book had an additional challenge, R, and was: > > 1: Alice to Bob: {g^A mod p}W > 2: Bob to ALice: {g^B mod p}W, R > 3: Alice to Bob: {R} encrypted with g^AB mod p > 4: Bob to ALice: {Y} encrypted with g^AB > 5: Alice to Bob: R signed by Alice's private key > > So I'm proposing removing messages 3 and 5, combining messages 2 and 4, > and removing the field "R" > from message 2. > > > > --------------000402090701020508090701-- From alper.yegin@samsung.com Mon Jun 27 16:30:23 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j5RKUM5j012079 for ; Mon, 27 Jun 2005 16:30:22 -0400 (EDT) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) j5RKUEeQ029246 for ; Mon, 27 Jun 2005 16:30:15 -0400 (EDT) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IIR00LBVFMD4M@mailout3.samsung.com> for saag@mit.edu; Tue, 28 Jun 2005 05:30:13 +0900 (KST) Received: from Alperyegin ([105.144.29.41])14 2004)) with ESMTPA id <0IIR00LDYFMBW1@mmp1.samsung.com> for saag@mit.edu; Tue, 28 Jun 2005 05:30:13 +0900 (KST) Date: Mon, 27 Jun 2005 13:28:40 -0700 From: Alper Yegin In-reply-to: <6.2.1.2.2.20050624160251.069c3780@mail.binhost.com> To: "'Russ Housley'" Message-id: <02cf01c57b56$cfa94cb0$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.662299 cc: saag@mit.edu Subject: [saag] RE: AAA Key Management X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 27 Jun 2005 20:30:24 -0000 Russ, > How about: > This document provides architectural guidance to designers of AAA key > management protocols. The guidance is also useful to designers of > systems and solutions that include AAA key management protocols. Yes, this makes sense. > How about: > The party initiating EAP authentication. The term authenticator > is used in [IEEE-802.1X], and authenticator has the same meaning > in this document. This looks good too. > > > >[3] Should the document discuss that a typical NAS hosts an EAP peer > + a > > > >AAA client? > > > > > > How does this impact the guidance that is being offered? > > > >I'm not 100% sure... Isn't there any significance of EAP authenticator > >and RADIUS client being on the same node as far as delivery of AAA-Key > >or channel binding is concerned? > > > >(correction: I should have said "an EAP authenticator + a AAA client") > > If one designs for separate machines for each party, then the fact that > some of the parties end up on the same machine in some deployment > scenarios > does not seem to be a problem, as long as the fact that some parties have > the same addresses does not confuse the key naming. I understand that collocating otherwise separable entities is not likely to be an issue. I was asking if we require (assume) the EAP authenticator and the AAA client be on the same node. > > This probably deserves some discussion in the security considerations. > How about: > In some deployment scenarios, more than one party in the AAA key > management protocol can reside on the same host. For example, an EAP > authenticator and a AAA client might be on the same host. If the design > anticipates separate hosts for each party, and then some of the parties > end up on the same host does not seem to be a problem, as long as the > fact that some parties have the same addresses does not introduce > ambiguity into the key naming. > > Okay, I'll add PANA. Thanks. > > > > >[5] What's the difference between the key scope and key context? > > > >You missed the above question. > > Actually, the discussion below was intended to help answer that > question. I guess it didn't achieve that goal. > > Key scope - which parties have access to the key (or are able to derive > it). > > Key context - how the parties will make use of the key. Note that the key > scope is part of the context. This makes perfect sense to me. > > > >[6] > > > > > > > > Compromise of a single authenticator MUST NOT compromise > >any > > > > other part of the system, especially session keys and > >long-term > > > > keys. > > > > > > > >I think the document should expand on the term "system." Some > >specific > > > >examples from well-known architectures like WiFi, 3GPP2, DSL, etc. > >would > > > >be useful. > > > > > > How about: > > > For example, if one IEEE 802.11 Access Point (AP) is compromised, then > >one > > > must assume that all of the keying material known to that AP has been > > > disclosed. This damaging event should not in turn lead to the > >compromise > > > of keying material know to other APs in the same system. > > > >OK, in this example, the APs are peers in terms of the AAA key > >management hierarchy. If we had a centralized NAS that perceived the > >associated APs as its ports, then I think we'd be OK if compromise of > >NAS led to compromise of all the associated APs. Can we say this > >"system" in this example is the collection of NAS and its associated > >APs? > > In my view, the system also includes the peers. Let me confirm on an illustration. The following is a physical topology: NAS (EAP authenticator, RADIUS client, holds AAA-Key) | +----+----+ | | AP1 AP2 (each AP has its own TSK for the STA) . . . STA (EAP peer, holds AAA-Key, TSK) If NAS is compromised, the APs are compromised. Does this violate the domino effect rule? (I hope not). Thanks. Alper From housley@vigilsec.com Mon Jun 27 16:47:48 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j5RKlk5j012182 for ; Mon, 27 Jun 2005 16:47:46 -0400 (EDT) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) j5RKlY5O014893 for ; Mon, 27 Jun 2005 16:47:34 -0400 (EDT) Received: (qmail 5585 invoked by uid 0); 27 Jun 2005 20:47:27 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.44.179) by woodstock.binhost.com with SMTP; 27 Jun 2005 20:47:27 -0000 Message-Id: <6.2.1.2.2.20050627164046.0772b720@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 27 Jun 2005 16:47:28 -0400 To: Alper Yegin From: Russ Housley In-Reply-To: <02cf01c57b56$cfa94cb0$291d9069@sisa.samsung.com> References: <6.2.1.2.2.20050624160251.069c3780@mail.binhost.com> <02cf01c57b56$cfa94cb0$291d9069@sisa.samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.6 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.637378 cc: saag@mit.edu Subject: [saag] RE: AAA Key Management X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 27 Jun 2005 20:47:48 -0000 Alper: I have dropped parts of the discussion where we have reached closure. > > > > >[3] Should the document discuss that a typical NAS hosts an EAP > peer + a > > > > >AAA client? > > > > > > > > How does this impact the guidance that is being offered? > > > > > >I'm not 100% sure... Isn't there any significance of EAP authenticator > > >and RADIUS client being on the same node as far as delivery of AAA-Key > > >or channel binding is concerned? > > > > > >(correction: I should have said "an EAP authenticator + a AAA client") > > > > If one designs for separate machines for each party, then the fact that > > some of the parties end up on the same machine in some deployment scenarios > > does not seem to be a problem, as long as the fact that some parties have > > the same addresses does not confuse the key naming. > >I understand that collocating otherwise separable entities is not likely >to be an issue. I was asking if we require (assume) the EAP >authenticator and the AAA client be on the same node. I do not think so. In fact, in the CAPWAP architecture, it is not clear that they will be on the same host. > > > > >[6] > > > > > Compromise of a single authenticator MUST NOT compromise any > > > > > other part of the system, especially session keys and > long-term > > > > > keys. > > > > > > > > > >I think the document should expand on the term "system." Some specific > > > > >examples from well-known architectures like WiFi, 3GPP2, DSL, etc. > would > > > > >be useful. > > > > > > > > How about: > > > > For example, if one IEEE 802.11 Access Point (AP) is compromised, > then one > > > > must assume that all of the keying material known to that AP has been > > > > disclosed. This damaging event should not in turn lead to the > compromise > > > > of keying material know to other APs in the same system. > > > > > >OK, in this example, the APs are peers in terms of the AAA key > > >management hierarchy. If we had a centralized NAS that perceived the > > >associated APs as its ports, then I think we'd be OK if compromise of > > >NAS led to compromise of all the associated APs. Can we say this > > >"system" in this example is the collection of NAS and its associated > > >APs? > > > > In my view, the system also includes the peers. > >Let me confirm on an illustration. The following is a physical topology: > > NAS (EAP authenticator, RADIUS client, holds AAA-Key) > | > +----+----+ > | | >AP1 AP2 (each AP has its own TSK for the STA) > . > . > . >STA (EAP peer, holds AAA-Key, TSK) > >If NAS is compromised, the APs are compromised. Does this violate the >domino effect rule? (I hope not). Okay. So, the confusion seems to be the word "authenticator." I'll think about how to make this more clear. Wording suggestions welcome. Russ From paul.hoffman@vpnc.org Mon Jun 27 20:49:43 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j5S0ng5j013654 for ; Mon, 27 Jun 2005 20:49:42 -0400 (EDT) Received: from above.proper.com (above.proper.com [208.184.76.39]) j5S0nXbS005777 for ; Mon, 27 Jun 2005 20:49:33 -0400 (EDT) Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5S0nVA7068817 for ; Mon, 27 Jun 2005 17:49:32 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 27 Jun 2005 17:49:31 -0700 To: saag@mit.edu From: Paul Hoffman Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.627260 Subject: [saag] Fwd: Notification re UTR #36, Security Issues X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 28 Jun 2005 00:49:44 -0000 >To: unicode@unicode.org >Subject: Notification re UTR #36, Security Issues >Date: Mon, 27 Jun 2005 13:02:13 -0700 >From: Rick McGowan >X-archive-position: 3495 >X-ecartis-version: Ecartis v1.0.0 >Sender: unicore-bounce@unicode.org >X-original-sender: rick@unicode.org > >Due to computer security issues, a set of guidelines is being drafted that >can impact the use of future International Domain Names (i.e., >http://m¸ller.de/ ) and identifiers. The computer security issues that have >arisen involve spoofing of letters or numbers (e.g., in a recent case, >unsuspecting users were sending credit card information to "PayPal.com" >which was spelled with a capital "I" in place of lowercase "L", because the >two are not visibly distinct in some fonts). Similarly Cyrillic or Greek >letters could be used in lieu of similar looking Latin letters in domain >names. > >The current draft Unicode Technical Report #36 contains guidelines that >suggest restricting a variety of characters; they would only be permitted >under lenient security settings. See >http://www.unicode.org/draft/reports/tr36/tr36.html. The document is a >working draft, and both it and the data files it points to may be edited up >to the time it is released. > >Because of the subject matter, this draft will be released very soon, but >there is still some time for feedback. Comments received by the end of this >week (July 1) can be considered for this version of the document, while >those after that point will be considered for the next version. Comments >should be sent via http://unicode.org/reporting.html . > >You many find it useful to look at the characters listed in the following >file: http://unicode.org/draft/reports/tr36/data/draft-restrictions.txt . >These lists include a representation of the characters, but the image may >not appear on your screen depending on the fonts installed on your machine; >you may need to use the character code numbers [or names] and refer to the >code charts at http://www.unicode.org/charts/.) From alper.yegin@samsung.com Tue Jun 28 17:00:09 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j5SL085j020436 for ; Tue, 28 Jun 2005 17:00:08 -0400 (EDT) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) j5SKxxaI004376 for ; Tue, 28 Jun 2005 17:00:00 -0400 (EDT) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IIT00C8FBNYNO@mailout2.samsung.com> for saag@mit.edu; Wed, 29 Jun 2005 05:59:58 +0900 (KST) Received: from Alperyegin ([105.144.29.41])Jun 23saag@mit.edu; Wed, 29 Jun 2005 05:59:58 +0900 (KST) Date: Tue, 28 Jun 2005 13:58:25 -0700 From: Alper Yegin In-reply-to: <6.2.1.2.2.20050627164046.0772b720@mail.binhost.com> To: "'Russ Housley'" Message-id: <00d601c57c24$21a7f750$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.556832 cc: saag@mit.edu Subject: [saag] RE: AAA Key Management X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 28 Jun 2005 21:00:09 -0000 > >Let me confirm on an illustration. The following is a physical topology: > > > > NAS (EAP authenticator, RADIUS client, holds AAA-Key) > > | > > +----+----+ > > | | > >AP1 AP2 (each AP has its own TSK for the STA) > > . > > . > > . > >STA (EAP peer, holds AAA-Key, TSK) > > > >If NAS is compromised, the APs are compromised. Does this violate the > >domino effect rule? (I hope not). > > Okay. So, the confusion seems to be the word "authenticator." I'll think > about how to make this more clear. Wording suggestions welcome. Can we look at this from the key hierarchy perspective? In that, if a node in the hierarchy is compromised, all the nodes within that node's subtree may be compromised, but no other node must be compromised. For example, - if AAA server is compromised, the NAS is compromised. If the NAS is compromised, the BSs are compromised (per above figure). - if the NAS is compromised, the AAA server must not be compromised. From kapil.sood@intel.com Tue Jun 28 18:14:51 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j5SMEo5j020973 for ; Tue, 28 Jun 2005 18:14:50 -0400 (EDT) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) j5SMEgaI015172 for ; Tue, 28 Jun 2005 18:14:43 -0400 (EDT) Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) 2004/09/17 17:50:56 root Exp $) with ESMTP id j5SMEeaS030152; Tue, 28 Jun 2005 22:14:40 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) 2004/09/17 18:05:01 root Exp $) with SMTP id j5SMESON013928; Tue, 28 Jun 2005 22:14:37 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) M2005062815143726635 ; Tue, 28 Jun 2005 15:14:37 -0700 Received: from orsmsx404.amr.corp.intel.com ([192.168.65.44]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Jun 2005 15:14:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [saag] RE: AAA Key Management Date: Tue, 28 Jun 2005 15:14:35 -0700 Message-ID: <0604335B7764D141945E2021531059600541FC48@orsmsx404.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] RE: AAA Key Management Thread-Index: AcV8Ju2kj9DSr1+NSMm/W90seVQ0KQABtjIA From: "Sood, Kapil" To: "Alper Yegin" , "Russ Housley" X-OriginalArrivalTime: 28 Jun 2005 22:14:37.0197 (UTC) FILETIME=[C56493D0:01C57C2E] X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: -0.985 X-Spam-Flag: NO Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.580362 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id j5SMEo5j020973 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 28 Jun 2005 22:14:51 -0000 Whether the other nodes carrying components of the key hierarchy are compromised depends on number of things: 1. Whether the keys derived at each level are static or dynamic. 2. The purpose or desired/designed use of the keys. What I am suggesting is that based on key derivation mechanism and purposed use of keys, any key compromised in the key hierarchy may make the entire key hiererchy un-usable. Best Regards, Kapil. 503.264.3759 -----Original Message----- From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of Alper Yegin Sent: Tuesday, June 28, 2005 1:58 PM To: 'Russ Housley' Cc: saag@mit.edu Subject: [saag] RE: AAA Key Management > >Let me confirm on an illustration. The following is a physical topology: > > > > NAS (EAP authenticator, RADIUS client, holds AAA-Key) > > | > > +----+----+ > > | | > >AP1 AP2 (each AP has its own TSK for the STA) > > . > > . > > . > >STA (EAP peer, holds AAA-Key, TSK) > > > >If NAS is compromised, the APs are compromised. Does this violate the > >domino effect rule? (I hope not). > > Okay. So, the confusion seems to be the word "authenticator." I'll think > about how to make this more clear. Wording suggestions welcome. Can we look at this from the key hierarchy perspective? In that, if a node in the hierarchy is compromised, all the nodes within that node's subtree may be compromised, but no other node must be compromised. For example, - if AAA server is compromised, the NAS is compromised. If the NAS is compromised, the BSs are compromised (per above figure). - if the NAS is compromised, the AAA server must not be compromised. _______________________________________________ saag mailing list saag@mit.edu https://jis.mit.edu/mailman/listinfo/saag From Donald.Eastlake@motorola.com Tue Jun 28 21:01:42 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j5T11g5j022154 for ; Tue, 28 Jun 2005 21:01:42 -0400 (EDT) Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) j5T11Y2c026502 for ; Tue, 28 Jun 2005 21:01:34 -0400 (EDT) Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate7) with ESMTP id j5T1ALW9028160 for ; Tue, 28 Jun 2005 18:10:21 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id j5T15kPB019902 for ; Tue, 28 Jun 2005 20:05:46 -0500 (CDT) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Jun 2005 21:01:32 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF238109316D7F@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: "'saag@mit.edu'" Date: Tue, 28 Jun 2005 21:01:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: -0.413 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.019172 Spam-Alum-Time: 0.524546 cc: 'Tony Hansen' Subject: [saag] SHAs source code ID X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 29 Jun 2005 01:01:43 -0000 Hi, Tony Hansen and I have produced an internet-draft with source code for the SHA hashes including 32-bit and 64-bit arithmetic code for SHA-512 and SHA-384. The draft has been up for a little while so I thought I'd post a message here to see if anyone had any comments. It's ftp://ftp.ietf.org/internet-drafts/draft-eastlake-sha2-00.txt. Thanks, Donald From brc@zurich.ibm.com Thu Jun 2 07:47:14 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j52BlD5j012944 for ; Thu, 2 Jun 2005 07:47:13 -0400 (EDT) Received: from mtagate4.de.ibm.com (mtagate4.de.ibm.com [195.212.29.153]) j52Bl14R026291 for ; Thu, 2 Jun 2005 07:47:02 -0400 (EDT) Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j52Bl1tc184360 for ; Thu, 2 Jun 2005 11:47:01 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229])id j52Bl0Do131026 for ; Thu, 2 Jun 2005 13:47:01 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) j52BkxLr021285 for ; Thu, 2 Jun 2005 13:46:59 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) j52Bkwxk021266; Thu, 2 Jun 2005 13:46:59 +0200 Received: from zurich.ibm.com (sig-9-146-220-72.de.ibm.com [9.146.220.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA41042; Thu, 2 Jun 2005 13:46:58 +0200 Message-ID: <429EF1AE.1040805@zurich.ibm.com> From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Jeffrey Altman Subject: Re: [saag] [Sam Hartman] draft-harris-ssh-arcfour-fixes-02: informational or proposed? References: <429E0F70.6040708@columbia.edu> In-Reply-To: <429E0F70.6040708@columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.099 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.707130 X-Mailman-Approved-At: Tue, 28 Jun 2005 22:04:24 -0400 cc: ietf@ietf.org cc: ietf-ssh@netbsd.org cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Date: Thu, 02 Jun 2005 11:47:15 -0000 X-Original-Date: Thu, 02 Jun 2005 13:46:54 +0200 X-List-Received-Date: Thu, 02 Jun 2005 11:47:15 -0000 Jeffrey Altman wrote: > My personal opinion is that if there is a protocol that has been widely > deployed but which for whatever reason the IETF does not want to > encourage its adoption, the RFC should be published immediately as > HISTORIC. > > Jeffrey Altman My personal opinion is that RFC 2026 doesn't really allow this, except by a very strange process in which the IESG first authorizes publication as Informational and then immediately authorizes re-classification as Historic. Whenever 2026 gets updated, this could be clarified. In any case, in such a case (if the IESG agrees) the mechanism is to publish with an appropriate IESG Note included, to give the health warning. That is much more important than whether it's labelled info or historic. But the substantive question about rc4 remains. Brian > > > Sam Hartman wrote: > > >>Hi. I believe the following request is of interest to secsh and saag. >> >> >> >>------------------------------------------------------------------------ >> >>Subject: >>draft-harris-ssh-arcfour-fixes-02: informational or proposed? >>From: >>Sam Hartman >>Date: >>Wed, 01 Jun 2005 14:35:07 -0400 >>To: >>ietf@ietf.org >> >>To: >>ietf@ietf.org >>CC: >>iesg@ietf.org >> >>Return-Path: >> >>Received: >>from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus >>v2.1.16-IPv6-Debian-2.1.16-10) with LMTP; Wed, 01 Jun 2005 14:37:25 -0400 >>X-Sieve: >>CMU Sieve 2.2 >>Return-Path: >> >>Received: >>from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by >>suchdamage.org (Postfix) with ESMTP id 581AA1383D for >>; Wed, 1 Jun 2005 14:37:23 -0400 (EDT) >>Received: >>from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by >>megatron.ietf.org with esmtp (Exim 4.32) id 1DdY3t-00074x-D9; Wed, 01 >>Jun 2005 14:35:29 -0400 >>Received: >>from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org >>with esmtp (Exim 4.32) id 1DdY3r-00073R-2v; Wed, 01 Jun 2005 14:35:27 -0400 >>Received: >>from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org >>(8.9.1a/8.9.1a) with ESMTP id OAA13323; Wed, 1 Jun 2005 14:35:23 -0400 (EDT) >>Received: >>from stratton-three-sixty-nine.mit.edu ([18.187.6.114] >>helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim >>4.33) id 1DdYNe-0002lY-42; Wed, 01 Jun 2005 14:55:59 -0400 >>Received: >>by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 36E3DE0063; >>Wed, 1 Jun 2005 14:35:07 -0400 (EDT) >>Message-ID: >> >>User-Agent: >>Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) >>X-Scan-Signature: >>c1c65599517f9ac32519d043c37c5336 >>X-BeenThere: >>ietf@ietf.org >>X-Mailman-Version: >>2.1.5 >>Precedence: >>list >>List-Id: >>IETF-Discussion >>List-Unsubscribe: >>, >> >>List-Post: >> >>List-Help: >> >>List-Subscribe: >>, >> >>Sender: >>ietf-bounces@ietf.org >>Errors-To: >>ietf-bounces@ietf.org >>X-Spam-Checker-Version: >>SpamAssassin 3.0.2 (2004-11-16) on solipsist-nation.suchdamage.org >>X-Spam-Status: >>No, score=-1.7 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 >>MIME-Version: >>1.0 >> >> >> >>Hi, folks. The IESG has received a last call comment recommending >>that the new rc4 cipher for ssh be published as informational rather >>than as a proposed standard because of weaknesses in rc4. It would be >>inappropriate to make a decision based on one comment so I am >>soliciting comments on this point. >> >>The argument in favor of publishing this document at proposed is that >>the existing arcfour cipher is part of a standard and that many other >>IETF protocols use rc4 in standards track documents. >> >> >>Please submit comments to ietf@ietf.org or iesg@ietf.org on this issue >>by 2005-06-28. >> >>Included below is a partial bibliography of RC4 attacks provided to >>the IESG by the person making the original comment. >> >> >> >>S. Fluhrer, I. Mantin, & A. Shamir, "Weaknesses in the Key Scheduling >>Algorithm of RC4", Proceedings of 8th Annual International Workshop >>on Selected areas in Cryptography (SAC 2001), Toronto, ON, CA, >>August 2001. >> >>J. D. Golic, "Linear Statistical Weakness of RC4 Key Generator", >>Procedings of EuroCrypt 1997, Konstanz, DE, May 1997. >> >>S. Fluhrer & D. McGrew, "Statistical Analysis of the RC4 Key >>Generator", Proceedings of 7th International Workshop on Fast >>Software Encryption (FSE 2000), New York, NY, US, April 2000. >> >>S. Mister & S.E. Tavares, "Cryptanalysis of RC4-like Ciphers", >>Proceedings of 5th Annual International Workshop on Selected >>Areas in Cryptography (SAC 1998), Kingston, ON, CA, August 1998. >> >>L. Knudsen, W. Meier, B. Preneel, V. Rijmen, & S. Verdoolaege, >>"Analysis Method for RC4", Proceedings of AsiaCrypt 1998. >> >>R. Wash, "Lecture Notes on Stream Ciphers and RC4", unpublished, >>Case Western Reserve University, OH, US >>http://acm.cwru.edu/files/2002%20Spring/talks/latex_samp2_4_09_02.pdf >> >>S. Paul & B. Preneel, "Analysis of Non-fortuitous Predictive States >>of the RC4 Key Generator", Proceedings of 4th International Conference >>on Cryptology in India (IndoCrypt 2003), New Delhi, IN, December 2003. >> >>_______________________________________________ >>Ietf mailing list >>Ietf@ietf.org >>https://www1.ietf.org/mailman/listinfo/ietf >> >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>saag mailing list >>saag@mit.edu >>https://jis.mit.edu/mailman/listinfo/saag >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>Ietf mailing list >>Ietf@ietf.org >>https://www1.ietf.org/mailman/listinfo/ietf From tony@att.com Tue Jun 28 22:54:11 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j5T2sB5j023113 for ; Tue, 28 Jun 2005 22:54:11 -0400 (EDT) Received: from mail131.messagelabs.com (mail131.messagelabs.com [216.82.242.99])j5T2s22U025463 for ; Tue, 28 Jun 2005 22:54:02 -0400 (EDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-5.tower-131.messagelabs.com!1120013642!3738415!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.166.71] Received: (qmail 17567 invoked from network); 29 Jun 2005 02:54:02 -0000 Received: from almso2.att.com (HELO almso2.proxy.att.com) (192.128.166.71) by server-5.tower-131.messagelabs.com with SMTP; 29 Jun 2005 02:54:02 -0000 Received: from maillennium.att.com ([135.25.114.99])j5T2s2Gd021262 for ; Tue, 28 Jun 2005 22:54:02 -0400 Received: from [135.70.57.56] (unknown[135.70.57.56](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20050629025315gw100gipnje> (Authid: tony); Wed, 29 Jun 2005 02:53:15 +0000 Message-ID: <42C20D45.20803@att.com> Date: Tue, 28 Jun 2005 22:53:57 -0400 From: Tony Hansen User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: "'saag@mit.edu'" References: <62173B970AE0A044AED8723C3BCF238109316D7F@ma19exm01.e6.bcs.mot.com> In-Reply-To: <62173B970AE0A044AED8723C3BCF238109316D7F@ma19exm01.e6.bcs.mot.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.001 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000002 Spam-Alum-Time: 0.537529 Subject: [saag] Re: SHAs source code ID X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 29 Jun 2005 02:54:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In addition to providing bit-level hashes for sha 224, 256, 384 and 512, the draft also updates rfc3174's sha-1 code with bit-level support. Tony Hansen tony@att.com Eastlake III Donald-LDE008 wrote: > Tony Hansen and I have produced an internet-draft with source code > for the SHA hashes including 32-bit and 64-bit arithmetic code for > SHA-512 and SHA-384. The draft has been up for a little while so I > thought I'd post a message here to see if anyone had any comments. > It's ftp://ftp.ietf.org/internet-drafts/draft-eastlake-sha2-00.txt. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCwg1FxsSylYhzrRYRAj7WAJsFeJcDLHktS4oYH1KR0ighVnZ31wCgs7yi 1eJH7s0ghCZspS+ENiiZqfM= =3dOd -----END PGP SIGNATURE----- From ben@algroup.co.uk Thu Jun 30 04:12:33 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j5U8CW5j004102 for ; Thu, 30 Jun 2005 04:12:32 -0400 (EDT) Received: from mail.links.org (mail.links.org [217.155.92.109]) j5U8CLRi018451 for ; Thu, 30 Jun 2005 04:12:22 -0400 (EDT) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 599A733C1A; Thu, 30 Jun 2005 09:12:27 +0100 (BST) Message-ID: <42C3A8EA.9000603@algroup.co.uk> Date: Thu, 30 Jun 2005 09:10:18 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman Subject: Re: [saag] Fwd: Notification re UTR #36, Security Issues References: In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.600920 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 30 Jun 2005 08:12:34 -0000 Paul Hoffman wrote: >> Due to computer security issues, a set of guidelines is being >> drafted that can impact the use of future International Domain >> Names (i.e., http://m¸ller.de/ ) and identifiers. The computer >> security issues that have arisen involve spoofing of letters or >> numbers (e.g., in a recent case, unsuspecting users were sending >> credit card information to "PayPal.com" which was spelled with a >> capital "I" in place of lowercase "L", because the two are not >> visibly distinct in some fonts). Similarly Cyrillic or Greek >> letters could be used in lieu of similar looking Latin letters in >> domain names. I'd note that this first issue is _not_ an IDN issue, but applies to traditional domain names. This would appear to have rather serious impact on the DNS, if we decide to take this report seriously (I'm assuming it includes recommendations that related to I vs. l, since I have not been able to actually reach the site since I saw this post). Of course, what this is really pointing to is what we all surely know: the domain name is a really stupid place to base trust. Is there any interest in fixing this fundamental issue? Cheers, Ben. -- >>> ApacheCon Europe<<< http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 jwkckid1@ix.netcom.com Fri Jul 1 04:30:13 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j618UC5j011936 for ; Fri, 1 Jul 2005 04:30:12 -0400 (EDT) Received: from pop04.mail.atl.earthlink.net (pop04.mail.atl.earthlink.net [207.69.200.28])j618U2Fm005765 for ; Fri, 1 Jul 2005 04:30:02 -0400 (EDT) Received: from 1cust35.tnt37.dfw9.da.uu.net ([67.234.20.35] helo=ix.netcom.com) by pop04.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1DoGuM-0000AV-00; Fri, 01 Jul 2005 04:29:58 -0400 Message-ID: <42C518A4.C76D2D6@ix.netcom.com> Date: Fri, 01 Jul 2005 03:19:17 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Ben Laurie Subject: Re: [saag] Fwd: Notification re UTR #36, Security Issues References: <42C3A8EA.9000603@algroup.co.uk> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.593 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.652466 cc: Greg Abbott cc: aba isc list cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 01 Jul 2005 08:30:14 -0000 Ben and all, It may be advisable that the FTC and other EU equivalents should be notified of this so as to get at least a warning more broadly decimated... Ben Laurie wrote: > Paul Hoffman wrote: > >> Due to computer security issues, a set of guidelines is being > >> drafted that can impact the use of future International Domain > >> Names (i.e., http://m¸ller.de/ ) and identifiers. The computer > >> security issues that have arisen involve spoofing of letters or > >> numbers (e.g., in a recent case, unsuspecting users were sending > >> credit card information to "PayPal.com" which was spelled with a > >> capital "I" in place of lowercase "L", because the two are not > >> visibly distinct in some fonts). Similarly Cyrillic or Greek > >> letters could be used in lieu of similar looking Latin letters in > >> domain names. > > I'd note that this first issue is _not_ an IDN issue, but applies to > traditional domain names. This would appear to have rather serious > impact on the DNS, if we decide to take this report seriously (I'm > assuming it includes recommendations that related to I vs. l, since I > have not been able to actually reach the site since I saw this post). > > Of course, what this is really pointing to is what we all surely know: > the domain name is a really stupid place to base trust. Is there any > interest in fixing this fundamental issue? > > Cheers, > > Ben. > > -- > >>> ApacheCon Europe<<< http://www.apachecon.com/ > > http://www.apache-ssl.org/ben.html http://www.thebunker.net/ > > "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 > https://jis.mit.edu/mailman/listinfo/saag Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From James_Hughes@StorageTek.com Fri Jul 8 18:28:26 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j68MSP5j012065 for ; Fri, 8 Jul 2005 18:28:25 -0400 (EDT) Received: from sherman.stortek.com (sherman.stortek.com [129.80.22.146]) j68MSGL8017155 for ; Fri, 8 Jul 2005 18:28:16 -0400 (EDT) Received: from sherman.stortek.com (localhost [127.0.0.1]) by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id j68MSFD4012317 for ; Fri, 8 Jul 2005 16:28:15 -0600 (MDT) Received: from [129.80.46.57] (JimsOfc2.stortek.com [129.80.46.57]) by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id j68MSDDC012301; Fri, 8 Jul 2005 16:28:14 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: james hughes Date: Fri, 8 Jul 2005 18:28:13 -0400 To: saag@mit.edu X-Mailer: Apple Mail (2.730) X-Spam-Score: -1.603 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.724655 cc: james hughes Subject: [saag] 3rd International IEEE Security in Storage Workshop X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 08 Jul 2005 22:28:26 -0000 3rd International IEEE Security in Storage Workshop December 13, 2005 Golden Gate Holiday Inn, San Francisco, California USA Sponsored by the IEEE Computer Society Task Force on Information Assurance (TFIA) Part of the IEEE Information Assurance Activities (IEEEIA) Held In Cooperation and Co-Located With the 4th USENIX Conference on File and Storage Technologies (FAST05) December 14-16, 2005, San Francisco, CA, USA In Cooperation with the IEEE Mass Storage Systems Technical Committee (MSSTC) Description Meeting the challenge to protect stored information critical to individuals, corporations, and governments is made more difficult by the continually changing uses of storage and the exposure of storage media to adverse conditions. Example uses include employment of large shared storage systems for cost reduction and, for convenience, wide use of transiently- connected storage devices offering significant capacities and manifested in many forms, often embedded in mobile devices. Protecting intellectual property, privacy, health records, and military secrets when media or devices are lost, stolen, or captured is critical to information owners. A comprehensive, systems approach to storage security is required for the activities that rely on storage technology to remain or become viable. This workshop serves as an open forum to discuss storage threats, technologies, methodologies and deployment. The workshop seeks submissions from academia and industry presenting novel research on all theoretical and practical aspects of designing, building and managing secure storage systems; possible topics include, but are not limited to the following: - Cryptographic Algorithms for Storage - Cryptanalysis of Systems and Protocols - Key Management for Sector and File based Storage Systems - Balancing Usability, Performance and Security concerns - Unintended Data Recovery - Attacks on Storage Area Networks and Storage - Insider Attack Countermeasures - Security for Mobile Storage - Defining and Defending Trust Boundaries in Storage - Relating Storage Security to Network Security - Database Encryption - Search on Encrypted Information The goal of the workshop is to disseminate new research, and to bring together researchers and practitioners from both governmental and civilian areas. Accepted papers will be published by the IEEE Computer Society Press in the workshop proceedings and become part of the IEEE Digital Library. Workshop Sponsor - Jack Cole (US Army Research Laboratory, USA) Program Chair - James Hughes (StorageTek, USA) Program Committee - Don Beaver (USA) - John Black (University of Colorado, USA) - Randal Burns (Johns Hopkins University, USA) - Ronald Dodge (United States Military Academy, USA) - Kevin Fu (University of Massachusetts Amherst, USA) - Russ Housley (Vigil Security, USA) - Yongdae Kim (University of Minnesota, USA) - Ben Kobler (NASA, USA) - Noboru Kunihiro (University of Electro-Communications, Japan) - Arjen Lenstra (Lucent Technologies' Bell Laboratories and Technische Universiteit Eindhoven, Netherlands) - Fabio Maino (Cisco Systems, USA) - Ethan Miller (University of California, Santa Cruz, USA) - Reagan Moore (University of California, San Diego, USA) - Dalit Naor (IBM Haifa, Israel) - Andrew Odlyzko (University of Minnesota, USA) - Rod Van Meter (Keio University, Japan) - Tom Shrimpton (Portland State, USA) - John Viega (Secure Software, USA) - Erez Zadok (Stony Brook University, USA) - Yuliang Zheng (University of North Carolina, USA) Submissions Papers must begin with the title, authors, affiliations, a short abstract, a list of key words, and an introduction. The introduction should summarize the contributions of the paper at a level appropriate for a non-specialist reader. Papers must be submitted in PDF format less than 4MB in size (final paper has no limit). Email submissions must attach the paper, specify if this is a duplicate work, and be sent to James_Hughes@StorageTek.com Papers should be at most 12 pages in length including the bibliography, figures, and appendices (using 10pt body text and two- column layout). Authors are responsible for obtaining appropriate clearances. Authors of accepted papers will be asked to sign IEEE copyright release forms. Final submissions must be in camera-ready PostScript or PDF. Authors of accepted papers must guarantee that their paper will be presented at the conference. Papers that duplicate work that any of the authors have or will publish elsewhere are acceptable for presentation at the workshop. However, only original papers will be considered for publication in the proceedings. Although full papers are preferred, submissions of extended abstracts describing the final paper will be considered based on merit and assessing the author's ability to complete the paper within the allotted time. Important Dates Paper due: September 1, 2005 Notification of acceptance: October 1, 2005 Workshop paper due: December 1, 2005 Workshop: December 13, 2005 Proceedings paper due: December 20, 2005 Questions should be sent electronically to James_Hughes@StorageTek.com The Call For Papers is also available on the web at http://ieeeia.org/sisw/2005/index.htm http://ieeeia.org/sisw/2005/SISW05CFP.pdf From pekkas@netcore.fi Mon Jul 11 12:36:09 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j6BGa85j029908 for ; Mon, 11 Jul 2005 12:36:08 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1])j6BGZvHN026026 for ; Mon, 11 Jul 2005 12:35:57 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j6BGZud00986; Mon, 11 Jul 2005 19:35:56 +0300 Date: Mon, 11 Jul 2005 19:35:56 +0300 (EEST) From: Pekka Savola To: saag@mit.edu, ipsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.604304 Subject: [saag] Re: I-D ACTION:draft-ietf-v6ops-ipsec-tunnels-00.txt (fwd) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 11 Jul 2005 16:36:09 -0000 FYI, Looks from the security and IPsec perspective in particular would be welcome, so that we got the details right. Please send feedback to v6ops@ops.ietf.org or to me (acting as the editor right now). Thanks! ---------- Forwarded message ---------- Date: Mon, 11 Jul 2005 19:24:07 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-ipsec-tunnels-00.txt On Mon, 11 Jul 2005 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : Using IPsec to Secure IPv6-in-IPv4 Tunnels > Author(s) : P. Savola, et al. > Filename : draft-ietf-v6ops-ipsec-tunnels-00.txt > Pages : 21 > Date : 2005-7-11 > > This document gives guidance on securing manually configured IPv6-in- > IPv4 tunnels using IPsec. No additional protocol extensions are > described beyond those available with the IPsec framework. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipsec-tunnels-00.txt The authors believe that this version addresses all comments sent to date. There has been substantial revision in the draft. Those who previously read it are encouraged to take another look and see if it's better. If you haven't taken a look yet, now would be a good chance. The issue list is at: http://www.netcore.fi/pekkas/ietf/temp/ipsec-tunnels.html There's also a htmlwdiff there. -- 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 m-shimaoka@secom.co.jp Mon Jul 11 21:38:54 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j6C1cp5j003389 for ; Mon, 11 Jul 2005 21:38:51 -0400 (EDT) Received: from ns01.secom.co.jp (ns01.secom.co.jp [61.114.178.247]) j6C1cgvD010726 for ; Mon, 11 Jul 2005 21:38:43 -0400 (EDT) Received: from mldsit02.intra.secom.co.jp ([172.21.1.41]) by ns01.secom.co.jp (8.11.7-20030918/3.7W) with ESMTP id j6C1ccZ28928; Tue, 12 Jul 2005 10:38:38 +0900 (JST) Received: from sectrl.isl.secom.co.jp (localhost [127.0.0.1]) j6C1ccMU015866; Tue, 12 Jul 2005 10:38:38 +0900 (JST) X-Authentication-Warning: mldsit02.intra.secom.co.jp: iscan owned process doing -bs Received: from isis.sp.isl.secom.co.jp (isis.isl.secom.co.jp [10.131.16.23]) by sectrl.isl.secom.co.jp (Postfix) with ESMTP id C91351E72E; Tue, 12 Jul 2005 10:38:37 +0900 (JST) Received: from [127.0.0.1] (jonathan [10.131.128.85] (may be forged)) KAA03887; Tue, 12 Jul 2005 10:38:35 +0900 Date: Tue, 12 Jul 2005 10:38:33 +0900 From: Masaki SHIMAOKA To: saag@mit.edu Sender: m-shimaoka@secom.co.jp Message-Id: <20050712023720.21C4.SHIMAOKA@secom.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21 [ja] X-Spam-Score: -1.951 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000001 Spam-Alum-Time: 0.554863 cc: mpki cc: Nelson Hastings Subject: [saag] Asking to review multi-domain PKI interoperability I-D X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 12 Jul 2005 01:38:54 -0000 Hi all, Nelson and I are developing a memorandum, as an individual I-D, that tries to capture the necessary issues for the deployment of multi-domain PKIs. We would like to ask the SAAG ML to review the I-D as an initial step towards publishing the I-D as an informational RFC or BCP. This I-D appears to be out of scope for the PKIX WG because most of the issues are not technical but operational. However to achieve interoperability across different PKIs, a consensus of the operational issues for multi-domain PKIs that should be considered is needed. This I-D has been developed based on knowledge derived from various PKI interoperability experiences such as Japanese Government PKI and US Federal PKI. Therefore, we hope to publish as an informational RFC or BCP, and when multi-domain PKI interoperability issues crop up the document can provide some advice and guidance. Thanks, -- shima From m-shimaoka@secom.co.jp Mon Jul 11 21:41:24 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j6C1fM5j003419 for ; Mon, 11 Jul 2005 21:41:22 -0400 (EDT) Received: from ns01.secom.co.jp (ns01.secom.co.jp [61.114.178.247]) j6C1fHcE011675 for ; Mon, 11 Jul 2005 21:41:18 -0400 (EDT) Received: from mldsit02.intra.secom.co.jp ([172.21.1.41]) by ns01.secom.co.jp (8.11.7-20030918/3.7W) with ESMTP id j6C1fEZ29136; Tue, 12 Jul 2005 10:41:14 +0900 (JST) Received: from sectrl.isl.secom.co.jp (localhost [127.0.0.1]) j6C1fD0c015990; Tue, 12 Jul 2005 10:41:13 +0900 (JST) X-Authentication-Warning: mldsit02.intra.secom.co.jp: iscan owned process doing -bs Received: from isis.sp.isl.secom.co.jp (isis.isl.secom.co.jp [10.131.16.23]) by sectrl.isl.secom.co.jp (Postfix) with ESMTP id 759CF1E72E; Tue, 12 Jul 2005 10:41:13 +0900 (JST) Received: from [127.0.0.1] (jonathan [10.131.128.85] (may be forged)) KAA03897; Tue, 12 Jul 2005 10:41:13 +0900 Date: Tue, 12 Jul 2005 10:41:10 +0900 From: Masaki SHIMAOKA To: saag@mit.edu Sender: m-shimaoka@secom.co.jp In-Reply-To: <20050712023720.21C4.SHIMAOKA@secom.ne.jp> References: <20050712023720.21C4.SHIMAOKA@secom.ne.jp> Message-Id: <20050712103847.21D5.SHIMAOKA@secom.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21 [ja] X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.558121 cc: mpki cc: Nelson Hastings Subject: [saag] Re: Asking to review multi-domain PKI interoperability I-D X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 12 Jul 2005 01:41:25 -0000 Sorry, you can get our I-D from below: http://www.ietf.org/internet-drafts/draft-shimaoka-multidomain-pki-05.txt On Tue, 12 Jul 2005 10:38:33 +0900 Masaki SHIMAOKA wrote: > Hi all, > > Nelson and I are developing a memorandum, as an individual I-D, that > tries to capture the necessary issues for the deployment of multi-domain > PKIs. We would like to ask the SAAG ML to review the I-D as an initial > step towards publishing the I-D as an informational RFC or BCP. > > This I-D appears to be out of scope for the PKIX WG because most of the > issues are not technical but operational. However to achieve > interoperability across different PKIs, a consensus of the operational > issues for multi-domain PKIs that should be considered is needed. > > This I-D has been developed based on knowledge derived from various PKI > interoperability experiences such as Japanese Government PKI and US > Federal PKI. Therefore, we hope to publish as an informational RFC or > BCP, and when multi-domain PKI interoperability issues crop up the > document can provide some advice and guidance. > > Thanks, > -- shima -- Masaki SHIMAOKA SECOM IS Lab. Core Technology Div. +81 422 76 2105 (4172) From jwkckid1@ix.netcom.com Tue Jul 12 01:55:21 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j6C5tK5j005213 for ; Tue, 12 Jul 2005 01:55:20 -0400 (EDT) Received: from pop06.mail.atl.earthlink.net (pop06.mail.atl.earthlink.net [207.69.200.40])j6C5tBw3001821 for ; Tue, 12 Jul 2005 01:55:12 -0400 (EDT) Received: from 1cust100.tnt37.dfw9.da.uu.net ([67.234.20.100] helo=ix.netcom.com) by pop06.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1DsDjO-0007fa-00; Tue, 12 Jul 2005 01:54:59 -0400 Message-ID: <42D374BB.A48096DB@ix.netcom.com> Date: Tue, 12 Jul 2005 00:43:56 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Masaki SHIMAOKA Subject: Re: [saag] Re: Asking to review multi-domain PKI interoperability I-D References: <20050712023720.21C4.SHIMAOKA@secom.ne.jp> <20050712103847.21D5.SHIMAOKA@secom.ne.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.616193 cc: saag@mit.edu cc: mpki cc: Nelson Hastings X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 12 Jul 2005 05:55:22 -0000 Masaki and all, A couple of questions for now. I will likely have others later... What is the criterion for a definition of "Distinguished Names" as referred to below? Is there any consideration for other interoperability for other in use and trusted PKI certs that are not X.509 based? Masaki SHIMAOKA wrote: > Sorry, you can get our I-D from below: > http://www.ietf.org/internet-drafts/draft-shimaoka-multidomain-pki-05.txt > > On Tue, 12 Jul 2005 10:38:33 +0900 > Masaki SHIMAOKA wrote: > > > Hi all, > > > > Nelson and I are developing a memorandum, as an individual I-D, that > > tries to capture the necessary issues for the deployment of multi-domain > > PKIs. We would like to ask the SAAG ML to review the I-D as an initial > > step towards publishing the I-D as an informational RFC or BCP. > > > > This I-D appears to be out of scope for the PKIX WG because most of the > > issues are not technical but operational. However to achieve > > interoperability across different PKIs, a consensus of the operational > > issues for multi-domain PKIs that should be considered is needed. > > > > This I-D has been developed based on knowledge derived from various PKI > > interoperability experiences such as Japanese Government PKI and US > > Federal PKI. Therefore, we hope to publish as an informational RFC or > > BCP, and when multi-domain PKI interoperability issues crop up the > > document can provide some advice and guidance. > > > > Thanks, > > -- shima > > -- > Masaki SHIMAOKA > SECOM IS Lab. > Core Technology Div. > +81 422 76 2105 (4172) > > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From m-shimaoka@secom.co.jp Tue Jul 12 11:43:58 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j6CFhs5j008872 for ; Tue, 12 Jul 2005 11:43:54 -0400 (EDT) Received: from mx09.ms.so-net.ne.jp (mx09.ms.so-net.ne.jp [202.238.82.9]) j6CFhjiR015010 for ; Tue, 12 Jul 2005 11:43:46 -0400 (EDT) Received: from [127.0.0.1] (pd32dca.tkyoac00.ap.so-net.ne.jp [61.211.45.202]) by mx09.ms.so-net.ne.jp with ESMTP id j6CFha5w025024; Wed, 13 Jul 2005 00:43:37 +0900 (JST) Date: Wed, 13 Jul 2005 00:43:34 +0900 From: Masaki SHIMAOKA To: Jeff Williams Subject: Re[2]: [saag] Re: Asking to review multi-domain PKI interoperability I-D Sender: m-shimaoka@secom.co.jp In-Reply-To: <42D374BB.A48096DB@ix.netcom.com> References: <20050712103847.21D5.SHIMAOKA@secom.ne.jp> <42D374BB.A48096DB@ix.netcom.com> Message-Id: <20050713003859.21FA.SHIMAOKA@secom.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21 [ja] X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.552216 cc: saag@mit.edu cc: mpki cc: Nelson Hastings X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 12 Jul 2005 15:43:58 -0000 Jeff, Thanks for your interesting. Basically we focus on only PKI certs based on X.509 and RFC 3280, because our focused issues are caused by some certificate extensions on X.509 certs. That is, > What is the criterion for a definition of "Distinguished Names" > as referred to below? We have been working under the assumption of X.509 certificate and DN as defined in X.509. And, > Is there any consideration for other interoperability for other > in use and trusted PKI certs that are not X.509 based? Currently there is no consideration for other PKI certs that are not X.509 based. But if we should have considerations for other interoperability issues with other technology, please show us your concerns. If necessary, we may have to consider other interoperability with other PKI certs that are not X.509 based. Anyway, we must clear way firstly for the interoperability between X.509 based PKIs. Thanks, -- shima From jwkckid1@ix.netcom.com Tue Jul 12 20:40:22 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j6D0eL5j012171 for ; Tue, 12 Jul 2005 20:40:21 -0400 (EDT) Received: from pop03.mail.atl.earthlink.net (pop03.mail.atl.earthlink.net [207.69.200.48])j6D0eDCQ028955 for ; Tue, 12 Jul 2005 20:40:13 -0400 (EDT) Received: from 1cust80.tnt37.dfw9.da.uu.net ([67.234.20.80] helo=ix.netcom.com) by pop03.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1DsVIH-0000yF-00; Tue, 12 Jul 2005 20:40:09 -0400 Message-ID: <42D47C70.6BBB8512@ix.netcom.com> Date: Tue, 12 Jul 2005 19:29:06 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Masaki SHIMAOKA Subject: Re: [saag] Re: Asking to review multi-domain PKI interoperability I-D References: <20050712103847.21D5.SHIMAOKA@secom.ne.jp> <42D374BB.A48096DB@ix.netcom.com> <20050713003859.21FA.SHIMAOKA@secom.ne.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.599319 cc: saag@mit.edu cc: mpki cc: Nelson Hastings X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 13 Jul 2005 00:40:23 -0000 Masaki sama and all, The best way for me to respond would be for me to invite you to view this webcast: http://itw.itworld.com/GoNow/a15565a131456a75352868a0 It should give you at least some insight as to bridging the PKI gap. Masaki SHIMAOKA wrote: > Jeff, > > Thanks for your interesting. > > Basically we focus on only PKI certs based on X.509 and RFC 3280, > because our focused issues are caused by some certificate extensions on > X.509 certs. > > That is, > > What is the criterion for a definition of "Distinguished Names" > > as referred to below? > > We have been working under the assumption of X.509 certificate and DN as > defined in X.509. > > And, > > Is there any consideration for other interoperability for other > > in use and trusted PKI certs that are not X.509 based? > Currently there is no consideration for other PKI certs that are not > X.509 based. > But if we should have considerations for other interoperability issues > with other technology, please show us your concerns. > If necessary, we may have to consider other interoperability with other > PKI certs that are not X.509 based. > > Anyway, we must clear way firstly for the interoperability between X.509 > based PKIs. > > Thanks, > -- shima Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From m-shimaoka@secom.co.jp Thu Jul 14 03:45:09 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j6E7j15j023060 for ; Thu, 14 Jul 2005 03:45:02 -0400 (EDT) Received: from ns01.secom.co.jp (ns01.secom.co.jp [61.114.178.247]) j6E7ipob009192 for ; Thu, 14 Jul 2005 03:44:52 -0400 (EDT) Received: from mldsit02.intra.secom.co.jp ([172.21.1.41]) by ns01.secom.co.jp (8.11.7-20030918/3.7W) with ESMTP id j6E7ikZ27790; Thu, 14 Jul 2005 16:44:47 +0900 (JST) Received: from sectrl.isl.secom.co.jp (localhost [127.0.0.1]) j6E7ikZk027319; Thu, 14 Jul 2005 16:44:46 +0900 (JST) X-Authentication-Warning: mldsit02.intra.secom.co.jp: iscan owned process doing -bs Received: from isis.sp.isl.secom.co.jp (isis.isl.secom.co.jp [10.131.16.23]) by sectrl.isl.secom.co.jp (Postfix) with ESMTP id 129FB1E72E; Thu, 14 Jul 2005 16:44:46 +0900 (JST) Received: from [127.0.0.1] (jonathan [10.131.128.85] (may be forged)) QAA11235; Thu, 14 Jul 2005 16:44:45 +0900 Date: Thu, 14 Jul 2005 16:44:45 +0900 From: Masaki SHIMAOKA To: Jeff Williams Subject: Re[2]: [saag] Re: Asking to review multi-domain PKI interoperability I-D Sender: m-shimaoka@secom.co.jp In-Reply-To: <42D47C70.6BBB8512@ix.netcom.com> References: <20050713003859.21FA.SHIMAOKA@secom.ne.jp> <42D47C70.6BBB8512@ix.netcom.com> Message-Id: <20050714120254.224A.SHIMAOKA@secom.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21 [ja] X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.642419 cc: saag@mit.edu cc: mpki cc: Nelson Hastings X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 14 Jul 2005 07:45:10 -0000 Jeff, Thank you for valuable information from another point of view. I guess that you probably want to suggest introducing several technology other than PKI. I can understand such suggestion. Of course I know there are many technologies other than PKI in the world. And I do not contradict them, we should be able to choose several technologies. But, as the same as one of them, PKI also should be improved to enhance our convenience. So we propose to make a consensus for multi-domain PKI interoperability, as PKI engineer. It is just same as an improvement for other technologies. The focus of the I-D is to help PKI engineers trying to implement/deploy multi-domain PKI. The I-D should keep to focus on helping PKI engineers, though I do not contradict other alternative technologies. Thanks, -- shima On Tue, 12 Jul 2005 19:29:06 -0700 Jeff Williams wrote: > Masaki sama and all, > > The best way for me to respond would be for me to invite you to > view this webcast: > http://itw.itworld.com/GoNow/a15565a131456a75352868a0 > It should give you at least some insight as to bridging the PKI > gap. > > Masaki SHIMAOKA wrote: > > > Jeff, > > > > Thanks for your interesting. > > > > Basically we focus on only PKI certs based on X.509 and RFC 3280, > > because our focused issues are caused by some certificate extensions on > > X.509 certs. > > > > That is, > > > What is the criterion for a definition of "Distinguished Names" > > > as referred to below? > > > > We have been working under the assumption of X.509 certificate and DN as > > defined in X.509. > > > > And, > > > Is there any consideration for other interoperability for other > > > in use and trusted PKI certs that are not X.509 based? > > Currently there is no consideration for other PKI certs that are not > > X.509 based. > > But if we should have considerations for other interoperability issues > > with other technology, please show us your concerns. > > If necessary, we may have to consider other interoperability with other > > PKI certs that are not X.509 based. > > > > Anyway, we must clear way firstly for the interoperability between X.509 > > based PKIs. > > > > Thanks, > > -- shima > > Regards, > > -- > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) > "Be precise in the use of words and expect precision from others" - > Pierre Abelard > > "If the probability be called P; the injury, L; and the burden, B; > liability depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =============================================================== > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security > IDNS. div. of Information Network Eng. INEG. INC. > E-Mail jwkckid1@ix.netcom.com > Registered Email addr with the USPS > Contact Number: 214-244-4827 > -- Masaki SHIMAOKA SECOM IS Lab. Core Technology Div. +81 422 76 2105 (4172) From jsalowey@cisco.com Mon Aug 1 06:31:49 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j71AVm5j005848 for ; Mon, 1 Aug 2005 06:31:48 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) j71AVebX003400 for ; Mon, 1 Aug 2005 06:31:40 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 01 Aug 2005 03:31:40 -0700 X-IronPort-AV: i="3.95,156,1120460400"; d="scan'208"; a="327804218:sNHT29667988" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j71AVdJL002047 for ; Mon, 1 Aug 2005 03:31:39 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 1 Aug 2005 03:36:17 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905A0D293@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secmech BOF Tuesday 10:30 Thread-Index: AcWWhDL+i/y3ahXXQ3a2VvJa4T0v6Q== From: "Salowey, Joe" To: X-Spam-Score: -2.601 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.619443 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id j71AVm5j005848 Subject: [saag] secmech BOF Tuesday 10:30 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 01 Aug 2005 10:31:50 -0000 This is a reminder that the secmech BOF will be held Tuesday 1030-1230 Morning Session II (Room 342) Description of the BOF agenda is provided below: CHAIR: Joe Salowey DESCRIPTION: There exists a disconnect between the IETF's security frameworks. Although these frameworks have very similar goals, the set of mechanisms available depends upon the choice of framework. There are a number of issues that make a compelling case for converging the way we develop mechanisms for these frameworks. - The actual mechanisms in each of these frameworks have very similar goals of authentication and establishing a cryptographic context. In many cases frameworks are developing new functionality that bring them closer together. An example of this is the addition of a PRF API to access key material from GSS-API. - There is a desire to standardized EAP mechanisms and there currently is no working group with this on its charter. It would be desirable to work on this in conjunction with other efforts in the security area including work on GSS-API enhancements in KITTEN working group and SASL enhancements in the SASL working group. - There is pressure to adopt a particular framework because of the set of mechanisms available not because of the capabilities and upper-layer interface of the framework. This recently was an issue with ISMS, but there has also been a desire to use EAP to authenticate other applications. We should be in a situation where the choice on mechanism was dictated by the deployment requirements and the choice of framework dictated by protocol design and implementation simplicity. - There is a duplication of effort in the development of security mechanism that support similar credential types and infrastructures. This is problematic because the development of security mechanisms is both difficult and time consuming. It would be good to leverage the work and expertise required for developing a mechanism across all the frameworks. - Often the cost of deploying a security mechanism is in the infrastructure and not the implementation of the mechanism itself. There limited set of mechanisms available to particular frameworks makes the coordination and administration of security between applications that use different frameworks more difficult. The first tasks of a SECMECH working group would be to document a set of evaluation criteria/guidelines explaining what standards-track security mechanisms need to do and how we will evaluate them and to document how we're going to go about specifying a security mechanism for use in the frameworks that are in scope. The working group would also be chartered to define a set of standards track mechanisms. The mechanism work would complete after the first two tasks have completed. Discussion List: General Discussion: secmech@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/secmech Archive: http://www.ietf.org/mail-archive/web/secmech/index.html AGENDA: Generaly Usable Authentication Mechanism (GUAM) (20min) EAP methods (20 min) GSS-API framework (20 min) Charter Discussion (1 hr) From jaltman@columbia.edu Thu Aug 4 04:39:32 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j748dV5j027745 for ; Thu, 4 Aug 2005 04:39:31 -0400 (EDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) j748dSMu021831 for ; Thu, 4 Aug 2005 04:39:28 -0400 (EDT) Received: from [86.255.24.98] (open-24-98.ietf63.ietf.org [86.255.24.98]) (user=jaltman mech=PLAIN bits=0)j748dQWH017505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 4 Aug 2005 04:39:27 -0400 (EDT) Message-ID: <42F1D464.8080306@columbia.edu> Date: Thu, 04 Aug 2005 10:40:04 +0200 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: saag@mit.edu X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020800060604030105070708" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: -2.601 X-Spam-Flag: NO Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.895488 Subject: [saag] [Fwd: Summary of IETF63 Kitten meeting] X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Aug 2005 08:39:33 -0000 This is a cryptographically signed message in MIME format. --------------ms020800060604030105070708 Content-Type: multipart/mixed; boundary="------------050203000007070606080800" This is a multi-part message in MIME format. --------------050203000007070606080800 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------050203000007070606080800 Content-Type: message/rfc822; name="Summary of IETF63 Kitten meeting" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Summary of IETF63 Kitten meeting" Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by tepin.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j73H32xR022593 for ; Wed, 3 Aug 2005 13:03:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0MdV-0002L4-Eb; Wed, 03 Aug 2005 13:02:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0MdI-0002Kl-FW for kitten@megatron.ietf.org; Wed, 03 Aug 2005 13:02:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01117 for ; Wed, 3 Aug 2005 13:02:17 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0NA0-0002BJ-Ar for kitten@ietf.org; Wed, 03 Aug 2005 13:36:09 -0400 Received: from [86.255.24.98] (open-24-98.ietf63.ietf.org [86.255.24.98]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j73H2952002898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Aug 2005 13:02:11 -0400 (EDT) Message-ID: <42F0F8B6.9060107@columbia.edu> Date: Wed, 03 Aug 2005 19:02:46 +0200 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kitten , housley@vigilsec.com, hartmans-ietf@mit.edu X-Enigmail-Version: 0.92.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.28.169 X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0 () X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: Subject: Summary of IETF63 Kitten meeting X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1438548451==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1438548451== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020603040309030906030206" This is a cryptographically signed message in MIME format. --------------ms020603040309030906030206 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The Kitten working group met at IETF63 in one of the new style rooms. We really lucked out because the room contained at least three mobile microphones that were handed out to the audience. It enabled realtime discussions in a much more flexible format. We would like to see more of this at future IETF meetings. More mobile mics the better. Summarized document status: * PRF API extension for GSS draft -05 submitted Addresses issues raised during the most recent WGLC. Will be submitted for a short WGLC next week * PRF API for Kerberos 5 GSS draft -04 passed WGLC Being held until the generic PRF extension document passes WGLC * Corrections and Updates of GSS-API Java Bindings The existing draft contains a list of changes from RFC 2853. These changes were the result of the Java Community Process making changes after the RFC was finished. The JCP is what was implemented. The IETF is effectively rubber stamping these changes as no one implements the RFC. It has been made clear to Sun that for current work the JCP cannot make changes after the documents pass last call. A new draft will be submitted shortly that is 2853 with all of the changes applied. * C# Bindings Since IETF62 consensus was reached to split the C# and Java Bindings into separate documents. A new draft providing a full C# binding based upon RFC 2853 will be published next week. * Desired Enhancements to GSS Naming An informational draft providing scope for the naming problems the working group will solve. All sections but number 7 appear to be ready for WGLC. The chair wishes to expand the description of the credential selection problem described by section 7 before it moves forward. * GSS-API Naming Extensions Draft -00 submitted in May but has not received discussion on the mailing list. * Clarifications to GSSAPI v2 Update 1 No draft yet published and the milestone has been missed Previous volunteers to work on this draft have withdrawn. Technical Discussions: GSS-API Naming Extensions draft-ietf-kitten-gssapi-naming-exts-00.txt The working group reviewed the contents of the draft for the purpose of boot strapping discussion as no one had read it before the meeting. The draft has a summary of the problems caused by the limited naming capabilities of GSS import and export name when attempting to use the authenticated name for the purpose of constructing ACLs. This is followed by five sections describing how to extend GSS names with name attributes including sections on how to use pkix attributes and kerberos authorization data. The details are very incomplete and need significant review. We especially need volunteers from the pkix community to assist in this effort. The document describes a proposed abstract api plus C and java language bindings. There is also an IANA considerations. * use of names on ACLs * the need for including critical bit on attributes. This is expected to be easy for PKIX but it is not authenticated. * corrections to the use of kerberos cross realm transit paths. cross realm transit path lists are not ordered. they only provide a list of the realms that were crossed. * the current draft's description of how to reference x.509 trust paths is very incomplete. The full path from the trust anchor must be specified. * Inclusion of PKIX proxy certificates must be specified * Must ensure that the EKU OID is used as part of PKIX names * There is concern that naming is an extremely broad and highly complex problem. Can it be done in a simple generic manner? * The inquire function scares many people. * name attributes are being treated as tagged blobs. This results in problems both with how to represent dependencies between blobs and how to handle in a generic manner how to extract sub-parts of a blob. * there is a concern with how we can successfully compare names when there are arbitrary sets of name attributes. What is the canonical name? Part of the justification for this work is because there is not always a canonical name that is static for all time. * there needs to be a means of limiting the credentials provided to an application based upon the needs of the application and the qualities the credentials support. * Denis Pikas wrote for CAT a draft to describe how to represent group membership. It can be found via google. The wg should review: draft-ietf-cat-xgssapi-acc-cntrl-03.txt * Review closely the saml attribute work * There is a desire to support negative attributes. In order to do so there must be some means of indicating that for a given set of positive and negative ACLs that all of the negative ACLs have been included and none have been removed. The wg ran out of time. Clearly more discussion is required on the list. Please read the draft. Technical Discussion: Moving RFC2743 and RFC2744 to Draft Our AD, Sam Hartman, requested that the WG consider the steps necessary to move RFCs 2743 and 2744 from Proposed to Draft. The wg discussed the scope of interoperability testing at both the wire and language layers. The wg intends to design a test matrix that is rough grained across implementation of features. Nico Williams will ask for assistance within Sun Microsystems for assistance to the chair in putting together the test matrix. The WG will look at gssmonger as a source of tests. Technical Discussion: Review ML archives to find content for 'Clarifications to GSSAPIv2' The wg ran out of time to discuss this topic. The chair is going to ask specific people for assistance with this task. If this milestone is not being bet the wg will have to stop working on other efforts people care a great deal about. --------------ms020603040309030906030206 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwODAzMTcwMjQ2WjAjBgkqhkiG9w0BCQQxFgQUusKM7sfXF8Sg9vbXCaoPIlnoofAw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAod94W+FyHL8Fvg8ponYmC2lCk63IfkdDUnxl08Zk kzFb+kkouv3Dlf6eMrsqSDe6MMNGHvkgiy+17I8/8DMOmEOXamgIumSszefml4e+ec7EQvHE KmeYgojNgYZVpCxphwWsvOuU6A4851V4lMRWjeZ/EnlMNr4qpyILmLJM440TF0kS3rIkERLJ gvpbCK9m3ZmRf9frQsZJCEJUoDhHxc2pPzIRrHFXv1WmucqJjtHzIth1UPArGuuIo9+8Iaq8 8ZwRvZtzw2z8TE20i+4CevIq88tziJsvjNfSryuhT7eAfhVJQ8tqeSlPNJlJRBkmjn82OKIt Qld6w0HHctFmvwAAAAAAAA== --------------ms020603040309030906030206-- --===============1438548451== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1438548451==-- --------------050203000007070606080800-- --------------ms020800060604030105070708 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwODA0MDg0MDA0WjAjBgkqhkiG9w0BCQQxFgQUk5f+krn4WVVkh3cJX6wsCPnabt0w UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAKqGBly56a08uOBvB8X4BWGR1P9LJcSWmmwAPRtJ6 fDx9d88aDjQLpJe3k6Uu0mIWyG4GA7ZJ+VM/cy44fFaJM2PqE8Rg96mjs/xxZ0mqACUdQM43 4hVg/+5oTEvJk27tpSRSlRiiEmD0O5pwxRt8pxzaXFMYbaOzwFOJn9m93r/j0f58mwoe1S2R ep5f2nNRlHh8vIlcSF2jz9dbM2edGhf7EeMlO/CNESwtd88u35nbaaLojLkJII2L0oHgv2Hy D2ALKpXi7lquDT5haioZveH4OWrBoiYZ8cAXrkF/tex+6Ll7UfrsZ7eM3UlnhnhFzyI1yCSs jY+8gKsnstk0lgAAAAAAAA== --------------ms020800060604030105070708-- From pekka.nikander@nomadiclab.com Thu Aug 4 04:54:30 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j748sT5j027871 for ; Thu, 4 Aug 2005 04:54:29 -0400 (EDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) j748sKMu016082; Thu, 4 Aug 2005 04:54:20 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 2457C212C72; Thu, 4 Aug 2005 11:54:19 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Thu, 4 Aug 2005 10:54:21 +0200 To: Sam Hartman , Russ Housley X-Mailer: Apple Mail (2.733) X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.568326 cc: momipriv@lacnic.net cc: James Kempf cc: saag@mit.edu Subject: [saag] Brief ALIEN BoF report X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Aug 2005 08:54:30 -0000 This is a brief report from the Wednesday ALIEN BoF for today's SAAG session. The ALIEN (Anonymous Identifiers) BoF discussed privacy, focusing on making various identifiers throughout the protocol stack unlinkable, thereby achieving some level of anonymity or pseudonymity. The result from the discussion was that we are not close enough of understanding the threat model and the exact problem we want to solve to consider forming a Working Group. However, the feeling of the room was that this is an important problem and worth IETF/IRTF attention. The likely next steps are writing a concrete proposal for an IRTF Research Group. Some people were also interested in organising a workshop on the topic. There was a proposal was to have an IAB workshop, but at this time it is completely unclear whether the workshop should be an IAB one or, perhaps more likely, a separate workshop to kick start the research group. One of the first working items for the research group, probably to be discussed also in the workshop, is the understand better the threat model, exact technical problems, and the requirements from those people that need the functionality. --Pekka From warlord@MIT.EDU Thu Aug 4 04:58:55 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j748ws5j027941 for ; Thu, 4 Aug 2005 04:58:54 -0400 (EDT) Received: from cliodev.pgp.com (open-26-4.ietf63.ietf.org [86.255.26.4]) j748wjAP014317 for ; Thu, 4 Aug 2005 04:58:46 -0400 (EDT) Received: from cliodev.pgp.com (cliodev.pgp.com [127.0.0.1]) by cliodev.pgp.com (8.13.1/8.13.1) with ESMTP id j748wjx2026785 for ; Thu, 4 Aug 2005 10:58:45 +0200 Received: (from warlord@localhost) by cliodev.pgp.com (8.13.1/8.13.1/Submit) id j748wjIN026782; Thu, 4 Aug 2005 10:58:45 +0200 X-Authentication-Warning: cliodev.pgp.com: warlord set sender to warlord@MIT.EDU using -f From: Derek Atkins To: saag@MIT.EDU User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) Date: Thu, 04 Aug 2005 10:58:45 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -2.099 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.675472 Subject: [saag] Status of OpenPGP at IETF-63 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Aug 2005 08:58:56 -0000 --=-=-= Attached are the draft minutes for the OpenPGP meeting. In short: 1) 2440bis should go to WGLC later this month 2) new milestones were proposed by the chair and no objections noted 3) there appears to be interest in adopting new work: the message-header -derek --=-=-= Content-Disposition: attachment; filename=Minutes-63.txt Content-Description: draft minutes AGENDA -- -- Introduction and Agenda Bashing No changes -- 2440 bis status - In "pentultimate last call" for some time (over a year) - now only doing tweaks to the document. - If you want changes in wording - need to be compatable and suggest text. - Only open issue is David Shaw's BNF request for literal+literal. No reason not to include David Shaw's request, but not in draft 14. Should go into 15 - Run last call and finish this document - Use difference documents for new work - downside is that not everything will be in a small number of documents. Good news is that will have a fixed definitive document -- 2440 next steps - Go to Last call. finish by end of August - Try for a bake off? try for Draft Standard. (early in '06) - update milestones - proposal given. - Draft standard would be tried for 6 months after IESG approval. - New Life - New documents not hit 2440bis. - -- Proposed Milestones - No Objections --- Message Header - draft-josefsson-openpgp-mailnews-header-01.txt - standardize some X- headers for PGP. - Lookup URL and key id of a sender - simplified original by dropping some unnecessary data. - key id - longer fingerprint - url to key - What is the problem to be solved? - Not completely clear - invent header that could be used programatically to lookup key and keyid of sender - Manual cut & paste? - request for additinoal current usage of old headers for inclusion in the doument. - Open Issuses: - Add token to state strong preference for reciving PGP and potentially the PGP format to be sent. - IETF process restricted to MIME? - place same info into a packet? - Keyserver field? - unsure of what this would be really for. Next expansion of the idea. - BNF problems on the draft need corrections. Open MIKE JON - Supports idea of draft - supports "supports token" - PGP has a similar item already used. used with different values for different reading devices. - Wants support to plain inline text - kill mime and only use plain text as a personal preference. - response - Need additional proposals to solve some of the problems? JON - display problems not format issues - Don't ban text only w/o mime wrappers. 8-bit character set problems with servers - Vigourous dispute on issues with character sets. Thomas ? - two formats - with and w/o tag - please elimiate the tag version. ??? - Please add finger print header - used for validation. - possible support already? JON - KeyID is a trucated fingerprint - allow for longer id to get fuller fingerprint w/o much additional parsing. - -00 to -01 allowed for longer KeyID from a fixed length. --- Open Discussion - Meeting closed. --=-=-= -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant --=-=-=-- From ldondeti@qualcomm.com Thu Aug 4 05:14:23 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j749EM5j028074 for ; Thu, 4 Aug 2005 05:14:22 -0400 (EDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) j749ECAP013292 for ; Thu, 4 Aug 2005 05:14:13 -0400 (EDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) j749EAsa004307 for ; Thu, 4 Aug 2005 02:14:10 -0700 (PDT) Received: from [10.50.68.206] (qconnect-10-50-68-206.qualcomm.com [10.50.68.206])j749E6ic003904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 4 Aug 2005 02:14:08 -0700 (PDT) Message-ID: <42F1DC5D.4070707@qualcomm.com> Date: Thu, 04 Aug 2005 11:14:05 +0200 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: saag@mit.edu Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.618957 Subject: [saag] [Fwd: [MSEC] MSEC@IETF-63 meeting summary and draft minutes.] X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: ldondeti@qualcomm.com List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Aug 2005 09:14:24 -0000 -------- Original Message -------- Subject: [MSEC] MSEC@IETF-63 meeting summary and draft minutes. Date: Thu, 04 Aug 2005 11:09:48 +0200 From: Lakshminath Dondeti Reply-To: ldondeti@qualcomm.com Organization: Qualcomm To: msec@securemulticast.org CC: hartmans-ietf@mit.edu, Russ Housley Draft minutes: http://securemulticast.org/IETF-63/IETF63-minutes-draft.htm Summary: Two MSEC documents have been published as informational RFCs between Minneapolis and Paris (RFC 4046 and RFC 4082). Three more are in RFC Ed queue (1 added to the queue) Three more are in IESG review (working on revisions from there) In Minneapolis we got an action item from Russ to work on MSEC extensions to IPsec. Brian Weis, George Gross and Dragan Ignjatic wrote a draft. The chair will distribute it to the IPSEC WG list for wider review. (Action item 1) That draft and several other MSEC drafts were presented at the meeting. We note that there are several MIKEY related drafts in MSEC now (4 + the RFC), so an action item might be to write an umbrella document to explain how they are related to each other. Or better yet, write a roadmap document for all MSEC documents. This is to be discussed on the list. (Action Item 2) MIKEY-RSA-R draft to be circulated to MMUSIC for their review. (Action Item 3) MSEC milestones have been updated and will be submitted after the meeting. (Action Item 4) MSEC WG was asked to review an RMT-TESLA proposal. There was a question as to where that work belongs. The guidance is that it doesn't matter where the document is homed, as long it goes through an RMT and MSEC WGLCs. IPDVB group asked MSEC to review their use of the GSAKMP key management protocol. It appears that that work may have other things to do before tackling this particular issue (details of it are going to be covered by Steve Bellovin). First up is security requirements and MSEC will do a review when asked. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From kent@bbn.com Thu Aug 4 05:39:37 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j749da5j028245 for ; Thu, 4 Aug 2005 05:39:37 -0400 (EDT) Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) j749dTAP023206 for ; Thu, 4 Aug 2005 05:39:30 -0400 (EDT) Received: from [86.255.25.238] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j749dRDd003552 for ; Thu, 4 Aug 2005 05:39:28 -0400 (EDT) Mime-Version: 1.0 Message-Id: Date: Thu, 4 Aug 2005 05:39:17 -0400 To: saag@mit.edu From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.581619 Subject: [saag] PKIX WG meeting summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Aug 2005 09:39:38 -0000 Draft meeting minutes have been distributed to the list. Two new RFCs (PK Algorithms and Permanent Identifier) have been issued since the last meeting. Four additional documents have been approved by the IESG and are in the RFC editor's queue (certificate path building, warranty extension, 2510bis and 2511bis). Three documents are being reviewed by the ADs (AC policies, CertStire HTTP, and 3770bis). CRL AIA is in IESG last call. WG last call for SIM will be initiated after this IETF meeting. More detailed discussions of 3280bis and SCVP will follow. We expect to enter into last call on the SIM draft next week. The two major documents discussed at this meeting were 3280bis and SCVP. The former is an update of the current cert and CRL profile, the latter is a protocol to support delegated cert path construction and validation, e.g., for thin clients. Both documents have undergone a number of revisions, and both appear to be close to completion. However both still require some revisions. There has been considerable discussion on the list and there was an "issues" presentation for each of these documents. As a result of the meeting, the authors agreed to revisit some details of each document and publish a next draft of each. An individual draft on representation of DNS SRV RR query strings in certs was put forth and the WG has agreed to adopt it as a WG item. The meeting concluded with brief liaison presentations on an ETSI digital signature document and on the W3C XKMS specification. From jsalowey@cisco.com Thu Aug 4 05:48:55 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j749ms5j028329 for ; Thu, 4 Aug 2005 05:48:54 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) j749mjAP007866 for ; Thu, 4 Aug 2005 05:48:45 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 04 Aug 2005 02:48:45 -0700 X-IronPort-AV: i="3.95,166,1120460400"; d="scan'208"; a="328903833:sNHT30467964" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j749mgoo005472 for ; Thu, 4 Aug 2005 02:48:43 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 4 Aug 2005 02:53:22 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905A0DD95@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SECMECH] Summary of IETF63 secmech BOF Thread-Index: AcWYxiBnZfcMIZFrSQycZGFlV0DksgAE3REg From: "Salowey, Joe" To: X-Spam-Score: -2.601 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.616895 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id j749ms5j028329 Subject: [saag] FW: [SECMECH] Summary of IETF63 secmech BOF X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Aug 2005 09:48:55 -0000 > -----Original Message----- > From: Salowey, Joe > Sent: Thursday, August 04, 2005 12:33 AM > To: secmech@ietf.org > Cc: Russ Housley > Subject: [SECMECH] Summary of IETF63 secmech BOF > > The secmech BOF met on Tuesday morning. We had discussion on > the standardization of EAP methods and on unifying GSS-API, > SASL and EAP mechanism development. > > We had a discussion on the status and history of EAP method > development, which has largely happened outside the IETF. > This may lead to a situation where network access interfaces > are less open and interoperable than perhaps desired. A > concern was also raised that if standards work is started in > this space, it may not be good to gate this on EAP, GSS-API, > and SASL mechanism development unification. A small set > (1-3) of EAP mechanism types should be selected for > standardization based on requirements from IETF and external SDO's. > > The discussion of EAP, SASL, and GSS-API mechanism > development unification. There was discussion on several > approaches to unifying mechanism development. There was some > discussion on how closely EAP needs to be tied in with AAA > requirements. There was discussion of bridging vs. alternate > approaches to mechanism development. There was no clear > preference so more discussion on the list is necessary. > > The basic results of the BOF were as follows: > > 1. There was rough consensus that EAP method standardization > is important 2. Most people didn't care where the work was > done, but there was a preference for doing the work in the > security area. > 3. There was rough consensus that unifying authentication > mechanism development would be good. > 4. The current proposals for mechanism development > unification need to be more concrete. > 5. There was light interest in actually authoring and review > drafts in the unifying authentication mechanism area. > > Next Steps / Action Items > -------------------------- > 1. Collect the requirements we have for EAP methods and > select a (1 - 3) types of mechanisms to support. > 2. Better define the GUAM proposal and see if there is more > interest in a more focused proposal. > 3. Submit a charter for a working group if enough document > authors and reviewers can be found in the respective areas. > > _______________________________________________ > SECMECH mailing list > SECMECH@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/secmech > From gregory-ietf@earthlink.net Thu Aug 4 05:59:20 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j749xJ5j028452 for ; Thu, 4 Aug 2005 05:59:19 -0400 (EDT) Received: from smtpauth01.mail.atl.earthlink.net (smtpauth01.mail.atl.earthlink.net [209.86.89.61])j749xFAP022747; Thu, 4 Aug 2005 05:59:15 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=EZY9mFmXPAGz9ZHBBwA9o8/qYtABfMSsW+3RMRAPAanDu0y6eeUwwuft0ouCD5Q4; h=Received:Message-Id:X-Sender:X-Mailer:Date:To:From:Subject:Mime-Version:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [86.255.31.55] (helo=gregory-lt.earthlink.net) (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1E0cVO-0003xb-Q9; Thu, 04 Aug 2005 05:59:15 -0400 Message-Id: <6.1.2.0.0.20050804021249.06639540@popd.ix.netcom.com> X-Sender: gregory-ietf@earthlink.net@mail.earthlink.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 04 Aug 2005 02:59:11 -0700 To: housley@vigilsec.com, hartmans-ietf@mit.edu, pki4ipsec@icsalabs.com, saag@mit.edu From: Gregory M Lebovitz Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: bb75549d41bf6763a56c75a03b4135ad4d2b10475b571120d133a2cf85d063db701d50021d5d83e5b9fdf044f9081595350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 86.255.31.55 X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.590420 Subject: [saag] Status of pki4ipsec, ietf63 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Aug 2005 09:59:21 -0000 ==== Summary of pki4ipsec @ ietf63 ==== - draft-ietf-pki4ipsec-ikecert-profile-05.txt - was posted to shadow site (www.icsalabs.com/pki4ipsec) and submitted to editor, but not yet ID posted officially. Minor changes, include PAD link to 2401bis. - Small issue around EKU. Proposal approved by room and since posted to list. Includes deprecating 3 old EKU OIDs and creating one new EKU OID for ipsec/ike (done). Will make this change and re-publish. - Strong hum to move updated doc to WG last call. No contradictions. Taking it to list - draft-ietf-pki4ipsec-mgmt-profile-rqts-03.txt - member brought up a new use case that would dramatically change the base architecture agreed upon years ago. Idea that user/ID database is the center of the architecture, and PKI system gets bolted onto that vs. current idea of a VPN system of functions which interacts with a PKI system of functions. use case is valid - has already been summarized to list. will discuss on list and figure out how it affects our doc. May punt on the use case. TBD on list. - Re-charter - unanimous hum to REMOVE the 3rd charter item, a profile of CMC per the mgmt-profile-rqts ID - will take it to the list for confirmation. ==== ACTION ITEMS: ==== DONE - Russ to create new OID DONE - russ to propose new text to list DONE - gregory to post WG Last Call staw poll results to list, and ask list to weigh in - Stefan/Russ/Brian K - solve text on EKU. - Brian K - post ...profile-06.txt as ID - gregory - WG Last call on profile-06.txt DONE - Stefan to post new use case for mgmt-profile-rqts ID - List - decide how to handle Stefan's new use case DONE - Gregory - post charter change (remove item to create CMC profile) to list for straw poll. +++++++++++++++++++++++++ IETF-related email from Gregory M. Lebovitz Juniper Networks W - +01 (1) 408 543 8002 From stephen.farrell@cs.tcd.ie Thu Aug 4 05:59:47 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j749xk5j028475 for ; Thu, 4 Aug 2005 05:59:46 -0400 (EDT) Received: from pollux.ietf63.ietf.org (pollux.ietf63.ietf.org [86.255.2.7]) j749xcAP023541 for ; Thu, 4 Aug 2005 05:59:39 -0400 (EDT) Received: from [127.0.0.1] (open-25-42.ietf63.ietf.org [86.255.25.42]) by pollux.ietf63.ietf.org (Postfix) with ESMTP id 6558437 for ; Thu, 4 Aug 2005 02:59:38 -0700 (PDT) Message-ID: <42F1E871.1090901@cs.tcd.ie> Date: Thu, 04 Aug 2005 11:05:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: saag@mit.edu Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.413 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.566530 Subject: [saag] summary of sacred WG X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Aug 2005 09:59:48 -0000 Although sacred has completed all its chartered milestones, the results were somewhat unsatisfactory since the WG chose not to adopt a strong password scheme (EKE, SPEKE, etc.). There is now a possibility that some relevant IPR positions may have changed, so the WG met to explore this. We had an overview presentation from Radia, then presentations about PAKE (from Lucent), SPEKE (from Phoenix) and about a new strong password scheme called OPAKE (from Docomo). There was interest in the new OPAKE scheme, but it was felt that this was simply too new to be adopted as yet. There was interest in exploring use of PAKE and/or (to a lesser extent according to humming) SPEKE. Although not dealt with in detail there was also interest in exploring use of SRP and EKE. Igor Feinberg (Lucent) and Robert Mol (Phoenix) took actions to calrify their IPR positions by the end of the month. (Details on that will be in the minutes.) There was also interest in moving any new protocol from BEEP to HTTP, but only if a strong password scheme is adopted. Once the Lucent and Phoenix actions are done, then we will have a list discussion to determine whether there is WG concensus to re-do the sacred protocol to use one or more strong paasword schemes. Stephen. From jari.arkko@piuha.net Thu Aug 4 06:02:19 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j74A2I5j028534 for ; Thu, 4 Aug 2005 06:02:18 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) j74A2AAP028390 for ; Thu, 4 Aug 2005 06:02:11 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id E1D3889854; Thu, 4 Aug 2005 13:02:09 +0300 (EEST) Message-ID: <42F1E7AE.4050805@piuha.net> Date: Thu, 04 Aug 2005 13:02:22 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: saag@mit.edu, MOBIKE Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.591359 cc: Paul Hoffman Subject: [saag] MOBIKE summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Aug 2005 10:02:20 -0000 The MOBIKE WG is working towards its goal of enabling movements and simultaneous connectivity in IKEv2-based VPNs. In May, we reached an agreement on all of our major design decisions, and in June the protocol specification came out as a WG draft. We received a number of in-depth reviews prior to IETF-63, and much of the feedback was reflected in a revised specification that come out in July. We spent most of the time in this week's meeting to discuss the technical issues that had not yet been addressed. It seemed that we have consensus on the way forward for most of the simple issues. One big issue still remains to be solved, relating to one detail around MOBIKE's interaction with NAT traversal. (We were told that this issue can affect as many as 20 lines of code, so the debate will no doubt continue on the list.) We expect the MOBIKE protocol specification to go to WGLC in September, and be sent to the IESG prior to IETF-64. The next weeks will be spent on the list to confirm the consensus from the meeting, to close the remaining issues, address some new reviews that we received and for additional review. Reviewers for this protocol are also sought from the rest of the SEC area. If you want to have an impact on the protocol, this would be a good time to read the spec. Separately, our protocol design considerations document is tracking the discussion, and will come out a little behind the protocol itself. We expect that it is done before the next IETF as well. We also have gotten our first inter-WG dependency for MOBIKE within the IETF, and received a liason statement from the 3GPP2 stating an interest in our solution. From lha@kth.se Thu Aug 4 06:35:39 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j74AZc5j028897 for ; Thu, 4 Aug 2005 06:35:38 -0400 (EDT) Received: from nutcracker.it.su.se (open-31-10.ietf63.ietf.org [86.255.31.10]) j74AZQMu023275; Thu, 4 Aug 2005 06:35:26 -0400 (EDT) Received: by nutcracker.it.su.se (Postfix, from userid 913) id D7C1234C17E; Thu, 4 Aug 2005 12:31:56 +0200 (CEST) To: From: =?iso-8859-1?q?Love_H=F6rnquist_=C5strand?= Date: Thu, 04 Aug 2005 12:31:53 +0200 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Spam-Score: -2.352 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.695139 cc: Sam Hartman cc: saag@mit.edu Subject: [saag] BTNS WG meeting summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Aug 2005 10:35:40 -0000 --=-=-= The BTNS working group met at IETF63 in Paris this morning, Summery of document status ========================== * BTNS Problem and Applicability statement draft -00. The editor, Joe Touch, have received comments from 2 persons. One person at the meeting promised send comments on structure. Joe will update the document on a couple of weeks after receiving the comments and submit it again. The current belief is that it requires one (or two) more iterations depending on more comments. Decisions made during the meeting ================================= * The group need to support tunnel mode, where the inner address is the same as the other. This is because its the required implementation by other documents. * Will look at the problem using IKE v2 first and then go back and look what modification is needed for IKE v1. Update milestones milestones to the following * WGLC late September/early October for Problem and Applicability Statement * SPD/PAD draft done well before Vancouver meeting Discussion that came up during the meeting ========================================== * The question came up if we should define a X.509 policy for self signed certificates ? Also, if we just should use bare keys without certificates ? * The asymmetric case (BTNS peer to full IKE peer) need to be supported, its part of our chart. * Discuss on internal interface to expose the fact that BTNS/IKE was used or not. Love --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (NetBSD) iQEVAwUAQvHunNo1gLFKFEjAAQKCOgf/fS/Zq3uciW1hysCE+wY+3ezSag6gI3fw qKZ6cfLWf1J6VgfwGl8nO9gvESwR9nU7DNOI8aLU02hw84pPBmsqgjrDoHZ34WNI V5npDoWkFsIkGyZqGvkyxfAFMcePR2kkFrtsJgVZGCjwzR5y9KCl+x2VBsTzL8TI 3FqwBMQQ1iXtMyl43YhCyS65s3SvNaEa4NjwPTUl+Bedm/8aWI327bMIY61aYKgR aWl9ty72vaJo6qfYaN6bWwMr8MpYCnW5pvchS0q73rolhlGs6/LtTtcJOUEUVU0A 9T0RAZt4BLxWqZBVf3VPdPDxBoRwBkAdZK5pULoXzc2BZrVEosftIQ== =LDkZ -----END PGP SIGNATURE----- --=-=-=-- From jhutz@cmu.edu Thu Aug 4 06:52:47 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j74Aqk5j028991 for ; Thu, 4 Aug 2005 06:52:47 -0400 (EDT) Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) j74AqcAP005889; Thu, 4 Aug 2005 06:52:38 -0400 (EDT) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa25712; 4 Aug 2005 6:52 EDT Received: from [10.11.0.207] (concorde301.adptelecom.net [212.180.41.212]) (authenticated bits=0)j74AqXLQ001602 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 4 Aug 2005 06:52:35 -0400 (EDT) Date: Thu, 04 Aug 2005 12:52:29 +0200 From: Jeffrey Hutzelman To: ietf-krb-wg@anl.gov Message-ID: <42C263766FEFB9F25C9EA1CB@bistromath.pc.cs.cmu.edu> Originator-Info: login-token=Mulberry:01wPGhJCpZFpgMPBml82/Rk1dj2E9HJRotZs+J9nE=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (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: 1.206 X-Spam-Level: * (1.206) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.658811 cc: hartmans-ietf@mit.edu cc: saag@mit.edu Subject: [saag] krb-wg summary from IETF 63 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Aug 2005 10:52:48 -0000 Kerberos Working Group - IETF 63 meeting summary - The chairs gave an update of the status of documents which have been sent to the IESG, and of ongoing work: + Kerberos clarifications - published as RFC4120 + The GSSAPI-CFX document - published as RFC4121 + PKINIT - close to done; 2 issues will be discussed today + OCSP-for-PKINIT - done; will be ballotted with PKINIT + RFC1510ter - not much progress + Referrals - authors think it is nearly ready for WGLC + Enctype-Nego - needs updates from last call comments + Set/Change PW - author thinks last issue is resolved - There was a long discussion on ticket #837, related to identifying KDC certificates. The sense of the room was that my message of July 18 correctly summarized the problem, and correctly described what appears in pkinit-26 and -27. The current document specifies the use of the KerberosPrincipalName SAN with the principal name of the TGS (krbtgt/REALM@REALM) to identify a certificate for use with PKINIT and belonging to a particluar realm's KDC(s). The sense of the room was to keep this method and to keep it as the REQUIRED method for both usage and naming. The sense of the room was that no other naming methods needed to be specified, but that clients should be permitted to accept certificates with other names based on local policy (also permitted by -27). There was much contention on the issue of whether an EKU should be required in this case, and, if not, whether it should be specified at all; this question remained unresolved. - Andre Scedrov (UPenn) and Aaron Jaggard (Tulane) have been doing formal analysis of Kerberos protocols, and gave a presentation on a problem they found in PKINIT in RSA mode. They described two approaches which they believe would fix the problem. One involves having the KDC sign the AS-REQ; the other involves having it sign the client's identity. The former approach is essentially what Larry has proposed in pkinit-27, and they believe that will fix the problem. After some discussion, there was general agreement that the approach taken by pkinit-27 was acceptable, and to a certain extent even preferred. Love objected to the use of a keyed checksum which was sitting right along side its key (both in a structure signed by the KDC); it was pointed out that the use of a keyed checksum allowed us to use RFC3961 cksumtypes, which essentially come only in keyed variants. It was pointed out that ASN.1 comments are not the best place to have the only copy of a normative requirement (wrt the client. The editor will fix this. - Sam Hartman gave some brief comments on some assumptions currently made in Kerberos which he would like to see go away. Unfortunately, there was not time for significant discussion; we will likely see the full version of this presentation in Vancouver. - There will be an interim meeting September 19,20 at Microsoft for the purpose of doing work needed to advance RFC's 3961, 3962, and 4121 to draft standard. Details will be posted to the list. DECISIONS (to be validated): * Specify KerberosPrincipalName SAN with the TGS principal name as a way of identifying KDC certificates, and make it the REQUIRED method. * PKINIT-27's approach to the binding problem is acceptable ACTION ITEMS: * chair: consensus call on set/change pw direction (from Minneapolis) * WG: Resolve the PKINIT EKU issue * nico: update and submit set/change pw * chair: last call set/change pw when ready * chair: last call referrals when ready * chair: get secdir review on pkinit * chair: last call pkinit when ready From rdd@cert.org Thu Aug 4 07:24:08 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j74BO75j029202 for ; Thu, 4 Aug 2005 07:24:07 -0400 (EDT) Received: from franclinus.red.cert.org (franclinus.red.cert.org [192.88.209.16])j74BNoAP024616 for ; Thu, 4 Aug 2005 07:23:50 -0400 (EDT) Received: from ioannes.indigo.cert.org (ioannes.indigo.cert.org [10.60.10.57]) j74BNnbF007761 for ; Thu, 4 Aug 2005 07:23:49 -0400 Received: from localhost (starsky.blue.cert.org [10.10.10.156]) j74BNmgZ027828 for ; Thu, 4 Aug 2005 07:23:49 -0400 Date: Thu, 04 Aug 2005 07:23:44 -0400 From: Roman Danyliw To: saag@mit.edu Message-ID: <2FC06189C5B99178E036FE6C@box.ietf63.ietf.org> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.52 on 192.88.209.16 X-Spam-Score: -2.599 X-Spam-Flag: NO Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.593084 Subject: [saag] INCH wg summary from IETF 63 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Aug 2005 11:24:09 -0000 Extended Incident Handling (INCH) WG report Wednesday, August 3, 2005, 10.30-12.30 IETF 63: Paris, France, USA The Paris INCH meeting was productive in discussing many of the remaining issues in the working group. - A new -04 version of the requirements draft [1] was produced to with a number of proofing changes. Another final set of comments were provided just before the meeting. An -05 draft will be produced by August 30, and the document will then enter WG last call. - A substantial update was made to the data model [2] in the new -04 draft. Most important amongst these changes was the migration from DTD to Schema. Only a few modeling issues and a number of editorial changes remain. The WG is aiming to freeze the data model by September 2005 and use the subsequent months till December 2005 to address the editorial issues. - The updated -03 draft of RID [3] has completed its transformation into a generalized messaging format for IODEF documents. Given the recent changes in the data model [2], a revision of this draft is necessary. - Complementing the RID message format is a newly drafted individual I-D [6] that provides a SOAP transport binding. This draft will help inform the WG and the IESG as to whether this direction is appropriate for the WG as transport entails a substantial expansion of the charter. If approved, it would become a WG document. The feedback provided at this meeting with inform an updated -01 draft to be written in September 2005. - A previously submitted individual draft extending the IODEF to describe phishing has been accepted as WG document [5]. This new -00 draft addressed minor modeling and grammatical nits. - No changes have been made to the implementation draft [4] pending resolution on transport and data model issues. - Milestone updates were made to reflect a slight slippage in the delivery dates (WG last-call) of the WG drafts. o 09-2005: Requirements o 12-2005: Data Model o 12-2005: Phishing extention data model (contingent on [2] o 12-2005: RID o 02-2006: Implementation Guide (contingent on [2]) Relevant Documents [1] draft-ietf-inch-requirements-04 [2] draft-ietf-inch-iodef-04 [3] draft-ietf-inch-rid-03 [4] draft-ietf-inch-implement-01 [5] draft-ietf-inch-phishingextns-00 [6] draft-moriarty-soap-00 From tlyu@MIT.EDU Thu Aug 4 07:29:23 2005 Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j74BTN5j029266 for ; Thu, 4 Aug 2005 07:29:23 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) j74BTLYC003355 for ; Thu, 4 Aug 2005 07:29:22 -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.1/8.12.4) with ESMTP id j74BTFIX023050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 4 Aug 2005 07:29:15 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9) id j74BTF1e021477; Thu, 4 Aug 2005 07:29:15 -0400 (EDT) To: saag@mit.edu From: Tom Yu Date: Thu, 04 Aug 2005 07:29:15 -0400 Message-ID: Lines: 52 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.041 X-Spam-Level: * (1.041) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.610920 Subject: [saag] IETF63 SASL WG summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Aug 2005 11:29:24 -0000 SASL WG Tuesday, August 2, 2005 16:30-18:00 SUMMARY ======= CRAM-MD5 is expired; Sam suggests that it be published as historic or informational. Consensus to take it off the standards track. It also needs a better applicability statement. The GSSAPI mech draft has been refreshed; it has two sorts of mechanisms: the generic family and legacy (krb5 and SPNEGO). Roundtrip optimizations are only available for legacy mechanisms. Consensus to work on roundtrip optimization of generic family and split out legacy mechanisms. PLAIN revised, and got some replies. Sam will talk with Kurt regarding some issues. SASL base specification (rfc2222bis) went to WGLC, got some responses, mostly editorial, and some misunderstandings about stringprep. We appreciate the outside review. Confusion remains about authentication vs authorization names; additional clarity is needed in the text here. DIGEST-MD5 (rfc2831bis) re-issued recently. Alexey sent mail requesting comment; none yet. Discussion of AES cipher mode: CBC mode vs counter mode. Agreement that counter mode is good. Consensus to drop CBC that does not send random IV in every packet ("proposal #2"). Lengthy discussion of whether to use CCM/GCM or other combined encryption & integrity modes. Phillip notes Christian's presentation to Applications Area re security of challenge response; raised concerns that DIGEST-MD5 is not much better than CRAM-MD5, thus must be used under TLS. Nico explains how channel bindings to TLS would be useful. Simon points out that CRAM-MD5 uses HMAC and has provable security, while DIGEST-MD5 doesn't. Roger says LDAP community is concerned. Apps area is nervous about lack of security community consensus re hash breaks, including how DIGEST-MD5 is affected. ACTION ITEMS ============ SASL-base to iesg by end of Aug. discuss future of DIGEST-MD5 discuss future of CRAM-MD5 text for CRAM-MD5 applicability split GSSAPI SASL mech -> legacy (krb5 & spnego) vs other GSSAPI mechanisms GSSAPI SASL legacy mech ready by Oct. other revised milestones to be discussed on list From tgondrom@opentext.com Thu Aug 4 07:45:43 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j74Bjf5j029376 for ; Thu, 4 Aug 2005 07:45:42 -0400 (EDT) Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.31.98]) j74BjTFh025827; Thu, 4 Aug 2005 07:45:30 -0400 (EDT) Received: from MUCXGC1.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id j74Bj4bP008525; Thu, 4 Aug 2005 13:45:25 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C598E9.C690B5EC" Date: Thu, 4 Aug 2005 13:43:59 +0200 Message-ID: <3C1BE8610E44734499EF92FB35F5B070010E375A@MUCXGC1.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS WG Session Summary - IETF 63 - August 1, 2005, 16:30-18:00 Thread-Index: AcWY6c3KwxZ2g8hiSGW3iTM6cQQRrQ== From: "Tobias Gondrom" To: X-Spam-Score: -2.598 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.777515 cc: hartmans-ietf@mit.edu cc: saag@mit.edu Subject: [saag] LTANS WG Session Summary - IETF 63 - August 1, 2005, 16:30-18:00 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Aug 2005 11:45:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C598E9.C690B5EC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Minutes of LTANS meeting August 1, 2005 16:30 - 18:00 (attendees: ~40) =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Action items =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * update milestones * update reqs draft concerning comments from Denis and the meeting * proceed and finish ers-02 * proceed and refine ltap-00 * get input from community for notareqs-02 =20 =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Agenda Topics: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =20 Administrivia =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (preliminary link until the minutes are released: www.gondrom.org/ietf/ltans/63/ltans.ppt) =20 * after decrese of speed of WG from 61st IETF, take up normal schedule again * revised milestones after IETF =20 =20 Short update on archive requirements (reqs-04)=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (preliminary link until the minutes are released: www.gondrom.org/ietf/ltans/63/ltans-reqs.ppt) =20 =20 =20 Comments on Archive Requirements (reqs-04). =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (preliminary link until the minutes are released: www.gondrom.org/ietf/ltans/63/Comments_LTANS-reqs.ppt) =20 * idea of an attestation of deposit has been raised: a user (Client) should recieve a ticket (that might even be used for authorization) as an attestation for the deposition of the archived date.=20 * need to store meta data * Denis expressed the need to manage accounts for the LTAP -> this has been objected by several persons deferring the management of accounts to already existing mechanisms. =20 =20 Cryptographic Maintenance Policy =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (preliminary link until the minutes are released: www.gondrom.org/ietf/ltans/63/LTANS_crypto_maintenance_policy.ppt) =20 * encryption algorithms schould be stored to meta data, so that the server can react upon this information, e.g. send warnings when the used algorithms get insecure * Concerning Cryptography: the question has been rised wether encryption of data on the LTA makes any sense - as the encryption mechanisms will become insecure on the long run (5-30 years+) anyway. Denis made the point that he wants to be able to make the normal Systems Engineers (running the LTA) incapable to disclose or read information that is stored currently. Anyway he recognizes that data that might be stored today will be possibly decrypted in several years. Nonetheless the possibility to store encrypted data limits the possibilities for disclosure by the System Engineer working on the LTA. (and the confidentiality of the information might decrease in importance after several years, as data is generally aslo losing its value by time.) * Cryptographic Maintenance Policy will change with time - could be some kind of linked list as the future Maintenance Policies will not be known at the time of archiving as it is unknown at what time relevant cryptographic algorithms are becoming insecure and what new algorithms are developed in the future... * Stephan Santesson: is one of the goals to process signatures inside the archived data packets, e.g. signature verification? Clear answer from Denis and the editors: No. * Larry: we should also keep the application of the maintenance policies so flexible that we can also start a maintenance process when e.g. the certificates expire (simply by time not by broken algorithms) - e.g. introduce additional parameter =20 =20 Presentation of LTAP Protocol =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (preliminary link until the minutes are released: www.gondrom.org/ietf/ltans/63/LTAP.ppt) =20 * Peter made the point to make the Protocol as small as possible to make it easy to implement and roll-out even minimal implementetations -> defer account management to other technology * Larry: accounts don't live very long, most probably not as long as the documents are stored. * Denis, audience: suggestion to change the retriever to "public" e.g. after 5 years - so that expired accounts might not be a problem for access... * Shall the LTA certify that certain AC has been applied? * David Black: AC could also be role based * M.T: Carrasco: design a simple level of archive so that it can be implemented easily * Peter: LTAP design is an asynchronous protocol (message send, message received and message archived) - getting the asynchronous message "message archived" has been realized in LTAP by using the poll-mechanism so that no back cahnnel to the client has to be managed * also important is the mechanism to transfer data from one LTA to an other LTA and from one "policy space" to another, e.g. when a inspection is on the way and data must be kept until it is completed although the applied policy would no longer require that the data be kept or maintained. =20 =20 ltans-notareq-04, =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (preliminary link until the minutes are released: www.gondrom.org/ietf/ltans/63/ltans-notareqs-02.ppt) =20 * Larry & tobias: the draft is very slim and we urgently need input from the community about use case and real needs for the scenarios - otherwise we are unsure how to proceed =20 =20 Remarks: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Denis also referred to CAdES and the RFC3126 =20 =20 =20 Tobias, Chair of LTANS ------_=_NextPart_001_01C598E9.C690B5EC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Minutes of LTANS meeting

August 1, 2005 16:30 - = 18:00

(attendees: ~40)

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Action items

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

* update milestones

* update reqs draft concerning comments from Denis = and the meeting

* proceed and finish = ers-02

* proceed and refine = ltap-00

* get input from community for = notareqs-02

 

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Agenda Topics:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

 

Administrivia

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

(preliminary link until the minutes are released: www.gondrom.org/ietf/ltans/63/ltans.ppt)

 

* after decrese of speed of WG from 61st IETF, take = up normal schedule again

* revised milestones after = IETF

 

 

Short update on archive requirements (reqs-04) =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

(preliminary link until the minutes are released: www.gondrom.org/ietf/ltans/63/ltans-reqs.ppt)

 

 

 

Comments on Archive Requirements (reqs-04).   

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

(preliminary link until the minutes are released: www.gondrom.org/ietf/ltans/63/Comments_LTANS-reqs.ppt)<= /font>

 

* idea of an attestation of deposit has been = raised:

a user (Client) should recieve a ticket (that might = even be used for authorization) as an attestation for the deposition of the = archived date.

* need to store meta = data

* Denis expressed the need to manage accounts for the = LTAP

-> this has been objected by several persons = deferring the management of accounts to already existing = mechanisms.

 

 

Cryptographic Maintenance Policy           &= nbsp;   

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

(preliminary link until the minutes are released: www.gondrom.org/ietf/ltans/63/LTANS_crypto_maintenance_policy.ppt)

 

* encryption algorithms schould be stored to meta = data, so that the server can react upon this information, e.g. send warnings when = the used algorithms get insecure

* Concerning = Cryptography:

the question has been rised wether encryption of data = on the LTA makes any sense - as the encryption mechanisms will become insecure = on the long run (5-30 years+) anyway.

Denis made the point that he wants to be able to make = the normal Systems Engineers (running the LTA) incapable to disclose or read information that is stored currently. Anyway he recognizes that data = that might be stored today will be possibly decrypted in several years. Nonetheless = the possibility to store encrypted data limits the possibilities for = disclosure by the System Engineer working on the LTA. (and the confidentiality of the information might decrease in importance after several years, as data is generally aslo losing its value by time.)

* Cryptographic Maintenance Policy will change with = time - could be some kind of linked list as the future Maintenance Policies = will not be known at the time of archiving as it is unknown at what time relevant cryptographic algorithms are becoming insecure and what new algorithms = are developed in the future...

* Stephan Santesson: is one of the goals to process signatures inside the archived data packets, e.g. signature = verification? Clear answer from Denis and the editors: No.

* Larry: we should also keep the application of the maintenance policies so flexible that we can also start a maintenance = process when e.g. the certificates expire (simply by time not by broken = algorithms) - e.g. introduce additional parameter

 

 

Presentation of LTAP Protocol           = ;      

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

(preliminary link until the minutes are released: www.gondrom.org/ietf/ltans/63/LTAP.ppt)

 

* Peter made the point to make the Protocol as small = as possible to make it easy to implement and roll-out even minimal implementetations -> defer account management to other = technology

* Larry: accounts don't live very long, most probably = not as long as the documents are stored.

* Denis, audience: suggestion to change the retriever = to "public" e.g. after 5 years - so that expired accounts might = not be a problem for access...

* Shall the LTA certify that certain AC has been = applied?

* David Black: AC could also be role = based

* M.T: Carrasco: design a simple level of archive so = that it can be implemented easily

* Peter: LTAP design is an asynchronous protocol = (message send, message received and message archived) - getting the asynchronous = message "message archived" has been realized in LTAP by using the poll-mechanism so that no back cahnnel to the client has to be = managed

* also important is the mechanism to transfer data = from one LTA to an other LTA and from one "policy space" to another, = e.g. when a inspection is on the way and data must be kept until it is completed = although the applied policy would no longer require that the data be kept or = maintained.

 

 

ltans-notareq-04,      &= nbsp;           &n= bsp;            

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

(preliminary link until the minutes are released: www.gondrom.org/ietf/ltans/63/ltans-notareqs-02.ppt)

 

* Larry & tobias: the draft is very slim and we = urgently need input from the community about use case and real needs for the = scenarios - otherwise we are unsure how to proceed

 

 

Remarks:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Denis also referred to CAdES and the = RFC3126

 

 

 

Tobias, Chair of LTANS

------_=_NextPart_001_01C598E9.C690B5EC-- From fenton@cisco.com Thu Aug 4 08:13:38 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j74CDb5j029580 for ; Thu, 4 Aug 2005 08:13:37 -0400 (EDT) Received: from sb7.songbird.com (sb7.songbird.com [208.184.79.137]) j74CDMs7023739; Thu, 4 Aug 2005 08:13:23 -0400 (EDT) Received: from bbfujip7 (open-28-238.ietf63.ietf.org [86.255.28.238]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j74CDqsf031574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Aug 2005 05:13:56 -0700 From: Jim Fenton To: Russ Housley , Sam Hartman X-Mailer: PocoMail 3.4 (2130) - Licensed Version X-URL: bbiw.net Date: Thu, 04 Aug 2005 05:03:56 -0700 Message-ID: <20058414134.250233@bbfujip7> In-Reply-To: <42F2042C.4090103@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-SpamCheck: X-Songbird-From: fenton@cisco.com X-Spam-Score: -2.06 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.582957 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id j74CDb5j029580 cc: saag@mit.edu Subject: [saag] Summary of the MASS/DKIM BoF X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Aug 2005 12:13:39 -0000 MASS/DKIM BOF Summary - 4 Aug 05 Co-Chairs: Jim Fenton, Cisco Dave Crocker, Brandenburg DKIM uses an independent domain name identity for establishing a digital signature to an email message body and selected headers. The BOF continued discussions from the MASS mailing list (ietf-mailsig) reviewing the DKIM specifications, a draft working group charter, and a list of open questions about the charter. Miles Libbey, of Yahoo!, said that a Yahoo! IPR statement would be filed by 5 September. A full-and-frank BOF discussion quickly moved to concerns about the lack of a sufficient threat analysis and, generally, confusion over the actual utility of DKIM. This did necessarily represent a broad belief that it was not useful, but a common concern was that DKIM not oversell its potential benefit. DKIM was developed out of anti-spam and anti-spoofing, but its direct utility in solving these problems is, at best, unclear. The sense of the room was to establish a DKIM- specific mailing list; it will be announced through the mailsig list. ACTION: The homework assignment for attendees is to bring assignments are to formulate concise suggestions for threat statements and benefits statements. ACTION: The DKIM "community" must produce a satisfactory threat analysis before a working group can be chartered. From dhc2@dcrocker.net Thu Aug 4 08:29:45 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j74CTi5j029779 for ; Thu, 4 Aug 2005 08:29:44 -0400 (EDT) Received: from sb7.songbird.com (sb7.songbird.com [208.184.79.137]) j74CTQFh026160; Thu, 4 Aug 2005 08:29:27 -0400 (EDT) Received: from bbfujip7 (open-28-238.ietf63.ietf.org [86.255.28.238]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j74CU1wo000802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Aug 2005 05:30:05 -0700 From: Dave Crocker To: Russ Housley , Sam Hartman X-Mailer: PocoMail 3.4 (2130) - Licensed Version X-URL: bbiw.net Date: Thu, 4 Aug 2005 14:29:14 +0200 Message-ID: <200584142914.449679@bbfujip7> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-SpamCheck: X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: -0.946 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.577125 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id j74CTi5j029779 cc: saag@mit.edu Subject: [saag] MASS/DKIM BOF Summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: Dave Crocker List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Aug 2005 12:29:46 -0000 MASS/DKIM BOF Summary - 4 Aug 05 Co-Chairs: Jim Fenton, Cisco Dave Crocker, Brandenburg DKIM uses an independent domain name identity for establishing a digital signature to an email message body and selected headers. The BOF continued discussions from the MASS mailing list (ietf-mailsig) reviewing the DKIM specifications, a draft working group charter, and a list of open questions about the charter. Miles Libbey, of Yahoo!, said that a Yahoo! IPR statement would be filed by 5 September. A full-and-frank BOF discussion quickly moved to concerns about the lack of a sufficient threat analysis and, generally, confusion over the actual utility of DKIM. This did necessarily represent a broad belief that it was not useful, but a common concern was that DKIM not oversell its potential benefit. DKIM was developed out of anti-spam and anti-spoofing, but its direct utility in solving these problems is, at best, unclear. The sense of the room was to establish a DKIM- specific mailing list; it will be announced through the mailsig list. ACTION: The homework assignment for attendees is to bring assignments are to formulate concise suggestions for threat statements and benefits statements. ACTION: The DKIM "community" must produce a satisfactory threat analysis before a working group can be chartered. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net From paul.hoffman@vpnc.org Thu Aug 4 08:51:02 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j74Cp15j029897 for ; Thu, 4 Aug 2005 08:51:01 -0400 (EDT) Received: from above.proper.com (above.proper.com [208.184.76.39]) j74CosFh002309 for ; Thu, 4 Aug 2005 08:50:55 -0400 (EDT) Received: from [86.255.19.201] (open-26-18.ietf63.ietf.org [86.255.26.18]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74CoquO009123 for ; Thu, 4 Aug 2005 05:50:53 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 4 Aug 2005 14:50:54 +0200 To: saag@mit.edu From: Paul Hoffman Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.539981 Subject: [saag] Hash Bof notes X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Aug 2005 12:51:03 -0000 The Hash BoF met on Monday evening. We had presentations on the upcoming NIST Hash meeting, where NIST is going with truncation, and other tentative proposals for strengthening SHA-1 and MD5 against the recent attacks from Wang on Merkle-Damgård-based hash functions. We then had a good discussion of what work people wanted to see in this area. There was general consensus that we need to document which major security frameworks in the IETF do and do not allow users to move gracefully to different hash functions. There was also strong consensus that the IETF should not develop hash functions here, but we might want to review propsals for strengthening schemes and new functions that others develop. --Paul Hoffman, Director --VPN Consortium From huitema@windows.microsoft.com Thu Aug 4 08:54:58 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j74Csv5j029943 for ; Thu, 4 Aug 2005 08:54:58 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) j74Csks7012649; Thu, 4 Aug 2005 08:54:47 -0400 (EDT) Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Aug 2005 05:54:45 -0700 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Aug 2005 05:54:44 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Aug 2005 05:54:45 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.89]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Aug 2005 05:54:47 -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" Subject: RE: [saag] IETF63 SASL WG summary Date: Thu, 4 Aug 2005 05:54:40 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] IETF63 SASL WG summary thread-index: AcWY6ZPK6yPGRmx9RSy/6ahDfXEVlwACaLAA From: "Christian Huitema" To: "Tom Yu" , X-OriginalArrivalTime: 04 Aug 2005 12:54:47.0394 (UTC) FILETIME=[B1982420:01C598F3] X-Spam-Score: -2.6 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.542532 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id j74Csv5j029943 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Aug 2005 12:54:59 -0000 > ... Phillip notes Christian's presentation > to Applications Area re security of challenge response; raised > concerns that DIGEST-MD5 is not much better than CRAM-MD5, thus must > be used under TLS. Nico explains how channel bindings to TLS would be > useful. Simon points out that CRAM-MD5 uses HMAC and has provable > security, while DIGEST-MD5 doesn't. Roger says LDAP community is > concerned. Apps area is nervous about lack of security community > consensus re hash breaks, including how DIGEST-MD5 is affected. The main argument against simple challenge/response protocols is their vulnerability to dictionary attacks. The use of HMAC does not protect that. In fact, moving from MD5 to SHA256 would not solve the problem either. DIGEST-MD5 should indeed only be used under TLS. -- Christian Huitema From smb@cs.columbia.edu Thu Aug 4 09:05:51 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j74D5p5j000023 for ; Thu, 4 Aug 2005 09:05:51 -0400 (EDT) Received: from machshav.com (machshav.com [147.28.0.16]) j74D5bs7004040; Thu, 4 Aug 2005 09:05:38 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 90856FB282; Thu, 4 Aug 2005 09:05:37 -0400 (EDT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CC4F3FB27C; Thu, 4 Aug 2005 09:05:36 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 064C83BFF7F; Thu, 4 Aug 2005 15:05:35 +0200 (CEST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: "Christian Huitema" Subject: Re: [saag] IETF63 SASL WG summary In-Reply-To: Your message of "Thu, 04 Aug 2005 05:54:40 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Aug 2005 09:05:35 -0400 Sender: smb@cs.columbia.edu Message-Id: <20050804130535.064C83BFF7F@berkshire.machshav.com> X-Spam-Score: -2.099 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.567260 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Aug 2005 13:05:52 -0000 In message , "Christian Huitema" writes: >> ... Phillip notes Christian's presentation >> to Applications Area re security of challenge response; raised >> concerns that DIGEST-MD5 is not much better than CRAM-MD5, thus must >> be used under TLS. Nico explains how channel bindings to TLS would be >> useful. Simon points out that CRAM-MD5 uses HMAC and has provable >> security, while DIGEST-MD5 doesn't. Roger says LDAP community is >> concerned. Apps area is nervous about lack of security community >> consensus re hash breaks, including how DIGEST-MD5 is affected. > >The main argument against simple challenge/response protocols is their >vulnerability to dictionary attacks. The use of HMAC does not protect >that. In fact, moving from MD5 to SHA256 would not solve the problem >either. DIGEST-MD5 should indeed only be used under TLS. I agree. This is a problem I've been worrying about since 1990, and dictionary attack programs have gotten much better since then. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb From jaltman@columbia.edu Thu Aug 4 09:15:15 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j74DFE5j000089 for ; Thu, 4 Aug 2005 09:15:14 -0400 (EDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) j74DF5s7022437 for ; Thu, 4 Aug 2005 09:15:06 -0400 (EDT) Received: from [86.255.24.98] (open-24-98.ietf63.ietf.org [86.255.24.98]) (user=jaltman mech=PLAIN bits=0)j74DF0Uv013124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Aug 2005 09:15:01 -0400 (EDT) Message-ID: <42F214F9.4050100@columbia.edu> Date: Thu, 04 Aug 2005 15:15:37 +0200 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Steven M. Bellovin" Subject: Re: [saag] IETF63 SASL WG summary References: <20050804130535.064C83BFF7F@berkshire.machshav.com> In-Reply-To: <20050804130535.064C83BFF7F@berkshire.machshav.com> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030702090602000102040109" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: -2.601 X-Spam-Flag: NO Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.668067 cc: saag@mit.edu cc: Christian Huitema X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Aug 2005 13:15:16 -0000 This is a cryptographically signed message in MIME format. --------------ms030702090602000102040109 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steven M. Bellovin wrote: > In message loy.ntdev.microsoft.com>, "Christian Huitema" writes: > >>>... Phillip notes Christian's presentation >>>to Applications Area re security of challenge response; raised >>>concerns that DIGEST-MD5 is not much better than CRAM-MD5, thus must >>>be used under TLS. Nico explains how channel bindings to TLS would be >>>useful. Simon points out that CRAM-MD5 uses HMAC and has provable >>>security, while DIGEST-MD5 doesn't. Roger says LDAP community is >>>concerned. Apps area is nervous about lack of security community >>>consensus re hash breaks, including how DIGEST-MD5 is affected. >> >>The main argument against simple challenge/response protocols is their >>vulnerability to dictionary attacks. The use of HMAC does not protect >>that. In fact, moving from MD5 to SHA256 would not solve the problem >>either. DIGEST-MD5 should indeed only be used under TLS. > > > I agree. This is a problem I've been worrying about since 1990, and > dictionary attack programs have gotten much better since then. > > --Steven M. Bellovin, http://www.cs.columbia.edu/~smb Since the SASL meeting, Nico Williams and I have written text that defines channel bindings for SASL DIGEST-MD5 and provides a specific binding for TLS. We hope the working group will decide to pursue the inclusion of this work. There is a question as to whether or not it is in scope of the WG's charter. Jeffrey Altman --------------ms030702090602000102040109 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwODA0MTMxNTM3WjAjBgkqhkiG9w0BCQQxFgQUpaMMo2zCphUYRiTNzQnlHT9M8Y8w UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAU8NdCmGWR+1xlhopc7hKbw99s7Htv6yzSoI/q86q oJQN4N9qFtkad/M9H6trmXqmRAh4l8MmFMB/ZIK/LrExjXnucSsWyiNqPkfslTFtxQSKnk7O 8PgaTA4vZGQvAajXgY8WrpBDbEIVLu9OdH09X2hFmTIXXe6zv3vl3RsDpAT/gcCtwFTHn1Eg JGGTEmLrLcFQrMflmI9Kh53GPYtLAFZ0wh0vHUQa4yYdVdGKjiyYoO2RwIwJ7ZAd0LehiE5Z mdfaHGyKG9aP3R2Tx/Ty8PhczzR4k4Y9eK2/M/iD3E5QIV/PXDFXfiwsqtnxd673or1qDZOe asX5GeXcPEyHPQAAAAAAAA== --------------ms030702090602000102040109-- From mleech@nortel.com Thu Aug 4 09:26:57 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j74DQu5j000181 for ; Thu, 4 Aug 2005 09:26:56 -0400 (EDT) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57])j74DQms7015026 for ; Thu, 4 Aug 2005 09:26:49 -0400 (EDT) Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) id j74DQJt13824; Thu, 4 Aug 2005 09:26:19 -0400 (EDT) Received: from [47.248.126.240] (47.248.126.240 [47.248.126.240]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QDGYG8GZ; Thu, 4 Aug 2005 09:26:19 -0400 Message-ID: <42F21774.9020202@nortel.com> Date: Thu, 04 Aug 2005 09:26:12 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Marcus Leech" User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc3 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Steven M. Bellovin" Subject: Re: [saag] IETF63 SASL WG summary References: <20050804130535.064C83BFF7F@berkshire.machshav.com> In-Reply-To: <20050804130535.064C83BFF7F@berkshire.machshav.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.544627 cc: saag@mit.edu cc: Christian Huitema X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Aug 2005 13:26:58 -0000 Steven M. Bellovin wrote: > >I agree. This is a problem I've been worrying about since 1990, and >dictionary attack programs have gotten much better since then. > > > From RFC3562, single-block MD5 on a single-CPU proceeds at roughly 4.16e6 guesses/sec. That was ca 2002 timeframe, so approximately 2 Moores-law intervals have passed since then. HMAC-based transforms would proceed at approximately half the rate of naked MD5. I don't have anything to scale others (like SHA-1 and friends). I'm also rather nervous about dictionary-attack-possible methods like these... From smb@cs.columbia.edu Thu Aug 4 09:31:29 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j74DVS5j000234 for ; Thu, 4 Aug 2005 09:31:28 -0400 (EDT) Received: from machshav.com (machshav.com [147.28.0.16]) j74DVKFh012787 for ; Thu, 4 Aug 2005 09:31:20 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id F02FDFB282; Thu, 4 Aug 2005 09:31:19 -0400 (EDT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 43860FB27C; Thu, 4 Aug 2005 09:31:19 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 4B1B53BFECD; Thu, 4 Aug 2005 15:31:17 +0200 (CEST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: "Marcus Leech" Subject: Re: [saag] IETF63 SASL WG summary In-Reply-To: Your message of "Thu, 04 Aug 2005 09:26:12 EDT." <42F21774.9020202@nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Aug 2005 09:31:17 -0400 Sender: smb@cs.columbia.edu Message-Id: <20050804133117.4B1B53BFECD@berkshire.machshav.com> X-Spam-Score: -2.099 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.560327 cc: saag@mit.edu cc: Christian Huitema X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Aug 2005 13:31:30 -0000 In message <42F21774.9020202@nortel.com>, "Marcus Leech" writes: >Steven M. Bellovin wrote: > >> >>I agree. This is a problem I've been worrying about since 1990, and >>dictionary attack programs have gotten much better since then. >> >> >> > From RFC3562, single-block MD5 on a single-CPU proceeds at roughly > 4.16e6 guesses/sec. That was ca 2002 timeframe, so approximately > 2 Moores-law intervals have passed since then. > >HMAC-based transforms would proceed at approximately half the rate > of naked MD5. I don't have anything to scale others (like SHA-1 and > friends). > >I'm also rather nervous about dictionary-attack-possible methods like >these... > See Christian's slides from the APPS area at http://www.huitema.net/talks/ietf63-security.ppt --Steven M. Bellovin, http://www.cs.columbia.edu/~smb From quittek@netlab.nec.de Thu Aug 4 09:52:08 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j74Dq75j000403 for ; Thu, 4 Aug 2005 09:52:07 -0400 (EDT) Received: from kyoto.netlab.nec.de (kyoto.netlab.nec.de [195.37.70.21]) j74DpvFh024278 for ; Thu, 4 Aug 2005 09:52:00 -0400 (EDT) Received: from open-25-41.ietf63.ietf.org (open-25-41.ietf63.ietf.org [86.255.25.41]) by kyoto.netlab.nec.de (Postfix) with ESMTP id D7CAC1BAC4D; Thu, 4 Aug 2005 15:51:56 +0200 (CEST) Date: Thu, 04 Aug 2005 15:51:54 +0200 From: Juergen Quittek To: saag@mit.edu Message-ID: X-Mailer: Mulberry/3.1.6 (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: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.562878 cc: kenh@cmf.nrl.navy.mil Subject: [saag] IETF63 ISMS WG summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 04 Aug 2005 13:52:09 -0000 =================================== IETF-63 ISMS Session Summary Tuesday August 2, 14:00 h - 16:00 h =================================== In April the WG achieved (very rough) consensus on using an encapsulated keying architecture (as used by the TLSM proposal). At this meeting the WG progressed the decision on a transport protocol to be used by ISMS. Candidate protocols were TLS+SASL, SSH, DTLS, and BEEP. Among the proposals, DTLS is the only one based on UDP. Since DTLS is not yet commonly deployed and not extensively tested, it was eliminated from the discussion after the WG agreed that UDP transport is not necessarily required for the ISMS solution. For all of the remaining three protocols there was support in the WG. Among them, SSH had clearly the strongest support, mainly, because SSH is already widely deployed and used in network management and thus could best achieve the goal of integrating the ISMS solution into existing security infrastructures. Within the session there was a consensus on choosing only one protocol as work item and there was rough consensus that this protocol would be SSH. The consensus still needs to be confirmed on the mailing list. Decisions made: - ISMS will work on one transport protocol only - Use SSH as transport protocol Action items: - confirm WG consensus on decisions on the mailing list (August) - draft new charter, discuss on mailing list (August) - start work on SSH-based solution From hartmans@MIT.EDU Thu Aug 11 14:14:42 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j7BIEg5j018562 for ; Thu, 11 Aug 2005 14:14:42 -0400 (EDT) Received: from carter-zimmerman.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197])j7BIETxu014049 for ; Thu, 11 Aug 2005 14:14:34 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 036D8E004B; Thu, 11 Aug 2005 14:14:22 -0400 (EDT) To: saag@mit.edu From: Sam Hartman Date: Thu, 11 Aug 2005 14:14:22 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 1.041 X-Spam-Level: * (1.041) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.586354 cc: margaret@thingmagic.com Subject: [saag] [The IESG] Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 11 Aug 2005 18:14:43 -0000 --=-=-= Hi. A revision to RFC 2538 (DNS cert record) is in last call. I'd appreciate comments from the security community directed to iesg@ietf.org or ietf@ietf.org before August 24. here are issues I'd particularly like comments on: * The utility of this specification * Comments on trust model issues. The security considerations section discusses when you can trust a certificate obtained from DNS without validating the trust chain if it is in a signed zone. It basically leaves it up to user policy. Is there more text we want on this issue? --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.16-IPv6-Debian-2.1.16-10) with LMTP; Wed, 10 Aug 2005 14:44:45 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 9A9C71383F for ; Wed, 10 Aug 2005 14:44:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vOb-0004Bx-M8; Wed, 10 Aug 2005 14:33:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vOZ-0004Bs-81 for ietf-announce@megatron.ietf.org; Wed, 10 Aug 2005 14:33:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15757 for ; Wed, 10 Aug 2005 14:33:41 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2vwg-00070T-Ea for ietf-announce@ietf.org; Wed, 10 Aug 2005 15:08:58 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1E2vOV-0005EH-LM; Wed, 10 Aug 2005 14:33:39 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 10 Aug 2005 14:33:39 -0400 X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: namedroppers@ops.ietf.org Subject: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-announce-bounces@ietf.org Errors-To: ietf-announce-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on solipsist-nation.suchdamage.org X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 MIME-Version: 1.0 The IESG has received a request from the DNS Extensions WG to consider the following document: - 'Storing Certificates in the Domain Name System (DNS)' as a Proposed Standard This document updates RFC 2538. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-08-24. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-03.txt _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --=-=-=-- From aboba@internaut.com Thu Aug 11 17:26:15 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j7BLQE5j019600 for ; Thu, 11 Aug 2005 17:26:14 -0400 (EDT) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) j7BLPdn0015313; Thu, 11 Aug 2005 17:25:39 -0400 (EDT) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1E3KYV-000Iqx-A8; Thu, 11 Aug 2005 17:25:39 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j7BLPbQ02161; Thu, 11 Aug 2005 14:25:37 -0700 X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Thu, 11 Aug 2005 14:25:37 -0700 (PDT) From: Bernard Aboba To: Sam Hartman Subject: Re: [saag] [The IESG] Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.166 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.539613 cc: margaret@thingmagic.com cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 11 Aug 2005 21:26:16 -0000 > Hi. A revision to RFC 2538 (DNS cert record) is in last call. I'd > appreciate comments from the security community directed to > iesg@ietf.org or ietf@ietf.org before August 24. > > here are issues I'd particularly like comments on: > > * The utility of this specification There is currently research going on within Terena in order to develop more scalable roaming scheme for the EDUROAM consortium. I believe that this research (which seems promising) depends on the DNS cert record. See: http://www.lab.telin.nl/~arjan/pub/tnc05-ea-eertink.pdf From pekka.nikander@nomadiclab.com Mon Aug 15 02:54:22 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j7F6sL5j009829 for ; Mon, 15 Aug 2005 02:54:21 -0400 (EDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) j7F6sHOE016359 for ; Mon, 15 Aug 2005 02:54:18 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 044C0212CA9; Mon, 15 Aug 2005 09:54:16 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <41F164DA-08A4-442F-A0F4-92425D21C82F@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Mon, 15 Aug 2005 08:54:16 +0200 To: momipriv@lacnic.net, saag@mit.edu, Internet Area X-Mailer: Apple Mail (2.733) X-Spam-Score: -2.598 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.002374 Spam-Alum-Time: 0.545366 Subject: [saag] Preliminary ALIEN BoF minutes available for corrections X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: momipriv@lacnic.net, Pekka Nikander List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 15 Aug 2005 06:54:22 -0000 [Apologies for cross-posting; discussion at momipriv only, please.] Preliminary minutes for the ALIEN BoF on April 3rd, at 2-4:30pm, are now available at http://www.tml.tkk.fi/~pnr/ietf63_alien_minutes.html for review. Please check that we have correctly transcribed what you intended to say, and send any corrections to me. Context diff appreciated but any format will do. If you can identify the two unidentified speakers towards the end of the meeting, that would be great. Please send your corrections no later than Thursday, August 18. I will mail the final minutes to the secretariat on Friday, August 19. --Pekka Nikander From James_hughes@storagetek.com Mon Aug 15 09:51:25 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j7FDpO5j011536 for ; Mon, 15 Aug 2005 09:51:24 -0400 (EDT) Received: from sherman.stortek.com (sherman.stortek.com [129.80.22.146]) j7FDpERX021818 for ; Mon, 15 Aug 2005 09:51:14 -0400 (EDT) Received: from sherman.stortek.com (localhost [127.0.0.1]) by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id j7FDpDcW023202 for ; Mon, 15 Aug 2005 07:51:13 -0600 (MDT) Received: from [169.231.1.149] ([129.80.72.102]) by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id j7FDpBPV023188; Mon, 15 Aug 2005 07:51:11 -0600 (MDT) In-Reply-To: <41F164DA-08A4-442F-A0F4-92425D21C82F@nomadiclab.com> References: <41F164DA-08A4-442F-A0F4-92425D21C82F@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: james hughes Date: Mon, 15 Aug 2005 06:51:10 -0700 To: saag@mit.edu X-Mailer: Apple Mail (2.733) X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000002 Spam-Alum-Time: 0.522481 cc: james hughes Subject: [saag] Crypto Rump Session to be webcast X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 15 Aug 2005 13:51:26 -0000 FYI, Crypto 2005 Rump Session will be webcast starting 7pm Pacific Tuesday August 16th. Further information will be posted at http://www.iacr.org. Please feel free to cross post this to other security mailinglists. Thanks jim From James_hughes@storagetek.com Tue Aug 16 14:36:53 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j7GIar5j021056 for ; Tue, 16 Aug 2005 14:36:53 -0400 (EDT) Received: from sherman.stortek.com (sherman.stortek.com [129.80.22.146]) j7GIaiq5006303 for ; Tue, 16 Aug 2005 14:36:44 -0400 (EDT) Received: from sherman.stortek.com (localhost [127.0.0.1]) by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id j7GIahcW017977 for ; Tue, 16 Aug 2005 12:36:43 -0600 (MDT) Received: from [169.231.68.125] ([129.80.72.102]) by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id j7GIYnPV017289; Tue, 16 Aug 2005 12:34:50 -0600 (MDT) In-Reply-To: References: <41F164DA-08A4-442F-A0F4-92425D21C82F@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: multipart/alternative; boundary=Apple-Mail-2--118800713 Message-Id: <814716B0-81A2-41E1-A266-D9E54558DBFF@storagetek.com> From: james hughes Date: Tue, 16 Aug 2005 11:34:47 -0700 To: saag@mit.edu X-Mailer: Apple Mail (2.733) X-Spam-Score: -2.511 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.579254 cc: james hughes Subject: [saag] Re: Crypto Rump Session to be webcast X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 16 Aug 2005 18:36:54 -0000 --Apple-Mail-2--118800713 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed For those interested, testing will begin at 3:30pm PDT. More information see http://www.iacr.org/conferences/crypto2005/rump.html The program is now available http://www.iacr.org/conferences/crypto2005/C05rump.pdf Please feel free to forward this to other security list. I believe it will be an interesting rump session. Thanks jim On Aug 15, 2005, at 6:51 AM, james hughes wrote: > FYI, Crypto 2005 Rump Session will be webcast starting 7pm Pacific > Tuesday August 16th. > > Further information will be posted at http://www.iacr.org. > > Please feel free to cross post this to other security mailinglists. > > Thanks > > jim > > > > --Apple-Mail-2--118800713 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 For those interested, testing = will begin at 3:30pm PDT. More information see=A0
=A0=A0=A0=A0http://www.i= acr.org/conferences/crypto2005/rump.html

The program is now = available=A0

Please feel free to forward = this to other security list. I believe it will be an interesting rump = session.=A0

Thanks

jim

= On Aug 15, 2005, at 6:51 AM, james hughes wrote:

FYI, Crypto 2005 Rump Session will be webcast starting 7pm = Pacific=A0
Tuesday August 16th.

Further information will be = posted at http://www.iacr.org.
=
Please feel free to cross post this to other security = mailinglists.

Thanks

jim



 =


= --Apple-Mail-2--118800713-- From housley@vigilsec.com Tue Sep 6 16:26:08 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j86KQ75j023253 for ; Tue, 6 Sep 2005 16:26:07 -0400 (EDT) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) j86KQ2fq003622 for ; Tue, 6 Sep 2005 16:26:02 -0400 (EDT) Received: (qmail 3625 invoked by uid 0); 6 Sep 2005 20:25:55 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.179.121) by woodstock.binhost.com with SMTP; 6 Sep 2005 20:25:55 -0000 Message-Id: <6.2.1.2.2.20050906162254.076e1c60@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 06 Sep 2005 16:24:46 -0400 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.568437 Subject: [saag] Informational RFC to be: draft-krovetz-umac-04.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 06 Sep 2005 20:26:08 -0000 Security Area Advisors Group: This RFC-to-be was submitted to the RFC Editor to be published as Informational: draft-krovetz-umac-04.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. UMAC: Message Authentication Code using Universal Hashing This specification describes how to generate an authentication tag using the UMAC message authentication algorithm. UMAC is designed to be very fast to compute in software on contemporary uniprocessors. Measured speeds are as low as one cycle per byte. UMAC relies on addition of 32-bit and 64-bit numbers and multiplication of 32-bit numbers, operations well-supported by contemporary machines. To generate the authentication tag on a given message, a "universal" hash function is applied to the message and key to produce a short, fixed-length hash value, and this hash value is then xor'ed with a key-derived pseudorandom pad. UMAC enjoys a rigorous security analysis and its only internal "cryptographic" use is a block cipher to generate the pseudorandom pads and internal key material. Thanks, Russ From smb@cs.columbia.edu Mon Sep 19 20:22:34 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j8K0MY5j016436 for ; Mon, 19 Sep 2005 20:22:34 -0400 (EDT) Received: from machshav.com (machshav.com [147.28.0.16]) j8K0MRdH012849 for ; Mon, 19 Sep 2005 20:22:27 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id F1079FB28A; Mon, 19 Sep 2005 20:22:26 -0400 (EDT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D3BA3FB262 for ; Mon, 19 Sep 2005 20:22:24 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id B7B973BFCBF for ; Mon, 19 Sep 2005 20:22:21 -0400 (EDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: saag@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Sep 2005 20:22:21 -0400 Sender: smb@cs.columbia.edu Message-Id: <20050920002221.B7B973BFCBF@berkshire.machshav.com> X-Spam-Score: -2.099 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.553125 Subject: [saag] I-D ACTION:draft-bellovin-useipsec-04.txt (Forwarded) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 20 Sep 2005 00:22:35 -0000 ------- Forwarded Message To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Sep 2005 10:50:02 -0400 - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Guidelines for Mandating the Use of IPsec Author(s) : S. Bellovin Filename : draft-bellovin-useipsec-04.txt Pages : 13 Date : 2005-9-19 The Security Considerations sections of many Internet Drafts say, in effect, "just use IPsec". While this is sometimes correct, more often it will leave users without real, interoperable security mechanisms. This memo offers some guidance on when IPsec should and should not be specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bellovin-useipsec-04.txt --Steven M. Bellovin, http://www.cs.columbia.edu/~smb From ldondeti@qualcomm.com Thu Sep 22 18:10:36 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j8MMAZ5j013208 for ; Thu, 22 Sep 2005 18:10:35 -0400 (EDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) j8MMAVM1024064 for ; Thu, 22 Sep 2005 18:10:31 -0400 (EDT) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) j8MM9doV009454; Thu, 22 Sep 2005 15:09:40 -0700 (PDT) Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.100])j8MM9aoZ004324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Sep 2005 15:09:37 -0700 (PDT) Message-Id: <6.2.2.1.2.20050922133615.02af53b8@qcmail1.qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1 Date: Thu, 22 Sep 2005 15:09:35 -0700 To: "Steven M. Bellovin" , saag@mit.edu From: Lakshminath Dondeti Subject: Re: [saag] I-D ACTION:draft-bellovin-useipsec-04.txt (Forwarded) In-Reply-To: <20050920002221.B7B973BFCBF@berkshire.machshav.com> References: <20050920002221.B7B973BFCBF@berkshire.machshav.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.099 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.754076 cc: msec@securemulticast.org cc: iesg@ietf.org X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 22 Sep 2005 22:10:37 -0000 Note: This document is also in IETF last call, so I am cc'ing the IESG. Someone might choose to delete them from the cc list if a long discussion follows. Summary: I read the 00 or 01 of this document, and hoped that it will be revised and brought up to date before being published as an RFC. As is stands now, it will be published in early 2006, already outdated and not as useful as it might be if revised to reflect the issues in choosing IPsecbis and IKEv2. Furthermore, many new standards proposals in the IETF and in other SDOs are already using IKEv2 and IPsecbis, so this BCP, if published as is sends mixed messages. Finally, the text on the use of IPsec for multicast security is at odds with several years worth of completed and ongoing work in the MSEC WG. Review: "Let's use IPsec (2401bis etc) and IKEv2" is what IETF WGs and other SDOs say nowadays. An entire working group (MOBIKE), at least one work item in the MIP6 WG (e.g., http://ietfreport.isoc.org/all-ids/draft-ietf-mip6-ikev2-ipsec-03.txt) and some work in 3GPP2 are examples of this. I recently started a couple of discussions in the IPSEC list asking questions that arose while working on 3GPP2 contributions, and the discussions centered around strict compliance with 2401bis and IKEv2 (as well they should; however, there are some conflicts in requirements between those two documents and there is the ikev2-clarifications document to address that, but I digress). Tone of the document -------------------------- The useipsec I-D takes the tone of not all required features in the specifications are supported in implementations so new RFC authors might want to take note of that: practical advice, but I think also a slippery slope to normalize implementations that might have been centered around a specific use case -- e.g., VPNs. Other use cases -- some in discussion now and others yet to be conceived -- may require features that are in the specs as RECOMMENDED or even MUST, but are not necessarily available in all implementations. (Please see Section 8, item (h)). The IETF's advice should be along the lines of what's in the specs and not what is widely implemented. If there is consensus that what's implemented is all that is needed and the original specifications are overdone, well we should revise the specs (e.g., we do that, as in case of IKE to IKEv2). New protocols vs. Old protocols -------------------------------------- To come back to the issue of IKE+IPsec vs. IKEv2+IPsecbis: I think the BCP should talk about IKEv2 and IPsecbis and make some passing references to IKE and IPsec in historical notes. I realize IKEv2 and IPsecbis are in infancy w.r.t. implementation and deployment, but we should encourage future specification writers, whether in the IETF or other SDOs, to use IKEv2 and IPsecbis and not the older versions (as I note above, people are already using IKEv2 and IPsecbis, and so the IETF publishing a BCP referring to protocols that are ready to be phased out sends a mixed message). Some specific changes along those lines would be in Sections 6 (e.g., there are new selectors and databases in IPsecbis to consider now) and 8 (No more main and aggressive modes, please :-)). In Section 8, I would delete (h). Section 7, Multicast related text ------------------------------------------ Next, I think Section 7 needs to be updated and references to Transport mode need to be updated with point to multi-point use (perhaps end-to-end is a more generic and all encompassing term to use with transport mode). Section 7 notes that there are no key management protocols for the general case: the MSEC group developed, not one but two (MIKEY, which is referred to, was also an MSEC product, but has nothing to do with IPsec) group key management protocols: GDOI specified in RFC 3547 is quite similar to IKEv1 and is a general purpose group key management protocol; similarly GSAKMP is also a general purpose key management protocol, and is currently in the RFC Editor queue. While I agree that replay protection is important, it is after all OPTIONAL in IPsec specifications and so was not a priority for MSEC. Multi-sender replay protection is indeed a hard problem and someone -- Sandy Harris@Paris -- noted that it has come up in RPSEC recently, and so MSEC agreed to try and look at the problem again. GDOI and GSAKMP work very well with IPsec and other security encapsulation protocols and so the BCP should not be saying that it is inappropriate to use IPsec for multicast traffic. In fact, there is a msec-ipsec-extensions document which is specifying multicast and group security extensions to IPsec. The multicast portions of the current IPsecbis document were written after a good amount of discussion with a team of MSEC contributors. Some nits: Old Authors of RFCs that rely on IPsec must specify the following: New Authors of standards documents that rely on IPsec must specify the following In Section 4 Old RFC2041 New RFC2401 In Section 8 Old RFC2284 New RFC3748 regards, Lakshminath At 05:22 PM 9/19/2005, Steven M. Bellovin wrote: >------- Forwarded Message > > >To: i-d-announce@ietf.org >From: Internet-Drafts@ietf.org >Message-Id: >Date: Mon, 19 Sep 2005 10:50:02 -0400 > > >- --NextPart > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Guidelines for Mandating the Use of IPsec > Author(s) : S. Bellovin > Filename : draft-bellovin-useipsec-04.txt > Pages : 13 > Date : 2005-9-19 > >The Security Considerations sections of many Internet Drafts say, in > effect, "just use IPsec". While this is sometimes correct, more > often it will leave users without real, interoperable security > mechanisms. This memo offers some guidance on when IPsec should and > should not be specified. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-bellovin-useipsec-04.txt > > > > --Steven M. Bellovin, http://www.cs.columbia.edu/~smb > > >_______________________________________________ >saag mailing list >saag@mit.edu >https://jis.mit.edu/mailman/listinfo/saag From pekkas@netcore.fi Thu Sep 29 01:48:07 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j8T5m65j006381 for ; Thu, 29 Sep 2005 01:48:06 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1])j8T5m1j4029404 for ; Thu, 29 Sep 2005 01:48:02 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j8T5luH14959; Thu, 29 Sep 2005 08:47:56 +0300 Date: Thu, 29 Sep 2005 08:47:56 +0300 (EEST) From: Pekka Savola To: saag@mit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000016 Spam-Alum-Time: 0.535675 cc: distsec@machshav.com Subject: [saag] Distributed Security mailing-list set up X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 29 Sep 2005 05:48:07 -0000 Hi, We're planning to have a BOF on 'Distributed security', and have just set up a mailing-list (please join if interested): https://www.machshav.com/mailman/listinfo.cgi/distsec There are two documents, both under revision right now: http://www.ietf.org/internet-drafts/draft-vives-distsec-framework-00.txt http://www.ietf.org/internet-drafts/draft-savola-distsec-threat-model-00.txt The draft charter will also be posted shortly. A wider announcements will be sent out in a while, once things are more finalized. -- 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 mcr@sandelman.ottawa.on.ca Thu Sep 29 18:40:50 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j8TMen5j013500 for ; Thu, 29 Sep 2005 18:40:49 -0400 (EDT) Received: from lists.sandelman.ca (cod.sandelman.ca [192.139.46.139]) j8TMeihS025233 for ; Thu, 29 Sep 2005 18:40:44 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id j8TMeXM09004 verified OK); Thu, 29 Sep 2005 18:40:39 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 3E316E9955; Thu, 29 Sep 2005 18:40:03 -0400 (EDT) To: Pekka Savola Subject: Re: [saag] Distributed Security mailing-list set up In-Reply-To: Message from Pekka Savola References: X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Thu, 29 Sep 2005 18:40:03 -0400 Message-ID: <12891.1128033603@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.720957 cc: distsec@machshav.com cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 29 Sep 2005 22:40:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Pekka" == Pekka Savola writes: Pekka> We're planning to have a BOF on 'Distributed security', and Pekka> have just set up a mailing-list (please join if interested): Pekka> https://www.machshav.com/mailman/listinfo.cgi/distsec Joining... Has it been gmane.org'ed? Doesn't look like it. I'll ask. I browsed the two drafts briefly, and read the 5 messages of archives. Why should the IETF care? I'm not clear where the bits on the wire that need to be standardized comes in. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQzxtQIqHRg3pndX9AQHA8gP/YBoTIICx1mZcwIqKbS2c+uQVJKi6M2ou d5NAvxsfdQXEg8WMXO/Z4//PJbRdJOlgw3/h9ZVPq9Bo08wCvkdXaFiqHM+oy6Dx 0CFDH6HelSOyEsemnasxmFIHEiMx+IQcag9CWtXlGmdtyRgq3N4HtEJqWBM9l98N CeZ0OwVh1Gw= =ORj/ -----END PGP SIGNATURE----- From pekkas@netcore.fi Fri Sep 30 01:02:10 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j8U5295j016547 for ; Fri, 30 Sep 2005 01:02:09 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1])j8U51xFP009275 for ; Fri, 30 Sep 2005 01:02:00 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j8U50hI06276; Fri, 30 Sep 2005 08:00:45 +0300 Date: Fri, 30 Sep 2005 08:00:43 +0300 (EEST) From: Pekka Savola To: Michael Richardson Subject: Re: [saag] Distributed Security mailing-list set up In-Reply-To: <12891.1128033603@marajade.sandelman.ottawa.on.ca> Message-ID: References: <12891.1128033603@marajade.sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.572456 cc: distsec@machshav.com cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 30 Sep 2005 05:02:11 -0000 On Thu, 29 Sep 2005, Michael Richardson wrote: > Has it been gmane.org'ed? Doesn't look like it. I'll ask. Thanks. > Why should the IETF care? > > I'm not clear where the bits on the wire that need to be standardized > comes in. This is a fair question, and one we'd hopefully discuss at the BOF. The policy exchange protocol, at least, has bits on the wire. Personally, this boils down to whether the different vendors each implementing something like this (Cisco/Microsoft, various anti-virus companies, ...) are interested in having something interoperable. If yes, it may be worth doing the work (and unless a better place is found, the IETF could be it). If not, I don't think there's any sense for us to do anything (except maybe an informational framework document). Our initial discussions with the companies have indicated that there seems to be rather high interest in the work, but we'll see.. -- 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 paul.hoffman@vpnc.org Tue Oct 11 18:21:05 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9BMKx5j000067 for ; Tue, 11 Oct 2005 18:21:04 -0400 (EDT) Received: from above.proper.com (above.proper.com [208.184.76.39]) j9BMKsrK021155 for ; Tue, 11 Oct 2005 18:20:55 -0400 (EDT) Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9BMKrpD040893 for ; Tue, 11 Oct 2005 15:20:54 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 11 Oct 2005 15:20:48 -0700 To: saag@mit.edu From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.521 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.629941 Subject: [saag] Fwd: New Public Review Issue: UTR #36, UTS #39 (Security) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 11 Oct 2005 22:21:06 -0000 Of interest to many in this group: >To: unicode@unicode.org >Subject: New Public Review Issue: UTR #36, UTS #39 (Security) >Date: Tue, 11 Oct 2005 13:27:33 -0700 >From: Rick McGowan >X-archive-position: 231 >X-ecartis-version: Ecartis v1.0.0 >Sender: unicore-bounce@unicode.org >X-original-sender: rick@unicode.org > >The Unicode Technical Committee has posted a new issue for public review >and comment. Details are on the following web page: > > http://www.unicode.org/review/ > >Review period for the new item closes on October 24, 2005. > >Please see the page for links to discussion and relevant documents. >Briefly, the new issue is: > > >77 Proposed Draft UTS #39 and Proposed Update UTR #36 (close 2005-10-24) > >The sections of UTR #36: Unicode Security Considerations that pertain to >security functions have been split off into a new proposed draft UTS #39: >Unicode Security Mechanisms. In addition, a section on some of the problems >with language-based security has been added to UTR #36. We would >appreciate feedback on the proposed changes, and comments on the security >issues highlighted in UTR #36. See: > > http://www.unicode.org/reports/tr36/tr36-4.html > http://www.unicode.org/reports/tr39/tr39-1.html > > >If you have comments for official UTC consideration, please post them by >submitting your comments through our feedback & reporting page: > > http://www.unicode.org/reporting.html > >If you wish to discuss issues on the Unicode mail list, then please use >the following link to subscribe (if necessary). Please be aware that >discussion comments on the Unicode mail list are not automatically recorded >as input to the UTC. You must use the reporting link above to generate >comments for UTC consideration. > > http://www.unicode.org/consortium/distlist.html > >Regards, > Rick McGowan > Unicode, Inc. From housley@vigilsec.com Thu Oct 13 14:25:10 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9DIP95j017597 for ; Thu, 13 Oct 2005 14:25:09 -0400 (EDT) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) j9DIP0H9015085 for ; Thu, 13 Oct 2005 14:25:00 -0400 (EDT) Received: (qmail 28940 invoked by uid 0); 13 Oct 2005 18:24:54 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.99.91) by woodstock.binhost.com with SMTP; 13 Oct 2005 18:24:54 -0000 Message-Id: <6.2.1.2.2.20051013142401.06d71eb0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 13 Oct 2005 14:24:56 -0400 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.612172 Subject: [saag] Phishing attack targets one-time passwords X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 13 Oct 2005 18:25:10 -0000 URL: http://www.theregister.co.uk/2005/10/12/outlaw_phishing/ Phishing attack targets one-time passwords ========================================== A Swedish internet bank was forced to shut down its website for a short time last week after its one-time password security system was targeted by a new type of phishing scam, according to reports. Phishing usually occurs when a fraudster sends an email that contains a link to a fraudulent website where the users are asked to provide personal account information. The email and website are usually disguised to appear to recipients as though they are from a bank or another well-known brand. However last week, according to a blog posting by Finnish security firm F-Secure, fraudsters unleashed a new version of the scam targeting Swedish customers of the online bank, part of Nordic financial services group Nordea. Recipients were directed to several fake websites, thought to be based in South Korea, and asked not only for their account details, but also for the next password on their list of one-time passwords. F-Secure explains that Nordea's online banking customers are given a scratch sheet, which contains a certain number of hidden passwords. As customers use the service they uncover the next password in the list, which gives them access to their account. According to F-Secure: "Regardless of what you entered, the site would complain about the scratch code and asked you to try the next one. In reality the bad boys were trying to collect several scratch codes for their own use." The bank discovered the attack last Monday night, and shut the site for around 12 hours. This is said to be the first time that a phishing scam has targeted such a password system, which is intended to be more secure than a normal fixed-password scheme. F-Secure says it is also the first time that a phishing scam has been sent in Swedish. Normally the fraudulent emails are written in English. From RGuida@CORUS.JNJ.com Thu Oct 13 15:32:48 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9DJWl5j018199 for ; Thu, 13 Oct 2005 15:32:47 -0400 (EDT) Received: from ncsusraimge01.jnj.com (ncsusraimge01.jnj.com [148.177.2.21]) j9DJWgii005017 for ; Thu, 13 Oct 2005 15:32:42 -0400 (EDT) Received: from ncsusrawsa2.na.jnj.com ([10.4.21.2])j9DJWem1021128; Thu, 13 Oct 2005 15:32:40 -0400 (EDT) Received: from (10.4.20.170) by ncsusrawsa2.na.jnj.com via smtp id 1c3c_8043d0a6_3c20_11da_8118_0002b3ec9bcc; Thu, 13 Oct 2005 15:35:24 -0400 Received: by ncsusraexims2.na.jnj.com with Internet Mail Service (5.5.2658.3) id <45SRDP7S>; Thu, 13 Oct 2005 15:32:39 -0400 Message-ID: <8C9266D8DEC7B3439D3A49E5706844100556C29F@jjcusnbexs4.jjcus.na.jnj.com> From: "Guida, Richard [JJCUS]" To: "'Russ Housley'" , saag@mit.edu Subject: RE: [saag] Phishing attack targets one-time passwords Date: Thu, 13 Oct 2005 15:32:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.3) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D02C.35DE3F70" X-Spam-Score: -2.023 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.716045 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 13 Oct 2005 19:32:48 -0000 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5D02C.35DE3F70 Content-Type: text/plain; charset="iso-8859-1" Russ - thanks very much, and if I understand this correctly, this attack works on non-dynamic one-time passwords (i.e., a one-time password list) but would be hard to work with dynamically generated one-time passwords (like RSA SecurID) that are time-sensitive (e.g., only good for thirty seconds) unless the miscreant could replay a 30 second password quickly enough. Regardless - this attack obviously does not work on any asymmetric crypto approaches like digital certs/private keys - yet another reason to promote that technology (forgive my taking the opportunity to shamelessly do so...). -----Original Message----- From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu]On Behalf Of Russ Housley Sent: Thursday, October 13, 2005 2:25 PM To: saag@mit.edu Subject: [saag] Phishing attack targets one-time passwords URL: http://www.theregister.co.uk/2005/10/12/outlaw_phishing/ Phishing attack targets one-time passwords ========================================== A Swedish internet bank was forced to shut down its website for a short time last week after its one-time password security system was targeted by a new type of phishing scam, according to reports. Phishing usually occurs when a fraudster sends an email that contains a link to a fraudulent website where the users are asked to provide personal account information. The email and website are usually disguised to appear to recipients as though they are from a bank or another well-known brand. However last week, according to a blog posting by Finnish security firm F-Secure, fraudsters unleashed a new version of the scam targeting Swedish customers of the online bank, part of Nordic financial services group Nordea. Recipients were directed to several fake websites, thought to be based in South Korea, and asked not only for their account details, but also for the next password on their list of one-time passwords. F-Secure explains that Nordea's online banking customers are given a scratch sheet, which contains a certain number of hidden passwords. As customers use the service they uncover the next password in the list, which gives them access to their account. According to F-Secure: "Regardless of what you entered, the site would complain about the scratch code and asked you to try the next one. In reality the bad boys were trying to collect several scratch codes for their own use." The bank discovered the attack last Monday night, and shut the site for around 12 hours. This is said to be the first time that a phishing scam has targeted such a password system, which is intended to be more secure than a normal fixed-password scheme. F-Secure says it is also the first time that a phishing scam has been sent in Swedish. Normally the fraudulent emails are written in English. _______________________________________________ saag mailing list saag@mit.edu https://jis.mit.edu/mailman/listinfo/saag ------_=_NextPart_001_01C5D02C.35DE3F70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [saag] Phishing attack targets one-time passwords

Russ - thanks very much, and if I understand this = correctly, this attack works on non-dynamic one-time passwords (i.e., a = one-time password list) but would be hard to work with dynamically = generated one-time passwords (like RSA SecurID) that are time-sensitive = (e.g., only good for thirty seconds) unless the miscreant could replay = a 30 second password quickly enough.  Regardless - this attack = obviously does not work on any asymmetric crypto approaches like = digital certs/private keys - yet another reason to promote that = technology (forgive my taking the opportunity to shamelessly do = so...).



-----Original Message-----
From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu]On = Behalf Of
Russ Housley
Sent: Thursday, October 13, 2005 2:25 PM
To: saag@mit.edu
Subject: [saag] Phishing attack targets one-time = passwords


URL: http://www.theregister.co.uk/2005/10/12/outlaw_phishin= g/


Phishing attack targets one-time passwords
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

A Swedish internet bank was forced to shut down its = website for a short
time last week after its one-time password security = system was targeted by
a new type of phishing scam, according to = reports.

Phishing usually occurs when a fraudster sends an = email that contains a
link to a fraudulent website where the users are = asked to provide personal
account information. The email and website are = usually disguised to appear
to recipients as though they are from a bank or = another well-known brand.

However last week, according to a blog posting by = Finnish security firm
F-Secure, fraudsters unleashed a new version of the = scam targeting Swedish
customers of the online bank, part of Nordic = financial services group Nordea.

Recipients were directed to several fake websites, = thought to be based in
South Korea, and asked not only for their account = details, but also for the
next password on their list of one-time = passwords.

F-Secure explains that Nordea's online banking = customers are given a
scratch sheet, which contains a certain number of = hidden passwords. As
customers use the service they uncover the next = password in the list, which
gives them access to their account.

According to F-Secure: "Regardless of what you = entered, the site would
complain about the scratch code and asked you to try = the next one. In
reality the bad boys were trying to collect several = scratch codes for their
own use."

The bank discovered the attack last Monday night, and = shut the site for
around 12 hours.

This is said to be the first time that a phishing = scam has targeted such a
password system, which is intended to be more secure = than a normal
fixed-password scheme. F-Secure says it is also the = first time that a
phishing scam has been sent in Swedish. Normally the = fraudulent emails are
written in English.

_______________________________________________
saag mailing list
saag@mit.edu
https://jis.mit.edu/mailman/listinfo/saag

------_=_NextPart_001_01C5D02C.35DE3F70-- From alex@alten.org Sun Oct 16 02:51:24 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9G6pJ5j009226 for ; Sun, 16 Oct 2005 02:51:24 -0400 (EDT) Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) j9G6pEL1004200 for ; Sun, 16 Oct 2005 02:51:15 -0400 (EDT) Received: from alten.alten.org (c-24-5-235-118.hsd1.ca.comcast.net[24.5.235.118]) by comcast.net (rwcrmhc13) with SMTP id <2005101606511401500rao1re>; Sun, 16 Oct 2005 06:51:14 +0000 Message-Id: <4.3.2.7.1.20051015234218.0525d718@mail.alten.org> X-Sender: alex@alten.org@mail.alten.org X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 16 Oct 2005 00:00:40 -0700 To: cryptography@metzdowd.com, saag@mit.edu From: Alex Alten Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.002500 Spam-Alum-Time: 0.516731 cc: cfrg@ietf.org Subject: [saag] status of SSL vs SHA-1/MD-5, etc.? X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 16 Oct 2005 06:51:25 -0000 Everyone, So where do we stand with secure networking protocols vs SHA-1/MD-5? Is SSL at risk? Is TLS OK (because of HMAC)? SSH, IPSec, etc? - Alex -- - Alex Alten From smb@cs.columbia.edu Sun Oct 16 09:46:25 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9GDkO5j011291 for ; Sun, 16 Oct 2005 09:46:24 -0400 (EDT) Received: from machshav.com (machshav.com [147.28.0.16]) j9GDkFKr008329 for ; Sun, 16 Oct 2005 09:46:15 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B19E2FB283; Sun, 16 Oct 2005 13:46:14 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A759EFB27D; Sun, 16 Oct 2005 13:46:13 +0000 (UTC) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 442FB3BFD37; Sun, 16 Oct 2005 09:46:12 -0400 (EDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Alex Alten Subject: Re: [saag] status of SSL vs SHA-1/MD-5, etc.? In-Reply-To: Your message of "Sun, 16 Oct 2005 00:00:40 PDT." <4.3.2.7.1.20051015234218.0525d718@mail.alten.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 16 Oct 2005 09:46:12 -0400 Sender: smb@cs.columbia.edu Message-Id: <20051016134612.442FB3BFD37@berkshire.machshav.com> X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.594760 cc: cryptography@metzdowd.com cc: cfrg@ietf.org cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 16 Oct 2005 13:46:26 -0000 In message <4.3.2.7.1.20051015234218.0525d718@mail.alten.org>, Alex Alten write s: >Everyone, > >So where do we stand with secure networking protocols vs SHA-1/MD-5? > >Is SSL at risk? Is TLS OK (because of HMAC)? > >SSH, IPSec, etc? > The major risk that I know of is for signed objects, which generally means signed email, i.e., S/MIME and PGP. MD5 absolutely should not be used for email, period. The current attack on SHA-1 is probably infeasible for most attackers; that said, it would be better to have something stronger. We'll know more about that in two weeks, after NIST's Hash Function Workshop. As I mentioned on the cryptography list -- did you really have to post your query to all three lists? -- a few days ago, NSA rated SHA-384 as suitable for Top Secret traffic, though I'll note that the authenticity of a message rarely has the long-term need for security as does confidentiality. As Eric Rescorla and I showed, though, none of the network protocols are ready for deployment of a new hash function. That is, newer versions of OpenSSL support may SHA-256, but there's no way to negotiate such usage if you don't know the status of the system to which you're talking. My own estimate is that it will take 4-8 years before everything just works: 1 year for the IETF to standardize negotiation mechanisms, 1-2 years for design, code, and test by vendors, and 2-5 years for deployment by the user community -- note that most machines are *never* upgrade, only replaced. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb From ben@algroup.co.uk Sun Oct 16 12:07:23 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9GG7M5j012360 for ; Sun, 16 Oct 2005 12:07:22 -0400 (EDT) Received: from mail.links.org (mail.links.org [217.155.92.109]) j9GG7Jmp001174 for ; Sun, 16 Oct 2005 12:07:19 -0400 (EDT) Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 6E17033C1A; Sun, 16 Oct 2005 17:07:18 +0100 (BST) Message-ID: <43527ABA.9040303@algroup.co.uk> Date: Sun, 16 Oct 2005 17:07:22 +0100 From: Ben Laurie User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: "Steven M. Bellovin" Subject: Re: [saag] status of SSL vs SHA-1/MD-5, etc.? References: <20051016134612.442FB3BFD37@berkshire.machshav.com> In-Reply-To: <20051016134612.442FB3BFD37@berkshire.machshav.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.53 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.537006 cc: cryptography@metzdowd.com cc: cfrg@ietf.org cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 16 Oct 2005 16:07:23 -0000 Steven M. Bellovin wrote: > As Eric Rescorla and I showed, though, none of the network protocols > are ready for deployment of a new hash function. That is, newer > versions of OpenSSL support may SHA-256, but there's no way to > negotiate such usage if you don't know the status of the system to > which you're talking. None of the ones you looked at you mean - your survey wasn't comprehensive. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 smb@cs.columbia.edu Sun Oct 16 14:25:02 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9GIP15j013591 for ; Sun, 16 Oct 2005 14:25:01 -0400 (EDT) Received: from machshav.com (machshav.com [147.28.0.16]) j9GIOvG5005947 for ; Sun, 16 Oct 2005 14:24:57 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id F189CFB285; Sun, 16 Oct 2005 18:24:56 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 69EC3FB27D; Sun, 16 Oct 2005 18:24:56 +0000 (UTC) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 2D6DC3BFD37; Sun, 16 Oct 2005 14:24:55 -0400 (EDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Ben Laurie Subject: Re: [saag] status of SSL vs SHA-1/MD-5, etc.? In-Reply-To: Your message of "Sun, 16 Oct 2005 17:07:22 BST." <43527ABA.9040303@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 16 Oct 2005 14:24:55 -0400 Sender: smb@cs.columbia.edu Message-Id: <20051016182455.2D6DC3BFD37@berkshire.machshav.com> X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.535845 cc: cryptography@metzdowd.com cc: cfrg@ietf.org cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 16 Oct 2005 18:25:03 -0000 In message <43527ABA.9040303@algroup.co.uk>, Ben Laurie writes: >Steven M. Bellovin wrote: >> As Eric Rescorla and I showed, though, none of the network protocols >> are ready for deployment of a new hash function. That is, newer >> versions of OpenSSL support may SHA-256, but there's no way to >> negotiate such usage if you don't know the status of the system to >> which you're talking. > >None of the ones you looked at you mean - your survey wasn't comprehensive. > No, it wasn't comprehensive, but we looked at the major IETF protocols. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb From rgm-sec@htt-consult.com Sun Oct 23 00:28:45 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9N4Sf5j016054 for ; Sun, 23 Oct 2005 00:28:45 -0400 (EDT) Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) j9N4SYsI009947 for ; Sun, 23 Oct 2005 00:28:34 -0400 (EDT) Received: from nc4010.htt-consult.com ([65.84.78.244]) by htt-consult.com ; Sun, 23 Oct 2005 00:28:33 -0400 Message-Id: <6.2.3.4.2.20051023002639.01d052d0@homebase.htt-consult.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sun, 23 Oct 2005 00:28:23 -0400 To: saag@mit.edu From: Robert Moskowitz Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Rcpt-To: X-Spam-Score: -0.74 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000014 Spam-Alum-Time: 0.523098 Subject: [saag] FWD: Skype Security Evaluation X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 23 Oct 2005 04:28:46 -0000 http://www.skype.net/security/files/2005-031%20security%20evaluation.pdf I just have had time to scan through it. Datagram Integrity seems weak. Seems like author pointed this out to skype people. Robert Moskowitz ICSAlabs/A Division of TruSecure Corporation Security Interest EMail: rgm-sec@htt-consult.com From djm@mindrot.org Sun Oct 23 22:39:53 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9O2dp5j024110 for ; Sun, 23 Oct 2005 22:39:52 -0400 (EDT) Received: from mail.mindrot.org (fuyu.mindrot.org [203.217.30.81]) j9O2dhNN002882 for ; Sun, 23 Oct 2005 22:39:44 -0400 (EDT) Received: by mail.mindrot.org (Postfix, from userid 1000) id 68EEC17E606; Mon, 24 Oct 2005 12:39:42 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.mindrot.org (Postfix) with ESMTP id 6178517E604; Mon, 24 Oct 2005 12:39:42 +1000 (EST) Date: Mon, 24 Oct 2005 12:39:42 +1000 (EST) From: Damien Miller To: cryptography@metzdowd.com In-Reply-To: <067801c5d829$b86235f0$6401a8c0@GQ7000> Message-ID: References: <20051023153121.GW2249@leitl.org> <067801c5d829$b86235f0$6401a8c0@GQ7000> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.622960 cc: saag@mit.edu Subject: [saag] Re: [smb@cs.columbia.edu: Skype security evaluation] X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 24 Oct 2005 02:39:53 -0000 On Sun, 23 Oct 2005, Joseph Ashwood wrote: > ----- Original Message ----- Subject: [Tom Berson Skype Security Evaluation] > > Tom Berson's conclusion is incorrect. One needs only to take a look at the > publicly available information. I couldn't find an immediate reference > directly from the Skype website, but it uses 1024-bit RSA keys, the coverage > of breaking of 1024-bit RSA has been substantial. The end, the security is > flawed. Of course I told them this now years ago, when I told them that > 1024-bit RSA should be retired in favor of larger keys, and several other > people as well told them. More worrying is the disconnect between the front page summary and the body of the review. If one only reads the summary, then one would only see the gushing praise and not the SSH protocol 1-esque use of a weak CRC as a integrity mechanism (section 3.4.4) or what sounds suspiciously like a exploitable signed vs. unsigned issue in protocol parsing (section 3.4.6). Also disappointing is the focus on the correct implementation of cryptographic primitives (why not just use tested commercial or open-source implementations?) to the exclusion of other more interesting questions (at least to me): - What properties does the proprietary key agreement protocol offer (it sounds a bit like an attenuated version of the SSH-1 KEX protocol and, in particular, doesn't appear to offer PFS). - Does the use of RC4 follow Mantin's recommendations to discard the early, correlated keystream? - How does the use of RC4 to generate RSA keys work when only 64 bits of entropy are collected from Skype's RNG? (Section 3.1) - Why does Skype "roll its own" entropy collection functions instead of using the platform's standard one? - Ditto the use of standard protocols? (DTLS would seem an especially obvious choice). - What techniques (such as privilege dropping or separation) does Skype use to limit the scope of a network compromise of a Skype client? -d From housley@vigilsec.com Tue Oct 25 12:44:49 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9PGim5j009361 for ; Tue, 25 Oct 2005 12:44:48 -0400 (EDT) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) j9PGikxV008950 for ; Tue, 25 Oct 2005 12:44:46 -0400 (EDT) Received: (qmail 21965 invoked by uid 0); 25 Oct 2005 16:44:41 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.137.237) by woodstock.binhost.com with SMTP; 25 Oct 2005 16:44:41 -0000 Message-Id: <7.0.0.10.2.20051025124107.02d130d8@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Tue, 25 Oct 2005 12:44:42 -0400 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.532847 Subject: [saag] Hash-Based Key Derivation X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 25 Oct 2005 16:44:50 -0000 I wanted call your attention to an individual draft on "Hash-Based Key Derivation." http://www.ietf.org/internet-drafts/draft-dang-nistkdf-00.txt This draft specifies a soon to be NIST-approved algorithm for deriving secret key material from a shared secret using a hash algorithm. This algorithm is in the NIST draft SP 800-56. I encourage review and comment. If you have concerns with this document, then the concerns probably apply to he NIST draft SP 800-56 document too. I am considering sponsoring this document as an Informational RFC. Please let me know if you have any concerns with this proposed action. Thanks, Russ From nw141292@binky.Central.Sun.COM Tue Oct 25 13:36:56 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9PHaq5j009980 for ; Tue, 25 Oct 2005 13:36:56 -0400 (EDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) j9PHail2026625 for ; Tue, 25 Oct 2005 13:36:45 -0400 (EDT) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j9PHaidK012540 for ; Tue, 25 Oct 2005 10:36:44 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) with ESMTP id j9PHahxR015114 for ; Tue, 25 Oct 2005 11:36:43 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) j9PHahju018932; Tue, 25 Oct 2005 12:36:43 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j9PHag32018931; Tue, 25 Oct 2005 12:36:42 -0500 (CDT) Date: Tue, 25 Oct 2005 12:36:42 -0500 From: Nicolas Williams To: Russ Housley Subject: Re: [saag] Hash-Based Key Derivation Message-ID: <20051025173642.GM803@binky.Central.Sun.COM> References: <7.0.0.10.2.20051025124107.02d130d8@vigilsec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7.0.0.10.2.20051025124107.02d130d8@vigilsec.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.571297 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 25 Oct 2005 17:36:57 -0000 On Tue, Oct 25, 2005 at 12:44:42PM -0400, Russ Housley wrote: > I wanted call your attention to an individual draft on "Hash-Based > Key Derivation." > > http://www.ietf.org/internet-drafts/draft-dang-nistkdf-00.txt > > This draft specifies a soon to be NIST-approved algorithm for > deriving secret key material from a shared secret using a hash > algorithm. This algorithm is in the NIST draft SP 800-56. > > I encourage review and comment. If you have concerns with this > document, then the concerns probably apply to he NIST draft SP 800-56 > document too. Comments: - What byte order for the lengths? I'd expect network byte order. - Why should IDs be required inputs for the KDF? There are legitimate instances where we may not have IDs or where the parties may be allowed to disagree about each other's IDs (e.g., BTNS). I'd much rather the draft say nothing at all about IDs beyond saying that protocols that use the HKDF and which want to bind IDs into the KDF should define their 'SharedInfo' accordingly. - Section 3 seems unnecessary. How about replacing it with informative references to uses of KDFs? Or are we sure that this KDF is only applicable to some set of uses? - Why not include the value of 'reps' in the hash input? Nico -- From sommerfeld@sun.com Tue Oct 25 13:50:51 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9PHop5j010090 for ; Tue, 25 Oct 2005 13:50:51 -0400 (EDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) j9PHofhI005490 for ; Tue, 25 Oct 2005 13:50:42 -0400 (EDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j9PHoe3F010681; Tue, 25 Oct 2005 11:50:41 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) ESMTP id j9PHoeKQ029372; Tue, 25 Oct 2005 13:50:40 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1])j9PHoetf001811; Tue, 25 Oct 2005 13:50:40 -0400 (EDT) Subject: Re: [saag] Hash-Based Key Derivation From: Bill Sommerfeld To: Russ Housley In-Reply-To: <7.0.0.10.2.20051025124107.02d130d8@vigilsec.com> References: <7.0.0.10.2.20051025124107.02d130d8@vigilsec.com> Content-Type: text/plain Message-Id: <1130262639.1164.34.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.323 Date: Tue, 25 Oct 2005 13:50:40 -0400 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.598190 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 25 Oct 2005 17:50:52 -0000 On Tue, 2005-10-25 at 12:44, Russ Housley wrote: > I wanted call your attention to an individual draft on "Hash-Based > Key Derivation." > > http://www.ietf.org/internet-drafts/draft-dang-nistkdf-00.txt > > This draft specifies a soon to be NIST-approved algorithm for > deriving secret key material from a shared secret using a hash > algorithm. This algorithm is in the NIST draft SP 800-56. > > I encourage review and comment. If you have concerns with this > document, then the concerns probably apply to he NIST draft SP 800-56 > document too. I observe that appendix B.5 and B.6 of NIST 800-56 contain the ominous words: Note that PRF-IKE is allowed for use with IKEv2 only. and Warning!! PRF-TLS is allowed for use with TLS only. So, did we blow it when designing IKE and TLS, or is this just an attempt to head off KDF proliferation? Apparently related to this, in appendix B.1, I found the following design consideration: The ordering of the input to a hash function used by a KDF should put the more variable input components first (leftmost) and the least variable components last (rightmost). For example, a counter should usually be placed to the left of a shared secret. This is stated as a should , as there can be reasons to order the input differently (for example, when the shared secret is used as the key of a keyed-hash function); however, in the absence of specific reasons otherwise, this is the preferred ordering. if cryptographers come to anything resembling consensus on the above design considerations, I'd think that, at the very least, this new I-D should pull in more of the meat of appendix B to 800-56 specifically because they form "security considerations" for existing IETF protocols which (for instance) put the hash function inputs into a different order. - Bill From housley@vigilsec.com Tue Oct 25 14:07:33 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9PI7W5j010279 for ; Tue, 25 Oct 2005 14:07:32 -0400 (EDT) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) j9PI7ThI013573 for ; Tue, 25 Oct 2005 14:07:29 -0400 (EDT) Received: (qmail 6743 invoked by uid 0); 25 Oct 2005 18:07:24 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.138.214) by woodstock.binhost.com with SMTP; 25 Oct 2005 18:07:24 -0000 Message-Id: <7.0.0.10.2.20051025140105.02cf0b48@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Tue, 25 Oct 2005 14:07:14 -0400 To: Nicolas Williams From: Russ Housley Subject: Re: [saag] Hash-Based Key Derivation In-Reply-To: <20051025173642.GM803@binky.Central.Sun.COM> References: <7.0.0.10.2.20051025124107.02d130d8@vigilsec.com> <20051025173642.GM803@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.559909 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 25 Oct 2005 18:07:33 -0000 Nico: I have had this discussion already, so I'll summarize the answer that I got. The desire is to ensure that both parties using the KDF have the same context. So, in cases where there is not a meaningful identifier, a constant value is provided. For example, an ephemeral key might use "Ephemeral" for the KDF input identifier. This ensures that both parties believe that an ephemeral value is being used. On the other hand, when there is a relevant identifier, such as an IP address, email address, domain name, or distinguished name, then the both parties are able to confirm this context. If both parties have different context, which leads to different KDF inputs, then the resulting symmetric key will be different. Russ At 01:36 PM 10/25/2005, Nicolas Williams wrote: > - Why should IDs be required inputs for the KDF? There are legitimate > instances where we may not have IDs or where the parties may be > allowed to disagree about each other's IDs (e.g., BTNS). > > I'd much rather the draft say nothing at all about IDs beyond saying > that protocols that use the HKDF and which want to bind IDs into the > KDF should define their 'SharedInfo' accordingly. From tim.polk@nist.gov Tue Oct 25 17:26:10 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9PLQ95j011642 for ; Tue, 25 Oct 2005 17:26:09 -0400 (EDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) j9PLQ6De010556 for ; Tue, 25 Oct 2005 17:26:07 -0400 (EDT) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j9PLQ2GO003275; Tue, 25 Oct 2005 17:26:02 -0400 Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j9PLPJG4026352; Tue, 25 Oct 2005 17:25:19 -0400 (EDT) Message-Id: <5.1.0.14.2.20051025164331.03329710@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 25 Oct 2005 17:29:07 -0400 To: Bill Sommerfeld , Russ Housley From: Tim Polk Subject: Re: [saag] Hash-Based Key Derivation In-Reply-To: <1130262639.1164.34.camel@thunk> References: <7.0.0.10.2.20051025124107.02d130d8@vigilsec.com> <7.0.0.10.2.20051025124107.02d130d8@vigilsec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.621273 cc: qdang@nist.gov cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 25 Oct 2005 21:26:11 -0000 Bill, At 01:50 PM 10/25/2005 -0400, Bill Sommerfeld wrote: >(stuff deleted) > >I observe that appendix B.5 and B.6 of NIST 800-56 contain the ominous >words: > > Note that PRF-IKE is allowed for use with IKEv2 only. > >and > > Warning!! PRF-TLS is allowed for use with TLS only. > >So, did we blow it when designing IKE and TLS, or is this just an >attempt to head off KDF proliferation? We are attempting to head off KDF proliferation while ensuring that cryptomodules that support PRF-IKE and PRF-TLS can still be validated under FIPS 140 after 800-56 is finalized. I'm not a FIPS 140 guy, but as I understand it: Since we currently don't have a standard, cryptomodules can currently implement any KDF they choose. Once this document is finalized, cryptomodules would be limited to "approved" KDFs (at least in FIPS mode). Explicitly calling them out makes them approved within the context of their protocols. PRF-IKE and PRF-TLS are considered acceptable in the context of their protocols or we would not have included that caveat. However, there may be other protocols where application of PRF-IKE or PRF-TLS would not be appropriate. The "preferred" KDF is designed for the more general case. If new protocols stick with the preferred KDF, we will have greater confidence and not need to perform so much contextual review. >Apparently related to this, in appendix B.1, I found the following >design consideration: > > The ordering of the input to a hash function used by a KDF should > put the more variable input components first (leftmost) and the > least variable components last (rightmost). For example, a counter > should usually be placed to the left of a shared secret. This is > stated as a should , as there can be reasons to order the input > differently (for example, when the shared secret is used as the key > of a keyed-hash function); however, in the absence of specific > reasons otherwise, this is the preferred ordering. > >if cryptographers come to anything resembling consensus on the above >design considerations, I'd think that, at the very least, this new I-D >should pull in more of the meat of appendix B to 800-56 specifically >because they form "security considerations" for existing IETF protocols >which (for instance) put the hash function inputs into a different >order. Thanks for pointing this out. We'll go read Appendix B and see what material we can add to the body of the document. > - Bill > Tim >_______________________________________________ >saag mailing list >saag@mit.edu >https://jis.mit.edu/mailman/listinfo/saag From sommerfeld@sun.com Tue Oct 25 19:33:55 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9PNXs5j012766 for ; Tue, 25 Oct 2005 19:33:54 -0400 (EDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) j9PNXkPR017336 for ; Tue, 25 Oct 2005 19:33:46 -0400 (EDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j9PNXjdK012122; Tue, 25 Oct 2005 16:33:45 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) ESMTP id j9PNXiUs029090; Tue, 25 Oct 2005 19:33:44 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1])j9PNXhdc003907; Tue, 25 Oct 2005 19:33:44 -0400 (EDT) Subject: Re: [saag] Hash-Based Key Derivation From: Bill Sommerfeld To: Tim Polk In-Reply-To: <5.1.0.14.2.20051025164331.03329710@email.nist.gov> References: <7.0.0.10.2.20051025124107.02d130d8@vigilsec.com> <7.0.0.10.2.20051025124107.02d130d8@vigilsec.com> <5.1.0.14.2.20051025164331.03329710@email.nist.gov> Content-Type: text/plain Message-Id: <1130283223.1164.269.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.323 Date: Tue, 25 Oct 2005 19:33:43 -0400 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.565467 cc: qdang@nist.gov cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 25 Oct 2005 23:33:55 -0000 On Tue, 2005-10-25 at 17:29, Tim Polk wrote: > We are attempting to head off KDF proliferation while ensuring that > cryptomodules that support PRF-IKE and PRF-TLS can still be validated under > FIPS 140 after 800-56 is finalized. I'm not a FIPS 140 guy, but as I > understand it: > > Since we currently don't have a standard, cryptomodules can > currently implement any KDF they choose. Once this document > is finalized, cryptomodules would be limited to "approved" KDFs > (at least in FIPS mode). Explicitly calling them out > makes them approved within the context of their protocols. Hmm. So other protocols with custom KDF's are left "out in the cold" in FIPS mode once this goes through? For something close to home for me, SSH v2 does something different, and, judging by the design criteria in the NIST document, not exactly optimal. See draft-ietf-secsh-transport-24.txt, section 7.2. I bet there are others. - Bill From tim.polk@nist.gov Wed Oct 26 09:53:22 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9QDrL5j018919 for ; Wed, 26 Oct 2005 09:53:21 -0400 (EDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) j9QDrJuJ013031 for ; Wed, 26 Oct 2005 09:53:19 -0400 (EDT) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j9QDrCXi007385; Wed, 26 Oct 2005 09:53:15 -0400 Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j9QDqsG4023008; Wed, 26 Oct 2005 09:52:54 -0400 (EDT) Message-Id: <5.1.0.14.2.20051026094037.03fa2b18@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 26 Oct 2005 09:56:40 -0400 To: Bill Sommerfeld From: Tim Polk Subject: Re: [saag] Hash-Based Key Derivation In-Reply-To: <1130283223.1164.269.camel@thunk> References: <5.1.0.14.2.20051025164331.03329710@email.nist.gov> <7.0.0.10.2.20051025124107.02d130d8@vigilsec.com> <7.0.0.10.2.20051025124107.02d130d8@vigilsec.com> <5.1.0.14.2.20051025164331.03329710@email.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.632112 cc: qdang@nist.gov cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 26 Oct 2005 13:53:23 -0000 At 07:33 PM 10/25/2005 -0400, Bill Sommerfeld wrote: >On Tue, 2005-10-25 at 17:29, Tim Polk wrote: > > We are attempting to head off KDF proliferation while ensuring that > > cryptomodules that support PRF-IKE and PRF-TLS can still be validated > under > > FIPS 140 after 800-56 is finalized. I'm not a FIPS 140 guy, but as I > > understand it: > > > > Since we currently don't have a standard, cryptomodules can > > currently implement any KDF they choose. Once this document > > is finalized, cryptomodules would be limited to "approved" KDFs > > (at least in FIPS mode). Explicitly calling them out > > makes them approved within the context of their protocols. > >Hmm. So other protocols with custom KDF's are left "out in the cold" >in FIPS mode once this goes through? NIST would need to explicitly review the KDF used in that protocol to ensure we could live with it. That is a lot of work, which is a big motivator for minimizing KDF proliferation. For critical protocols we will be forced to perform that exercise. Some others will simply not be supported in FIPS mode. >For something close to home for me, SSH v2 does something different, >and, judging by the design criteria in the NIST document, not exactly >optimal. See draft-ietf-secsh-transport-24.txt, section 7.2. We will take a look! Considering that it is in the RFC editor's queue, I gather we are a bit late to impact this specification, but it is a good example for the discussion. >I bet there are others. You are certainly correct. I believe that there are many varieties of KDFs with unique characteristics, each of which may - or may not - be acceptable within the context of the protocol. We hope that the KDF specified in the ID is sufficiently flexible and robust to apply in most protocols, simplifying future analysis and avoiding potential problems. I think of this ID as a KDF cookbook, so that future protocol designers won't need to invent their own KDF. > - Bill Tim From sommerfeld@sun.com Wed Oct 26 10:18:39 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9QEIc5j019169 for ; Wed, 26 Oct 2005 10:18:38 -0400 (EDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) j9QEIZuJ008446 for ; Wed, 26 Oct 2005 10:18:36 -0400 (EDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j9QEIYdK017866 for ; Wed, 26 Oct 2005 07:18:35 -0700 (PDT) Received: from localhost.east.sun.com (punchin-sommerfeld.East.Sun.COM [129.148.19.3])ESMTP id j9QEIYUs029681 for ; Wed, 26 Oct 2005 10:18:34 -0400 (EDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) j9QEIBel022422; Wed, 26 Oct 2005 10:18:11 -0400 (EDT) Received: (from sommerfeld@localhost)j9QEIBXk022421; Wed, 26 Oct 2005 10:18:11 -0400 (EDT) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: [saag] Hash-Based Key Derivation From: Bill Sommerfeld To: Tim Polk In-Reply-To: <5.1.0.14.2.20051026094037.03fa2b18@email.nist.gov> References: <5.1.0.14.2.20051025164331.03329710@email.nist.gov> <7.0.0.10.2.20051025124107.02d130d8@vigilsec.com> <7.0.0.10.2.20051025124107.02d130d8@vigilsec.com> <5.1.0.14.2.20051025164331.03329710@email.nist.gov> <5.1.0.14.2.20051026094037.03fa2b18@email.nist.gov> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1130336290.17423.108.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.324 Date: Wed, 26 Oct 2005 10:18:10 -0400 X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.535755 cc: qdang@nist.gov cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 26 Oct 2005 14:18:40 -0000 On Wed, 2005-10-26 at 09:56, Tim Polk wrote: > >For something close to home for me, SSH v2 does something different, > >and, judging by the design criteria in the NIST document, not exactly > >optimal. See draft-ietf-secsh-transport-24.txt, section 7.2. > > We will take a look! Considering that it is in the RFC editor's queue, I > gather we are a bit late to impact this specification, but it is a good > example for the discussion. Thanks! Note that the key exchange protocol used by ssh is negotiated during connection setup and specifies the hash function to be used as part of the ssh KDF. If there was something actively bad as opposed to merely nonoptimal with the ssh KDF, it would be possible to define new key exchanges which used a different KDF while preserving interoperability with old implementations. - Bill From smb@cs.columbia.edu Wed Oct 26 10:23:16 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9QENF5j019222 for ; Wed, 26 Oct 2005 10:23:16 -0400 (EDT) Received: from machshav.com (machshav.com [147.28.0.16]) j9QEN6uJ018882 for ; Wed, 26 Oct 2005 10:23:07 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5FACAFB284; Wed, 26 Oct 2005 14:23:06 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C6491FB249; Wed, 26 Oct 2005 14:23:05 +0000 (UTC) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 62BC23BFD40; Wed, 26 Oct 2005 10:23:04 -0400 (EDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Tim Polk Subject: Re: [saag] Hash-Based Key Derivation In-Reply-To: Your message of "Wed, 26 Oct 2005 09:56:40 EDT." <5.1.0.14.2.20051026094037.03fa2b18@email.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Oct 2005 10:23:04 -0400 Sender: smb@cs.columbia.edu Message-Id: <20051026142304.62BC23BFD40@berkshire.machshav.com> X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.533708 cc: qdang@nist.gov cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 26 Oct 2005 14:23:17 -0000 In message <5.1.0.14.2.20051026094037.03fa2b18@email.nist.gov>, Tim Polk writes : > >I think of this ID as a KDF cookbook, so that future protocol designers >won't need to invent their own KDF. > And that is a *very* good thing, especially if these documents -- the I-D and 800-56 -- have been reviewed by the open community and, umm, NIST's "friends". We've learned, over the years, just how easy it is to make subtle -- or not so subtle -- mistakes in protocol design. Having a set of *good* building blocks is a tremendous advantage. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb From tim.polk@nist.gov Wed Oct 26 14:31:29 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9QIVS5j021178 for ; Wed, 26 Oct 2005 14:31:28 -0400 (EDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) j9QIVKHY024733 for ; Wed, 26 Oct 2005 14:31:20 -0400 (EDT) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j9QIVFsw023671; Wed, 26 Oct 2005 14:31:17 -0400 Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j9QIUTG4029468; Wed, 26 Oct 2005 14:30:29 -0400 (EDT) Message-Id: <5.1.0.14.2.20051026140245.040fc728@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 26 Oct 2005 14:34:15 -0400 To: Nicolas Williams , Russ Housley From: Tim Polk Subject: Re: [saag] Hash-Based Key Derivation In-Reply-To: <20051025173642.GM803@binky.Central.Sun.COM> References: <7.0.0.10.2.20051025124107.02d130d8@vigilsec.com> <7.0.0.10.2.20051025124107.02d130d8@vigilsec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.611757 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 26 Oct 2005 18:31:29 -0000 Nico, Thanks for the speedy review! At 12:36 PM 10/25/2005 -0500, Nicolas Williams wrote: >Comments: > > - What byte order for the lengths? I'd expect network byte order. That is important, isn't it? Yeah, network byte order is what makes sense to me... we'll get it into the next draft. > - Why should IDs be required inputs for the KDF? There are legitimate > instances where we may not have IDs or where the parties may be > allowed to disagree about each other's IDs (e.g., BTNS). > > I'd much rather the draft say nothing at all about IDs beyond saying > that protocols that use the HKDF and which want to bind IDs into the > KDF should define their 'SharedInfo' accordingly. [Russ's rationale was more eloquent than I will be able to manage, so insert his answer here!] > - Section 3 seems unnecessary. How about replacing it with informative > references to uses of KDFs? Or are we sure that this KDF is only > applicable to some set of uses? The draft NIST SP 800-56, which includes this KDF, is focused on two-party key establishment schemes. Section 3 covers use of the KDF for the types of schemes in 800-56 and adds a scenario with RSA key transport. We thought it was useful to establish guidance - a cookbook, if you will - for common applications of the KDF. A protocol designer can look at the appropriate scenario in Section 3 and find guidance with respect to the optional fields. I wouldn't claim Section 3 is exhaustive even for two-party scenarios, and I suspect we could extend the KDF for a multi-party application. (However, those scenarios are way beyond my expertise.) If we decide to retain section 3, we should clarify that the set of scenarios is not exhaustive. > - Why not include the value of 'reps' in the hash input? I will have to research this one. I don't know if that was considered and rejected, or overlooked entirely. Thanks, Tim >Nico >-- >_______________________________________________ >saag mailing list >saag@mit.edu >https://jis.mit.edu/mailman/listinfo/saag From tim.polk@nist.gov Thu Oct 27 18:24:41 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9RMOe5j003911 for ; Thu, 27 Oct 2005 18:24:40 -0400 (EDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) j9RMOa57018191 for ; Thu, 27 Oct 2005 18:24:36 -0400 (EDT) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j9RMOXDJ031797; Thu, 27 Oct 2005 18:24:34 -0400 Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j9RMO8G4014887; Thu, 27 Oct 2005 18:24:08 -0400 (EDT) Message-Id: <5.1.0.14.2.20051027165303.041d4c78@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 27 Oct 2005 18:27:53 -0400 To: Nicolas Williams From: Tim Polk Subject: Re: [saag] Hash-Based Key Derivation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.599422 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 27 Oct 2005 22:24:42 -0000 Nico, I promised to follow up on why "reps" wasn't explicitly included in the hash inputs. Here's what I've got so far... (1) Note that the counter values 1 through "reps" are used as an input during the iterative process, so in that sense "reps" does influence the value of the derived keying material when viewed as a whole. I suspect that is not what you're looking for... since the values of the Hash-i for i < "reps" are not affected. (2) The optional algorithmID input field, which describes how the keying material is to be parsed and used, implicitly includes data that reflects the amount of keying material used. This is also reflected in "reps". For example, assume the algorithmID indicates that you use the first 128 bits for an HMAC key, then next 256 bits for an AES key, and then use the last 128 bits for a (secret) IV. We have a keydatalen of 512, and "reps" depends directly upon keydatalen and the hash output size. So, you could say that "reps" is an implicit input to the hash whenever the algorithmID field is included. (3) If we want to be sure that the result depends upon the length of the key material desired, we should probably use the actual length of the derived keying material as an input instead of "reps". (Since many different length values will correspond to the same value of "reps", including "reps" as an input could still produce two key strings that are identical excepting the extra bits in the longer result.) Including keydatalen as an input instead of "reps" would ensure distinct results for each set of inputs. While not required, there is nothing in the specification that precludes using the keydatalen as an input (e.g., as a component of SharedInfo). Maybe we should advise including the keydatalen as an input? Or would making algorithmID mandatory be sufficient? Tim Polk From canetti@watson.ibm.com Fri Oct 28 15:49:19 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9SJnI5j012917 for ; Fri, 28 Oct 2005 15:49:18 -0400 (EDT) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) j9SJnFfO003665 for ; Fri, 28 Oct 2005 15:49:15 -0400 (EDT) Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41])ESMTP id j9SJotCN026688; Fri, 28 Oct 2005 15:50:56 -0400 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) with ESMTP id j9SJn2F268652; Fri, 28 Oct 2005 15:49:02 -0400 Received: from mgsmtp00.watson.ibm.com (mgsmtp00.watson.ibm.com [9.2.40.58]) with ESMTP id j9SJn14184088; Fri, 28 Oct 2005 15:49:01 -0400 Received: from prf.watson.ibm.com (prf.watson.ibm.com [9.2.16.112]) j9SJn0CO031549; Fri, 28 Oct 2005 15:49:00 -0400 Received: from localhost (canetti@localhost)id j9SJn0l26890; Fri, 28 Oct 2005 15:49:00 -0400 Date: Fri, 28 Oct 2005 15:48:59 -0400 (EDT) From: canetti To: cfrg@ietf.org, saag@mit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.4 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.676995 Subject: [saag] KDF: Randomness extraction vs. key expansion X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 28 Oct 2005 19:49:20 -0000 I have a high level remark on the KDF I-D and much of the following discussion. (Some of these issues appear in Hugo's recent notes to cfrg, but way too implicitly in my eyes...) The proposed KDF function takes as input a "secret value" SV and stretches it to a longer "pseudorandom" output. The value SV is not assumed to be pseudorandom; rather, it can only have "high entropy". In fact, in typical applications (such as the result of a DH exchange) the entropy of SV given the public values is zero; so SV only has "high computational entropy". This definition of KDF in the I-D lumps together two very different cryptographic tasks: * Randomness extraction: taking an input with "high computational entropy" and generating from it a pseudorandom value. * Key expansion: taking a short pseudorandom value and extending it to a longer pseudorandom value, here the output length is variable anddepends on the application. The second task is rather simple, and can be carried out by straightforward application of a PRF (eg, HMAC or any block cipher) in either counter or feedback mode or a combination of the two. The first task is more intricate, and has different solutions in different settings (see more details below). Furthermore, in typical modeling and security analysis of key exchange protocols the two tasks live on different layers: randomness extraction is part of the key exchange protocol itself, in an effort to output a pseudorandom key to the application that uses the key exchange protocol. in particular, in order to do randomness extraction you dont need to know the specific length of keyng material needed for the application. In contrast, key expansion is done in the layer that uses the "raw key" in order to key the actual transforms in use (encryption mac, etc.). So, it seems to me that lumping randomness extraction and key expansion into a single function is a "cryptographic layer violation". We would be better off having two different functions, one for each task. Some advantages: * We can analyze each function separately, based on different assumptions on cryptographic algorithms in use. This way, we can get better, tighter, and more meaningful analysis rather than just "assuming that this all works". * We can have key expansion functions for different settings, and - more importantly - different randomness expansion functions for different settings. This would bring us closer to the notion of a "toolbox", as proposed earlier on saag. * We dont break the standard layering of cryptographic protocols, thus making cryptographic protocol analysis somewhat easier. One potential disadvantage of two separate functions is efficiency. But I dont think that the price here is significant. The functions we're talking about here are typically very efficeint, much more so than the public key operations that are bound to be part of almost any key exchange. A remark on randomness extraction: Randomness extraction becomes significantly easier if the extracting function has some public random input that is independent from the secret value. In many situations such public randomness is readily available (eg, take the nonces used in the exchange). So it makes much sense to design a randomness extraction function that makes use of such public random values when they are available. (In contrast, there are situations where no such public randomness is avilable, eg, the MQV or HMQV protocols. For such cases, a different design is needed.) Finally, a general remark on modeling and abstractions: I can imagine people read this note and think to themselves: "why is he bothing us with these abstract notions. In the end of the day all that is going to be done is a bunch of hashes and/or block cipher operations, so why not do it explicitly and be done with it." My answer is that these abstractions are our only hope to make sense of this spaghetti of hashes, shifts, concatenations, exponentiations etc. If we want to build systems that will have some pretence of security we have no choice but use the abstractions and abide by them, even is there is some price in complexity. Ran From sommerfeld@sun.com Fri Oct 28 16:58:53 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9SKwq5j013408 for ; Fri, 28 Oct 2005 16:58:52 -0400 (EDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) j9SKwj7h022865 for ; Fri, 28 Oct 2005 16:58:45 -0400 (EDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j9SKwfD7003359; Fri, 28 Oct 2005 14:58:41 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) ESMTP id j9SKwdWa000028; Fri, 28 Oct 2005 16:58:40 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1])j9SKwdRo007967; Fri, 28 Oct 2005 16:58:39 -0400 (EDT) Subject: Re: [saag] KDF: Randomness extraction vs. key expansion From: Bill Sommerfeld To: canetti In-Reply-To: References: Content-Type: text/plain Message-Id: <1130533119.7684.133.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.323 Date: Fri, 28 Oct 2005 16:58:39 -0400 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.546133 cc: cfrg@ietf.org cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 28 Oct 2005 20:58:53 -0000 On Fri, 2005-10-28 at 15:48, canetti wrote: > * Randomness extraction: taking an input with "high computational entropy" > and generating from it a pseudorandom value. > > * Key expansion: taking a short pseudorandom value and extending it to a > longer pseudorandom value, here the output length is variable anddepends > on the application. Some plumbing-level questions: you suggested that random nonces should go into the first stage. would non-random context/identity inputs go there, too? and: would it ever be appropriate to use multiple stages of key expansion? for instance: [diffie-hellman] -> [randomness extraction] -> [key expansion] -> (A, B, C) A -> [key expansion] -> (A1, A2, A3) B -> [key expansion] -> (B1, B2, B3) C -> [key expansion] -> (C1, C2, C3) - Bill From nw141292@binky.Central.Sun.COM Fri Oct 28 18:03:33 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9SM3W5j014045 for ; Fri, 28 Oct 2005 18:03:32 -0400 (EDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) j9SM3Tp7009848 for ; Fri, 28 Oct 2005 18:03:29 -0400 (EDT) Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.central.sun.com [129.147.62.14]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j9SM3TD7000531 for ; Fri, 28 Oct 2005 16:03:29 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) with ESMTP id j9SM3Sgr006254 for ; Fri, 28 Oct 2005 16:03:28 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) j9SM3Sai021420; Fri, 28 Oct 2005 17:03:28 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j9SM3Ric021419; Fri, 28 Oct 2005 17:03:27 -0500 (CDT) Date: Fri, 28 Oct 2005 17:03:27 -0500 From: Nicolas Williams To: Russ Housley Subject: Re: [saag] Hash-Based Key Derivation Message-ID: <20051028220327.GD20236@binky.Central.Sun.COM> References: <7.0.0.10.2.20051025124107.02d130d8@vigilsec.com> <20051025173642.GM803@binky.Central.Sun.COM> <7.0.0.10.2.20051025140105.02cf0b48@vigilsec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7.0.0.10.2.20051025140105.02cf0b48@vigilsec.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.607118 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 28 Oct 2005 22:03:33 -0000 On Tue, Oct 25, 2005 at 02:07:14PM -0400, Russ Housley wrote: > Nico: > > I have had this discussion already, so I'll summarize the answer that I got. > > The desire is to ensure that both parties using the KDF have the same > context. So, in cases where there is not a meaningful identifier, a > constant value is provided. For example, an ephemeral key might use > "Ephemeral" for the KDF input identifier. This ensures that both > parties believe that an ephemeral value is being used. On the other > hand, when there is a relevant identifier, such as an IP address, > email address, domain name, or distinguished name, then the both > parties are able to confirm this context. If both parties have > different context, which leads to different KDF inputs, then the > resulting symmetric key will be different. First, there needs to be a security consideration that the alg-id and the ID value encodings are unambiguous w.r.t. all possible ID types, since there's no ID type in this KDF. Second, this KDF looks close enough to an application of a PRF to an octet string constructed from the KDF's inputs that I have to ask: why not do it that way? Why should the PRF construction be analyzed together with the construction of its inputs, instead of separately. Also, what does this do the GSS-API Kerberos V mechanism's GSS_Pseudo_random() function? Will applications that use GSS_Pseudo_random() as a KDF not be FIPS compliant? Should we re-do the krb5 GSS PRF so it's based on this KDF? How? After all the GSS_Pseudo_random() function has very simple inputs, so since this KDF is not corrently separated from its underlying PRF we can't do this. Or is GSS_Pseudo_random() not an issue if it's output is used as an input to this KDF along with a secret from a separate key exchange? (This would be akin to binding a key exchange to a GSS-API security context.) And if so, why shouldn't we have a NIST standard PRF that we could use to construct GSS mechanisms' GSS_Pseudo_random()? And many other things besides... Nico -- From canetti@watson.ibm.com Sat Oct 29 00:46:09 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9T4k85j017069 for ; Sat, 29 Oct 2005 00:46:08 -0400 (EDT) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) j9T4k59b029761 for ; Sat, 29 Oct 2005 00:46:06 -0400 (EDT) Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40])ESMTP id j9T4lkVw018722; Sat, 29 Oct 2005 00:47:46 -0400 Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) with ESMTP id j9T4jrn39026; Sat, 29 Oct 2005 00:45:53 -0400 Received: from mgsmtp00.watson.ibm.com (mgsmtp00.watson.ibm.com [9.2.40.58]) with ESMTP id j9T4jqN40136; Sat, 29 Oct 2005 00:45:52 -0400 Received: from prf.watson.ibm.com (prf.watson.ibm.com [9.2.16.112]) j9T4jp2J013476; Sat, 29 Oct 2005 00:45:51 -0400 Received: from localhost (canetti@localhost)id j9T4jpG31780; Sat, 29 Oct 2005 00:45:51 -0400 Date: Sat, 29 Oct 2005 00:45:50 -0400 (EDT) From: canetti To: Bill Sommerfeld Subject: Re: [saag] KDF: Randomness extraction vs. key expansion In-Reply-To: <1130533119.7684.133.camel@thunk> Message-ID: References: <1130533119.7684.133.camel@thunk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.4 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.581727 cc: cfrg@ietf.org cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 29 Oct 2005 04:46:09 -0000 Bill, Thanks for the good questions. See inline: On Fri, 28 Oct 2005, Bill Sommerfeld wrote: > On Fri, 2005-10-28 at 15:48, canetti wrote: > > * Randomness extraction: taking an input with "high computational entropy" > > and generating from it a pseudorandom value. > > > > * Key expansion: taking a short pseudorandom value and extending it to a > > longer pseudorandom value, here the output length is variable anddepends > > on the application. > > Some plumbing-level questions: > > you suggested that random nonces should go into the first stage. would > non-random context/identity inputs go there, too? Yes. But indeed not for the purpose of randomness extraction. eg, the identities are useful for binding the generated key to the identitied of the peers. In general, the first stage should do whatever is necessary to get an initial seed of fixed length (say, 128 or 160 bits) that is pseudorandom for anyone except the two peers, and is bound to the correct peer identity within each one of the peers. > > and: would it ever be appropriate to use multiple stages of key > expansion? Yes, that could ofcourse happen. But the requirements from all levels of key expansion are the same: take a fixed-length pseudorandom key and expand it to a long-enough pseudorandom value. This is in fact another motivation for separating randomness extraction from key expansion. All these levels of key expansion already get a pseudorandom key, so they dont need the full power of the KDF proposed in the I-D. Ran > > for instance: > > [diffie-hellman] -> [randomness extraction] -> [key expansion] -> (A, B, > C) > > A -> [key expansion] -> (A1, A2, A3) > B -> [key expansion] -> (B1, B2, B3) > C -> [key expansion] -> (C1, C2, C3) > > - Bill > > > > > > > From nw141292@binky.Central.Sun.COM Sat Oct 29 04:08:41 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9T88e5j018368 for ; Sat, 29 Oct 2005 04:08:40 -0400 (EDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) j9T88bjm003206 for ; Sat, 29 Oct 2005 04:08:38 -0400 (EDT) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j9T88b4u008806 for ; Sat, 29 Oct 2005 01:08:37 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) with ESMTP id j9T88ZFA019280 for ; Sat, 29 Oct 2005 02:08:36 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) j9T88X8r021662; Sat, 29 Oct 2005 03:08:33 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j9T88VjK021661; Sat, 29 Oct 2005 03:08:31 -0500 (CDT) Date: Sat, 29 Oct 2005 03:08:31 -0500 From: Nicolas Williams To: canetti Subject: Re: [saag] KDF: Randomness extraction vs. key expansion Message-ID: <20051029080831.GH20236@binky.Central.Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.590984 cc: cfrg@ietf.org cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 29 Oct 2005 08:08:42 -0000 On Fri, Oct 28, 2005 at 03:48:59PM -0400, canetti wrote: > Finally, a general remark on modeling and abstractions: I can imagine people > read this note and think to themselves: "why is he bothing us with these > abstract notions. In the end of the day all that is going to be done is a > bunch of hashes and/or block cipher operations, so why not do it explicitly > and be done with it." My answer is that these abstractions are our > only hope to make sense of this spaghetti of hashes, shifts, > concatenations, exponentiations etc. If we want to build systems that will > have some pretence of security we have no choice but use the abstractions > and abide by them, even is there is some price in complexity. I'm with you on the same layering abstraction matter; even we agreed on the identity function for randomness extraction there would still be a layering abstraction. This KDF has a lot of inputs, and in some ways arguably not enough (e.g., IDs but, surprisingly, no ID types), but a PRF has a much simpler function signature. So it seems simpler to define a PRF and then a KDF in terms of said PRF than to inextricably mix the two. And why shouldn't there be a standard PRF if there is to be a standard KDF? And if there's to be a standard PRF then that'd be all the more reason to base a standard KDF on a standard PRF. Nico -- From djb-dsn-1130580912.16308@cr.yp.to Sat Oct 29 06:14:57 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9TAEv5j019172 for ; Sat, 29 Oct 2005 06:14:57 -0400 (EDT) Received: from stoneport.math.uic.edu (stoneport.math.uic.edu [131.193.178.160])j9TAEox7011930 for ; Sat, 29 Oct 2005 06:14:50 -0400 (EDT) Received: (qmail 16309 invoked by uid 1016); 29 Oct 2005 10:15:12 -0000 Date: 29 Oct 2005 10:15:12 -0000 Message-ID: <20051029101512.16308.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: cfrg@ietf.org, saag@mit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.700139 Subject: [saag] Re: [Cfrg] KDF: Randomness extraction vs. key expansion X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 29 Oct 2005 10:14:58 -0000 How do we encrypt a series of messages using a Diffie-Hellman shared secret g^xy? There are many solutions that are conjectured to be secure. The most efficient solutions all have two common levels of structure: * They convert g^xy into a long string and then xor pieces of the string with the messages. * They compute the long string as a series of short blocks, where the nth block is obtained by feeding (g^xy,n) to a primitive circuit. One conjectures that the attacker, given g^x and g^y, can't distinguish the circuit outputs from independent uniform random strings. This implies that a passive attacker can't break the encryption. (A more complicated conjecture handles active attackers.) Essentially identical comments apply to authentication, thanks to Wegman-Carter. It also turns out that the most efficient solutions use elliptic-curve groups. This may change---perhaps someone will find a better attack; even if not, genus 2 has evolved into a serious competitor---but it's shared structure for the moment. Are there other common structures? In particular, is there a common structure to the fastest primitive circuits used to mangle (g^xy,n)? The answer is no. There are many competing structures for the primitive circuit. One can easily take any of these structures and use it to build an apparently unbreakable circuit that, on today's CPUs, uses fewer than 20 cycles per output byte. No single structure is a clear speed leader. There are, however, some structures that clearly are _not_ speed leaders for their conjectured security level. In particular, a structure that combines SHA-256 with AES ends up consuming considerably more hardware resources, L1 I-cache, etc. than a structure that iterates a unified round function for a similar number of rounds. I've noticed some people becoming overly excited about particular structures. Often these people get so caught up in the buzzwords used to describe their structures, such as ``randomness extraction,'' that they lose sight of what users actually want, namely security and speed of the encryption (and authentication) system as a whole. These people start demanding that other people follow the same structures---even when the structures are neither necessary nor sufficient for security! Ran Canetti says, for example, that one is obliged to use the following structure, because anything else is a ``cryptographic layer violation'': * apply a ``randomness extractor'' R to g^xy; * use R(g^xy) as a key for a ``conjectured PRG'' G; and * use G(R(g^xy)) as a key for a ``conjectured PRF'' F producing the desired output blocks. If R and G are both serious cryptographic functions then this structure is overkill. The generator G is pointless complication, making the cryptosystem unnecessarily difficult to implement, especially in FPGAs. If, on the other hand, R and G are not serious cryptographic functions, then this structure can easily lose all security. An active attacker can feed related inputs to R (such as g^(xy+x), g^(xy+2x), g^(xy+3x), etc.), unless higher-level protocol layers take tons of time to check proof of secret-key possession. Typical randomness extractors R, even perfectly secure ones, will turn those related inputs into related outputs. If the key for F isn't longer than the output of R then G can be the identity function, a provable PRG. The keys for F are then related---exposing F to a related-key attack, which PRFs are not required to resist. The whole point of key derivation is to eliminate related-key attacks, known-DH-bit attacks, etc. We all know how to do this properly: feed the shared secret through a cryptographic hash function---even a fairly wimpy one, such as g^xy |-> MD5(g^xy,0),MD5(g^xy,1). I don't object to using larger hash functions, preferably sharing code with functions that need to be implemented anyway; this computation is amortized over many blocks. I do, however, object to having the hash function constrained to follow someone's naive notion of proper ``cryptographic layers.'' ---D. J. Bernstein, Professor, Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From paul.hoffman@vpnc.org Sat Oct 29 17:28:16 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9TLSF5j023305 for ; Sat, 29 Oct 2005 17:28:15 -0400 (EDT) Received: from above.proper.com (above.proper.com [208.184.76.39]) j9TLS7Vb024882 for ; Sat, 29 Oct 2005 17:28:08 -0400 (EDT) Received: from [165.227.249.220] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9TLS64Z067558 for ; Sat, 29 Oct 2005 14:28:07 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Sat, 29 Oct 2005 14:28:08 -0700 To: saag@mit.edu From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.570587 Subject: [saag] Fwd: Impending publication: draft-iab-dos-03.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 29 Oct 2005 21:28:16 -0000 Of interest to many on this mailing list... >To: IETF Announcement list >From: Leslie Daigle >Date: Sat, 29 Oct 2005 15:54:11 -0400 >X-Spam-Score: 0.0 (/) >X-Scan-Signature: 97adf591118a232206bdb5a27b217034 >Cc: iab@ietf.org >Subject: Impending publication: draft-iab-dos-03.txt >X-BeenThere: ietf-announce@ietf.org >X-Mailman-Version: 2.1.5 >List-Id: ietf-announce.ietf.org >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > >Sender: ietf-announce-bounces@ietf.org > >The IAB is ready to ask the RFC-Editor to publish > > Internet Denial of Service Considerations > draft-iab-dos-03.txt > > >as an Informational RFC. This document provides a survey >of known denial of service (DoS) attack types on various >parts of Internet infrastructure (hosts, routers, links, >etc), as well as reviewing attack amplifiers. Mitigation >strategies -- from protocol design through deployment >choices -- are explored. > >The IAB solicits comments by November 26, 2005. Please send >comments to the IAB (iab@iab.org), or to ietf@ietf.org. > >The document can be found at > > >http://www.ietf.org/internet-drafts/draft-iab-dos-03.txt > > >>From the Abstract: > > This document provides an overview of possible avenues for denial-of- > service attack on Internet systems. The aim is to encourage protocol > designers and network engineers towards designs that are more robust. > We discuss partial solutions that reduce the effectiveness of > attacks, and how some solutions might inadvertently open up > alternative vulnerabilities. > > >Leslie Daigle, > For the IAB. > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce From canetti@watson.ibm.com Sun Oct 30 10:34:55 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9UFYs5j028823 for ; Sun, 30 Oct 2005 10:34:54 -0500 (EST) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) j9UFYqli002995 for ; Sun, 30 Oct 2005 10:34:52 -0500 (EST) Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41])ESMTP id j9UFZfUL019648; Sun, 30 Oct 2005 10:35:51 -0500 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) with ESMTP id j9UFXlF209580; Sun, 30 Oct 2005 10:33:47 -0500 Received: from mgsmtp00.watson.ibm.com (mgsmtp00.watson.ibm.com [9.2.40.58]) with ESMTP id j9UFXk4209578; Sun, 30 Oct 2005 10:33:46 -0500 Received: from prf.watson.ibm.com (prf.watson.ibm.com [9.2.16.112]) j9UFXjH5006578; Sun, 30 Oct 2005 10:33:45 -0500 Received: from localhost (canetti@localhost)id j9UFXih65542; Sun, 30 Oct 2005 10:33:44 -0500 Date: Sun, 30 Oct 2005 10:33:43 -0500 (EST) From: canetti To: "D. J. Bernstein" Subject: Re: [saag] Re: [Cfrg] KDF: Randomness extraction vs. key expansion In-Reply-To: <20051029101512.16308.qmail@cr.yp.to> Message-ID: References: <20051029101512.16308.qmail@cr.yp.to> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.4 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.739209 cc: cfrg@ietf.org cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 30 Oct 2005 15:34:55 -0000 Dan, If one prefers to treat the entire cryptographic processing in, say, a VPN application as a single unit with no punctuations then indeed my proposal is of no value. But then, as you point out, we're left with one main analytical tool: the vague notion of a "serious cryptographic function". Note: No specific abstraction (or, layering) is ever mandatory, and they are all naive to some extent, by the essence of being abstractions. But we can't do without abstractions, and the one I'm advocating is standard (and quite effective as well). Ran On Sat, 29 Oct 2005, D. J. Bernstein wrote: > How do we encrypt a series of messages using a Diffie-Hellman shared > secret g^xy? There are many solutions that are conjectured to be secure. > The most efficient solutions all have two common levels of structure: > > * They convert g^xy into a long string and then xor pieces of the > string with the messages. > > * They compute the long string as a series of short blocks, where the > nth block is obtained by feeding (g^xy,n) to a primitive circuit. > > One conjectures that the attacker, given g^x and g^y, can't distinguish > the circuit outputs from independent uniform random strings. This > implies that a passive attacker can't break the encryption. (A more > complicated conjecture handles active attackers.) Essentially identical > comments apply to authentication, thanks to Wegman-Carter. > > It also turns out that the most efficient solutions use elliptic-curve > groups. This may change---perhaps someone will find a better attack; > even if not, genus 2 has evolved into a serious competitor---but it's > shared structure for the moment. > > Are there other common structures? In particular, is there a common > structure to the fastest primitive circuits used to mangle (g^xy,n)? > > The answer is no. There are many competing structures for the primitive > circuit. One can easily take any of these structures and use it to build > an apparently unbreakable circuit that, on today's CPUs, uses fewer than > 20 cycles per output byte. No single structure is a clear speed leader. > > There are, however, some structures that clearly are _not_ speed leaders > for their conjectured security level. In particular, a structure that > combines SHA-256 with AES ends up consuming considerably more hardware > resources, L1 I-cache, etc. than a structure that iterates a unified > round function for a similar number of rounds. > > I've noticed some people becoming overly excited about particular > structures. Often these people get so caught up in the buzzwords used to > describe their structures, such as ``randomness extraction,'' that they > lose sight of what users actually want, namely security and speed of the > encryption (and authentication) system as a whole. These people start > demanding that other people follow the same structures---even when the > structures are neither necessary nor sufficient for security! > > Ran Canetti says, for example, that one is obliged to use the following > structure, because anything else is a ``cryptographic layer violation'': > > * apply a ``randomness extractor'' R to g^xy; > * use R(g^xy) as a key for a ``conjectured PRG'' G; and > * use G(R(g^xy)) as a key for a ``conjectured PRF'' F producing the > desired output blocks. > > If R and G are both serious cryptographic functions then this structure > is overkill. The generator G is pointless complication, making the > cryptosystem unnecessarily difficult to implement, especially in FPGAs. > > If, on the other hand, R and G are not serious cryptographic functions, > then this structure can easily lose all security. An active attacker can > feed related inputs to R (such as g^(xy+x), g^(xy+2x), g^(xy+3x), etc.), > unless higher-level protocol layers take tons of time to check proof of > secret-key possession. Typical randomness extractors R, even perfectly > secure ones, will turn those related inputs into related outputs. If the > key for F isn't longer than the output of R then G can be the identity > function, a provable PRG. The keys for F are then related---exposing F > to a related-key attack, which PRFs are not required to resist. > > The whole point of key derivation is to eliminate related-key attacks, > known-DH-bit attacks, etc. We all know how to do this properly: feed the > shared secret through a cryptographic hash function---even a fairly > wimpy one, such as g^xy |-> MD5(g^xy,0),MD5(g^xy,1). I don't object to > using larger hash functions, preferably sharing code with functions that > need to be implemented anyway; this computation is amortized over many > blocks. I do, however, object to having the hash function constrained to > follow someone's naive notion of proper ``cryptographic layers.'' > > ---D. J. Bernstein, Professor, Mathematics, Statistics, > and Computer Science, University of Illinois at Chicago > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag > From djb-dsn-1130736370.4157@cr.yp.to Mon Oct 31 00:26:13 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9V5QC5j004752 for ; Mon, 31 Oct 2005 00:26:12 -0500 (EST) Received: from stoneport.math.uic.edu (stoneport.math.uic.edu [131.193.178.160])j9V5Q5Ua025914 for ; Mon, 31 Oct 2005 00:26:10 -0500 (EST) Received: (qmail 4158 invoked by uid 1016); 31 Oct 2005 05:26:10 -0000 Date: 31 Oct 2005 05:26:10 -0000 Message-ID: <20051031052610.4157.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: saag@mit.edu, cfrg@ietf.org Subject: Re: [saag] Re: [Cfrg] KDF: Randomness extraction vs. key expansion References: <20051029101512.16308.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: -1.11 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.596355 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 31 Oct 2005 05:26:14 -0000 canetti writes: > But then, as you point out, we're left with one main analytical tool: > the vague notion of a "serious cryptographic function". The security of a key-derivation function is _always_ a vague notion. You _must_ combine key derivation with a Diffie-Hellman group to produce a clear security notion, namely HDH. _Every_ key-derivation function can have its security destroyed by a poor choice of Diffie-Hellman function. In fact, _every_ key-derivation function, no matter how many buzzwords were used in its construction, can potentially have security destroyed by a choice of Diffie-Hellman function that would have been secure with most key-derivation functions. Even worse, if you make a sufficiently poor choice of key-derivation function, then your security _will_ be destroyed by _standard_ choices of Diffie-Hellman functions. You've made a contrary claim, namely that you can build a conjecturally secure key-derivation function by combining any randomness extractor and any conjectured PRG. That claim is _false_. Your construction can lose all the security that would have been produced by the NIST KDF. Your construction fails to prevent related-key attacks. The last two paragraphs of my previous message explain this in detail. You could try to fix your security mistake by replacing ``randomness extractor'' with a stronger notion---but if you continue trying to avoid vague notions then you'll inevitably end up with something that's either too weak or too strong. You do _not_ have, and you will never have, a key-derivation function that's provably secure assuming AES security. ---D. J. Bernstein, Professor, Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From canetti@watson.ibm.com Mon Oct 31 10:05:34 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9VF5X5j008448 for ; Mon, 31 Oct 2005 10:05:33 -0500 (EST) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) j9VF5TAo014496 for ; Mon, 31 Oct 2005 10:05:29 -0500 (EST) Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41])ESMTP id j9VF6jBN007084; Mon, 31 Oct 2005 10:06:45 -0500 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) with ESMTP id j9VF4oF314370; Mon, 31 Oct 2005 10:04:50 -0500 Received: from mgsmtp00.watson.ibm.com (mgsmtp00.watson.ibm.com [9.2.40.58]) with ESMTP id j9VF4n4314176; Mon, 31 Oct 2005 10:04:49 -0500 Received: from prf.watson.ibm.com (prf.watson.ibm.com [9.2.16.112]) j9VF4m5G015948; Mon, 31 Oct 2005 10:04:48 -0500 Received: from localhost (canetti@localhost)id j9VF4m930390; Mon, 31 Oct 2005 10:04:48 -0500 Date: Mon, 31 Oct 2005 10:04:47 -0500 (EST) From: canetti To: "D. J. Bernstein" Subject: Re: [saag] Re: [Cfrg] KDF: Randomness extraction vs. key expansion In-Reply-To: <20051031052610.4157.qmail@cr.yp.to> Message-ID: References: <20051031052610.4157.qmail@cr.yp.to> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.4 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.633620 cc: cfrg@ietf.org cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 31 Oct 2005 15:05:34 -0000 Dan, we seem to be in violent agreement, at least on the main point of this thread. You say: > too weak or too strong. You do _not_ have, and you will never have, a > key-derivation function that's provably secure assuming AES security. Exactly. Being a block cipher is not a strong enough property for randomness extraction (or, key derivation if you prefer this name). In contrast, being a block cipher is a perfect fit for key expansion. So let's separate the two tasks! BTW. In spite of the date, I dont share your pessimistic view that key derivation/randomness extraction is doomed to be a vague notion where sorcery rules forever. I think we do have tools to make mathematical sense of it and to make concrete security claims. But I certainly agree that it's a very different (and harder) task than key expansion. Ran On Mon, 31 Oct 2005, D. J. Bernstein wrote: > canetti writes: > > But then, as you point out, we're left with one main analytical tool: > > the vague notion of a "serious cryptographic function". > > The security of a key-derivation function is _always_ a vague notion. > You _must_ combine key derivation with a Diffie-Hellman group to produce > a clear security notion, namely HDH. _Every_ key-derivation function can > have its security destroyed by a poor choice of Diffie-Hellman function. > In fact, _every_ key-derivation function, no matter how many buzzwords > were used in its construction, can potentially have security destroyed > by a choice of Diffie-Hellman function that would have been secure with > most key-derivation functions. Even worse, if you make a sufficiently > poor choice of key-derivation function, then your security _will_ be > destroyed by _standard_ choices of Diffie-Hellman functions. > > You've made a contrary claim, namely that you can build a conjecturally > secure key-derivation function by combining any randomness extractor and > any conjectured PRG. That claim is _false_. Your construction can lose > all the security that would have been produced by the NIST KDF. Your > construction fails to prevent related-key attacks. The last two > paragraphs of my previous message explain this in detail. > > You could try to fix your security mistake by replacing ``randomness > extractor'' with a stronger notion---but if you continue trying to avoid > vague notions then you'll inevitably end up with something that's either > too weak or too strong. You do _not_ have, and you will never have, a > key-derivation function that's provably secure assuming AES security. > > ---D. J. Bernstein, Professor, Mathematics, Statistics, > and Computer Science, University of Illinois at Chicago > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag > From knoppix@MIT.EDU Sun Nov 6 12:59:28 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jA6HxR1r018425 for ; Sun, 6 Nov 2005 12:59:27 -0500 (EST) Received: from Knoppix (JISVPN.MIT.EDU [18.100.101.102]) jA6HxPqW027344 for ; Sun, 6 Nov 2005 12:59:25 -0500 (EST) Received: by Knoppix via sendmail from stdin id (Debian Smail3.2.0.115) Sun, 6 Nov 2005 12:59:18 -0500 (EST) Resent-From: knoppix@MIT.EDU Resent-Date: Sun, 6 Nov 2005 12:59:18 -0500 Resent-Message-ID: <20051106175918.GC6954@mit.edu> Resent-To: saag@mit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9RLdW5j003538 for ; Thu, 27 Oct 2005 17:39:32 -0400 (EDT) Received: from psg.com (psg.com [147.28.0.62])j9RLdQ57020173 for ; Thu, 27 Oct 2005 17:39:27 -0400 (EDT) Received: from [147.28.0.62] (helo=usmovnazinin.alcatel.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVFT4-000LBP-Jz; Thu, 27 Oct 2005 21:39:26 +0000 Date: Thu, 27 Oct 2005 14:39:12 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <393302246.20051027143912@psg.com> To: routing-discussion@ietf.org, saag@mit.edu, idr@ietf.org, rtg-dir@ietf.org, rtg-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -1.214 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.590617 Spam-Alum-Time: 0.580425 X-Mailman-Approved-At: Sun, 06 Nov 2005 13:16:54 -0500 Subject: [saag] Secure Interdomain Routing BOF X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: Alex Zinin List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 06 Nov 2005 17:59:29 -0000 Folks- We're going to have a BOF in Vancouver to discuss mechanisms for securing Internet inter-domain routing. Please subscribe to the list, and mark you calendars. Information below. It is currently scheduled on Thur, 9:00-11:30am. -- Alex http://www.psg.com/~zinin Name of the BOF: Secure Interdomain Routing (SIDR) Area: Routing Chairs: Geoff Huston Sponsoring ADs: Alex Zinin, Bill Fenner The RPSEC WG has been working on security requirements for the Internet routing system in general and the BGP routing protocol in particular. While considerable progress has been made so far, formulation of the complete set of requirements can take some time. At the same time, there's a shared understanding in the IETF community that architectural and protocol work on securing interdomain routing needs to start, as it will take time to formulate an architectural approach and associated protocol interactions, develop implementations and see first deployments. The goal of this BOF is to discuss creation of an extensible interdomain routing security architecture that would form the foundation of an approach that incrementally defines security features for BGP, while the discussion on requirements progresses. The expected outcome is an agreement on the initial set of security features that such an architecture would provide. It is not a goal of this BOF to choose between SBGP and SoBGP. Agenda: 1. Introduction and current status [15m] 2. Brief overview of currently proposed solutions [30m] 3. Description of proposed work [15m] 4. Discussion [60m] Mailing list: sidr@ietf.org To subscribe: sidr-request@ietf.org Reading material: Requirements: http://www.ietf.org/internet-drafts/draft-ietf-rpsec-routing-threats-07.txt http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-02.txt SoBGP: http://www.ietf.org/internet-drafts/draft-white-sobgp-architecture-01.txt http://www.ietf.org/internet-drafts/draft-ng-sobgp-bgp-extensions-01.txt http://www.ietf.org/internet-drafts/draft-weis-sobgp-certificates-01.txt SBGP: SBGP web page: http://www.net-tech.bbn.com/sbgp/sbgp-index.html From knoppix@MIT.EDU Sun Nov 6 12:59:29 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jA6HxS1r018426 for ; Sun, 6 Nov 2005 12:59:28 -0500 (EST) Received: from Knoppix (JISVPN.MIT.EDU [18.100.101.102]) jA6HxPPa002380 for ; Sun, 6 Nov 2005 12:59:25 -0500 (EST) Received: by Knoppix via sendmail from stdin id (Debian Smail3.2.0.115) Sun, 6 Nov 2005 12:59:18 -0500 (EST) Resent-From: knoppix@MIT.EDU Resent-Date: Sun, 6 Nov 2005 12:59:18 -0500 Resent-Message-ID: <20051106175918.GA6954@mit.edu> Resent-To: saag@mit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9GG565j012311 for ; Sun, 16 Oct 2005 12:05:07 -0400 (EDT) Received: from postix.sonance.net (mx2.sonance.net [62.116.45.130]) j9GG536x017838 for ; Sun, 16 Oct 2005 12:05:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by postix.sonance.net (Postfix) with ESMTP id AF85517B46D; Sun, 16 Oct 2005 18:04:52 +0200 (CEST) Received: from postix.sonance.net ([127.0.0.1]) by localhost (zentrix [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15593-06; Sun, 16 Oct 2005 18:04:52 +0200 (CEST) Received: from [IPv6???1] (localhost [127.0.0.1]) by postix.sonance.net (Postfix) with ESMTP id CE95C17B46C; Sun, 16 Oct 2005 18:04:51 +0200 (CEST) Message-ID: <43527A54.3020904@systemics.com> From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Alten References: <4.3.2.7.1.20051015234218.0525d718@mail.alten.org> In-Reply-To: <4.3.2.7.1.20051015234218.0525d718@mail.alten.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at sonance.net X-Spam-Score: -1.214 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.679165 Spam-Alum-Time: 0.606774 X-Mailman-Approved-At: Sun, 06 Nov 2005 13:16:55 -0500 cc: cryptography@metzdowd.com cc: cfrg@ietf.org cc: saag@mit.edu Subject: [saag] Re: status of SSL vs SHA-1/MD-5, etc.? X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Date: Sun, 06 Nov 2005 17:59:29 -0000 X-Original-Date: Sun, 16 Oct 2005 17:05:40 +0100 X-List-Received-Date: Sun, 06 Nov 2005 17:59:29 -0000 Alex Alten wrote: > Everyone, > > So where do we stand with secure networking protocols vs SHA-1/MD-5? Wait until the Halloween Bash, and then another year or two before it all settles out. In the meantime the work that has to be done is to prepare all the protocols to be able to handle multiple hashes (something I posted on a while ago here, and I gather that Eric and Steven have written up in more detail in a paper). Even if you decide to replace the hashes now, you still have to do all the above work anyway, so it makes sense to do the work, then select the hash as late as possible. > Is SSL at risk? No, not from that. To quote from Adi's laws, Cryptography is typically bypassed, not penetrated. (I would say he was being conservative, to any measurable degree it is always bypassed, never penetrated.) > Is TLS OK (because of HMAC)? There is a rollback attack in SSL which needs to be fixed, but the real fix - turn off SSL v2 - is hard because it can only be done at the app level at the moment. (It's a big flaw in "secure" browsing. Mozilla has been testing and moving towards turning off v2 in its browser for 6 months now so as to help phishing.) So, yes, turn off SSL v2 wherever and whenever you can and move to TLS. Do it in your servers and browsers. > SSH, IPSec, etc? By far the biggest risk is that crypto protocols aren't deployed because of complexity. A change to hashes increases complexity, so a priori it will probably reduce security more than it improves it. Hence the strategy above, to move hashes in so that they can migrate without effecting the rest of the protocol. Just some comments! iang From knoppix@MIT.EDU Sun Nov 6 12:59:31 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jA6HxU1r018433 for ; Sun, 6 Nov 2005 12:59:30 -0500 (EST) Received: from Knoppix (JISVPN.MIT.EDU [18.100.101.102]) jA6HxSPa002455 for ; Sun, 6 Nov 2005 12:59:28 -0500 (EST) Received: by Knoppix via sendmail from stdin id (Debian Smail3.2.0.115) Sun, 6 Nov 2005 12:59:18 -0500 (EST) Resent-From: knoppix@MIT.EDU Resent-Date: Sun, 6 Nov 2005 12:59:18 -0500 Resent-Message-ID: <20051106175918.GB6954@mit.edu> Resent-To: saag@mit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id j9PLKJ5j011528 for ; Tue, 25 Oct 2005 17:20:19 -0400 (EDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) j9PLKFDe025387 for ; Tue, 25 Oct 2005 17:20:15 -0400 (EDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) j9PLKC9g000477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Oct 2005 14:20:13 -0700 Received: from AGANTMAN2.qualcomm.com (qconnect-10-50-68-86.qualcomm.com [10.50.68.86])j9PLK9le000551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Oct 2005 14:20:10 -0700 (PDT) Message-Id: <6.2.2.1.2.20051025141346.033dc720@qcmail1.qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1 Date: Tue, 25 Oct 2005 14:20:09 -0700 To: Russ Housley , saag@mit.edu From: Alexander Gantman Subject: Re: [saag] Hash-Based Key Derivation In-Reply-To: <7.0.0.10.2.20051025124107.02d130d8@vigilsec.com> References: <7.0.0.10.2.20051025124107.02d130d8@vigilsec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.214 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.554478 Spam-Alum-Time: 0.569347 X-Mailman-Approved-At: Sun, 06 Nov 2005 13:16:55 -0500 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 06 Nov 2005 17:59:32 -0000 I noticed words like "strong" and "secure" used throughout the document without any real definition. What does it mean for a KDF to be strong? What are the actual security properties being claimed? Same goes for the hash function. What does it mean for the hash function to be secure? Does it have to collision resistant? pre-image resistant, second pre-image resistant? -Alex At 09:44 AM 10/25/2005, Russ Housley wrote: >I wanted call your attention to an individual draft on "Hash-Based Key >Derivation." > > http://www.ietf.org/internet-drafts/draft-dang-nistkdf-00.txt > >This draft specifies a soon to be NIST-approved algorithm for deriving >secret key material from a shared secret using a hash algorithm. This >algorithm is in the NIST draft SP 800-56. > >I encourage review and comment. If you have concerns with this document, >then the concerns probably apply to he NIST draft SP 800-56 document too. > >I am considering sponsoring this document as an Informational RFC. Please >let me know if you have any concerns with this proposed action. > >Thanks, > Russ > >_______________________________________________ >saag mailing list >saag@mit.edu >https://jis.mit.edu/mailman/listinfo/saag From housley@vigilsec.com Tue Nov 8 17:34:13 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jA8MYC1r012306 for ; Tue, 8 Nov 2005 17:34:12 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) jA8MY5gm023943 for ; Tue, 8 Nov 2005 17:34:05 -0500 (EST) Received: (qmail 28897 invoked by uid 0); 8 Nov 2005 22:33:57 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (209.52.108.226) by woodstock.binhost.com with SMTP; 8 Nov 2005 22:33:57 -0000 Message-Id: <7.0.0.10.2.20051108173208.05c3c548@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Tue, 08 Nov 2005 17:33:54 -0500 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.019278 Spam-Alum-Time: 0.507282 Subject: [saag] draft-housley-aaa-key-mgmt-01.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 08 Nov 2005 22:34:13 -0000 This document will appear later toady. Please take a look. The plan is for it to become a BCP. http://www.ietf.org/internet-drafts/draft-housley-aaa-key-mgmt-01.txt Thanks, Russ From jaltman@columbia.edu Thu Nov 10 14:37:23 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jAAJbM1r003578 for ; Thu, 10 Nov 2005 14:37:22 -0500 (EST) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) jAAJbBCh025977; Thu, 10 Nov 2005 14:37:11 -0500 (EST) Received: from [10.100.12.163] ([207.34.158.130]) (user=jaltman mech=PLAIN bits=0)jAAJb7TQ027118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Nov 2005 14:37:08 -0500 (EST) Message-ID: <4373A1EC.4010703@columbia.edu> Date: Thu, 10 Nov 2005 11:39:24 -0800 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: saag@mit.edu, kitten@lists.ietf.org, Russ Housley , Sam Hartman X-Enigmail-Version: 0.93.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030307080206030100070407" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: -2.6 X-Spam-Flag: NO Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.703355 Subject: [saag] IETF64 Kitten WG Summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 10 Nov 2005 19:37:24 -0000 This is a cryptographically signed message in MIME format. --------------ms030307080206030100070407 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The Kitten working group met at IETF64 on Wednesday morning. The presentation materials are available at: https://onsite.ietf.org/public/meeting_materials.cgi?meeting_num=64 The Audio Stream is available at http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf64/ietf64-ch8-wed.mp3.1 The Jabber Logs are available at: http://www.xmpp.org/ietf-logs/kitten@ietf.xmpp.org/2005-11-09.html --------------------------------------------------------------------------------- The Kitten Working Group continued its efforts to use the IETF meeting time for providing high-bandwidth work time to make progress on active documents. Unlike the Paris meeting, this room suffered from a lack of microphones sufficient facilitate our purpose. I propose that rooms should provide five microphones. One for the chair, one wireless for the presenter, two microphones for front row participants who have read the documents, and one floor microphone for others. --------------------------------------------------------------------------------- Summary of document status: * PRF API extension for GSS draft -07 submitted to IESG * PRF API extension for GSS KRB5 mech draft -04 submitted to IESG * C# Bindings - New draft sent to Internet-Drafts for publication draft-ietf-kitten-gssapi-csharp-bindings-00.txt * Desired Enhancements to GSS Naming draft-03 WG last call in progress ending Nov 23rd * GSS-API Naming Extensions Draft -01 submitted. Topic of technical discussion at this meeting. * Clarifications to GSSAPI v2 Update 1 No draft yet published. Topic of technical discussion at this meeting. -------------------------------------------------------------------------------- Technical Discussions: GSS-API Naming Extensions draft-ietf-kitten-gssapi-naming-exts-01.txt The working group reviewed the open issues related to this work. Discussions were held on the merits of the gss_inquire_name_attribute() functionality. A preliminary decision was made to remove the functionality from the draft as it has the potential to significantly reduce the portability of applications. Lengthy discussions were held on the support of negative ACLs. The fundamental problem with supporting negative ACLs is that in order for them to be valid the evaluator must be able determine that the complete set of relevant membership information is available. This is possible to enforce when there is only a single source of ACEs. However, in the model being considered, ACEs can be provided from multiple sources and it is extremely difficult to ensure that conflicts or a failure to provide relevant ACEs do not occur. The WG believes there is a need to support negative ACLs for applications such as NFSv4. The WG proposes supporting negative ACLs and writing appropriate Security Considerations text describing the dangers of certain use cases. There was much discussion of how Microsoft solved the issues in Windows although it appears that most of the solutions are enforced by the user interface tools preventing the construction of dangerous combinations. It is clear that the use of "NAME" in GSS to refer to the "principal" (the entity being authenticated) is confusing for many people. The documents need to be extra careful to specify the terminology. The former CAT draft "Extended Generic Security Service APIs: XGSS-APIs Access control and delegation extensions" was discussed as it applied to the choice between supporting enumerated native types vs. OID tagged blobs. A preliminary decision was made to use OID tagged blobs. Technical Discussions: GSS API v2 upd 1 Clarifications The working group during the meeting wrote text for this document. Sections include: - Character-set issues - Thread safety issues - Channel Bindings + what to do about lack of a GSS_C_AF_INET6 symbol - C language utilization + type utilization + name spaces A first draft should be available real soon. Open issue. Are channel bindings defined on a per-mechanism basis or are they supposed to be defined in a general manner? --------------ms030307080206030100070407 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUxMTEwMTkzOTI0WjAjBgkqhkiG9w0BCQQxFgQUQNX6atUklJ0dKny4KauQDcrADY0w UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAQ/A+vye6QTNYXvx5f2oR8j+WklN5FU0YXmaKzLNK Qr/jow+DYflYZGlEyG8DwphRAkcNtYTfKSO8yExCEkcmFps5Egs23uGL9kjRpxo8aDEC32K4 kEtMoXF3kCVtoC22kaOw6ASMjKf4G4xy4XWl0YJiGFXn2b1zpns6xiF6PK636JL1LFKGanvE WeYN3eI0U8PJrL54ku93sfd1IX1+QZQPsQkoq73Nu6dlYxerRoVHmaMdUgCkzIfmtHiXrh+B 6Uul+jyy4xiFloCxEEXydoSFDCZAWB9I7mhUuFk6sS5ZAJXIR4yTEwnLq7BsiLzch3FWzv4g aLPRVwOXXTp6zgAAAAAAAA== --------------ms030307080206030100070407-- From tlyu@MIT.EDU Thu Nov 10 14:43:01 2005 Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jAAJh11r003683 for ; Thu, 10 Nov 2005 14:43:01 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) jAAJgmLZ000799; Thu, 10 Nov 2005 14:42:49 -0500 (EST) 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.1/8.12.4) with ESMTP id jAAJgkmS012207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Nov 2005 14:42:47 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9) id jAAJgkqm028348; Thu, 10 Nov 2005 14:42:46 -0500 (EST) To: ietf-sasl@imc.org From: Tom Yu Date: Thu, 10 Nov 2005 14:42:46 -0500 Message-ID: Lines: 49 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.574305 cc: hartmans-ietf@mit.edu cc: housley@vigilsec.com cc: kurt@openldap.org cc: saag@mit.edu Subject: [saag] IETF64 SASL WG summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 10 Nov 2005 19:43:02 -0000 SASL WG Tuesday, November 8, 2005 09:00-11:30 SUMMARY ======= Thanks to Bob Morgan for scribing. SASL base spec is late; Kurt to revise and post new version this week. No objections to WGLC for the GSSAPI mech, but require positive support to progress. Plain mech will hold for base. Previous consensus during IETF63 for taking CRAM-MD5 off standards track, but objections in mailing list. Some people prefer standards track for CRAM-MD5, but do not object to making it Informational. DIGEST-MD5: Added channel bindings text. Dropped AES CBC mode with separate IV. Update ABNF to reference RFC. Some discussion about how to get AES counter mode text written. Some remaining issues about ISO 8859-1 compat with HTTP DIGEST. Check with apps area. SASL base: Minor changes re error handling, empty initial server challenge, etc. Some proposed cleanup of security considerations section. Discussion re IANA considerations re family of mechs. Consensus for delegation to registrant upon assignment. GSSAPI family of mechs: Simon will write some text; note base-32 encoding needs checking vs DNSEXT. ACTION ITEMS ============ Kurt will talk with apps area people about HTTP DIGEST 8859-1 issue GSS (krb5 & SPNEGO) WGLC nowish SASL base to IESG Dec 2005 DIGEST-MD5 next rev before Dec 2006 GSS mech family initial draft Feb 2006 CRAM-MD5 WGLC around Mar 2006 DIGEST-MD5 WGLC around Mar 2006 implementation plan Summer 2006 GSS mech family to IESG Sep 2006 From rdd@cert.org Thu Nov 10 14:45:48 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jAAJjm1r003749 for ; Thu, 10 Nov 2005 14:45:48 -0500 (EST) Received: from franclinus.red.cert.org (franclinus.red.cert.org [192.88.209.16])jAAJjiCh016441 for ; Thu, 10 Nov 2005 14:45:44 -0500 (EST) Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5])jAAJjhi3019875 for ; Thu, 10 Nov 2005 14:45:43 -0500 Received: from localhost (magnum.yellow.cert.org [10.20.10.203]) jAAJjgMD030594 for ; Thu, 10 Nov 2005 14:45:43 -0500 Date: Thu, 10 Nov 2005 14:45:41 -0500 From: Roman Danyliw To: saag@mit.edu Message-ID: X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.52 on 192.88.209.16 X-Spam-Score: -2.599 X-Spam-Flag: NO Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.603930 Subject: [saag] INCH WG report from IETF 64 (fwd) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 10 Nov 2005 19:45:49 -0000 ------------ Forwarded Message ------------ Date: Thursday, November 10, 2005 2:40 PM -0500 From: Roman Danyliw To: hartmans-ietf@mit.edu, housley@vigilsec.com Cc: INCH Mailing List Subject: INCH WG report from IETF 64 Extended Incident Handling (INCH) WG report Wednesday, November 9, 2005, 13.00-15.00 IETF 64: Vancouver, USA Chair: Roman Danyliw AD Adviser: Sam Hartman The Vancouver INCH meeting was short overview of the progress and remaining issues in the working group. - An -05 version of the requirements draft [1] was produced shortly after IETF63. Minor changes are still required in the security requirements to ensure that the messaging format and transport binding are considered. A new draft should be available in a week, at which point the document can enter WG last call. - A substantial update was made to the data model [2] in the new -05 draft. A major effort was made to uncover inconsistencies between the Schema and the associated text. In this new revision, issues related to internationalization and those brought up by implementers were addressed. Only two technical issues remain and the plan is to address them aggressively. - The updated -05 draft of RID [3] reflects changes made to the data model. Other than tracking changes in [2], the draft is complete. - The individual draft [6] that provides a SOAP transport binding is ready for review by the AD as the basis for re-chartering the WG to include transport. Draft language for the updated charter will be available shortly. - Minor technical and editorial changes were made to the IODEF Phishing extension [5]. - No changes have been made to the implementation draft [4] pending resolution on transport and data model issues. - Milestone updates were made to reflect a slight slippage in the delivery dates (WG last-call) of the WG drafts. o 11-2005: Requirements - These milestones remain aggressive, but firm. o 12-2005: Data Model o 12-2005: Phishing extention data model (contingent on [2] o 12-2005: RID o 02-2006: Implementation Guide (contingent on [2]) Relevant Documents [1] draft-ietf-inch-requirements-05 [2] draft-ietf-inch-iodef-05 [3] draft-ietf-inch-rid-05 [4] draft-ietf-inch-implement-01 [5] draft-ietf-inch-phishingextns-02 [6] draft-moriarty-soap-01 ---------- End Forwarded Message ---------- From jsalowey@cisco.com Fri Nov 11 14:21:30 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jABJLU1r014939 for ; Fri, 11 Nov 2005 14:21:30 -0500 (EST) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) jABJLQvr024425 for ; Fri, 11 Nov 2005 14:21:26 -0500 (EST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 11 Nov 2005 11:21:26 -0800 X-IronPort-AV: i="3.99,119,1131350400"; d="scan'208"; a="674076440:sNHT28404424" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jABJLNZC020518; Fri, 11 Nov 2005 11:21:24 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 11 Nov 2005 11:27:04 -0800 Message-ID: <7210B31550AC934A8637D6619739CE690638754B@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EMU BOF Summary Thread-Index: AcXm9RrDz7/qizTQRQmdw+HVwWP30g== From: "Salowey, Joe" To: , , X-Spam-Score: -2.4 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.557938 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id jABJLU1r014939 Subject: [saag] EMU BOF Summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 11 Nov 2005 19:21:31 -0000 EAP Method Update (EMU) BOF Thursday, November 10, 2005 9:00 - 11:00 AM This was a continuation of the SECMECH BOF from last IETF, but it focused on the EAP method standardization work item. The goal of the BOF was to determine if there was interest to work on the standardization of a small number of EAP methods. There were presentations on requirements for EAP methods and different types of methods. We had a discussion on the different types of credentials and authentication infrastructures that methods can support. In the end we reached consensus to create a working group to look at three things: (1) an update of EAP-TLS for certificate-based infrastructure (2) a method based on strong shared secrets (3) a method based on using existing password infrastructure such as AAA servers password databases It would be better if some of these requirements could be combined into one mechanism, however it was brought up that this may not be possible to do and still maintain compact mechanism implementations that are usable in constrained environments. After these work items are done it will be possible to add additional items to the working group charter to work on additional methods. The meeting concluded with presentations on several EAP method drafts. From hartmans@MIT.EDU Mon Nov 21 14:24:15 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jALJOF1r021790 for ; Mon, 21 Nov 2005 14:24:15 -0500 (EST) Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148])jALJOC7O016558 for ; Mon, 21 Nov 2005 14:24:12 -0500 (EST) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id A71C7E0075; Mon, 21 Nov 2005 14:24:12 -0500 (EST) To: saag@mit.edu From: Sam Hartman Message-Id: <20051121192412.A71C7E0075@carter-zimmerman.mit.edu> Date: Mon, 21 Nov 2005 14:24:12 -0500 (EST) X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.654595 Subject: [saag] Draft Minutes for IETf 64 SAAG meeting X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 21 Nov 2005 19:24:16 -0000 Please comment within the next week Security Area Advisory Group (SAAG) IETF64, Vancouver, Canada Minutes compiled by Sam Hartman and Russ Housley Scribe: Jeff Hutzelman Introduction Russ Housley presented the agenda: WG Reports BoF Reports Deploying a New Hash Function Security Area Response to Hash Function Breaks Open Microphone Working Group and BoF Reports ( Each working group or BoF that had a meeting at IETF 63 gave a very brief summary of the session. Please see the minutes for each of these sessions. The highlights are not repeated here. Reports were given by: PKIX Kerberos S/MIME Syslog SASL ISMS TLS PKi4IPSEC MSEC Kitten MMUSIC [xxx this is not ours] INCH MOBIKE BTNS DKIM BOF EMU BOF Deploying a New Hash Function Eric Rescorla presented the paper he co-authored with Steve Bellovin on deploying new hash functions in IETF protocols. All the protocols analyzed required work in order to support new hash functions. Security Area Response to Hash Function Breaks Russ said we should "walk, not run." This is not a problem yet but as attacks are improved it will become a problem. NIST held a hash workshop. Conclusions from that workshop include a reminder that SHA-1 should be EOLed for digital signatures by 2010. Also, we cannot expect any new standardized hash functions before then. The security ADs have decided that we need to transition to sha-256 now. There will probably be a later transition to something new after it is developed. So, we need to become good at transitions as we have at least two. Protocols with active WGs will be analyzed within those WGs; others in SAAG. Directives to WGs/Chairs: Do analysis on every protocol in the WG by IETF 65 Start standards work on transition to sha-256, but plan for future transitions. Several issues were discused. In some cases it may be appropriate to transition away from a hash entirely to a MAC or other primitive. There are concerns about the operational issues of transitions: protocol specification is only part of the problem. Uri Blumenthal is concerned about the decision to choose sha-256. He said that sha-256 is based on intuitive rather than scientific principles; we have already lost on that with sha-0 and sha-1. Russ pointed out that there was a lot of discussion of that issue at the hash workshop and this is the best call we can make. Randomized hashing was discussed; in some cases this is a good idea. However we don't have a recommended randomized hash construction. We will handle protocols outside the security area as time goes on; we will lead by example by first solving problems within the area. david McGrew is concerned that hmac-md5 may be the next target; hmac-sha-1 is still believed safe. Open Microphone Uri Blumenthal gave a presentation on a possible alternative to sha-1 during open mic. His slides are included in the presentations. Two major concerns were raised. First it is not clear this work has had sufficient review. Second, it would still leave us with a 160-bit hash, which would not meet our goal of getting to something longer by 2010. Nico Williams expressed disappointment that we were not discussing the KDF today. Russ said that the KDF document needs work. Russ said that the NIST document only covers one use of KDFs. Sam indicated there was a lot of concern about NIST creating a situation where a lot of IETF protocols could not get FIPS 140-2 certification. Sam pointed out that section 4.5 of RFC 3766 is an IETf BCP describing a key derivation function. The NIST function seems a lot better; we probably want to fix 3766. From housley@vigilsec.com Fri Nov 25 12:26:34 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jAPHQX1r002105 for ; Fri, 25 Nov 2005 12:26:33 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) jAPHQVZ9028142 for ; Fri, 25 Nov 2005 12:26:31 -0500 (EST) Received: (qmail 9361 invoked by uid 0); 25 Nov 2005 17:26:24 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (66.44.57.244) by woodstock.binhost.com with SMTP; 25 Nov 2005 17:26:24 -0000 Message-Id: <7.0.0.10.2.20051124135914.00f50558@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Thu, 24 Nov 2005 14:12:35 -0500 To: ietf@ietf.org, wgchairs@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.352 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.600391 cc: secdir@mit.edu cc: saag@mit.edu Subject: [saag] Security Area Response to Hash Function "Breaks" X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 25 Nov 2005 17:26:34 -0000 Below is a summary of the discussion that occurred at the SAAG session during IETF 64. When MD5 or SHA-1 is used to support digital signatures or used by itself, recent cryptographic research findings indicate the need for a transition. Therefore, I encourage all IETF WGs to follow the lead of the Security Area in transition away from MD5 and SHA-1 toward SHA-256. TCP-MD5 is one example where a transition is needed. In this case, a transition to HMAC-SHA-1 or HMAC-SHA-256 seems like a reasonable move. Russ Housley Security Area Director = = = = = = = = = = During IETF 64, the Security Area Advisors Group (SAAG) session was dedicated to the discussion of hash function "breaks" and the appropriate IETF response to this situation. Eric Rescorla from gave a presentation on deploying a new hash function. The presentation is based on a paper that Eric co-authored with Steve Bellovin. All of the IETF security protocols that were analyzed required work in order to support transition to new hash functions. The paper is available at http://www.cs.columbia.edu/~smb/papers/new-hash.pdf Russ Housley gave a presentation on the Security Area response to these hash function "breaks." We should "walk, not run." This is not a problem yet, but as the attacks are improved it will become a problem. Russ shared his conclusions from the NIST Hash Workshop held on October 31st and November 1st. * SHA-1 should be reach its "end of life" digital signatures by 2010; * The IETF cannot expect any new standard hash functions before 2010; * The security ADs have decided that we need to transition to SHA-256 now; and * There will probably be another transition once a new hash function is available. The IETF needs to become good at transitions as we have at least two. Within the Security Area, protocols with active WGs will be analyzed within those WGs; others will be handled in SAAG. The following directive to WG Chairs in the Security Area was given: * Perform Bellovin-Rescorla analysis on every protocol in the WG by IETF 65; and * Start standards work on transition to SHA-256, but plan for future transitions. In some cases it may be appropriate to transition away from hash functions, perhaps to a message authentication code. From mouse@Sparkle.Rodents.Montreal.QC.CA Fri Nov 25 12:50:42 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jAPHod1r002447 for ; Fri, 25 Nov 2005 12:50:39 -0500 (EST) Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7])jAPHoSZ9023715; Fri, 25 Nov 2005 12:50:28 -0500 (EST) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id MAA11848; Fri, 25 Nov 2005 12:50:27 -0500 (EST) From: der Mouse Message-Id: <200511251750.MAA11848@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Fri, 25 Nov 2005 12:42:28 -0500 (EST) To: secdir@mit.edu, saag@mit.edu Subject: Re: [saag] Security Area Response to Hash Function "Breaks" In-Reply-To: <7.0.0.10.2.20051124135914.00f50558@vigilsec.com> References: <7.0.0.10.2.20051124135914.00f50558@vigilsec.com> X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.542269 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 25 Nov 2005 17:50:42 -0000 > * There will probably be another transition once a new hash > function is available. This implies that there aren't other hash functions available now, which is false. (As a really simple example, any block cipher can be turned into a hash function in at least two ways that even I can think of offhand.) Is it simply a question of looking for hash functions that have attracted serious cryptographer time examining their security, or is there something else going on? Personally, I am inclined to distrust SHA-256 because it is basically the same design as SHA-1 and MD5 - but as a cryptographer I'm strictly a dilettante. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From smb@cs.columbia.edu Fri Nov 25 13:41:54 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jAPIfr1r003023 for ; Fri, 25 Nov 2005 13:41:53 -0500 (EST) Received: from machshav.com (machshav.com [147.28.0.16]) jAPIfhsQ002568; Fri, 25 Nov 2005 13:41:43 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id BFDCAFB28A; Fri, 25 Nov 2005 13:41:42 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B9E26FB286; Fri, 25 Nov 2005 13:41:41 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 9395D3BFFBC; Fri, 25 Nov 2005 13:41:40 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: der Mouse Subject: Re: [saag] Security Area Response to Hash Function "Breaks" In-Reply-To: Your message of "Fri, 25 Nov 2005 12:42:28 EST." <200511251750.MAA11848@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Nov 2005 13:41:40 -0500 Sender: smb@cs.columbia.edu Message-Id: <20051125184140.9395D3BFFBC@berkshire.machshav.com> X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.623046 X-Mailman-Approved-At: Fri, 25 Nov 2005 16:07:46 -0500 cc: secdir@mit.edu cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 25 Nov 2005 18:41:55 -0000 In message <200511251750.MAA11848@Sparkle.Rodents.Montreal.QC.CA>, der Mouse wr ites: >> * There will probably be another transition once a new hash >> function is available. > >This implies that there aren't other hash functions available now, >which is false. (As a really simple example, any block cipher can be >turned into a hash function in at least two ways that even I can think >of offhand.) Is it simply a question of looking for hash functions >that have attracted serious cryptographer time examining their >security, or is there something else going on? Several things. First, block ciphers are in general much slower than hash functions. Second, other hash functions haven't received the necessary degree of scrutiny, either. One reason NIST is not having a hash function competition now is that the consensus in the community is that we don't know enough about design or analysis principles. Third, conversions take a long time. If we knew what we wanted *today*, it would take at least 5 years and more likely 7 for a large portion of the net to convert -- a few years for design/code/test and the release cycle, plus 4-5 years for old machines to die off and be replaced, since many machines are never upgraded. > >Personally, I am inclined to distrust SHA-256 because it is basically >the same design as SHA-1 and MD5 - but as a cryptographer I'm strictly >a dilettante. > There was no consensus on this latter point at the NIST workshop. Bart Preneel noted that if SHA-1 had double the number of rounds, the workshop wouldn't have happened. If MD5 had double the number of rounds, it would still be strong enough. If I recall correctly, three of the four members of one panel felt that SHA-256 was ok; the fourth, one of Shamir's grad students, felt that it was not. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb From housley@vigilsec.com Sun Nov 27 15:54:17 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jARKsE1r019602 for ; Sun, 27 Nov 2005 15:54:14 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) jARKsCYT011724 for ; Sun, 27 Nov 2005 15:54:12 -0500 (EST) Received: (qmail 4110 invoked by uid 0); 27 Nov 2005 20:54:05 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.159.19) by woodstock.binhost.com with SMTP; 27 Nov 2005 20:54:05 -0000 Message-Id: <7.0.0.10.2.20051127153643.06281070@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Sun, 27 Nov 2005 15:39:41 -0500 To: der Mouse From: Russ Housley Subject: Re: [saag] Security Area Response to Hash Function "Breaks" In-Reply-To: <200511251750.MAA11848@Sparkle.Rodents.Montreal.QC.CA> References: <7.0.0.10.2.20051124135914.00f50558@vigilsec.com> <200511251750.MAA11848@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.570750 cc: secdir@mit.edu cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 27 Nov 2005 20:54:18 -0000 These points were made at the NIST Hash Workshop. To each, someone had a counter-argument. My conclusion is that SHA-256 needs more study, but the study that has received indicates that it will stand for the rest of this decade. That should allow sufficient time for another hash function to be selected in which we have more confidence. Russ At 12:42 PM 11/25/2005, der Mouse wrote: > > * There will probably be another transition once a new hash > > function is available. > >This implies that there aren't other hash functions available now, >which is false. (As a really simple example, any block cipher can be >turned into a hash function in at least two ways that even I can think >of offhand.) Is it simply a question of looking for hash functions >that have attracted serious cryptographer time examining their >security, or is there something else going on? > >Personally, I am inclined to distrust SHA-256 because it is basically >the same design as SHA-1 and MD5 - but as a cryptographer I'm strictly >a dilettante. > >/~\ The ASCII der Mouse >\ / Ribbon Campaign > X Against HTML mouse@rodents.montreal.qc.ca >/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B >_______________________________________________ >saag mailing list >saag@mit.edu >http://jis.mit.edu/mailman/listinfo/saag From pbaker@verisign.com Mon Nov 28 14:48:48 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jASJml1r028136 for ; Mon, 28 Nov 2005 14:48:47 -0500 (EST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) jASJmURi006988; Mon, 28 Nov 2005 14:48:31 -0500 (EST) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.13.1/8.13.4) with ESMTP id jASJmMlA004587; Mon, 28 Nov 2005 11:48:22 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 28 Nov 2005 11:48:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [saag] Security Area Response to Hash Function "Breaks" Date: Mon, 28 Nov 2005 11:48:22 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD377C258E@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Security Area Response to Hash Function "Breaks" Thread-Index: AcXyBh+5MLZf53+XTCu8ML3+wQfVIwCTa1mA From: "Hallam-Baker, Phillip" To: "Steven M. Bellovin" , "der Mouse" X-OriginalArrivalTime: 28 Nov 2005 19:48:22.0137 (UTC) FILETIME=[B0406E90:01C5F454] X-Spam-Score: -2.465 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.566226 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id jASJml1r028136 cc: secdir@mit.edu cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 28 Nov 2005 19:48:50 -0000 > Behalf Of Steven M. Bellovin > There was no consensus on this latter point at the NIST > workshop. Bart Preneel noted that if SHA-1 had double the > number of rounds, the workshop wouldn't have happened. If > MD5 had double the number of rounds, it would still be strong > enough. If I recall correctly, three of the four members of > one panel felt that SHA-256 was ok; the fourth, one of > Shamir's grad students, felt that it was not. While I agree that it is quite likely that SHA-256 will turn to offer more than sufficient security there is a process at work and it is not clear at this point what the question asked in that process will be. One possible question for the NIST process is 'what is the best next generation hash algorithm', another is 'is SHA-256 unacceptably insecure and if so what should the replacement be?' I think it is unlikely that the answer to the first question will be SHA-256, but there is perhaps an argument to be made in favor of a thumb on the scales. One argument in favor of SHA-256 is that although there are known compromises against the technique we know rather more about that technique now than others. So we can asses the strength of each round more accurately than for alternative constructions. It might well be that the outcome of the process might be 'use SHA-512 truncated to 256 bits' or some such, the longer hashes also have more rounds. From mcr@sandelman.ottawa.on.ca Tue Nov 29 11:04:57 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jATG4u1r006377 for ; Tue, 29 Nov 2005 11:04:56 -0500 (EST) Received: from lists.sandelman.ca (cod.sandelman.ca [192.139.46.139]) jATG4aPo013958; Tue, 29 Nov 2005 11:04:40 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id jATG4ST24878 verified OK); Tue, 29 Nov 2005 11:04:35 -0500 (EST) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id C454E3AD9C; Tue, 29 Nov 2005 11:03:58 -0500 (EST) To: secdir@mit.edu, saag@mit.edu Subject: Re: [saag] Security Area Response to Hash Function "Breaks" In-Reply-To: Message from "Hallam-Baker, Phillip" <198A730C2044DE4A96749D13E167AD377C258E@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD377C258E@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Tue, 29 Nov 2005 11:03:58 -0500 Message-ID: <10671.1133280238@sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.631158 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 29 Nov 2005 16:04:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 To quote Russ: "walk, not run to SHA-256" "do so by 2010" In Openswan (IPsec for Linux), we already permit SHA-256 for session use, but it isn't on by default. Likely, we will add it to our "default" set. (the one you get if you don't ask for anything else). I think it will be #2 of 3: SHA1 SHA-256 MD5 Having said that, we unfortunately still have some places in our code that reads: switch(alg) { case md5: stuff. case sha1: stuff. default: /* do something more complicated, and less well tested */ } My goal in introducing SHA-256 is to actually get rid of the md5/sha1 cases, and always use the one case that will become well tested. So the push to SHA-256 (or ANY other hash) will increase agility for us. I am interested in Uri's SHA1-UEI (did I get that right?), and I'd like to see an informational RFC on it that asks IANA for numbers. I would also like to see a non-keyed HMAC-SHA1 defined. (set the key to a constant). I am presuming two things about this. a) it is valuable to re-use HMAC-SHA1 for which *TESTED* and optomized libraries and perhaps hardware is already available for. b) there is some bulk user of SHA1 (other than IPsec, which uses HMAC-SHA1), which would benefit from a hash verion of HMAC-SHA1. (TLS? or would it prefer keyed-HMAC-SHA1) I believe that a number of things have been proposed that can be used by CA's to add some non-determinism to the thing that they are hashing with SHA1 before signing. (without changing the protocol, I think) I think that this is actually the thing that matters most. I'm not clear how they can all work. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBQ4x764CLcPvd0N1lAQKEJAf/S+SrE8DsLrALvq88fWmuO2adYxb/TNpC e6+qI3wapF0E0W3Mg8Yzo7GNONvVmALvxkf1iOV9JxLT52jK+HqoV6h2caT0y2XJ 8WcfeteQdSPJqBj6AEFkERpCjW6bpBOqO7xD9xWpr4gcnOc6n9clEi8HqUk0ibew 99gkH+EQj6WndyIBscRqTNfX4YRWxyeoM0DYxoWKUHnalcCru2vg4a1zS+Cy1s1F Ggwc1JvPkuOE9r8cQULjBvKFZ7+y7X/JsK2GCKpcR1EhjgHkULLpqXP3/YEqftx4 4u6j5oRtbidkmb9LeG1TX5o5pmwfB0e6NHD+zZOnteCmr7NIE2ZPGA== =irTR -----END PGP SIGNATURE----- From paul.hoffman@vpnc.org Wed Nov 30 15:43:43 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jAUKhb1r020103 for ; Wed, 30 Nov 2005 15:43:42 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) jAUKhJR0014552 for ; Wed, 30 Nov 2005 15:43:19 -0500 (EST) Received: from [10.20.30.249] (dsl2-63-249-109-231.cruzio.com [63.249.109.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUKhGKD047931 for ; Wed, 30 Nov 2005 12:43:18 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 30 Nov 2005 12:43:26 -0800 To: saag@mit.edu From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.574077 Subject: [saag] Structure of documents discussing protocols and hashes X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 30 Nov 2005 20:43:43 -0000 Greetings again. I have published an Internet Draft that discusses how IKE and IPsec use hash functions; it is now available at . I have started a thread on the IPsec ex-WG mailing list about the protocol-specific parts of that draft. Give that every IETF protocol that uses hashes is going to need such a document, it would be good if we had a model or template for them. Given that this is (or may be?) the first such document, it might be appropriate for folks here to discuss what should go into such a document. The outline of my -00 draft is: 1. Introduction 2. Hashes in IKEv1 and IKEv2 3. Hashes in IPsec 4. PKIX Certificates 5. Suggested Changes 5.1. Suggested Changes for the Protocols 5.2. Suggested Changes for Implementors 6. Security Considerations 7. Informative References Sections 2 and 3 are a detailed list of how hashes are used in the protocols. Because you can use PKIX certificates for authentication in IKE, Section 4 covers that separately. (One hopes that the PKIX WG creates their own document on this topic that can be referenced...). Section 5 covers all the suggested changes (and lack thereof) that come from the analysis in Sections 2, 3, and 4. The Security Considerations section is fairly stubby, and all the references are Informative because this is not a standards-track document. How do folks feel about such a structure? Are there more sections to add? What else should be covered in these kinds of documents? --Paul Hoffman, Director --VPN Consortium From mcr@sandelman.ottawa.on.ca Wed Nov 30 16:00:47 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jAUL0Y1r020242 for ; Wed, 30 Nov 2005 16:00:47 -0500 (EST) Received: from lists.sandelman.ca (cod.sandelman.ca [192.139.46.139]) jAUL0KR0025503 for ; Wed, 30 Nov 2005 16:00:22 -0500 (EST) Received: from sandelman.ottawa.on.ca (CPE0006b123a026-CM0011aea1b6fc.cpe.net.cable.rogers.com [65.49.207.194]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id jAUL0Ci20450 verified OK); Wed, 30 Nov 2005 16:00:18 -0500 (EST) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 2BC0B3AD9C; Wed, 30 Nov 2005 16:00:12 -0500 (EST) To: Paul Hoffman Subject: Re: [saag] Structure of documents discussing protocols and hashes In-Reply-To: Message from Paul Hoffman of "Wed, 30 Nov 2005 12:43:26 PST." References: X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Wed, 30 Nov 2005 16:00:11 -0500 Message-ID: <9375.1133384411@sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.579787 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 30 Nov 2005 21:00:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Paul" == Paul Hoffman writes: Paul> Sections 2 and 3 are a detailed list of how hashes are used in Paul> the protocols. Because you can use PKIX certificates for Paul> authentication in IKE, Section 4 covers that separately. (One Paul> hopes that the PKIX WG creates their own document on this Paul> topic that can be referenced...). Section 5 covers all the Having not read it yet, it seems that there are differences between the general problem (where you can't control the CAs used), and the IPsec situation (where we have had to have total control over the CA involved, cf: pki4ipsec.) Paul> How do folks feel about such a structure? Are there more Paul> sections to add? What else should be covered in these kinds of Paul> documents? It suits me. I'll go read it. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBQ44S2YCLcPvd0N1lAQKGowf9EkcnHo7p1xidEHj/WI73My0rn/j3Y0Lc BJAUSlSVs4Fgfvt2Yb3CxzPTYNTXLJ3X2ADyYTvIP94Bz/qwbKCJdpJdjVxhnijS P28h0Y5dRhsZcgnfg6g3b595qLy/60s54aiiQEy1EJ79eJfdHXfHvk8MtCsm3vAf LTj9FG12rGQiz5fWa5q+UARB3+oVVEv16FYRv98Jjo3nqX8xzvQb9/L9mrDVIHPv 7bnQuy+Lv9sluMR6ZIIl3CZO3Fz9kDah8rNmmk0qOC9xpdo6WaHKzFv4cNyTv8/C 9AUdmBpaUYSrPIE5KjRWtL/niss6wroNt+9GvYQTbU3c22kHOF3ujg== =ih7a -----END PGP SIGNATURE----- From mcgrew@cisco.com Wed Nov 30 17:23:13 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jAUMNC1r020915 for ; Wed, 30 Nov 2005 17:23:12 -0500 (EST) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) jAUMN7Y0021869 for ; Wed, 30 Nov 2005 17:23:07 -0500 (EST) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 30 Nov 2005 14:23:05 -0800 X-IronPort-AV: i="3.99,196,1131350400"; d="scan'208"; a="679900993:sNHT2686171380" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAUMMLCn002989; Wed, 30 Nov 2005 14:23:04 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Nov 2005 17:22:50 -0500 Received: from [161.44.57.78] ([161.44.57.78]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Nov 2005 17:22:50 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: [saag] Structure of documents discussing protocols and hashes Date: Wed, 30 Nov 2005 14:22:51 -0800 To: Paul Hoffman X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 30 Nov 2005 22:22:50.0733 (UTC) FILETIME=[999771D0:01C5F5FC] X-Spam-Score: -2.4 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.617045 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 30 Nov 2005 22:23:14 -0000 Hi Paul, good to see this work. I'm glad that you're suggesting using dedicated message authentication codes in Section 5.2 - this is certainly a good approach. It would be good to also reference RFC 3566 for AES-XCBC-MAC-96, and also mention AES GCM ESP (RFC 4106) as another alternative, which has performance advantages over SHA1 based algorithms as well. I think that it's worth suggesting that implementors move to a SHA-256 based PRF for IKE. The structure of the document looks OK to me. An alternative would be to identify every use of a hash, and for each use describe the security considerations and list the alternatives. If there were many hash uses, this structure would probably be better, but I don't think that's the case here. David On Nov 30, 2005, at 12:43 PM, Paul Hoffman wrote: > Greetings again. I have published an Internet Draft that discusses > how IKE and IPsec use hash functions; it is now available at > use-00.txt>. I have started a thread on the IPsec ex-WG mailing > list about the protocol-specific parts of that draft. > > Give that every IETF protocol that uses hashes is going to need > such a document, it would be good if we had a model or template for > them. Given that this is (or may be?) the first such document, it > might be appropriate for folks here to discuss what should go into > such a document. The outline of my -00 draft is: > > 1. Introduction > 2. Hashes in IKEv1 and IKEv2 > 3. Hashes in IPsec > 4. PKIX Certificates > 5. Suggested Changes > 5.1. Suggested Changes for the Protocols > 5.2. Suggested Changes for Implementors > 6. Security Considerations > 7. Informative References > > Sections 2 and 3 are a detailed list of how hashes are used in the > protocols. Because you can use PKIX certificates for authentication > in IKE, Section 4 covers that separately. (One hopes that the PKIX > WG creates their own document on this topic that can be > referenced...). Section 5 covers all the suggested changes (and > lack thereof) that come from the analysis in Sections 2, 3, and 4. > The Security Considerations section is fairly stubby, and all the > references are Informative because this is not a standards-track > document. > > How do folks feel about such a structure? Are there more sections > to add? What else should be covered in these kinds of documents? > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > saag mailing list > saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag > From uri.blumenthal@intel.com Mon Nov 28 15:36:41 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jASKae1r028673 for ; Mon, 28 Nov 2005 15:36:40 -0500 (EST) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) jASKaVTo001478; Mon, 28 Nov 2005 15:36:31 -0500 (EST) Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.253.24.21]) 2004/09/17 17:50:56 root Exp $) with ESMTP id jASKaUqc003726; Mon, 28 Nov 2005 20:36:30 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) 2004/09/17 18:05:01 root Exp $) with SMTP id jASKaSVC014198; Mon, 28 Nov 2005 20:36:30 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) M2005112812363015325 ; Mon, 28 Nov 2005 12:36:30 -0800 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Nov 2005 12:36:30 -0800 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Nov 2005 12:36:30 -0800 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Nov 2005 15:36:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [secdir]RE: [saag] Security Area Response to Hash Function "Breaks" Date: Mon, 28 Nov 2005 15:34:44 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929023A46E3@pysmsx401.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [secdir]RE: [saag] Security Area Response to Hash Function "Breaks" Thread-Index: AcXyBh+5MLZf53+XTCu8ML3+wQfVIwCTa1mAAAGdExA= From: "Blumenthal, Uri" To: , X-OriginalArrivalTime: 28 Nov 2005 20:36:28.0019 (UTC) FILETIME=[685F1430:01C5F45B] X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.52 on 10.253.24.21 X-Spam-Score: -0.891 X-Spam-Flag: NO Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.608546 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id jASKae1r028673 X-Mailman-Approved-At: Wed, 30 Nov 2005 23:45:08 -0500 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 28 Nov 2005 20:36:41 -0000 >> There was no consensus on this latter point at the NIST >> workshop. Bart Preneel noted that if SHA-1 had double the >> number of rounds, the workshop wouldn't have happened. If >> MD5 had double the number of rounds, it would still be strong >> enough. If I recall correctly, three of the four members of >> one panel felt that SHA-256 was ok; the fourth, one of >> Shamir's grad students, felt that it was not. > >While I agree that it is quite likely that SHA-256 will turn to offer >more than sufficient security there is a process at work and it is not >clear at this point what the question asked in that process will be. The current bet is that it will hold at least till the end of decade. However even if true, it may turn out insufficiently long. >One possible question for the NIST process is 'what is the best next >generation hash algorithm', another is 'is SHA-256 unacceptably insecure >and if so what should the replacement be?' I totally agree. >I think it is unlikely that the answer to the first question will be >SHA-256, but there is perhaps an argument to be made in favor of a thumb >on the scales. Likewise. Whirlpool-style approach sounds like the most promising direction. >One argument in favor of SHA-256 is that although there are known >compromises against the technique we know rather more about that >technique now than others. So we can asses the strength of each round >more accurately than for alternative constructions. I disagree. We know enough only inasmuch as we can apply block cipher model. The claim is: SHA-256 is close enough to a block cipher for the block cipher-specific attacks to apply - but not close enough to directly apply block cipher defenses. >It might well be that the outcome of the process might be 'use SHA-512 >truncated to 256 bits' or some such, the longer hashes also have more >rounds. It is hardly proper: truncation implies that all the output bits are "equal" entropy-wise, which they are not. John Kelsey demonstrated nice collisions which don't exist in the original function (SHA512 in this case) but occur in the truncated version. If you don't know how secure you are to begin with - truncating is likely to make situation a lot worse. From uri.blumenthal@intel.com Tue Nov 29 12:09:27 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jATH9Q1r009017 for ; Tue, 29 Nov 2005 12:09:26 -0500 (EST) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) jATH9FPo023138; Tue, 29 Nov 2005 12:09:16 -0500 (EST) Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.253.24.21]) 2004/09/17 17:50:56 root Exp $) with ESMTP id jATH9FdR008497; Tue, 29 Nov 2005 17:09:15 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) 2004/09/17 18:05:01 root Exp $) with SMTP id jATH91I1008095; Tue, 29 Nov 2005 17:09:15 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) M2005112909091423682 ; Tue, 29 Nov 2005 09:09:14 -0800 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Nov 2005 09:09:14 -0800 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Nov 2005 09:09:13 -0800 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Nov 2005 12:09:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5F507.9D6790C7" Date: Tue, 29 Nov 2005 12:07:25 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929023A4DE9@pysmsx401.amr.corp.intel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: SHA1 Thread-Index: AcX0/wZhnEieAUhWRqOl2Fs8oh3r7QAATKQg From: "Blumenthal, Uri" To: , X-OriginalArrivalTime: 29 Nov 2005 17:09:11.0020 (UTC) FILETIME=[9DC162C0:01C5F507] X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.52 on 10.253.24.21 X-Spam-Score: -0.891 X-Spam-Flag: NO Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 1.256952 X-Mailman-Approved-At: Wed, 30 Nov 2005 23:45:09 -0500 Subject: [saag] RE: SHA1 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 29 Nov 2005 17:09:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5F507.9D6790C7 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 > My goal in introducing SHA-256 is to actually get rid of the md5/sha1 > cases, and always use the one case that will become well tested. So the > push to SHA-256 (or ANY other hash) will increase agility for us. Understandable goal. But we don't know the "real" strength of SHA-256 yet... We hope that our intuition is correct this time, and SHA-256 will hold up. > I am interested in Uri's SHA1-UEI (did I get that right?), and I'd like > to see an informational RFC on it that asks IANA for numbers.=20 It's SHA1-IME (:-) - as in Improved Message Expansion. Relevant ID is enclosed. > I would also like to see a non-keyed HMAC-SHA1 defined. (set the key to > a constant). But you do realize that all the proofs about HMAC fly out of the window if the key is non-secret? It is quite possible that current attacks are extendable to HMAC-XXX *IF* the key is public. > I am presuming two things about this.=20 > a) it is valuable to re-use HMAC-SHA1 for which *TESTED* and optimized > libraries and perhaps hardware is already available for. Yes - but only for keyed applications (because that's where it is secure - see above). > b) there is some bulk user of SHA1 (other than IPsec, which uses > HMAC-SHA1), which would benefit from a hash verion of HMAC-SHA1.=20 > (TLS? or would it prefer keyed-HMAC-SHA1) There is no secure "non-key" version of HMAC. The way it foils adversaries is by making it infeasible to extend an attack through unknown values (provided by the secret key). > I believe that a number of things have been proposed that can be used by > CA's to add some non-determinism to the thing that they are hashing with > SHA1 before signing. (without changing the protocol, I think) Unfortunately, no. Randomizing hash involves both changing the API and the standards (therefore the protocols). Mucking the plaintext before hashing hurts performance and may or may not offer any security gain. Overall, IMHO we all will be much better off with a good cryptographically strong new hash-function. ------_=_NextPart_001_01C5F507.9D6790C7 Content-Type: text/plain; name="draft-irtf-cfrg-sha1-ime-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-irtf-cfrg-sha1-ime-00.txt Content-Disposition: attachment; filename="draft-irtf-cfrg-sha1-ime-00.txt" DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgIENyeXB0byBGb3J1bSBS ZXNlYXJjaCBHcm91cA0KSU5URVJORVQgRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFVyaSBCbHVtZW50aGFsLCBJbnRlbA0KTm92ZW1iZXIgMjAwNSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEMuUy4gSnV0bGEsIElCTQ0KRXhwaXJhdGlvbiBEYXRlOiBNYXkgMjAw NiAgICAgICAgICAgICAgIEEuIEMuIFBhdHRoYWssIFVUIEF1c3Rpbg0KDQogICAgICAgICAgICBT SEExLUlNRTogQSBTSEEtMSBWYXJpYW50IHdpdGggUHJvdmFibHkgR29vZA0KICAgICAgICAgICAg ICAgICAgICAgTWVzc2FnZSBFeHBhbnNpb24gQ29kZQ0KICAgICAgICAgICAgICAgIDxkcmFmdC1p cnRmLWNmcmctc2hhMS1pbWUtMDAudHh0Pg0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgICAg Qnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCAgZWFjaCAgYXV0aG9yICByZXByZXNl bnRzDQogICAgIHRoYXQgIGFueSAgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWlt cyBvZiB3aGljaCBoZQ0KICAgICBvciBzaGUgaXMgYXdhcmUgaGF2ZSBiZWVuIG9yIHdpbGwgYmUg ZGlzY2xvc2VkLCBhbmQgIGFueSAgb2YNCiAgICAgd2hpY2ggIGhlICBvciBzaGUgYmVjb21lcyBh d2FyZSB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3ItDQogICAgIGRhbmNlIHdpdGggU2VjdGlv biA2IG9mIEJDUCA3OS4NCg0KICAgICBUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0 IGFuZCBpcyAgaW4gIGZ1bGwgIGNvbmZvci0NCiAgICAgbWFuY2Ugd2l0aCBhbGwgcHJvdmlzaW9u cyBvZiBTZWN0aW9uIDEwIG9mIFJGQzIwMjYuDQoNCiAgICAgSW50ZXJuZXQtRHJhZnRzICBhcmUg IHdvcmtpbmcgIGRvY3VtZW50cyAgb2YgIHRoZSAgIEludGVybmV0DQogICAgIEVuZ2luZWVyaW5n ICBUYXNrICBGb3JjZSAgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZw0KICAgICBn cm91cHMuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgIHdvcmtp bmcNCiAgICAgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4NCg0KICAgICBJbnRlcm5ldC1E cmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSAgbWF4aW11bSAgb2YNCiAgICAg c2l4ICBtb250aHMgIGFuZCAgbWF5ICBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVk IGJ5DQogICAgIG90aGVyIGRvY3VtZW50cyBhdCBhbnkgdGltZS4gIEl0ICBpcyAgaW5hcHByb3By aWF0ZSAgdG8gIHVzZQ0KICAgICBJbnRlcm5ldC0gRHJhZnRzIGFzIHJlZmVyZW5jZSBtYXRlcmlh bCBvciB0byBjaXRlIHRoZW0gb3RoZXINCiAgICAgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4i DQoNCiAgICAgVGhlIGxpc3Qgb2YgIGN1cnJlbnQgIEludGVybmV0LURyYWZ0cyAgY2FuICBiZSAg YWNjZXNzZWQgIGF0DQogICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3Rz LnR4dA0KDQogICAgIFRoZSAgbGlzdCAgb2YgIEludGVybmV0LURyYWZ0ICBTaGFkb3cgIERpcmVj dG9yaWVzICBjYW4gICBiZQ0KICAgICBhY2Nlc3NlZCBhdCBodHRwOi8vd3d3LmlldGYub3JnL3No YWRvdy5odG1sLg0KDQpBYnN0cmFjdA0KDQogICAgIFRoaXMgZG9jdW1lbnQgIGRlc2NyaWJlcyBh IG5ldyBjcnlwdG9ncmFwaGljICBoYXNoICBmdW5jdGlvbg0KICAgICBTSEExLUlNRSAgd2l0aCBp bnB1dCBhbmQgb3V0cHV0IHBhcmFtZXRlcnMgaWRlbnRpY2FsIHRvIFNIQS0NCiAgICAgMS4gRnVy dGhlciwgdGhlIHNwZWNpZmljYXRpb24gb2YgU0hBMS1JTUUgIGlzICBpZGVudGljYWwgIHRvDQog ICAgIHRoYXQgIG9mICBTSEEtMSwgIGV4Y2VwdCAgZm9yICBhbiBpbXByb3ZlZCBtZXNzYWdlIGV4 cGFuc2lvbg0KICAgICBjb2RlLiBUaGUgaW1wcm92ZWQgIG1lc3NhZ2UgIGV4cGFuc2lvbiAgaXMg IHByb3ZlbiAgdG8gIG1ha2UNCiAgICAgU0hBMS1JTUUgIHJlc2lzdGFudCB0byByZWNlbnQgZGlm ZmVyZW50aWFsIGF0dGFja3MgYW5kIHRoZWlyDQogICAgIG5hdHVyYWwgZXh0ZW5zaW9ucy4NCiAg ICAgICBNb3Jlb3ZlciwgU0hBMS1JTUUgaGFzIG9ubHkgYSA1JSBvdmVyaGVhZCB3aGVuIGNvbXBh cmVkIHRvDQogICAgIFNIQS0xICBpbiAgYSBzb2Z0d2FyZSBpbXBsZW1lbnRhdGlvbi4gIFRoZSBz aW1wbGljaXR5IG9mIHRoZQ0KICAgICBkZXNpZ24gY2hhbmdlLCBjb21wYXRpYmlsaXR5IHdpdGgg U0hBLTEgcGFyYW1ldGVycywgYW5kICB0aGUNCiAgICAgZXhjZWxsZW50ICBzcGVlZC9zZWN1cml0 eSAgdHJhZGVvZmYgbWFrZXMgaXQgYW4gaWRlYWwgY2FuZGktDQogICAgIGRhdGUgZm9yIFNIQS0x IHJlcGxhY2VtZW50Lg0KDQoNCg0KDQoNCkJKUCAgICAgICAgPGRyYWZ0LWlydGYtY2ZyZy1zaGEx LWltZS0wMC50eHQ+ICAgICAgICAgIDENCg0KDQoNCg0KDQoNCg0KDQoNCg0KICAgICAgICAgICAg ICAgICAgICAgICAgVGFibGUgb2YgQ29udGVudHMNCg0KDQoNCg0KMS4gSW50cm9kdWN0aW9uIC4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uICAgIDMNCg0KMi4gQklU IFNUUklOR1MgQU5EIElOVEVHRVJTIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uICAg IDQNCg0KMy4gT1BFUkFUSU9OUyBPTiBXT1JEUyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uICAgIDQNCg0KNC4gTUVTU0FHRSBQQURESU5HIC4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uICAgIDUNCg0KNS4gRlVOQ1RJT05TIFVTRUQgLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uICAgIDYNCg0KNi4gQ09OU1RBTlRTIFVT RUQgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uICAgIDcNCg0KNy4g Q09NUFVUSU5HIFRIRSBNRVNTQUdFIERJR0VTVCAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u ICAgIDcNCg0KOC4gSW50ZWxsZWN0dWFsIFByb3BlcnR5IElzc3VlcyAuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uICAgIDgNCg0KOS4gVEVTVCBWRUNUT1JTIC4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uICAgIDgNCg0KMTAuIEFja25vd2xlZGdtZW50cyAuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uICAgIDkNCg0KMTEuIFJlZmVyZW5j ZXMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uICAgIDkNCg0K MTIuIEF1dGhvcnMnIEFkZHJlc3MgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uICAgIDkNCg0KMTMuIENvcHlyaWdodCBOb3RpY2UgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uICAgMTANCg0KQVBQRU5ESVggIEEsIEIgJiBDIChSZWZlcmVuY2UgSW1w bGVtZW50YXRpb24pIA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQpCSlAgICAgICAgIDxkcmFmdC1pcnRmLWNmcmctc2hhMS1pbWUtMDAudHh0PiAgICAgICAgICAy DQoNCg0KDQoNCg0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgTm92IDIwMDUNCg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgICAgSW4gdGhp cyBkb2N1bWVudCB3ZSBwcm9wb3NlIGEgbmV3IGNyeXB0b2dyYXBoaWMgIGhhc2ggIGZ1bmMtDQog ICAgIHRpb24gIFNIQTEtSU1FIChTSEEtMSB3aXRoIEltcHJvdmVkIE1lc3NhZ2UgRXhwYW5zaW9u KS4gVGhpcw0KICAgICBkb2N1bWVudCB3aWxsIGNsb3NlbHkgIGZvbGxvdyAgdGhlICBzcGVjaWZp Y2F0aW9uICBvZiAgU0hBLTENCiAgICAgZ2l2ZW4gaW4gRklQUyBQVUIgMTgwLTEgKFtTSEExXSku DQoNCiAgICAgQXMgZm9yIFNIQS0xLCB0aGUgaGFzaCBmdW5jdGlvbiBTSEExLUlNRSBpcyB1c2Vk IHRvICBjb21wdXRlDQogICAgIGEgIGNvbmRlbnNlZCAgcmVwcmVzZW50YXRpb24gb2YgYSBtZXNz YWdlIG9yIGEgZGF0YSBmaWxlLiBJbg0KICAgICBmYWN0LCBTSEExLUlNRSBzbyBjbG9zZWx5ICBy ZXNlbWJsZXMgIFNIQS0xLCAgZXhjZXB0ICBmb3IgIGENCiAgICAgc21hbGwgIG1vZGlmaWNhdGlv biAgaW4gIHRoZSAgY29kZSwgdGhhdCBpdHMgdXNhZ2UgaW4gc2luZ2xlDQogICAgIGJsb2NrLCBh bmQgaW4gbXVsdGkgYmxvY2sgc2V0dGluZ3MgaXMgIGlkZW50aWNhbCAgdG8gIFNIQS0xLg0KICAg ICBUaGUgIHNtYWxsICBtb2RpZmljYXRpb24gaW4gdGhlIGNvZGUgbGVhZHMgdG8gYSBodWdlIGdh aW4gaW4NCiAgICAgc2VjdXJpdHkgb3ZlciBTSEEtMSB3LnIudC4gZGlmZmVyZW50aWFsIGF0dGFj a3MsICBtYWtpbmcgIGl0DQogICAgIGFuICBpZGVhbCAgY2FuZGlkYXRlICBmb3IgYSBTSEEtMSBy ZXBsYWNlbWVudC4gTW9yZW92ZXIsIHRoZQ0KICAgICBzZWN1cml0eSBjbGFpbXMgYXJlIGJhc2Vk IG9uIGFjdHVhbCBwcm9vZnMgKHNlZSBbSlAxXSwgW0pQMl0NCiAgICAgZm9yIGV4dGVuc2l2ZSBz ZWN1cml0eSBhbmFseXNpcyBhbmQgcHJvb2ZzKS4NCg0KICAgICBJbiBhIHNvZnR3YXJlIGltcGxl bWVudGF0aW9uLCBTSEExLUlNRSBoYXMgb25seSBhICA1JSAgb3Zlci0NCiAgICAgaGVhZCAgd2hl biBjb21wYXJlZCB0byBTSEEtMS4gSW4gYSBoaWdoIHBlcmZvcm1hbmNlIGhhcmR3YXJlDQogICAg IGltcGxlbWVudGF0aW9uLCB3ZSBleHBlY3QgU0hBMS1JTUUgdG8gaGF2ZSAgYSAgMTAlICBvdmVy aGVhZA0KICAgICAoY29tcGFyYWJsZSB0byBTSEEtMjU2IFtTSEEyXSkuIEZ1cnRoZXIsIHRoZXJl IGFyZSBubyBJbnRlbC0NCiAgICAgbGVjdHVhbCBQcm9wZXJ0eSBjbGFpbXMgb24gIHRoZSBuZXcg aGFzaCBmdW5jdGlvbiBTSEExLUlNRS4NCg0KICAgICBUbyBnaXZlIGEgYnJpZWYgb3ZlcnZpZXcg b2YgU0hBMS1JTUUsIHJlY2FsbCB0aGF0IGluICBTSEEtMSwNCiAgICAgYSAgbWVzc2FnZSBleHBh bnNpb24gY29kZSBpcyB1c2VkIHRvIGV4cGFuZCA1MTIgYml0cyAocGFja2VkDQogICAgIGluIDE2 IHdvcmRzKSB0byA4MCB3b3Jkcy4gVGhpcyBsaW5lYXIgZXhwYW5zaW9uICBjb2RlLCAgaG93LQ0K ICAgICBldmVyICB0dXJuZWQgIG91dCAgdG8gIGhhdmUgIGEgIG11Y2ggc21hbGxlciBtaW5pbXVt IGhhbW1pbmcNCiAgICAgd2VpZ2h0IHRoYW4gZXhwZWN0ZWQuIFRoaXMgZmFjdCBpcyBhbiBpbnRl Z3JhbCBwYXJ0ICBvZiAgdGhlDQogICAgIHJlY2VudCAgYXR0YWNrICBvZiAgV2FuZyBldCBhbCAo W1dZWV0pIG9uIFNIQS0xLiBUaGUgbWVzc2FnZQ0KICAgICBleHBhbnNpb24gY29kZSBpbiBTSEEx LUlNRSAod2hpY2ggaXMgdGhlIG9ubHkgcGxhY2Ugd2hlcmUgaXQNCiAgICAgZGlmZmVycyAgZnJv bSBTSEEtMSkgaGFzIGJlZW4gcHJvdmVuIHRvIGhhdmUgYSBsYXJnZSBtaW5pbXVtDQogICAgIGhh bW1pbmcgd2VpZ2h0KFtKUDFdKS4gRnVydGhlciwgaXQgaGFzIGJlZW4gc2hvd24gIGluICBbSlAy XQ0KICAgICB0aGF0ICB3aGVuICB0aGUgIG1lc3NhZ2UgIGV4cGFuc2lvbiBjb2RlIGhhcyBhIGxh cmdlIG1pbmltdW0NCiAgICAgaGFtbWluZyB3ZWlnaHQgdGhlbiBkaWZmZXJlbnRpYWwgYXR0YWNr cyAoaW5jbHVkaW5nIFdhbmcgIGV0DQogICAgIGFsICBbV1lZXSBhbmQgaXRzIG5hdHVyYWwgZXh0 ZW5zaW9ucykgY2Fubm90IGJlIHVzZWQgdG8gZmluZA0KICAgICBjb2xsaXNpb25zLg0KDQogICAg IFRoZSBzcGVjaWZpY2F0aW9uIG9mIFNIQTEtSU1FIGRpZmZlcnMgIGZyb20gIFNIQS0xICBpbiAg T05MWQ0KICAgICBzdGVwIChiKSBvZiBzZWN0aW9uIDcgIkNvbXB1dGluZyB0aGUgTWVzc2FnZSBE aWdlc3QiIG9mIEZJUFMNCiAgICAgUFVCIDE4MC0xLiBUaGlzIGNvcnJlc3BvbmRzIHRvIHN0ZXAg KGIpIG9mIHNlY3Rpb24gNyBvZiB0aGlzDQogICAgIGRvY3VtZW50LiAgVGh1cywgcmVwbGFjaW5n IHN0ZXAgKGIpIG9mIHNlY3Rpb24gNyBvZiBGSVBTIFBVQg0KICAgICAxODAtMSAgYnkgc3RlcCAo Yikgb2Ygc2VjdGlvbiAgNyAgb2YgIHRoZSAgY3VycmVudCAgZG9jdW1lbnQNCiAgICAgd291bGQg IGxlYWQgIHRvICBhICBjb3JyZWN0IGltcGxlbWVudGF0aW9uIG9mIFNIQTEtSU1FLiBUZXN0DQog ICAgIFZlY3RvcnMgZm9yIFNIQTEtSU1FIGFyZSAgcHJvdmlkZWQgIGluICBzZWN0aW9uICA5LiAg IEl0ICBpcw0KICAgICBub3Rld29ydGh5ICB0aGF0ICB0aGUgZGVzY3JpcHRpb24gb2YgU0hBLTEg aW4gRklQUyBQVUIgMTgwLTINCiAgICAgaXMgaWRlbnRpY2FsIHRvIHRoZSBkZXNjcmlwdGlvbiBv ZiBTSEEtMSBpbiBGSVBTIFBVQiAgMTgwLTEuDQogICAgIEEgUmVmZXJlbmNlIEltcGxlbWVudGF0 aW9uIGlzIGdpdmVuIGluIHRoZSBhcHBlbmRpeC4NCg0KDQoNCkJKUCAgICAgICAgPGRyYWZ0LWly dGYtY2ZyZy1zaGExLWltZS0wMC50eHQ+ICAgICAgICAgIDMNCg0KDQoNCg0KDQpJbnRlcm5ldCBE cmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOb3YgMjAwNQ0K DQoNCiAgICAgRm9yIGEgbWVzc2FnZSBvZiBsZW5ndGggPCAyXjY0IGJpdHMsIFNIQTEtSU1FIHBy b2R1Y2VzIGEgMTYwDQogICAgIGJpdCBtZXNzYWdlIGRpZ2VzdC4NCg0KMi4gIEJJVCBTVFJJTkdT IEFORCBJTlRFR0VSUw0KDQogICAgIFRoZSAgZm9sbG93aW5nICB0ZXJtaW5vbG9neSAgcmVsYXRl ZCAgdG8gIGJpdCAgc3RyaW5ncyAgIGFuZA0KICAgICBpbnRlZ2VycyB3aWxsIGJlIHVzZWQ6DQoN CiAgICAgYS4gICAgQSBoZXggZGlnaXQgaXMgYW4gZWxlbWVudCBvZiB0aGUgc2V0IHswLCAxLCAu Li4gICwgIDksDQogICAgICAgICAgQSwgIC4uLiAsIEZ9LiBBIGhleCBkaWdpdCBpcyB0aGUgcmVw cmVzZW50YXRpb24gb2YgYSA0LQ0KICAgICAgICAgIGJpdCBzdHJpbmcuDQoNCiAgICAgYi4gICAg QSB3b3JkIGVxdWFscyBhIDMyLWJpdCBzdHJpbmcgd2hpY2ggbWF5IGJlIHJlcHJlc2VudGVkDQog ICAgICAgICAgYXMgIGEgIHNlcXVlbmNlIG9mIDggaGV4IGRpZ2l0cy4gVG8gY29udmVydCBhIHdv cmQgdG8gOA0KICAgICAgICAgIGhleCBkaWdpdHMgZWFjaCA0LWJpdCBzdHJpbmcgaXMgY29udmVy dGVkICB0byAgaXRzICBoZXgNCiAgICAgICAgICBlcXVpdmFsZW50IGFzIGRlc2NyaWJlZCBpbiAo YSkgYWJvdmUuDQoNCiAgICAgYy4gICBBbiBpbnRlZ2VyIGJldHdlZW4gMCBhbmQgMl4zMiAgLSAg MSAgaW5jbHVzaXZlICBtYXkgIGJlDQogICAgICAgICAgcmVwcmVzZW50ZWQgIGFzIGEgd29yZC4g VGhlIGxlYXN0IHNpZ25pZmljYW50IGZvdXIgYml0cw0KICAgICAgICAgIG9mIHRoZSBpbnRlZ2Vy IGFyZSByZXByZXNlbnRlZCBieSAgdGhlICByaWdodC1tb3N0ICBoZXgNCiAgICAgICAgICBkaWdp dCBvZiB0aGUgd29yZCByZXByZXNlbnRhdGlvbi4gSWYgeiBpcyBhbiBpbnRlZ2VyLCAwDQogICAg ICAgICAgPD0geiA8IDJeNjQsIHRoZW4geiA9IDJeMzJ4ICsgeSB3aGVyZSAwIDw9IHggPCAyXjMy IGFuZA0KICAgICAgICAgIDAgIDw9ICB5ICA8ICAyXjMyLiAgU2luY2UgeCBhbmQgeSBjYW4gYmUg cmVwcmVzZW50ZWQgYXMNCiAgICAgICAgICB3b3JkcyBYIGFuZCBZLCByZXNwZWN0aXZlbHksIHog Y2FuICBiZSAgcmVwcmVzZW50ZWQgIGFzDQogICAgICAgICAgdGhlIHBhaXIgb2Ygd29yZHMgKFgs WSkuDQoNCiAgICAgZC4gICBibG9jayA9IDUxMi1iaXQgc3RyaW5nLiBBIGJsb2NrICBtYXkgYmUg cmVwcmVzZW50ZWQgIGFzDQogICAgICAgICAgYSBzZXF1ZW5jZSBvZiAxNiB3b3Jkcy4NCg0KMy4g IE9QRVJBVElPTlMgT04gV09SRFMNCg0KICAgICBUaGUgZm9sbG93aW5nIGxvZ2ljYWwgb3BlcmF0 b3JzIHdpbGwgYmUgYXBwbGllZCB0byB3b3JkczoNCg0KICAgICBhLg0KICAgICAgICAgIFggQU5E IFkgICAgICAgICA9ICBiaXR3aXNlIGxvZ2ljYWwgImFuZCIgb2YgIFggYW5kIFkuDQoNCiAgICAg ICAgICBYIE9SIFkgID0gIGJpdHdpc2UgbG9naWNhbCAiaW5jbHVzaXZlLW9yIiBvZiBYIGFuZCBZ Lg0KDQogICAgICAgICAgWCBYT1IgWSA9ICBiaXR3aXNlIGxvZ2ljYWwgImV4Y2x1c2l2ZS1vciIg b2YgWCBhbmQgWS4NCg0KICAgICAgICAgIE5PVCAgWCAgICAgICAgICA9ICBiaXR3aXNlIGxvZ2lj YWwgImNvbXBsZW1lbnQiIG9mIFguDQoNCiAgICAgYi4gICBUaGUgb3BlcmF0aW9uIFggKyBZIGlz IGRlZmluZWQgYXMgZm9sbG93czogd29yZHMgWCAgYW5kDQogICAgICAgICAgWSByZXByZXNlbnQg aW50ZWdlcnMgeCBhbmQgeSwgd2hlcmUgMCA8PSB4IDwgMl4zMiBhbmQgMA0KICAgICAgICAgIDw9 IHkgPCAyXjMyLiBGb3IgcG9zaXRpdmUgaW50ZWdlcnMgbiBhbmQgbSwgbGV0IG4gbW9kIG0NCiAg ICAgICAgICBiZSB0aGUgcmVtYWluZGVyIHVwb24gZGl2aWRpbmcgbiBieSBtLiBDb21wdXRlIHog PSAoeCArDQogICAgICAgICAgeSkgbW9kIDJeMzIuDQoNCg0KDQoNCkJKUCAgICAgICAgPGRyYWZ0 LWlydGYtY2ZyZy1zaGExLWltZS0wMC50eHQ+ICAgICAgICAgIDQNCg0KDQoNCg0KDQpJbnRlcm5l dCBEcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOb3YgMjAw NQ0KDQoNCiAgICAgICAgICBUaGVuIDAgPD0geiA8IDJeMzIuIENvbnZlcnQgeiB0byBhIHdvcmQs IFosIGFuZCAgZGVmaW5lDQogICAgICAgICAgWiA9IFggKyBZLg0KDQogICAgIGMuICAgVGhlIGNp cmN1bGFyIGxlZnQgc2hpZnQgb3BlcmF0aW9uIFJPTG4oWCksICB3aGVyZSBYICBpcw0KICAgICAg ICAgIGEgd29yZCAgYW5kIG4gaXMgYW4gaW50ZWdlciB3aXRoIDAgPD0gbl4zMiwgaXMgZGVmaW5l ZA0KICAgICAgICAgIGJ5IFJPTG4oWCkgPSAoWCA8PCBuKSBPUiAoWCA+PiAzMi1uKS4gDQoJICBF LmcuIFJPTDIxKEEpID0gKEEgPDwgMjEpIE9SIChBID4+IDExKQ0KDQogICAgICAgICAgSW4gdGhl IGFib3ZlLCBYIDw8IG4gaXMgb2J0YWluZWQgIGFzICBmb2xsb3dzOiAgZGlzY2FyZA0KICAgICAg ICAgIHRoZSAgbGVmdC1tb3N0IG4gYml0cyBvZiBYIGFuZCB0aGVuIHBhZCB0aGUgcmVzdWx0IHdp dGgNCiAgICAgICAgICBuIHplcm9lcyBvbiB0aGUgcmlnaHQgKHRoZSAgcmVzdWx0ICB3aWxsICBz dGlsbCAgYmUgIDMyDQogICAgICAgICAgYml0cykuICBYID4+IG4gaXMgb2J0YWluZWQgYnkgZGlz Y2FyZGluZyB0aGUgcmlnaHQtbW9zdA0KICAgICAgICAgIG4gYml0cyBvZiBYIGFuZCB0aGVuIHBh ZGRpbmcgdGhlIHJlc3VsdCB3aXRoICBuICB6ZXJvZXMNCiAgICAgICAgICBvbiAgdGhlICBsZWZ0 LiBUaHVzIFJPTG4oWCkgaXMgZXF1aXZhbGVudCB0byBhIGNpcmN1bGFyDQogICAgICAgICAgc2hp ZnQgb2YgWCBieSBuIHBvc2l0aW9ucyB0byB0aGUgbGVmdC4NCg0KNC4gIE1FU1NBR0UgUEFERElO Rw0KDQogICAgIFRoZSBTSEExLUlNRSBpcyB1c2VkIHRvIGNvbXB1dGUgYSBtZXNzYWdlIGRpZ2Vz dCBmb3IgYSAgbWVzLQ0KICAgICBzYWdlICBvciBkYXRhIGZpbGUgdGhhdCBpcyBwcm92aWRlZCBh cyBpbnB1dC4gVGhlIG1lc3NhZ2Ugb3INCiAgICAgZGF0YSBmaWxlIHNob3VsZCBiZSBjb25zaWRl cmVkICB0byAgYmUgIGEgIGJpdCAgc3RyaW5nLiAgVGhlDQogICAgIGxlbmd0aCAgb2YgIHRoZSBt ZXNzYWdlIGlzIHRoZSBudW1iZXIgb2YgYml0cyBpbiB0aGUgbWVzc2FnZQ0KICAgICAodGhlIGVt cHR5IG1lc3NhZ2UgaGFzIGxlbmd0aCAwKS4gSWYgdGhlIG51bWJlciBvZiBiaXRzIGluIGENCiAg ICAgbWVzc2FnZSBpcyBhIG11bHRpcGxlIG9mIDgsIGZvciBjb21wYWN0bmVzcyB3ZSBjYW4gcmVw cmVzZW50DQogICAgIHRoZSBtZXNzYWdlIGluIGhleC4gVGhlIHB1cnBvc2Ugb2YgIG1lc3NhZ2Ug IHBhZGRpbmcgIGlzICB0bw0KICAgICBtYWtlIHRoZSB0b3RhbCBsZW5ndGggb2YgYSBwYWRkZWQg bWVzc2FnZSBhIG11bHRpcGxlIG9mIDUxMi4NCiAgICAgVGhlIFNIQTEtSU1FIHNlcXVlbnRpYWxs eSBwcm9jZXNzZXMgYmxvY2tzIG9mIDUxMiBiaXRzICB3aGVuDQogICAgIGNvbXB1dGluZyAgdGhl ICBtZXNzYWdlICBkaWdlc3QuIFRoZSBmb2xsb3dpbmcgc3BlY2lmaWVzIGhvdw0KICAgICB0aGlz IHBhZGRpbmcgc2hhbGwgYmUgcGVyZm9ybWVkLiBBcyBhIHN1bW1hcnksICBhICAiMSIgIGZvbC0N CiAgICAgbG93ZWQgYnkgbSAiMCJzIGZvbGxvd2VkIGJ5IGEgNjQtYml0IGludGVnZXIgYXJlIGFw cGVuZGVkIHRvDQogICAgIHRoZSBlbmQgb2YgdGhlIG1lc3NhZ2UgdG8gcHJvZHVjZSBhIHBhZGRl ZCBtZXNzYWdlIG9mIGxlbmd0aA0KICAgICA1MTIgKiBuLiBUaGUgNjQtYml0IGludGVnZXIgaXMg bCwgdGhlIGxlbmd0aCBvZiB0aGUgb3JpZ2luYWwNCiAgICAgbWVzc2FnZS4gVGhlIHBhZGRlZCBt ZXNzYWdlIGlzIHRoZW4gcHJvY2Vzc2VkIGJ5ICB0aGUgIFNIQTEtDQogICAgIElNRSBhcyBuIDUx Mi1iaXQgYmxvY2tzLg0KDQogICAgIFN1cHBvc2UgYSBtZXNzYWdlIGhhcyBsZW5ndGggbCA8IDJe NjQuIEJlZm9yZSBpdCBpcyBpbnB1dCB0bw0KICAgICB0aGUgU0hBMS1JTUUsIHRoZSBtZXNzYWdl IGlzIHBhZGRlZCBvbiB0aGUgcmlnaHQgYXMgZm9sbG93czoNCg0KICAgICBhLiAgICIxIiBpcyBh cHBlbmRlZC4gRXhhbXBsZTogaWYgdGhlICBvcmlnaW5hbCAgbWVzc2FnZSAgaXMNCiAgICAgICAg ICAiMDEwMTAwMDAiLCB0aGlzIGlzIHBhZGRlZCB0byAiMDEwMTAwMDAxIi4NCg0KICAgICBiLiAg ICIwInMgYXJlIGFwcGVuZGVkLiBUaGUgbnVtYmVyIG9mICIwInMgIHdpbGwgIGRlcGVuZCAgb24N CiAgICAgICAgICB0aGUgb3JpZ2luYWwgbGVuZ3RoIG9mIHRoZSBtZXNzYWdlLiBUaGUgbGFzdCA2 NCBiaXRzIG9mDQogICAgICAgICAgdGhlIGxhc3QgNTEyLWJpdCBibG9jayBhcmUgcmVzZXJ2ZWQg Zm9yIHRoZSBsZW5ndGggbCBvZg0KICAgICAgICAgIHRoZSAgb3JpZ2luYWwgIG1lc3NhZ2UuICBF eGFtcGxlOiAgU3VwcG9zZSB0aGUgb3JpZ2luYWwNCiAgICAgICAgICBtZXNzYWdlIGlzIHRoZSBi aXQgc3RyaW5nDQoNCiAgICAgICAgICAgICAgIDAxMTAwMDAxIDAxMTAwMDEwIDAxMTAwMDExIDAx MTAwMTAwIDAxMTAwMTAxLg0KDQoNCg0KQkpQICAgICAgICA8ZHJhZnQtaXJ0Zi1jZnJnLXNoYTEt aW1lLTAwLnR4dD4gICAgICAgICAgNQ0KDQoNCg0KDQoNCkludGVybmV0IERyYWZ0ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5vdiAyMDA1DQoNCg0KICAgICAgICAg IEFmdGVyIHN0ZXAgKGEpIHRoaXMgZ2l2ZXMNCg0KICAgICAgICAgICAgICAgMDExMDAwMDEgMDEx MDAwMTAgMDExMDAwMTEgMDExMDAxMDAgMDExMDAxMDEgMS4NCg0KICAgICAgICAgIFNpbmNlIGwg PSA0MCwgdGhlIG51bWJlciBvZiBiaXRzIGluIHRoZSBhYm92ZSBpcyA0MSBhbmQNCiAgICAgICAg ICA0MDcgICIwInMgIGFyZSBhcHBlbmRlZCwgbWFraW5nIHRoZSB0b3RhbCBub3cgNDQ4LiBUaGlz DQogICAgICAgICAgZ2l2ZXMgKGluIGhleCkNCiAgICAgICAgICAgICAgIDYxNjI2MzY0IDY1ODAw MDAwIDAwMDAwMDAwIDAwMDAwMDAwDQogICAgICAgICAgICAgICAwMDAwMDAwMCAwMDAwMDAwMCAw MDAwMDAwMCAwMDAwMDAwMA0KICAgICAgICAgICAgICAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAw MDAgMDAwMDAwMDANCiAgICAgICAgICAgICAgIDAwMDAwMDAwIDAwMDAwMDAwLg0KDQogICAgIGMu ICAgT2J0YWluIHRoZSAyLXdvcmQgcmVwcmVzZW50YXRpb24gb2YgbCwgIHRoZSAgbnVtYmVyICBv Zg0KICAgICAgICAgIGJpdHMgIGluICB0aGUgIG9yaWdpbmFsICBtZXNzYWdlLiAgSWYgbCA8IDJe MzIgdGhlbiB0aGUNCiAgICAgICAgICBmaXJzdCB3b3JkIGlzIGFsbCB6ZXJvZXMuIEFwcGVuZCB0 aGVzZSB0d28gd29yZHMgdG8gdGhlDQogICAgICAgICAgcGFkZGVkICBtZXNzYWdlLiAgRXhhbXBs ZTogU3VwcG9zZSB0aGUgb3JpZ2luYWwgbWVzc2FnZQ0KICAgICAgICAgIGlzIGFzIGluIChiKS4g VGhlbiBsID0gNDAgIChub3RlICB0aGF0ICBsICBpcyAgY29tcHV0ZWQNCiAgICAgICAgICBiZWZv cmUgIGFueSBwYWRkaW5nKS4gVGhlIHR3by13b3JkIHJlcHJlc2VudGF0aW9uIG9mIDQwDQogICAg ICAgICAgaXMgaGV4IDAwMDAwMDAwIDAwMDAwMDI4LiBIZW5jZSB0aGUgZmluYWwgIHBhZGRlZCAg bWVzLQ0KICAgICAgICAgIHNhZ2UgaXMgaGV4DQogICAgICAgICAgICAgICA2MTYyNjM2NCA2NTgw MDAwMCAwMDAwMDAwMCAwMDAwMDAwMA0KICAgICAgICAgICAgICAgMDAwMDAwMDAgMDAwMDAwMDAg MDAwMDAwMDAgMDAwMDAwMDANCiAgICAgICAgICAgICAgIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAw MDAwIDAwMDAwMDAwDQogICAgICAgICAgICAgICAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAw MDAwMDAyOC4NCg0KICAgICAgICAgIFRoZSBwYWRkZWQgbWVzc2FnZSB3aWxsIGNvbnRhaW4gMTYg KiBuIHdvcmRzIGZvciBzb21lIG4NCiAgICAgICAgICA+ICAwLiBUaGUgcGFkZGVkIG1lc3NhZ2Ug aXMgcmVnYXJkZWQgYXMgYSBzZXF1ZW5jZSBvZiBuDQogICAgICAgICAgYmxvY2tzIE0oMSkgLCBN KDIpLCAuLi4gLCBNKG4pLCB3aGVyZSAgZWFjaCAgTShpKSAgY29uLQ0KICAgICAgICAgIHRhaW5z ICAxNiAgd29yZHMgYW5kIE0oMSkgY29udGFpbnMgdGhlIGZpcnN0IGNoYXJhY3RlcnMNCiAgICAg ICAgICAob3IgYml0cykgb2YgdGhlIG1lc3NhZ2UuDQoNCg0KNS4NCg0KICAgICBBIHNlcXVlbmNl IG9mIGxvZ2ljYWwgZnVuY3Rpb25zIGZfMCwgZl8xLC4uLiwgZl97Nzl9IGlzIHVzZWQNCiAgICAg aW4gIHRoZSAgU0hBMS1JTUUuIEVhY2ggZl90LCAwIDw9IHQgPD0gNzksIG9wZXJhdGVzIG9uIHRo cmVlDQogICAgIDMyLWJpdCB3b3JkcyBCLCBDLCBEIGFuZCBwcm9kdWNlcyBhIDMyLWJpdCB3b3Jk ICBhcyAgb3V0cHV0Lg0KICAgICBmX3QoQixDLEQpIGlzIGRlZmluZWQgYXMgZm9sbG93czogZm9y IHdvcmRzIEIsIEMsIEQsDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkJKUCAgICAgICAgPGRy YWZ0LWlydGYtY2ZyZy1zaGExLWltZS0wMC50eHQ+ICAgICAgICAgIDYNCg0KDQoNCg0KDQpJbnRl cm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOb3Yg MjAwNQ0KDQoNCiAgICAgZl90KEIsQyxEKSA9IChCIEFORCBDKSBPUiAoKE5PVCBCKSBBTkQgRCkg KCAwIDw9IHQgPD0gMTkpDQoNCg0KICAgICBmX3QoQixDLEQpID0gQiBYT1IgQyBYT1IgRCAoMjAg PD0gdCA8PSAzOSkNCg0KDQogICAgIGZfdChCLEMsRCkgPSAoQiBBTkQgQykgT1IgKEIgQU5EIEQp IE9SIChDIEFORCBEKSAoNDAgPD0gdCA8PSA1OSkNCg0KDQogICAgIGZfdChCLEMsRCkgPSBCIFhP UiBDIFhPUiBEICg2MCA8PSB0IDw9IDc5KS4NCg0KNi4gIENPTlNUQU5UUyBVU0VEDQoNCiAgICAg QSBzZXF1ZW5jZSBvZiBjb25zdGFudCB3b3JkcyBLKDApLCBLKDEpLCAuLi4gLCBLKDc5KSBpcyB1 c2VkDQogICAgIGluIHRoZSBTSEExLUlNRS4gSW4gaGV4IHRoZXNlIGFyZSBnaXZlbiBieQ0KDQog ICAgICAgICAgSyh0KSA9IDVBODI3OTk5ICggMCA8PSB0IDw9IDE5KQ0KDQogICAgICAgICAgSyh0 KSA9IDZFRDlFQkExICgyMCA8PSB0IDw9IDM5KQ0KDQogICAgICAgICAgSyh0KSA9IDhGMUJCQ0RD ICg0MCA8PSB0IDw9IDU5KQ0KDQogICAgICAgICAgSyh0KSA9IENBNjJDMUQ2ICg2MCA8PSB0IDw9 IDc5KS4NCg0KNy4gIENPTVBVVElORyBUSEUgTUVTU0FHRSBESUdFU1QNCg0KICAgICBUaGUgbWVz c2FnZSBkaWdlc3QgaXMgY29tcHV0ZWQgdXNpbmcgdGhlIGZpbmFsICBwYWRkZWQgIG1lcy0NCiAg ICAgc2FnZS4gIFRoZSAgY29tcHV0YXRpb24gdXNlcyB0d28gYnVmZmVycywgZWFjaCBjb25zaXN0 aW5nIG9mDQogICAgIGZpdmUgMzItYml0IHdvcmRzLCBhbmQgYSBzZXF1ZW5jZSBvZiAgZWlnaHR5 ICAzMi1iaXQgIHdvcmRzLg0KICAgICBUaGUgIHdvcmRzIG9mIHRoZSBmaXJzdCA1LXdvcmQgYnVm ZmVyIGFyZSBsYWJlbGVkIEEsQixDLEQsRS4NCiAgICAgVGhlIHdvcmRzIG9mIHRoZSBzZWNvbmQg NS13b3JkIGJ1ZmZlciBhcmUgIGxhYmVsZWQgIEgwLCAgSDEsDQogICAgIEgyLCAgSDMsICBINC4g IFRoZSB3b3JkcyBvZiB0aGUgODAtd29yZCBzZXF1ZW5jZSBhcmUgbGFiZWxlZA0KICAgICBXKDAp LCBXKDEpLC4uLiwgVyg3OSkuIEEgc2luZ2xlIHdvcmQgIGJ1ZmZlciAgVEVNUCAgaXMgIGFsc28N CiAgICAgZW1wbG95ZWQuDQoNCiAgICAgVG8gZ2VuZXJhdGUgdGhlIG1lc3NhZ2UgZGlnZXN0LCAg dGhlICAxNi13b3JkICBibG9ja3MgIE0oMSksDQogICAgIE0oMiksLi4uLCAgTShuKSBkZWZpbmVk IGluIFNlY3Rpb24gNCBhcmUgcHJvY2Vzc2VkIGluIG9yZGVyLg0KICAgICBUaGUgcHJvY2Vzc2lu ZyBvZiBlYWNoIE0oaSkgaW52b2x2ZXMgODAgc3RlcHMuDQoNCiAgICAgQmVmb3JlIHByb2Nlc3Np bmcgYW55IGJsb2NrcywgdGhlIHtIaX0gIGFyZSAgaW5pdGlhbGl6ZWQgIGFzDQogICAgIGZvbGxv d3M6IGluIGhleCwNCg0KICAgICAgICAgIEgwID0gNjc0NTIzMDENCg0KICAgICAgICAgIEgxID0g RUZDREFCODkNCg0KICAgICAgICAgIEgyID0gOThCQURDRkUNCg0KDQoNCg0KQkpQICAgICAgICA8 ZHJhZnQtaXJ0Zi1jZnJnLXNoYTEtaW1lLTAwLnR4dD4gICAgICAgICAgNw0KDQoNCg0KDQoNCklu dGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5v diAyMDA1DQoNCg0KICAgICAgICAgIEgzID0gMTAzMjU0NzYNCg0KICAgICAgICAgIEg0ID0gQzNE MkUxRjAuDQoNCiAgICAgTm93IE0oMSksIE0oMiksIC4uLiAsIE0obikgYXJlIHByb2Nlc3NlZC4g VG8gIHByb2Nlc3MgIE0oaSksDQogICAgIHdlIHByb2NlZWQgYXMgZm9sbG93czoNCg0KICAgICBh LiAgIERpdmlkZSBNKGkpIGludG8gMTYgd29yZHMgIFcoMCksICBXKDEpLCAgLi4uICAsICBXKDE1 KSwNCiAgICAgICAgICB3aGVyZSBXKDApIGlzIHRoZSBsZWZ0LW1vc3Qgd29yZC4NCg0KICAgICBi LiAgIEZvciB0ID0gMTYgdG8gMzUgbGV0DQogICAgICAgICAgVyh0KSA9IChXKHQtMykgWE9SIFco dC04KSBYT1IgVyh0LSAxNCkgWE9SIFcodC0xNikpIFhPUg0KICAgICAgICAgICAgICAgICBST0wx MyhXKGktMSkgWE9SIFcoaS0yKSBYT1IgVyhpLTE1KSkuDQoNCiAgICAgICAgICBGb3IgdCA9IDM2 IHRvIDc5IGxldA0KICAgICAgICAgIFcodCkgPSAoVyh0LTMpIFhPUiBXKHQtOCkgWE9SIFcodC0g MTQpIFhPUiBXKHQtMTYpKSBYT1INCiAgICAgICAgICAgICAgICAgUk9MMTMoVyhpLTEpIFhPUiBX KGktMikgWE9SIFcoaS0xNSkgWE9SIFcoaS0yMCkpLg0KDQpjLiAgIExldCBBID0gSDAsIEIgPSBI MSwgQyA9IEgyLCBEID0gSDMsIEUgPSBINC4NCg0KZC4gICBGb3IgdCA9IDAgdG8gNzkgZG8NCiAg ICAgICAgICAgICBURU1QID0gUk9MNShBKSArIGZfdChCLEMsRCkgKyBFICsgVyh0KSArIEsodCk7 DQogICAgICAgICAgICAgRSA9IEQ7IEQgPSBDOyBDID0gUk9MMzAoQik7IEIgPSBBOyBBID0gVEVN UDsNCg0KZS4gICBMZXQgSDAgPSBIMCArIEEsIEgxID0gSDEgKyBCLCBIMiA9IEgyICsgQywgSDMg PSBIMyArIEQsIA0KICAgICAgICAgSDQgPSBINCArIEUuDQoNCiAgICAgQWZ0ZXIgcHJvY2Vzc2lu ZyBNKG4pLCB0aGUgbWVzc2FnZSAgZGlnZXN0ICBpcyAgdGhlICAxNjAtYml0DQogICAgIHN0cmlu ZyByZXByZXNlbnRlZCBieSB0aGUgNSB3b3JkcyBIMCBIMSBIMiBIMyBINC4NCg0KOC4gIEludGVs bGVjdHVhbCBQcm9wZXJ0eSBJc3N1ZXMNCg0KICAgICBUaGVyZSBpcyBubyBpbnRlbGxlY3R1YWwg cHJvcGVydHkgZmlsZWQgb24gU0hBMS1JTUUuDQoNCjkuICBURVNUIFZFQ1RPUlMNCg0KQS4gICBM ZXQgdGhlIG1lc3NhZ2UgYmUgdGhlIEFTQ0lJICBiaW5hcnktY29kZWQgIGZvcm0gIG9mICAiYWJj IiwNCiAgICAgaS5lLiwNCiAgICAgICAgICAwMTEwMDAwMSAwMTEwMDAxMCAwMTEwMDAxMQ0KICAg ICBUaGUgTWVzc2FnZSBEaWdlc3QgdXNpbmcgIHRoZSBhYm92ZSAgU0hBMS1JTUUgIHNwZWNpZmlj YXRpb24NCiAgICAgaXMNCiAgICAgICAgICAzZWFlMTkxZSA1NTVjM2Q0YyAzMTRiZmNkNyAwOTg3 NWI2ZSA1MTgwMDNmNQ0KDQpCLiAgIExldCB0aGUgbWVzc2FnZSBiZSB0aGUgYmluYXJ5IGNvZGVk IGZvcm0gb2YgdGhlIEFTQ0lJIHN0cmluZw0KICAgICAiYWJjZGJjZGVjZGVmZGVmZ2VmZ2hmZ2hp Z2hpamhpamtpamtsamtsbWtsbW5sbW5vbW5vcG5vcHEiLg0KICAgICBUaGUgTWVzc2FnZSBEaWdl c3QgaXMNCiAgICAgICAgICBlNGIwZWNlNyAwNTJlNjVlZCA2ZjUyYjY2YiBiMjNkOWYzZCAxZGNj MTc3YQ0KDQpDLiAgIExldCB0aGUgbWVzc2FnZSBiZSB0aGUgYmluYXJ5IGNvZGVkIGZvcm0gb2Yg dGhlIEFTQ0lJIHN0cmluZw0KDQoNCkJKUCAgICAgICAgPGRyYWZ0LWlydGYtY2ZyZy1zaGExLWlt ZS0wMC50eHQ+ICAgICAgICAgIDgNCg0KDQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOb3YgMjAwNQ0KDQoNCiAgICAgd2hpY2gg Y29uc2lzdHMgb2YgMSwwMDAsMDAwIHJlcGV0aXRpb25zIG9mICJhIi4NCiAgICAgVGhlIE1lc3Nh Z2UgZGlnZXN0IGlzDQogICAgICAgICAgM2MwMDYyNTggMzQwZGIxMGIgYTM2ODI3NzAgYTRjYjZm MzAgZWZiYzI2NWMNCg0KMTAuICBBY2tub3dsZWRnbWVudHMNCg0KICAgICBUaGUgYXV0aG9ycyB3 b3VsZCBsaWtlIHRvIHRoYW5rICBQYW5rYWogUm9oYXRnaSwgQXJqZW4gTGVucy0NCiAgICAgdHJh LCBSb24gUml2ZXN0LCBhbmQgSHVnbyBLcmF3Y3p5ayBmb3IgaGVscGZ1bCBjb21tZW50cy4gDQog ICAgIFNvdXJjZSBjb2RlIG9mIFNIQTEgcHJvdmlkZWQgYnkgRC4gRWFzdGxha2UgW0RFXSB3YXMg bW9kaWZpZWQNCiAgICAgdG8gcHJvdmlkZSB0aGlzIHJlZmVyZW5jZSBjb2RlLg0KDQoxMS4gIFJl ZmVyZW5jZXMNCg0KW1NIQTFdIEZJUFMgUFVCIDE4MC0xLCAiU2VjdXJlIEhhc2ggU3RhbmRhcmQi LCBNYXkgMTk5My4NCg0KW1NIQTJdIEZJUFMgUFVCIDE4MC0yLCAiU2VjdXJlIEhhc2ggU3RhbmRh cmQiLCBBdWcgMjAwMi4NCg0KW0pQMV0gQy4gUy4gSnV0bGEsIEEuIEMuIFBhdHRoYWssICJBICBT aW1wbGUgIGFuZCAgUHJvdmFibHkgIEdvb2QNCiAgICAgQ29kZSAgIGZvciAgU0hBICBNZXNzYWdl ICBFeHBhbnNpb24iLCAgSUFDUiAgZXByaW50ICBhcmNoaXZlDQogICAgIDIwMDUvMjQ3LCBKdWx5 IDIwMDUuDQoNCltKUDJdIEMuIFMuIEp1dGxhLCBBLiBDLiBQYXR0aGFrLCAiSXMgU0hBLTEgQ29u Y2VwdHVhbGx5IFNvdW5kPyIsDQogICAgIElBQ1IgZXByaW50IGFyY2hpdmUgMjAwNS8zNTAsIE9j dCAyMDA1Lg0KDQpbV1lZXSBYLiBXYW5nLCBILiBZdSwgWS5MLiBZaW4sICJGaW5kaW5nIENvbGxp c2lvbnMgaW4gIHRoZSAgZnVsbA0KICAgICBTSEEtMSIsIFByb2MuIENyeXB0byAyMDA1Lg0KDQpb REVdIEQuIEVhc3RsYWtlLCAzcmQsIFAuIEpvbmVzLCAgIlVTIFNlY3VyZSBIYXNoIEFsZ29yaXRo bSAxIChTSEExKSIsDQogICAgIFJGQyAzMTc0LCBTZXB0ZW1iZXIgMjAwMS4NCg0KMTIuICBBdXRo b3IncyBBZGRyZXNzDQoNCiAgICAgICAgICAgICBVcmkgQmx1bWVudGhhbA0KICAgICAgICAgICAg IEludGVsIENvcnBvcmF0aW9uDQogICAgICAgICAgICAgMTUxNSBTdGF0ZSBSb3V0ZSAxMCwNCiAg ICAgICAgICAgICAzUFkxLTMuNTM2DQogICAgICAgICAgICAgUGFyc2lwcGFueSwgTkogIDA3MDU0 DQogICAgICAgICAgICAgVVNBDQogICAgICAgICAgICAgUGhvbmU6ICsxLjk3My45NjcuNjQ0Ng0K ICAgICAgICAgICAgIEVtYWlsOiB1cmkgRE9UIGJsdW1lbnRoYWwgQVQgaW50ZWwgRE9UIGNvbQ0K DQogICAgICAgICAgICAgQ2hhcmFuaml0IFMuIEp1dGxhDQogICAgICAgICAgICAgSUJNIFQuSi4g V2F0c29uIFJlc2VhcmNoIENlbnRlciwNCiAgICAgICAgICAgICBZb3JrdG93biBIZWlnaHRzLCBO WSAxMDU5OC03MDQuDQogICAgICAgICAgICAgUGhvbmU6IDkxNC03ODQtNzg5MA0KICAgICAgICAg ICAgIEVtYWlsOiBjc2p1dGxhIEFUIHVzIERPVCBpYm0gRE9UIGNvbQ0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCkJKUCAgICAgICAgPGRyYWZ0LWlydGYtY2ZyZy1zaGExLWltZS0wMC50eHQ+ICAgICAg ICAgIDkNCg0KDQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBOb3YgMjAwNQ0KDQoNCiAgICAgICAgICAgICBBbmluZHlhIFBhdHRo YWsNCiAgICAgICAgICAgICBEZXBhcnRtZW50IG9mIENvbXB1dGVyIFNjaWVuY2UsDQogICAgICAg ICAgICAgVGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgYXQgQXVzdGluLA0KICAgICAgICAgICAgIDEg VW5pdmVyc2l0eSBTdGF0aW9uIEMwNTAwDQogICAgICAgICAgICAgQXVzdGluLCBUWCA3ODcxMg0K ICAgICAgICAgICAgIFBob25lOiAoNTEyKSA0NzEtOTU3Mi4NCiAgICAgICAgICAgICBFbWFpbDog YW5pbmR5YSBBVCBjcyBET1QgdXRleGFzIERPVCBlZHUNCg0KICAgICBDb21tZW50cyBzaG91bGQg YmUgc2VudCB0byBDLiBTLiBKdXRsYSBhdCBoaXMNCiAgICAgZS1tYWlsIGFkZHJlc3MgYWJvdmUu DQoNCjEzLiBDT1BZUklHSFQgTk9USUNFDQoNCiAgICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJu ZXQgU29jaWV0eSAoMjAwNSkuDQoNCiAgICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIHRo ZSByaWdodHMsICBsaWNlbnNlcyAgYW5kICByZXMtDQogICAgIHRyaWN0aW9ucyAgY29udGFpbmVk ICBpbiAgQkNQICA3OCwgIGFuZCAgZXhjZXB0IGFzIHNldCBmb3J0aA0KICAgICB0aGVyZWluLCB0 aGUgYXV0aG9ycyByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy4NCg0KICAgICBUaGlzIGRvY3VtZW50 IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgIHByby0NCiAgICAgdmlk ZWQgb24gYW4gIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkEt DQogICAgIFRJT04gSEUvU0hFIFJFUFJFU0VOVFMgT1IgSVMgIFNQT05TT1JFRCAgQlkgIChJRiAg QU5ZKSwgIFRIRQ0KICAgICBJTlRFUk5FVCAgU09DSUVUWSAgQU5EICBUSEUgIElOVEVSTkVUIEVO R0lORUVSSU5HIFRBU0sgRk9SQ0UNCiAgICAgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJF U1MgT1IgSU1QTElFRCwgIElOQ0xVRElORyAgQlVUDQogICAgIE5PVCAgTElNSVRFRCBUTyBBTlkg V0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRSBJTkZPUk1BVElPTg0KICAgICBIRVJFSU4gV0lM TCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgIElNUExJRUQgIFdBUlJBTi0NCiAgICAg VElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBP U0UuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpCSlAg ICAgICAgIDxkcmFmdC1pcnRmLWNmcmctc2hhMS1pbWUtMDAudHh0PiAgICAgICAgIDEwDQoNCg0K DQpBcHBlbmRpeCBBLiBzaGExaW1lLmgNCg0KLyoNCiAqICBzaGExaW1lLmgNCiAqDQogKiAgRGVz Y3JpcHRpb246DQogKiAgICAgIFRoaXMgaXMgdGhlIGhlYWRlciBmaWxlIGZvciBjb2RlIHdoaWNo IGltcGxlbWVudHMgdGhlIElNRQ0KICogICAgICBtb2RpZmljYXRpb24gb2YgU2VjdXJlIEhhc2hp bmcgQWxnb3JpdGhtIDEgYXMgZGVmaW5lZCBpbiANCiAqICAgICAgRklQUyBQVUIgMTgwLTEgYW5k IDE4MC0yLiANCiAqDQogKiAgICAgIFBsZWFzZSByZWFkIHRoZSBmaWxlIHNoYTFpbWUuYyBmb3Ig bW9yZSBpbmZvcm1hdGlvbi4NCiAqDQogKi8NCg0KI2lmbmRlZiBfU0hBMUlNRV9IXw0KI2RlZmlu ZSBfU0hBMUlNRV9IXw0KDQojaW5jbHVkZSA8c3RkaW50Lmg+DQovKg0KICogSWYgeW91IGRvIG5v dCBoYXZlIHRoZSBJU08gc3RhbmRhcmQgc3RkaW50LmggaGVhZGVyIGZpbGUsIHRoZW4geW91DQog KiBtdXN0IHR5cGRlZiB0aGUgZm9sbG93aW5nOg0KICogICAgbmFtZSAgICAgICAgICAgICAgbWVh bmluZw0KICogIHVpbnQzMl90ICAgICAgICAgdW5zaWduZWQgMzIgYml0IGludGVnZXINCiAqICB1 aW50OF90ICAgICAgICAgIHVuc2lnbmVkIDggYml0IGludGVnZXIgKGkuZS4sIHVuc2lnbmVkIGNo YXIpDQogKiAgaW50X2xlYXN0MTZfdCAgICBpbnRlZ2VyIG9mID49IDE2IGJpdHMNCiAqDQogKi8N Cg0KI2lmbmRlZiBfU0hBX2VudW1fDQojZGVmaW5lIF9TSEFfZW51bV8NCmVudW0NCnsNCiAgICBz aGFTdWNjZXNzID0gMCwNCiAgICBzaGFOdWxsLCAgICAgICAgICAgIC8qIE51bGwgcG9pbnRlciBw YXJhbWV0ZXIgKi8NCiAgICBzaGFJbnB1dFRvb0xvbmcsICAgIC8qIGlucHV0IGRhdGEgdG9vIGxv bmcgKi8NCiAgICBzaGFTdGF0ZUVycm9yICAgICAgIC8qIGNhbGxlZCBJbnB1dCBhZnRlciBSZXN1 bHQgKi8NCn07DQojZW5kaWYNCiNkZWZpbmUgU0hBMUlNRUhhc2hTaXplIDIwDQoNCi8qDQogKiAg VGhpcyBzdHJ1Y3R1cmUgd2lsbCBob2xkIGNvbnRleHQgaW5mb3JtYXRpb24gZm9yIHRoZSBTSEEt MQ0KICogIGhhc2hpbmcgb3BlcmF0aW9uDQogKi8NCnR5cGVkZWYgc3RydWN0IFNIQTFJTUVDb250 ZXh0DQp7DQogICAgdWludDMyX3QgSW50ZXJtZWRpYXRlX0hhc2hbU0hBMUlNRUhhc2hTaXplLzRd OyAvKiBNZXNzYWdlIERpZ2VzdCAgKi8NCg0KICAgIHVpbnQzMl90IExlbmd0aF9Mb3c7ICAgICAg ICAgICAgLyogTWVzc2FnZSBsZW5ndGggaW4gYml0cyAgICAgICovDQogICAgdWludDMyX3QgTGVu Z3RoX0hpZ2g7ICAgICAgICAgICAvKiBNZXNzYWdlIGxlbmd0aCBpbiBiaXRzICAgICAgKi8NCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8qIEluZGV4IGludG8gbWVzc2FnZSBibG9j ayBhcnJheSAgICovDQogICAgaW50X2xlYXN0MTZfdCBNZXNzYWdlX0Jsb2NrX0luZGV4Ow0KICAg IHVpbnQ4X3QgTWVzc2FnZV9CbG9ja1s2NF07ICAgICAgLyogNTEyLWJpdCBtZXNzYWdlIGJsb2Nr cyAgICAgICovDQoNCiAgICBpbnQgQ29tcHV0ZWQ7ICAgICAgICAgICAgICAgLyogSXMgdGhlIGRp Z2VzdCBjb21wdXRlZD8gICAgICAgICAqLw0KICAgIGludCBDb3JydXB0ZWQ7ICAgICAgICAgICAg IC8qIElzIHRoZSBtZXNzYWdlIGRpZ2VzdCBjb3JydXB0ZWQ/ICovDQp9IFNIQTFJTUVDb250ZXh0 Ow0KDQovKg0KICogIEZ1bmN0aW9uIFByb3RvdHlwZXMNCiAqLw0KDQppbnQgU0hBMUlNRVJlc2V0 KCAgU0hBMUlNRUNvbnRleHQgKik7DQppbnQgU0hBMUlNRUlucHV0KCAgU0hBMUlNRUNvbnRleHQg KiwNCiAgICAgICAgICAgICAgICBjb25zdCB1aW50OF90ICosDQogICAgICAgICAgICAgICAgdW5z aWduZWQgaW50KTsNCmludCBTSEExSU1FUmVzdWx0KCBTSEExSU1FQ29udGV4dCAqLA0KICAgICAg ICAgICAgICAgIHVpbnQ4X3QgTWVzc2FnZV9EaWdlc3RbU0hBMUlNRUhhc2hTaXplXSk7DQoNCiNl bmRpZg0KDQoNCkFwcGVuZGl4IEIuIHNoYTFpbWUuYw0KDQovKg0KICogIHNoYTFpbWUuYw0KICoN CiAqICBEZXNjcmlwdGlvbjoNCiAqICAgICAgVGhpcyBmaWxlIGltcGxlbWVudHMgdGhlIElNRSBt b2RpZmljYXRpb24gdG8gU2VjdXJlIEhhc2hpbmcNCiAqICAgICAgQWxnb3JpdGhtIDEgYXMgZGVm aW5lZCBpbiBGSVBTIFBVQiAxODAtMSBhbmQgMTgwLTIuDQogKg0KICogICAgICBUaGUgU0hBMS1J TUUsIHByb2R1Y2VzIGEgMTYwLWJpdCBtZXNzYWdlIGRpZ2VzdCBmb3IgYSBnaXZlbg0KICogICAg ICBkYXRhIHN0cmVhbS4gIEl0IHNob3VsZCB0YWtlIGFib3V0IDIqKm4gc3RlcHMgdG8gZmluZCBh DQogKiAgICAgIG1lc3NhZ2Ugd2l0aCB0aGUgc2FtZSBkaWdlc3QgYXMgYSBnaXZlbiBtZXNzYWdl IGFuZA0KICogICAgICAyKioobi8yKSB0byBmaW5kIGFueSB0d28gbWVzc2FnZXMgd2l0aCB0aGUg c2FtZSBkaWdlc3QsDQogKiAgICAgIHdoZW4gbiBpcyB0aGUgZGlnZXN0IHNpemUgaW4gYml0cy4g IFRoZXJlZm9yZSwgdGhpcw0KICogICAgICBhbGdvcml0aG0gY2FuIHNlcnZlIGFzIGEgbWVhbnMg b2YgcHJvdmlkaW5nIGENCiAqICAgICAgImZpbmdlcnByaW50IiBmb3IgYSBtZXNzYWdlLg0KICoN CiAqICBQb3J0YWJpbGl0eSBJc3N1ZXM6DQogKiAgICAgIFNIQTEtSU1FIGlzIGRlZmluZWQgaW4g dGVybXMgb2YgMzItYml0ICJ3b3JkcyIuICBUaGlzIGNvZGUNCiAqICAgICAgdXNlcyA8c3RkaW50 Lmg+IChpbmNsdWRlZCB2aWEgInNoYTEuaCIgdG8gZGVmaW5lIDMyIGFuZCA4DQogKiAgICAgIGJp dCB1bnNpZ25lZCBpbnRlZ2VyIHR5cGVzLiAgSWYgeW91ciBDIGNvbXBpbGVyIGRvZXMgbm90DQog KiAgICAgIHN1cHBvcnQgMzIgYml0IHVuc2lnbmVkIGludGVnZXJzLCB0aGlzIGNvZGUgaXMgbm90 DQogKiAgICAgIGFwcHJvcHJpYXRlLg0KICoNCiAqICBDYXZlYXRzOg0KICogICAgICBTSEExLUlN RSBsaWtlIFNIQS0xLCBpcyBkZXNpZ25lZCB0byB3b3JrIHdpdGggbWVzc2FnZXMgbGVzcw0KICog ICAgICB0aGFuIDJeNjQgYml0cyBsb25nLiAgQWx0aG91Z2ggU0hBMS1JTUUgYWxsb3dzIGEgbWVz c2FnZSBkaWdlc3QNCiAqICAgICAgdG8gYmUgZ2VuZXJhdGVkIGZvciBtZXNzYWdlcyBvZiBhbnkg bnVtYmVyIG9mIGJpdHMgbGVzcyB0aGFuIDJeNjQsDQogKiAgICAgIHRoaXMgaW1wbGVtZW50YXRp b24gb25seSB3b3JrcyB3aXRoIG1lc3NhZ2VzIHdpdGggYSBsZW5ndGggdGhhdCBpcw0KICogICAg ICBhIG11bHRpcGxlIG9mIHRoZSBzaXplIG9mIGFuIDgtYml0IGNoYXJhY3Rlci4NCiAqDQogKi8N Cg0KI2luY2x1ZGUgInNoYTFpbWUuaCINCg0KLyoNCiAqICBEZWZpbmUgdGhlIFNIQTEtSU1FIGNp cmN1bGFyIGxlZnQgc2hpZnQgbWFjcm8NCiAqLw0KI2RlZmluZSBTSEExSU1FQ2lyY3VsYXJTaGlm dChiaXRzLHdvcmQpIFwNCiAgICAgICAgICAgICAgICAoKCh3b3JkKSA8PCAoYml0cykpIHwgKCh3 b3JkKSA+PiAoMzItKGJpdHMpKSkpDQoNCi8qIExvY2FsIEZ1bmN0aW9uIFByb3RvdHlwdGVzICov DQp2b2lkIFNIQTFJTUVQYWRNZXNzYWdlKFNIQTFJTUVDb250ZXh0ICopOw0Kdm9pZCBTSEExSU1F UHJvY2Vzc01lc3NhZ2VCbG9jayhTSEExSU1FQ29udGV4dCAqKTsNCg0KLyoNCiAqICBTSEExSU1F UmVzZXQNCiAqDQogKiAgRGVzY3JpcHRpb246DQogKiAgICAgIFRoaXMgZnVuY3Rpb24gd2lsbCBp bml0aWFsaXplIHRoZSBTSEExSU1FQ29udGV4dCBpbg0KICoJcHJlcGFyYXRpb24gZm9yIGNvbXB1 dGluZyBhIG5ldyBTSEExLUlNRSBtZXNzYWdlIGRpZ2VzdC4NCiAqDQogKiAgUGFyYW1ldGVyczoN CiAqICAgICAgY29udGV4dDogW2luL291dF0NCiAqICAgICAgICAgIFRoZSBjb250ZXh0IHRvIHJl c2V0Lg0KICoNCiAqICBSZXR1cm5zOg0KICogICAgICBzaGEgRXJyb3IgQ29kZS4NCiAqDQogKi8N CmludCBTSEExSU1FUmVzZXQoU0hBMUlNRUNvbnRleHQgKmNvbnRleHQpDQp7DQogICAgaWYgKCFj b250ZXh0KQ0KICAgIHsNCiAgICAgICAgcmV0dXJuIHNoYU51bGw7DQogICAgfQ0KDQogICAgY29u dGV4dC0+TGVuZ3RoX0xvdyAgICAgICAgICAgICA9IDA7DQogICAgY29udGV4dC0+TGVuZ3RoX0hp Z2ggICAgICAgICAgICA9IDA7DQogICAgY29udGV4dC0+TWVzc2FnZV9CbG9ja19JbmRleCAgICA9 IDA7DQoNCiAgICBjb250ZXh0LT5JbnRlcm1lZGlhdGVfSGFzaFswXSAgID0gMHg2NzQ1MjMwMTsN CiAgICBjb250ZXh0LT5JbnRlcm1lZGlhdGVfSGFzaFsxXSAgID0gMHhFRkNEQUI4OTsNCiAgICBj b250ZXh0LT5JbnRlcm1lZGlhdGVfSGFzaFsyXSAgID0gMHg5OEJBRENGRTsNCiAgICBjb250ZXh0 LT5JbnRlcm1lZGlhdGVfSGFzaFszXSAgID0gMHgxMDMyNTQ3NjsNCiAgICBjb250ZXh0LT5JbnRl cm1lZGlhdGVfSGFzaFs0XSAgID0gMHhDM0QyRTFGMDsNCg0KICAgIGNvbnRleHQtPkNvbXB1dGVk ICAgPSAwOw0KICAgIGNvbnRleHQtPkNvcnJ1cHRlZCAgPSAwOw0KDQogICAgcmV0dXJuIHNoYVN1 Y2Nlc3M7DQp9DQoNCi8qDQogKiAgU0hBMUlNRVJlc3VsdA0KICoNCiAqICBEZXNjcmlwdGlvbjoN CiAqICAgICAgVGhpcyBmdW5jdGlvbiB3aWxsIHJldHVybiB0aGUgMTYwLWJpdCBtZXNzYWdlIGRp Z2VzdCBpbnRvIHRoZQ0KICogICAgICBNZXNzYWdlX0RpZ2VzdCBhcnJheSAgcHJvdmlkZWQgYnkg dGhlIGNhbGxlci4NCiAqICAgICAgTk9URTogVGhlIGZpcnN0IG9jdGV0IG9mIGhhc2ggaXMgc3Rv cmVkIGluIHRoZSAwdGggZWxlbWVudCwNCiAqICAgICAgICAgICAgdGhlIGxhc3Qgb2N0ZXQgb2Yg aGFzaCBpbiB0aGUgMTl0aCBlbGVtZW50Lg0KICoNCiAqICBQYXJhbWV0ZXJzOg0KICogICAgICBj b250ZXh0OiBbaW4vb3V0XQ0KICogICAgICAgICAgVGhlIGNvbnRleHQgdG8gdXNlIHRvIGNhbGN1 bGF0ZSB0aGUgU0hBLTEgaGFzaC4NCiAqICAgICAgTWVzc2FnZV9EaWdlc3Q6IFtvdXRdDQogKiAg ICAgICAgICBXaGVyZSB0aGUgZGlnZXN0IGlzIHJldHVybmVkLg0KICoNCiAqICBSZXR1cm5zOg0K ICogICAgICBzaGEgRXJyb3IgQ29kZS4NCiAqDQogKi8NCmludCBTSEExSU1FUmVzdWx0KCBTSEEx SU1FQ29udGV4dCAqY29udGV4dCwNCiAgICAgICAgICAgICAgICAgICB1aW50OF90IE1lc3NhZ2Vf RGlnZXN0W1NIQTFJTUVIYXNoU2l6ZV0pDQp7DQogICAgaW50IGk7DQoNCiAgICBpZiAoIWNvbnRl eHQgfHwgIU1lc3NhZ2VfRGlnZXN0KQ0KICAgIHsNCiAgICAgICAgcmV0dXJuIHNoYU51bGw7DQog ICAgfQ0KDQogICAgaWYgKGNvbnRleHQtPkNvcnJ1cHRlZCkNCiAgICB7DQogICAgICAgIHJldHVy biBjb250ZXh0LT5Db3JydXB0ZWQ7DQogICAgfQ0KDQogICAgaWYgKCFjb250ZXh0LT5Db21wdXRl ZCkNCiAgICB7DQogICAgICAgIFNIQTFJTUVQYWRNZXNzYWdlKGNvbnRleHQpOw0KICAgICAgICBm b3IoaT0wOyBpPDY0OyArK2kpDQogICAgICAgIHsNCiAgICAgICAgICAgIC8qIG1lc3NhZ2UgbWF5 IGJlIHNlbnNpdGl2ZSwgY2xlYXIgaXQgb3V0ICovDQogICAgICAgICAgICBjb250ZXh0LT5NZXNz YWdlX0Jsb2NrW2ldID0gMDsNCiAgICAgICAgfQ0KICAgICAgICBjb250ZXh0LT5MZW5ndGhfTG93 ID0gMDsgICAgLyogYW5kIGNsZWFyIGxlbmd0aCAqLw0KICAgICAgICBjb250ZXh0LT5MZW5ndGhf SGlnaCA9IDA7DQogICAgICAgIGNvbnRleHQtPkNvbXB1dGVkID0gMTsNCg0KICAgIH0NCg0KICAg IGZvcihpID0gMDsgaSA8IFNIQTFJTUVIYXNoU2l6ZTsgKytpKQ0KICAgIHsNCiAgICAgICAgTWVz c2FnZV9EaWdlc3RbaV0gPSBjb250ZXh0LT5JbnRlcm1lZGlhdGVfSGFzaFtpPj4yXQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgID4+IDggKiAoIDMgLSAoIGkgJiAweDAzICkgKTsNCiAgICB9 DQoNCiAgICByZXR1cm4gc2hhU3VjY2VzczsNCn0NCg0KLyoNCiAqICBTSEExSU1FSW5wdXQNCiAq DQogKiAgRGVzY3JpcHRpb246DQogKiAgICAgIFRoaXMgZnVuY3Rpb24gYWNjZXB0cyBhbiBhcnJh eSBvZiBvY3RldHMgYXMgdGhlIG5leHQgcG9ydGlvbg0KICogICAgICBvZiB0aGUgbWVzc2FnZS4N CiAqDQogKiAgUGFyYW1ldGVyczoNCiAqICAgICAgY29udGV4dDogW2luL291dF0NCiAqICAgICAg ICAgIFRoZSBTSEExLUlNRSBjb250ZXh0IHRvIHVwZGF0ZQ0KICogICAgICBtZXNzYWdlX2FycmF5 OiBbaW5dDQogKiAgICAgICAgICBBbiBhcnJheSBvZiBjaGFyYWN0ZXJzIHJlcHJlc2VudGluZyB0 aGUgbmV4dCBwb3J0aW9uIG9mDQogKiAgICAgICAgICB0aGUgbWVzc2FnZS4NCiAqICAgICAgbGVu Z3RoOiBbaW5dDQogKiAgICAgICAgICBUaGUgbGVuZ3RoIG9mIHRoZSBtZXNzYWdlIGluIG1lc3Nh Z2VfYXJyYXkNCiAqDQogKiAgUmV0dXJuczoNCiAqICAgICAgc2hhIEVycm9yIENvZGUuDQogKg0K ICovDQppbnQgU0hBMUlNRUlucHV0KCAgICBTSEExSU1FQ29udGV4dCAgICAqY29udGV4dCwNCiAg ICAgICAgICAgICAgICAgICAgIGNvbnN0IHVpbnQ4X3QgICAgICptZXNzYWdlX2FycmF5LA0KICAg ICAgICAgICAgICAgICAgICAgdW5zaWduZWQgICAgICAgICAgbGVuZ3RoKQ0Kew0KICAgIGlmICgh bGVuZ3RoKQ0KICAgIHsNCiAgICAgICAgcmV0dXJuIHNoYVN1Y2Nlc3M7DQogICAgfQ0KDQogICAg aWYgKCFjb250ZXh0IHx8ICFtZXNzYWdlX2FycmF5KQ0KICAgIHsNCiAgICAgICAgcmV0dXJuIHNo YU51bGw7DQogICAgfQ0KDQogICAgaWYgKGNvbnRleHQtPkNvbXB1dGVkKQ0KICAgIHsNCiAgICAg ICAgY29udGV4dC0+Q29ycnVwdGVkID0gc2hhU3RhdGVFcnJvcjsNCg0KICAgICAgICByZXR1cm4g c2hhU3RhdGVFcnJvcjsNCiAgICB9DQoNCiAgICBpZiAoY29udGV4dC0+Q29ycnVwdGVkKQ0KICAg IHsNCiAgICAgICAgIHJldHVybiBjb250ZXh0LT5Db3JydXB0ZWQ7DQogICAgfQ0KICAgIHdoaWxl KGxlbmd0aC0tICYmICFjb250ZXh0LT5Db3JydXB0ZWQpDQogICAgew0KICAgIGNvbnRleHQtPk1l c3NhZ2VfQmxvY2tbY29udGV4dC0+TWVzc2FnZV9CbG9ja19JbmRleCsrXSA9DQogICAgICAgICAg ICAgICAgICAgICgqbWVzc2FnZV9hcnJheSAmIDB4RkYpOw0KDQogICAgY29udGV4dC0+TGVuZ3Ro X0xvdyArPSA4Ow0KICAgIGlmIChjb250ZXh0LT5MZW5ndGhfTG93ID09IDApDQogICAgew0KICAg ICAgICBjb250ZXh0LT5MZW5ndGhfSGlnaCsrOw0KICAgICAgICBpZiAoY29udGV4dC0+TGVuZ3Ro X0hpZ2ggPT0gMCkNCiAgICAgICAgew0KICAgICAgICAgICAgLyogTWVzc2FnZSBpcyB0b28gbG9u ZyAqLw0KICAgICAgICAgICAgY29udGV4dC0+Q29ycnVwdGVkID0gMTsNCiAgICAgICAgfQ0KICAg IH0NCg0KICAgIGlmIChjb250ZXh0LT5NZXNzYWdlX0Jsb2NrX0luZGV4ID09IDY0KQ0KICAgIHsN CiAgICAgICAgU0hBMUlNRVByb2Nlc3NNZXNzYWdlQmxvY2soY29udGV4dCk7DQogICAgfQ0KDQog ICAgbWVzc2FnZV9hcnJheSsrOw0KICAgIH0NCg0KICAgIHJldHVybiBzaGFTdWNjZXNzOw0KfQ0K DQovKg0KICogIFNIQTFJTUVQcm9jZXNzTWVzc2FnZUJsb2NrDQogKg0KICogIERlc2NyaXB0aW9u Og0KICogICAgICBUaGlzIGZ1bmN0aW9uIHdpbGwgcHJvY2VzcyB0aGUgbmV4dCA1MTIgYml0cyBv ZiB0aGUgbWVzc2FnZQ0KICogICAgICBzdG9yZWQgaW4gdGhlIE1lc3NhZ2VfQmxvY2sgYXJyYXku DQogKg0KICogIFBhcmFtZXRlcnM6DQogKiAgICAgIE5vbmUuDQogKg0KICogIFJldHVybnM6DQog KiAgICAgIE5vdGhpbmcuDQogKg0KICogIENvbW1lbnRzOg0KDQogKiAgICAgIE1hbnkgb2YgdGhl IHZhcmlhYmxlIG5hbWVzIGluIHRoaXMgY29kZSwgZXNwZWNpYWxseSB0aGUNCiAqICAgICAgc2lu Z2xlIGNoYXJhY3RlciBuYW1lcywgd2VyZSB1c2VkIGJlY2F1c2UgdGhvc2Ugd2VyZSB0aGUNCiAq ICAgICAgbmFtZXMgdXNlZCBpbiB0aGUgcHVibGljYXRpb24uDQogKg0KICoNCiAqLw0Kdm9pZCBT SEExSU1FUHJvY2Vzc01lc3NhZ2VCbG9jayhTSEExSU1FQ29udGV4dCAqY29udGV4dCkNCnsNCiAg ICBjb25zdCB1aW50MzJfdCBLW10gPSAgICB7ICAgICAgIC8qIENvbnN0YW50cyBkZWZpbmVkIGlu IFNIQS0xICAgKi8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAweDVBODI3OTk5LA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDB4NkVEOUVCQTEsDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgMHg4RjFCQkNEQywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAweENBNjJD MUQ2DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgfTsNCiAgICBpbnQgICAgICAgICAgIHQ7 ICAgICAgICAgICAgICAgICAvKiBMb29wIGNvdW50ZXIgICAgICAgICAgICAgICAgKi8NCiAgICB1 aW50MzJfdCAgICAgIHRlbXA7ICAgICAgICAgICAgICAvKiBUZW1wb3Jhcnkgd29yZCB2YWx1ZSAg ICAgICAgKi8NCiAgICB1aW50MzJfdCAgICAgIFdbODBdOyAgICAgICAgICAgICAvKiBXb3JkIHNl cXVlbmNlICAgICAgICAgICAgICAgKi8NCiAgICB1aW50MzJfdCAgICAgIEEsIEIsIEMsIEQsIEU7 ICAgICAvKiBXb3JkIGJ1ZmZlcnMgICAgICAgICAgICAgICAgKi8NCg0KICAgIC8qDQogICAgICog IEluaXRpYWxpemUgdGhlIGZpcnN0IDE2IHdvcmRzIGluIHRoZSBhcnJheSBXDQogICAgICovDQog ICAgZm9yKHQgPSAwOyB0IDwgMTY7IHQrKykNCiAgICB7DQogICAgICAgIFdbdF0gPSBjb250ZXh0 LT5NZXNzYWdlX0Jsb2NrW3QgKiA0XSA8PCAyNDsNCiAgICAgICAgV1t0XSB8PSBjb250ZXh0LT5N ZXNzYWdlX0Jsb2NrW3QgKiA0ICsgMV0gPDwgMTY7DQogICAgICAgIFdbdF0gfD0gY29udGV4dC0+ TWVzc2FnZV9CbG9ja1t0ICogNCArIDJdIDw8IDg7DQogICAgICAgIFdbdF0gfD0gY29udGV4dC0+ TWVzc2FnZV9CbG9ja1t0ICogNCArIDNdOw0KICAgIH0NCg0KICAgIGZvcih0ID0gMTY7IHQgPCAz NjsgdCsrKQ0KICAgIHsNCiAgICAgICBXW3RdID0gKFdbdC0zXSBeIFdbdC04XSBeIFdbdC0xNF0g XiBXW3QtMTZdKSBeDQogICAgICAgICAgICAgIFNIQTFJTUVDaXJjdWxhclNoaWZ0KDEzLCANCgkg ICAgICAgICAgIChXW3QtMV0gXiBXW3QtMl0gXiBXW3QtMTVdKSk7DQogICAgfQ0KICAgIGZvcih0 ID0gMzY7IHQgPCA4MDsgdCsrKQ0KICAgIHsNCiAgICAgICBXW3RdID0gKFdbdC0zXSBeIFdbdC04 XSBeIFdbdC0xNF0gXiBXW3QtMTZdKSBeDQogICAgICAgICAgICAgIFNIQTFJTUVDaXJjdWxhclNo aWZ0KDEzLCANCgkJICAgKFdbdC0xXSBeIFdbdC0yXSBeIFdbdC0xNV0gXiBXW3QtMjBdKSk7DQog ICAgfQ0KDQogICAgQSA9IGNvbnRleHQtPkludGVybWVkaWF0ZV9IYXNoWzBdOw0KICAgIEIgPSBj b250ZXh0LT5JbnRlcm1lZGlhdGVfSGFzaFsxXTsNCiAgICBDID0gY29udGV4dC0+SW50ZXJtZWRp YXRlX0hhc2hbMl07DQogICAgRCA9IGNvbnRleHQtPkludGVybWVkaWF0ZV9IYXNoWzNdOw0KICAg IEUgPSBjb250ZXh0LT5JbnRlcm1lZGlhdGVfSGFzaFs0XTsNCg0KICAgIGZvcih0ID0gMDsgdCA8 IDIwOyB0KyspDQogICAgew0KICAgICAgICB0ZW1wID0gIFNIQTFJTUVDaXJjdWxhclNoaWZ0KDUs QSkgKw0KICAgICAgICAgICAgICAgICgoQiAmIEMpIHwgKCh+QikgJiBEKSkgKyBFICsgV1t0XSAr IEtbMF07DQogICAgICAgIEUgPSBEOw0KICAgICAgICBEID0gQzsNCiAgICAgICAgQyA9IFNIQTFJ TUVDaXJjdWxhclNoaWZ0KDMwLEIpOw0KDQogICAgICAgIEIgPSBBOw0KICAgICAgICBBID0gdGVt cDsNCiAgICB9DQoNCiAgICBmb3IodCA9IDIwOyB0IDwgNDA7IHQrKykNCiAgICB7DQogICAgICAg IHRlbXAgPSBTSEExSU1FQ2lyY3VsYXJTaGlmdCg1LEEpICsgKEIgXiBDIF4gRCkgKyBFICsgV1t0 XSArIEtbMV07DQogICAgICAgIEUgPSBEOw0KICAgICAgICBEID0gQzsNCiAgICAgICAgQyA9IFNI QTFJTUVDaXJjdWxhclNoaWZ0KDMwLEIpOw0KICAgICAgICBCID0gQTsNCiAgICAgICAgQSA9IHRl bXA7DQogICAgfQ0KDQogICAgZm9yKHQgPSA0MDsgdCA8IDYwOyB0KyspDQogICAgew0KICAgICAg ICB0ZW1wID0gU0hBMUlNRUNpcmN1bGFyU2hpZnQoNSxBKSArDQogICAgICAgICAgICAgICAoKEIg JiBDKSB8IChCICYgRCkgfCAoQyAmIEQpKSArIEUgKyBXW3RdICsgS1syXTsNCiAgICAgICAgRSA9 IEQ7DQogICAgICAgIEQgPSBDOw0KICAgICAgICBDID0gU0hBMUlNRUNpcmN1bGFyU2hpZnQoMzAs Qik7DQogICAgICAgIEIgPSBBOw0KICAgICAgICBBID0gdGVtcDsNCiAgICB9DQoNCiAgICBmb3Io dCA9IDYwOyB0IDwgODA7IHQrKykNCiAgICB7DQogICAgICAgIHRlbXAgPSBTSEExSU1FQ2lyY3Vs YXJTaGlmdCg1LEEpICsgKEIgXiBDIF4gRCkgKyBFICsgV1t0XSArIEtbM107DQogICAgICAgIEUg PSBEOw0KICAgICAgICBEID0gQzsNCiAgICAgICAgQyA9IFNIQTFJTUVDaXJjdWxhclNoaWZ0KDMw LEIpOw0KICAgICAgICBCID0gQTsNCiAgICAgICAgQSA9IHRlbXA7DQogICAgfQ0KDQogICAgY29u dGV4dC0+SW50ZXJtZWRpYXRlX0hhc2hbMF0gKz0gQTsNCiAgICBjb250ZXh0LT5JbnRlcm1lZGlh dGVfSGFzaFsxXSArPSBCOw0KICAgIGNvbnRleHQtPkludGVybWVkaWF0ZV9IYXNoWzJdICs9IEM7 DQogICAgY29udGV4dC0+SW50ZXJtZWRpYXRlX0hhc2hbM10gKz0gRDsNCiAgICBjb250ZXh0LT5J bnRlcm1lZGlhdGVfSGFzaFs0XSArPSBFOw0KDQogICAgY29udGV4dC0+TWVzc2FnZV9CbG9ja19J bmRleCA9IDA7DQp9DQoNCi8qDQogKiAgU0hBMUlNRVBhZE1lc3NhZ2UNCiAqDQoNCiAqICBEZXNj cmlwdGlvbjoNCiAqICAgICAgQWNjb3JkaW5nIHRvIHRoZSBzdGFuZGFyZCwgdGhlIG1lc3NhZ2Ug bXVzdCBiZSBwYWRkZWQgdG8gYW4gZXZlbg0KICogICAgICA1MTIgYml0cy4gIFRoZSBmaXJzdCBw YWRkaW5nIGJpdCBtdXN0IGJlIGEgJzEnLiAgVGhlIGxhc3QgNjQNCiAqICAgICAgYml0cyByZXBy ZXNlbnQgdGhlIGxlbmd0aCBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4gIEFsbCBiaXRzIGluDQog KiAgICAgIGJldHdlZW4gc2hvdWxkIGJlIDAuICBUaGlzIGZ1bmN0aW9uIHdpbGwgcGFkIHRoZSBt ZXNzYWdlDQogKiAgICAgIGFjY29yZGluZyB0byB0aG9zZSBydWxlcyBieSBmaWxsaW5nIHRoZSBN ZXNzYWdlX0Jsb2NrIGFycmF5DQogKiAgICAgIGFjY29yZGluZ2x5LiAgSXQgd2lsbCBhbHNvIGNh bGwgdGhlIFByb2Nlc3NNZXNzYWdlQmxvY2sgZnVuY3Rpb24NCiAqICAgICAgcHJvdmlkZWQgYXBw cm9wcmlhdGVseS4gIFdoZW4gaXQgcmV0dXJucywgaXQgY2FuIGJlIGFzc3VtZWQgdGhhdA0KICog ICAgICB0aGUgbWVzc2FnZSBkaWdlc3QgaGFzIGJlZW4gY29tcHV0ZWQuDQogKg0KICogIFBhcmFt ZXRlcnM6DQogKiAgICAgIGNvbnRleHQ6IFtpbi9vdXRdDQogKiAgICAgICAgICBUaGUgY29udGV4 dCB0byBwYWQNCiAqICAgICAgUHJvY2Vzc01lc3NhZ2VCbG9jazogW2luXQ0KICogICAgICAgICAg VGhlIGFwcHJvcHJpYXRlIFNIQSpQcm9jZXNzTWVzc2FnZUJsb2NrIGZ1bmN0aW9uDQogKiAgUmV0 dXJuczoNCiAqICAgICAgTm90aGluZy4NCiAqDQogKi8NCg0Kdm9pZCBTSEExSU1FUGFkTWVzc2Fn ZShTSEExSU1FQ29udGV4dCAqY29udGV4dCkNCnsNCiAgICAvKg0KICAgICAqICBDaGVjayB0byBz ZWUgaWYgdGhlIGN1cnJlbnQgbWVzc2FnZSBibG9jayBpcyB0b28gc21hbGwgdG8gaG9sZA0KICAg ICAqICB0aGUgaW5pdGlhbCBwYWRkaW5nIGJpdHMgYW5kIGxlbmd0aC4gIElmIHNvLCB3ZSB3aWxs IHBhZCB0aGUNCiAgICAgKiAgYmxvY2ssIHByb2Nlc3MgaXQsIGFuZCB0aGVuIGNvbnRpbnVlIHBh ZGRpbmcgaW50byBhIHNlY29uZA0KICAgICAqICBibG9jay4NCiAgICAgKi8NCiAgICBpZiAoY29u dGV4dC0+TWVzc2FnZV9CbG9ja19JbmRleCA+IDU1KQ0KICAgIHsNCiAgICAgICAgY29udGV4dC0+ TWVzc2FnZV9CbG9ja1tjb250ZXh0LT5NZXNzYWdlX0Jsb2NrX0luZGV4KytdID0gMHg4MDsNCiAg ICAgICAgd2hpbGUoY29udGV4dC0+TWVzc2FnZV9CbG9ja19JbmRleCA8IDY0KQ0KICAgICAgICB7 DQogICAgICAgICAgICBjb250ZXh0LT5NZXNzYWdlX0Jsb2NrW2NvbnRleHQtPk1lc3NhZ2VfQmxv Y2tfSW5kZXgrK10gPSAwOw0KICAgICAgICB9DQoNCiAgICAgICAgU0hBMUlNRVByb2Nlc3NNZXNz YWdlQmxvY2soY29udGV4dCk7DQoNCiAgICAgICAgd2hpbGUoY29udGV4dC0+TWVzc2FnZV9CbG9j a19JbmRleCA8IDU2KQ0KICAgICAgICB7DQogICAgICAgICAgICBjb250ZXh0LT5NZXNzYWdlX0Js b2NrW2NvbnRleHQtPk1lc3NhZ2VfQmxvY2tfSW5kZXgrK10gPSAwOw0KICAgICAgICB9DQogICAg fQ0KICAgIGVsc2UNCiAgICB7DQogICAgICAgIGNvbnRleHQtPk1lc3NhZ2VfQmxvY2tbY29udGV4 dC0+TWVzc2FnZV9CbG9ja19JbmRleCsrXSA9IDB4ODA7DQogICAgICAgIHdoaWxlKGNvbnRleHQt Pk1lc3NhZ2VfQmxvY2tfSW5kZXggPCA1NikNCiAgICAgICAgew0KDQogICAgICAgICAgICBjb250 ZXh0LT5NZXNzYWdlX0Jsb2NrW2NvbnRleHQtPk1lc3NhZ2VfQmxvY2tfSW5kZXgrK10gPSAwOw0K ICAgICAgICB9DQogICAgfQ0KDQogICAgLyoNCiAgICAgKiAgU3RvcmUgdGhlIG1lc3NhZ2UgbGVu Z3RoIGFzIHRoZSBsYXN0IDggb2N0ZXRzDQogICAgICovDQogICAgY29udGV4dC0+TWVzc2FnZV9C bG9ja1s1Nl0gPSBjb250ZXh0LT5MZW5ndGhfSGlnaCA+PiAyNDsNCiAgICBjb250ZXh0LT5NZXNz YWdlX0Jsb2NrWzU3XSA9IGNvbnRleHQtPkxlbmd0aF9IaWdoID4+IDE2Ow0KICAgIGNvbnRleHQt Pk1lc3NhZ2VfQmxvY2tbNThdID0gY29udGV4dC0+TGVuZ3RoX0hpZ2ggPj4gODsNCiAgICBjb250 ZXh0LT5NZXNzYWdlX0Jsb2NrWzU5XSA9IGNvbnRleHQtPkxlbmd0aF9IaWdoOw0KICAgIGNvbnRl eHQtPk1lc3NhZ2VfQmxvY2tbNjBdID0gY29udGV4dC0+TGVuZ3RoX0xvdyA+PiAyNDsNCiAgICBj b250ZXh0LT5NZXNzYWdlX0Jsb2NrWzYxXSA9IGNvbnRleHQtPkxlbmd0aF9Mb3cgPj4gMTY7DQog ICAgY29udGV4dC0+TWVzc2FnZV9CbG9ja1s2Ml0gPSBjb250ZXh0LT5MZW5ndGhfTG93ID4+IDg7 DQogICAgY29udGV4dC0+TWVzc2FnZV9CbG9ja1s2M10gPSBjb250ZXh0LT5MZW5ndGhfTG93Ow0K DQogICAgU0hBMUlNRVByb2Nlc3NNZXNzYWdlQmxvY2soY29udGV4dCk7DQp9DQoNCg0KQXBwZW5k aXggQy4gc2hhMWltZV90ZXN0LmMNCg0KLyoNCiAqICBzaGExaW1lX3Rlc3QuYw0KICoNCiAqICBE ZXNjcmlwdGlvbjoNCiAqICAgICAgVGhpcyBmaWxlIHdpbGwgZXhlcmNpc2UgdGhlIFNIQS0xIGNv ZGUgcGVyZm9ybWluZyB0aGUgdGhyZWUNCiAqICAgICAgdGVzdHMgZG9jdW1lbnRlZCBpbiBGSVBT IFBVQiAxODAtMSBwbHVzIG9uZSB3aGljaCBjYWxscw0KICogICAgICBTSEExSW5wdXQgd2l0aCBh biBleGFjdCBtdWx0aXBsZSBvZiA1MTIgYml0cywgcGx1cyBhIGZldw0KICogICAgICBlcnJvciB0 ZXN0IGNoZWNrcy4NCiAqDQogKiAgUG9ydGFiaWxpdHkgSXNzdWVzOg0KICogICAgICBOb25lLg0K ICoNCiAqLw0KDQojaW5jbHVkZSA8c3RkaW50Lmg+DQojaW5jbHVkZSA8c3RkaW8uaD4NCiNpbmNs dWRlIDxzdHJpbmcuaD4NCiNpbmNsdWRlICJzaGExaW1lLmgiDQoNCi8qDQogKiAgRGVmaW5lIHBh dHRlcm5zIGZvciB0ZXN0aW5nDQogKi8NCiNkZWZpbmUgVEVTVDEgICAiYWJjIg0KI2RlZmluZSBU RVNUMmEgICJhYmNkYmNkZWNkZWZkZWZnZWZnaGZnaGlnaGlqaGkiDQoNCiNkZWZpbmUgVEVTVDJi ICAiamtpamtsamtsbWtsbW5sbW5vbW5vcG5vcHEiDQojZGVmaW5lIFRFU1QyICAgVEVTVDJhIFRF U1QyYg0KI2RlZmluZSBURVNUMyAgICJhIg0KI2RlZmluZSBURVNUNGEgICIwMTIzNDU2NzAxMjM0 NTY3MDEyMzQ1NjcwMTIzNDU2NyINCiNkZWZpbmUgVEVTVDRiICAiMDEyMzQ1NjcwMTIzNDU2NzAx MjM0NTY3MDEyMzQ1NjciDQogICAgLyogYW4gZXhhY3QgbXVsdGlwbGUgb2YgNTEyIGJpdHMgKi8N CiNkZWZpbmUgVEVTVDQgICBURVNUNGEgVEVTVDRiDQpjaGFyICp0ZXN0YXJyYXlbNF0gPQ0Kew0K ICAgIFRFU1QxLA0KICAgIFRFU1QyLA0KICAgIFRFU1QzLA0KICAgIFRFU1Q0DQp9Ow0KbG9uZyBp bnQgcmVwZWF0Y291bnRbNF0gPSB7IDEsIDEsIDEwMDAwMDAsIDEwIH07DQpjaGFyICpyZXN1bHRh cnJheVs0XSA9IHsNCiAgICAiM0UgQUUgMTkgMUUgNTUgNUMgM0QgNEMgMzEgNEIgRkMgRDcgMDkg ODcgNUIgNkUgNTEgODAgMDMgRjUiLCANCiAgICAiRTQgQjAgRUMgRTcgMDUgMkUgNjUgRUQgNkYg NTIgQjYgNkIgQjIgM0QgOUYgM0QgMUQgQ0MgMTcgN0EiLA0KICAgICIzQyAwMCA2MiA1OCAzNCAw RCBCMSAwQiBBMyA2OCAyNyA3MCBBNCBDQiA2RiAzMCBFRiBCQyAyNiA1QyIsDQogICAgIjExIEZE IDM2IEFBIDI5IEY2IDlDIDRDIDkwIDREIDkyIDJDIEEzIDdCIEZCIEMyIEFBIDYzIDVFIDI3Ig0K fTsNCg0KaW50IG1haW4oKQ0Kew0KICAgIFNIQTFJTUVDb250ZXh0IHNoYTsNCiAgICBpbnQgaSwg aiwgZXJyOw0KICAgIHVpbnQ4X3QgTWVzc2FnZV9EaWdlc3RbMjBdOw0KDQogICAgLyoNCiAgICAg KiAgUGVyZm9ybSBTSEExLUlNRSB0ZXN0cw0KICAgICAqLw0KICAgIGZvcihqID0gMDsgaiA8IDQ7 ICsraikNCiAgICB7DQogICAgICAgIHByaW50ZiggIlxuVGVzdCAlZDogJWQsICclcydcbiIsDQog ICAgICAgICAgICAgICAgaisxLA0KICAgICAgICAgICAgICAgIHJlcGVhdGNvdW50W2pdLA0KICAg ICAgICAgICAgICAgIHRlc3RhcnJheVtqXSk7DQoNCiAgICAgICAgZXJyID0gU0hBMUlNRVJlc2V0 KCZzaGEpOw0KICAgICAgICBpZiAoZXJyKQ0KICAgICAgICB7DQogICAgICAgICAgICBmcHJpbnRm KHN0ZGVyciwgIlNIQTFJTUVSZXNldCBFcnJvciAlZC5cbiIsIGVyciApOw0KICAgICAgICAgICAg YnJlYWs7ICAgIC8qIG91dCBvZiBmb3IgaiBsb29wICovDQogICAgICAgIH0NCg0KICAgICAgICBm b3IoaSA9IDA7IGkgPCByZXBlYXRjb3VudFtqXTsgKytpKQ0KICAgICAgICB7DQoNCiAgICAgICAg ICAgIGVyciA9IFNIQTFJTUVJbnB1dCgmc2hhLA0KICAgICAgICAgICAgICAgICAgKGNvbnN0IHVu c2lnbmVkIGNoYXIgKikgdGVzdGFycmF5W2pdLA0KICAgICAgICAgICAgICAgICAgc3RybGVuKHRl c3RhcnJheVtqXSkpOw0KICAgICAgICAgICAgaWYgKGVycikNCiAgICAgICAgICAgIHsNCiAgICAg ICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIlNIQTFJTUVJbnB1dCBFcnJvciAlZC5cbiIsIGVy ciApOw0KICAgICAgICAgICAgICAgIGJyZWFrOyAgICAvKiBvdXQgb2YgZm9yIGkgbG9vcCAqLw0K ICAgICAgICAgICAgfQ0KICAgICAgICB9DQoNCiAgICAgICAgZXJyID0gU0hBMUlNRVJlc3VsdCgm c2hhLCBNZXNzYWdlX0RpZ2VzdCk7DQogICAgICAgIGlmIChlcnIpDQogICAgICAgIHsNCiAgICAg ICAgICAgIGZwcmludGYoc3RkZXJyLA0KICAgICAgICAgICAgIlNIQTFJTUVSZXN1bHQgRXJyb3Ig JWQsIGNvdWxkIG5vdCBjb21wdXRlIG1lc3NhZ2UgZGlnZXN0LlxuIiwNCiAgICAgICAgICAgIGVy ciApOw0KICAgICAgICB9DQogICAgICAgIGVsc2UNCiAgICAgICAgew0KICAgICAgICAgICAgcHJp bnRmKCJcdCIpOw0KICAgICAgICAgICAgZm9yKGkgPSAwOyBpIDwgMjAgOyArK2kpDQogICAgICAg ICAgICB7DQogICAgICAgICAgICAgICAgcHJpbnRmKCIlMDJYICIsIE1lc3NhZ2VfRGlnZXN0W2ld KTsNCiAgICAgICAgICAgIH0NCiAgICAgICAgICAgIHByaW50ZigiXG4iKTsNCiAgICAgICAgfQ0K ICAgICAgICBwcmludGYoIlNob3VsZCBtYXRjaDpcbiIpOw0KICAgICAgICBwcmludGYoIlx0JXNc biIsIHJlc3VsdGFycmF5W2pdKTsNCiAgICB9DQoNCiAgICAvKiBUZXN0IHNvbWUgZXJyb3IgcmV0 dXJucyAqLw0KICAgIGVyciA9IFNIQTFJTUVJbnB1dCgmc2hhLChjb25zdCB1bnNpZ25lZCBjaGFy ICopIHRlc3RhcnJheVsxXSwgMSk7DQogICAgcHJpbnRmICgiXG5FcnJvciAlZC4gU2hvdWxkIGJl ICVkLlxuIiwgZXJyLCBzaGFTdGF0ZUVycm9yICk7DQogICAgZXJyID0gU0hBMUlNRVJlc2V0KDAp Ow0KICAgIHByaW50ZiAoIlxuRXJyb3IgJWQuIFNob3VsZCBiZSAlZC5cbiIsIGVyciwgc2hhTnVs bCApOw0KICAgIHJldHVybiAwOw0KfQ0KDQo= ------_=_NextPart_001_01C5F507.9D6790C7-- From jhutz@cmu.edu Tue Nov 29 13:39:35 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jATIdY1r009695 for ; Tue, 29 Nov 2005 13:39:34 -0500 (EST) Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) jATIdFGr023769; Tue, 29 Nov 2005 13:39:15 -0500 (EST) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa21087; 29 Nov 2005 13:39 EST Received: from bistromath-home.pc.cs.cmu.edu (IDENT:U2FsdGVkX1+scGMoeQE8c1u0y4qqwdXzfzUHOJgLvNA@NEUPERT-EFFECT.FAC.CS.CMU.EDU [128.2.200.133]) (authenticated bits=0)jATIcvRk009857 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 29 Nov 2005 13:39:02 -0500 (EST) Date: Tue, 29 Nov 2005 13:38:56 -0500 From: Jeffrey Hutzelman To: "Blumenthal, Uri" , secdir@mit.edu, saag@mit.edu Message-ID: In-Reply-To: <3DEC199BD7489643817ECA151F7C5929023A4DE9@pysmsx401.amr.corp.intel.com> References: <3DEC199BD7489643817ECA151F7C5929023A4DE9@pysmsx401.amr.corp.int el.com> Originator-Info: login-token=Mulberry:017h+nFliHHIo6ah+XIZ3XhYWR3kF1UyBblNV7JJ8=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (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: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.603506 X-Mailman-Approved-At: Wed, 30 Nov 2005 23:45:08 -0500 cc: Jeffrey Hutzelman Subject: [saag] Re: [secdir]RE: SHA1 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 29 Nov 2005 18:39:35 -0000 On Tuesday, November 29, 2005 12:07:25 PM -0500 "Blumenthal, Uri" wrote: >> I believe that a number of things have been proposed that can be used by >> CA's to add some non-determinism to the thing that they are hashing with >> SHA1 before signing. (without changing the protocol, I think) > > Unfortunately, no. Randomizing hash involves both changing the API and > the standards (therefore the protocols). Mucking the plaintext before > hashing hurts performance and may or may not offer any security gain. No, Michael's statement is essentially correct. There are things that the operator of an X.509 CA can do to resist the currently-known attacks without requiring changes to any protocol or software. For example, the serial number of an X.509 certificate appears early, before to-be-signed data from the certificate request. Thus, by using random large serial numbers rather than sequential ones, a CA removes the attacker's ability to predict the data input to the hash before his colliding pair, and this foils the attack. Of course, collision attacks against an X.509 CA are not all that interesting, and the ability in this protocol for a signer to randomize the hash without adversely affecting the meaning of the signed message does seem to be somewhat unusual. I believe I said this at the SAAG meeting, but I think it bears repeating. When possible, protocols which use hashes should be designed to support MIC's with separate "create" and "verify" operations, rather than assuming a hash can simply be computed in two places and compared. With the former approach, it is easy to start using randomized or otherwised parameterized hashes; with the latter it is very hard. > Overall, IMHO we all will be much better off with a good > cryptographically strong new hash-function. Agreed. Unfortunately, it looks like that is still a ways off. -- Jeff From saag-bounces@ietf.org Thu Dec 1 10:45:16 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB1FjG1r028185 for ; Thu, 1 Dec 2005 10:45:16 -0500 (EST) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) jB1Fj8Ta004048 for ; Thu, 1 Dec 2005 10:45:08 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhqZi-0003UO-3a for saag@mit.edu; Thu, 01 Dec 2005 10:42:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhqZh-0003UJ-8F for saag@megatron.ietf.org; Thu, 01 Dec 2005 10:42:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06403 for ; Thu, 1 Dec 2005 10:41:35 -0500 (EST) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EhquB-00028f-2M for saag@ietf.org; Thu, 01 Dec 2005 11:03:33 -0500 Received: (qmail 15260 invoked by uid 0); 1 Dec 2005 15:42:04 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.40.79) by woodstock.binhost.com with SMTP; 1 Dec 2005 15:42:04 -0000 Message-Id: <7.0.0.10.2.20051201101105.06044e40@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Thu, 01 Dec 2005 10:13:38 -0500 To: saag@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -0.05 X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.073475 Spam-Alum-Time: 0.520688 Subject: [saag] You are enrolled in the wrong email list for SAAG X-BeenThere: saag@mit.edu List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 01 Dec 2005 15:45:17 -0000 I discovered that you are enrolled in saag@ietf.org. This is not the list used by the IETF Security Area Advisors Group. Please join the mail list at saag@mit.edu. http://jis.mit.edu/mailman/listinfo/saag Thanks, Russ _______________________________________________ saag mailing list saag@ietf.org https://www1.ietf.org/mailman/listinfo/saag From housley@vigilsec.com Thu Dec 1 15:37:08 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB1Kb71r000850 for ; Thu, 1 Dec 2005 15:37:07 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) jB1KaxxR005172 for ; Thu, 1 Dec 2005 15:36:59 -0500 (EST) Received: (qmail 17190 invoked by uid 0); 1 Dec 2005 20:36:53 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.40.79) by woodstock.binhost.com with SMTP; 1 Dec 2005 20:36:53 -0000 Message-Id: <7.0.0.10.2.20051201152832.0615a2d8@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Thu, 01 Dec 2005 15:36:54 -0500 To: saag@mit.edu From: Russ Housley Subject: Re: [saag] You are enrolled in the wrong email list for SAAG In-Reply-To: <7.0.0.10.2.20051201101105.06044e40@vigilsec.com> References: <7.0.0.10.2.20051201101105.06044e40@vigilsec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.548614 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 01 Dec 2005 20:37:08 -0000 This message confused some folks. Mostly because I had an incomplete view of the mail list situation. Here is the situation as I understand it. More details may become clear as we go forward. There are two lists: saag@mit.edu and saag@ietf.org. The Security Area Advisory Group has been using the mit.edu list for a very long time, and most of the members are enrolled there. I discovered that a few people were enrolled at the ietf.org list. My intent was to get those people to move to the mit.edu list. After sending the message, I unsubscribed them. My goal is to have one list. Two was obviously leading to confusion. I intend to have the IETF Secretariat delete the saag@ietf.org mail list. Russ At 10:13 AM 12/1/2005, Russ Housley wrote: >I discovered that you are enrolled in saag@ietf.org. This is not >the list used by the IETF Security Area Advisors Group. Please join >the mail list at saag@mit.edu. > >http://jis.mit.edu/mailman/listinfo/saag > >Thanks, > Russ From phoffman@imc.org Thu Dec 1 20:50:18 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB21oI1r003210 for ; Thu, 1 Dec 2005 20:50:18 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) jB21oDkN002376 for ; Thu, 1 Dec 2005 20:50:14 -0500 (EST) Received: from [10.20.30.249] (dsl2-63-249-109-231.cruzio.com [63.249.109.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB21oBcM038895 for ; Thu, 1 Dec 2005 17:50:13 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 1 Dec 2005 17:48:19 -0800 To: saag@mit.edu From: Paul Hoffman Subject: Re: [saag] Structure of documents discussing protocols and hashes Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.587902 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 02 Dec 2005 01:50:19 -0000 At 2:22 PM -0800 11/30/05, David McGrew wrote: >. . . >It would be good to . . . also mention AES GCM ESP (RFC 4106) as >another alternative, which has performance advantages over SHA1 >based algorithms as well. Maybe not, until AES GCM ESP is at least a SHOULD-level algorithm. It may confuse implementers to see a MAY-level algorithm (particularly one of many possible ones) mentioned after saying "you don't need to make any changes". I would propose this non-suggesting for all the documents that come out of this hash-evaluation effort. If we feel a need to change our algorithm suggestions, they should be done as SHOULD-level or MUST-level changes to the protocols themselves, with a note in the hash-related document to the effect of "because of the hash weaknesses, new RFC 5678 now has BetterAlg as a SHOULD; implementers should strongly consider adding that to their implementations of the protocol as soon as possible". Do others agree with this? If not, what rules should we as a group use when picking algorithms to mention/recommend in the hash-evaluation effort? --Paul Hoffman, Director --Internet Mail Consortium From phoffman@imc.org Thu Dec 1 21:12:14 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB22CD1r003410 for ; Thu, 1 Dec 2005 21:12:13 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) jB22CAr3027334 for ; Thu, 1 Dec 2005 21:12:10 -0500 (EST) Received: from [10.20.30.249] (dsl2-63-249-109-231.cruzio.com [63.249.109.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB22C8rE040323 for ; Thu, 1 Dec 2005 18:12:09 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <9375.1133384411@sandelman.ottawa.on.ca> References: <9375.1133384411@sandelman.ottawa.on.ca> Date: Thu, 1 Dec 2005 18:12:07 -0800 To: saag@mit.edu From: Paul Hoffman Subject: Re: [saag] Structure of documents discussing protocols and hashes Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.587009 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 02 Dec 2005 02:12:15 -0000 At 4:00 PM -0500 11/30/05, Michael Richardson wrote: >. . . it seems that there are differences between >the general problem (where you can't control the CAs used), and the >IPsec situation (where we have had to have total control over the CA >involved, cf: pki4ipsec.) I was about to put that into the -01 of the draft when I realized that I don't think the IETF has *any* protocols "where you can't control the CAs used". You may be thinking of the serious implementation { feature | flaw } in popular web browsers that come pre-trusting { some | dozens of | an insane number of } CAs. That is, I don't think that whomever is going to write the hash-use document for TLS needs to deal with this as a protocol issue. In thinking about it, I also disagree that IKE has "total control over the CA involved". Sending the CERTREQ payload is not mandatory, so you might receive a certificate signed by a random CA. To me, this seems not that different than the SSL case, if your IKE implementation comes with the same gigantic-bag-of-trust that your browser or OS does. It would be worthwhile for this group to craft wording for what should be said in hash-use documents in protocols where the most popular applications come with many pre-trusted root CAs, and that wording maybe should be in the hash-use document for PKIX itself. Some topics come to mind: - Users cannot know whether or not CAs are using mechanisms (such as introducing unpredictable values in the serial number) to thwart collision-based attacks. - Users may not be able to easily determine the hash algorithm used by all trusted roots. (Many of us use systems that have built-in trust for one or more certs which use MD2.) - Users cannot be expected to understand all this. --Paul Hoffman, Director --Internet Mail Consortium From mcgrew@cisco.com Fri Dec 2 06:47:05 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB2Bl41r006489 for ; Fri, 2 Dec 2005 06:47:05 -0500 (EST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) jB2BkvfQ025343 for ; Fri, 2 Dec 2005 06:46:58 -0500 (EST) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 02 Dec 2005 03:46:57 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB2BkSAI026743; Fri, 2 Dec 2005 03:46:55 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Dec 2005 03:46:54 -0800 Received: from [192.168.1.101] ([10.32.254.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Dec 2005 03:46:54 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2B7EC54D-69D4-49EC-AF93-88D3ACE8CD9C@cisco.com> Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: [saag] Structure of documents discussing protocols and hashes Date: Fri, 2 Dec 2005 03:46:52 -0800 To: Paul Hoffman X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 02 Dec 2005 11:46:54.0304 (UTC) FILETIME=[1769EE00:01C5F736] X-Spam-Score: -2.6 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.605978 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 02 Dec 2005 11:47:06 -0000 Paul, On Dec 1, 2005, at 5:48 PM, Paul Hoffman wrote: > At 2:22 PM -0800 11/30/05, David McGrew wrote: > >> . . . >> It would be good to . . . also mention AES GCM ESP (RFC 4106) as >> another alternative, which has performance advantages over SHA1 >> based algorithms as well. >> > > Maybe not, until AES GCM ESP is at least a SHOULD-level algorithm. > It may confuse implementers to see a MAY-level algorithm > (particularly one of many possible ones) mentioned after saying > "you don't need to make any changes". I would propose this non- > suggesting for all the documents that come out of this hash- > evaluation effort. I'm confused. Your document says that "implementors should strongly consider adding support for ... AES-XCBC-MAC-96", by which I assume you mean the use of that algorithm as a MAC in ESP as in RFC 3566. In what sense is that authentication transform a SHOULD implement and RFC4106 a MAY implement? Is this the recommendation of the IKEv2 draft? Certainly it is not true for IKEv1. Or am I missing something? > If we feel a need to change our algorithm suggestions, they should > be done as SHOULD-level or MUST-level changes to the protocols > themselves, with a note in the hash-related document to the effect > of "because of the hash weaknesses, new RFC 5678 now has BetterAlg > as a SHOULD; implementers should strongly consider adding that to > their implementations of the protocol as soon as possible". > > Do others agree with this? If not, what rules should we as a group > use when picking algorithms to mention/recommend in the hash- > evaluation effort? For sure each protocol affected by the SHA1 fallout needs to add new algorithms that SHOULD or MUST implemented. But since you're writing an Informational document focused on security, you should feel free to make your own recommendations, and perhaps point out where they diverge from the standard. Presumably, if the standards already made suitable recommendations, you wouldn't have to write this doc ;-) David > > --Paul Hoffman, Director > --Internet Mail Consortium > _______________________________________________ > saag mailing list > saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag > From mcgrew@cisco.com Fri Dec 2 07:21:10 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB2CL91r006710 for ; Fri, 2 Dec 2005 07:21:09 -0500 (EST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) jB2CL6fQ003241 for ; Fri, 2 Dec 2005 07:21:06 -0500 (EST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 02 Dec 2005 04:21:05 -0800 X-IronPort-AV: i="3.99,205,1131350400"; d="scan'208"; a="236477647:sNHT26727332" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jB2CKnQa005258; Fri, 2 Dec 2005 04:21:03 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Dec 2005 04:21:02 -0800 Received: from [192.168.1.101] ([10.32.254.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Dec 2005 04:21:01 -0800 In-Reply-To: <2B7EC54D-69D4-49EC-AF93-88D3ACE8CD9C@cisco.com> References: <2B7EC54D-69D4-49EC-AF93-88D3ACE8CD9C@cisco.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: [saag] Structure of documents discussing protocols and hashes Date: Fri, 2 Dec 2005 04:21:00 -0800 To: Paul Hoffman X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 02 Dec 2005 12:21:01.0929 (UTC) FILETIME=[DBE4B590:01C5F73A] X-Spam-Score: -2.6 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.578327 cc: "'saag@mit.edu'" X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 02 Dec 2005 12:21:10 -0000 Hi Paul, another point below: On Dec 2, 2005, at 3:46 AM, David McGrew wrote: > Paul, > > On Dec 1, 2005, at 5:48 PM, Paul Hoffman wrote: > > >> At 2:22 PM -0800 11/30/05, David McGrew wrote: >> >> >>> . . . >>> It would be good to . . . also mention AES GCM ESP (RFC 4106) as >>> another alternative, which has performance advantages over SHA1 >>> based algorithms as well. >>> >>> >> >> Maybe not, until AES GCM ESP is at least a SHOULD-level algorithm. >> It may confuse implementers to see a MAY-level algorithm >> (particularly one of many possible ones) mentioned after saying >> "you don't need to make any changes". I would propose this non- >> suggesting for all the documents that come out of this hash- >> evaluation effort. >> > > I'm confused. Your document says that "implementors should > strongly consider adding support for ... AES-XCBC-MAC-96", by which > I assume you mean the use of that algorithm as a MAC in ESP as in > RFC 3566. In what sense is that authentication transform a SHOULD > implement and RFC4106 a MAY implement? Is this the recommendation > of the IKEv2 draft? Certainly it is not true for IKEv1. Or am I > missing something? > The MAC in RFC 3566 isn't on the list of NIST approved/recommended algorithms. It is similar to CMAC (SP-800-38B), which is another CBC- MAC variant, but CMAC is slightly better optimized, and unfortunately the optimizations make it incompatible with the earlier XCBC variant. (Thanks to Sheila Frankel for confirming this quickly!) NIST plans to recommend AES GCM, which makes RFC 4106 a better implementation choice whenever FIPS-140 conformance is a consideration. David From rja@extremenetworks.com Fri Dec 2 08:57:48 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB2Dvl1r007278 for ; Fri, 2 Dec 2005 08:57:47 -0500 (EST) Received: from smtp1.extremenetworks.com (smtp1.extremenetworks.com [216.52.8.6])jB2DvdKE014612 for ; Fri, 2 Dec 2005 08:57:39 -0500 (EST) Received: from [10.30.20.240] (unknown [10.30.20.240]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 3EAE07941 for ; Fri, 2 Dec 2005 05:57:37 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: <2B7EC54D-69D4-49EC-AF93-88D3ACE8CD9C@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4450B729-1071-45EF-9D90-365232CEDFFA@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [saag] Structure of documents discussing protocols and hashes Date: Fri, 2 Dec 2005 08:57:35 -0500 To: saag@mit.edu X-Mailer: Apple Mail (2.746.2) X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.538624 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 02 Dec 2005 13:57:49 -0000 On 2 Dec 2005, at 07:21, David McGrew wrote: > NIST plans to recommend AES GCM, which makes RFC 4106 > a better implementation choice whenever FIPS-140 conformance > is a consideration. NIST FIPS-140 approvals are a consideration whenever one plans to sell one's product to a growing list of governments (not just the US !) in North America, Europe [1], and the Asia/Pacific region. So this is not a small consideration -- in the commercial world. Of course, in the IETF world, RFC-1984 is applicable instead. :-) Ran [1] France being an exception, as is commonly the case when discussing groups of countries or governments. From mcr@sandelman.ottawa.on.ca Fri Dec 2 10:36:05 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB2Fa41r007895 for ; Fri, 2 Dec 2005 10:36:04 -0500 (EST) Received: from lists.sandelman.ca (cod.sandelman.ca [192.139.46.139]) jB2FZvqo015131 for ; Fri, 2 Dec 2005 10:35:57 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id jB2FZoC24666 verified OK) for ; Fri, 2 Dec 2005 10:35:56 -0500 (EST) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 7414D3AD9C for ; Fri, 2 Dec 2005 10:35:20 -0500 (EST) To: saag@mit.edu Subject: Re: [saag] Structure of documents discussing protocols and hashes In-Reply-To: Message from David McGrew References: X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Fri, 02 Dec 2005 10:35:20 -0500 Message-ID: <26719.1133537720@sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.601973 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 02 Dec 2005 15:36:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "David" == David McGrew writes: David> I think that it's worth suggesting that implementors move to David> a SHA-256 based PRF for IKE. I don't think you understand the attacks very well if you suggest that. The PRF is about sifting bits. The inputs to it are fixed in length (for a given situation) consists of pieces from both parties, which are both public (nonces and cookies), as well as private (result of DH). The output of it is never made public. There is nothing for an attacker to get onto. As far as I understand things, unless someone figures out a way to break MD5 such that knowing one input to the function means that you know the entire output, the use of hashes for PRFs is not imperiled. The reason that I say this is because getting the right inputs and outputs to the PRF is often very difficult. An error here is usually made consistently, so an implementation will interoperate with itself, and it is often hard to get to details of the input/output of the PRF out of many implementations (in debug mode), so it is very hard to figure out what is occuring wrong. i.e. this is among the hardest piece to test. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBQ5BpsYCLcPvd0N1lAQJJFwgAwBLRiNZY37O0VVSIu6fTA+sCVKTULKIe zlUdZdqYD9mADXadUG9Oz/Rx4VZ4zUbzNqQHB7QOHYhETJNN+30llbYwBx63hUeP eRgN6EirxvQjviPjU/3FdVDpy9YjLBYvjSxDfWWd0fjXudjjHPmVEHH6wRPz+3+A WqkeOMm/c0Ba/bdt/qdUvJcdp2Yvp+QoSunkakoavp6mVlePp6NlriHxj/ml3Jim CXPNXIVKlo7lZVMs4/J+uiqKrLp9UPGrLpPfkjMcDgRRUkhyXt1IVzrzj/WT7oBv ogOEX8OHnsSJmo2nhdHRqcA1SICI/gk6yULeJdB6Y/o9dbNL7wBM+A== =NN06 -----END PGP SIGNATURE----- From mcr@sandelman.ottawa.on.ca Fri Dec 2 10:56:03 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB2Fu31r008034 for ; Fri, 2 Dec 2005 10:56:03 -0500 (EST) Received: from lists.sandelman.ca (cod.sandelman.ca [192.139.46.139]) jB2Fteqo009800; Fri, 2 Dec 2005 10:55:40 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id jB2FtTC25108 verified OK); Fri, 2 Dec 2005 10:55:35 -0500 (EST) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 5E85B3AD9C; Fri, 2 Dec 2005 10:54:59 -0500 (EST) To: "Blumenthal, Uri" Subject: Re: [saag] RE: SHA1 In-Reply-To: Message from "Blumenthal, Uri" <3DEC199BD7489643817ECA151F7C5929023A4DE9@pysmsx401.amr.corp.intel.com> References: <3DEC199BD7489643817ECA151F7C5929023A4DE9@pysmsx401.amr.corp.intel.com> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Fri, 02 Dec 2005 10:54:59 -0500 Message-ID: <21002.1133538899@sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.575972 cc: secdir@mit.edu cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 02 Dec 2005 15:56:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Uri" == Blumenthal, Uri writes: >> I would also like to see a non-keyed HMAC-SHA1 defined. (set the >> key >> to a constant). Uri> But you do realize that all the proofs about HMAC fly out of Uri> the window if the key is non-secret? It is quite possible that Uri> current attacks are extendable to HMAC-XXX *IF* the key is Uri> public. Ah, I see. I had understood that the reason that the HMAC construction was immune was because it was not possible to append additional data to the original. Maybe that was just the MD5 issue. >> SHA1 before signing. (without changing the protocol, I think) Uri> Unfortunately, no. Randomizing hash involves both changing the Uri> API and the standards (therefore the protocols). Mucking the Uri> plaintext before hashing hurts performance and may or may not Uri> offer any security gain. I thought that if the CA uses a non-predicable serial number, that they had additional defenses. Uri> Overall, IMHO we all will be much better off with a good Uri> cryptographically strong new hash-function. I agree. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBQ5BuUoCLcPvd0N1lAQJH7gf+Kzz7clJtVRQ/q8GIxBqI0FgnHJ9GOKJS 5q9PTue9aoFwYWH8v4sx7tZczzuxE8ue4sTV8NTJMWfhrqvpuByvDAUmpVJy3qXY o0M3ZhBMacp6deyithLlEkAoFq+CA3dQHW7YN80Rz6fAvh55r/rOas4QmnmHepp4 joptyZ7X3Pdy+ZMnzuJiKZGUWwyzLkxpf/syDeB4w38D0UKcQtYuOD8a4V1fDwbw xn0UmWax3fQv4UGDKT8tx14+9wirVliODxzj1RY6C8Ch+me1X9Tic9q76Nnbgi+U sPMlIkQ6hxqAIh6O/LcP0H8TtwHWsOqxstV1vv5sa9NqFZf4L73GTg== =5w44 -----END PGP SIGNATURE----- From mcr@sandelman.ottawa.on.ca Fri Dec 2 11:08:11 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB2G8B1r008133 for ; Fri, 2 Dec 2005 11:08:11 -0500 (EST) Received: from lists.sandelman.ca (cod.sandelman.ca [192.139.46.139]) jB2G7sH1028335 for ; Fri, 2 Dec 2005 11:07:54 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id jB2G7jC25174 verified OK); Fri, 2 Dec 2005 11:07:51 -0500 (EST) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id E72213AD9C; Fri, 2 Dec 2005 11:07:14 -0500 (EST) To: Paul Hoffman Subject: Re: [saag] Structure of documents discussing protocols and hashes In-Reply-To: Message from Paul Hoffman of "Thu, 01 Dec 2005 18:12:07 PST." References: <9375.1133384411@sandelman.ottawa.on.ca> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Fri, 02 Dec 2005 11:07:14 -0500 Message-ID: <662.1133539634@sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.597172 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 02 Dec 2005 16:08:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Paul" == Paul Hoffman writes: Paul> I was about to put that into the -01 of the draft when I Paul> realized that I don't think the IETF has *any* protocols Paul> "where you can't control the CAs used". You may be thinking of Paul> the serious implementation { feature | flaw } in popular web Paul> browsers that come pre-trusting { some | dozens of | an insane Paul> number of } CAs. That is, I don't think that whomever is going Paul> to write the hash-use document for TLS needs to deal with this Paul> as a protocol issue. Yes, I agree. There are also some differences in how S/MIME uses CAs, since often there can be no online negotiation of the CA/certificate used. Paul> In thinking about it, I also disagree that IKE has "total Paul> control over the CA involved". Sending the CERTREQ payload is Paul> not mandatory, so you might receive a certificate signed by a Paul> random CA. To me, this seems not that different than the SSL Paul> case, if your IKE implementation comes with the same Paul> gigantic-bag-of-trust that your browser or OS does. In general, receiving a certificate signed by some random CA causes failure to communicate in IKE. The same thing in web causes the user to click through some dialgue they don't understand :-) Paul> - Users cannot be expected to understand all this. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Finger me for keys iQEUAwUBQ5BxMYCLcPvd0N1lAQK+3gf2MWmKsGcJVsSaJQ2CDzCQjaNgFXWzBIxQ byZCl0uahQx2PLMg1CtR9O/jqIyN6pcxNwsSBMI70Nlgs74HNFczRE8VcgBwJ431 q5T0FO/DTlrzL9SyOqgKm2VLeOFuJTXfF3huUAjReaHRWkGwfyGQNg092G28IkqC uaKtZZlp+/8ZwiJbywwpad1s0iqMBDjp28nKTIqJX/cQKpvQdFAT38fqBqQ4H7Hp II5/DMRb5Xs/52eXjYWeH1PTSRAJLlXafs1+Zm1quRus+EPWueC5sfIKYi1CRpAW zyYRkjd5H30lJWhoDccxJ/OF50NTe1Fi2Lc6kLqu0WMzCf7TLmkS =N/sg -----END PGP SIGNATURE----- From paul.hoffman@vpnc.org Fri Dec 2 12:26:45 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB2HQi1r008751 for ; Fri, 2 Dec 2005 12:26:44 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) jB2HQfqo001893 for ; Fri, 2 Dec 2005 12:26:41 -0500 (EST) Received: from [10.20.30.249] (dsl2-63-249-109-231.cruzio.com [63.249.109.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2HQdhO030783 for ; Fri, 2 Dec 2005 09:26:40 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4450B729-1071-45EF-9D90-365232CEDFFA@extremenetworks.com> <2B7EC54D-69D4-49EC-AF93-88D3ACE8CD9C@cisco.com> References: <2B7EC54D-69D4-49EC-AF93-88D3ACE8CD9C@cisco.com> <2B7EC54D-69D4-49EC-AF93-88D3ACE8CD9C@cisco.com> <4450B729-1071-45EF-9D90-365232CEDFFA@extremenetworks.com> <2B7EC54D-69D4-49EC-AF93-88D3ACE8CD9C@cisco.com> Date: Fri, 2 Dec 2005 09:25:14 -0800 To: saag@mit.edu From: Paul Hoffman Subject: Re: [saag] Structure of documents discussing protocols and hashes Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.648465 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 02 Dec 2005 17:26:46 -0000 At 3:46 AM -0800 12/2/05, David McGrew wrote: >>. . . >>It would be good to . . . also mention AES GCM ESP (RFC 4106) as >>another alternative ... >>...snip... >>... to make any changes". I would propose this non-suggesting for >>all the documents that come out of this hash-evaluation effort. > >I'm confused. Your document says that "implementors should strongly >consider adding support for ... AES-XCBC-MAC-96", by which I assume >you mean the use of that algorithm as a MAC in ESP as in RFC 3566. >In what sense is that authentication transform a SHOULD implement >and RFC4106 a MAY implement? Is this the recommendation of the >IKEv2 draft? Certainly it is not true for IKEv1. Or am I missing >something? Probably. The forthcoming IKEv2 recommendations in the RFC Editor's Queue (draft-ietf-ipsec-ikev2-algorithms-05.txt) has AES-XCBC-MAC-96 as a SHOULD+. >> If we feel a need to change our algorithm suggestions, they should >>be done as SHOULD-level or MUST-level changes to the protocols ... >>...snip... >>Do others agree with this? If not, what rules should we as a group >>use when picking algorithms to mention/recommend in the >>hash-evaluation effort? > >For sure each protocol affected by the SHA1 fallout needs to add new >algorithms that SHOULD or MUST implemented. But since you're >writing an Informational document focused on security, you should >feel free to make your own recommendations, and perhaps point out >where they diverge from the standard. Presumably, if the standards >already made suitable recommendations, you wouldn't have to write >this doc ;-) The fact that this is an informational document is irrelevant in my mind. It is going to be IESG-approved, and thus it should not disagree with earlier IESG-approved standards-track documents. >The MAC in RFC 3566 isn't on the list of NIST approved/recommended >algorithms. It is similar to CMAC (SP-800-38B), which is another >CBC-MAC variant, but CMAC is slightly better optimized, and >unfortunately the optimizations make it incompatible with the >earlier XCBC variant. (Thanks to Sheila Frankel for confirming this >quickly!) >NIST plans to recommend AES GCM, which makes RFC 4106 a better >implementation choice whenever FIPS-140 conformance is a >consideration. At the point that GCM becomes FIPS-approved, the IETF should consider whether or not to change it recommendations from RFC 3566. At 8:57 AM -0500 12/2/05, RJ Atkinson wrote: >NIST FIPS-140 approvals are a consideration whenever one plans >to sell one's product to a growing list of governments (not just >the US !) in North America, Europe [1], and the Asia/Pacific region. >So this is not a small consideration -- in the commercial world. Fully agree. The question is: how does that affect the IETF standards process, particularly if we have previously made SHOULD-level or MUST-level standards for different algorithms? --Paul Hoffman, Director --VPN Consortium From uri.blumenthal@intel.com Fri Dec 2 13:29:50 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB2ITn1r009214 for ; Fri, 2 Dec 2005 13:29:49 -0500 (EST) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) jB2ITWGh024068; Fri, 2 Dec 2005 13:29:32 -0500 (EST) Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.253.24.20]) 2004/09/17 17:50:56 root Exp $) with ESMTP id jB2ITVtW006070; Fri, 2 Dec 2005 18:29:31 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) 2004/09/17 18:05:01 root Exp $) with SMTP id jB2ITULa004419; Fri, 2 Dec 2005 18:29:31 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) M2005120210293105640 ; Fri, 02 Dec 2005 10:29:31 -0800 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Dec 2005 10:29:31 -0800 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Dec 2005 10:29:30 -0800 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Dec 2005 13:29:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [saag] RE: SHA1 Date: Fri, 2 Dec 2005 13:29:28 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929023FB335@pysmsx401.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] RE: SHA1 Thread-Index: AcX3WOVTqTPjI426Tei5v6qNrp3FZQACR2rw From: "Blumenthal, Uri" To: "Michael Richardson" X-OriginalArrivalTime: 02 Dec 2005 18:29:29.0903 (UTC) FILETIME=[5545D3F0:01C5F76E] X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.52 on 10.253.24.20 X-Spam-Score: -2.599 X-Spam-Flag: NO Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.528107 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id jB2ITn1r009214 cc: secdir@mit.edu cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 02 Dec 2005 18:29:51 -0000 > I had understood that the reason that the HMAC construction > was immune was because it was not possible to append additional > data to the original. Maybe that was just the MD5 issue. No, not just MD5. But the main concern now is _collision_ exploitation, and HMAC defends against it by having secret (unpredictable) reasonably large key. > I thought that if the CA uses a non-predicable serial number, that > they had additional defenses. Yes, it provides some extra defense. The question is: how strong this extra defense is, and for how long it may stand? My point was - it really depends. From rja@extremenetworks.com Fri Dec 2 15:38:03 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB2Kc21r010140 for ; Fri, 2 Dec 2005 15:38:02 -0500 (EST) Received: from smtp1.extremenetworks.com (smtp1.extremenetworks.com [216.52.8.6])jB2KbwTu024964 for ; Fri, 2 Dec 2005 15:37:58 -0500 (EST) Received: from [10.30.20.240] (unknown [10.30.20.240]) by smtp1.extremenetworks.com (Postfix) with ESMTP id A008E7941; Fri, 2 Dec 2005 12:37:57 -0800 (PST) In-Reply-To: References: <2B7EC54D-69D4-49EC-AF93-88D3ACE8CD9C@cisco.com> <2B7EC54D-69D4-49EC-AF93-88D3ACE8CD9C@cisco.com> <4450B729-1071-45EF-9D90-365232CEDFFA@extremenetworks.com> <2B7EC54D-69D4-49EC-AF93-88D3ACE8CD9C@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5D2FD776-92A3-482C-A03C-194F9BA28F21@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [saag] Structure of documents discussing protocols and hashes Date: Fri, 2 Dec 2005 15:37:55 -0500 To: Paul Hoffman X-Mailer: Apple Mail (2.746.2) X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.580266 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 02 Dec 2005 20:38:04 -0000 On 2 Dec 2005, at 12:25, Paul Hoffman wrote: > At 8:57 AM -0500 12/2/05, RJ Atkinson wrote: >> NIST FIPS-140 approvals are a consideration whenever one plans >> to sell one's product to a growing list of governments (not just >> the US !) in North America, Europe [1], and the Asia/Pacific region. >> So this is not a small consideration -- in the commercial world. > > Fully agree. The question is: how does that affect the IETF > standards process, particularly if we have previously made SHOULD- > level or MUST-level standards for different algorithms? The bit of my note that you deleted addressed that question. To give a more expansive reply... I would argue that the decision of any government should not affect the IETF standards processes at all. [RFC-1984] IETF ought to be standardising cryptographic algorithms/modes solely on the basis of the published literature about candidate algorithms/modes, the public confidence level in such candidates based on the public literature, and so forth. All governmental approvals ought to be ignored as part of this process, because the IETF operates globally rather than nationally. That said, it is helpful if there is at least an informational specification of how to use NIST (and any other openly specified) algorithms/modes with IETF protocols. I see no requirement for any/all such specifications to be on the standards-track. From a commercial perspective, rather than an IETF standards process perspective, the need is simply to have open specifications so things interoperate, without any commercial need for everything to formally be on the IETF standards-track. Yours, Ran rja@extremenetworks.com From mcgrew@cisco.com Fri Dec 2 17:55:49 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB2Mtm1r011010 for ; Fri, 2 Dec 2005 17:55:48 -0500 (EST) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) jB2MtfnZ009716 for ; Fri, 2 Dec 2005 17:55:41 -0500 (EST) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 02 Dec 2005 14:55:41 -0800 X-IronPort-AV: i="3.99,208,1131350400"; d="scan'208"; a="680811495:sNHT37186550" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB2MtLBR010356; Fri, 2 Dec 2005 14:55:38 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Dec 2005 14:55:24 -0800 Received: from [192.168.1.101] ([10.32.254.210]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Dec 2005 14:55:24 -0800 In-Reply-To: <26719.1133537720@sandelman.ottawa.on.ca> References: <26719.1133537720@sandelman.ottawa.on.ca> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <57F8C696-5CFD-4798-8264-646BD0CEEF82@cisco.com> From: David McGrew Subject: Re: [saag] Structure of documents discussing protocols and hashes Date: Fri, 2 Dec 2005 14:55:21 -0800 To: Michael Richardson X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 02 Dec 2005 22:55:24.0159 (UTC) FILETIME=[7AC018F0:01C5F793] X-Spam-Score: -2.6 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.641388 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id jB2Mtm1r011010 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 02 Dec 2005 22:55:50 -0000 Hi Michael, On Dec 2, 2005, at 7:35 AM, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > >>>>>> "David" == David McGrew writes: >>>>>> > David> I think that it's worth suggesting that implementors > move to > David> a SHA-256 based PRF for IKE. > > I don't think you understand the attacks very well if you suggest > that. > The PRF is about sifting bits. The inputs to it are fixed in length > (for a given situation) consists of pieces from both parties, which > are > both public (nonces and cookies), as well as private (result of DH). > The output of it is never made public. There is nothing for an > attacker to get onto. > As far as I understand things, unless someone figures out a way to > break MD5 such that knowing one input to the function means that you > know the entire output, the use of hashes for PRFs is not imperiled. Sure, and HMAC-SHA1 is believed to be secure regardless of the collision results against SHA1, and it is HMAC that's used in the PRF. My comments were in part motivated by the desire to use a Diffie- Hellman method that's provably secure. I believe that that collision resistance of the IKE KDF hash is needed for such a proof. The analysis of the key derivation used in IKE that I have in mind is in Dodis, Gennaro, Håstad, Krawczyk, and Rabin, "Randomness Extraction and Key Derivation Using the CBC, Cascade and HMAC Modes", Advances in Cryptology – CRYPTO 2004, online at http://theory.lcs.mit.edu/ ~yevgen/ps/hmac.ps. The IKE implications are mentioned in the 2nd to last par. of Section 1.2, and the HMAC results are in the subsection "The Extraction Properties of HMAC". I'll check with Hugo to verify my interpretation here. The point that I wanted to make is that "it is best to migrate towards crypto methods that have less unproven assumptions", not "there is a lurking flaw and we all need to implement something new right away". I agree with your gist, that as far as we know, there are no security problems with using IKE relying on an HMAC-SHA1 PRF. > > The reason that I say this is because getting the right inputs and > outputs to the PRF is often very difficult. An error here is usually > made consistently, so an implementation will interoperate with itself, > and it is often hard to get to details of the input/output of the PRF > out of many implementations (in debug mode), so it is very hard to > figure out what is occuring wrong. > > i.e. this is among the hardest piece to test. Yes, and unfortunately KDFs in general seem to have been designed without algorithm agility in mind. David > From mcr@sandelman.ottawa.on.ca Fri Dec 2 20:29:26 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB31TP1r011947 for ; Fri, 2 Dec 2005 20:29:25 -0500 (EST) Received: from lists.sandelman.ca (cod.sandelman.ca [192.139.46.139]) jB31TLBI009348 for ; Fri, 2 Dec 2005 20:29:22 -0500 (EST) Received: from sandelman.ottawa.on.ca (postfix@wlan225.sandelman.ca [205.150.200.225]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id jB31TIL02064 verified OK); Fri, 2 Dec 2005 20:29:19 -0500 (EST) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id BDC9F3AD9C; Fri, 2 Dec 2005 20:29:17 -0500 (EST) To: David McGrew Subject: Re: [saag] Structure of documents discussing protocols and hashes In-Reply-To: Message from David McGrew <57F8C696-5CFD-4798-8264-646BD0CEEF82@cisco.com> References: <26719.1133537720@sandelman.ottawa.on.ca> <57F8C696-5CFD-4798-8264-646BD0CEEF82@cisco.com> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Fri, 02 Dec 2005 20:29:17 -0500 Message-ID: <357.1133573357@sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.595461 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 03 Dec 2005 01:29:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "David" == David McGrew writes: David> The point that I wanted to make is that "it is best to David> migrate towards crypto methods that have less unproven David> assumptions", not "there is a lurking flaw and we all need to David> implement something new right away". I agree with your gist, David> that as far as we know, there are no security problems with David> using IKE relying on an HMAC-SHA1 PRF. >> The reason that I say this is because getting the right inputs >> and outputs to the PRF is often very difficult. An error here is >> usually made consistently, so an implementation will interoperate >> with itself, and it is often hard to get to details of the >> input/output of the PRF out of many implementations (in debug >> mode), so it is very hard to figure out what is occuring wrong. >> >> i.e. this is among the hardest piece to test. David> Yes, and unfortunately KDFs in general seem to have been David> designed without algorithm agility in mind. I don't agree. We are rather agile in the KDFs in IKE. My point is that debugging the KDF is difficult, since it involves combining inputs from a remote end --- it isn't deterministic, so it's hard to build a regression test unless you can easily control both ends. And at that point, it isn't clear that you are really testing what you should be. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBQ5D07ICLcPvd0N1lAQJXnwf+Ns6+FtWeZKMQvNa6VuldNSTca6jgxeiJ 2qL/LXCHhxeSqZdh3VVeSjCE6bldN1CinAbxOFA6W+9OCINdoCLdKc0w5TPNXRBM 5/h5/uCmEgrO3NpBkP2oYm5ugqVdO0XxlbtzBMMFBZVwXWi/eeciPVay4+QMt/rD yxqI7Tpwhzm/9OXqO3Rb85bYvKqx02+ExZkc8mHPhp2UNxkeaCnhpKt0FJRGiMHx 2hR0ku/pq38VC09SGc5iqlY4nFHwaD1RSeHVTqXfEF0KXuYyCabwq/4BwQpiGa9/ 6D9+ZS0VpENe2sVnEtkYcED8dIHQx54TnUH6Mk5NQGAtnlb8/aIBLg== =wrPF -----END PGP SIGNATURE----- From hugo@ee.technion.ac.il Mon Dec 5 14:49:57 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB5Jnu1r004851 for ; Mon, 5 Dec 2005 14:49:56 -0500 (EST) Received: from mailgw2.technion.ac.il (mailgw2.technion.ac.il [132.68.238.33]) jB5JnluN007657 for ; Mon, 5 Dec 2005 14:49:47 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw2.technion.ac.il (Postfix) with ESMTP id BFEF33901F0 for ; Mon, 5 Dec 2005 21:49:46 +0200 (IST) Received: from mailgw2.technion.ac.il ([127.0.0.1]) by localhost (mailgw2.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 02288-01-22 for ; Mon, 5 Dec 2005 21:49:46 +0200 (IST) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw2.technion.ac.il (Postfix) with ESMTP id 9390D3901D3 for ; Mon, 5 Dec 2005 21:49:46 +0200 (IST) Received: from ee.technion.ac.il (localhost [127.0.0.1]) jB5Jq1FK016337; Mon, 5 Dec 2005 21:52:01 +0200 (IST) Received: from localhost (hugo@localhost)jB5Jq0kq016334; Mon, 5 Dec 2005 21:52:01 +0200 (IST) Date: Mon, 5 Dec 2005 21:52:00 +0200 (IST) From: Hugo Krawczyk To: David McGrew Subject: Re: [saag] Structure of documents discussing protocols and hashes In-Reply-To: <57F8C696-5CFD-4798-8264-646BD0CEEF82@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-8 X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new at technion.ac.il X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.689886 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by jis.mit.edu id jB5Jnu1r004851 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 05 Dec 2005 19:49:57 -0000 David McGrew asked me to comment on the appended message re hash functions in IKE. My view is that there is no need to RUSH into upgrading SHA-1 in IKEv1 or v2. The only place where the recent attacks have a direct relevance is in public key certificates. Other uses of hashes in IKE (which include PRF, MAC, ephemeral signatures, and the randomness extraction functionality referred to by David's mail) would have some benefit from a hash function upgrade but nothing truly urgent. None of these uses are based on collision resistance in some essential way. Of course, new attacks, in particular on the pseudo-random properties of secretly-keyed HMAC, could be found in the future (or maybe even in the present), but such attacks to be of real significance will not be merely collision attacks. On the other hand it is imperative that a transition to stronger hash functions be planned now and executed asap. First, we do not know how fast attacks will improve and reach the point of being relevant even for uses such as in IKE. Second, such a transition is needed across all cryptographic applications and certainly across ietf standards. Last, there are no performance issues with the hash functions used in IKE. These operations are all quite insiginificant in comparison to public key (signatures and Diffie-Hellman) operations, so a slower hash function should not be a consideration against upgrading (this may be different in the case of ipsec that uses HMAC to MAC millions of packets). As for certificates, where collision attacks may be of real significance, this is not IKE-specific. In that front, planning a transition is even more significant (and I would not count on the lack of explicit practical attacks on real-world certificates). Hugo On Fri, 2 Dec 2005, David McGrew wrote: > Hi Michael, > > On Dec 2, 2005, at 7:35 AM, Michael Richardson wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > >>>>>> "David" == David McGrew writes: > >>>>>> > > David> I think that it's worth suggesting that implementors > > move to > > David> a SHA-256 based PRF for IKE. > > > > I don't think you understand the attacks very well if you suggest > > that. > > The PRF is about sifting bits. The inputs to it are fixed in length > > (for a given situation) consists of pieces from both parties, which > > are > > both public (nonces and cookies), as well as private (result of DH). > > The output of it is never made public. There is nothing for an > > attacker to get onto. > > As far as I understand things, unless someone figures out a way to > > break MD5 such that knowing one input to the function means that you > > know the entire output, the use of hashes for PRFs is not imperiled. > > Sure, and HMAC-SHA1 is believed to be secure regardless of the > collision results against SHA1, and it is HMAC that's used in the PRF. > > My comments were in part motivated by the desire to use a Diffie- > Hellman method that's provably secure.I believe that that collision > resistance of the IKE KDF hash is needed for such a proof.The > analysis of the key derivation used in IKE that I have in mind is in > Dodis, Gennaro, Håstad, Krawczyk, and Rabin, "Randomness Extraction > and Key Derivation Using the CBC, Cascade and HMAC Modes", Advances > in Cryptology – CRYPTO 2004, online at http://theory.lcs.mit.edu/ > ~yevgen/ps/hmac.ps.The IKE implications are mentioned in the 2nd to > last par. of Section 1.2, and the HMAC results are in the subsection > "The Extraction Properties of HMAC".I'll check with Hugo to verify > my interpretation here. > > The point that I wanted to make is that "it is best to migrate > towards crypto methods that have less unproven assumptions", not > "there is a lurking flaw and we all need to implement something new > right away".I agree with your gist, that as far as we know, there > are no security problems with using IKE relying on an HMAC-SHA1 PRF. > > > > > The reason that I say this is because getting the right inputs and > > outputs to the PRF is often very difficult. An error hereis usually > > made consistently, so an implementation will interoperate with itself, > > and it is often hard to get to details of the input/output of the PRF > > out of many implementations (in debug mode), so it is very hard to > > figure out what is occuring wrong. > > > > i.e. this is among the hardest piece to test. > > Yes, and unfortunately KDFs in general seem to have been designed > without algorithm agility in mind. > > David > > > > From paul.hoffman@vpnc.org Mon Dec 5 17:56:48 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB5Mul1r006272 for ; Mon, 5 Dec 2005 17:56:47 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) jB5MuY3M001402 for ; Mon, 5 Dec 2005 17:56:34 -0500 (EST) Received: from [10.20.30.249] (dsl2-63-249-109-231.cruzio.com [63.249.109.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB5MuL75020461; Mon, 5 Dec 2005 14:56:23 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 5 Dec 2005 14:53:59 -0800 To: Hugo Krawczyk From: Paul Hoffman Subject: Re: [saag] Structure of documents discussing protocols and hashes Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.600066 cc: IPsec WG cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 05 Dec 2005 22:56:49 -0000 At 9:52 PM +0200 12/5/05, Hugo Krawczyk wrote: >My view is that there is no need to RUSH into upgrading SHA-1 in >IKEv1 or v2. The only place where the recent attacks have a direct >relevance is in public key certificates. Other uses of hashes in IKE >(which include PRF, MAC, ephemeral signatures, and the randomness >extraction functionality referred to by David's mail) would have some >benefit from a hash function upgrade but nothing truly urgent. None of >these uses are based on collision resistance in some essential way. >Of course, new attacks, in particular on the pseudo-random properties of >secretly-keyed HMAC, could be found in the future (or maybe even in the >present), but such attacks to be of real significance will not be merely >collision attacks. The series of "hash evaluation" documents should give as specific numbers as possible. Here, you say "there is no need to RUSH" and "nothing truly urgent". Do we know of any collision-reduction attacks now that would cause any issues with IKE or IPsec? If not, why is there any need to amble, much less rush, towards new hash functions? Given that our preferred encryption algorithms are 112 and 128 bits strong, exactly where should we worry about using MD5 or SHA1 in IPsec (other than in the PKIX part)? Of course, if someone uses AES-192 or AES-256, they probably want to use SHA-256, but that's not relevant here. >First, we do not know how fast >attacks will improve and reach the point of being relevant even for uses >such as in IKE. Let's assume that the collision-resistance attacks get very good very quickly, such as reducing the collision-resistance of SHA-1 to 40 bits, but the preimage resistance is unaffected. Would our recommended hash functions change, and why? --Paul Hoffman, Director --VPN Consortium From smb@cs.columbia.edu Mon Dec 5 18:19:53 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB5NJq1r006494 for ; Mon, 5 Dec 2005 18:19:52 -0500 (EST) Received: from machshav.com (machshav.com [147.28.0.16]) jB5NJiED015353 for ; Mon, 5 Dec 2005 18:19:44 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id ABB89FB28A; Mon, 5 Dec 2005 18:19:43 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 25466FB27F; Mon, 5 Dec 2005 18:19:42 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id DBAB03C015D; Mon, 5 Dec 2005 18:19:34 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Paul Hoffman Subject: Re: [saag] Structure of documents discussing protocols and hashes In-Reply-To: (Your message of "Mon, 05 Dec 2005 14:53:59 PST.") Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Dec 2005 18:19:34 -0500 Sender: smb@cs.columbia.edu Message-Id: <20051205231934.DBAB03C015D@berkshire.machshav.com> X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.537238 cc: IPsec WG cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 05 Dec 2005 23:19:53 -0000 In message , Paul Hoffman writes: > >Here, you say "there is no need to RUSH" and "nothing truly urgent". >Do we know of any collision-reduction attacks now that would cause >any issues with IKE or IPsec? If not, why is there any need to amble, >much less rush, towards new hash functions? > Per mine and ekr's paper, the problem is that we *can't* switch, even if a serious problem developed. What's really necessary now is to add the extra signaling, so that we can switch hash functions if and when that becomes necessary. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb From paul.hoffman@vpnc.org Mon Dec 5 19:07:05 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB60741r006834 for ; Mon, 5 Dec 2005 19:07:04 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) jB60713M023256 for ; Mon, 5 Dec 2005 19:07:01 -0500 (EST) Received: from [10.20.30.249] (dsl2-63-249-109-231.cruzio.com [63.249.109.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB605iZJ027786; Mon, 5 Dec 2005 16:05:45 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20051205231934.DBAB03C015D@berkshire.machshav.com> References: <20051205231934.DBAB03C015D@berkshire.machshav.com> Date: Mon, 5 Dec 2005 16:05:43 -0800 To: "Steven M. Bellovin" From: Paul Hoffman Subject: Re: [saag] Structure of documents discussing protocols and hashes Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.537039 cc: IPsec WG cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 06 Dec 2005 00:07:06 -0000 At 6:19 PM -0500 12/5/05, Steven M. Bellovin wrote: >In message , Paul Hoffman writes: > >> >>Here, you say "there is no need to RUSH" and "nothing truly urgent". >>Do we know of any collision-reduction attacks now that would cause >>any issues with IKE or IPsec? If not, why is there any need to amble, >>much less rush, towards new hash functions? >> > >Per mine and ekr's paper, the problem is that we *can't* switch, even >if a serious problem developed. What's really necessary now is to add >the extra signaling, so that we can switch hash functions if and when >that becomes necessary. That is important, but orthogonal to my question for Hugo. --Paul Hoffman, Director --VPN Consortium From hugo@ee.technion.ac.il Thu Dec 8 14:02:59 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB8J2w1r003596 for ; Thu, 8 Dec 2005 14:02:58 -0500 (EST) Received: from mailgw2.technion.ac.il (mailgw2.technion.ac.il [132.68.238.33]) jB8J2nwD001686 for ; Thu, 8 Dec 2005 14:02:50 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw2.technion.ac.il (Postfix) with ESMTP id E2E9739028E for ; Thu, 8 Dec 2005 21:02:48 +0200 (IST) Received: from mailgw2.technion.ac.il ([127.0.0.1]) by localhost (mailgw2.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27944-01-73 for ; Thu, 8 Dec 2005 21:02:48 +0200 (IST) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw2.technion.ac.il (Postfix) with ESMTP id A7B1D390278 for ; Thu, 8 Dec 2005 21:02:48 +0200 (IST) Received: from ee.technion.ac.il (localhost [127.0.0.1]) jB8J4wdr008841; Thu, 8 Dec 2005 21:04:59 +0200 (IST) Received: from localhost (hugo@localhost)jB8J4vcq008838; Thu, 8 Dec 2005 21:04:58 +0200 (IST) Date: Thu, 8 Dec 2005 21:04:57 +0200 (IST) From: Hugo Krawczyk To: Paul Hoffman Subject: Re: [saag] Structure of documents discussing protocols and hashes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new at technion.ac.il X-Spam-Score: -2.399 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.699796 cc: IPsec WG cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 08 Dec 2005 19:03:00 -0000 See below On Mon, 5 Dec 2005, Paul Hoffman wrote: > At 9:52 PM +0200 12/5/05, Hugo Krawczyk wrote: > >My view is that there is no need to RUSH into upgrading SHA-1 in > >IKEv1 or v2. The only place where the recent attacks have a direct > >relevance is in public key certificates. Other uses of hashes in IKE > >(which include PRF, MAC, ephemeral signatures, and the randomness > >extraction functionality referred to by David's mail) would have some > >benefit from a hash function upgrade but nothing truly urgent. None of > >these uses are based on collision resistance in some essential way. > >Of course, new attacks, in particular on the pseudo-random properties of > >secretly-keyed HMAC, could be found in the future (or maybe even in the > >present), but such attacks to be of real significance will not be merely > >collision attacks. > > The series of "hash evaluation" documents should give as specific > numbers as possible. > > Here, you say "there is no need to RUSH" and "nothing truly urgent". > Do we know of any collision-reduction attacks now that would cause > any issues with IKE or IPsec? If not, why is there any need to amble, > much less rush, towards new hash functions? Even if the functions we use today are not yet broken in a practical sense, what is broken is our confidence on these functions, and we have to act on this "broken confidence". The way to do it is NOT by trying to measure (quantify) every day what is the latest best attack, but rather we should take advantage of the fact that most applications are currently NOT broken and prepare for a calm (but firm!) transition to new functions. In this sense I am not suggesting anything different than Belovin-Rescorla. As Steve has recently put it: > Per mine and ekr's paper, the problem is that we *can't* switch, even > if a serious problem developed. What's really necessary now is to add > the extra signaling, so that we can switch hash functions if and when > that becomes necessary. The counter-part of this switching problem is (paraphrasing the above): "even when we'll be ready to switch we won't know to WHAT to switch". That is, do not expect that we will be in a situation where our confidence will be fully (or even significantly) recovered. But that is not necessarily a bad thing. Thinking of specific cryptographic functions as resistant to attacks for many years to come is an illusion. We must always be ready for cryptanalytical developments as we've seen with MD5/SHA or even more serious ones (i.e., ones that develop more rapidly into practical attacks). What can we do about this state of affairs? Preparing our applications and implementations for switchable functions, building our protocols on the basis of functionality rather than on specific algorithms (for example, define the protocol in terms of mac or prf instead of HMAC, and certainly not in terms of specific functions such as SHA2) and BUILD YOUR SECURITY/CRYPTO DESIGNS ON THE MINIMAL POSSIBLE ASSUMPTIONS ON THE UNDERLYING FUNCTIONS. HMAC's design is a good example of applying the latter principle and the reason HMAC has resisted all the recent attacks. Should we apply this principle again? Sure. Randomized hashing is the name of the (new) game when it comes to collision resistant hashing and signatures. Hugo > > Given that our preferred encryption algorithms are 112 and 128 bits > strong, exactly where should we worryabout using MD5 or SHA1 in > IPsec (other than in the PKIX part)? Of course, if someone uses > AES-192 or AES-256, they probably want to use SHA-256, but that's not > relevant here. > > >First, we do not know how fast > >attacks will improve and reach the point of being relevant even for uses > >such as in IKE. > > Let's assume that the collision-resistance attacks get very good very > quickly, such as reducing the collision-resistance of SHA-1 to 40 > bits, but the preimage resistance is unaffected. Would our > recommended hash functions change, and why? > > --Paul Hoffman, Director > --VPN Consortium > From hartmans@MIT.EDU Thu Dec 8 15:02:59 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB8K2x1r004056 for ; Thu, 8 Dec 2005 15:02:59 -0500 (EST) Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148])jB8K2p4U027997 for ; Thu, 8 Dec 2005 15:02:51 -0500 (EST) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 404F2E0070; Thu, 8 Dec 2005 15:02:45 -0500 (EST) To: Hugo Krawczyk Subject: Re: [saag] Structure of documents discussing protocols and hashes References: From: Sam Hartman Date: Thu, 08 Dec 2005 15:02:45 -0500 In-Reply-To: (Hugo Krawczyk's message of "Thu, 8 Dec 2005 21:04:57 +0200 (IST)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.631973 cc: IPsec WG cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 08 Dec 2005 20:03:00 -0000 >>>>> "Hugo" == Hugo Krawczyk writes: Hugo> See below Hugo> On Mon, 5 Dec 2005, Paul Hoffman wrote: >> At 9:52 PM +0200 12/5/05, Hugo Krawczyk wrote: >My view is that >> there is no need to RUSH into upgrading SHA-1 in >IKEv1 or >> v2. The only place where the recent attacks have a direct >> >relevance is in public key certificates. Other uses of hashes >> in IKE >(which include PRF, MAC, ephemeral signatures, and the >> randomness >extraction functionality referred to by David's >> mail) would have some >benefit from a hash function upgrade but >> nothing truly urgent. None of >these uses are based on >> collision resistance in some essential way. >Of course, new >> attacks, in particular on the pseudo-random properties of >> >secretly-keyed HMAC, could be found in the future (or maybe >> even in the >present), but such attacks to be of real >> significance will not be merely >collision attacks. >> >> The series of "hash evaluation" documents should give as >> specific numbers as possible. >> >> Here, you say "there is no need to RUSH" and "nothing truly >> urgent". Do we know of any collision-reduction attacks now >> that would cause any issues with IKE or IPsec? If not, why is >> there any need to amble, much less rush, towards new hash >> functions? Hugo> Even if the functions we use today are not yet broken in a Hugo> practical sense, what is broken is our confidence on these Hugo> functions, and we have to act on this "broken confidence". Hugo> The way to do it is NOT by trying to measure (quantify) Hugo> every day what is the latest best attack, but rather we Hugo> should take advantage of the fact that most applications are Hugo> currently NOT broken and prepare for a calm (but firm!) Hugo> transition to new functions. In this sense I am not Hugo> suggesting anything different than Belovin-Rescorla. As Hugo> Steve has recently put it: >> Per mine and ekr's paper, the problem is that we *can't* >> switch, even if a serious problem developed. What's really >> necessary now is to add the extra signaling, so that we can >> switch hash functions if and when that becomes necessary. I'd like to strongly agree. We'd like to have quantified results to guide our thinking. We don't have such results; we have educated intuition about the strengths of functions we are using. I think it would be irresponsible to ignore this intuition just as I think it irresponsible to panic. --Sam From mcr@sandelman.ottawa.on.ca Thu Dec 8 16:48:18 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB8LmH1r004897 for ; Thu, 8 Dec 2005 16:48:17 -0500 (EST) Received: from lists.sandelman.ca (cod.sandelman.ca [192.139.46.139]) jB8Lm73d009433 for ; Thu, 8 Dec 2005 16:48:10 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id jB8LlV218934 verified OK); Thu, 8 Dec 2005 16:47:37 -0500 (EST) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 5817D3AD9C; Thu, 8 Dec 2005 16:47:01 -0500 (EST) To: Hugo Krawczyk Subject: Re: [saag] Structure of documents discussing protocols and hashes In-Reply-To: Message from Hugo Krawczyk References: X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Thu, 08 Dec 2005 16:47:01 -0500 Message-ID: <15586.1134078421@sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.569507 cc: IPsec WG cc: Paul Hoffman cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 08 Dec 2005 21:48:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Hugo" == Hugo Krawczyk writes: Hugo> different than Belovin-Rescorla. As Steve has recently put Hugo> it: smb> Per mine and ekr's paper, the problem is that we *can't* switch, smb> even if a serious problem developed. What's really necessary now smb> is to add the extra signaling, so that we can switch hash smb> functions if and when that becomes necessary. Hugo> The counter-part of this switching problem is (paraphrasing Hugo> the above): "even when we'll be ready to switch we won't know Hugo> to WHAT to switch". That is, do not expect that we will be in Hugo> a situation where our confidence will be fully (or even My feeling is: pick something. SHA-256 is fine as a test case for testing the ability to switch. It might not be the right answer in 2010. I also continue to question if PRF uses are really affected. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBQ5ip04CLcPvd0N1lAQIC+Af+IZGmTCc82MFzYh+qtv4oc94rTnb26d8I I9SF+RdGdVqr7oUPr59X4rfakY2LEHMZTH+vSkmwL6REVGhGpkvqPrNfIvAcaoZq STCxWv7bhnHbuuOO9wRJ8LPWVe35FrjnHKmvkaW4Y/zWGas5OFoxJYt35ufqt8ln Xz/IM5WT/vc9bS0ihWPwPKLPMqQCdK6H1wNnp5AtyZc0/GhGJ1LLWo/gCcBMo15Y M5RkR5W/FPiAwpSNzfsmOAD6BVFhZqhye5oq0ina309umVecOv1cJ08G8Jtn2rct /dHfXWSAsktVNAi1kaAAWOFOXX91iOxL4239Nxf0z9sDWhAMa94ikA== =+LOT -----END PGP SIGNATURE----- From paul.hoffman@vpnc.org Thu Dec 8 18:03:41 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB8N3e1r005541 for ; Thu, 8 Dec 2005 18:03:41 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) jB8N3W3d004659 for ; Thu, 8 Dec 2005 18:03:33 -0500 (EST) Received: from [10.20.30.249] (dsl2-63-249-109-231.cruzio.com [63.249.109.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB8N3Obd072851; Thu, 8 Dec 2005 15:03:24 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 8 Dec 2005 15:02:19 -0800 To: IPsec WG , saag@mit.edu From: Paul Hoffman Subject: Re: [saag] Structure of documents discussing protocols and hashes Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.569352 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 08 Dec 2005 23:03:42 -0000 At 3:02 PM -0500 12/8/05, Sam Hartman wrote: >We'd like to have quantified results to guide our thinking. We don't >have such results; we have educated intuition about the strengths of >functions we are using. We have both. We now have quantified results that tell us that the two popular hash functions have much-weaker-than-expected collision-resistance. We have another related quantified result: the initial attacks on these functions were improved on in less than a year. We have educated intuition that these attacks will probably get better. >I think it would be irresponsible to ignore >this intuition just as I think it irresponsible to panic. Fully agree. But I don't see how the intuition affects the structure of of documents discussing protocols and hashes. - Our desire for agility in choosing all cryptographic functions to use is based on solid quantified understanding that sometimes a devastating attack is found. The reasons we need agility today are exactly the same as they were three years ago, before the current attacks were found; no intuition there. - We have quantified results that our earlier intuition about particular hash functions was wrong. We know for a fact that we should not to re-use the same intuition: we know we should look for things that don't match what we did before. Where did you want the intuition to come in here? --Paul Hoffman, Director --VPN Consortium From hugo@ee.technion.ac.il Thu Dec 8 18:29:08 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB8NT71r005758 for ; Thu, 8 Dec 2005 18:29:07 -0500 (EST) Received: from mailgw2.technion.ac.il (mailgw2.technion.ac.il [132.68.238.33]) jB8NSx3d000436 for ; Thu, 8 Dec 2005 18:28:59 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw2.technion.ac.il (Postfix) with ESMTP id 50681390246 for ; Fri, 9 Dec 2005 01:28:58 +0200 (IST) Received: from mailgw2.technion.ac.il ([127.0.0.1]) by localhost (mailgw2.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 24534-01-78 for ; Fri, 9 Dec 2005 01:28:58 +0200 (IST) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw2.technion.ac.il (Postfix) with ESMTP id 24A4639020D for ; Fri, 9 Dec 2005 01:28:57 +0200 (IST) Received: from ee.technion.ac.il (localhost [127.0.0.1]) jB8NV6dr003158; Fri, 9 Dec 2005 01:31:06 +0200 (IST) Received: from localhost (hugo@localhost)jB8NV0Jr003134; Fri, 9 Dec 2005 01:31:05 +0200 (IST) Date: Fri, 9 Dec 2005 01:31:00 +0200 (IST) From: Hugo Krawczyk To: Stephen Kent Subject: Re: [saag] Structure of documents discussing protocols and hashes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new at technion.ac.il X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.601905 cc: IPsec WG cc: Paul Hoffman cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 08 Dec 2005 23:29:09 -0000 On Thu, 8 Dec 2005, Stephen Kent wrote: > Hugo, > > I think it would be good to explore randomized hashing in the near > term (said the non-cryptographer).At a minimum it might be good to > develop RH-based integrity options for our various protocols, and see > what the performance and engineering implications are.Would you > envision using an hash algorithm like SHA-256 with randomization as a > pre-processing step? Exactly! And not only with SHA-256, but with any other existing or future hash function. I envision randomized hashing as a way to FREE digital signatures from their dependency on collision resistance (much like HMAC did for MAC functions) > That might be an especially attractive approach > for an interim hash function solution, given that NIST is likely to > suggest a near term transition to SHA-256. > As said, I do not see this just as an interim approach, but rather as a durable SAFETY NET for one of our most precious cryptographic tools: digital signatures. Now, while this approach does not require to change hash functions or to build dedicated hash functions, it does require a change of data encoding in digital signatures. This is not a trivial change but one we can afford (and well worth the insurance it buys us). Moreover, if we are going to clean up our protocols for better robustness to future attacks then we may well (personally, I'd say WE MUST) take the opporunity to upgrade the security of digital signatures (especially in applications with third-party verifiability such as certificates). This approach is explained in the now-expired draft draft-irtf-cfrg-rhash-00.txt which I re-posted now as http://www.ee.technion.ac.il/~hugo/draft-irtf-cfrg-rhash-00.txt Since its publication we have obtained very encouraging theoretical results backing the specific design outlined in the above draft. An academic paper with these results will be posted (I'll try to do it tomorrow) in http://www.ee.technion.ac.il/~hugo/rhash.pdf Comments are welcome. Hugo > Steve > From hugo@ee.technion.ac.il Fri Dec 9 18:53:15 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB9NrE1r015480 for ; Fri, 9 Dec 2005 18:53:14 -0500 (EST) Received: from mailgw2.technion.ac.il (mailgw2.technion.ac.il [132.68.238.33]) jB9Nr4VM015974 for ; Fri, 9 Dec 2005 18:53:05 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw2.technion.ac.il (Postfix) with ESMTP id E76C7390255 for ; Sat, 10 Dec 2005 01:53:03 +0200 (IST) Received: from mailgw2.technion.ac.il ([127.0.0.1]) by localhost (mailgw2.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 29532-02-23 for ; Sat, 10 Dec 2005 01:53:03 +0200 (IST) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw2.technion.ac.il (Postfix) with ESMTP id C9DB03901C2 for ; Sat, 10 Dec 2005 01:53:03 +0200 (IST) Received: from ee.technion.ac.il (localhost [127.0.0.1]) jB9NtGdr007667; Sat, 10 Dec 2005 01:55:16 +0200 (IST) Received: from localhost (hugo@localhost)jB9NtEYD007664; Sat, 10 Dec 2005 01:55:15 +0200 (IST) Date: Sat, 10 Dec 2005 01:55:14 +0200 (IST) From: Hugo Krawczyk To: Stephen Kent Subject: Re: [saag] Structure of documents discussing protocols and hashes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new at technion.ac.il X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.620456 cc: Paul Hoffman cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 09 Dec 2005 23:53:15 -0000 The paper on randomized hashing referred to below is now available from http://www.ee.technion.ac.il/~hugo/rhash.pdf Hugo On Fri, 9 Dec 2005, Hugo Krawczyk wrote: > > > On Thu, 8 Dec 2005, Stephen Kent wrote: > > > Hugo, > > > > I think it would be good to explore randomized hashing in the near > > term (said the non-cryptographer).At a minimum it might be good to > > develop RH-based integrity options for our various protocols, and see > > what the performance and engineering implications are.Would you > > envision using an hash algorithm like SHA-256 with randomization as a > > pre-processing step? > > Exactly!And not only with SHA-256, but with any other existing or future > hash function. I envision randomized hashing as a way to FREE digital > signatures from their dependency on collision resistance (much like HMAC > did for MAC functions) > > > That might be an especially attractive approach > > for an interim hash function solution, given that NIST is likely to > > suggest a near term transition to SHA-256. > > > > As said, I do not see this just as an interim approach, but rather > as a durable SAFETY NET for one of our most precious cryptographic > tools: digital signatures. > > Now, while this approach does not require to change hash functions or to > build dedicated hash functions, it does require a change of data encoding > in digital signatures. This is not a trivial change but one we can afford > (and well worth the insurance it buys us). Moreover, if we are going to > clean up our protocols for better robustness to future attacks then we > may well (personally, I'd say WE MUST) take the opporunity to upgrade the > security of digital signatures (especially in applications with > third-party verifiability such as certificates). > > This approach is explained in the now-expired draft > draft-irtf-cfrg-rhash-00.txt > which I re-posted now as > http://www.ee.technion.ac.il/~hugo/draft-irtf-cfrg-rhash-00.txt > > Since its publication we have obtained very encouraging theoretical > results backing the specific design outlined in the above draft. > Anacademic paper with these results will be posted (I'll try to do it > tomorrow) in > http://www.ee.technion.ac.il/~hugo/rhash.pdf > > Commentsare welcome. > > Hugo > > > Steve > > > > > From paul.hoffman@vpnc.org Fri Dec 16 15:52:29 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jBGKqSDt014929 for ; Fri, 16 Dec 2005 15:52:29 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) jBGKqJAV009680 for ; Fri, 16 Dec 2005 15:52:19 -0500 (EST) Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBGKqHLe082556 for ; Fri, 16 Dec 2005 12:52:18 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 16 Dec 2005 12:52:18 -0800 To: saag@mit.edu From: Paul Hoffman Subject: Re: [saag] Structure of documents discussing protocols and hashes Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.534587 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 16 Dec 2005 20:52:30 -0000 Greetings again. Thank you for all the response on the -00 draft. I have significantly revised it, and the -01 is available from . In this draft, Section 5 is all new, and it would be grand if folks could read it carefully. In it, I try to glean the basics from Eric and Steve's paper and come to conclusions about what should be done. I may have missed important parts (for that matter, so might they), and others might have different conclusions from what I got. Please let the lists know what you think. --Paul Hoffman, Director --VPN Consortium From housley@vigilsec.com Fri Dec 16 18:00:02 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jBGN01Dt015872 for ; Fri, 16 Dec 2005 18:00:01 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) jBGMxm7W005235 for ; Fri, 16 Dec 2005 17:59:48 -0500 (EST) Received: (qmail 7288 invoked by uid 0); 16 Dec 2005 22:59:40 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.162.215) by woodstock.binhost.com with SMTP; 16 Dec 2005 22:59:40 -0000 Message-Id: <7.0.0.10.2.20051216175710.06a9d988@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Fri, 16 Dec 2005 17:59:44 -0500 To: saag@mit.edu, cfrg@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.544114 Subject: [saag] Fwd: Comments requested on NIST Draft RNG Publication X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 16 Dec 2005 23:00:02 -0000 > Date: Fri, 16 Dec 2005 08:47:45 -0500 > From: Elaine Barker > Subject: Comments requested on NIST Draft RNG Publication > > A draft NIST Special Publication (Draft SP 800-90, Recommendation for > Random Number Generation Using Deterministic Random Bit Generators) is > available for public comment at > http://csrc.nist.gov/publications/drafts.html. Comments should be > submitted to ebarker@nist.gov by Wednesday, February 1, 2006. Please > place "Comments on SP 800-90" in the subject line. > > Elaine Barker > National Institute of Standards and Technology > 100 Bureau Drive, Stop 8930 > Gaithersburg, MD 20899-8930 > 301-975-2911 From garyhski@gmail.com Thu Dec 8 20:19:34 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jB91JX1r006486 for ; Thu, 8 Dec 2005 20:19:33 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) jB91JPZa000634 for ; Thu, 8 Dec 2005 20:19:26 -0500 (EST) Received: by wproxy.gmail.com with SMTP id i4so628572wra for ; Thu, 08 Dec 2005 17:19:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=EAR8ZILP9a7w3YrCtIxUnha3lN5L/c58HEsoCQwYztaiIucBCFKQ52myWTvpXbwnnVK3BQtqK9hnEDQ2mS5+9FxuAO6hDATdJ/jDDJkSV+51PzFKM0Sx+m4QObWmIWuAIqF5jtMJtF3FTFNRVGr9pSHCbwTZO4rTp0tSWmjeJvM= Received: by 10.54.135.3 with SMTP id i3mr2651421wrd; Thu, 08 Dec 2005 17:19:25 -0800 (PST) Received: by 10.54.160.20 with HTTP; Thu, 8 Dec 2005 17:19:25 -0800 (PST) Message-ID: <7bf3113b0512081719g2c869a2cy796066c98130a05c@mail.gmail.com> Date: Thu, 8 Dec 2005 18:19:25 -0700 From: Gary Hanyzewski To: saag@mit.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_16027_9902448.1134091165321" X-Spam-Score: -2.103 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.014820 Spam-Alum-Time: 0.541766 X-Mailman-Approved-At: Fri, 16 Dec 2005 18:14:02 -0500 Subject: [saag] IETF Open PGP broken link X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: garyh@patrec.com List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 09 Dec 2005 01:19:34 -0000 ------=_Part_16027_9902448.1134091165321 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline FYI, The "IETF Open PGP " link on the "IETF Security Area" webpage (http://web.mit.edu/network/ietf/sa/) is broken. It generates a "404 Access Denied" error. All other links on this page work. ------=_Part_16027_9902448.1134091165321 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline FYI,

The "IETF Open PGP&qu= ot; link on the "IETF Security Area" webpage (http://web.mit.edu/network= /ietf/sa/) is broken. It generates a "404 Access Denied" error.
All other links on this page work.

------=_Part_16027_9902448.1134091165321-- From warlord@MIT.EDU Fri Dec 16 18:18:53 2005 Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jBGNIqDt016081 for ; Fri, 16 Dec 2005 18:18:52 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) jBGNIkOE025800; Fri, 16 Dec 2005 18:18:47 -0500 (EST) Received: from w92-130-webmail-6.mit.edu (W92-130-WEBMAIL-6.MIT.EDU [18.7.22.137]) ) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id jBGNISgf015006; Fri, 16 Dec 2005 18:18:28 -0500 (EST) Received: (from nobody@localhost) by w92-130-webmail-6.mit.edu (8.12.4) id jBGNISXT019954; Fri, 16 Dec 2005 18:18:28 -0500 Received: from 69-172-168-140.atlsfl.adelphia.netauthenticatedwith HTTP for ; Fri, 16 Dec 2005 18:18:28 -0500 Message-ID: <20051216181828.deltmndpgidc0kg0@webmail.mit.edu> Date: Fri, 16 Dec 2005 18:18:28 -0500 From: Derek Atkins To: garyh@patrec.com, Gary Hanyzewski Subject: Re: [saag] IETF Open PGP broken link References: <7bf3113b0512081719g2c869a2cy796066c98130a05c@mail.gmail.com> In-Reply-To: <7bf3113b0512081719g2c869a2cy796066c98130a05c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000002 Spam-Alum-Time: 0.708575 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 16 Dec 2005 23:18:53 -0000 Quoting Gary Hanyzewski : > FYI, > > The "IETF Open PGP " link on the "IETF > Security Area" webpage (http://web.mit.edu/network/ietf/sa/) is broken. It > generates a "404 Access Denied" error. > All other links on this page work. Indeed, it should be ietf-openpgp, not ietf-open-pgp. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From hartmans@MIT.EDU Mon Dec 19 20:19:54 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jBK1JrDt011791 for ; Mon, 19 Dec 2005 20:19:53 -0500 (EST) Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178])jBK1JiBJ016299 for ; Mon, 19 Dec 2005 20:19:45 -0500 (EST) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 18EECE0075; Mon, 19 Dec 2005 20:19:37 -0500 (EST) To: garyh@patrec.com Subject: Re: [saag] IETF Open PGP broken link References: <7bf3113b0512081719g2c869a2cy796066c98130a05c@mail.gmail.com> From: Sam Hartman Date: Mon, 19 Dec 2005 20:19:37 -0500 In-Reply-To: <7bf3113b0512081719g2c869a2cy796066c98130a05c@mail.gmail.com> (Gary Hanyzewski's message of "Thu, 8 Dec 2005 18:19:25 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.352 X-Spam-Level: * (1.352) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000231 Spam-Alum-Time: 0.522076 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 20 Dec 2005 01:19:54 -0000 >>>>> "Gary" == Gary Hanyzewski writes: Gary> FYI, The "IETF Open PGP" link on the "IETF Security Area" Gary> webpage (http:// web.mit.edu/network/ietf/sa/) is broken. It Gary> generates a "404 Access Denied" error. All other links on Gary> this page work. Where did you find a link to this page from? --Sam From garyhski@gmail.com Tue Dec 20 10:54:24 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jBKFsNDt018009 for ; Tue, 20 Dec 2005 10:54:23 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) jBKFsDa8014896 for ; Tue, 20 Dec 2005 10:54:14 -0500 (EST) Received: by wproxy.gmail.com with SMTP id i21so1231109wra for ; Tue, 20 Dec 2005 07:54:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:sender; b=T/YED9fLjIZuqm9UIMmNCPtz0+MT20YbdEXEjAlQNTewdxsvOiyyUX6osof4Sq7tZk2tufBSipFZfyNArgNgAcoGiWUpJ71oSyJN64fRN+ZAkMi2BpDWixBcNmdVBNVOSkp4QIAht1lis6A31tT7MLxC70/5ajDHiYWg7Pp/2C0= Received: by 10.65.183.7 with SMTP id k7mr4287421qbp; Tue, 20 Dec 2005 07:54:13 -0800 (PST) Received: from ?192.168.1.101? ( [67.51.100.6]) by mx.gmail.com with ESMTP id e13sm3412060qba.2005.12.20.07.54.11; Tue, 20 Dec 2005 07:54:12 -0800 (PST) Message-ID: <43A8291A.1000309@patrec.com> Date: Tue, 20 Dec 2005 08:54:02 -0700 From: Gary Hanyzewski User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman Subject: Re: [saag] IETF Open PGP broken link References: <7bf3113b0512081719g2c869a2cy796066c98130a05c@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: Gary Hanyzewski X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000147 Spam-Alum-Time: 0.522343 X-Mailman-Approved-At: Tue, 20 Dec 2005 11:12:42 -0500 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list Reply-To: garyh@patrec.com List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 20 Dec 2005 15:54:24 -0000 Probably one of the search engines (google?). I was doing research on public key encryption . Sam Hartman wrote: >>>>>>"Gary" == Gary Hanyzewski writes: >>>>>> >>>>>> > > Gary> FYI, The "IETF Open PGP" link on the "IETF Security Area" > Gary> webpage (http:// web.mit.edu/network/ietf/sa/) is broken. It > Gary> generates a "404 Access Denied" error. All other links on > Gary> this page work. > >Where did you find a link to this page from? > > >--Sam > > > From warlord@MIT.EDU Tue Dec 20 11:55:13 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jBKGtCDt018494 for ; Tue, 20 Dec 2005 11:55:12 -0500 (EST) Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) jBKGsxa8029145; Tue, 20 Dec 2005 11:54:59 -0500 (EST) Received: from cliodev.pgp.com (69-172-168-140.atlsfl.adelphia.net [69.172.168.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id 50DAABD842F; Tue, 20 Dec 2005 11:54:59 -0500 (EST) Received: (from warlord@localhost) by cliodev.pgp.com (8.13.1/8.13.1/Submit) id jBKGsmJT004341; Tue, 20 Dec 2005 11:54:48 -0500 From: Derek Atkins To: Sam Hartman Subject: Re: [saag] IETF Open PGP broken link References: <7bf3113b0512081719g2c869a2cy796066c98130a05c@mail.gmail.com> Date: Tue, 20 Dec 2005 11:54:48 -0500 In-Reply-To: (Sam Hartman's message of "Mon, 19 Dec 2005 20:19:37 -0500") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.352 X-Spam-Level: * (1.352) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000128 Spam-Alum-Time: 0.535998 cc: garyh@patrec.com cc: saag@MIT.EDU X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 20 Dec 2005 16:55:14 -0000 Sam Hartman writes: >>>>>> "Gary" == Gary Hanyzewski writes: > > Gary> FYI, The "IETF Open PGP" link on the "IETF Security Area" > Gary> webpage (http:// web.mit.edu/network/ietf/sa/) is broken. It > Gary> generates a "404 Access Denied" error. All other links on > Gary> this page work. > > Where did you find a link to this page from? My first guess is "google" > --Sam -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From hartmans@MIT.EDU Tue Dec 20 13:09:44 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jBKI9hDt019100 for ; Tue, 20 Dec 2005 13:09:43 -0500 (EST) Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178])jBKI9eTH006733 for ; Tue, 20 Dec 2005 13:09:40 -0500 (EST) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id E8538E0070; Tue, 20 Dec 2005 13:09:34 -0500 (EST) To: garyh@patrec.com Subject: Re: [saag] IETF Open PGP broken link References: <7bf3113b0512081719g2c869a2cy796066c98130a05c@mail.gmail.com> <43A8291A.1000309@patrec.com> From: Sam Hartman Date: Tue, 20 Dec 2005 13:09:34 -0500 In-Reply-To: <43A8291A.1000309@patrec.com> (Gary Hanyzewski's message of "Tue, 20 Dec 2005 08:54:02 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.352 X-Spam-Level: * (1.352) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.594948 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 20 Dec 2005 18:09:45 -0000 >>>>> "Gary" == Gary Hanyzewski writes: Gary> Probably one of the search engines (google?). I was doing Gary> research on public key encryption . Gary> Sam Hartman wrote: >>>>>>> "Gary" == Gary Hanyzewski writes: >>>>>>> >>>>>>> >> Gary> FYI, The "IETF Open PGP" link on the "IETF Security Area" Gary> webpage (http:// web.mit.edu/network/ietf/sa/) is broken. It Gary> generates a "404 Access Denied" error. All other links on Gary> this page work. >> Where did you find a link to this page from? >> >> >> --Sam >> >> >> OK. That's an out of date link. Take a look at http://sec.ietf.org. That is also broken but at least I can (and will) fix it. From jis@MIT.EDU Tue Dec 20 15:03:48 2005 Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jBKK3lDt019894 for ; Tue, 20 Dec 2005 15:03:47 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) jBKK3gwF023216; Tue, 20 Dec 2005 15:03:42 -0500 (EST) Received: from [192.168.94.131] (JISVPN.MIT.EDU [18.100.101.102]) (authenticated bits=0) (User authenticated as jis5@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id jBKK3M8o024185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Dec 2005 15:03:34 -0500 (EST) Message-ID: <43A86365.6070902@mit.edu> Date: Tue, 20 Dec 2005 15:02:45 -0500 From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman Subject: Re: [saag] IETF Open PGP broken link References: <7bf3113b0512081719g2c869a2cy796066c98130a05c@mail.gmail.com> <43A8291A.1000309@patrec.com> In-Reply-To: X-Enigmail-Version: 0.92.0.0 OpenPGP: id=F414952B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000005 Spam-Alum-Time: 0.523915 cc: garyh@patrec.com cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 20 Dec 2005 20:03:49 -0000 http://web.mit.edu/network/sa now redirects to http://sec.ietf.org. -Jeff -- ============================================================================= Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu ============================================================================ From songyi@huawei.com Wed Dec 28 04:23:41 2005 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jBS9NesL023921 for ; Wed, 28 Dec 2005 04:23:40 -0500 (EST) Received: from huawei.com (szxga02-in.huawei.com [61.144.161.54]) jBS9NNsj021504 for ; Wed, 28 Dec 2005 04:23:27 -0500 (EST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IS700KCJBX5EF@szxga02-in.huawei.com> for saag@mit.edu; Wed, 28 Dec 2005 17:34:17 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IS700I5VBX5KS@szxga02-in.huawei.com> for saag@mit.edu; Wed, 28 Dec 2005 17:34:17 +0800 (CST) Received: from s45414 ([10.70.67.70]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IS7006ZGC2QN4@szxml01-in.huawei.com> for saag@mit.edu; Wed, 28 Dec 2005 17:37:38 +0800 (CST) Date: Wed, 28 Dec 2005 17:23:22 +0800 From: songyi To: saag@mit.edu Message-id: <000c01c60b90$591a4d90$4643460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: multipart/alternative; boundary="Boundary_(ID_XFcVQkuvknIOUlu1u+7eww)" X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 1.495 X-Spam-Level: * (1.495) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000009 Spam-Alum-Time: 0.563213 Subject: [saag] Help X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 28 Dec 2005 09:23:42 -0000 This is a multi-part message in MIME format. --Boundary_(ID_XFcVQkuvknIOUlu1u+7eww) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi all I have a simple question about authentication.If you could spend your time to read my email,I would appreciate you much.If this letter disturbed you, I'll appologize for that. My question is about RADIUS(Remote Authentication Dial In User Service).I have read the RFC2865,and RFC2138.In these protocols, the RADIUS are in Client/Server Model.And there are Client,RADIUS server and proxy client.Now,my question is when there are messages transfered between proxy client and RADIUS server or between proxy clients,how to ensure the security of these messages?Is there any shared keys in the RADIUS server and proxy clients.And the messages are encrypted by these keys.And if so,how could these keys produced, and what's the lifetime of these keys and how to refresh these keys?Or is there any other methods to ensure the message transfered between proxy clients and between proxy client and RADIUS server?If the method is complex and hard to explain in a few words,could you please tell me where I can find the documents or protocols about these aspects? Thanks a lot! --Boundary_(ID_XFcVQkuvknIOUlu1u+7eww) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi all
   I have a simple question about authentication.If you could spend your time to read my email,I would appreciate you much.If this letter disturbed you, I'll appologize for that.
   My question is about RADIUS(Remote Authentication Dial In User Service).I have read the RFC2865,and RFC2138.In these protocols, the RADIUS are in Client/Server Model.And there are Client,RADIUS server and proxy client.Now,my question is when there are messages transfered between proxy client and RADIUS server or between proxy clients,how to ensure the security of these messages?Is there any shared keys in the RADIUS server and proxy clients.And the messages are encrypted by these keys.And if so,how could these keys produced, and what's the lifetime of these keys and how to refresh these keys?Or is there any other methods to ensure the message transfered between proxy clients and between proxy client and RADIUS server?If the method is complex and hard to explain in a few words,could you please tell me where I can find the documents or protocols about these aspects?
Thanks a lot!
--Boundary_(ID_XFcVQkuvknIOUlu1u+7eww)-- From jari.arkko@piuha.net Wed Dec 28 05:39:49 2005 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id jBSAdmsL024435 for ; Wed, 28 Dec 2005 05:39:48 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) jBSAddrE023027 for ; Wed, 28 Dec 2005 05:39:40 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id BD66D898BA; Wed, 28 Dec 2005 12:39:38 +0200 (EET) Message-ID: <43B26B21.6070507@piuha.net> Date: Wed, 28 Dec 2005 12:38:25 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: songyi Subject: Re: [saag] Help References: <000c01c60b90$591a4d90$4643460a@china.huawei.com> In-Reply-To: <000c01c60b90$591a4d90$4643460a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.636298 cc: saag@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1 Precedence: list List-Id: IETF Security Area Advisory Group List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 28 Dec 2005 10:39:49 -0000 Hi, > I have a simple question about authentication.If you could spend your > time to read my email,I would appreciate you much.If this letter > disturbed you, I'll appologize for that. No problem. Feel free to ask. > My question is about RADIUS(Remote Authentication Dial In User > Service).I have read the RFC2865,and RFC2138.In these protocols, the > RADIUS are in Client/Server Model.And there are Client,RADIUS server > and proxy client.Now,my question is when there are messages transfered > between proxy client and RADIUS server or between proxy clients,how to > ensure the security of these messages?Is there any shared keys in the > RADIUS server and proxy clients.And the messages are encrypted by > these keys.And if so,how could these keys produced, and what's the > lifetime of these keys and how to refresh these keys?Or is there any > other methods to ensure the message transfered between proxy clients > and between proxy client and RADIUS server?If the method is complex > and hard to explain in a few words,could you please tell me where I > can find the documents or protocols about these aspects? RADIUS communications are typically protected with a shared secret, applied in a hop-by-hop fashion. That is, the NAS and a proxy RADIUS server share a secret and then there's another shared secret between the proxy RADIUS server and the home RADIUS server. Such keys are manually configured and typically remain in effect until manually reconfigured. The actual protection on a RADIUS packet is fairly weak, its based on MD5 (not even with HMAC) and mostly only for integrity, not for confidentiality. See details from RFC 2865 Section 3. It is also possible to employ an outer layer of protection on RADIUS through IPsec. The details are in RFC 3579, Section 4.2, but as far as I know this isn't very widely used in RADIUS deployments. This will provide key lifetimes, key refresh, algorithm negotiation, etc. The protection is hop-by-hop, i.e., the SAs terminate in the proxy server. The other IETF AAA protocol, Diameter, uses only "outer layer protection", which in most cases in Diameter is TLS. See RFC 3588 for the details. This provides roughly the same properties as the IPsec protection as well as offering application-level granularity in the configuration of policies and trusted peers. There has also been past work in end-to-end protection of communication through AAA proxies, but this work was abandoned due to lack of interest, and (I suspect) mismatch with business policies and practises that require both examination and even modification of some of the authorization parameters passed in these transactions. However, recent work such as RFC 4005 recommends a different approach to securing AAA via proxies, by allowing a "redirect" to take place so that the sensitive information can bypass the proxies. But it is unclear again whether this mode is being employed in practical deployments. Finally, there has been some past work on providing better automation for setting up the shared secrets. See draft-moskowitz-shared-secret- provprotocol-01.txt, for instance. The RADEXT WG mailing may be a good place for further discussions. Hope this helps, --Jari