From hartmans@MIT.EDU Wed Jan 3 20:28:51 2007 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l041Sm3I026566 for ; Wed, 3 Jan 2007 20:28:48 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id l041Sg3A027765 for ; Wed, 3 Jan 2007 20:28:43 -0500 (EST) Received: from carter-zimmerman.mit.edu (STRATTON-ONE-SIXTEEN.MIT.EDU [18.187.5.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 90A6C189CD1 for ; Wed, 3 Jan 2007 20:28:42 -0500 (EST) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 52D54E00B4; Wed, 3 Jan 2007 20:28:42 -0500 (EST) To: saag@MIT.EDU From: Sam Hartman Message-Id: <20070104012842.52D54E00B4@carter-zimmerman.mit.edu> Date: Wed, 3 Jan 2007 20:28:42 -0500 (EST) X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: kitten@ietf.org, ietf-sasl@imc.org, tls@ietf.org Subject: [saag] Writing Help with draft-williams-on-channel-binding X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2007 01:28:51 -0000 There was a lively discussion here of draft-williams-on-channel-binding. After revising the draft based on comments received, Nico has submitted it for publication. I've sent him some minor AD review comments; once he addresses them I think the document will be ready for last call. However, I think we could make it significantly better. The problem is that several of us have been thinking about channel binding for the last couple of years. We've got it stuck in our minds. The current draft speaks well to what we're looking for. However it isn't as good of an introduction to the concept as it could be. It does a good job of specifying requirements for channel binding values and mechanisms that use channel binding. Is there someone out there who is a reasonably good writer but who has not been heavily involved in the channel binding discussion who would be willing to commit some significant time over the next month or so to understand and improve the draft? If you would be interested please let Nico and I know. From housley@vigilsec.com Tue Jan 16 10:47:15 2007 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l0GFlFSX028728 for ; Tue, 16 Jan 2007 10:47:15 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id l0GFl7Yh004107 for ; Tue, 16 Jan 2007 10:47:07 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by mit.edu (Spam Firewall) with SMTP id 38C591BEF07 for ; Tue, 16 Jan 2007 10:47:05 -0500 (EST) Received: (qmail 32527 invoked by uid 0); 16 Jan 2007 15:47:02 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.157) by woodstock.binhost.com with SMTP; 16 Jan 2007 15:47:02 -0000 Message-Id: <7.0.0.16.2.20070116094334.04029c48@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 16 Jan 2007 09:43:57 -0500 To: saag@mit.edu From: IESG Secretary (by way of Russ Housley ) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.13 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] WG Review: Provisioning of Symmetric Keys (keyprov) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 15:47:16 -0000 A new IETF working group has been proposed in the Security Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by January 22nd. +++ Provisioning of Symmetric Keys (keyprov) ========================================= Current Status: Proposed Working Group Chair(s): TBD Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Russ Housley Mailing Lists: General Discussion: ietf-keyprov@safehaus.org To Subscribe: http://www.safehaus.org/mailman/listinfo/ietf-keyprov Archive: http://www.safehaus.org/pipermail/ietf-keyprov/ Background ---------- Current developments in deployment of Shared Symmetric Key (SSK) tokens have highlighted the need for a standard protocol for provisioning symmetric keys. The need for provisioning protocols in PKI architectures has been recognized for some time. Although the existence and architecture of these protocols provides a feasibility proof for the KEYPROV work assumptions built into these protocols mean that it is not possible to apply them to symmetric key architectures without substantial modification. In particular the ability to provision symmetric keys and associated attributes dynamically to already issued devices such as cell phones and USB drives is highly desirable. The working group will develop the necessary protocols and data formats required to support provisioning and management of symmetric key authentication tokens, both proprietary and standards based. Input Documents --------------- The following Internet drafts have been proposed by their authors as input documents: * Dynamic Symmetric Key Provisioning Protocol (M. Pei, S. Machani) * Portable Symmetric Key Container (A. Vassilev, J. Martinsson, M. Pei, P. Hoyer, S. Machani) * Extensions to CT-KIP to support one- and two-pass key initialization (M. Nystroem, S. Machani) Scope and Deliverables ---------------------- The scope of the working group shall be to define protocols and data formats necessary for provisioning of symmetric cryptographic keys and associated attributes. The group shall consider use cases related to use of Shared Symmetric Key Tokens. Other use cases may be considered for the purpose of avoiding unnecessary restrictions in the design and ensure the potential for future extensibility. The working group will produce the following deliverables: * Portable Symmetric Key Container * Dynamic Symmetric Key Provisioning Protocol Milestones ---------- June 2007 WG Last Call Portable Symmetric Key Container June 2007 WG Last Call Dynamic Symmetric Key Provisioning Protocol August 2007 IETF Last Call Portable Symmetric Key Container August 2007 IETF Last Call Dynamic Symmetric Key Provisioning Protocol Jan 2008 Complete implementation and interoperability tests June 2008 WG documents to DRAFT Standard Status From housley@vigilsec.com Wed Jan 17 10:02:39 2007 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l0HF2d5Q016870 for ; Wed, 17 Jan 2007 10:02:39 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id l0HF2P7a008502 for ; Wed, 17 Jan 2007 10:02:26 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by mit.edu (Spam Firewall) with SMTP id F3EEF18C798 for ; Wed, 17 Jan 2007 10:02:18 -0500 (EST) Received: (qmail 12128 invoked by uid 0); 17 Jan 2007 15:02:15 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.157) by woodstock.binhost.com with SMTP; 17 Jan 2007 15:02:15 -0000 Message-Id: <7.0.0.16.2.20070117095212.04035c38@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 17 Jan 2007 10:02:14 -0500 To: ipsec@ietf.org, saag@mit.edu, ietf@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] MUST implement AES-CBC for IPsec ESP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 15:02:39 -0000 During the IETF Last Call for draft-manral-ipsec-rfc4305-bis-errata, we received a comment that deserves wide exposure. For ESP encryption algorithms, the document that was sent out for Last Call contains the following table: Requirement Encryption Algorithm (notes) ----------- -------------------- MUST NULL (1) MUST- TripleDES-CBC [RFC2451] SHOULD+ AES-CBC with 128-bit keys [RFC3602] SHOULD AES-CTR [RFC3686] SHOULD NOT DES-CBC [RFC2405] (3) The Last Call comment suggests changing the "SHOULD+" for AES-CBC to "MUST." I support this proposed change, and I have asked the author to make this change in the document that will be submitted to the IESG for consideration on the Telechat on January 25th. If anyone has an objection to this change, please speak now. Please send comments on this proposed change to the iesg@ietf.org or ietf@ietf.org mailing lists by 2007-01-24. Russ Housley Security AD From flefauch@cisco.com Fri Jan 19 09:14:52 2007 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l0JEEoU7006439 for ; Fri, 19 Jan 2007 09:14:50 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id l0JEEf6i022820 for ; Fri, 19 Jan 2007 09:14:41 -0500 (EST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by mit.edu (Spam Firewall) with ESMTP id 45CBF1D25B5; Fri, 19 Jan 2007 09:14:37 -0500 (EST) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 Jan 2007 15:14:36 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0JEEaWd002239; Fri, 19 Jan 2007 15:14:36 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0JEEVC8012942; Fri, 19 Jan 2007 15:14:31 +0100 (MET) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 15:14:31 +0100 Received: from [10.0.0.7] ([10.61.81.126]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 15:14:28 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/alternative; boundary=Apple-Mail-17--247430743 Message-Id: <8C6C7C18-184C-41F5-940D-6FFCF4C071AA@cisco.com> From: Francois Le Faucheur IMAP Date: Fri, 19 Jan 2007 06:50:13 +0100 To: Black_David@emc.com X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 19 Jan 2007 14:14:28.0793 (UTC) FILETIME=[21B47A90:01C73BD4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=30916; t=1169216076; x=1170080076; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[saag]=20tsvwg, preemption=20and=20rsvp=3A=20exposing= 20characteristics=20of=20confidentialtraffic |Sender:=20; bh=gCqv1EZx4z82aFu/b/NHmy7SQgo5QyhDAqwzUer9GLA=; b=RvVZJ7QstaevpqXfaQzOFSu3Ci3xcKSYgeuvcnXROD9zYY660eYeMuWEqXIsXDbFzGFokLYy v2aV2uoYcnEV3laMP0tlqlSsNlNNgaBGTwPIX3YzpTDShvXbr0rJF/S0; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 1.01 X-Spam-Level: * (1.01) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: ipsec@ietf.org, Francois Le Faucheur IMAP , pratik.bose@lmco.com, fred@cisco.com, saag@mit.edu, hartmans-ietf@mit.edu, tsvwg-chairs@tools.ietf.org Subject: Re: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 14:14:53 -0000 --Apple-Mail-17--247430743 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello David, Please see below: On 29 Dec 2006, at 19:00, Black_David@emc.com wrote: > Francois, > > > Do you agree that RFC 3175 allows use of AF? > > Yes - the fact that it deliberately did not put in a full PHB-ID is > unfortunate, > as having to infer from context whether a DSCP is a singleton vs. > representative > of a group from context is not the best approach. It looks like I > missed > this AF support in quickly scanning RFC 3175. > > > With respect to rsvp-ipsec, a simple approach is to edit the > description text of the "DSCP" field in the > > GENERIC-AGGREGATE SESSION object along the lines of what is in > RFC 3175 (ie if session uses > > single PHB, then field contains the DSCP of PHB. If session uses > group of PHBs like AF1x, then field > > contains the numerically smallest DSCP value as per [PHB-ID]). > This would make it explicit that > > rsvp-ipsec also allows use of PHB groups, and would ensure > consistent use of DSCP field between > > RFC 3175 and rsvp-ipsec. > > That's probably the right thing to do at this juncture, because ... > > > The other approach would be to change the format of the GENERIC- > AGGREGATE SESSION object > > and include a full 16-bit PHB-ID instead of DSCP field. I can see > that this could help in situations where > > (i) the Aggregate reservation crosses Diffserv domain boundaries > and (ii) different DSCP values are used > > for a given PHB/PHB-group. But I am not sure that this would be a > common situation. On the flip side, > > it would make things less consistent between RFC 3175 and rsvp- > ipsec (for example, in cases where the > > operator has elected to use a DSCP for the PHB which is different > from the recommended DSCP value, > > then RFC 3175 would encode the used-DSCP while rsvp-ipsec would > encode the recommended-DSCP > > as per PHB-ID). > > ... probably entails going back and changing RFC 3175 to use a PHB- > ID, something > that it's probably entirely too late to do, and I agree that a > divergence between > RFC 3175 and rsvp-ipsec is undesirable. Thinking this over, I now have a marked preference for the second approach (ie change the GENERIC-AGGREGATE-SESSION object format to include PHB-ID instead of DSCP). Despite that fact it is "the right thing to do", my main argument is that this is required to be able to operate in a scenario where the Aggregate RSVP reservation would span two Diffserv domains which happen to use different DSCP markings for the same PHB (or PHB-group). The object would look like this: 0 7 8 15 16 23 24 31 +-------------+-------------+-------------+-------------+ | IPv4 DestAddress (4 bytes) | +-------------+-------------+-------------+--+----------+ | Reserved | Flags | vDstPort |Rd | +-------------+-------------+-------------+--+----------+ | PHB-ID | Reserved | +-------------+-------------+-------------+-------------+ | Extended vDstPort | +-------------+-------------+-------------+-------------+ I don't think we need to change RFC3175. In fact, the objective of the Generic Aggregate I-D is to remove restrictions of RFC3175. This is just one more restriction of RFC3175 that we remove. I think ultimately the Generic Aggregate I-D will effectively supersede RFC3175. Does this work for you ? Cheers Francois > > > BTW: One related question on PHB-ID. PHB-ID says " Note that the > recommended DSCP value MUST > > be used, even if the network in question has chosen a different > mapping." So what happens if someone wants > > to deploy two instances of EF? how do you encode those in a PHB-ID? > > The second EF instance would be a case 2 PHB-ID - experimental or > local use. > The current PHB-ID reference is RFC 3140. > > One of the things I think we're discovering (e.g., w/Fred's > admitted-voice PHB) > is that EF instances aren't completely combinable in practice - in > theory they're > completely combinable, and hence one never needs more than one, > *if* the rules > are followed perfectly. That "if" doesn't appear to completely > hold in practice. > > Thanks, > --David > > > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] > Sent: Friday, December 29, 2006 5:01 AM > To: Black, David > Cc: Francois Le Faucheur IMAP; hartmans-ietf@MIT.EDU; saag@MIT.EDU; > ipsec@ietf.org; tsvwg-chairs@tools.ietf.org; fred@cisco.com; > pratik.bose@lmco.com > Subject: Re: [saag] tsvwg,preemption and rsvp: exposing > characteristics of confidentialtraffic > > Hello David, > > Now I understand your concern. Please see below: > > On 28 Dec 2006, at 22:44, Black_David@emc.com wrote: > >> Francois, >> >> My general concern for the draft is: >> >>>> The concern about how to use a PHB consisting of multiple DSCPs >> (e.g., AF) >>>> also applies to the rsvp-ipsec draft. Using PHBIDs (cf. RFC 3140) >> may >>>> help address this, and this concern may also affect RFC 3175. >> >> For example, this sentence from the Introduction (Section 1) applies >> to EF, but not AF for carrying the reserved traffic: >> >> One example is where E2E reservations using >> different preemption priorities (as per [RSVP-PREEMP]) need to be >> aggregated through a Diffserv cloud using the same DSCP. >> >> The underlying situation is that the raw notion of DSCP is being used >> instead of a PHB, and for better or worse, this is already the case >> in RFC 3175. The practical upshot is that RFC 3175 effectively >> forbids >> use of AF PHBs for carrying reserved traffic - > > Actually, RFC 3175 explicitly (attempts to) allow(s) the use of AF > PHBs for carrying reserved traffic. > In particular, it says: > " > In the case where a session uses a pair of PHBs (e.g., AF11 > and AF12), the DSCP used should represent the numerically smallest > PHB (e.g., AF11). This follows the same naming convention > described > in [BRIM]. > ... > > [BRIM] Brim, S., Carpenter, B. and F. LeFaucheur, "Per Hop > Behavior Identification Codes", RFC 2836, May 2000. > " > > Do you agree that RFC 3175 allows use of AF? > > >> one has to explicitly >> specify the DSCP (which could also be used as part of an AF PHB if >> one was being careful). Going back and changing RFC 3175 at this >> point is definitely *not* a good idea, so I would suggest just making >> this observation (RFC 3175 requires use of a single DSCP for traffic >> aggregated into a single reservation) in the rsvp-ipsec draft and >> observing that this forbids meaningful use of AF drop precedence >> for traffic covered by an RSVP reservation. > > With respect to rsvp-ipsec, a simple approach is to edit the > description text of the "DSCP" field in the GENERIC-AGGREGATE > SESSION object along the lines of what is in RFC 3175 (ie if > session uses single PHB, then field contains the DSCP of PHB. If > session uses group of PHBs like AF1x, then field contains the > numerically smallest DSCP value as per [PHB-ID]). This would make > it explicit that rsvp-ipsec also allows use of PHB groups, and > would ensure consistent use of DSCP field between RFC 3175 and rsvp- > ipsec. > > The other approach would be to change the format of the GENERIC- > AGGREGATE SESSION object and include a full 16-bit PHB-ID instead > of DSCP field. I can see that this could help in situations where > (i) the Aggregate reservation crosses Diffserv domain boundaries > and (ii) different DSCP values are used for a given PHB/PHB-group. > But I am not sure that this would be a common situation. On the > flip side, it would make things less consistent between RFC 3175 > and rsvp-ipsec (for example, in cases where the operator has > elected to use a DSCP for the PHB which is different from the > recommended DSCP value, then RFC 3175 would encode the used-DSCP > while rsvp-ipsec would encode the recommended-DSCP as per PHB-ID). > > Thoughts? > > BTW: One related question on PHB-ID. PHB-ID says " Note that the > recommended DSCP value MUST be used, even if the network in > question has chosen a different mapping." So what happens if > someone wants to deploy two instances of EF? how do you encode > those in a PHB-ID? > > Cheers > > Francois > > >> >> Thanks, >> --David >> ---------------------------------------------------- >> David L. Black, Senior Technologist >> EMC Corporation, 176 South St., Hopkinton, MA 01748 >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >> black_david@emc.com Mobile: +1 (978) 394-7754 >> ---------------------------------------------------- --Apple-Mail-17--247430743 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hello David,

Please see = below:

On 29 Dec 2006, at 19:00, Black_David@emc.com = wrote:

Francois,
=A0
> Do you agree that = RFC 3175 allows use of AF?
=A0
Yes - the fact that it deliberately did = not put in a full PHB-ID is unfortunate,
as having to infer from context whether = a DSCP is a singleton vs. representative
of a group from = context is not the best approach.=A0 It looks like I = missed
this = AF support in quickly scanning RFC 3175.
=A0
> With respect to rsvp-ipsec, a simple = approach is to edit the description text of the "DSCP" field in = the
> GENERIC-AGGREGATE SESSION = object along the lines of what is in RFC 3175 (ie if session = uses
> single PHB, then field contains the = DSCP of PHB. If session uses group of PHBs like AF1x, then = field
> contains the numerically smallest DSCP = value as per [PHB-ID]). This would make it explicit that
=
> = rsvp-ipsec also allows use of PHB groups, and would ensure consistent = use of DSCP field between
> RFC 3175 and = rsvp-ipsec.
=A0
That's = probably the right thing to do at this juncture, because = ...
=A0
> The other approach would be to change = the format of the=A0GENERIC-AGGREGATE = SESSION=A0object
> and include a = full 16-bit PHB-ID instead of DSCP field. I can see that this could help = in situations where
> (i) the Aggregate reservation crosses = Diffserv domain boundaries and (ii) different DSCP values are = used
> for a given PHB/PHB-group. But I am = not sure that this would be a common situation. On the flip = side,
> it would make things less consistent = between RFC 3175 and rsvp-ipsec (for example, in cases where = the
> operator has elected to use a DSCP for = the PHB which is different from the recommended DSCP value,
=
> = then RFC 3175=A0would encode the used-DSCP while rsvp-ipsec would encode = the recommended-DSCP
> as per PHB-ID).
=A0
... probably entails going back and changing RFC 3175 to = use a PHB-ID, something
that it's probably entirely too late to do, and I agree = that a divergence between
RFC 3175 and rsvp-ipsec is = undesirable.

Thinking this over, I now = have a marked preference for the second approach (ie change the = GENERIC-AGGREGATE-SESSION object format to include PHB-ID instead of = DSCP). Despite that fact it is "the right thing to do", my main argument = is that this is required to be able to operate in a scenario where the = Aggregate RSVP reservation would span two Diffserv domains which happen = to use different DSCP markings for the same PHB (or = PHB-group).=A0

The object would look like = this:

=A0 =A0=A0 =A0=A0 =A0=A0 =A00=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A07 8=A0=A0=A0=A0=A0=A0=A0=A0=A0=A015 16=A0=A0=A0=A0=A0=A0=A0=A0=A023 = 24=A0=A0=A0=A0=A0=A0=A0=A0=A0=A031
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0| Reserved=A0=A0=A0=A0|=A0=A0=A0=A0=A0Flags=A0=A0=A0|=A0=A0vDstPort=A0=A0= =A0|Rd =A0 =A0=A0=A0=A0=A0|
=A0 =A0 =A0=A0 =A0=A0 = =A0|=A0=A0=A0=A0=A0=A0 PHB-ID=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0|=A0 = =A0 =A0=A0 =A0=A0 =A0Reserved =A0=A0=A0=A0=A0=A0=A0=A0|
=A0=A0 =A0=A0 =A0=A0 = =A0=A0|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Extende= d vDstPort=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|
I don't think we need to = change RFC3175. In fact, the objective of the Generic Aggregate I-D is = to remove restrictions of RFC3175. This is just one more restriction of = RFC3175 that we remove. I think ultimately the Generic Aggregate I-D = will effectively supersede RFC3175.

Does this work for you = ?

Cheers

Francois

=A0
> BTW:=A0One related question on PHB-ID. = PHB-ID says "=A0Note that the recommended DSCP value MUST
=
> = be used, even if=A0the network = in question has chosen a different mapping." So what happens if someone = wants
> to deploy two instances of EF? how do = you encode those in a PHB-ID?
=A0
The second EF instance would be a case 2 = PHB-ID - experimental or local use.
The current PHB-ID reference is RFC = 3140.
=A0
One = of the things I think we're discovering (e.g., w/Fred's admitted-voice = PHB)
is = that EF instances aren't completely combinable in practice - in theory = they're
completely combinable, and hence one never needs more than = one, *if* the rules
are followed perfectly.=A0 That "if" doesn't appear to = completely hold in practice.
=A0
Thanks,
--David
=A0

From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] =
Sent: Friday, December 29, 2006 5:01 AM
To: = Black, David
Cc: Francois Le Faucheur IMAP; hartmans-ietf@MIT.EDU; saag@MIT.EDU; ipsec@ietf.org; tsvwg-chairs@tools.ietf.org; fred@cisco.com; pratik.bose@lmco.com
Subjec= t: Re: [saag] tsvwg,preemption and rsvp: exposing characteristics = of confidentialtraffic

Hello = David,

=
Now I understand your concern. Please see below:

=
On 28 Dec 2006, at 22:44, Black_David@emc.com = wrote:

Francois,

My general concern for the draft is:

The concern about how to use a PHB consisting = of multiple DSCPs
(e.g., AF)
=
also = applies to the rsvp-ipsec draft.=A0 = Using PHBIDs (cf. RFC = 3140)
may
help address this, and = this concern may also affect RFC = 3175.

For example, this = sentence from the Introduction (Section 1) applies
to EF, but not AF for carrying the reserved = traffic:

=A0=A0 One example is where = E2E reservations using=A0
=A0= =A0 different preemption priorities (as per [RSVP-PREEMP]) = need to be=A0
=
=A0=A0 = aggregated through a Diffserv cloud using the same DSCP.
=

The underlying situation is that the raw notion of = DSCP is being used
instead of a = PHB, and for better or worse, this is already the case
in RFC 3175.=A0= The practical upshot is that RFC 3175 effectively = forbids
use of AF PHBs for carrying = reserved traffic -

Actually, RFC 3175 = explicitly=A0(attempts to) allow(s) the use of AF PHBs for carrying = reserved traffic.
In particular, it says:
=
"
=A0 =A0In the case where a session uses a pair of = PHBs (e.g., AF11
=A0=A0 and AF12), the DSCP used should = represent the numerically smallest
=A0=A0 PHB (e.g., = AF11).=A0 This follows the same naming convention described
=
=A0=A0 in [BRIM].
...

=A0 =A0[BRIM]=A0 =A0 =A0=A0= Brim, S., Carpenter, B. and F. LeFaucheur, "Per Hop
=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 Behavior Identification Codes", RFC 2836, May = 2000.
"

Do you agree that RFC = 3175 allows use of AF?


=
one has to explicitly
specify the DSCP (which could also be used as part = of an AF PHB if
one was being = careful).=A0 Going back and = changing RFC 3175 at this
point = is definitely *not* a good idea, so I would suggest just = making
this observation (RFC 3175 = requires use of a single DSCP for traffic
aggregated into a single reservation) in the = rsvp-ipsec draft and
observing that = this forbids meaningful use of AF drop precedence
for traffic covered by an RSVP = reservation.

=
With respect to rsvp-ipsec, a simple approach is to edit the = description text of the "DSCP" field in the GENERIC-AGGREGATE = SESSION object along the lines of what is in RFC = 3175 (ie if session uses single PHB, then field contains the DSCP of = PHB. If session uses group of PHBs like AF1x, then field contains the = numerically smallest DSCP value as per [PHB-ID]). This would make it = explicit that rsvp-ipsec also allows use of PHB groups, and would = ensure consistent use of DSCP field between RFC 3175 and = rsvp-ipsec.

=
The other approach would be to change the format of the=A0GENERIC-AGGREGATE = SESSION=A0object and include a full 16-bit PHB-ID = instead of DSCP field. I can see that this could help in situations = where (i) the Aggregate reservation crosses Diffserv domain boundaries = and (ii) different DSCP values are used for a given PHB/PHB-group. But = I am not sure that this would be a common situation. On the flip side, = it would make things less consistent between RFC 3175 and rsvp-ipsec = (for example, in cases where the operator has elected to use a DSCP = for the PHB which is different from the recommended DSCP value, then = RFC 3175=A0would encode the used-DSCP while rsvp-ipsec would encode = the recommended-DSCP as per PHB-ID).

Thoughts?

BTW:=A0One related = question on PHB-ID. PHB-ID says "=A0Note that the recommended DSCP = value MUST be used, even if=A0the network in question has chosen a = different mapping." So what happens if someone wants to deploy two = instances of EF? how do you encode those in a PHB-ID?

Cheers

Francois


=

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA=A0 01748
+1 (508) 293-7953 =A0 =A0 =A0 =A0 =A0 =A0 FAX: = +1 (508) 293-7786
black_david@emc.com=A0 =A0 =A0 =A0 Mobile: +1 = (978) 394-7754
----------------------------------------------------

= --Apple-Mail-17--247430743-- From Black_David@emc.com Fri Jan 19 10:12:23 2007 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l0JFCMU6023852 for ; Fri, 19 Jan 2007 10:12:22 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id l0JFCFvZ019390 for ; Fri, 19 Jan 2007 10:12:15 -0500 (EST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 0296E19A8DA; Fri, 19 Jan 2007 10:12:13 -0500 (EST) Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0JFBqdh001136; Fri, 19 Jan 2007 10:11:52 -0500 (EST) Received: from corpussmtp2.corp.emc.com (corpussmtp2.corp.emc.com [128.221.14.146]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0JFBnrI007345; Fri, 19 Jan 2007 10:11:49 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp2.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 10:11:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 19 Jan 2007 10:11:48 -0500 Message-ID: In-Reply-To: <8C6C7C18-184C-41F5-940D-6FFCF4C071AA@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic Thread-Index: Acc71DjCoJ2NeO6LSqqlXPMekgmScAABuA4A References: <8C6C7C18-184C-41F5-940D-6FFCF4C071AA@cisco.com> To: X-OriginalArrivalTime: 19 Jan 2007 15:11:49.0259 (UTC) FILETIME=[2461EDB0:01C73BDC] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.19.64432 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CP_NOT_1 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 1.15 X-Spam-Level: * (1.15) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id l0JFCMU6023852 Cc: ipsec@ietf.org, tsvwg-chairs@tools.ietf.org, fred@cisco.com, saag@mit.edu, hartmans-ietf@mit.edu, pratik.bose@lmco.com, black_david@emc.com Subject: Re: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 15:12:23 -0000 Francois, I have no problem with your preference to do the "right thing" even if it differs with RFC 3175. I'm not an RSVP expert and hence I'm not in a position to express a strong opinion on alignment with vs. divergence from RFC 3175. So, your proposal is fine with me, and I'll leave it to you and others on this email to determine what the rough consensus of the RSVP community is on how to deal with issues and limitations in RFC 3175. Thanks, --David p.s. Nit - One probably should use plain text email when including ASCII data structure diagrams. Microsoft's HTML renderer did "interesting" things to your diagram in the HTML-format email ;-). ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- ________________________________ From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] Sent: Friday, January 19, 2007 12:50 AM To: Black, David Cc: Francois Le Faucheur IMAP; hartmans-ietf@MIT.EDU; saag@MIT.EDU; ipsec@ietf.org; tsvwg-chairs@tools.ietf.org; fred@cisco.com; pratik.bose@lmco.com Subject: Re: [saag] tsvwg,preemption and rsvp: exposing characteristics of confidentialtraffic Hello David, Please see below: On 29 Dec 2006, at 19:00, Black_David@emc.com wrote: Francois, > Do you agree that RFC 3175 allows use of AF? Yes - the fact that it deliberately did not put in a full PHB-ID is unfortunate, as having to infer from context whether a DSCP is a singleton vs. representative of a group from context is not the best approach. It looks like I missed this AF support in quickly scanning RFC 3175. > With respect to rsvp-ipsec, a simple approach is to edit the description text of the "DSCP" field in the > GENERIC-AGGREGATE SESSION object along the lines of what is in RFC 3175 (ie if session uses > single PHB, then field contains the DSCP of PHB. If session uses group of PHBs like AF1x, then field > contains the numerically smallest DSCP value as per [PHB-ID]). This would make it explicit that > rsvp-ipsec also allows use of PHB groups, and would ensure consistent use of DSCP field between > RFC 3175 and rsvp-ipsec. That's probably the right thing to do at this juncture, because ... > The other approach would be to change the format of the GENERIC-AGGREGATE SESSION object > and include a full 16-bit PHB-ID instead of DSCP field. I can see that this could help in situations where > (i) the Aggregate reservation crosses Diffserv domain boundaries and (ii) different DSCP values are used > for a given PHB/PHB-group. But I am not sure that this would be a common situation. On the flip side, > it would make things less consistent between RFC 3175 and rsvp-ipsec (for example, in cases where the > operator has elected to use a DSCP for the PHB which is different from the recommended DSCP value, > then RFC 3175 would encode the used-DSCP while rsvp-ipsec would encode the recommended-DSCP > as per PHB-ID). ... probably entails going back and changing RFC 3175 to use a PHB-ID, something that it's probably entirely too late to do, and I agree that a divergence between RFC 3175 and rsvp-ipsec is undesirable. Thinking this over, I now have a marked preference for the second approach (ie change the GENERIC-AGGREGATE-SESSION object format to include PHB-ID instead of DSCP). Despite that fact it is "the right thing to do", my main argument is that this is required to be able to operate in a scenario where the Aggregate RSVP reservation would span two Diffserv domains which happen to use different DSCP markings for the same PHB (or PHB-group). The object would look like this: 0 7 8 15 16 23 24 31 +-------------+-------------+-------------+-------------+ | IPv4 DestAddress (4 bytes) | +-------------+-------------+-------------+--+----------+ | Reserved | Flags | vDstPort |Rd | +-------------+-------------+-------------+--+----------+ | PHB-ID | Reserved | +-------------+-------------+-------------+-------------+ | Extended vDstPort | +-------------+-------------+-------------+-------------+ I don't think we need to change RFC3175. In fact, the objective of the Generic Aggregate I-D is to remove restrictions of RFC3175. This is just one more restriction of RFC3175 that we remove. I think ultimately the Generic Aggregate I-D will effectively supersede RFC3175. Does this work for you ? Cheers Francois > BTW: One related question on PHB-ID. PHB-ID says " Note that the recommended DSCP value MUST > be used, even if the network in question has chosen a different mapping." So what happens if someone wants > to deploy two instances of EF? how do you encode those in a PHB-ID? The second EF instance would be a case 2 PHB-ID - experimental or local use. The current PHB-ID reference is RFC 3140. One of the things I think we're discovering (e.g., w/Fred's admitted-voice PHB) is that EF instances aren't completely combinable in practice - in theory they're completely combinable, and hence one never needs more than one, *if* the rules are followed perfectly. That "if" doesn't appear to completely hold in practice. Thanks, --David ________________________________ From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] Sent: Friday, December 29, 2006 5:01 AM To: Black, David Cc: Francois Le Faucheur IMAP; hartmans-ietf@MIT.EDU; saag@MIT.EDU; ipsec@ietf.org; tsvwg-chairs@tools.ietf.org; fred@cisco.com; pratik.bose@lmco.com Subject: Re: [saag] tsvwg,preemption and rsvp: exposing characteristics of confidentialtraffic Hello David, Now I understand your concern. Please see below: On 28 Dec 2006, at 22:44, Black_David@emc.com wrote: Francois, My general concern for the draft is: The concern about how to use a PHB consisting of multiple DSCPs (e.g., AF) also applies to the rsvp-ipsec draft. Using PHBIDs (cf. RFC 3140) may help address this, and this concern may also affect RFC 3175. For example, this sentence from the Introduction (Section 1) applies to EF, but not AF for carrying the reserved traffic: One example is where E2E reservations using different preemption priorities (as per [RSVP-PREEMP]) need to be aggregated through a Diffserv cloud using the same DSCP. The underlying situation is that the raw notion of DSCP is being used instead of a PHB, and for better or worse, this is already the case in RFC 3175. The practical upshot is that RFC 3175 effectively forbids use of AF PHBs for carrying reserved traffic - Actually, RFC 3175 explicitly (attempts to) allow(s) the use of AF PHBs for carrying reserved traffic. In particular, it says: " In the case where a session uses a pair of PHBs (e.g., AF11 and AF12), the DSCP used should represent the numerically smallest PHB (e.g., AF11). This follows the same naming convention described in [BRIM]. ... [BRIM] Brim, S., Carpenter, B. and F. LeFaucheur, "Per Hop Behavior Identification Codes", RFC 2836, May 2000. " Do you agree that RFC 3175 allows use of AF? one has to explicitly specify the DSCP (which could also be used as part of an AF PHB if one was being careful). Going back and changing RFC 3175 at this point is definitely *not* a good idea, so I would suggest just making this observation (RFC 3175 requires use of a single DSCP for traffic aggregated into a single reservation) in the rsvp-ipsec draft and observing that this forbids meaningful use of AF drop precedence for traffic covered by an RSVP reservation. With respect to rsvp-ipsec, a simple approach is to edit the description text of the "DSCP" field in the GENERIC-AGGREGATE SESSION object along the lines of what is in RFC 3175 (ie if session uses single PHB, then field contains the DSCP of PHB. If session uses group of PHBs like AF1x, then field contains the numerically smallest DSCP value as per [PHB-ID]). This would make it explicit that rsvp-ipsec also allows use of PHB groups, and would ensure consistent use of DSCP field between RFC 3175 and rsvp-ipsec. The other approach would be to change the format of the GENERIC-AGGREGATE SESSION object and include a full 16-bit PHB-ID instead of DSCP field. I can see that this could help in situations where (i) the Aggregate reservation crosses Diffserv domain boundaries and (ii) different DSCP values are used for a given PHB/PHB-group. But I am not sure that this would be a common situation. On the flip side, it would make things less consistent between RFC 3175 and rsvp-ipsec (for example, in cases where the operator has elected to use a DSCP for the PHB which is different from the recommended DSCP value, then RFC 3175 would encode the used-DSCP while rsvp-ipsec would encode the recommended-DSCP as per PHB-ID). Thoughts? BTW: One related question on PHB-ID. PHB-ID says " Note that the recommended DSCP value MUST be used, even if the network in question has chosen a different mapping." So what happens if someone wants to deploy two instances of EF? how do you encode those in a PHB-ID? Cheers Francois Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From fred@cisco.com Fri Jan 19 10:27:35 2007 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l0JFRWcr027993 for ; Fri, 19 Jan 2007 10:27:32 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id l0JFR813015742 for ; Fri, 19 Jan 2007 10:27:08 -0500 (EST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mit.edu (Spam Firewall) with ESMTP id 2B61E1C0687; Fri, 19 Jan 2007 10:27:06 -0500 (EST) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 19 Jan 2007 07:27:05 -0800 X-IronPort-AV: i="4.13,212,1167638400"; d="scan'208"; a="103355683:sNHT104299452" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l0JFR4CG001221; Fri, 19 Jan 2007 07:27:04 -0800 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 l0JFR0Gm015233; Fri, 19 Jan 2007 07:27:04 -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.1830); Fri, 19 Jan 2007 07:27:02 -0800 Received: from [10.223.101.150] ([10.21.97.154]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 07:27:01 -0800 In-Reply-To: <8C6C7C18-184C-41F5-940D-6FFCF4C071AA@cisco.com> References: <8C6C7C18-184C-41F5-940D-6FFCF4C071AA@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Date: Fri, 19 Jan 2007 07:26:48 -0800 To: Francois Le Faucheur IMAP X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 19 Jan 2007 15:27:01.0525 (UTC) FILETIME=[4422AC50:01C73BDE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9611; t=1169220424; x=1170084424; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[saag]=20tsvwg, preemption=20and=20rsvp=3A=20exposing= 20characteristics=20of=20confidentialtraffic |Sender:=20; bh=CEfrOICgmRhfhcpCFmECiLT1VR7zCvfOXBdZvKw156g=; b=Xx+CDd+YWfZlFPOtkXuq9stboS9AczBwN0qNf7kNsYrZVUS+pvLNja3gDaqHg2Soa/4tmgPZ cTTyVsm3zvkxZUDlvCknhAzJrmDeY+k2eGd0bcuShAbJja0xlhOTnSD1; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: ipsec@ietf.org, tsvwg-chairs@tools.ietf.org, pratik.bose@lmco.com, saag@mit.edu, hartmans-ietf@mit.edu, black_david@emc.com Subject: Re: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 15:27:35 -0000 Sorry for being late picking this up. I personally can buy either the "a PHB group can be identified by the numerically least value in it" approach or your second option. If you want to go with 2836, it works for me. On Jan 18, 2007, at 9:50 PM, Francois Le Faucheur IMAP wrote: > Hello David, > > Please see below: > > On 29 Dec 2006, at 19:00, Black_David@emc.com wrote: > >> Francois, >> >> > Do you agree that RFC 3175 allows use of AF? >> >> Yes - the fact that it deliberately did not put in a full PHB-ID >> is unfortunate, >> as having to infer from context whether a DSCP is a singleton vs. >> representative >> of a group from context is not the best approach. It looks like I >> missed >> this AF support in quickly scanning RFC 3175. >> >> > With respect to rsvp-ipsec, a simple approach is to edit the >> description text of the "DSCP" field in the >> > GENERIC-AGGREGATE SESSION object along the lines of what is in >> RFC 3175 (ie if session uses >> > single PHB, then field contains the DSCP of PHB. If session uses >> group of PHBs like AF1x, then field >> > contains the numerically smallest DSCP value as per [PHB-ID]). >> This would make it explicit that >> > rsvp-ipsec also allows use of PHB groups, and would ensure >> consistent use of DSCP field between >> > RFC 3175 and rsvp-ipsec. >> >> That's probably the right thing to do at this juncture, because ... >> >> > The other approach would be to change the format of the GENERIC- >> AGGREGATE SESSION object >> > and include a full 16-bit PHB-ID instead of DSCP field. I can >> see that this could help in situations where >> > (i) the Aggregate reservation crosses Diffserv domain boundaries >> and (ii) different DSCP values are used >> > for a given PHB/PHB-group. But I am not sure that this would be >> a common situation. On the flip side, >> > it would make things less consistent between RFC 3175 and rsvp- >> ipsec (for example, in cases where the >> > operator has elected to use a DSCP for the PHB which is >> different from the recommended DSCP value, >> > then RFC 3175 would encode the used-DSCP while rsvp-ipsec would >> encode the recommended-DSCP >> > as per PHB-ID). >> >> ... probably entails going back and changing RFC 3175 to use a PHB- >> ID, something >> that it's probably entirely too late to do, and I agree that a >> divergence between >> RFC 3175 and rsvp-ipsec is undesirable. > > Thinking this over, I now have a marked preference for the second > approach (ie change the GENERIC-AGGREGATE-SESSION object format to > include PHB-ID instead of DSCP). Despite that fact it is "the right > thing to do", my main argument is that this is required to be able > to operate in a scenario where the Aggregate RSVP reservation would > span two Diffserv domains which happen to use different DSCP > markings for the same PHB (or PHB-group). > > The object would look like this: > > 0 7 8 15 16 23 24 31 > +-------------+-------------+-------------+-------------+ > | IPv4 DestAddress (4 bytes) | > +-------------+-------------+-------------+--+----------+ > | Reserved | Flags | vDstPort |Rd | > +-------------+-------------+-------------+--+----------+ > | PHB-ID | > Reserved | > +-------------+-------------+-------------+-------------+ > | Extended vDstPort | > +-------------+-------------+-------------+-------------+ > > I don't think we need to change RFC3175. In fact, the objective of > the Generic Aggregate I-D is to remove restrictions of RFC3175. > This is just one more restriction of RFC3175 that we remove. I > think ultimately the Generic Aggregate I-D will effectively > supersede RFC3175. > > Does this work for you ? > > Cheers > > Francois > >> >> > BTW: One related question on PHB-ID. PHB-ID says " Note that the >> recommended DSCP value MUST >> > be used, even if the network in question has chosen a different >> mapping." So what happens if someone wants >> > to deploy two instances of EF? how do you encode those in a PHB-ID? >> >> The second EF instance would be a case 2 PHB-ID - experimental or >> local use. >> The current PHB-ID reference is RFC 3140. >> >> One of the things I think we're discovering (e.g., w/Fred's >> admitted-voice PHB) >> is that EF instances aren't completely combinable in practice - in >> theory they're >> completely combinable, and hence one never needs more than one, >> *if* the rules >> are followed perfectly. That "if" doesn't appear to completely >> hold in practice. >> >> Thanks, >> --David >> >> >> From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] >> Sent: Friday, December 29, 2006 5:01 AM >> To: Black, David >> Cc: Francois Le Faucheur IMAP; hartmans-ietf@MIT.EDU; >> saag@MIT.EDU; ipsec@ietf.org; tsvwg-chairs@tools.ietf.org; >> fred@cisco.com; pratik.bose@lmco.com >> Subject: Re: [saag] tsvwg,preemption and rsvp: exposing >> characteristics of confidentialtraffic >> >> Hello David, >> >> Now I understand your concern. Please see below: >> >> On 28 Dec 2006, at 22:44, Black_David@emc.com wrote: >> >>> Francois, >>> >>> My general concern for the draft is: >>> >>>>> The concern about how to use a PHB consisting of multiple DSCPs >>> (e.g., AF) >>>>> also applies to the rsvp-ipsec draft. Using PHBIDs (cf. RFC 3140) >>> may >>>>> help address this, and this concern may also affect RFC 3175. >>> >>> For example, this sentence from the Introduction (Section 1) applies >>> to EF, but not AF for carrying the reserved traffic: >>> >>> One example is where E2E reservations using >>> different preemption priorities (as per [RSVP-PREEMP]) need to be >>> aggregated through a Diffserv cloud using the same DSCP. >>> >>> The underlying situation is that the raw notion of DSCP is being >>> used >>> instead of a PHB, and for better or worse, this is already the case >>> in RFC 3175. The practical upshot is that RFC 3175 effectively >>> forbids >>> use of AF PHBs for carrying reserved traffic - >> >> Actually, RFC 3175 explicitly (attempts to) allow(s) the use of AF >> PHBs for carrying reserved traffic. >> In particular, it says: >> " >> In the case where a session uses a pair of PHBs (e.g., AF11 >> and AF12), the DSCP used should represent the numerically smallest >> PHB (e.g., AF11). This follows the same naming convention >> described >> in [BRIM]. >> ... >> >> [BRIM] Brim, S., Carpenter, B. and F. LeFaucheur, "Per Hop >> Behavior Identification Codes", RFC 2836, May 2000. >> " >> >> Do you agree that RFC 3175 allows use of AF? >> >> >>> one has to explicitly >>> specify the DSCP (which could also be used as part of an AF PHB if >>> one was being careful). Going back and changing RFC 3175 at this >>> point is definitely *not* a good idea, so I would suggest just >>> making >>> this observation (RFC 3175 requires use of a single DSCP for traffic >>> aggregated into a single reservation) in the rsvp-ipsec draft and >>> observing that this forbids meaningful use of AF drop precedence >>> for traffic covered by an RSVP reservation. >> >> With respect to rsvp-ipsec, a simple approach is to edit the >> description text of the "DSCP" field in the GENERIC-AGGREGATE >> SESSION object along the lines of what is in RFC 3175 (ie if >> session uses single PHB, then field contains the DSCP of PHB. If >> session uses group of PHBs like AF1x, then field contains the >> numerically smallest DSCP value as per [PHB-ID]). This would make >> it explicit that rsvp-ipsec also allows use of PHB groups, and >> would ensure consistent use of DSCP field between RFC 3175 and >> rsvp-ipsec. >> >> The other approach would be to change the format of the GENERIC- >> AGGREGATE SESSION object and include a full 16-bit PHB-ID instead >> of DSCP field. I can see that this could help in situations where >> (i) the Aggregate reservation crosses Diffserv domain boundaries >> and (ii) different DSCP values are used for a given PHB/PHB-group. >> But I am not sure that this would be a common situation. On the >> flip side, it would make things less consistent between RFC 3175 >> and rsvp-ipsec (for example, in cases where the operator has >> elected to use a DSCP for the PHB which is different from the >> recommended DSCP value, then RFC 3175 would encode the used-DSCP >> while rsvp-ipsec would encode the recommended-DSCP as per PHB-ID). >> >> Thoughts? >> >> BTW: One related question on PHB-ID. PHB-ID says " Note that the >> recommended DSCP value MUST be used, even if the network in >> question has chosen a different mapping." So what happens if >> someone wants to deploy two instances of EF? how do you encode >> those in a PHB-ID? >> >> Cheers >> >> Francois >> >> >>> >>> Thanks, >>> --David >>> ---------------------------------------------------- >>> David L. Black, Senior Technologist >>> EMC Corporation, 176 South St., Hopkinton, MA 01748 >>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >>> black_david@emc.com Mobile: +1 (978) 394-7754 >>> ---------------------------------------------------- > From Black_David@emc.com Fri Jan 19 17:13:33 2007 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l0JMDX4S013270 for ; Fri, 19 Jan 2007 17:13:33 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id l0JMDQfQ012196 for ; Fri, 19 Jan 2007 17:13:26 -0500 (EST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id B95FA163322; Fri, 19 Jan 2007 17:13:25 -0500 (EST) Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0JMDCOc004502; Fri, 19 Jan 2007 17:13:13 -0500 (EST) Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.64.54]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0JMCNAG010838; Fri, 19 Jan 2007 17:13:05 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 17:12:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 19 Jan 2007 17:12:56 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic Thread-Index: Acc73ujUzcoZUBH0QZW3+zjNYvOQfQAN/dNg References: <8C6C7C18-184C-41F5-940D-6FFCF4C071AA@cisco.com> To: , X-OriginalArrivalTime: 19 Jan 2007 22:12:57.0041 (UTC) FILETIME=[F9277C10:01C73C16] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.19.135432 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CP_NOT_1 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 1.15 X-Spam-Level: * (1.15) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id l0JMDX4S013270 Cc: ipsec@ietf.org, tsvwg-chairs@tools.ietf.org, saag@mit.edu, hartmans-ietf@mit.edu, pratik.bose@lmco.com, black_david@emc.com Subject: Re: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 22:13:33 -0000 Actually it's now 3140, which fixed a few problems in 2836 ;-). Thanks, --David > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Friday, January 19, 2007 10:27 AM > To: Francois Le Faucheur IMAP > Cc: Black, David; hartmans-ietf@MIT.EDU; saag@MIT.EDU; > ipsec@ietf.org; tsvwg-chairs@tools.ietf.org; pratik.bose@lmco.com > Subject: Re: [saag] tsvwg,preemption and rsvp: exposing > characteristics of confidentialtraffic > > Sorry for being late picking this up. I personally can buy > either the > "a PHB group can be identified by the numerically least value in it" > approach or your second option. If you want to go with 2836, > it works > for me. > > On Jan 18, 2007, at 9:50 PM, Francois Le Faucheur IMAP wrote: > > > Hello David, > > > > Please see below: > > > > On 29 Dec 2006, at 19:00, Black_David@emc.com wrote: > > > >> Francois, > >> > >> > Do you agree that RFC 3175 allows use of AF? > >> > >> Yes - the fact that it deliberately did not put in a full PHB-ID > >> is unfortunate, > >> as having to infer from context whether a DSCP is a singleton vs. > >> representative > >> of a group from context is not the best approach. It > looks like I > >> missed > >> this AF support in quickly scanning RFC 3175. > >> > >> > With respect to rsvp-ipsec, a simple approach is to edit the > >> description text of the "DSCP" field in the > >> > GENERIC-AGGREGATE SESSION object along the lines of what is in > >> RFC 3175 (ie if session uses > >> > single PHB, then field contains the DSCP of PHB. If > session uses > >> group of PHBs like AF1x, then field > >> > contains the numerically smallest DSCP value as per [PHB-ID]). > >> This would make it explicit that > >> > rsvp-ipsec also allows use of PHB groups, and would ensure > >> consistent use of DSCP field between > >> > RFC 3175 and rsvp-ipsec. > >> > >> That's probably the right thing to do at this juncture, because ... > >> > >> > The other approach would be to change the format of the GENERIC- > >> AGGREGATE SESSION object > >> > and include a full 16-bit PHB-ID instead of DSCP field. I can > >> see that this could help in situations where > >> > (i) the Aggregate reservation crosses Diffserv domain > boundaries > >> and (ii) different DSCP values are used > >> > for a given PHB/PHB-group. But I am not sure that this would be > >> a common situation. On the flip side, > >> > it would make things less consistent between RFC 3175 and rsvp- > >> ipsec (for example, in cases where the > >> > operator has elected to use a DSCP for the PHB which is > >> different from the recommended DSCP value, > >> > then RFC 3175 would encode the used-DSCP while rsvp-ipsec would > >> encode the recommended-DSCP > >> > as per PHB-ID). > >> > >> ... probably entails going back and changing RFC 3175 to > use a PHB- > >> ID, something > >> that it's probably entirely too late to do, and I agree that a > >> divergence between > >> RFC 3175 and rsvp-ipsec is undesirable. > > > > Thinking this over, I now have a marked preference for the second > > approach (ie change the GENERIC-AGGREGATE-SESSION object format to > > include PHB-ID instead of DSCP). Despite that fact it is > "the right > > thing to do", my main argument is that this is required to be able > > to operate in a scenario where the Aggregate RSVP > reservation would > > span two Diffserv domains which happen to use different DSCP > > markings for the same PHB (or PHB-group). > > > > The object would look like this: > > > > 0 7 8 15 16 23 24 31 > > +-------------+-------------+-------------+-------------+ > > | IPv4 DestAddress (4 bytes) | > > +-------------+-------------+-------------+--+----------+ > > | Reserved | Flags | vDstPort |Rd | > > +-------------+-------------+-------------+--+----------+ > > | PHB-ID | > > Reserved | > > +-------------+-------------+-------------+-------------+ > > | Extended vDstPort | > > +-------------+-------------+-------------+-------------+ > > > > I don't think we need to change RFC3175. In fact, the objective of > > the Generic Aggregate I-D is to remove restrictions of RFC3175. > > This is just one more restriction of RFC3175 that we remove. I > > think ultimately the Generic Aggregate I-D will effectively > > supersede RFC3175. > > > > Does this work for you ? > > > > Cheers > > > > Francois > > > >> > >> > BTW: One related question on PHB-ID. PHB-ID says " Note > that the > >> recommended DSCP value MUST > >> > be used, even if the network in question has chosen a different > >> mapping." So what happens if someone wants > >> > to deploy two instances of EF? how do you encode those > in a PHB-ID? > >> > >> The second EF instance would be a case 2 PHB-ID - experimental or > >> local use. > >> The current PHB-ID reference is RFC 3140. > >> > >> One of the things I think we're discovering (e.g., w/Fred's > >> admitted-voice PHB) > >> is that EF instances aren't completely combinable in > practice - in > >> theory they're > >> completely combinable, and hence one never needs more than one, > >> *if* the rules > >> are followed perfectly. That "if" doesn't appear to completely > >> hold in practice. > >> > >> Thanks, > >> --David > >> > >> > >> From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] > >> Sent: Friday, December 29, 2006 5:01 AM > >> To: Black, David > >> Cc: Francois Le Faucheur IMAP; hartmans-ietf@MIT.EDU; > >> saag@MIT.EDU; ipsec@ietf.org; tsvwg-chairs@tools.ietf.org; > >> fred@cisco.com; pratik.bose@lmco.com > >> Subject: Re: [saag] tsvwg,preemption and rsvp: exposing > >> characteristics of confidentialtraffic > >> > >> Hello David, > >> > >> Now I understand your concern. Please see below: > >> > >> On 28 Dec 2006, at 22:44, Black_David@emc.com wrote: > >> > >>> Francois, > >>> > >>> My general concern for the draft is: > >>> > >>>>> The concern about how to use a PHB consisting of multiple DSCPs > >>> (e.g., AF) > >>>>> also applies to the rsvp-ipsec draft. Using PHBIDs > (cf. RFC 3140) > >>> may > >>>>> help address this, and this concern may also affect RFC 3175. > >>> > >>> For example, this sentence from the Introduction (Section > 1) applies > >>> to EF, but not AF for carrying the reserved traffic: > >>> > >>> One example is where E2E reservations using > >>> different preemption priorities (as per [RSVP-PREEMP]) > need to be > >>> aggregated through a Diffserv cloud using the same DSCP. > >>> > >>> The underlying situation is that the raw notion of DSCP is being > >>> used > >>> instead of a PHB, and for better or worse, this is > already the case > >>> in RFC 3175. The practical upshot is that RFC 3175 effectively > >>> forbids > >>> use of AF PHBs for carrying reserved traffic - > >> > >> Actually, RFC 3175 explicitly (attempts to) allow(s) the > use of AF > >> PHBs for carrying reserved traffic. > >> In particular, it says: > >> " > >> In the case where a session uses a pair of PHBs (e.g., AF11 > >> and AF12), the DSCP used should represent the > numerically smallest > >> PHB (e.g., AF11). This follows the same naming convention > >> described > >> in [BRIM]. > >> ... > >> > >> [BRIM] Brim, S., Carpenter, B. and F. LeFaucheur, "Per Hop > >> Behavior Identification Codes", RFC 2836, May 2000. > >> " > >> > >> Do you agree that RFC 3175 allows use of AF? > >> > >> > >>> one has to explicitly > >>> specify the DSCP (which could also be used as part of an AF PHB if > >>> one was being careful). Going back and changing RFC 3175 at this > >>> point is definitely *not* a good idea, so I would suggest just > >>> making > >>> this observation (RFC 3175 requires use of a single DSCP > for traffic > >>> aggregated into a single reservation) in the rsvp-ipsec draft and > >>> observing that this forbids meaningful use of AF drop precedence > >>> for traffic covered by an RSVP reservation. > >> > >> With respect to rsvp-ipsec, a simple approach is to edit the > >> description text of the "DSCP" field in the GENERIC-AGGREGATE > >> SESSION object along the lines of what is in RFC 3175 (ie if > >> session uses single PHB, then field contains the DSCP of PHB. If > >> session uses group of PHBs like AF1x, then field contains the > >> numerically smallest DSCP value as per [PHB-ID]). This would make > >> it explicit that rsvp-ipsec also allows use of PHB groups, and > >> would ensure consistent use of DSCP field between RFC 3175 and > >> rsvp-ipsec. > >> > >> The other approach would be to change the format of the GENERIC- > >> AGGREGATE SESSION object and include a full 16-bit PHB-ID instead > >> of DSCP field. I can see that this could help in situations where > >> (i) the Aggregate reservation crosses Diffserv domain boundaries > >> and (ii) different DSCP values are used for a given > PHB/PHB-group. > >> But I am not sure that this would be a common situation. On the > >> flip side, it would make things less consistent between RFC 3175 > >> and rsvp-ipsec (for example, in cases where the operator has > >> elected to use a DSCP for the PHB which is different from the > >> recommended DSCP value, then RFC 3175 would encode the used-DSCP > >> while rsvp-ipsec would encode the recommended-DSCP as per PHB-ID). > >> > >> Thoughts? > >> > >> BTW: One related question on PHB-ID. PHB-ID says " Note that the > >> recommended DSCP value MUST be used, even if the network in > >> question has chosen a different mapping." So what happens if > >> someone wants to deploy two instances of EF? how do you encode > >> those in a PHB-ID? > >> > >> Cheers > >> > >> Francois > >> > >> > >>> > >>> Thanks, > >>> --David > >>> ---------------------------------------------------- > >>> David L. Black, Senior Technologist > >>> EMC Corporation, 176 South St., Hopkinton, MA 01748 > >>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 > >>> black_david@emc.com Mobile: +1 (978) 394-7754 > >>> ---------------------------------------------------- > > > > From ldondeti@qualcomm.com Sat Jan 20 16:36:26 2007 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l0KLaQsc014709 for ; Sat, 20 Jan 2007 16:36:26 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id l0KLaGoP020779 for ; Sat, 20 Jan 2007 16:36:17 -0500 (EST) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 9D5C81EF82B for ; Sat, 20 Jan 2007 16:36:15 -0500 (EST) Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0KLa9Pq016520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 20 Jan 2007 13:36:10 -0800 Received: from [10.50.72.98] (qconnect-10-50-72-98.qualcomm.com [10.50.72.98]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0KLa8Ks008418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 20 Jan 2007 13:36:09 -0800 (PST) Message-ID: <45B28AFE.6090204@qualcomm.com> Date: Sat, 20 Jan 2007 13:34:54 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: Russ Housley References: <7.0.0.16.2.20070117095212.04035c38@vigilsec.com> In-Reply-To: <7.0.0.16.2.20070117095212.04035c38@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: ipsec@ietf.org, saag@mit.edu, ietf@ietf.org Subject: Re: [saag] MUST implement AES-CBC for IPsec ESP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 21:36:26 -0000 What are the export implications due to this? A compliant ESP implementation MUST include the DES cipher due to this change. With status quo, a compliant ESP implementation can be used for integrity protection alone with NULL encryption. regards, Lakshminath Russ Housley wrote: > During the IETF Last Call for draft-manral-ipsec-rfc4305-bis-errata, we > received a comment that deserves wide exposure. > > For ESP encryption algorithms, the document that was sent out for Last > Call contains the following table: > > Requirement Encryption Algorithm (notes) > ----------- -------------------- > MUST NULL (1) > MUST- TripleDES-CBC [RFC2451] > SHOULD+ AES-CBC with 128-bit keys [RFC3602] > SHOULD AES-CTR [RFC3686] > SHOULD NOT DES-CBC [RFC2405] (3) > > The Last Call comment suggests changing the "SHOULD+" for AES-CBC to > "MUST." > > I support this proposed change, and I have asked the author to make this > change in the document that will be submitted to the IESG for > consideration on the Telechat on January 25th. If anyone has an > objection to this change, please speak now. Please send comments on > this proposed change to the iesg@ietf.org or ietf@ietf.org mailing lists > by 2007-01-24. > > Russ Housley > Security AD > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > From paul.hoffman@vpnc.org Sat Jan 20 17:55:04 2007 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l0KMt4oP031901 for ; Sat, 20 Jan 2007 17:55:04 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id l0KMsxeV010829 for ; Sat, 20 Jan 2007 17:55:00 -0500 (EST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 5D898193114 for ; Sat, 20 Jan 2007 17:54:34 -0500 (EST) Received: from [10.20.30.108] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0KMsUNX076047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Jan 2007 15:54:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <45B28AFE.6090204@qualcomm.com> References: <7.0.0.16.2.20070117095212.04035c38@vigilsec.com> <45B28AFE.6090204@qualcomm.com> Date: Sat, 20 Jan 2007 14:54:21 -0800 To: Lakshminath Dondeti , Russ Housley From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: ipsec@ietf.org, saag@mit.edu, ietf@ietf.org Subject: [saag] [Ipsec] Re: MUST implement AES-CBC for IPsec ESP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 22:55:04 -0000 At 1:34 PM -0800 1/20/07, Lakshminath Dondeti wrote: >What are the export implications due to this? Two answers: - None. TripleDES is already a MUST in RFC 4305, and thus it already has a strong crypto requirement. - Export from which country? To which country? Who knows? Why are you asking the IETF's armchair lawyers to start firing up their keyboards? :-) --Paul Hoffman, Director --VPN Consortium From smb@cs.columbia.edu Sat Jan 20 18:28:18 2007 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l0KNSI7p007738 for ; Sat, 20 Jan 2007 18:28:18 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id l0KNSEUM006924 for ; Sat, 20 Jan 2007 18:28:15 -0500 (EST) Received: from machshav.com (machshav.com [147.28.0.16]) by mit.edu (Spam Firewall) with ESMTP id C36E02205F3 for ; Sat, 20 Jan 2007 18:28:13 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id D7713FB42B; Sat, 20 Jan 2007 23:28:12 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B2A59FB41B; Sat, 20 Jan 2007 23:28:11 +0000 (UTC) Received: by berkshire.machshav.com (Postfix, from userid 54047) id 50B9D7660C0; Sat, 20 Jan 2007 18:28:10 -0500 (EST) Date: Sat, 20 Jan 2007 18:28:10 -0500 From: "Steven M. Bellovin" To: lrosen@rosenlaw.com In-Reply-To: <021901c73ce4$b2907490$0202fea9@LROSENTOSHIBA> References: <7.0.0.16.2.20070117095212.04035c38@vigilsec.com> <45B28AFE.6090204@qualcomm.com> <021901c73ce4$b2907490$0202fea9@LROSENTOSHIBA> Organization: Columbia University X-Mailer: Claws Mail 2.7.1 (GTK+ 2.10.7; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20070120232810.50B9D7660C0@berkshire.machshav.com> X-Spam-Score: 0.13 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: ipsec@ietf.org, 'Russ Housley' , 'Lakshminath Dondeti' , ietf@ietf.org, saag@mit.edu Subject: Re: [saag] MUST implement AES-CBC for IPsec ESP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 23:28:18 -0000 On Sat, 20 Jan 2007 14:45:26 -0800 "Lawrence Rosen" wrote: > > > For ESP encryption algorithms, the document that was sent out for > > > Last Call contains the following table: > > > > > > Requirement Encryption Algorithm (notes) > > > ----------- -------------------- > > > MUST NULL (1) > > > MUST- TripleDES-CBC [RFC2451] > > > SHOULD+ AES-CBC with 128-bit keys [RFC3602] > > > SHOULD AES-CTR [RFC3686] > > > SHOULD NOT DES-CBC [RFC2405] (3) > > > > > > The Last Call comment suggests changing the "SHOULD+" for AES-CBC > > > to "MUST." > > Are any of these encryption algorithms patented? > Almost certainly not. DES was patented, but the patent was never enforced; it has long since expired. (Trivia: IBM filed a statement saying that DES was royalty-free *if* used in one of the NIST-approvedd modes of operation. But they never went after anyone who used it in other ways.) To my knowledge, 3DES was never patented; even if it had been, it was first publicly described in 1979, so I doubt that any patent would still be valid. AES itself had to be unencumbered; see http://csrc.nist.gov/CryptoToolkit/aes/pre-round1/aes_9709.htm#sec2d . The designers of Rijndael never even attempted to patent it; see the text quoted in RFC 3602 or the old Rijndael home page. CBC dates from at least 1980 -- I seem to recall 1978, but I don't have a citation handy. That leaves CTR mode. I doubt very much that it's patented, since it's been very well known for many years and NIST rarely standardizes patented algorithms in this space (which I know you appreciate...). However, I don't have any citations to prove this negative. --Steve Bellovin, http://www.cs.columbia.edu/~smb From smb@cs.columbia.edu Sat Jan 20 18:30:17 2007 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l0KNUHls008144 for ; Sat, 20 Jan 2007 18:30:17 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id l0KNUAXu002025 for ; Sat, 20 Jan 2007 18:30:10 -0500 (EST) Received: from machshav.com (machshav.com [147.28.0.16]) by mit.edu (Spam Firewall) with ESMTP id DE59F16B878 for ; Sat, 20 Jan 2007 18:30:09 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 39ACAFB432; Sat, 20 Jan 2007 23:30:09 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4C812FB41B; Sat, 20 Jan 2007 23:30:08 +0000 (UTC) Received: by berkshire.machshav.com (Postfix, from userid 54047) id 0BD537660C0; Sat, 20 Jan 2007 18:30:07 -0500 (EST) Date: Sat, 20 Jan 2007 18:30:06 -0500 From: "Steven M. Bellovin" To: Lakshminath Dondeti In-Reply-To: <45B28AFE.6090204@qualcomm.com> References: <7.0.0.16.2.20070117095212.04035c38@vigilsec.com> <45B28AFE.6090204@qualcomm.com> Organization: Columbia University X-Mailer: Claws Mail 2.7.1 (GTK+ 2.10.7; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20070120233007.0BD537660C0@berkshire.machshav.com> X-Spam-Score: 3 X-Spam-Level: *** (3) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: ipsec@ietf.org, saag@mit.edu, Russ Housley , ietf@ietf.org Subject: Re: [saag] MUST implement AES-CBC for IPsec ESP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 23:30:17 -0000 On Sat, 20 Jan 2007 13:34:54 -0800 Lakshminath Dondeti wrote: > What are the export implications due to this? A compliant ESP > implementation MUST include the DES cipher due to this change. With > status quo, a compliant ESP implementation can be used for integrity > protection alone with NULL encryption. > I don't understand your question. Apart from the Danvers doctrine -- the IETF makes technically sound decisions without regard to politics -- how do you conclude that DES MUST be included? The new document says SHOULD NOT. > > Russ Housley wrote: > > During the IETF Last Call for > > draft-manral-ipsec-rfc4305-bis-errata, we > received a comment that > > deserves wide exposure. > > > For ESP encryption algorithms, the document that was sent out for > > > Last > Call contains the following table: Requirement > > > Encryption Algorithm (notes) > > ----------- -------------------- > > MUST NULL (1) > > MUST- TripleDES-CBC [RFC2451] > > SHOULD+ AES-CBC with 128-bit keys [RFC3602] > > SHOULD AES-CTR [RFC3686] > > SHOULD NOT DES-CBC [RFC2405] (3) > > > The Last Call comment suggests changing the "SHOULD+" for AES-CBC > > > to > "MUST." I support this proposed change, and I have asked the > > > author to make this > change in the document that will be > > > submitted to the IESG for > consideration on the Telechat on > > > January 25th. If anyone has an > objection to this change, > > > please speak now. Please send comments on > this proposed change > > > to the iesg@ietf.org or ietf@ietf.org mailing lists > by > > > 2007-01-24. Russ Housley > > Security AD > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > --Steve Bellovin, http://www.cs.columbia.edu/~smb From ldondeti@qualcomm.com Sat Jan 20 20:50:09 2007 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l0L1o9Mj004398 for ; Sat, 20 Jan 2007 20:50:09 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id l0L1o3GM006851 for ; Sat, 20 Jan 2007 20:50:03 -0500 (EST) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id A1688148ECB for ; Sat, 20 Jan 2007 20:50:02 -0500 (EST) Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0L1njmH004350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 20 Jan 2007 17:49:45 -0800 Received: from [10.50.73.37] (qconnect-10-50-73-37.qualcomm.com [10.50.73.37]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0L1nile002344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 20 Jan 2007 17:49:44 -0800 (PST) Message-ID: <45B2C66E.50205@qualcomm.com> Date: Sat, 20 Jan 2007 17:48:30 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: "Steven M. Bellovin" References: <7.0.0.16.2.20070117095212.04035c38@vigilsec.com> <45B28AFE.6090204@qualcomm.com> <20070120233007.0BD537660C0@berkshire.machshav.com> In-Reply-To: <20070120233007.0BD537660C0@berkshire.machshav.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: ipsec@ietf.org, saag@mit.edu, Russ Housley , ietf@ietf.org Subject: Re: [saag] MUST implement AES-CBC for IPsec ESP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 01:50:09 -0000 Thanks Steve. Oddly enough I have never heard of 3365 until now. Apologies to all for my posting earlier. regards, Lakshminath From housley@vigilsec.com Mon Jan 22 17:47:29 2007 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l0MMlTqh000421 for ; Mon, 22 Jan 2007 17:47:29 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id l0MMlMQV028488 for ; Mon, 22 Jan 2007 17:47:22 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by mit.edu (Spam Firewall) with SMTP id 4129A214605 for ; Mon, 22 Jan 2007 17:47:22 -0500 (EST) Received: (qmail 21057 invoked by uid 0); 22 Jan 2007 22:47:14 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (12.104.158.98) by woodstock.binhost.com with SMTP; 22 Jan 2007 22:47:14 -0000 Message-Id: <7.0.0.16.2.20070122174348.040caac8@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Mon, 22 Jan 2007 17:45:45 -0500 To: "Yaakov Stein" From: Russ Housley In-Reply-To: <457D36D9D89B5B47BC06DA869B1C815D030B2257@exrad3.ad.rad.co. il> References: <45B28AFE.6090204@qualcomm.com> <457D36D9D89B5B47BC06DA869B1C815D030B2257@exrad3.ad.rad.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: ipsec@ietf.org, saag@mit.edu, ietf@ietf.org Subject: Re: [saag] MUST implement AES-CBC for IPsec ESP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 22:47:29 -0000 Yaakov: >Strangely missing is AES/GCM [RFC4106]. > >SHOULDn't this be a SHOULD ? None of the MUST/SHOULD algorithms are authenticated-encryption algorithms. This has not been proposed in the past, and it is very late in the processing of this document to propose it now. I'm pleased to entertain adding it the next time this document is updated. Russ From vishwas.ietf@gmail.com Mon Jan 22 19:58:18 2007 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l0N0wI82023771 for ; Mon, 22 Jan 2007 19:58:18 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id l0N0wBpQ011685 for ; Mon, 22 Jan 2007 19:58:11 -0500 (EST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mit.edu (Spam Firewall) with ESMTP id 0EBB81C2197 for ; Mon, 22 Jan 2007 19:58:10 -0500 (EST) Received: by nf-out-0910.google.com with SMTP id i2so66808nfe for ; Mon, 22 Jan 2007 16:58:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=P5UaNUfaNiJTopfIGcpsTkkzvIWWqK5wRBCdvfarCy1yr8QYVnhYUQr5fTIwcYdU35ej5czKPsAtfbdKd2RFKAPEMstUzwen0w2AFXoghGrRtUOID/Ea6XXMzle0WZ2jGOTVmOHmZfoi55aDfS4GT3rPHk56uDH+TjzGgtiNv3M= Received: by 10.48.204.7 with SMTP id b7mr235805nfg.1169513890464; Mon, 22 Jan 2007 16:58:10 -0800 (PST) Received: by 10.48.221.18 with HTTP; Mon, 22 Jan 2007 16:58:10 -0800 (PST) Message-ID: <77ead0ec0701221658h373b8868n525d25da3901948d@mail.gmail.com> Date: Mon, 22 Jan 2007 16:58:10 -0800 From: "Vishwas Manral" To: "Russ Housley" In-Reply-To: <7.0.0.16.2.20070122174348.040caac8@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45B28AFE.6090204@qualcomm.com> <457D36D9D89B5B47BC06DA869B1C815D030B2257@exrad3.ad.rad.co.il> <7.0.0.16.2.20070122174348.040caac8@vigilsec.com> X-Spam-Score: 1 X-Spam-Level: * (1) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: ipsec@ietf.org, saag@mit.edu, Yaakov Stein , ietf@ietf.org Subject: Re: [saag] [Ipsec] RE: MUST implement AES-CBC for IPsec ESP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 00:58:18 -0000 Hi Yaakov, The following new text has been added to the draft. http://www.ietf.org/internet-drafts/draft-manral-ipsec-rfc4305-bis-errata-03.txt Although there are no suggested or required combined algorithms at this time, AES-CCM [RFC4309] and AES-GCM [RFC4106] are of interest. AES-CCM has been adopted as the preferred mode in IEEE 802.11 [802.11i], and AES- GCM has been adopted as the preferred mode in IEEE 802.1ae [802.1ae]. Actually till version02 of the draft, I had a todo list(Appendix A.) which contained updating the status of new algorithms as one of the points in the agenda. However as I got no feedback on the same from the list, I did not go ahead and add any nenw algorithm status. Thanks, Vishwas On 1/22/07, Russ Housley wrote: > Yaakov: > > >Strangely missing is AES/GCM [RFC4106]. > > > >SHOULDn't this be a SHOULD ? > > None of the MUST/SHOULD algorithms are authenticated-encryption > algorithms. This has not been proposed in the past, and it is very > late in the processing of this document to propose it now. > > I'm pleased to entertain adding it the next time this document is updated. > > Russ > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > From housley@vigilsec.com Tue Jan 23 14:49:37 2007 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l0NJnbHX007063 for ; Tue, 23 Jan 2007 14:49:37 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id l0NJnUxW028051 for ; Tue, 23 Jan 2007 14:49:31 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by mit.edu (Spam Firewall) with SMTP id 3AED91B49D4 for ; Tue, 23 Jan 2007 14:49:26 -0500 (EST) Received: (qmail 11068 invoked by uid 0); 23 Jan 2007 19:49:20 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (128.107.28.237) by woodstock.binhost.com with SMTP; 23 Jan 2007 19:49:20 -0000 Message-Id: <7.0.0.16.2.20070123143218.0471f7e8@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 23 Jan 2007 14:32:42 -0500 To: saag@mit.edu From: Shu-jen Chang (by way of Russ Housley ) Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Spam-Score: 1.08 X-Spam-Level: * (1.08) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] NIST announces Draft Requirements and Evaluation Criteria for New Hash Algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 19:49:37 -0000 NIST Wants Comments on Proposed Hash Algorithm Requirements and Evaluation Criteria

The National Institute of Standards and Technology is planning a competition to develop one or more cryptographic hash algorithms to augment and revise the current Secure Hash Standard (Federal Information Processing Standard 180-2). As a first step in this process, NIST is publishing draft minimum acceptability requirements, submission requirements, and evaluation criteria for candidate algorithms ( See the Federal Register Announcement on http://www.nist.gov/hash-function ), and requests public comment by April 27, 2007.
From lrosen@rosenlaw.com Sat Jan 20 17:48:04 2007 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l0KMm4GS029646 for ; Sat, 20 Jan 2007 17:48:04 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id l0KMm0sI025353 for ; Sat, 20 Jan 2007 17:48:01 -0500 (EST) Received: from mail26a.sbc-webhosting.com (mail26a.sbc-webhosting.com [216.173.237.164]) by mit.edu (Spam Firewall) with SMTP id 0FA3C192B32 for ; Sat, 20 Jan 2007 17:47:59 -0500 (EST) Received: from mx85.stngva01.us.mxservers.net (198.173.112.2) by mail26a.sbc-webhosting.com (RS ver 1.0.95vs) with SMTP id 2-0139413277; Sat, 20 Jan 2007 17:47:58 -0500 (EST) Received: from www.rosenlaw.com [216.173.242.124] (EHLO LROSENTOSHIBA) by mx85.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id efa92b54.15784.084.mx85.stngva01.us.mxservers.net; Sat, 20 Jan 2007 17:43:10 -0500 (EST) From: "Lawrence Rosen" To: "'Lakshminath Dondeti'" , "'Russ Housley'" References: <7.0.0.16.2.20070117095212.04035c38@vigilsec.com> <45B28AFE.6090204@qualcomm.com> Date: Sat, 20 Jan 2007 14:45:26 -0800 Organization: Rosenlaw & Einschlag Message-ID: <021901c73ce4$b2907490$0202fea9@LROSENTOSHIBA> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <45B28AFE.6090204@qualcomm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acc824WVVJLaWwVnQS6cyKgn7FIgkwACQfKQ X-Spam: [F=0.0044854881; heur=0.500(-20100); stat=0.010; spamtraq-heur=0.308(2007010918)] X-MAIL-FROM: X-SOURCE-IP: [216.173.242.124] X-Loop-Detect: 1 X-DistLoop-Detect: 1 X-Spam-Score: 0.31 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Thu, 25 Jan 2007 11:44:21 -0500 Cc: ipsec@ietf.org, saag@mit.edu, ietf@ietf.org Subject: Re: [saag] MUST implement AES-CBC for IPsec ESP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: lrosen@rosenlaw.com List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 22:48:04 -0000 > > For ESP encryption algorithms, the document that was sent out for Last > > Call contains the following table: > > > > Requirement Encryption Algorithm (notes) > > ----------- -------------------- > > MUST NULL (1) > > MUST- TripleDES-CBC [RFC2451] > > SHOULD+ AES-CBC with 128-bit keys [RFC3602] > > SHOULD AES-CTR [RFC3686] > > SHOULD NOT DES-CBC [RFC2405] (3) > > > > The Last Call comment suggests changing the "SHOULD+" for AES-CBC to > > "MUST." Are any of these encryption algorithms patented? /Larry Rosen Lawrence Rosen Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com) Stanford University, Lecturer in Law 3001 King Ranch Road, Ukiah, CA 95482 707-485-1242 * cell: 707-478-8932 * fax: 707-485-1243 Skype: LawrenceRosen Author of "Open Source Licensing: Software Freedom and Intellectual Property Law" (Prentice Hall 2004) > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > Sent: Saturday, January 20, 2007 1:35 PM > To: Russ Housley > Cc: ipsec@ietf.org; saag@mit.edu; ietf@ietf.org > Subject: Re: MUST implement AES-CBC for IPsec ESP > > What are the export implications due to this? A compliant ESP > implementation MUST include the DES cipher due to this change. With > status quo, a compliant ESP implementation can be used for integrity > protection alone with NULL encryption. > > regards, > Lakshminath > > Russ Housley wrote: > > During the IETF Last Call for draft-manral-ipsec-rfc4305-bis-errata, we > > received a comment that deserves wide exposure. > > > > For ESP encryption algorithms, the document that was sent out for Last > > Call contains the following table: > > > > Requirement Encryption Algorithm (notes) > > ----------- -------------------- > > MUST NULL (1) > > MUST- TripleDES-CBC [RFC2451] > > SHOULD+ AES-CBC with 128-bit keys [RFC3602] > > SHOULD AES-CTR [RFC3686] > > SHOULD NOT DES-CBC [RFC2405] (3) > > > > The Last Call comment suggests changing the "SHOULD+" for AES-CBC to > > "MUST." > > > > I support this proposed change, and I have asked the author to make this > > change in the document that will be submitted to the IESG for > > consideration on the Telechat on January 25th. If anyone has an > > objection to this change, please speak now. Please send comments on > > this proposed change to the iesg@ietf.org or ietf@ietf.org mailing lists > > by 2007-01-24. > > > > Russ Housley > > Security AD > > > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf From bart.preneel@esat.kuleuven.be Sat Jan 20 18:40:25 2007 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l0KNePqs009933 for ; Sat, 20 Jan 2007 18:40:25 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id l0KNeMqO021865 for ; Sat, 20 Jan 2007 18:40:23 -0500 (EST) Received: from nibbel.kulnet.kuleuven.ac.be (nibbel.kulnet.kuleuven.ac.be [134.58.240.41]) by mit.edu (Spam Firewall) with ESMTP id BCBEC1CD9B9 for ; Sat, 20 Jan 2007 18:40:21 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by nibbel.kulnet.kuleuven.ac.be (Postfix) with ESMTP id 7BE0B4D1E6; Sun, 21 Jan 2007 00:40:20 +0100 (CET) Received: from smtp02.kuleuven.be (lepidus.kulnet.kuleuven.ac.be [134.58.240.72]) by nibbel.kulnet.kuleuven.ac.be (Postfix) with ESMTP id D97C54CF38; Sun, 21 Jan 2007 00:40:19 +0100 (CET) Received: from smtp02.kuleuven.be (localhost.localdomain [127.0.0.1]) by smtp02.kuleuven.be (Postfix) with ESMTP id AB3F02CAAAD; Sun, 21 Jan 2007 00:40:19 +0100 (CET) Received: from bezout.esat.kuleuven.be (bezout.esat.kuleuven.be [134.58.189.101]) by smtp02.kuleuven.be (Postfix) with ESMTP id 995212CAA72; Sun, 21 Jan 2007 00:40:19 +0100 (CET) Date: Sun, 21 Jan 2007 00:40:19 +0100 (CET) From: Bart Preneel X-X-Sender: preneel@bezout.esat.kuleuven.be To: "Steven M. Bellovin" In-Reply-To: <20070120232810.50B9D7660C0@berkshire.machshav.com> Message-ID: References: <7.0.0.16.2.20070117095212.04035c38@vigilsec.com> <45B28AFE.6090204@qualcomm.com> <021901c73ce4$b2907490$0202fea9@LROSENTOSHIBA> <20070120232810.50B9D7660C0@berkshire.machshav.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Thu, 25 Jan 2007 11:44:22 -0500 Cc: ipsec@ietf.org, saag@mit.edu, lrosen@rosenlaw.com, 'Russ Housley' , ietf@ietf.org Subject: Re: [saag] [Ipsec] Re: MUST implement AES-CBC for IPsec ESP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 23:40:25 -0000 Steven, Counter mode is described in: W. Diffie and M. E. Hellman, "Privacy and Authentication: An Introduction to Cryptography," Proceedings of the IEEE, Vol. 67, March 1979, pp. 397-427. See Figure 18 on page 417. http://www-ee.stanford.edu/%7Ehellman/publications/32.pdf -- Bart Preneel ------------------------------------------------------------------------------- Katholieke Universiteit Leuven tel. +32 16 32 11 48 Dept. Electrical Engineering-ESAT / COSIC fax. +32 16 32 19 69 Kasteelpark Arenberg 10, B-3001 Leuven-Heverlee, BELGIUM bart.preneel@esat.kuleuven.be http://www.esat.kuleuven.be/~preneel ------------------------------------------------------------------------------- On Sat, 20 Jan 2007, Steven M. Bellovin wrote: > On Sat, 20 Jan 2007 14:45:26 -0800 > "Lawrence Rosen" wrote: > > > > > For ESP encryption algorithms, the document that was sent out for > > > > Last Call contains the following table: > > > > > > > > Requirement Encryption Algorithm (notes) > > > > ----------- -------------------- > > > > MUST NULL (1) > > > > MUST- TripleDES-CBC [RFC2451] > > > > SHOULD+ AES-CBC with 128-bit keys [RFC3602] > > > > SHOULD AES-CTR [RFC3686] > > > > SHOULD NOT DES-CBC [RFC2405] (3) > > > > > > > > The Last Call comment suggests changing the "SHOULD+" for AES-CBC > > > > to "MUST." > > > > Are any of these encryption algorithms patented? > > [...] > > > That leaves CTR mode. I doubt very much that it's patented, since it's > been very well known for many years and NIST rarely standardizes > patented algorithms in this space (which I know you appreciate...). > However, I don't have any citations to prove this negative. > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm From Jorge.Contreras@wilmerhale.com Sun Jan 21 08:23:10 2007 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l0LDNAJ6003110 for ; Sun, 21 Jan 2007 08:23:10 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id l0LDN6rk013609 for ; Sun, 21 Jan 2007 08:23:06 -0500 (EST) Received: from mail138.messagelabs.com (mail138.messagelabs.com [216.82.249.35]) by mit.edu (Spam Firewall) with SMTP id 74C481B04C1 for ; Sun, 21 Jan 2007 08:23:05 -0500 (EST) X-VirusChecked: Checked X-Env-Sender: Jorge.Contreras@wilmerhale.com X-Msg-Ref: server-12.tower-138.messagelabs.com!1169385783!3579630!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [216.207.71.29] Received: (qmail 24972 invoked from network); 21 Jan 2007 13:23:04 -0000 Received: from unknown (HELO SVDCPAPPDMZ1.wilmerhale.com) (216.207.71.29) by server-12.tower-138.messagelabs.com with SMTP; 21 Jan 2007 13:23:04 -0000 Received: from SDCPEXCCL2MX.wilmerhale.com ([216.207.71.17]) by SVDCPAPPDMZ1.wilmerhale.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 21 Jan 2007 08:23:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 21 Jan 2007 08:23:01 -0500 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <50E312B117033946BA23AA102C8134C67FFF39@SDCPEXCCL2MX.wilmerhale.com> In-reply-to: <20070120232810.50B9D7660C0@berkshire.machshav.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MUST implement AES-CBC for IPsec ESP Thread-Index: Acc86uG2q36yKtPbS8yUyssR1lZAegAc55Mg From: "Contreras, Jorge" To: "Steven M. Bellovin" , X-OriginalArrivalTime: 21 Jan 2007 13:23:02.0932 (UTC) FILETIME=[4736F540:01C73D5F] X-Spam-Score: 0.72 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id l0LDNAJ6003110 X-Mailman-Approved-At: Thu, 25 Jan 2007 11:44:22 -0500 Cc: ipsec@ietf.org, saag@mit.edu, ietf@ietf.org Subject: Re: [saag] MUST implement AES-CBC for IPsec ESP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 13:23:10 -0000 Larry, Please note that any responses to your question "Are any of these encryption algorithms patented?" are being provided by individuals in the spirit of helpfulness and open sharing of information. Neither IETF nor the IETF Trust provide assurances or advice as to whether or not technology covered by IETF standards are covered by patent claims. The exclusive mechanism for soliciting and disclosing patent claims within the context of IETF activity is specified in RFC 3979, as we have discussed before. Please do not take anyone's efforts to respond to your questions as "official" IETF positions, as they are not and may not be relied upon as such. Regards, Jorge > -----Original Message----- > From: Steven M. Bellovin [mailto:smb@cs.columbia.edu] > Sent: Saturday, January 20, 2007 6:28 PM > To: lrosen@rosenlaw.com > Cc: ipsec@ietf.org; ietf@ietf.org; saag@mit.edu > Subject: Re: MUST implement AES-CBC for IPsec ESP > > > On Sat, 20 Jan 2007 14:45:26 -0800 > "Lawrence Rosen" wrote: > > > > > For ESP encryption algorithms, the document that was > sent out for > > > > Last Call contains the following table: > > > > > > > > Requirement Encryption Algorithm (notes) > > > > ----------- -------------------- > > > > MUST NULL (1) > > > > MUST- TripleDES-CBC [RFC2451] > > > > SHOULD+ AES-CBC with 128-bit keys [RFC3602] > > > > SHOULD AES-CTR [RFC3686] > > > > SHOULD NOT DES-CBC [RFC2405] (3) > > > > > > > > The Last Call comment suggests changing the "SHOULD+" > for AES-CBC > > > > to "MUST." > > > > Are any of these encryption algorithms patented? > > > > Almost certainly not. DES was patented, but the patent was never > enforced; it has long since expired. (Trivia: IBM filed a statement > saying that DES was royalty-free *if* used in one of the > NIST-approvedd > modes of operation. But they never went after anyone who used it in > other ways.) To my knowledge, 3DES was never patented; even if it had > been, it was first publicly described in 1979, so I doubt that any > patent would still be valid. > > AES itself had to be unencumbered; see > http://csrc.nist.gov/CryptoToolkit/aes/pre-round1/aes_9709.htm#sec2d . > The designers of Rijndael never even attempted to patent it; see the > text quoted in RFC 3602 or the old Rijndael home page. > > CBC dates from at least 1980 -- I seem to recall 1978, but I > don't have > a citation handy. > > That leaves CTR mode. I doubt very much that it's patented, > since it's > been very well known for many years and NIST rarely standardizes > patented algorithms in this space (which I know you appreciate...). > However, I don't have any citations to prove this negative. > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > From lrosen@rosenlaw.com Sun Jan 21 11:03:31 2007 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l0LG3V35006027 for ; Sun, 21 Jan 2007 11:03:31 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id l0LG3OrH000530 for ; Sun, 21 Jan 2007 11:03:24 -0500 (EST) Received: from mail26c.sbc-webhosting.com (mail26c.sbc-webhosting.com [216.173.237.166]) by mit.edu (Spam Firewall) with SMTP id BAEBC168C62 for ; Sun, 21 Jan 2007 11:03:23 -0500 (EST) Received: from mx87.stngva01.us.mxservers.net (198.173.112.4) by mail26c.sbc-webhosting.com (RS ver 1.0.95vs) with SMTP id 0-0749155400; Sun, 21 Jan 2007 11:03:22 -0500 (EST) Received: from www.rosenlaw.com [216.173.242.124] (EHLO LROSENTOSHIBA) by mx87.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id c2d83b54.28966.073.mx87.stngva01.us.mxservers.net; Sun, 21 Jan 2007 10:56:28 -0500 (EST) From: "Lawrence Rosen" To: "'Contreras, Jorge'" , "'Steven M. Bellovin'" References: <20070120232810.50B9D7660C0@berkshire.machshav.com> <50E312B117033946BA23AA102C8134C67FFF39@SDCPEXCCL2MX.wilmerhale.com> Date: Sun, 21 Jan 2007 08:01:24 -0800 Organization: Rosenlaw & Einschlag Message-ID: <02b201c73d75$691880f0$0202fea9@LROSENTOSHIBA> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <50E312B117033946BA23AA102C8134C67FFF39@SDCPEXCCL2MX.wilmerhale.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acc86uG2q36yKtPbS8yUyssR1lZAegAc55MgAAVBcDA= X-Spam: [F=0.0044854881; heur=0.500(-26100); stat=0.010; spamtraq-heur=0.308(2007010918)] X-MAIL-FROM: X-SOURCE-IP: [216.173.242.124] X-Loop-Detect: 1 X-DistLoop-Detect: 1 X-Spam-Score: 0.43 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Thu, 25 Jan 2007 11:44:22 -0500 Cc: ipsec@ietf.org, saag@mit.edu, ietf@ietf.org Subject: Re: [saag] MUST implement AES-CBC for IPsec ESP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: lrosen@rosenlaw.com List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 16:03:31 -0000 Jorge Contreras wrote: > Please note that any responses to your question "Are any of these > encryption algorithms patented?" are being provided by individuals in the > spirit of helpfulness and open sharing of information. Neither IETF nor > the IETF Trust provide assurances or advice as to whether or not > technology covered by IETF standards are covered by patent claims. The > exclusive mechanism for soliciting and disclosing patent claims within the > context of IETF activity is specified in RFC 3979, as we have discussed > before. Please do not take anyone's efforts to respond to your questions > as "official" IETF positions, as they are not and may not be relied upon > as such. I didn't take anyone's comments on this list as any reassurance of anything other than their own understanding of the situation. I just asked about patent coverage because I wondered if anyone knew. This kind of question comes up at other organizations I work with too. Asking a patent question on an IETF list should not conflict with the "exclusive mechanism" you describe. You should realize that I, perhaps more so than others on this list, would never rely on helpful and open emails on a public IETF list--no matter how expert the writers are--for official reassurances about patents, particularly third party patents. The people here don't read patent claims, nor should they have to for this purpose. That is in part why I am in favor of mandatory licensing by contributors in addition to disclosures. /Larry > -----Original Message----- > From: Contreras, Jorge [mailto:Jorge.Contreras@wilmerhale.com] > Sent: Sunday, January 21, 2007 5:23 AM > To: Steven M. Bellovin; lrosen@rosenlaw.com > Cc: ipsec@ietf.org; ietf@ietf.org; saag@mit.edu > Subject: RE: MUST implement AES-CBC for IPsec ESP > > Larry, > > Please note that any responses to your question "Are any of these > encryption algorithms patented?" are being provided by individuals in the > spirit of helpfulness and open sharing of information. Neither IETF nor > the IETF Trust provide assurances or advice as to whether or not > technology covered by IETF standards are covered by patent claims. The > exclusive mechanism for soliciting and disclosing patent claims within the > context of IETF activity is specified in RFC 3979, as we have discussed > before. Please do not take anyone's efforts to respond to your questions > as "official" IETF positions, as they are not and may not be relied upon > as such. > > Regards, > Jorge > > > > -----Original Message----- > > From: Steven M. Bellovin [mailto:smb@cs.columbia.edu] > > Sent: Saturday, January 20, 2007 6:28 PM > > To: lrosen@rosenlaw.com > > Cc: ipsec@ietf.org; ietf@ietf.org; saag@mit.edu > > Subject: Re: MUST implement AES-CBC for IPsec ESP > > > > > > On Sat, 20 Jan 2007 14:45:26 -0800 > > "Lawrence Rosen" wrote: > > > > > > > For ESP encryption algorithms, the document that was > > sent out for > > > > > Last Call contains the following table: > > > > > > > > > > Requirement Encryption Algorithm (notes) > > > > > ----------- -------------------- > > > > > MUST NULL (1) > > > > > MUST- TripleDES-CBC [RFC2451] > > > > > SHOULD+ AES-CBC with 128-bit keys [RFC3602] > > > > > SHOULD AES-CTR [RFC3686] > > > > > SHOULD NOT DES-CBC [RFC2405] (3) > > > > > > > > > > The Last Call comment suggests changing the "SHOULD+" > > for AES-CBC > > > > > to "MUST." > > > > > > Are any of these encryption algorithms patented? > > > > > > > Almost certainly not. DES was patented, but the patent was never > > enforced; it has long since expired. (Trivia: IBM filed a statement > > saying that DES was royalty-free *if* used in one of the > > NIST-approvedd > > modes of operation. But they never went after anyone who used it in > > other ways.) To my knowledge, 3DES was never patented; even if it had > > been, it was first publicly described in 1979, so I doubt that any > > patent would still be valid. > > > > AES itself had to be unencumbered; see > > http://csrc.nist.gov/CryptoToolkit/aes/pre-round1/aes_9709.htm#sec2d . > > The designers of Rijndael never even attempted to patent it; see the > > text quoted in RFC 3602 or the old Rijndael home page. > > > > CBC dates from at least 1980 -- I seem to recall 1978, but I > > don't have > > a citation handy. > > > > That leaves CTR mode. I doubt very much that it's patented, > > since it's > > been very well known for many years and NIST rarely standardizes > > patented algorithms in this space (which I know you appreciate...). > > However, I don't have any citations to prove this negative. > > > > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf > > From yaakov_s@rad.com Mon Jan 22 06:26:44 2007 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l0MBQhxl012724 for ; Mon, 22 Jan 2007 06:26:43 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id l0MBQQur001395 for ; Mon, 22 Jan 2007 06:26:31 -0500 (EST) Received: from antivir2.rad.co.il (mx2-012.rad.co.il [212.199.240.16]) by mit.edu (Spam Firewall) with ESMTP id 0142F1227A0 for ; Mon, 22 Jan 2007 06:26:23 -0500 (EST) Received: from exrad3.rad.co.il (HELO exrad3.ad.rad.co.il) ([192.114.24.112]) by antivir2.rad.co.il with ESMTP; 22 Jan 2007 13:26:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Jan 2007 13:26:19 +0200 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D030B2257@exrad3.ad.rad.co.il> In-Reply-To: <45B28AFE.6090204@qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MUST implement AES-CBC for IPsec ESP Thread-Index: Acc821KdU2W4+kMdRHC0W/eSTaSLswBPAe/w From: "Yaakov Stein" To: "Russ Housley" X-Spam-Score: 3.5 X-Spam-Level: *** (3.5) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id l0MBQhxl012724 X-Mailman-Approved-At: Thu, 25 Jan 2007 11:44:22 -0500 Cc: ipsec@ietf.org, saag@mit.edu, ietf@ietf.org Subject: Re: [saag] MUST implement AES-CBC for IPsec ESP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 11:26:44 -0000 Russ Housley wrote: > During the IETF Last Call for draft-manral-ipsec-rfc4305-bis-errata, > we received a comment that deserves wide exposure. > > For ESP encryption algorithms, the document that was sent out for Last > Call contains the following table: > > Requirement Encryption Algorithm (notes) > ----------- -------------------- > MUST NULL (1) > MUST- TripleDES-CBC [RFC2451] > SHOULD+ AES-CBC with 128-bit keys [RFC3602] > SHOULD AES-CTR [RFC3686] > SHOULD NOT DES-CBC [RFC2405] (3) > > The Last Call comment suggests changing the "SHOULD+" for AES-CBC to > "MUST." > > I support this proposed change, and I have asked the author to make > this change in the document that will be submitted to the IESG for > consideration on the Telechat on January 25th. If anyone has an > objection to this change, please speak now. Please send comments on > this proposed change to the iesg@ietf.org or ietf@ietf.org mailing > lists by 2007-01-24. > > Russ Housley > Security AD Strangely missing is AES/GCM [RFC4106]. SHOULDn't this be a SHOULD ? Y(J)S From tglassey@earthlink.net Mon Jan 22 06:40:07 2007 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l0MBe7J2016716 for ; Mon, 22 Jan 2007 06:40:07 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id l0MBdovP022742 for ; Mon, 22 Jan 2007 06:39:50 -0500 (EST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by mit.edu (Spam Firewall) with ESMTP id CF9B920F9AB for ; Mon, 22 Jan 2007 06:39:46 -0500 (EST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=UFdPVOCb+EYAFPdpKhjjq+SZgo3RXliicY/AdddlFwKsgX3gOrSqU6QnOGCM0JJ5; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:x-mimeole:X-ELNK-Trace:X-Originating-IP; Received: from [66.245.141.79] (helo=gw) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1H8xWN-0005G0-Bb; Mon, 22 Jan 2007 06:39:31 -0500 Message-ID: <004c01c73e1a$08a98e30$2101a8c0@home.glassey.com> From: "todd glassey" To: "Contreras, Jorge" , "Steven M. Bellovin" , References: <50E312B117033946BA23AA102C8134C67FFF39@SDCPEXCCL2MX.wilmerhale.com> Date: Mon, 22 Jan 2007 03:39:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7935f8bd878428ddd31aed775c4abc790c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.245.141.79 X-Spam-Score: 0.13 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Thu, 25 Jan 2007 11:44:22 -0500 Cc: ipsec@ietf.org, saag@mit.edu, ietf@ietf.org Subject: Re: [saag] MUST implement AES-CBC for IPsec ESP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 11:40:07 -0000 Which is why Jorge that the current IP Disclosure model is a joke. Ask the simple and rudimentary question as to "What are the implications of not disclosing known IP constraints?" - nothing... are they that the IESG wont let you participate with the IETF any more? Are they that the IP that is underway in a standards process is to be stopped? The point is that there is in the real world a consequence to everything - except in the IETF where the consequences have been omitted or eliminated in anything but telling the IETF how screwed up it is. Nice. Todd Glassey ----- Original Message ----- From: "Contreras, Jorge" To: "Steven M. Bellovin" ; Cc: ; ; Sent: Sunday, January 21, 2007 5:23 AM Subject: RE: MUST implement AES-CBC for IPsec ESP Larry, Please note that any responses to your question "Are any of these encryption algorithms patented?" are being provided by individuals in the spirit of helpfulness and open sharing of information. Neither IETF nor the IETF Trust provide assurances or advice as to whether or not technology covered by IETF standards are covered by patent claims. The exclusive mechanism for soliciting and disclosing patent claims within the context of IETF activity is specified in RFC 3979, as we have discussed before. Please do not take anyone's efforts to respond to your questions as "official" IETF positions, as they are not and may not be relied upon as such. Regards, Jorge > -----Original Message----- > From: Steven M. Bellovin [mailto:smb@cs.columbia.edu] > Sent: Saturday, January 20, 2007 6:28 PM > To: lrosen@rosenlaw.com > Cc: ipsec@ietf.org; ietf@ietf.org; saag@mit.edu > Subject: Re: MUST implement AES-CBC for IPsec ESP > > > On Sat, 20 Jan 2007 14:45:26 -0800 > "Lawrence Rosen" wrote: > > > > > For ESP encryption algorithms, the document that was > sent out for > > > > Last Call contains the following table: > > > > > > > > Requirement Encryption Algorithm (notes) > > > > ----------- -------------------- > > > > MUST NULL (1) > > > > MUST- TripleDES-CBC [RFC2451] > > > > SHOULD+ AES-CBC with 128-bit keys [RFC3602] > > > > SHOULD AES-CTR [RFC3686] > > > > SHOULD NOT DES-CBC [RFC2405] (3) > > > > > > > > The Last Call comment suggests changing the "SHOULD+" > for AES-CBC > > > > to "MUST." > > > > Are any of these encryption algorithms patented? > > > > Almost certainly not. DES was patented, but the patent was never > enforced; it has long since expired. (Trivia: IBM filed a statement > saying that DES was royalty-free *if* used in one of the > NIST-approvedd > modes of operation. But they never went after anyone who used it in > other ways.) To my knowledge, 3DES was never patented; even if it had > been, it was first publicly described in 1979, so I doubt that any > patent would still be valid. > > AES itself had to be unencumbered; see > http://csrc.nist.gov/CryptoToolkit/aes/pre-round1/aes_9709.htm#sec2d . > The designers of Rijndael never even attempted to patent it; see the > text quoted in RFC 3602 or the old Rijndael home page. > > CBC dates from at least 1980 -- I seem to recall 1978, but I > don't have > a citation handy. > > That leaves CTR mode. I doubt very much that it's patented, > since it's > been very well known for many years and NIST rarely standardizes > patented algorithms in this space (which I know you appreciate...). > However, I don't have any citations to prove this negative. > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From dean@av8.com Mon Jan 22 11:56:08 2007 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l0MGu8cv003566 for ; Mon, 22 Jan 2007 11:56:08 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id l0MGtpgs013729 for ; Mon, 22 Jan 2007 11:55:51 -0500 (EST) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 3B87A167560 for ; Mon, 22 Jan 2007 11:46:01 -0500 (EST) Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id l0MGjD6D017151 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 22 Jan 2007 11:45:18 -0500 Date: Mon, 22 Jan 2007 11:45:13 -0500 (EST) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: "Contreras, Jorge" In-Reply-To: <50E312B117033946BA23AA102C8134C67FFF39@SDCPEXCCL2MX.wilmerhale.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Thu, 25 Jan 2007 11:44:22 -0500 Cc: ipsec@ietf.org, saag@mit.edu, lrosen@rosenlaw.com, ietf@ietf.org Subject: Re: [saag] MUST implement AES-CBC for IPsec ESP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 16:56:08 -0000 Attorney Contreras has mis-spoken regarding RFC3979. Steven Bellovin previously disputed (in his official role as IETF IPR WG Chair), my claim that RFC3979 controls IPR policy for the IETF. The assertion by Bellovin was appealed by Anderson to the IESG, and subsequently to the IAB. While professional dishonesty in Bellovin's claim was asserted in the appeals by Dean Anderson, neither the IESG nor the IAB felt that Bellovin was either wrong or dishonest in his claim that RFC3669 controlled IETF policy rather than RFC3979, as Anderson asserted. Therefore, it seems that, for now, RFC3669 controls, per Bellovin, and the IESG and IAB ruling on the matter. http://www1.ietf.org/mail-archive/web/ietf/current/msg37557.html http://www.iab.org/appeals/2006-04-18-anderson-appeal.html http://www.iab.org/appeals/2006-07-13-anderson-response.html Further references to the appeals are available on request, but can be found on the IESG and IAB websites. Preparation of lawsuit regarding this and other issues is under way. Dean Anderson Av8 Internet, Inc On Sun, 21 Jan 2007, Contreras, Jorge wrote: > Larry, > > Please note that any responses to your question "Are any of these > encryption algorithms patented?" are being provided by individuals in > the spirit of helpfulness and open sharing of information. Neither > IETF nor the IETF Trust provide assurances or advice as to whether or > not technology covered by IETF standards are covered by patent claims. > The exclusive mechanism for soliciting and disclosing patent claims > within the context of IETF activity is specified in RFC 3979, as we > have discussed before. Please do not take anyone's efforts to respond > to your questions as "official" IETF positions, as they are not and > may not be relied upon as such. > > Regards, > Jorge > > > > -----Original Message----- > > From: Steven M. Bellovin [mailto:smb@cs.columbia.edu] > > Sent: Saturday, January 20, 2007 6:28 PM > > To: lrosen@rosenlaw.com > > Cc: ipsec@ietf.org; ietf@ietf.org; saag@mit.edu > > Subject: Re: MUST implement AES-CBC for IPsec ESP > > > > > > On Sat, 20 Jan 2007 14:45:26 -0800 > > "Lawrence Rosen" wrote: > > > > > > > For ESP encryption algorithms, the document that was > > sent out for > > > > > Last Call contains the following table: > > > > > > > > > > Requirement Encryption Algorithm (notes) > > > > > ----------- -------------------- > > > > > MUST NULL (1) > > > > > MUST- TripleDES-CBC [RFC2451] > > > > > SHOULD+ AES-CBC with 128-bit keys [RFC3602] > > > > > SHOULD AES-CTR [RFC3686] > > > > > SHOULD NOT DES-CBC [RFC2405] (3) > > > > > > > > > > The Last Call comment suggests changing the "SHOULD+" > > for AES-CBC > > > > > to "MUST." > > > > > > Are any of these encryption algorithms patented? > > > > > > > Almost certainly not. DES was patented, but the patent was never > > enforced; it has long since expired. (Trivia: IBM filed a statement > > saying that DES was royalty-free *if* used in one of the > > NIST-approvedd > > modes of operation. But they never went after anyone who used it in > > other ways.) To my knowledge, 3DES was never patented; even if it had > > been, it was first publicly described in 1979, so I doubt that any > > patent would still be valid. > > > > AES itself had to be unencumbered; see > > http://csrc.nist.gov/CryptoToolkit/aes/pre-round1/aes_9709.htm#sec2d . > > The designers of Rijndael never even attempted to patent it; see the > > text quoted in RFC 3602 or the old Rijndael home page. > > > > CBC dates from at least 1980 -- I seem to recall 1978, but I > > don't have > > a citation handy. > > > > That leaves CTR mode. I doubt very much that it's patented, > > since it's > > been very well known for many years and NIST rarely standardizes > > patented algorithms in this space (which I know you appreciate...). > > However, I don't have any citations to prove this negative. > > > > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From rja@extremenetworks.com Tue Jan 23 15:54:28 2007 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l0NKsS3P019681 for ; Tue, 23 Jan 2007 15:54:28 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id l0NKsPZw021998 for ; Tue, 23 Jan 2007 15:54:26 -0500 (EST) Received: from centrmmtao01.cox.net (centrmmtao01.cox.net [70.168.83.83]) by mit.edu (Spam Firewall) with ESMTP id 47888160429 for ; Tue, 23 Jan 2007 15:54:24 -0500 (EST) Received: from eastrmimpo01.cox.net ([68.1.16.119]) by centrmmtao01.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070123205424.JVNO24316.centrmmtao01.cox.net@eastrmimpo01.cox.net> for ; Tue, 23 Jan 2007 15:54:24 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id EkuQ1W00G0pnMhQ0000000; Tue, 23 Jan 2007 15:54:24 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: saag@mit.edu From: RJ Atkinson Date: Tue, 23 Jan 2007 15:54:23 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.13 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Thu, 25 Jan 2007 11:44:22 -0500 Subject: [saag] labelled networking & IPsec X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 20:54:28 -0000 http://www.ietf.org/rfc/rfc2407.txt If one looks in RFC-2407, there is some support already for adding sensitivity-labels into IPsec Security Associations. Its presence in that RFC is not accidental, as this kind of labelled network deployment was known to the IPsec WG chair(s) and some document authors back when the IPsec DoI was put together for ISAKMP/IKE. For example, please see Page 17, where there is explicit definition of things like "labelled domain identifier" (e.g. some number that might mean "US DoE", "US DoD", "NATO" "UK MoD" and so forth), "secrecy level" (e.g. some number that might mean unclassified, secret, top secret), "secrecy compartment bitmap" (e.g. compartments within a given secrecy level). I believe there is at least one implementation of ISAKMP/IKE that uses this, using a Labelled Domain Identifier in accordance with Section 6.8 of that same RFC. It isn't clear to me that a lot of IETF standards work would be required to deploy this capability. There might be some, in the area of clarifying the semantics of various bits. There might also need to be a document or two put together within each deployment community, to ease deployment of IPsec within a labelled network. I don't think there is a huge amount of work needed, however. Yours, Ran rja@extremenetworks.com From nw141292@binky.Central.Sun.COM Thu Jan 25 13:13:53 2007 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l0PIDpmT018300 for ; Thu, 25 Jan 2007 13:13:51 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id l0PIDbcD010679 for ; Thu, 25 Jan 2007 13:13:37 -0500 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by mit.edu (Spam Firewall) with ESMTP id B9A5E1F5FF4 for ; Thu, 25 Jan 2007 13:12:51 -0500 (EST) Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0PICo4G008625 for ; Thu, 25 Jan 2007 11:12:50 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l0PICnDM011363 for ; Thu, 25 Jan 2007 11:12:49 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id l0PICMou027020; Thu, 25 Jan 2007 12:12:22 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id l0PICKmb027019; Thu, 25 Jan 2007 12:12:20 -0600 (CST) Date: Thu, 25 Jan 2007 12:12:20 -0600 From: Nicolas Williams To: todd glassey Message-ID: <20070125181219.GF12135@binky.Central.Sun.COM> Mail-Followup-To: todd glassey , "Contreras, Jorge" , "Steven M. Bellovin" , lrosen@rosenlaw.com, ipsec@ietf.org, saag@mit.edu, ietf@ietf.org References: <50E312B117033946BA23AA102C8134C67FFF39@SDCPEXCCL2MX.wilmerhale.com> <004c01c73e1a$08a98e30$2101a8c0@home.glassey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004c01c73e1a$08a98e30$2101a8c0@home.glassey.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: ipsec@ietf.org, "Contreras, Jorge" , ietf@ietf.org, saag@mit.edu, lrosen@rosenlaw.com Subject: Re: [saag] MUST implement AES-CBC for IPsec ESP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 18:13:53 -0000 On Mon, Jan 22, 2007 at 03:39:38AM -0800, todd glassey wrote: > Which is why Jorge that the current IP Disclosure model is a joke. > > Ask the simple and rudimentary question as to "What are the implications of > not disclosing known IP constraints?" - nothing... are they that the IESG > wont let you participate with the IETF any more? Are they that the IP that > is underway in a standards process is to be stopped? > > The point is that there is in the real world a consequence to everything - > except in the IETF where the consequences have been omitted or eliminated in > anything but telling the IETF how screwed up it is. I don't agree. The IETF, as an open, non-member, consensus-driven organization cannot shield the Internet from the vaguaries of patent, inport, export, and other laws around the world. It can only apply its stamp of approval (in the form of Standards Tack labels on specifications published by the RFC-Editor), or else withhold its approval. And it can demand disclosure of specification author's knowledge of IPR claims. That's about it, that's about all the IETF can do. Get over it. Why are we having this discussion here, now? What does this have to do with this particular I-D? And the irony is that the risk of future IPR claims w.r.t. the technologies promoted in this I-D is as near zero as we could get to. Nico -- From fernando@gont.com.ar Mon Feb 12 19:09:31 2007 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l1D09Vwg010201 for ; Mon, 12 Feb 2007 19:09:31 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id l1D09OFl021307 for ; Mon, 12 Feb 2007 19:09:24 -0500 (EST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by mit.edu (Spam Firewall) with ESMTP id ECE8925CF0A for ; Mon, 12 Feb 2007 19:09:22 -0500 (EST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id BFDAFF0C4D0 for ; Mon, 12 Feb 2007 21:09:25 -0300 (ART) Received: from fgont.gont.com.ar (3-176-231-201.fibertel.com.ar [201.231.176.3]) (authenticated bits=0) by venus.xmundo.net (8.12.11.20060308/8.12.11) with ESMTP id l1D09Nds005280 for ; Mon, 12 Feb 2007 21:09:24 -0300 Message-Id: <200702130009.l1D09Nds005280@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 12 Feb 2007 21:08:24 -0300 To: saag@mit.edu From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Mon, 12 Feb 2007 21:09:24 -0300 (ART) X-Spam-Score: 0.13 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Port randomization draft X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2007 00:09:31 -0000 Folks, We have published a revision of our port randomization draft (draft-larsen-tsvwg-port-randomization). The draft proposes a RFC1948-like scheme for randomizing the ephemeral port numbers used by clients. This can be of help for any off-path attack that requires the attacker to guess the four-tuple that identifies the connection to be attacked. The draft is targetted at tsvwg because the same stuff can be applied to other protocols. But most (all?) of the work on this has been done mainly for TCP. The draft is available at http://www.gont.com.ar/drafts/port-randomization/draft-larsen-tsvwg-port-randomization-01.txt , and will soon be available at the usual places. Any feedback will be more than welcome. Thanks! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From hartmans@MIT.EDU Thu Feb 15 18:53:13 2007 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l1FNrD7t027499 for ; Thu, 15 Feb 2007 18:53:13 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id l1FNr6Z9009560 for ; Thu, 15 Feb 2007 18:53:07 -0500 (EST) Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id A28A9251A1B for ; Thu, 15 Feb 2007 18:53:06 -0500 (EST) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id F201CE031B; Thu, 15 Feb 2007 18:52:57 -0500 (EST) From: Sam Hartman To: ietf-krb-wg@anl.gov, saag@MIT.EDU Date: Thu, 15 Feb 2007 18:52:57 -0500 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Seeking co-chair for the Kerberos Working Group X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2007 23:53:13 -0000 I'm seeking a second chair for the Kerberos working group to help Jeff Hutzelman in running the group. Please send nominations (self nominations encouraged) including a description of why you think the candidate is qualified to me within the next two weeks. Candidates need to be willing to dedicate a few hours a week to the task and plan on attending most IETF meetings. The following are requirements for the position: 1) Success at motivating busy participants to spend time on the working group and at recruiting new reviewers and editors. 2)Willing to guide a group of strongly opinionated participants including the AD who is active in the group making sure that the group moves towards consensus and that all sides are heard. 3) Familiarity with Kerberos. 4) Familiarity with IETF process. From housley@vigilsec.com Fri Feb 23 07:37:25 2007 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l1NCbP5a023377 for ; Fri, 23 Feb 2007 07:37:25 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id l1NCb9ka014041 for ; Fri, 23 Feb 2007 07:37:09 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by mit.edu (Spam Firewall) with SMTP id 4117127FE4E for ; Fri, 23 Feb 2007 07:37:09 -0500 (EST) Received: (qmail 18040 invoked by uid 0); 23 Feb 2007 12:37:08 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 23 Feb 2007 12:37:08 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 23 Feb 2007 07:37:06 -0500 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070223123709.4117127FE4E@mit.edu> X-Spam-Score: 3.542 X-Spam-Level: *** (3.542) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] SAAG Session time slot in Prague X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 12:37:25 -0000 We are having a very hard time with the schedule this time. I agreed to shift the SAAG session for Prague in order to help resolve some of the trouble. Russ >To: Dinara.Suleymanova@neustar.biz >Date: Thu, 22 Feb 2007 19:44:50 -0500 (EST) >From: sandy@tislabs.com (Sandy Murphy) >Cc: wgchairs@ietf.org >Subject: Re: 68th IETF - DRAFT Meeting Agenda for Review > >I just noticed that the saag meeting was moved from Thursday to Friday. >Any chance it will move back to its originally scheduled (and typical) >Thursday? > >--Sandy From narten@us.ibm.com Tue Feb 27 22:11:05 2007 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l1S3B5nC031571 for ; Tue, 27 Feb 2007 22:11:05 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id l1S3Awkh022828 for ; Tue, 27 Feb 2007 22:10:59 -0500 (EST) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id EF0C61F95D9 for ; Tue, 27 Feb 2007 22:10:57 -0500 (EST) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l1S3Be4M012081 for ; Tue, 27 Feb 2007 22:11:40 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l1S3AtAO109694 for ; Tue, 27 Feb 2007 22:10:55 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l1S3AtmR006652 for ; Tue, 27 Feb 2007 22:10:55 -0500 Received: from cichlid ([9.67.175.182]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l1S3ArgZ006637 for ; Tue, 27 Feb 2007 22:10:54 -0500 Received: from cichlid (localhost.localdomain [127.0.0.1]) by cichlid (8.13.8/8.12.5) with ESMTP id l1S3Ap2X018469 for ; Tue, 27 Feb 2007 22:10:52 -0500 Message-Id: <200702280310.l1S3Ap2X018469@cichlid> To: saag@mit.edu Date: Tue, 27 Feb 2007 22:10:50 -0500 From: Thomas Narten X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] NIST profiles for IPv6 (including IPsec) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2007 03:11:05 -0000 Dunno if folk here have looked at these, but NIST has issued draft profiles for IPv6 and IPsec: http://www.antd.nist.gov/usgv6-v1-comments.html These profiles are likely to have a siginificant impact on what vendors do and what USG buys. Have folk looked at the IPsec recommendations and do you think they are reasonable? (Comments are due this Friday.) One thing I note is that AH is optional rather than mandatory, with ESP and NULL encryption used for authentication where needed. Is that they way the market has gone at this point? Thomas From paul.hoffman@vpnc.org Tue Feb 27 23:01:04 2007 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l1S4121x010373 for ; Tue, 27 Feb 2007 23:01:04 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id l1S40tSN003972 for ; Tue, 27 Feb 2007 23:00:56 -0500 (EST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 2FBE592DBA for ; Tue, 27 Feb 2007 23:00:51 -0500 (EST) Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1S40l8B047504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Feb 2007 21:00:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200702280310.l1S3Ap2X018469@cichlid> References: <200702280310.l1S3Ap2X018469@cichlid> Date: Tue, 27 Feb 2007 19:58:49 -0800 To: Thomas Narten , saag@mit.edu From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] NIST profiles for IPv6 (including IPsec) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2007 04:01:04 -0000 At 10:10 PM -0500 2/27/07, Thomas Narten wrote: >These profiles are likely to have a siginificant impact on what >vendors do and what USG buys. It would be grand if this had an effect on what vendors do; they are doing too little now. For example, VPNC cannot test either IKEv1 or IKEv2 and IPv6 because we can't even find five of our members who say they support it (much less interoperate). >Have folk looked at the IPsec recommendations and do you think they >are reasonable? (Comments are due this Friday.) It is not clear what you mean by "IPse recommendations". The document just repeats the MUST/SHOULD/MAY language of the RFCs. The one place where the document could be greatly improved is to completely discount use of manual keying. This would eliminate some of the problems listed with the newer modes for AES, and would simplify some other requirements. A fair number of IPsec VPN systems don't even support manual keying any more. Alas, there are still some folks in the USgovt who demand it. >One thing I note is that AH is optional rather than mandatory, with >ESP and NULL encryption used for authentication where needed. Is that >they way the market has gone at this point? Yes. We are seeing fewer new systems with AH in the the administrative UIs. --Paul Hoffman, Director --VPN Consortium From narten@us.ibm.com Wed Feb 28 08:42:19 2007 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l1SDgJ6I020337 for ; Wed, 28 Feb 2007 08:42:19 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id l1SDg9Ha018005 for ; Wed, 28 Feb 2007 08:42:09 -0500 (EST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 526901F1D16 for ; Wed, 28 Feb 2007 08:42:06 -0500 (EST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l1SDg0WN023355 for ; Wed, 28 Feb 2007 08:42:00 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l1SDg0IK237942 for ; Wed, 28 Feb 2007 08:42:00 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l1SDg03I004068 for ; Wed, 28 Feb 2007 08:42:00 -0500 Received: from cichlid ([9.67.175.182]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l1SDg0ud004041; Wed, 28 Feb 2007 08:42:00 -0500 Received: from cichlid (localhost.localdomain [127.0.0.1]) by cichlid (8.13.8/8.12.5) with ESMTP id l1SDfwFT030300; Wed, 28 Feb 2007 08:41:59 -0500 Message-Id: <200702281341.l1SDfwFT030300@cichlid> To: Paul Hoffman In-reply-to: References: <200702280310.l1S3Ap2X018469@cichlid> Comments: In-reply-to Paul Hoffman message dated "Tue, 27 Feb 2007 19:58:49 -0800." Date: Wed, 28 Feb 2007 08:41:58 -0500 From: Thomas Narten X-Spam-Score: 3.2 X-Spam-Level: *** (3.2) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] NIST profiles for IPv6 (including IPsec) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2007 13:42:19 -0000 > At 10:10 PM -0500 2/27/07, Thomas Narten wrote: > >These profiles are likely to have a siginificant impact on what > >vendors do and what USG buys. > It would be grand if this had an effect on what vendors do; they are > doing too little now. For example, VPNC cannot test either IKEv1 or > IKEv2 and IPv6 because we can't even find five of our members who say > they support it (much less interoperate). The other piece of the puzzle is the OMB mandate (http://www.whitehouse.gov/omb/memoranda/fy2005/m05-22.pdf). It says (among other things): To avoid unnecessary costs in the future, you should, to the maximum extent practicable, ensure that all new IT procurements are IPv6 compliant. Any exceptions to the use of IPv6 require the agency's CIO to give advance, written approval. My assumption is that the NIST profile (as well as the DoD one at http://jitc.fhu.disa.mil/adv_ip/register/register.html) will effectively define what "compliance" means. Hence, vendors will likely implement what the profiles call for. > >Have folk looked at the IPsec recommendations and do you think they > >are reasonable? (Comments are due this Friday.) > It is not clear what you mean by "IPse recommendations". The document > just repeats the MUST/SHOULD/MAY language of the RFCs. Except, I suspect that MUST will mean your product MUST support the RFC, if you want to be eligible for general USG purchase, whereas SHOULD means SHOULD. So even if the language is largely the same, the market implications are different. I think the key word is "compliance". Thomas From kent@bbn.com Wed Feb 28 21:37:47 2007 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l212blKX021233 for ; Wed, 28 Feb 2007 21:37:47 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id l212bfIp010221 for ; Wed, 28 Feb 2007 21:37:41 -0500 (EST) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by mit.edu (Spam Firewall) with ESMTP id 869F41F312F for ; Wed, 28 Feb 2007 21:37:40 -0500 (EST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[169.223.66.230]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HMbAo-0001Vt-42; Wed, 28 Feb 2007 21:37:40 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <200702280310.l1S3Ap2X018469@cichlid> References: <200702280310.l1S3Ap2X018469@cichlid> Date: Wed, 28 Feb 2007 20:27:27 -0500 To: Thomas Narten From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] NIST profiles for IPv6 (including IPsec) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2007 02:37:47 -0000 At 10:10 PM -0500 2/27/07, Thomas Narten wrote: >Dunno if folk here have looked at these, but NIST has issued draft >profiles for IPv6 and IPsec: > > http://www.antd.nist.gov/usgv6-v1-comments.html > >These profiles are likely to have a siginificant impact on what >vendors do and what USG buys. > >Have folk looked at the IPsec recommendations and do you think they >are reasonable? (Comments are due this Friday.) > >One thing I note is that AH is optional rather than mandatory, with >ESP and NULL encryption used for authentication where needed. Is that >they way the market has gone at this point? I don't know about what current products offer, but 4301 says that support for AH is optional, and for a long time we have suggested using ESP with NULL encryption in lieu of AH. Steve From thomas.g.otto@googlemail.com Thu Mar 1 07:11:00 2007 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l21CB0Mw010599 for ; Thu, 1 Mar 2007 07:11:00 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id l21CApWa010605 for ; Thu, 1 Mar 2007 07:10:51 -0500 (EST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mit.edu (Spam Firewall) with ESMTP id 6BDE42D234A for ; Thu, 1 Mar 2007 07:10:51 -0500 (EST) Received: by ug-out-1314.google.com with SMTP id m2so373740uge for ; Thu, 01 Mar 2007 04:10:50 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:user-agent:mime-version:to:subject:content-type:content-transfer-encoding:from; b=rFj9QR9jJw6KPKto3R9QbEEmBdwB99agFpR8PDzq4jqgQbncOMoj/W0bkgjoNly5pRmCSQTHXgrtXkSNUHjkd4HH3cR3XNTAqu8Vc5A8PH2rm5cV2VJdwGPDseh9QHVPrCYR+oXV6fYgMppxc068XwEYAQL4IW02nWXYzZhwq/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:user-agent:mime-version:to:subject:content-type:content-transfer-encoding:from; b=UQ7MelCYvxBmfC6jn9abclL6+SJKBeCjVgBynZr4ECZp3z1Z6b9SvMfFOVnV09WmA22V/xmTEmXasfjeZEL2+EtrLak9oqv6dkdLQ4nGVN2kz7AuLpr9mg6yOjiUm+IpzzLHqlDyzhWb0rhSfX88a9QuQ0UV76IacwX9xRwBfgg= Received: by 10.67.19.17 with SMTP id w17mr1997270ugi.1172751050395; Thu, 01 Mar 2007 04:10:50 -0800 (PST) Received: from ?192.168.0.6? ( [213.54.146.169]) by mx.google.com with ESMTP id e9sm6997928muf.2007.03.01.04.10.48; Thu, 01 Mar 2007 04:10:49 -0800 (PST) Message-ID: <45E6C2C8.9010707@tu-bs.de> Date: Thu, 01 Mar 2007 13:10:48 +0100 User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: saag@mit.edu Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit From: Thomas Otto X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Thesis "Extensible Network Access Authentication" X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2007 12:11:00 -0000 Hi all, I would like to give a pointer to my recent announcment in EMU Working Group. There, you can find a download link for my diploma thesis about Extensible Network Access Authentication (which is with 180 pages quite extensive ;-)) The URL is http://www1.ietf.org/mail-archive/web/emu/current/msg00380.html Thomas (PS. If you think other IETF mailing lists might be more suitable for this announcement, I'd be glad if you forward it there. Thanks! If you want directly to me, my email is t.otto@tu-bs.de ) From rja@extremenetworks.com Fri Mar 2 11:43:06 2007 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l22Gh6TB032645 for ; Fri, 2 Mar 2007 11:43:06 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id l22GgxFF018335 for ; Fri, 2 Mar 2007 11:42:59 -0500 (EST) Received: from smtp1.extremenetworks.com (unknown [207.179.9.76]) by mit.edu (Spam Firewall) with ESMTP id AA7F52CDC0A for ; Fri, 2 Mar 2007 11:42:58 -0500 (EST) Received: from [10.30.20.240] (unknown [10.30.20.240]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 58AFD7946 for ; Fri, 2 Mar 2007 08:42:47 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: saag@mit.edu From: RJ Atkinson Date: Fri, 2 Mar 2007 11:42:46 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] NIST profiles for IPv6 (including IPsec) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2007 16:43:06 -0000 It is important to differentiate between two different deployment segments in this discussion, IMHO. In the specific context of VPNs, and the VPN implementers have dominated the IPsec WG for some years now, AH is not very popular. (The reasons don't really matter in this thread, so please lets not rat hole in that discussion.) In the broader context of IPv6 (i.e. outside of VPNs), implementation of AH remains important. AH and "ESP with Null Encryption" provide different security properties. For VPNs, those differences might or might not matter (opinons vary and, separately, deployment circumstances also vary). For other uses, that is not including VPNs, the differences in security properties can matter a great deal. To pick one example, ESP with Null encryption can't protect some routing protocols (e.g. PIM) because ESP cannot authenticate IP-layer options (which are used/needed by the routing protocol). I am told that this is why AH is the IETF standard approach to PIM routing protocol authentication, though I'm far from a PIM expert. For some other routing protocols, for example OSPFv3, AH is also the standard authentication approach. There is significant and growing interest within the router implementer community in using AH to protect IPv4 interior routing protocols -- and in the abstract AH is probably a better approach than the sundry other mechanisms we have for RIPv2 or OSPFv2.[1] (I/IS-IS uses the link-layer, not IP, so neither AH nor ESP are applicable to I/IS-IS.) So, the IPsec document set's words are not the whole answer with respect to NIST's IPv6 profile (or any other IPv6 profile). One has to also consider what other IETF standards-track documents say. To the extent that a profile requires some IETF protocol FOO (e.g. PIM) and the RFCs specifying FOO require support for AH (as PIM's reportedly do), then AH is also required by the profile implicitly (at least for those implementations that support the FOO protocol, for example PIM for IPv6). Ideally, folks who write IPv6 feature profiles will sort through these dependencies and make all these requirements explicit, although that can be a lot of additional effort to build the total specification dependency graph. So, implementers might want to consider that some authors of such profiles might not document things in such an explicit manner and some implicit requirements might also exist. Yours, Ran [1] AH did not exist at the time that RIPv2 Authentication and OSPFv2 Authentication initially were deployed. Both of those built-in authentication mechanisms have substantial deployments and have had substantial deployments for years. Transitioning a given deployment from the existing mechanisms to AH is far from being a trivial operational task. For a new deployment, choosing to use AH instead of a built-in mechanism is easier -- provided all of one's OSPFv2 and/or RIPv2 routers support that deployment option. From dougm@nist.gov Fri Mar 2 12:13:04 2007 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l22HD3WD007613 for ; Fri, 2 Mar 2007 12:13:03 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id l22HCsbK009262 for ; Fri, 2 Mar 2007 12:12:55 -0500 (EST) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 3B22493E18 for ; Fri, 2 Mar 2007 12:12:54 -0500 (EST) Received: from [127.0.0.1] (16-140.antd.nist.gov [129.6.140.16]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id l22HCeSu027827; Fri, 2 Mar 2007 12:12:44 -0500 Message-ID: <45E85B07.2050406@nist.gov> Date: Fri, 02 Mar 2007 12:12:39 -0500 From: Doug Montgomery Organization: http://www.antd.nist.gov/ User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: RJ Atkinson References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: dougm@nist.gov X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] NIST profiles for IPv6 (including IPsec) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2007 17:13:04 -0000 RJ Atkinson wrote: > Ideally, folks who write IPv6 feature profiles will sort > through these dependencies and make all these requirements explicit, > although that can be a lot of additional effort to build the total > specification dependency graph. So, implementers might want > to consider that some authors of such profiles might not document > things in such an explicit manner and some implicit requirements > might also exist. > We tried, .... it is a lot of effort, and can be quite an *interesting* exercise with some IETF specs. We are aware that we need to reconcile the "S+" for OSPF-AUTH (RFC 4552) vs for "O" for AH in routers. For this version that is not technically in conflict, but the issue might be better documented and going forward might need to be revisited. Other than that, we solicit comments (http://www.antd.nist.gov/usgv6-v1-comments.html) on other requirements (explicit or implicit) that you feel should be clarified in the profile. thanks dougm From stephen.farrell@cs.tcd.ie Mon Mar 5 05:05:36 2007 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l25A5a9e022986 for ; Mon, 5 Mar 2007 05:05:36 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id l25A5SbF021694 for ; Mon, 5 Mar 2007 05:05:28 -0500 (EST) Received: from imx2.tcd.ie (wpad.iss.tcd.ie [134.226.1.156]) by mit.edu (Spam Firewall) with ESMTP id 17E6933349B for ; Mon, 5 Mar 2007 05:05:28 -0500 (EST) Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 580D5680BC for ; Mon, 5 Mar 2007 10:05:27 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A063E654BB0; Mon, 05 Mar 2007 10:05:27 +0000 Received: from [134.226.62.103] (cswireless62-103.cs.tcd.ie [134.226.62.103]) by imx2.tcd.ie (Postfix) with ESMTP id 4602C680BC for ; Mon, 5 Mar 2007 10:05:27 +0000 (GMT) Message-ID: <45EBEBB8.4000707@cs.tcd.ie> Date: Mon, 05 Mar 2007 10:06:48 +0000 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: saag@mit.edu Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A163E654BB0 X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.57.6 VDF=9.65.6) X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] W3C work on web security context ... X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2007 10:05:36 -0000 There's a new-ish W3C security group [1] who're trying to figure out what might be better that a lock icon in a browser, or, more generally, how to better present security context information to "web" users. The group's 1st public document is out now [2] and feedback is welcome (there's an address for that in the doc itself). Cheers, S. [1] http://www.w3.org/2006/WSC/ [2] http://www.w3.org/TR/wsc-usecases/ From vidyan@qualcomm.com Thu Mar 15 04:37:00 2007 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2F8b08F004302 for ; Thu, 15 Mar 2007 04:37:00 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id l2F8arte011107 for ; Thu, 15 Mar 2007 04:36:54 -0400 (EDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 57FBE3CAE1D for ; Thu, 15 Mar 2007 04:36:53 -0400 (EDT) Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l2F8apgL015932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 15 Mar 2007 01:36:52 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l2F8apQN009930 for ; Thu, 15 Mar 2007 01:36:51 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 01:36:51 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Mar 2007 01:36:48 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IP Mobility Threat Analysis and Security Requirements - Request for Review and Comments Thread-Index: Acdm3RIjbPoQoliqTjOdzRJR4/pBNg== From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 15 Mar 2007 08:36:51.0140 (UTC) FILETIME=[13EC3040:01C766DD] X-Spam-Score: 0.60 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id l2F8b08F004302 Subject: [saag] IP Mobility Threat Analysis and Security Requirements - Request for Review and Comments X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2007 08:37:00 -0000 All, The IETF has been involved with developing a suite of IP mobility protocols to handle global and local mobility of nodes. Most of these protocols are based on tunneling packets meant for one, relatively stable, IP address to another, relatively transient, IP address that identifies the topologically correct location of the node. Examples of this class of protocols include the Mobile IP suite of protocols such as Mobile IPv4, Mobile IPv6, Fast MIP4/6, Hierarchical MIP6, Proxy MIP4/6, Regional registration for MIP4, other network-based mobility protocols, network mobility (NEMOv4/6), etc. MOBIKE also shares some of the similar properties. Security solutions for some of these protocols have been proposed and for some other protocols, solutions are currently under development. While some of these protocols have done their own, independent threat analysis, some others have not. Consequently, there is not a good common understanding of the threat model or security requirements needed in a particular solution. draft-vidya-ip-mobility-threats-00 and draft-vidya-ip-mobility-sec-reqs-00 attempt to provide such a threat analysis and set of security requirements for IP mobility protocols. Reviews and comments are greatly appreciated. Regards, Vidya From vidyan@qualcomm.com Thu Mar 15 05:01:35 2007 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2F91Zci010559 for ; Thu, 15 Mar 2007 05:01:35 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id l2F91StK017662 for ; Thu, 15 Mar 2007 05:01:29 -0400 (EDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 24AEE2E40E0 for ; Thu, 15 Mar 2007 05:01:27 -0400 (EDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l2F91QOe017122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 15 Mar 2007 02:01:27 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l2F91QBU012119 for ; Thu, 15 Mar 2007 02:01:26 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 02:01:26 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Mar 2007 02:01:21 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Security Analysis of RFC4285 Thread-Index: Acdm4IBbkDYd3Ru0S+C0b15i5JK9cA== From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 15 Mar 2007 09:01:26.0133 (UTC) FILETIME=[83164250:01C766E0] X-Spam-Score: 0.72 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id l2F91Zci010559 Subject: [saag] Security Analysis of RFC4285 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2007 09:01:36 -0000 All, A couple of years ago, the MIP6 WG decided to specify an alternate security mechanism for Mobile IPv6, following the model used for Mobile IPv4. While such a document was published (RFC4285), it was published with a lot of resistance from a security perspective. Eventually, the IESG put a note on the document, pretty much to the effect that the document has not gone through any security reviews. However, there is no documented reason for the IESG note and the note often goes unnoticed and gets dismissed when mentioned and consequently, this protocol continues to be proposed and used in various deployments. I wrote a draft (http://www.ietf.org/internet-drafts/draft-vidya-rfc4285-security-analys is-00.txt) explaining the security issues with RFC4285. Russ suggested I get a review from SAAG on the document to see if people think this is worth publishing. I'd appreciate review and feedback. Thanks, Vidya From tgondrom@opentext.com Wed Mar 21 09:34:29 2007 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2LDYTVg022146 for ; Wed, 21 Mar 2007 09:34:29 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id l2LDYJPc028479 for ; Wed, 21 Mar 2007 09:34:19 -0400 (EDT) Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by mit.edu (Spam Firewall) with ESMTP id 34259355610 for ; Wed, 21 Mar 2007 09:34:17 -0400 (EDT) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id l2LDYElk029755; Wed, 21 Mar 2007 14:34:14 +0100 (MET) 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_01C76BBD.9D8B0D19" Date: Wed, 21 Mar 2007 14:34:14 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868C07025@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] LTANS meeting summary Thread-Index: AcdrvZ3s1Z9eswtMSX+D2AQmljcFUw== X-Priority: 5 Priority: Non-Urgent Importance: low From: "Tobias Gondrom" To: X-Spam-Score: 0.72 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Wed, 21 Mar 2007 09:39:23 -0400 Cc: Tim Polk , Carl Wallace Subject: [saag] LTANS meeting summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2007 13:34:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C76BBD.9D8B0D19 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, LTANS (Long Term Archive and Notary Services) held a short meeting in = Prague, to review the status of the active working group documents. The Requirements document passed IETF LC and will be released as = informational RFC 4810. ERS is currently in IESG review.=20 The WG will now focus on LTAP and the XML representations of ERS and = LTAP.=20 Work proceeds with ERS/SCVP and PKI Retention aiming to start WGLC in = April.=20 The two drafts validate (related to preserving verification data) and = ARI (architecture of LTA Services) will continue but require = review/feedback. (Decision on whether these documents shall be continued = as WG items is open at the moment.) The meeting had presentations about LTAP (Long-term archive protocol), = XMLERS (XML representation of ERS), VALIDATE (Verification Data) and a = product implementation of ERS (by Fraunhofer).=20 There has been a short discussion about whether WG should use more = "current" ASN.1 instead of 88-ASN.1 in their modules (and which one to = make normative and which informative if both are provided). Argument to = use 88-ASN.1 as normative at the moment, is that there is still no free = ASN.1 compiler fully capable of 1997/2002-ASN.1. Counter argument is = that there exists asn1c. AD pointed out that this compiler has been = evaluated and still had some deficiencies. Last item on the agenda was = to discuss about the usage of non-RFC3161 TS in ERS. (this item had to = be deferred to the mailing-list as the WG ran out of time.) More detailed meeting minutes has been uploaded to the Materials page. Tobias Chair of LTANS __________________________________________ Tobias Gondrom Head of Open Text Security Team Open Text Corporation Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/ =20 Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der = Trift 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: = +49 (0) 6103 89 04 11 | Register Court / Registergericht: Offenbach, = Germany | Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID: = DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton This email is protected by domestic and international copyright laws and = treaties and is the property of Open Text Corporation, it may contain = confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This email may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above ("Authorized Recipient") for = the purpose for which it was sent by OTC. All other rights and licenses = to this email are fully reserved to OTC. If you are not an Authorized = Recipient, you are required to immediately delete this email in its = entirety without printing, copying, using, and/or re-transmitting this = email, either in whole or in part. The transmission of this email by OTC = is not to be construed as a waiver by OTC and/or the individual sending = this email on behalf of OTC of any of their respective rights or = privileges at law or otherwise, howsoever arising. ------_=_NextPart_001_01C76BBD.9D8B0D19 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [saag] LTANS meeting summary

Hi,

LTANS (Long Term Archive and Notary = Services) held a short meeting in Prague, to review the status of the active working group = documents.

The = Requirements document passed IETF LC and will be released as = informational RFC 4810. ERS is currently in IESG review. =

The = WG will now focus on LTAP and the XML representations of ERS and LTAP. =

Work = proceeds with ERS/SCVP and PKI Retention aiming to start WGLC in April. =

The = two drafts validate (related to preserving verification data) and ARI = (architecture of LTA Services) will continue but require = review/feedback. (Decision on whether these documents shall be continued = as WG items is open at the moment.)

The = meeting had presentations about LTAP (Long-term archive protocol), = XMLERS (XML representation of ERS), VALIDATE (Verification Data) and a = product implementation of ERS (by Fraunhofer).

There = has been a short discussion about whether WG should use more = “current” ASN.1 instead of 88-ASN.1 in their modules (and = which one to make normative and which informative if both are provided). = Argument to use 88-ASN.1 as normative at the moment, is that there is = still no free ASN.1 compiler fully capable of 1997/2002-ASN.1. Counter = argument is that there exists asn1c. AD pointed out that this compiler = has been evaluated and still had some deficiencies. Last item on the = agenda was to discuss about the usage of non-RFC3161 TS in ERS. (this = item had to be deferred to the mailing-list as the WG ran out of = time.)


More detailed meeting minutes has been uploaded to the = Materials page.

Tobias

Chair = of LTANS


__________________________________________
Tobias = Gondrom
Head of = Open Text Security Team

Open Text = Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:tobias.gondrom@opentex= t.com
Internet: http://www.opentext.com/  =

Place = of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der Trift = 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: +49 (0) = 6103 89 04 11 | Register Court / Registergericht: Offenbach, Germany | = Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID:  DE 114 = 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton

This = email is protected by domestic and international copyright laws and = treaties and is the property of Open Text Corporation, it may contain = confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This email may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above ("Authorized = Recipient") for the purpose for which it was sent by OTC. All other = rights and licenses to this email are fully reserved to OTC. If you are = not an Authorized Recipient, you are required to immediately delete this = email in its entirety without printing, copying, using, and/or = re-transmitting this email, either in whole or in part. The transmission = of this email by OTC is not to be construed as a waiver by OTC and/or = the individual sending this email on behalf of OTC of any of their = respective rights or privileges at law or otherwise, howsoever = arising.

------_=_NextPart_001_01C76BBD.9D8B0D19-- From kent@bbn.com Wed Mar 21 10:37:10 2007 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2LEbA0X014544 for ; Wed, 21 Mar 2007 10:37:10 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id l2LEatCw002091 for ; Wed, 21 Mar 2007 10:36:56 -0400 (EDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by mit.edu (Spam Firewall) with ESMTP id 369663CDFEB for ; Wed, 21 Mar 2007 10:31:00 -0400 (EDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.17.112]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HU1q7-00080x-4M for saag@mit.edu; Wed, 21 Mar 2007 10:31:00 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 21 Mar 2007 10:30:52 -0400 To: saag@mit.edu From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-1037635036==_ma============" X-Spam-Score: 0.26 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] PKIX WG Smmary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2007 14:37:10 -0000 --============_-1037635036==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" PKIX Meeting Summary Major WG item actions: - Jim Schaad will revise his CMC documents based on IESG feedback, we will have a new Wg last call, and resend to the IESG. - The design team for the ECC algorithms draft will be reconstituted to try to develop a new solution, one that will not run afoul of Russ's objections. - Stefan will revise his SAN for Service Name I-D to address internationalization issues raised by he IESG. There is still an open issue re an "applicability statement" the needs to be resolved. In any case, we will need to conduct a WG last call, again. Other WG actions of significance: - the WG will track progress in he EAI WG, since we will likely need to change the SAN definition to accommodate this - Denis Pinkas will be asked to provide an outline and lent estimate for his proposed new document, an Informational RFC dealing with key rollover - We will work with Scott Lawrence et al. to help them develop a certificate profile for use with SIP --============_-1037635036==_ma============ Content-Type: text/html; charset="us-ascii" PKIX WG Smmary
PKIX Meeting Summary

Major WG item actions:

      - Jim Schaad will revise his CMC documents based on IESG feedback, we will have a new Wg last call, and resend to the IESG.

     - The design team for the ECC algorithms draft will be reconstituted to try to develop a new solution, one that will not run afoul of Russ's objections.

        - Stefan will revise his SAN for Service Name I-D to address internationalization issues raised by he IESG. There is still an open issue re an "applicability statement" the needs to be resolved. In any case, we will need to conduct a WG last call, again.


Other WG actions of significance:

- the WG will track progress in he EAI WG, since we will likely need to change the SAN definition to accommodate this

   - Denis Pinkas will be asked to provide an outline and lent estimate for his proposed new document, an Informational RFC dealing with key rollover

      - We will work with Scott Lawrence et al. to help them develop a certificate profile for use with SIP
--============_-1037635036==_ma============-- From gregory.ietf@gmail.com Wed Mar 21 11:10:40 2007 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2LFAeMm028674 for ; Wed, 21 Mar 2007 11:10:40 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id l2LFAXsR003117 for ; Wed, 21 Mar 2007 11:10:33 -0400 (EDT) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.236]) by mit.edu (Spam Firewall) with ESMTP id AFC4A284C6F for ; Wed, 21 Mar 2007 11:10:32 -0400 (EDT) Received: by nz-out-0506.google.com with SMTP id x3so73869nzd for ; Wed, 21 Mar 2007 08:10:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:x-mailer:date:to:from:subject:cc:in-reply-to:references:mime-version:content-type:message-id; b=RlWKblLBnoLdyFpmIMZimOejYO9v8sIgIbFAvDPSkssgmivOSojqz5VjUfdV5Ra16mUMPrDetNsRyL1DV1LW2pMoI3+kQgKdFfEkzwmu5Kw9pvSNUphTjT5a7lmeHhmMLVw1VKxYa/RmPJMa3EAD1DNMX0NfAAPuGD0PinUOSDk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:x-mailer:date:to:from:subject:cc:in-reply-to:references:mime-version:content-type:message-id; b=g2mHyDU3IThIuNF52jlyB5Kk0PgecVAO9xNynNJp9PAsB30aD/fL/YfV/ZVVa7z09NaT6BXy/UmofyTmbHgazvYcPukFOQ3Pd671sued4IQRTxe1xEiVxxGYlIRyw6zqMSGaWLo2Hes48dY5SHC4+6pUP4VPbMW6+gn87lYzGYI= Received: by 10.35.121.2 with SMTP id y2mr1570261pym.1174489831980; Wed, 21 Mar 2007 08:10:31 -0700 (PDT) Received: from gregory-lt.gmail.com ( [66.129.225.151]) by mx.google.com with ESMTP id p77sm3380301pyb.2007.03.21.08.10.25; Wed, 21 Mar 2007 08:10:28 -0700 (PDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 21 Mar 2007 08:10:18 -0700 To: Tim Polk , saag@mit.edu, Sam Hartman From: "Gregory M. Lebovitz" In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_96757379==.ALT" Message-ID: <46014ae4.1a7f158e.2db7.5e40@mx.google.com> X-Spam-Score: 0.96 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: pki4ipsec@icsalabs.com, Paul Knight Subject: [saag] pki4ipsec - wg status X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2007 15:10:40 -0000 --=====================_96757379==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed PKI4IPSEC did NOT meet here in Prague. We have only two documents in all. draft-ietf-pki4ipsec-ikecert-profile-12.txt - was in IESG review and is stuck on some DISCUSS issues that are being addressed by the author. When solution determined, doc will rev and be released as RFC. We will be sure to take the issue and discussion of it to list before moving on, as this is the appropriate process via PROTO. Requirements for an IPsec Certificate Management Profile - RFC 4809 the cert mgmt protocol profile requirements document has moved to RFC. does not how up on wg web page; ticket into secretariate to fix. As soon as ike-cert profile goes to RFC, wg will close. Gregory. --=====================_96757379==.ALT Content-Type: text/html; charset="us-ascii" PKI4IPSEC did NOT meet here in Prague.

We have only two documents in all.

draft-ietf-pki4ipsec-ikecert-profile-12.txt -
 was in IESG review and is stuck on some DISCUSS issues that are being addressed by the author. When solution determined, doc will rev and be released as RFC. We will be sure to take the issue and discussion of it to list before moving on, as this is the appropriate process via PROTO.

Requirements for an IPsec Certificate Management Profile - RFC 4809
  the cert mgmt protocol profile requirements document has moved to
RFC.
  does not how up on wg web page; ticket into secretariate to fix.

As soon as ike-cert profile goes to RFC, wg will close.

Gregory.


--=====================_96757379==.ALT--


From Pasi.Eronen@nokia.com Wed Mar 21 13:15:42 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2LHFghh013798
	for ; Wed, 21 Mar 2007 13:15:42 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2LHFUl8025273
	for ; Wed, 21 Mar 2007 13:15:30 -0400 (EDT)
Received: from mgw-ext14.nokia.com (smtp.nokia.com [131.228.20.173])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id DBF71304B52
	for ; Wed, 21 Mar 2007 13:15:29 -0400 (EDT)
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145])
	by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l2LHF8PC027826; Wed, 21 Mar 2007 19:15:24 +0200
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by
	esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Mar 2007 19:15:14 +0200
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by
	esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Mar 2007 19:15:14 +0200
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Date: Wed, 21 Mar 2007 19:15:12 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IETF68 TLS WG summary
Thread-Index: Acdr3HxcKpvCl9umRca9NcP7xrskqQ==
From: 
To: , 
X-OriginalArrivalTime: 21 Mar 2007 17:15:14.0413 (UTC)
	FILETIME=[7D6581D0:01C76BDC]
X-Nokia-AV: Clean
X-Spam-Score: 1.15
X-Spam-Level: * (1.15)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id
	l2LHFghh013798
Subject: [saag] IETF68 TLS WG summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: Pasi.Eronen@nokia.com
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 21 Mar 2007 17:15:42 -0000

Transport Layer Security (TLS) working group met on Tuesday morning.

The main topic was TLS 1.2, which is progressing (although missing
some milestones). We discussed how to best handle algorithm agility
for signatures (in certificates and certain TLS messages), what to 
say about algorithm identifier parameters, and alert messages.

Eric and Joe Salowey presented drafts that add AES-GCM cipher suites
to TLS 1.2, one document containing RSA key exchange and the other
"Suite B" compliant ECC suites. There was consensus to adopt both as
WG documents (subject to confirmation on the list).  There was also
some desire to have clear rules when to adopt algorithm and/or profile
documents as WG items, so that similar documents backed by other
national governments would be treated fairly. The chairs promised to
make a first proposal for rules.

Yaron Sheffer gave a presentation on adding EAP authentication TLS.
This is not consistent with current EAP applicability statement, and
changing it needs more discussion with EAP community. There was
some interest from e.g. SSL VPN community.

GSS-API authentication for TLS was not presented, but it was observed
that there are similarities to EAP work. WG seemed to have interest
in this work, and discussion will continue on the list.

Eric gave a presentation on using TLS to derive keys for other uses
than TLS record layer (such as SRTP and SCTP). This seems desirable,
but needs to consider other parts of security association than just
the key. As few people had read the draft, this will continue as an
individual draft for now.

Best regards,
Pasi & Eric


From julien.laganier@gmail.com Wed Mar 21 14:22:16 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2LIMG9a001939
	for ; Wed, 21 Mar 2007 14:22:16 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2LIM0jw012436
	for ; Wed, 21 Mar 2007 14:22:00 -0400 (EDT)
Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178])
	by mit.edu (Spam Firewall) with ESMTP id B82D135E73F
	for ; Wed, 21 Mar 2007 14:17:09 -0400 (EDT)
Received: by py-out-1112.google.com with SMTP id d32so124285pye
	for ; Wed, 21 Mar 2007 11:17:09 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender;
	b=N+wRa/r+f0AlkvjwRr2DkPSgACpau/1QXytxbsyFy4Q+YxMEx27P1ZNZ2zP+h1fZVp5bCVqDM5HDuPDItqdfGhke+LcxgrIcvmalgq5BbVFnlGmMBAv9Ec0f70xh/ZhBl0Vv3A4TvlR+5B3E4NrkFetQHtR2dKxs17YvRLhdIsc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:from:to:subject:date:user-agent:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender;
	b=QqFDZ9APIlWxesDhyXC2whHZPPY2SNkDiNh7gmdlPq63zhR6mjPiWTw0yrIyoHTbIugU+5wwwV13/r7P8MHsH2mEtglJz7dFOtqZCKN9ME1CMxYQVP9aGBbl6LvIZ3usk5H7jT3OpHBp/VhPEuU0qRJ1n72rTPtAuyXqQXbRGRs=
Received: by 10.35.50.5 with SMTP id c5mr1904192pyk.1174501029211;
	Wed, 21 Mar 2007 11:17:09 -0700 (PDT)
Received: from dhcp-106a.ietf68.org ( [130.129.16.106])
	by mx.google.com with ESMTP id u62sm3679463pyb.2007.03.21.11.17.04;
	Wed, 21 Mar 2007 11:17:05 -0700 (PDT)
From: Julien Laganier 
To: SAAG mailing list 
Date: Wed, 21 Mar 2007 19:16:55 +0100
User-Agent: KMail/1.8.2
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200703211916.55754.julien.IETF@laposte.net>
Sender: julien laganier 
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: Sam Hartman , BTNS mailing list ,
	Tim Polk 
Subject: [saag] IETF68 BTNS Summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 21 Mar 2007 18:22:16 -0000

The BTNS WG met shortly on Wednesday at IETF68. We had 
a short update on the problem and applicability 
statement, it will be submitted to IESG for 
publication as Experimental RFC after the IETF general 
meeting.

The core document describing BTNS will be WGLC'ed after 
the IETF general meeting.

The connexion latching describing how to bind a given 
ULP communication (e.g. a TCP connexion) to a single 
BTNS SA was presented by Nico Williams. It needs more 
review and discussion and will then be WGLC'ed.

Two API documents were presented: an abstract API (by 
Michael Richardson) inspired by the GSS API and a C 
language one (by Miika Komu). They need to be reviewed 
and discussed on the mailing list before we adopt them 
as WG draft.

Due to lack of time the IKE extensions document could 
not be presented by Michael Richardson. It needs 
discussion on the mailing list.

Best,

-- Julien & Love

From stephen.farrell@cs.tcd.ie Wed Mar 21 14:26:05 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2LIQ46H003382
	for ; Wed, 21 Mar 2007 14:26:05 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2LIPmDd020723
	for ; Wed, 21 Mar 2007 14:25:48 -0400 (EDT)
Received: from smtp.ietf68.org (egon.ietf68.org [130.129.5.7])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 1DF6B3F4211
	for ; Wed, 21 Mar 2007 14:16:25 -0400 (EDT)
Received: from [130.129.20.89] (dhcp-1459.ietf68.org [130.129.20.89])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp.ietf68.org (Postfix) with ESMTP id AC62950051;
	Wed, 21 Mar 2007 19:16:24 +0100 (CET)
Message-ID: <460176CE.1010806@cs.tcd.ie>
Date: Wed, 21 Mar 2007 18:17:50 +0000
From: Stephen Farrell 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
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: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: ietf-dkim 
Subject: [saag] DKIM WG summary for SAAG
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 21 Mar 2007 18:26:05 -0000


DKIM met on Wed morning, ~43 people signed the blue sheets.

The base specification is in the RFC editor's queue.

Main meeting goals were finishing up the SSP requirements
document (WGLC runs until the end of next week), progressing
the SSP protocol work and considering the overview document's
future.

On the SSP requirements we had a couple of issues to discuss
and took one to the list for a strawpoll. We want more WGLC
comments on this.

In San Diego we had 4 different SSP proposals. With the
agreement of the proponents of 3 of those we decided to
proceed based on draft-allman-ssp with a bunch of changes
that were discussed at the meeting. We hope for a first
draft-ietf-dkim-ssp early in April. The chairs hope to
get active involvement from some DNS people in this work.

There was a proposal to split the Overview document into
three parts (from the authors). While there were a couple
of concerns with that, the meeting was ok with going with
the authors' suggestion since they were concerned with
getting out text that'll help with deploying the base
specification sooner rather than later.

Stephen Farrell/Barry Leiba



From julien.laganier@gmail.com Wed Mar 21 14:32:33 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2LIWXpm005492
	for ; Wed, 21 Mar 2007 14:32:33 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2LIWGue003973
	for ; Wed, 21 Mar 2007 14:32:17 -0400 (EDT)
Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.234])
	by mit.edu (Spam Firewall) with ESMTP id 2BA5F16446E
	for ; Wed, 21 Mar 2007 14:29:00 -0400 (EDT)
Received: by nz-out-0506.google.com with SMTP id x3so93250nzd
	for ; Wed, 21 Mar 2007 11:29:00 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:from:to:subject:user-agent:cc:mime-version:content-disposition:date:content-type:content-transfer-encoding:message-id:sender;
	b=s0nYrx8WwH7iii9xwsCJ63j4U/+aWVMXEOb5lGeS/KfZz1Wm1JSnFAG0r5JHO/WXDTINKKJYZC4ITsFLArMU3Hk+WWJ6U7/tQrEFc+s9khY6xsfgbD/SuywY8konceEvULoPrWDGKFnkwjCxXb5SApSrdBeHbtiiLeper9dWX0k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:from:to:subject:user-agent:cc:mime-version:content-disposition:date:content-type:content-transfer-encoding:message-id:sender;
	b=PffitRmOcO2ySs4ZaT5W3JTddreihe//Jor+hKuC5I8uLGSvg5s+n/Dogj7ymH5jlHETKl/E41FWfYm+xkCb/5W78JB65NhJy05RZzp4CwQx3bVaOed3MuMhIWV15l6R18lUak9/pPY78ikG5QFZxJ4CAZbojPqG9zRMr5a7dJQ=
Received: by 10.35.74.1 with SMTP id b1mr1919904pyl.1174501740184;
	Wed, 21 Mar 2007 11:29:00 -0700 (PDT)
Received: from dhcp-106a.ietf68.org ( [130.129.16.106])
	by mx.google.com with ESMTP id u62sm3698638pyb.2007.03.21.11.28.59;
	Wed, 21 Mar 2007 11:28:59 -0700 (PDT)
From: Julien Laganier 
To: SAAG mailing list 
User-Agent: KMail/1.8.2
MIME-Version: 1.0
Content-Disposition: inline
Date: Wed, 21 Mar 2007 19:28:57 +0100
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200703211928.58347.julien.IETF@laposte.net>
Sender: julien laganier 
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: Sam Hartman , BTNS mailing list ,
	Tim Polk 
Subject: [saag] Correction: IETF68 BTNS Summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 21 Mar 2007 18:32:33 -0000

[Apologize for resending, I made a slight error in the 
previous report]

The BTNS WG met shortly on Wednesday at IETF68.

The problem and applicability statement will be 
submitted to IESG for publication as Experimental RFC 
after the IETF general meeting.

We had a short update on the core document describing 
BTNS, it will be WGLC'ed after the IETF general 
meeting.

The connexion latching describing how to bind a given 
ULP communication (e.g. a TCP connexion) to a single 
BTNS SA was presented by Nico Williams. It needs more 
review and discussion and will then be WGLC'ed.

Two API documents were presented: an abstract API (by 
Michael Richardson) inspired by the GSS API and a C 
language one (by Miika Komu). They need to be reviewed 
and discussed on the mailing list before we adopt them 
as WG draft.

Due to lack of time the IKE extensions document could 
not be presented by Michael Richardson. It needs 
discussion on the mailing list.

Best,

-- Julien & Love


From sethomso@cisco.com Thu Mar 22 04:19:27 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2M8JRZ7025343
	for ; Thu, 22 Mar 2007 04:19:27 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2M8JLYR006881
	for ; Thu, 22 Mar 2007 04:19:21 -0400 (EDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149])
	by mit.edu (Spam Firewall) with ESMTP id BB7463DD11A
	for ; Thu, 22 Mar 2007 04:19:20 -0400 (EDT)
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-2.cisco.com with ESMTP; 22 Mar 2007 04:19:20 -0400
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2M8JIH6008037
	for ; Thu, 22 Mar 2007 04:19:18 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2M8JDlI021648
	for ; Thu, 22 Mar 2007 08:19:18 GMT
Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 22 Mar 2007 04:19:15 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Thu, 22 Mar 2007 04:19:13 -0400
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IETF68 NEA WG summary
Thread-Index: AcdsWsaKjJnPw/PJQZWtmHaSlXHsqw==
From: "Susan Thomson (sethomso)" 
To: 
X-OriginalArrivalTime: 22 Mar 2007 08:19:15.0472 (UTC)
	FILETIME=[C7964900:01C76C5A]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1426; t=1174551558;
	x=1175415558; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=sethomso@cisco.com;
	z=From:=20=22Susan=20Thomson=20\(sethomso\)=22=20
	|Subject:=20IETF68=20NEA=20WG=20summary |Sender:=20
	|To:=20;
	bh=pSWuEowW+BAlHsIjPugws8+Buc7kGKU8+z3JvrrzdoI=;
	b=OjoCqezlUAVoStRN2KN4yJxYg3Qyi9aQyVSELdx9RuUuNKCGrom6TslKDZa5WHZzr616Am9D
	3PnJ4viGWtXuWgVJZD7HPT25flG0hYwZdx15JhPwsjnQRRjgX3ZpKiio;
Authentication-Results: rtp-dkim-2; header.From=sethomso@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.60
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id
	l2M8JRZ7025343
Subject: [saag] IETF68 NEA WG summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 22 Mar 2007 08:19:27 -0000

NEA WG meeting
March 20, 2007

1. Charter milestones

Original milestones in charter need to be updated. Proposed updates to
milestones were reviewed in the meeting. A hum was taken demonstrating 
support for the changes. 

Next Steps: Take to list for final review before being sent to AD for
approval.

2. Review of Requirements draft

Current requirements draft reviewed including reference model, proposed
attribute types, and use cases. Open issues were raised on supporting
virtualization, security considerations, privacy considerations and NEA
support for non-endpoint devices. NEA support for non-endpoint devices
may be outside of scope of charter, but our AD indicated that further
discussion is warranted to understand the problem better.

Next Steps: WG participants and document editors to raise issues on
mailing list and continue discussion. Requirements draft to be updated
in April based on feedback received. 

3. Eduroam and NEA

There was a short presentation on use of federated 802.1x in
FWNA/eduroam
deployments, and how it may be impacted by NEA. While it is clear that
support
for such networks is outside the current NEA charter, the presenters'
intent was to  raise awareness of potential issues in an attempt to
avoid problems with supporting such deployments in the future. Several
proposals for resolving the issues without affecting NEA were suggested.


From clancy@cs.umd.edu Thu Mar 22 04:35:39 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2M8Zdd2030066
	for ; Thu, 22 Mar 2007 04:35:39 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2M8ZWtp029854
	for ; Thu, 22 Mar 2007 04:35:32 -0400 (EDT)
Received: from mcfeely.cs.umd.edu (mcfeely.cs.umd.edu [128.8.128.218])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id EE6C93C8A36
	for ; Thu, 22 Mar 2007 04:35:31 -0400 (EDT)
Received: from mcfeely.cs.umd.edu (localhost [127.0.0.1])
	by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id
	l2M8ZVdk023531; Thu, 22 Mar 2007 04:35:31 -0400
Received: (from apache@localhost)
	by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id
	l2M8ZRl7023527; Thu, 22 Mar 2007 04:35:27 -0400
X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to
	clancy@cs.umd.edu using -f
Received: from 130.129.19.126 (SquirrelMail authenticated user clancy)
	by webmail.cs.umd.edu with HTTP;
	Thu, 22 Mar 2007 04:35:27 -0400 (EDT)
Message-ID: <32851.130.129.19.126.1174552527.squirrel@webmail.cs.umd.edu>
Date: Thu, 22 Mar 2007 04:35:27 -0400 (EDT)
From: "Charles Clancy" 
To: saag@mit.edu
User-Agent: SquirrelMail/1.4.5
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
X-Mailman-Approved-At: Thu, 22 Mar 2007 04:38:08 -0400
Cc: tim.polk@nist.gov, hokey-chairs@tools.ietf.org
Subject: [saag] HOKEY WG Summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 22 Mar 2007 08:35:39 -0000

HOKEY WG Summary

HOKEY met Monday morning, and the meeting's focus was on updates to
the EMSK key hierarchy draft, and a proposal to use a 3-party key
agreement protocol as the basis of the HOKEY re-auth protocol.  There
were some comments regarding the changes to the EMSK keying hierarchy,
with a suggestion to add an extra level of keys to keep the hierarchy
balanced.  Discussion was taken to the list.  The 3-party protocol
proposal resulted in significant discussion, without resolution.  We
plan to discuss the additional protocol requirements that would
motivate the use of a 3-party protocol on the list, and initial
responses indicate a possible consensus on how to consolidate
proposals.

-- 
t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy


From gregory.ietf@gmail.com Thu Mar 22 11:02:19 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2MF2Jws018959
	for ; Thu, 22 Mar 2007 11:02:19 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2MF2Cov011184
	for ; Thu, 22 Mar 2007 11:02:12 -0400 (EDT)
Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.176])
	by mit.edu (Spam Firewall) with ESMTP id 81FDD384912
	for ; Thu, 22 Mar 2007 11:02:11 -0400 (EDT)
Received: by ik-out-1112.google.com with SMTP id b32so784227ika
	for ; Thu, 22 Mar 2007 08:02:10 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:x-mailer:date:to:from:subject:in-reply-to:references:mime-version:content-type:message-id;
	b=eC4hYsZ06uX3LLqoQPhxFPmF7eKSSkQef7jbeckKUTQCtO+3GWwbGLnEHRgOqetsex6YWwEy8fE7bSWbKQMaLLqJ1mYK6Or6rx6hs/02+i65xNDTxOayQm+gwaUjWjdHC6tEF7qqi8BPW9YzKC6Zbn3Z4vi7gf7ZqVdJvjNa2UQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:x-mailer:date:to:from:subject:in-reply-to:references:mime-version:content-type:message-id;
	b=LqEq4y4CtxubhHNjbRbfHRL+z0iL7m5+3+Rx5Wq50RZckHr2Uj/RtfJagPWm9FQJZvvhqsnwTWr0B85BINTC8ZBcFted/jKsHl/FnEInMEP+lh9kmosq4m2fBQrk+gC/4s00bZPMYgnrIZVaJ0LVMCB72xBl37PMZJSIotBeyrI=
Received: by 10.70.73.12 with SMTP id v12mr3702383wxa.1174575730221;
	Thu, 22 Mar 2007 08:02:10 -0700 (PDT)
Received: from gregory-lt.gmail.com ( [130.129.17.44])
	by mx.google.com with ESMTP id i34sm4950732wxd.2007.03.22.08.02.08;
	Thu, 22 Mar 2007 08:02:09 -0700 (PDT)
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 22 Mar 2007 08:02:02 -0700
To: Thomas Narten , saag@mit.edu
From: "Gregory M. Lebovitz" 
In-Reply-To: <200702280310.l1S3Ap2X018469@cichlid>
References: <200702280310.l1S3Ap2X018469@cichlid>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <46029a71.4ce57114.0a3a.3527@mx.google.com>
X-Spam-Score: 0.13
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: Re: [saag] NIST profiles for IPv6 (including IPsec)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 22 Mar 2007 15:02:20 -0000

At 08:10 PM 2/27/2007, Thomas Narten wrote:
>Dunno if folk here have looked at these, but NIST has issued draft
>profiles for IPv6 and IPsec:
>
>         http://www.antd.nist.gov/usgv6-v1-comments.html

--snip--

>One thing I note is that AH is optional rather than mandatory, with
>ESP and NULL encryption used for authentication where needed. Is that
>they way the market has gone at this point?

Yes. We've (NetScreen/Juniper) seen very little use of AH over the 
years, and much more ESP-NULL. From a breadth of deployment, testing, 
experience, I'd say we are MUCH better versed as an industry in ESP than AH.

Gregory.


From jsalowey@cisco.com Thu Mar 22 11:20:07 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2MFK7wr026500
	for ; Thu, 22 Mar 2007 11:20:07 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2MFK1FC023801
	for ; Thu, 22 Mar 2007 11:20:01 -0400 (EDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117])
	by mit.edu (Spam Firewall) with ESMTP id 00FF4317D5B
	for ; Thu, 22 Mar 2007 11:19:59 -0400 (EDT)
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-6.cisco.com with ESMTP; 22 Mar 2007 08:19:59 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2MFJx57023632
	for ; Thu, 22 Mar 2007 08:19:59 -0700
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 l2MFJMFA024668
	for ; Thu, 22 Mar 2007 15:19:58 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 22 Mar 2007 08:19:53 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Thu, 22 Mar 2007 08:19:50 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: EMU working group summary
Thread-Index: AcdslYjj2/zr4xqNQWCfG3jC6CLMJQ==
From: "Joseph Salowey (jsalowey)" 
To: 
X-OriginalArrivalTime: 22 Mar 2007 15:19:53.0024 (UTC)
	FILETIME=[8A571C00:01C76C95]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1162; t=1174576799;
	x=1175440799; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jsalowey@cisco.com;
	z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20
	|Subject:=20EMU=20working=20group=20summary |Sender:=20;
	bh=jWY4WGf0chJ1yJzm3H6IvfrnskW5GR0DCO5m3l/mme8=;
	b=otJ7VNR85BPl7Bo+Vd+b1PizxT5R1HtTof0ZUsQeYmF9U2Gg5ZaL9/kMxyt/OAi/i1U6/V6p
	X6pIl7h7bhMWXE8/6fh1haxiOYn4Ez8rWbR0S4acBnv+U+/5+9M+mZLw;
Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: 0.60
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id
	l2MFK7wr026500
Subject: [saag] EMU working group summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 22 Mar 2007 15:20:07 -0000

EMU (EAP Method Update) working group met on Monday afternoon.  

RFC2716bis (EAP-TLS) has completed working group last call.  The main
issues to resolve were around certificate processing.  We had good
discussion and should be able to resolve this quickly on the list.  The
action is to have a revised draft that can be submitted to the IESG soon
after this meeting.  

EAP-GPSK has also completed working group last call and received
comments.  The main issues to resolve were around ciphersuite selection
and a PRF for deriving a key hierarchy.  We had some good discussion and
clarification on the applicability of the NIST key derivation draft to
the key hierarchy derivation.  The action is to have a revised draft for
submission to the IESG soon after the meeting.  

We also had an update on the progress of the password based design team.
We had a discussion of requirements for the method and on the direction
that the design team is taking.  The basic direction is a password
exchange within a TLS tunnel.  The action is for the design team to
publish a draft before IETF-69 so it can be discussed at this meeting. 

Joe


From turners@ieca.com Thu Mar 22 12:51:38 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2MGpZGH026158
	for ; Thu, 22 Mar 2007 12:51:35 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2MGpSU3014363
	for ; Thu, 22 Mar 2007 12:51:28 -0400 (EDT)
Received: from smtp102.biz.mail.re2.yahoo.com (smtp102.biz.mail.re2.yahoo.com
	[68.142.229.216]) by mit.edu (Spam Firewall) with SMTP id B998A307570
	for ; Thu, 22 Mar 2007 12:36:58 -0400 (EDT)
Received: (qmail 59810 invoked from network); 22 Mar 2007 16:36:57 -0000
Received: from unknown (HELO Wylie) (turners@ieca.com@130.129.55.101 with
	login)
	by smtp102.biz.mail.re2.yahoo.com with SMTP; 22 Mar 2007 16:36:57 -0000
X-YMail-OSG: wjNlTe4VM1kNurUQgM9.SEaganS9WlNPFBg7QEiNqUJE44Z4vReMicvMslmNN6w27U3RQHUmLP3NQX1XMlUfQgtlza.ryB7ck4m9njHvbndRxNwQ0NZWGib4nmQupkAsnCqaaWNfE4J08Yk-
From: "Turner, Sean P." 
To: 
Date: Thu, 22 Mar 2007 17:35:13 +0100
Organization: IECA, Inc.
Message-ID: <002a01c76ca0$114b4060$4b01000a@Wylie>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcdsoBB0pHjK0zBnSImtpKnmrRarHA==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Spam-Score: 0.31
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] IETF 68 S/MIME WG Summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: turners@ieca.com
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 22 Mar 2007 16:51:39 -0000


The S/MIME WG meet Thursday, 22 March 2007 in the afternoon session II.

Sean Turner (that's me) presented the agenda and WG summary.  No new topics
were added as a result of agenda bashing.  

There are two documents with the RFC Editor.  There is one draft with the
IESG.  There are two expired drafts, but they are being raised from the dead
by their authors.  Both of these drafts will be pushed to WG LC as soon as
they are published 1) Now that the RSA-KEM drafts in IEEE/ANSI have been
finalized the RSA-KEM use with CMS ID will be resubmitted, 2) Now that
comments from Russ Housley and Jim Schaad have been addressed (and the
document has been aligned with the ETSI TS TS 101 733 v1.7.3 document) the
CMS Advanced Digital Signatures ID will be resubmitted. 

The two Identity Based Encryption (IBE) drafts NEED wider review.  If there
are any IBE experts (actually I'll take hacks too) please review the drafts,
as the review in the WG has not been as in-depth as both of the chairs would
have liked.  Assuming there is an in-depth review, the next version will be
WG LCed.

Summaries of the new IDs one for an Authenticated-Enveloped-Data content
type and another to describe the AES-CCM and AES-GCM algorithms use with
this content type were provided by Russ Housley.  One issue remains in the
Authenticated-Enveloped-Data ID and it has to do with the twidling of the
first bits in the encoding of the authenticated-enveloped contents: either
it should be done as it is for SignedData or it should hash what is sent (if
it turns out to be the later a prominent note will be added to say that it's
different than SignedData).

A summary of the Multiple Signatures attribute ID was provided by Sean
Turner (that's me again).  The only issue was raised by Paul Hoffman who
indicated that he would provide text to clarify the attack being protected
against.

spt
 



From vidyan@qualcomm.com Thu Mar 22 14:13:24 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2MIDOZV020484
	for ; Thu, 22 Mar 2007 14:13:24 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2MIDHFT024233
	for ; Thu, 22 Mar 2007 14:13:17 -0400 (EDT)
Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 28B8637784B
	for ; Thu, 22 Mar 2007 14:13:16 -0400 (EDT)
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l2MIDF3x016020
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for ; Thu, 22 Mar 2007 11:13:15 -0700
Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com
	[172.30.36.175])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l2MIDFHY003789 for ; Thu, 22 Mar 2007 11:13:15 -0700
Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by
	sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 22 Mar 2007 11:13:14 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Thu, 22 Mar 2007 11:13:13 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IFARE BoF Summary
Thread-Index: AcdsrcEtMqkRZGHeRa+uaBJJl/mLMA==
From: "Narayanan, Vidya" 
To: 
X-OriginalArrivalTime: 22 Mar 2007 18:13:14.0967 (UTC)
	FILETIME=[C261A670:01C76CAD]
X-Spam-Score: 0.60
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id
	l2MIDOZV020484
Subject: [saag] IFARE BoF Summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 22 Mar 2007 18:13:24 -0000


Background: 
The major motivation for the effort has been to dissuade the use of
not-so-secure solutions to secure Mobile IPv6 (in place of the IETF
mandated use of IPsec) as a means to avoid the undesired effects of
doing a full IKEv2 exchange (possibly with EAP) during Home Agent and/or
mobile node failures. While the motivating factor is Mobile IPv6, the
goal is to produce an IPsec failover solution that is generically
applicable for VPNs and applications using IPsec. The primary goals were
identified as specification of a standard state format and
client-involved session resumption. 

Discussion Summary: 
The problem statement generated a lot of discussion on the importance of
optimization for the use cases presented. While some in the room felt
that it was not important, there were others who felt this was an
important problem to solve. There was also a lot of discussion on the
need for addressing solutions transparent to the client for better use
with Mobile IPv6. From the discussions, it was evident that not everyone
had a common understanding of the scope and requirements. More
interaction with the members of the MIP6 working group is needed to
figure out the common set of goals that can be identified as worth
building a solution on. 

Decisions and Next Steps: 
Sam noted that given the lack of clarity in the common set of goals, a
second BoF will be required. The group will work on getting to a common
ground in the next couple of months. 


From jhutz@cmu.edu Thu Mar 22 20:33:13 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2N0XD4v025738
	for ; Thu, 22 Mar 2007 20:33:13 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2N0X67I026620
	for ; Thu, 22 Mar 2007 20:33:06 -0400 (EDT)
Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161])
	by mit.edu (Spam Firewall) with SMTP id B61A738559E
	for ; Thu, 22 Mar 2007 20:33:03 -0400 (EDT)
Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu
	id aa23273; 22 Mar 2007 20:32 EDT
Date: Thu, 22 Mar 2007 20:32:29 -0400 (EDT)
From: Jeffrey Hutzelman 
X-X-Sender: 
To: , 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 2
X-Spam-Level: ** (2)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] Summary of krb-wg sessions at IETF 68
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 23 Mar 2007 00:33:13 -0000

Kerberos Working Group - IETF 68 meeting summary

ACTION ITEMS:

  * jhutz: Consult with AD's about ECC IPR issues, and report to the list.
  * jhutz: Consult with Sam and Ken on a milestone for referrals
  * jhutz: Consult with Sam and Tom on a milestone for extensions
  * jhutz: Do a review and PROTO writeup of Set/Change Password.
  * jhutz: Start WGLC on anonymity and hash agility documents.
  * jhutz: Bring up charter items for admin protocol, iakerb, hw-auth, and otp.
  * nico: Comparison of FAST and STARTTLS
  * nico, shawn, raeburn: review draft-ietf-krb-wg-anon-03.txt
  * tgondrom: review draft-ietf-krb-wg-gss-cb-hash-agility-01.txt
  * stefan, shawn: review draft-ietf-krb-wg-pkinit-alg-agility-02.txt
  * raeburn: Summarize open issues for referrals to the mailing list.


DECISIONS (to be validated):

  * The cross-realm problem statement work will be in the charter proposal.
  * Work on at least one of FAST or STARTTLS will be in the charter proposal.


SESSION SUMMARY:

  + Larry Zhu will become co-chair sometime in the next few months.

  + There was a brief review of WG documents which have passed or are
    nearly ready for last call.

    - ECC-for-PKINIT is waiting for a PROTO writeup.
    - TCP Extensions is now in IETF last call.
    - Naming constraints is in WG last call.
    - Set Password is waiting for a PROTO writeup.
    - Anonymity should be in WGLC by the end of March.
    - The hash agility documents should be in WGLC in April.

  + The ECC-for-PKINIT document is ready, but has a normative reference
    to an informational document (RFC 3278) which specifies how to use
    ECC with CMS.  The referenced document is informational because of
    IPR issues with ECC, and the working group needs to decide whether
    we want to publish ECC-for-PKINIT as informational, or attempt to
    place it on the standards track despite the IPR issues and downref.
    Further discussion will take place on the mailing list.

  + There was discussion about the inability to determine whether GSS-API
    channel bindings have been recognized by the acceptor, and there was
    a proposal to add a criticality flag to context token extensions,
    which was ruled out of scope.

  + Work continues on the referrals and extensions documents; new versions
    of both have been submitted recently, but there are still changes to
    be folded in.  Ken Raeburn described some open issues with referrals,
    which he will bring up on the mailing list.

  + There was much discussion of items to be placed on our new charter.
    The following items were considered:
    - Work on an LDAP-based admin protocol
    - IAKERB, a mechanism for allowing communications between a GSS-API
      initiator and its KDC to be relayed by the GSS-API acceptor, when
      the initiator cannot talk to its KDC directly.
    - Examination of problems related to cross-realm authentication
    - A STARTTLS-like negotiation for using TLS to protect communication
      between Kerberos clients and the KDC.
    - A preauthentication model and framework, and several methods.

    There was strong consensus in the room that the charter proposal
    should include both the cross-realm problem work and at least one of
    STARTTLS or the FAST preauth framework.  Discussion of the admin
    protocol work was contentious and eventually deferred to the mailing
    list.  More discussion is required on IAKERB and the various preauth
    methods.



From tlyu@MIT.EDU Thu Mar 22 22:07:16 2007
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU
	[18.7.7.80])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2N27GGm009304
	for ; Thu, 22 Mar 2007 22:07:16 -0400
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])
	by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2N274dC011814; Thu, 22 Mar 2007 22:07:04 -0400 (EDT)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU
	[18.18.1.96]) (authenticated bits=56)
	(User authenticated as tlyu@ATHENA.MIT.EDU)
	by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l2N270hn020488
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 22 Mar 2007 22:07:03 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308)
	id l2N270mA005096; Thu, 22 Mar 2007 22:07:00 -0400 (EDT)
To: ietf-sasl@imc.org, saag@MIT.EDU
From: Tom Yu 
Date: Thu, 22 Mar 2007 22:07:00 -0400
Message-ID: 
Lines: 54
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
X-Spam-Flag: NO
X-Spam-Score: 0.00
Subject: [saag] IETF68 SASL WG summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 23 Mar 2007 02:07:17 -0000

SASL WG
Wednesday, March 21, 2006, at 1300-1500

SUMMARY
=======

Thanks to Bob Morgan for scribing.

Document Status:

draft-ietf-sasl-crammd5-08     in WGLC
draft-ietf-sasl-gs2-07         in WGLC
draft-ietf-sasl-gssapi-08      RFC 4752
draft-ietf-sasl-rfc2831bis-12  some issues...

WGLC documents -- mostly only have minor issues.  We need more
reviewers for CRAM-MD5.

Given problems with DIGEST-MD5 in terms of interoperability and
implementability, there appears to be consensus to move DIGEST-MD5 (in
the form of RFC 2831) to Historic.

Presentations about several proposed alternative password-based
mechanisms:

draft-cridland-sasl-hexa-00.txt
draft-newman-auth-scram-04.txt
draft-zeilenga-sasl-yap-00.txt

HEXA and SCRAM are somewhat similar and may end up being combined
eventually.  YAP may remain independent.  There appears to be
consensus for adopting at least one of these hash-based password
mechanisms as a WG work item, and adopting some HEXA+SCRAM derivative
as a replacement for DIGEST-MD5.  There appears to be consensus that
the WG doesn't yet have enough information about application
requirements to determine whether one of these mechanisms or two of
these mechansisms should be adopted.

Kurt talked about interop reports, and there was discussion about the
Draft Standard advancement process.

Alexey talked about Sam's Discuss on the smtp-auth document, regarding
mandating of the verification of server TLS certificates when using
PLAIN over TLS.

ACTION ITEMS
============

* in the next week, acquire more information about application
  requirements upon password-based mechanisms.

* conclude WG Last Calls

* recharter including DIGEST-MD5 replacement(s)

From j.schoenwaelder@iu-bremen.de Thu Mar 22 12:42:06 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2MGg2Bj021251
	for ; Thu, 22 Mar 2007 12:42:02 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2MGfqkv028167
	for ; Thu, 22 Mar 2007 12:41:53 -0400 (EDT)
Received: from hermes.iu-bremen.de (hermes.iu-bremen.de [212.201.44.23])
	by mit.edu (Spam Firewall) with ESMTP id 87B2833EF94
	for ; Thu, 22 Mar 2007 12:37:10 -0400 (EDT)
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id 1CEBA6DC27;
	Thu, 22 Mar 2007 17:37:09 +0100 (CET)
Received: from hermes.iu-bremen.de ([212.201.44.23])
	by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new,
	port 10024)
	with ESMTP id 28379-04; Thu, 22 Mar 2007 17:37:04 +0100 (CET)
Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de
	[10.50.231.133])
	by hermes.iu-bremen.de (Postfix) with ESMTP id 03C756DB4B;
	Thu, 22 Mar 2007 17:37:04 +0100 (CET)
Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501)
	id 9F0951F240A; Thu, 22 Mar 2007 17:37:02 +0100 (CET)
Date: Thu, 22 Mar 2007 17:37:02 +0100
From: Juergen Schoenwaelder 
To: saag@mit.edu
Message-ID: <20070322163702.GB4963@elstar.iuhb02.iu-bremen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.14 (2007-02-12)
X-Spam-Score: 0.12
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
X-Mailman-Approved-At: Fri, 23 Mar 2007 03:41:24 -0400
Cc: Dave Harrington ,
	Juergen Quittek 
Subject: [saag] saag report for isms
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: j.schoenwaelder@iu-bremen.de
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 22 Mar 2007 16:42:07 -0000

Hi,

below is the SAAG writeup for the ISMS working group meeting:

The ISMS WG has met on Thursday afternoon. ISMS has three WG
documents:

1) The first document is an extension of the SNMPv3 architecture
   introducing a transport subsystem to allow the introduction of
   secure transports.  This document went through the first WG last
   call and essentially all raised issues seem to be resolved and will
   be reflected in the next update.

2) The second document defines a transport security model for
   utilizing secure transports such as SSH. This document is still in
   WG last call; so far no criticial issues have surfaced.

3) The third document defines how SSH can be used as a secure
   transport for SNMP. There is still work to be done on this document
   since the editor's focus since the last IETF meeting was on the
   first two documents.

An individual submission discusses how RADIUS can be utilized for
authentication and authorization. While this submission addresses a
chartered work item (authentication), but it was concluded that
authorization is not well in scope of the charter and should therefore
be considered as potential followup work after ISMS has completed the
chartered work items.

Milestones will be updated with the target to submit the documents to
the IESG in August 2007.

/js

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
	 P.O. Box 750 561, 28725 Bremen, Germany

From stephen.farrell@cs.tcd.ie Fri Mar 23 05:35:24 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2N9ZODm007326
	for ; Fri, 23 Mar 2007 05:35:24 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2N9ZINw002139
	for ; Fri, 23 Mar 2007 05:35:18 -0400 (EDT)
Received: from smtp.ietf68.org (egon.ietf68.org [130.129.5.7])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 1E22D3EE515
	for ; Fri, 23 Mar 2007 05:35:16 -0400 (EDT)
Received: from [130.129.20.89] (dhcp-1459.ietf68.org [130.129.20.89])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp.ietf68.org (Postfix) with ESMTP id 5C22950051;
	Fri, 23 Mar 2007 10:35:15 +0100 (CET)
Message-ID: <46039FA8.7080101@cs.tcd.ie>
Date: Fri, 23 Mar 2007 09:36:40 +0000
From: Stephen Farrell 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: saag@mit.edu
Content-Type: multipart/mixed; boundary="------------090208070006020404070406"
X-Spam-Score: 3.5
X-Spam-Level: *** (3.5)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: Thomas Roessler 
Subject: [saag] [Fwd: Re: Jabbering today?]
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 23 Mar 2007 09:35:25 -0000

This is a multi-part message in MIME format.
--------------090208070006020404070406
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


 From Thomas,
S.


--------------090208070006020404070406
Content-Type: message/rfc822;
 name="Re: Jabbering today?"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Re: Jabbering today?"

Return-Path: 
X-Original-To: stephen.farrell@cs.tcd.ie
Delivered-To: stephen.farrell@cs.tcd.ie
Received: from localhost (localhost [127.0.0.1])
	by relay.cs.tcd.ie (Postfix) with ESMTP id 88EFB38BB
	for ; Fri, 23 Mar 2007 09:33:34 +0000 (GMT)
Received: from smtp.cs.tcd.ie ([127.0.0.1])
	by localhost (smtp.cs.tcd.ie [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 22569-08 for ;
	Fri, 23 Mar 2007 09:33:26 +0000 (GMT)
Received: from homer.w3.org (homer.w3.org [128.30.52.30])
	by smtp.cs.tcd.ie (Postfix) with ESMTP id B6FB93850
	for ; Fri, 23 Mar 2007 09:33:26 +0000 (GMT)
Received: from raktajino.does-not-exist.org (homer.w3.org [128.30.52.30])
	by homer.w3.org (Postfix) with ESMTP id EC0D04EEB4;
	Fri, 23 Mar 2007 05:33:24 -0400 (EDT)
Received: from roessler by raktajino.does-not-exist.org with local (Exim 4.63)
	(envelope-from )
	id 1HUg9R-0007WR-R3; Fri, 23 Mar 2007 10:33:37 +0100
Date: Fri, 23 Mar 2007 10:33:34 +0100
From: Thomas Roessler 
To: Stephen Farrell 
Subject: Re: Jabbering today?
Message-ID: <20070323093334.GW21783@raktajino.does-not-exist.org>
References: <46038C53.6050609@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <46038C53.6050609@cs.tcd.ie>
User-Agent: Mutt/1.5.14 (2007-03-20)
X-Virus-Scanned: amavisd-new at cs.tcd.ie
X-Spam-Status: No, score=1.391 required=6 tests=[AWL=-0.651, BAYES_50=0.001,
	DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, FORGED_RCVD_HELO=0.135,
	SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
X-Spam-Score: 1.391
X-Spam-Level: *

Thanks Stephen; nicely done.  Please feel free to forward the
following.  (I don't think I can write to the Security Area list;
not sure about that, though.)

- We hold face-to-face meetings with at least 8 weeks' notice.
  Workshops typically have more than that due to the position paper
  process. You will have ample notice, and it will go to the Apps
  and Security areas.

- The format is to have a workshop that's open to anybody who
  bothers to put together a position paper that isn't wildly (and I
  mean *wildly*) off base.

- Concerning the question about depressing user studies relevant to
  WSC WG, we're trying to make sure to not just know about them, but
  actually get the people involved that did them (or folks close to
  those).

If there are any other questions, please send e-mail; also, I'm
generally available on jabber as tlr@jabber.org.

Regards,
-- 
Thomas Roessler, W3C    +33.4.89063488







On 2007-03-23 08:14:11 +0000, Stephen Farrell wrote:
> From: Stephen Farrell 
> To: Thomas Roessler 
> Date: Fri, 23 Mar 2007 08:14:11 +0000
> Subject: Jabbering today?
> X-Spam-Level: 
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.5
> 
> 
> Hi Thomas,
> 
> I'm at saag now. I'll be in front of your slides in about
> 30 mins. Are you planning to join in the jabber session
> (saag@jabber.ietf.org) for this? I suspect there might
> be questions.
> 
> There's also an audio stream. [1]
> 
> Stephen.
> 
> [1] http://videolab.uoregon.edu/events/ietf/ietf685.m3u
> 
> 


--------------090208070006020404070406--

From kivinen@iki.fi Fri Mar 23 05:41:44 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2N9fiUD009382
	for ; Fri, 23 Mar 2007 05:41:44 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2N9fb5A004670
	for ; Fri, 23 Mar 2007 05:41:37 -0400 (EDT)
Received: from mail.kivinen.iki.fi (unknown [83.145.195.1])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 10EE432CCC6
	for ; Fri, 23 Mar 2007 05:41:36 -0400 (EDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1])
	by mail.kivinen.iki.fi (8.13.8/8.12.10) with ESMTP id l2N9f3LT019054
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 23 Mar 2007 11:41:03 +0200 (EET)
Received: (from kivinen@localhost)
	by fireball.kivinen.iki.fi (8.13.8/8.12.11) id l2N9f2qO008508;
	Fri, 23 Mar 2007 11:41:03 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to
	kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17923.41134.978652.828608@fireball.kivinen.iki.fi>
Date: Fri, 23 Mar 2007 11:41:02 +0200
From: Tero Kivinen 
To: saag@mit.edu, sp500-267-comments@antd.nist.gov
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 6 min
X-Total-Time: 9 min
X-Spam-Score: 0.01
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] USGv6 DPD/3706(O) case
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 23 Mar 2007 09:41:44 -0000

There was some texts on the slides talking about using RFC3706 with
IKEv2. This is not possible with the current RFC3706, as it is only
defined for the IKEv1. The notify payloads etc defined in the document
do not match the ones used in the IKEv2.

On the other hand there is no need to use RFC3706 with IKEv2, as there
is built in dead peer detection system in the IKEv2 which uses empty
informational exchanges (which are ACKed as all IKEv2 messages). For
more information see section 2.4 of RFC4306.
-- 
kivinen@safenet-inc.com

From dougm@nist.gov Fri Mar 23 06:14:35 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2NAEZqj021658
	for ; Fri, 23 Mar 2007 06:14:35 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2NAEQ5J015287
	for ; Fri, 23 Mar 2007 06:14:27 -0400 (EDT)
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id C5D513D6A03
	for ; Fri, 23 Mar 2007 06:06:21 -0400 (EDT)
Received: from [127.0.0.1] ([129.6.220.230])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id l2NA6CKY025024;
	Fri, 23 Mar 2007 06:06:14 -0400
Message-ID: <4603A694.9070003@nist.gov>
Date: Fri, 23 Mar 2007 06:06:12 -0400
From: Doug Montgomery 
Organization: http://www.antd.nist.gov/
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: sp500-267-comments@antd.nist.gov
References: <17923.41134.978652.828608@fireball.kivinen.iki.fi>
In-Reply-To: <17923.41134.978652.828608@fireball.kivinen.iki.fi>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: dougm@nist.gov
X-Spam-Score: 0.12
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] [Sp500-267-comments] USGv6 DPD/3706(O) case
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 23 Mar 2007 10:14:35 -0000

Thanks,  that is roughly our understanding.  We had recently received
a comment suggesting that we should mandate 3706 for IKEv2 and threw
that on the slide to see if it made sense to others.

dougm


Tero Kivinen wrote:
> There was some texts on the slides talking about using RFC3706 with
> IKEv2. This is not possible with the current RFC3706, as it is only
> defined for the IKEv1. The notify payloads etc defined in the document
> do not match the ones used in the IKEv2.
>
> On the other hand there is no need to use RFC3706 with IKEv2, as there
> is built in dead peer detection system in the IKEv2 which uses empty
> informational exchanges (which are ACKed as all IKEv2 messages). For
> more information see section 2.4 of RFC4306.
>   

-- 
+----------------------------------------------------------------------------+
| Doug Montgomery       Manager, Internetworking Technologies Research Group |
| Advanced Network Technologies Division      WWW: http://www.antd.nist.gov/ |
| National Institute of Standards and Technology      Email:  dougm@nist.gov |
| 100 Bureau Drive                                    Voice: +1-301-975-3630 |
| Gaithersburg, MD 20899-8920 USA                     Fax:   +1-301-975-6238 |
| Key fingerprint =       4E83 6ED5 A4F1 144C 5D8F  B3AB 3BD1 D6DC 00B8 4610 |
+----------------------------------------------------------------------------+



From ldondeti@qualcomm.com Fri Mar 23 10:49:04 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2NEn4pH030637
	for ; Fri, 23 Mar 2007 10:49:04 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2NEmvKd000906
	for ; Fri, 23 Mar 2007 10:48:58 -0400 (EDT)
Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 4AE58347C40
	for ; Fri, 23 Mar 2007 10:48:57 -0400 (EDT)
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l2NEmtAt011393
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for ; Fri, 23 Mar 2007 07:48:56 -0700
Received: from [10.50.64.56] (qconnect-10-50-64-56.qualcomm.com [10.50.64.56])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l2NEmr5m004403
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
	for ; Fri, 23 Mar 2007 07:48:55 -0700
Message-ID: <4603E8D4.8000404@qualcomm.com>
Date: Fri, 23 Mar 2007 07:48:52 -0700
From: Lakshminath Dondeti 
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
MIME-Version: 1.0
To: saag@mit.edu
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] Apologies
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 23 Mar 2007 14:49:04 -0000

Folks,

Apologies if my presentation at the meeting this morning was a complete 
waste of your time.  I was trying to make the case that the simple 
threat model we have as a reference is not quite sufficient.  I was 
further proposing whether providing guidelines on asset classification 
and mapping security functions to network entities might be a way 
forward.  It is clear that either people don't understand what I was 
getting at or disagree with that direction.

I have had the following suggestions so far:

1. Make the case that the services should be available with only a 
portion of the network functioning correctly.

Place the nodes that may result in failure of the entire network/service 
as deep as possible in the network.

2. Try and analyze a given protocol that may need an expanded threat 
model.  After that has been accepted, extrapolate it to see if it is 
applicable elsewhere.

Please send your suggestions either to the list or to me personally.  I 
hope to work on this further with your input.  If anyone is interested 
in working with me, that will be even better.

thanks,
Lakshminath

From fergdawg@netzero.net Fri Mar 23 11:14:37 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2NFEbgD009255
	for ; Fri, 23 Mar 2007 11:14:37 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2NFEYNC004869
	for ; Fri, 23 Mar 2007 11:14:34 -0400 (EDT)
Received: from outbound-mail.lax.untd.com (outbound-mail.lax.untd.com
	[64.136.28.164]) by mit.edu (Spam Firewall) with SMTP id 8F60F37AC63
	for ; Fri, 23 Mar 2007 11:13:31 -0400 (EDT)
Received: from webmail29.lax.untd.com (webmail29.lax.untd.com [10.131.27.169])
	by smtpout08.lax.untd.com with SMTP id AABDAH5WUAEUG4XA
	for  (sender );
	Fri, 23 Mar 2007 08:13:22 -0700 (PST)
X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPcINWq1SZzwVp6svcmR+U3LgFFpVGNZuxw==
Received: (from fergdawg@netzero.net) 
	by webmail29.lax.untd.com (jqueuemail) id MHJCSUSV;
	Fri, 23 Mar 2007 07:13:10 PST
Received: from [130.129.20.210] by webmail29.lax.untd.com with HTTP:
	Fri, 23 Mar 2007 15:12:40 GMT
X-Originating-IP: [130.129.20.210]
Mime-Version: 1.0
From: "Fergie" 
Date: Fri, 23 Mar 2007 15:12:40 GMT
To: ldondeti@qualcomm.com
X-Mailer: Webmail Version 4.0
Content-Disposition: inline
Content-Type: text/plain
Message-Id: <20070323.071310.694.810927@webmail29.lax.untd.com>
X-ContentStamp: 20:10:1105295235
X-MAIL-INFO: 4079b178fc08b1087901796d4c2ddcb5b55d91c1b5ec694c689c0d1ce95555b13909d578
X-UNTD-Peer-Info: 10.131.27.169|webmail29.lax.untd.com|webmail29.lax.untd.com|fergdawg@netzero.net
X-Spam-Score: 0.14
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id
	l2NFEbgD009255
Cc: saag@mit.edu
Subject: Re: [saag] Apologies
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 23 Mar 2007 15:14:37 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- -- Lakshminath Dondeti  wrote:

>Folks,
>
>Apologies if my presentation at the meeting this morning was a complete 
waste of your time.  I was trying to make the case that the simple 
threat model we have as a reference is not quite sufficient.  I was 
further proposing whether providing guidelines on asset classification 
and mapping security functions to network entities might be a way 
forward.  It is clear that either people don't understand what I was 
getting at or disagree with that direction.
>
>I have had the following suggestions so far:
>
>1. Make the case that the services should be available with only a 
portion of the network functioning correctly.
>
>Place the nodes that may result in failure of the entire network/service 
as deep as possible in the network.
>
>2. Try and analyze a given protocol that may need an expanded threat 
model.  After that has been accepted, extrapolate it to see if it is 
applicable elsewhere.
>
>Please send your suggestions either to the list or to me personally.  I 
hope to work on this further with your input.  If anyone is interested 
in working with me, that will be even better.
>

Lakshminath,

Quite the contrary -- I think your presentation, by simple fact that
it generated so much discussion, was a good one (even if I disagreed
with some major issues).

Most of the "threats" that I deal with these days have to do with
end-system (or even possible middle-boxen) compromises, and once that
occurs, secure channels, encryption, etc. is pretty much meaningless.

Having said that, I wonder if looking at the "threat landscape"
should not necessarily be just "critical" v. "non-critical"
components, but rather/also classified into "end-system" v.
"infrastructure"? And perhaps also "functional, yet compromised" v.
"non-functional [foo]" (where [foo] may be either compromised or
non-compromised)?

Cheers,

- - ferg 

-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.5.3 (Build 5003)

wj8DBQFGA+5fq1pz9mNUZTMRAgATAJ9hZyncUNNWxLiQfFYFfswttNwscgCeIOiE
cYjiLF7BNIr4E6XHq/XmY+s=
=FZ0l
-----END PGP SIGNATURE-----


--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/



From vidyan@qualcomm.com Fri Mar 23 12:57:11 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2NGvAWN009131
	for ; Fri, 23 Mar 2007 12:57:11 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2NGv3t1029999
	for ; Fri, 23 Mar 2007 12:57:04 -0400 (EDT)
Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id B36F1390107
	for ; Fri, 23 Mar 2007 12:57:02 -0400 (EDT)
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l2NGv1vW025272
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 23 Mar 2007 09:57:01 -0700
Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com
	[172.30.36.176])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l2NGv0BQ008080; Fri, 23 Mar 2007 09:57:00 -0700
Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by
	SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 23 Mar 2007 09:57:00 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Fri, 23 Mar 2007 09:56:59 -0700
Message-ID: 
In-Reply-To: <20070323.071310.694.810927@webmail29.lax.untd.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [saag] Apologies
Thread-Index: AcdtX5DFwkYN7aR/RuyAAbAbK91wsAACUEiw
References: <20070323.071310.694.810927@webmail29.lax.untd.com>
From: "Narayanan, Vidya" 
To: "Fergie" ,
	"Dondeti, Lakshminath" 
X-OriginalArrivalTime: 23 Mar 2007 16:57:00.0435 (UTC)
	FILETIME=[46293630:01C76D6C]
X-Spam-Score: 0.72
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id
	l2NGvAWN009131
Cc: saag@mit.edu
Subject: Re: [saag] Apologies
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 23 Mar 2007 16:57:11 -0000



> 
> Most of the "threats" that I deal with these days have to do with
> end-system (or even possible middle-boxen) compromises, and once that
> occurs, secure channels, encryption, etc. is pretty much meaningless.
> 

The above is very true. Actually, I don't think we can surely assume
that a certain entity is always more vulnerable than other entities,
since that is specific to a system.  

> Having said that, I wonder if looking at the "threat landscape"
> should not necessarily be just "critical" v. "non-critical"
> components, but rather/also classified into "end-system" v.
> "infrastructure"? And perhaps also "functional, yet compromised" v.
> "non-functional [foo]" (where [foo] may be either compromised or
> non-compromised)?
> 

On the above, one major point I didn't get in today's presentation was
whether Lakshminath was advocating that we actually classify end-system
entities as "non-critical" and infrastructure entities as "critical". I
think classification of assets is good, but, the classification will
differ for each system and each protocol. So, system and protocol
designers have to determine the mapping of their components into such
asset categories. Guidance on some general principles would be useful
though, IMO. For instance: 

- Security infrastructure elements (e.g., CA, a Kerberos KDC, AAA
server, etc.) are typically critical assets
- Endpoints of any protocol signaling may be critical assets (in the
sense that if the signaling endpoint is compromised, the protocol
functions are affected)

Something along the above lines may simply lead to guidance that says
critical assets are those, whose compromise may result in critical
failure of the system or protocol and non-critical assets are those,
whose compromise may lead to temporary glitches, but should generally be
recoverable via alternate non-critical assets. I would think that the
compromise of non-critical assets must not cause domino effects. As to
what entities fall under each category, that should be left to specific
systems. 

The additional classification may also be useful in providing "typical"
qualities that may be expected in each of those cases, with the caveat
that there may be system-specific exceptions. 

Vidya

> Cheers,
> 
> - ferg 
> 
> 
> *** END PGP VERIFIED MESSAGE ***
> 
> 
> --
> "Fergie", a.k.a. Paul Ferguson
>  Engineering Architecture for the Internet
>  fergdawg(at)netzero.net
>  ferg's tech blog: http://fergdawg.blogspot.com/
> 
> 
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://mailman.mit.edu/mailman/listinfo/saag
> 


From Nicolas.Williams@sun.com Fri Mar 23 14:11:03 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2NIB3aK000795
	for ; Fri, 23 Mar 2007 14:11:03 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2NIAuNL011595
	for ; Fri, 23 Mar 2007 14:10:56 -0400 (EDT)
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31])
	by mit.edu (Spam Firewall) with ESMTP id 614B1368DF9
	for ; Fri, 23 Mar 2007 14:10:55 -0400 (EDT)
Received: from centralmail4brm.central.Sun.COM ([129.147.62.198])
	by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	l2NIAsZZ005482 for ; Fri, 23 Mar 2007 18:10:54 GMT
Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104])
	by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id l2NIAsju027161
	for ; Fri, 23 Mar 2007 12:10:54 -0600 (MDT)
Received: from binky.central.sun.com (localhost [127.0.0.1])
	by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id
	l2NIA9KH028039; Fri, 23 Mar 2007 13:10:09 -0500 (CDT)
Received: (from nw141292@localhost)
	by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l2NIA8Ok028038; 
	Fri, 23 Mar 2007 13:10:08 -0500 (CDT)
X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to
	Nicolas.Williams@sun.com using -f
Date: Fri, 23 Mar 2007 13:10:08 -0500
From: Nicolas Williams 
To: Fergie 
Message-ID: <20070323181008.GU25751@Sun.COM>
References: <20070323.071310.694.810927@webmail29.lax.untd.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20070323.071310.694.810927@webmail29.lax.untd.com>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, ldondeti@qualcomm.com
Subject: Re: [saag] Apologies
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 23 Mar 2007 18:11:03 -0000

On Fri, Mar 23, 2007 at 03:12:40PM +0000, Fergie wrote:
> Quite the contrary -- I think your presentation, by simple fact that
> it generated so much discussion, was a good one (even if I disagreed
> with some major issues).

I agree.  It was _long_ however, and that actually ate into the amount
of time available for discussion.  Basically I take your presentation
and EKR's comments as a heads up that when we start building protocols
with complex infrastructures (or complex infrastructures from existing
protocols) that we must analyze the impact on security of each
component.  EKR's example (SIP) was a very good one.

Nico
-- 

From clancy@ltsnet.net Sat Mar 24 07:22:33 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2OBMXA6025899
	for ; Sat, 24 Mar 2007 07:22:33 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2OBMTJN001843
	for ; Sat, 24 Mar 2007 07:22:31 -0400 (EDT)
Received: from ltsnet.net (mail.ltsnet.net [65.127.220.12])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 1023F381B36
	for ; Sat, 24 Mar 2007 07:22:28 -0400 (EDT)
Received: from mail.ltsnet.net (localhost.localdomain [127.0.0.1])
	by ltsnet.net (8.13.8/8.13.5) with ESMTP id l2OBA5wo027007;
	Sat, 24 Mar 2007 07:10:05 -0400
Received: (from apache@localhost)
	by mail.ltsnet.net (8.13.8/8.13.8/Submit) id l2OBA5m7027006;
	Sat, 24 Mar 2007 07:10:05 -0400
X-Authentication-Warning: mail.ltsnet.net: apache set sender to
	clancy@ltsnet.net using -f
Received: from 81.19.44.226 (SquirrelMail authenticated user clancy)
	by mail.ltsnet.net with HTTP; Sat, 24 Mar 2007 07:10:05 -0400 (EDT)
Message-ID: <19481.81.19.44.226.1174734605.squirrel@mail.ltsnet.net>
In-Reply-To: <4603E8D4.8000404@qualcomm.com>
References: <4603E8D4.8000404@qualcomm.com>
Date: Sat, 24 Mar 2007 07:10:05 -0400 (EDT)
From: "Charles Clancy" 
To: "Lakshminath Dondeti" 
User-Agent: SquirrelMail/1.4.8-1.fc5
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] Apologies
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sat, 24 Mar 2007 11:22:33 -0000

> I have had the following suggestions so far:
>
> 1. Make the case that the services should be available with only a
> portion of the network functioning correctly.

Going along with some of the terminology you've suggested so far, I'd say
a non-critical asset is one who may play some security role in the
network, but whose compromise does not result in the compromise of the
rest of the security infrastructure.  If one's protocol seeks to minimize
the domino effect, hopefully most assets could be classified as
non-critical.

> Place the nodes that may result in failure of the entire network/service
> as deep as possible in the network.

So critical nodes, e.g. those involved in the root of a key hierarchy like
KDCs, CAs, etc, should be protected in some way, as there's no way to
prevent the domino effect if they are compromised.  I think "deep" should
be defined a little better.  It would ideally be behind firewalls, IDSes,
locked doors, etc.

I don't think it's necessarily feasible for every protocol to secure
themselves in this way, but I think it would be good for authors to have
to think about such issues, and at least document how their protocol would
operate under partially-compromised conditions.

-- 
t. charles clancy, ph.d.  <>  clancy@ltsnet.net  <>  www.ltsnet.net/~clancy


From stephen.farrell@cs.tcd.ie Sat Mar 24 11:51:59 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2OFpxU2021715
	for ; Sat, 24 Mar 2007 11:51:59 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2OFpvSu002927
	for ; Sat, 24 Mar 2007 11:51:58 -0400 (EDT)
Received: from relay.imagine.ie (dns1.dns.imagine.ie [87.232.1.40])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 8D8DD392EF5
	for ; Sat, 24 Mar 2007 11:51:57 -0400 (EDT)
Received: from mail1.int.imagine.ie (mail1 [87.232.1.152])
	by relay.imagine.ie (Postfix) with ESMTP id 6B7FE32111;
	Sat, 24 Mar 2007 15:51:56 +0000 (GMT)
Received: from [10.87.48.2] (dsl-102-234.cust.imagine.ie [87.232.102.234])
	by mail1.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id
	l2OFps06001286
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sat, 24 Mar 2007 15:51:55 GMT
Message-ID: <4605496C.8010706@cs.tcd.ie>
Date: Sat, 24 Mar 2007 15:53:16 +0000
From: Stephen Farrell 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Lakshminath Dondeti 
References: <4603E8D4.8000404@qualcomm.com>
In-Reply-To: <4603E8D4.8000404@qualcomm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Bayes-Prob: 0.0001 (Score 0)
X-Spam-Score: 0.00
X-Canit-Stats-ID: 6850729 - 0f576107d138 (trained as not-spam)
X-CanItPRO-Stream: outgoing
X-Scanned-By: MIMEDefang 2.42
X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.52
X-Spam-Flag: NO
Cc: saag@mit.edu
Subject: Re: [saag] Apologies
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sat, 24 Mar 2007 15:51:59 -0000



Lakshminath Dondeti wrote:
> Folks,
> 
> Apologies if my presentation at the meeting this morning was a complete 
> waste of your time.  I was trying to make the case that the simple 
> threat model we have as a reference is not quite sufficient.  

I agree with others that this was too long. But it also IMO contained
too much that was well known to too many in the group.

A succinct presentation of whatever you're proposing would have been
much better.

S.

From ldondeti@qualcomm.com Sun Mar 25 05:10:57 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2P9Avfn021694
	for ; Sun, 25 Mar 2007 05:10:57 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2P9Anfm024001
	for ; Sun, 25 Mar 2007 05:10:49 -0400 (EDT)
Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id EEDC336C9B2
	for ; Sun, 25 Mar 2007 05:08:53 -0400 (EDT)
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l2P98qOJ022717
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 25 Mar 2007 02:08:52 -0700
Received: from [10.50.64.140] (qconnect-10-50-64-140.qualcomm.com
	[10.50.64.140])
	by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l2P98lPT004027
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sun, 25 Mar 2007 02:08:50 -0700 (PDT)
Message-ID: <46063C1F.4070601@qualcomm.com>
Date: Sun, 25 Mar 2007 02:08:47 -0700
From: Lakshminath Dondeti 
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
MIME-Version: 1.0
To: Fergie 
References: <20070323.071310.694.810927@webmail29.lax.untd.com>
In-Reply-To: <20070323.071310.694.810927@webmail29.lax.untd.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.12
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] Apologies
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sun, 25 Mar 2007 09:10:57 -0000

Thanks.  I think you have a good idea as to what I was getting at.

3552 says "In general, we assume that the end-systems engaging in a protocol
    exchange have not themselves been compromised."

We need to qualify that better.  I presented a rather simplistic 
extension.  You are proposing a more nuanced model.  Let us discuss 
further to see if we can all converge.

thanks,
Lakshminath

PS:  I am on vacation this week and limiting my responses.  I hope the 
discussion continues in my absence.  I will join in when I can and more 
regularly after I am back in the office.

Fergie wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> - -- Lakshminath Dondeti  wrote:
> 
>  >Folks,
>  >
>  >Apologies if my presentation at the meeting this morning was a complete
> waste of your time.  I was trying to make the case that the simple
> threat model we have as a reference is not quite sufficient.  I was
> further proposing whether providing guidelines on asset classification
> and mapping security functions to network entities might be a way
> forward.  It is clear that either people don't understand what I was
> getting at or disagree with that direction.
>  >
>  >I have had the following suggestions so far:
>  >
>  >1. Make the case that the services should be available with only a
> portion of the network functioning correctly.
>  >
>  >Place the nodes that may result in failure of the entire network/service
> as deep as possible in the network.
>  >
>  >2. Try and analyze a given protocol that may need an expanded threat
> model.  After that has been accepted, extrapolate it to see if it is
> applicable elsewhere.
>  >
>  >Please send your suggestions either to the list or to me personally.  I
> hope to work on this further with your input.  If anyone is interested
> in working with me, that will be even better.
>  >
> 
> Lakshminath,
> 
> Quite the contrary -- I think your presentation, by simple fact that
> it generated so much discussion, was a good one (even if I disagreed
> with some major issues).
> 
> Most of the "threats" that I deal with these days have to do with
> end-system (or even possible middle-boxen) compromises, and once that
> occurs, secure channels, encryption, etc. is pretty much meaningless.
> 
> Having said that, I wonder if looking at the "threat landscape"
> should not necessarily be just "critical" v. "non-critical"
> components, but rather/also classified into "end-system" v.
> "infrastructure"? And perhaps also "functional, yet compromised" v.
> "non-functional [foo]" (where [foo] may be either compromised or
> non-compromised)?
> 
> Cheers,
> 
> - - ferg
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Desktop 9.5.3 (Build 5003)
> 
> wj8DBQFGA+5fq1pz9mNUZTMRAgATAJ9hZyncUNNWxLiQfFYFfswttNwscgCeIOiE
> cYjiLF7BNIr4E6XHq/XmY+s=
> =FZ0l
> -----END PGP SIGNATURE-----
> 
> 
> --
> "Fergie", a.k.a. Paul Ferguson
>  Engineering Architecture for the Internet
>  fergdawg(at)netzero.net
>  ferg's tech blog: http://fergdawg.blogspot.com/
> 

From ldondeti@qualcomm.com Sun Mar 25 05:23:52 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2P9NoI9024624
	for ; Sun, 25 Mar 2007 05:23:52 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2P9NiNS017275
	for ; Sun, 25 Mar 2007 05:23:44 -0400 (EDT)
Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id D4B1016E7A3
	for ; Sun, 25 Mar 2007 05:23:42 -0400 (EDT)
Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l2P9KWKx023707
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 25 Mar 2007 02:20:32 -0700
Received: from [10.50.64.140] (qconnect-10-50-64-140.qualcomm.com
	[10.50.64.140])
	by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l2P9KQ2D026117
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sun, 25 Mar 2007 02:20:29 -0700 (PDT)
Message-ID: <46063EDA.3040904@qualcomm.com>
Date: Sun, 25 Mar 2007 02:20:26 -0700
From: Lakshminath Dondeti 
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
MIME-Version: 1.0
To: "Narayanan, Vidya" 
References: <20070323.071310.694.810927@webmail29.lax.untd.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.12
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, Fergie 
Subject: Re: [saag] Apologies
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sun, 25 Mar 2007 09:23:52 -0000

Vidya,

Some notes inline:

Narayanan, Vidya wrote:
> 
> 
>> Most of the "threats" that I deal with these days have to do with
>> end-system (or even possible middle-boxen) compromises, and once that
>> occurs, secure channels, encryption, etc. is pretty much meaningless.
>>
> 
> The above is very true. Actually, I don't think we can surely assume
> that a certain entity is always more vulnerable than other entities,
> since that is specific to a system.  

No disagreement there.

> 
>> Having said that, I wonder if looking at the "threat landscape"
>> should not necessarily be just "critical" v. "non-critical"
>> components, but rather/also classified into "end-system" v.
>> "infrastructure"? And perhaps also "functional, yet compromised" v.
>> "non-functional [foo]" (where [foo] may be either compromised or
>> non-compromised)?
>>
> 
> On the above, one major point I didn't get in today's presentation was
> whether Lakshminath was advocating that we actually classify end-system
> entities as "non-critical" and infrastructure entities as "critical". I

Not sure when I said end-system entities are "non-critical."  I 
definitely did not mean that.  If the party to the service is 
compromised, we have little to work with.

There may be something to work with if one of the servers is 
compromised; it may be plausible for the client to discover that the 
things have gone awry and move to another server.  Even in that case, if 
the servers share security associations, the compromise might impact the 
entire system providing the service.

I am willing to go along with your take that we may not be able to label 
entities as critical or non-critical with a wide applicability.  But, we 
can go quite far; as you note we may actually find that some entities 
are typically critical and others are non-critical.

Perhaps as Ferg notes, we may need a different model or different type 
of classification.  I don't claim to have all the answers.

regards,
Lakshminath

> think classification of assets is good, but, the classification will
> differ for each system and each protocol. So, system and protocol
> designers have to determine the mapping of their components into such
> asset categories. Guidance on some general principles would be useful
> though, IMO. For instance: 
> 
> - Security infrastructure elements (e.g., CA, a Kerberos KDC, AAA
> server, etc.) are typically critical assets
> - Endpoints of any protocol signaling may be critical assets (in the
> sense that if the signaling endpoint is compromised, the protocol
> functions are affected)
> 
> Something along the above lines may simply lead to guidance that says
> critical assets are those, whose compromise may result in critical
> failure of the system or protocol and non-critical assets are those,
> whose compromise may lead to temporary glitches, but should generally be
> recoverable via alternate non-critical assets. I would think that the
> compromise of non-critical assets must not cause domino effects. As to
> what entities fall under each category, that should be left to specific
> systems. 
> 
> The additional classification may also be useful in providing "typical"
> qualities that may be expected in each of those cases, with the caveat
> that there may be system-specific exceptions. 
> 
> Vidya
> 
>> Cheers,
>>
>> - ferg 
>>
>>
>> *** END PGP VERIFIED MESSAGE ***
>>
>>
>> --
>> "Fergie", a.k.a. Paul Ferguson
>>  Engineering Architecture for the Internet
>>  fergdawg(at)netzero.net
>>  ferg's tech blog: http://fergdawg.blogspot.com/
>>
>>
>> _______________________________________________
>> saag mailing list
>> saag@mit.edu
>> http://mailman.mit.edu/mailman/listinfo/saag
>>
> 

From ldondeti@qualcomm.com Sun Mar 25 05:33:45 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2P9XjM1026708
	for ; Sun, 25 Mar 2007 05:33:45 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2P9XcXR027538
	for ; Sun, 25 Mar 2007 05:33:38 -0400 (EDT)
Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 2A4443EEA99
	for ; Sun, 25 Mar 2007 05:32:47 -0400 (EDT)
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l2P9TXZn024012
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 25 Mar 2007 02:29:34 -0700
Received: from [10.50.64.140] (qconnect-10-50-64-140.qualcomm.com
	[10.50.64.140])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l2P9TSe1021771
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sun, 25 Mar 2007 02:29:31 -0700
Message-ID: <460640F8.9000300@qualcomm.com>
Date: Sun, 25 Mar 2007 02:29:28 -0700
From: Lakshminath Dondeti 
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
MIME-Version: 1.0
To: Nicolas Williams , stephen.farrell@cs.tcd.ie
References: <20070323.071310.694.810927@webmail29.lax.untd.com>
	<20070323181008.GU25751@Sun.COM>
In-Reply-To: <20070323181008.GU25751@Sun.COM>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, Fergie 
Subject: Re: [saag] Apologies
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sun, 25 Mar 2007 09:33:45 -0000

Thanks.

I guess I could have cut it down to 10 minutes; the discussion time was 
out of my control :).

I have briefly talked to EKR afterwards and would like to continue the 
discussion either here on the SAAG list or on a private list of 
interested people.

On Stephen's comments, people at the SAAG meeting perhaps are well aware 
of what I was trying to get at.  My appeal was that we should structure 
the ideas and provide some guidance to protocol designers especially to 
those outside the SEC area (count me in as one of those people who are 
looking for consensus guidance here).

In the end, all this might result in a paragraph or two worth of text to 
be added to the 3552's text.

regards,
Lakshminath

Nicolas Williams wrote:
> On Fri, Mar 23, 2007 at 03:12:40PM +0000, Fergie wrote:
>> Quite the contrary -- I think your presentation, by simple fact that
>> it generated so much discussion, was a good one (even if I disagreed
>> with some major issues).
> 
> I agree.  It was _long_ however, and that actually ate into the amount
> of time available for discussion.  Basically I take your presentation
> and EKR's comments as a heads up that when we start building protocols
> with complex infrastructures (or complex infrastructures from existing
> protocols) that we must analyze the impact on security of each
> component.  EKR's example (SIP) was a very good one.
> 
> Nico

From ldondeti@qualcomm.com Sun Mar 25 05:42:43 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2P9ggOJ027943
	for ; Sun, 25 Mar 2007 05:42:43 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2P9gaLE005794
	for ; Sun, 25 Mar 2007 05:42:36 -0400 (EDT)
Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id A3B2116EC91
	for ; Sun, 25 Mar 2007 05:42:35 -0400 (EDT)
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l2P9gXvj014142
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 25 Mar 2007 02:42:33 -0700
Received: from [10.50.64.140] (qconnect-10-50-64-140.qualcomm.com
	[10.50.64.140])
	by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l2P9gSJB008935
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sun, 25 Mar 2007 02:42:31 -0700 (PDT)
Message-ID: <46064404.3000104@qualcomm.com>
Date: Sun, 25 Mar 2007 02:42:28 -0700
From: Lakshminath Dondeti 
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
MIME-Version: 1.0
To: Charles Clancy 
References: <4603E8D4.8000404@qualcomm.com>
	<19481.81.19.44.226.1174734605.squirrel@mail.ltsnet.net>
In-Reply-To: <19481.81.19.44.226.1174734605.squirrel@mail.ltsnet.net>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] Apologies
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sun, 25 Mar 2007 09:42:43 -0000

Agree with your suggestions Charles.  You are capturing what I think 
might be one of the more promising ways to go forward.  Documenting how 
systems/protocols behave under partially-compromised conditions would be 
very useful.

A few people got up and said, but in some designs, the AR is a critical 
asset.  Well, I don't quite agree, since that is not acceptable in all 
deployments.  Now, that is one just one opinion.  What's more important 
is that we document in the security considerations that compromise of a 
single AR (of which there may be many and unprotected from various 
protocol and non-protocol based attacks) may result in disruption of the 
entire service (if indeed that is the case); i.e., the design introduces 
many single points of failure :).

If we include such analysis in the security considerations, people who 
may not otherwise see the implications of assigning critical roles to 
say an AR, will readily see that and will provide their thoughts during 
the consensus processes.

thanks,
Lakshminath

Charles Clancy wrote:
>> I have had the following suggestions so far:
>>
>> 1. Make the case that the services should be available with only a
>> portion of the network functioning correctly.
> 
> Going along with some of the terminology you've suggested so far, I'd say
> a non-critical asset is one who may play some security role in the
> network, but whose compromise does not result in the compromise of the
> rest of the security infrastructure.  If one's protocol seeks to minimize
> the domino effect, hopefully most assets could be classified as
> non-critical.
> 
>> Place the nodes that may result in failure of the entire network/service
>> as deep as possible in the network.
> 
> So critical nodes, e.g. those involved in the root of a key hierarchy like
> KDCs, CAs, etc, should be protected in some way, as there's no way to
> prevent the domino effect if they are compromised.  I think "deep" should
> be defined a little better.  It would ideally be behind firewalls, IDSes,
> locked doors, etc.
> 
> I don't think it's necessarily feasible for every protocol to secure
> themselves in this way, but I think it would be good for authors to have
> to think about such issues, and at least document how their protocol would
> operate under partially-compromised conditions.
> 

From aboba@internaut.com Sun Mar 25 11:59:58 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2PFxwr5019211
	for ; Sun, 25 Mar 2007 11:59:58 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2PFxqea014051
	for ; Sun, 25 Mar 2007 11:59:52 -0400 (EDT)
Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 39953395C2F
	for ; Sun, 25 Mar 2007 11:59:51 -0400 (EDT)
Received: from c-24-16-66-58.hsd1.wa.comcast.net ([24.16.66.58]
	helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.63)
	(envelope-from )
	id 1HVV8J-000JQc-B8; Sun, 25 Mar 2007 11:59:51 -0400
Received: by internaut.com (Postfix, from userid 1000)
	id 4ECCB43EF1; Sun, 25 Mar 2007 08:59:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by internaut.com (Postfix) with ESMTP id 3FA0F43EE4;
	Sun, 25 Mar 2007 08:59:53 -0700 (PDT)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 24.16.66.58
X-Report-Abuse-To: abuse@dyndns.com (see
	http://www.mailhop.org/outbound/abuse.html for abuse reporting
	information)
X-MHO-User: aboba
Date: Sun, 25 Mar 2007 08:59:53 -0700 (PDT)
From: Bernard Aboba 
To: Lakshminath Dondeti 
In-Reply-To: <46063C1F.4070601@qualcomm.com>
Message-ID: 
References: <20070323.071310.694.810927@webmail29.lax.untd.com>
	<46063C1F.4070601@qualcomm.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] Apologies
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sun, 25 Mar 2007 15:59:59 -0000

> 3552 says "In general, we assume that the end-systems engaging in a protocol
>     exchange have not themselves been compromised."
> 
> We need to qualify that better.  

Perhaps the NEA WG can be of some assistance?


From jsalowey@cisco.com Wed Mar 28 11:48:47 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l2SFmlBX016407
	for ; Wed, 28 Mar 2007 11:48:47 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l2SFmeZf011926
	for ; Wed, 28 Mar 2007 11:48:40 -0400 (EDT)
Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72])
	by mit.edu (Spam Firewall) with ESMTP id DE5263AAC20
	for ; Wed, 28 Mar 2007 11:48:39 -0400 (EDT)
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-3.cisco.com with ESMTP; 28 Mar 2007 08:48:40 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2SFmcFc028052; 
	Wed, 28 Mar 2007 08:48:38 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2SFmNMP019958;
	Wed, 28 Mar 2007 15:48:38 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 28 Mar 2007 08:48:27 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Wed, 28 Mar 2007 08:48:27 -0700
Message-ID: 
In-Reply-To: <4603E8D4.8000404@qualcomm.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [saag] Apologies
Thread-Index: AcdtWwBIW1G35FjFTyagZucENjOE7gD9OPEw
From: "Joseph Salowey (jsalowey)" 
To: "Lakshminath Dondeti" , 
X-OriginalArrivalTime: 28 Mar 2007 15:48:27.0963 (UTC)
	FILETIME=[870088B0:01C77150]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1905; t=1175096918;
	x=1175960918; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jsalowey@cisco.com;
	z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20
	|Subject:=20RE=3A=20[saag]=20Apologies |Sender:=20;
	bh=KyOgtsUCH5Im1PtKw+Qoa3zSO7BBo0Wclv9xPVbS5fc=;
	b=vAglQXt3eUXoa2n3LtKDqe6yhf8EGN+I/LFBBgSsZ0Fnnk2V5N7lqzr7f+hM0iaBpbTE8nNL
	8zKGdazFVBu9ZJ0uuUrxTXFB4YOoVASrZQJp5xzQmg7auS9hmORmzpZ5;
Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: 0.72
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id
	l2SFmlBX016407
Subject: Re: [saag] Apologies
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 28 Mar 2007 15:48:47 -0000

Hi Lakshminath,

I remember there was a list for threat analysis posted to saag a while
back, see http://mailman.mit.edu/pipermail/saag/2006q4/001780.html.   I
haven't really followed this work, but perhaps there is enough in common
to have some fruitful discussion. 


Joe
 

> -----Original Message-----
> From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On 
> Behalf Of Lakshminath Dondeti
> Sent: Friday, March 23, 2007 7:49 AM
> To: saag@mit.edu
> Subject: [saag] Apologies
> 
> Folks,
> 
> Apologies if my presentation at the meeting this morning was 
> a complete waste of your time.  I was trying to make the case 
> that the simple threat model we have as a reference is not 
> quite sufficient.  I was further proposing whether providing 
> guidelines on asset classification and mapping security 
> functions to network entities might be a way forward.  It is 
> clear that either people don't understand what I was getting 
> at or disagree with that direction.
> 
> I have had the following suggestions so far:
> 
> 1. Make the case that the services should be available with 
> only a portion of the network functioning correctly.
> 
> Place the nodes that may result in failure of the entire 
> network/service as deep as possible in the network.
> 
> 2. Try and analyze a given protocol that may need an expanded 
> threat model.  After that has been accepted, extrapolate it 
> to see if it is applicable elsewhere.
> 
> Please send your suggestions either to the list or to me 
> personally.  I hope to work on this further with your input.  
> If anyone is interested in working with me, that will be even better.
> 
> thanks,
> Lakshminath
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://mailman.mit.edu/mailman/listinfo/saag
> 


From tum1995@yahoo.com Fri May 11 13:43:39 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4BHhdph010521
	for ; Fri, 11 May 2007 13:43:39 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4BHhcSg025493
	for ; Fri, 11 May 2007 13:43:38 -0400 (EDT)
Received: from web39711.mail.mud.yahoo.com (web39711.mail.mud.yahoo.com
	[209.191.106.57]) by mit.edu (Spam Firewall) with SMTP id 86A4347D2C4
	for ; Fri, 11 May 2007 13:43:29 -0400 (EDT)
Received: (qmail 85004 invoked by uid 60001); 11 May 2007 17:43:28 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;
	b=A7tnhTmJaWkjJbWFtddWvqfdGkcAZO3gAhAVtL6GydLsiBybX3PCeH6tceROR0YdBuC2c/KJD4Ob+EliEjE0L0vJNVNLFOZzWnwgKNaIhuj0n+egocN8zlk+SbG2bR2infaAEIVCZ0IltoGcMR+ZQMCLnceCaeLaZYi5vhxjRN4=;
X-YMail-OSG: iTEDtG0VM1nGQxY1g2KI7AoEPQNVSm8QQBxsdJq2BOeYJvqIhnD.Z5roqcHeLh99fvcqyfgianhiNKlr7Huf4uRSrEt5AHXh4shHFFF2v.hc1dRQpxF7Ld5GI8Q3pg--
Received: from [82.210.116.26] by web39711.mail.mud.yahoo.com via HTTP;
	Fri, 11 May 2007 10:43:28 PDT
Date: Fri, 11 May 2007 10:43:28 -0700 (PDT)
From: ngaga Gisse 
To: saag@mit.edu
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-2075829276-1178905408=:84772"
Content-Transfer-Encoding: 8bit
Message-ID: <667186.84772.qm@web39711.mail.mud.yahoo.com>
X-Spam-Score: 1.131
X-Spam-Level: * (1.131)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] Evolving symmetric encryption schemes with one masterkey
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 11 May 2007 17:43:40 -0000

--0-2075829276-1178905408=:84772
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi, 
  I need the have the following question.
Is it possible to have a forward   secure symmetric  encryption 
scheme that generated  different  encryption  keys (evolves) but   allows to
decrypt the messages using  one key (master key)?. Such a scheme must also allow dcryption using  individual keys. 

   I will highly appreciate if anyone over there knows the url to such 
information or has such information. 
  Ngaga 


       
---------------------------------
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. 
--0-2075829276-1178905408=:84772
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit


Hi, 
  I need the have the following question.
Is it possible to have a forward   secure symmetric  encryption 
scheme that generated  different  encryption  keys (evolves) but   allows to
decrypt the messages using  one key (master key)?. Such a scheme must also allow dcryption using  individual keys. 
  
 I will highly appreciate if anyone over there knows the url to such 
information or has such information. 
  Ngaga 
 
      
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. 
--0-2075829276-1178905408=:84772--

From Black_David@emc.com Sat May 12 23:13:13 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4D3DDML015262
	for ; Sat, 12 May 2007 23:13:13 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4D3D9O5012514
	for ; Sat, 12 May 2007 23:13:09 -0400 (EDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id B94A94D4B11
	for ; Sat, 12 May 2007 23:13:08 -0400 (EDT)
Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11])
	by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id
	l4D3D8vI000200; Sat, 12 May 2007 23:13:08 -0400 (EDT)
Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com
	[10.254.64.53])
	by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id
	l4D3D6Ym005626; Sat, 12 May 2007 23:13:06 -0400 (EDT)
From: Black_David@emc.com
Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by
	corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 12 May 2007 23:13:06 -0400
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C7950C.9FC3BB5E"
Date: Sat, 12 May 2007 23:13:05 -0400
Message-ID: 
In-Reply-To: <667186.84772.qm@web39711.mail.mud.yahoo.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [saag] Evolving symmetric encryption schemes with one masterkey
Thread-Index: AceT9RNzj3PxqvQ7S4iafLXUEtMlzwBFuaWw
References: <667186.84772.qm@web39711.mail.mud.yahoo.com>
To: , 
X-OriginalArrivalTime: 13 May 2007 03:13:06.0265 (UTC)
	FILETIME=[A02ABC90:01C7950C]
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604,
	Antispam-Data: 2007.5.12.194434
X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3,
	HTML_50_70 0.1, NO_REAL_NAME 0, __C230066_P5 0,
	__CP_MEDIA_BODY 0, __CP_URI_IN_BODY 0, __CT 0,
	__CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0,
	__CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __IMS_MSGID 0,
	__MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0,
	__TAG_EXISTS_HTML 0'
X-Spam-Score: 1.27
X-Spam-Level: * (1.27)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: Re: [saag] Evolving symmetric encryption schemes with one masterkey
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sun, 13 May 2007 03:13:13 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7950C.9FC3BB5E
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I'm not sure what your "forward secure" requirement/goal means.
=20
For the general structure of having individual message keys
plus a master key that can decrypt any message, send each message
encrypted with its own message key, and accompany each message by
a copy of its message key encrypted with the master key.
=20
If the recipient has the message key, the recipient decrypts
the message.  If the recipient has the master key, the recipient
decrypts the message key and then decrypts the message.
=20
Thanks,
--David
----------------------------------------------------=20
David L. Black, Senior Technologist=20
EMC Corporation, 176 South St., Hopkinton, MA  01748=20
+1 (508) 293-7953             FAX: +1 (508) 293-7786=20
black_david@emc.com        Mobile: +1 (978) 394-7754=20
----------------------------------------------------=20


________________________________

	From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On
Behalf Of ngaga Gisse
	Sent: Friday, May 11, 2007 1:43 PM
	To: saag@mit.edu
	Subject: [saag] Evolving symmetric encryption schemes with one
masterkey
=09
=09
	Hi,=20
	  I need the have the following question.
	Is it possible to have a forward   secure symmetric  encryption=20
	scheme that generated  different  encryption  keys (evolves) but
allows to
	decrypt the messages using  one key (master key)?. Such a scheme
must also allow dcryption using  individual keys.=20
=09
	 I will highly appreciate if anyone over there knows the url to
such=20
	information or has such information.=20
	  Ngaga=20
=09

=09
________________________________

	Take the Internet to Go: Yahoo!Go puts the Internet in your
pocket:
  mail, news, photos & more.=20


------_=_NextPart_001_01C7950C.9FC3BB5E
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







I'm not sure what your "forward secure"=20
requirement/goal means.


 


For the general structure of having individual message=20
keys


plus a master key that can decrypt any message, send each=20
message


encrypted with its own message key, and accompany each=20
message by


a copy of its message key encrypted with the master=20
key.


 


If the recipient has the message key, the recipient=20
decrypts


the message.  If the recipient =
has the=20
master key, the recipient


decrypts the message key and then decrypts the =
message.


 


Thanks,


--David


----------------------------------------------------=20

David L. =
Black, Senior=20
Technologist 
EMC Corporation, 176 South St., Hopkinton, MA  =
01748=20

+1 (508)=20
293-7953           =
; =20
FAX: +1 (508) 293-7786 
black_david@emc.com        =
Mobile: +1=20
(978) 394-7754 
----------------------------------------------------=20




  

  

  From: saag-bounces@mit.edu=20
  [mailto:saag-bounces@mit.edu] On Behalf Of ngaga =
Gisse
Sent:=20
  Friday, May 11, 2007 1:43 PM
To: =
saag@mit.edu
Subject:=20
  [saag] Evolving symmetric encryption schemes with one=20
  masterkey


  

  
Hi, 
  I need the have=20
  the following question.
Is it possible to have a=20
  forward   secure symmetric  encryption 
scheme that=20
  generated  different  encryption  keys (evolves)=20
  but   allows to
decrypt the messages using  one key =
(master=20
  key)?. Such a scheme must also allow dcryption using  individual=20
  keys. 

  
 I will highly appreciate if anyone over there knows the url =
to such=20
  
information or has such information. 
  Ngaga 

  

  

  Take the Internet to Go: Yahoo!Go puts the Internet=20
  in your pocket: mail, news, photos & more. =


------_=_NextPart_001_01C7950C.9FC3BB5E--

From alcaraz@lcc.uma.es Mon May 14 09:47:40 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4EDleDu005793
	for ; Mon, 14 May 2007 09:47:40 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4EDlZa3012973
	for ; Mon, 14 May 2007 09:47:36 -0400 (EDT)
Received: from nala.ctima.uma.es (nala.ctima.uma.es [150.214.57.23])
	by mit.edu (Spam Firewall) with ESMTP id 5C38047C653
	for ; Mon, 14 May 2007 09:47:34 -0400 (EDT)
Received: from nala.ctima.uma.es (localhost [127.0.0.1])
	by localhost.ctima.uma.es (Postfix) with ESMTP id 8105FB3AF
	for ; Mon, 14 May 2007 15:47:33 +0200 (CEST)
Received: from sol10.lcc.uma.es (sol10.lcc.uma.es [150.214.108.1])by 
	nala.ctima.uma.es (Postfix) with ESMTP id 496C1B3AEfor ;
	Mon, 14 May 2007 15:47:33 +0200 (CEST)
Received: from [127.0.0.1] (unknown [150.214.56.133])by sol10.lcc.uma.es 
	(Postfix) with ESMTP id E51CC38CEEfor ; Mon, 14 May 2007 
	15:47:32 +0200 (CEST)
Message-ID: <46486870.5060204@lcc.uma.es>
Date: Mon, 14 May 2007 15:47:28 +0200
From: Cristina Alcaraz Tello 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: saag@mit.edu
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 000740-0, 13/05/2007), Outbound message
X-Antivirus-Status: Clean
X-imss-version: 2.046
X-imss-result: Passed
X-imss-approveListMatch: *@*.uma.es
X-Spam-Score: 0.78
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] Second International Workshop on Critical Information
	InfrastructuresSecurity (CRITIS'07)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Mon, 14 May 2007 13:47:40 -0000


** Apologies for multiple copies **

F i r s t     C a l l     F o r     P a p e r s

Second International Workshop on Critical Information Infrastructures 
Security (CRITIS'07)
October 3-5, 2007
Benalmadena-Costa, Malaga, Spain

http://critis07.lcc.uma.es    


CRITI'07, co-sponsored by IFIP WG 11.10 on Critical Infrastructures
Protection, IEEE Computer Society Task Force on Information Assurance,
and Joint Research Center Ispra of the European Commission, wants to
bring together researchers and professionals from universities, private
companies and Public Administrations interested or involved in all
security-related heterogeneous aspects of
Critical Information Infrastructures.
We invite research papers, work-in-progress reports, R&D projects results,
surveying works and industrial experiences describing significant security
advances in the following (non-exclusive) areas of Critical Information
Infrastructures for which we plan to have sessions:

- Code of Practice and Metrics     
- Communication Risk & Assurance    
- Early Warning Systems         
- Economics on CIP
- R&D Agenda            
- SCADA and Embedded Security    
- National and Cross Border Issues    
- Information Sharing and Exchange    
- Policy Options Elaboration        
- Threats and Attacks Modeling

Furthermore, the following topics are within the scope of CRITIS?07:

- Continuity of Services and Resiliency
- Dependable Infrastructure Communications
- Internet-based remote control    
- Forensic Techniques         
- Incident Response            
- Network Survivability        
- Trust Models in Critical Scenarios    
- Security Logistics    


* Instructions for paper submission

All submissions will be subjected to a thorough blind review by at least
three reviewers. Papers should be up to 12 pages in English, including
bibliography and well-marked appendices.
As in the case of CRITIS?06, it is planned that post-proceedings are 
published
by Springer in the Lecture Notes in Computer Science (LNCS) series.
Pre-proceedings will appear at the time of the conference.
To submit a paper, follow the specific instructions on the Workshop website

The submitted paper (in PDF or PostScript format), which should follow the
template indicated by Springer
,
must start with a title, a short abstract, and a
list of keywords. However, it should be
anonymous without author(s), affiliations,
acknowledgements, nor obvious references.


* Important dates

Submission of papers: June 25th, 2007
Notification to authors: July 30th, 2007
Camera-ready copies: August 24th, 2007


* Program Committee Co-Chairs
Bernhard Hämmerli, HTA Luzern, Switzerland
Javier Lopez, University of Malaga, Spain

* General Co-Chair
Sokratis Katsikas, University of the Aegean, Greece
Saifur Rahman, Advanced Research Institute, Virginia Tech, US

* Sponsorship Co-Chairs
Marcelo Masera, IPSC, Italy
Stephen D. Wolthusen, Royal Holloway, UK

* Program Committee (tentative; list of expertds invited to join)
Fabrizio Baiardi, Università de Pisa, Italy
Stefan Brem, Federal Office for Civil Protection, Switzerland
Jim Clarke, Waterford Institute of Technology, Ireland
Jorge Cuellar, Siemens, Germany
Weidong Cui, Microsoft Research, US
Yvo Desmedt, University College London, UK
Ed Dawson, QUT, Australia
Myriam Dunn, ETH Zurich, Switzerland
Paul Friessem, Fraunhofer, Germany
Urs Gattiker, CyTRAP Labs, Switzerland
Adrian Gheorghe, Old Dominion University, US
Eric Goetz, Dartmouth College, US
Solange Ghernaouti-Hélie, Univ. de Lausanne, Switzerland
Janusz Gorski, Gdansk University of Technology, Poland
Rune Gustavsson, Blekinge Inst. of Technology, Sweden
John Griffin, IBM T.J. Watson, US
Stefanos Gritzalis, University of the Aegean, Greece
Ming-Yuh Huang, Boeing, US
Håkan Kvarnström, TeliaSonera, Sweden
Diego Lopez, RedIRIS, Spain
Eric Luiijf, TNO, Netherlands
Tom McCutcheon, NISCC, UK
Yuko Murayama, Iwate Prefectural University, Japan
Simin Nadjm-Tehrani, Linköping University, Sweden
Syed Naqvi, CETIC, Belgium
Eiji Okamoto, Univ. of Tsukuba, Japan
Andrew Powell, CPNI, UK
Kai Rannenberg, Goethe University Frankfurt, Germany
Dirk Reinermann, BSI, Germany
Michel Riguidel, ENST, France
Roberto Setola, Univ. Campus Bio-Medico di Roma, Italy
Sujeet Shenoi, University of Tulsa, US
Robin Sommer, LBNL/ICSI, US
Paulo Veríssimo, Universidade de Lisboa, Portugal
Yuliang Zheng, University of North Carolina, US
Jianying Zhou, I2R, Singapore


* Information about past CRITIS'06

http://critis06.lcc.uma.es    





From alcaraz@lcc.uma.es Mon May 14 09:50:09 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4EDo9s1006463
	for ; Mon, 14 May 2007 09:50:09 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4EDo5g7016835
	for ; Mon, 14 May 2007 09:50:05 -0400 (EDT)
Received: from nala.ctima.uma.es (nala.ctima.uma.es [150.214.57.23])
	by mit.edu (Spam Firewall) with ESMTP id BC1BD293DA7
	for ; Mon, 14 May 2007 09:50:03 -0400 (EDT)
Received: from nala.ctima.uma.es (localhost [127.0.0.1])
	by localhost.ctima.uma.es (Postfix) with ESMTP id 508B8B3AE
	for ; Mon, 14 May 2007 15:49:59 +0200 (CEST)
Received: from sol10.lcc.uma.es (sol10.lcc.uma.es [150.214.108.1])by 
	nala.ctima.uma.es (Postfix) with ESMTP id 1777FB3ABfor ;
	Mon, 14 May 2007 15:49:59 +0200 (CEST)
Received: from [127.0.0.1] (unknown [150.214.56.133])by sol10.lcc.uma.es 
	(Postfix) with ESMTP id D42E338CEEfor ; Mon, 14 May 2007 
	15:49:58 +0200 (CEST)
Message-ID: <46486903.80507@lcc.uma.es>
Date: Mon, 14 May 2007 15:49:55 +0200
From: Cristina Alcaraz Tello 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: saag@mit.edu
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 000740-0, 13/05/2007), Outbound message
X-Antivirus-Status: Clean
X-imss-version: 2.046
X-imss-result: Passed
X-imss-approveListMatch: *@*.uma.es
X-Spam-Score: 0.78
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] Second International Workshop on Critical Information
	InfrastructuresSecurity (CRITIS'07)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Mon, 14 May 2007 13:50:10 -0000


** Apologies for multiple copies **

F i r s t     C a l l     F o r     P a p e r s

Second International Workshop on Critical Information Infrastructures 
Security (CRITIS'07)
October 3-5, 2007
Benalmadena-Costa, Malaga, Spain

http://critis07.lcc.uma.es    


CRITI'07, co-sponsored by IFIP WG 11.10 on Critical Infrastructures
Protection, IEEE Computer Society Task Force on Information Assurance,
and Joint Research Center Ispra of the European Commission, wants to
bring together researchers and professionals from universities, private
companies and Public Administrations interested or involved in all
security-related heterogeneous aspects of
Critical Information Infrastructures.
We invite research papers, work-in-progress reports, R&D projects results,
surveying works and industrial experiences describing significant security
advances in the following (non-exclusive) areas of Critical Information
Infrastructures for which we plan to have sessions:

- Code of Practice and Metrics     
- Communication Risk & Assurance    
- Early Warning Systems         
- Economics on CIP
- R&D Agenda            
- SCADA and Embedded Security    
- National and Cross Border Issues    
- Information Sharing and Exchange    
- Policy Options Elaboration        
- Threats and Attacks Modeling

Furthermore, the following topics are within the scope of CRITIS?07:

- Continuity of Services and Resiliency
- Dependable Infrastructure Communications
- Internet-based remote control    
- Forensic Techniques         
- Incident Response            
- Network Survivability        
- Trust Models in Critical Scenarios    
- Security Logistics    


* Instructions for paper submission

All submissions will be subjected to a thorough blind review by at least
three reviewers. Papers should be up to 12 pages in English, including
bibliography and well-marked appendices.
As in the case of CRITIS?06, it is planned that post-proceedings are 
published
by Springer in the Lecture Notes in Computer Science (LNCS) series.
Pre-proceedings will appear at the time of the conference.
To submit a paper, follow the specific instructions on the Workshop website

The submitted paper (in PDF or PostScript format), which should follow the
template indicated by Springer
,
must start with a title, a short abstract, and a
list of keywords. However, it should be
anonymous without author(s), affiliations,
acknowledgements, nor obvious references.


* Important dates

Submission of papers: June 25th, 2007
Notification to authors: July 30th, 2007
Camera-ready copies: August 24th, 2007


* Program Committee Co-Chairs
Bernhard Hämmerli, HTA Luzern, Switzerland
Javier Lopez, University of Malaga, Spain

* General Co-Chair
Sokratis Katsikas, University of the Aegean, Greece
Saifur Rahman, Advanced Research Institute, Virginia Tech, US

* Sponsorship Co-Chairs
Marcelo Masera, IPSC, Italy
Stephen D. Wolthusen, Royal Holloway, UK

* Program Committee (tentative; list of expertds invited to join)
Fabrizio Baiardi, Università de Pisa, Italy
Stefan Brem, Federal Office for Civil Protection, Switzerland
Jim Clarke, Waterford Institute of Technology, Ireland
Jorge Cuellar, Siemens, Germany
Weidong Cui, Microsoft Research, US
Yvo Desmedt, University College London, UK
Ed Dawson, QUT, Australia
Myriam Dunn, ETH Zurich, Switzerland
Paul Friessem, Fraunhofer, Germany
Urs Gattiker, CyTRAP Labs, Switzerland
Adrian Gheorghe, Old Dominion University, US
Eric Goetz, Dartmouth College, US
Solange Ghernaouti-Hélie, Univ. de Lausanne, Switzerland
Janusz Gorski, Gdansk University of Technology, Poland
Rune Gustavsson, Blekinge Inst. of Technology, Sweden
John Griffin, IBM T.J. Watson, US
Stefanos Gritzalis, University of the Aegean, Greece
Ming-Yuh Huang, Boeing, US
Håkan Kvarnström, TeliaSonera, Sweden
Diego Lopez, RedIRIS, Spain
Eric Luiijf, TNO, Netherlands
Tom McCutcheon, NISCC, UK
Yuko Murayama, Iwate Prefectural University, Japan
Simin Nadjm-Tehrani, Linköping University, Sweden
Syed Naqvi, CETIC, Belgium
Eiji Okamoto, Univ. of Tsukuba, Japan
Andrew Powell, CPNI, UK
Kai Rannenberg, Goethe University Frankfurt, Germany
Dirk Reinermann, BSI, Germany
Michel Riguidel, ENST, France
Roberto Setola, Univ. Campus Bio-Medico di Roma, Italy
Sujeet Shenoi, University of Tulsa, US
Robin Sommer, LBNL/ICSI, US
Paulo Veríssimo, Universidade de Lisboa, Portugal
Yuliang Zheng, University of North Carolina, US
Jianying Zhou, I2R, Singapore


* Information about past CRITIS'06

http://critis06.lcc.uma.es    





From alcaraz@lcc.uma.es Mon May 14 10:15:15 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4EEFE2C017277
	for ; Mon, 14 May 2007 10:15:14 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4EEF5PI018194
	for ; Mon, 14 May 2007 10:15:08 -0400 (EDT)
Received: from nala.ctima.uma.es (nala.ctima.uma.es [150.214.57.23])
	by mit.edu (Spam Firewall) with ESMTP id 657B44760F5
	for ; Mon, 14 May 2007 10:12:57 -0400 (EDT)
Received: from nala.ctima.uma.es (localhost [127.0.0.1])
	by localhost.ctima.uma.es (Postfix) with ESMTP id 878D4B3E4
	for ; Mon, 14 May 2007 16:12:56 +0200 (CEST)
Received: from sol10.lcc.uma.es (sol10.lcc.uma.es [150.214.108.1])by 
	nala.ctima.uma.es (Postfix) with ESMTP id 4E78AB3DEfor ;
	Mon, 14 May 2007 16:12:56 +0200 (CEST)
Received: from [127.0.0.1] (unknown [150.214.56.133])by sol10.lcc.uma.es 
	(Postfix) with ESMTP id 862CF38CF3for ; Mon, 14 May 2007 
	16:12:45 +0200 (CEST)
Message-ID: <46486E5A.4040500@lcc.uma.es>
Date: Mon, 14 May 2007 16:12:42 +0200
From: Cristina Alcaraz Tello 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: saag@mit.edu
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 000740-0, 13/05/2007), Outbound message
X-Antivirus-Status: Clean
X-imss-version: 2.046
X-imss-result: Passed
X-imss-approveListMatch: *@*.uma.es
X-Spam-Score: 0.78
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] Second International Workshop on Critical Information
	InfrastructuresSecurity (CRITIS'07)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Mon, 14 May 2007 14:15:16 -0000


** Apologies for multiple copies **

F i r s t     C a l l     F o r     P a p e r s

Second International Workshop on Critical Information Infrastructures 
Security (CRITIS'07)
October 3-5, 2007
Benalmadena-Costa, Malaga, Spain

http://critis07.lcc.uma.es    


CRITI'07, co-sponsored by IFIP WG 11.10 on Critical Infrastructures
Protection, IEEE Computer Society Task Force on Information Assurance,
and Joint Research Center Ispra of the European Commission, wants to
bring together researchers and professionals from universities, private
companies and Public Administrations interested or involved in all
security-related heterogeneous aspects of
Critical Information Infrastructures.
We invite research papers, work-in-progress reports, R&D projects results,
surveying works and industrial experiences describing significant security
advances in the following (non-exclusive) areas of Critical Information
Infrastructures for which we plan to have sessions:

- Code of Practice and Metrics     
- Communication Risk & Assurance    
- Early Warning Systems         
- Economics on CIP
- R&D Agenda            
- SCADA and Embedded Security    
- National and Cross Border Issues    
- Information Sharing and Exchange    
- Policy Options Elaboration        
- Threats and Attacks Modeling

Furthermore, the following topics are within the scope of CRITIS?07:

- Continuity of Services and Resiliency
- Dependable Infrastructure Communications
- Internet-based remote control    
- Forensic Techniques         
- Incident Response            
- Network Survivability        
- Trust Models in Critical Scenarios    
- Security Logistics    


* Instructions for paper submission

All submissions will be subjected to a thorough blind review by at least
three reviewers. Papers should be up to 12 pages in English, including
bibliography and well-marked appendices.
As in the case of CRITIS?06, it is planned that post-proceedings are 
published
by Springer in the Lecture Notes in Computer Science (LNCS) series.
Pre-proceedings will appear at the time of the conference.
To submit a paper, follow the specific instructions on the Workshop website

The submitted paper (in PDF or PostScript format), which should follow the
template indicated by Springer
,
must start with a title, a short abstract, and a
list of keywords. However, it should be
anonymous without author(s), affiliations,
acknowledgements, nor obvious references.


* Important dates

Submission of papers: June 25th, 2007
Notification to authors: July 30th, 2007
Camera-ready copies: August 24th, 2007


* Program Committee Co-Chairs
Bernhard Hämmerli, HTA Luzern, Switzerland
Javier Lopez, University of Malaga, Spain

* General Co-Chair
Sokratis Katsikas, University of the Aegean, Greece
Saifur Rahman, Advanced Research Institute, Virginia Tech, US

* Sponsorship Co-Chairs
Marcelo Masera, IPSC, Italy
Stephen D. Wolthusen, Royal Holloway, UK

* Program Committee (tentative; list of expertds invited to join)
Fabrizio Baiardi, Università de Pisa, Italy
Stefan Brem, Federal Office for Civil Protection, Switzerland
Jim Clarke, Waterford Institute of Technology, Ireland
Jorge Cuellar, Siemens, Germany
Weidong Cui, Microsoft Research, US
Yvo Desmedt, University College London, UK
Ed Dawson, QUT, Australia
Myriam Dunn, ETH Zurich, Switzerland
Paul Friessem, Fraunhofer, Germany
Urs Gattiker, CyTRAP Labs, Switzerland
Adrian Gheorghe, Old Dominion University, US
Eric Goetz, Dartmouth College, US
Solange Ghernaouti-Hélie, Univ. de Lausanne, Switzerland
Janusz Gorski, Gdansk University of Technology, Poland
Rune Gustavsson, Blekinge Inst. of Technology, Sweden
John Griffin, IBM T.J. Watson, US
Stefanos Gritzalis, University of the Aegean, Greece
Ming-Yuh Huang, Boeing, US
Håkan Kvarnström, TeliaSonera, Sweden
Diego Lopez, RedIRIS, Spain
Eric Luiijf, TNO, Netherlands
Tom McCutcheon, NISCC, UK
Yuko Murayama, Iwate Prefectural University, Japan
Simin Nadjm-Tehrani, Linköping University, Sweden
Syed Naqvi, CETIC, Belgium
Eiji Okamoto, Univ. of Tsukuba, Japan
Andrew Powell, CPNI, UK
Kai Rannenberg, Goethe University Frankfurt, Germany
Dirk Reinermann, BSI, Germany
Michel Riguidel, ENST, France
Roberto Setola, Univ. Campus Bio-Medico di Roma, Italy
Sujeet Shenoi, University of Tulsa, US
Robin Sommer, LBNL/ICSI, US
Paulo Veríssimo, Universidade de Lisboa, Portugal
Yuliang Zheng, University of North Carolina, US
Jianying Zhou, I2R, Singapore


* Information about past CRITIS'06

http://critis06.lcc.uma.es    





From hartmans@MIT.EDU Wed May 16 15:27:55 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4GJRtV2023482
	for ; Wed, 16 May 2007 15:27:55 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4GJRr61018901
	for ; Wed, 16 May 2007 15:27:54 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org
	(carter-zimmerman.suchdamage.org [69.25.196.178])
	by mit.edu (Spam Firewall) with ESMTP id DB1004DAC7F
	for ; Wed, 16 May 2007 15:27:53 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042)
	id 477C1400F; Wed, 16 May 2007 15:27:53 -0400 (EDT)
To: saag@MIT.EDU
From: Sam Hartman 
Message-Id: <20070516192753.477C1400F@carter-zimmerman.suchdamage.org>
Date: Wed, 16 May 2007 15:27:53 -0400 (EDT)
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] Reminder: BOF proposals by May 22
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 16 May 2007 19:27:55 -0000


Tim and I just wanted to remind people who are considering proposing
new work in the security area that the deadline for BOF proposals to
the ADs is next Monday, May 222.

By this point you need to have an initial draft and a mailing list for
discussion.  You ideally should already have discussion on your list.

--Sam


From housley@vigilsec.com Wed May 16 16:49:32 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4GKnWgi007907
	for ; Wed, 16 May 2007 16:49:32 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4GKnUas022673
	for ; Wed, 16 May 2007 16:49:30 -0400 (EDT)
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2])
	by mit.edu (Spam Firewall) with SMTP id 2676F4ACBC5
	for ; Wed, 16 May 2007 16:49:29 -0400 (EDT)
Received: (qmail 21151 invoked by uid 0); 16 May 2007 20:49:23 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186)
	by woodstock.binhost.com with SMTP; 16 May 2007 20:49:23 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 16 May 2007 16:49:26 -0400
To: Sam Hartman , saag@mit.edu
From: Russ Housley 
In-Reply-To: <20070516192753.477C1400F@carter-zimmerman.suchdamage.org>
References: <20070516192753.477C1400F@carter-zimmerman.suchdamage.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-Id: <20070516204929.2676F4ACBC5@mit.edu>
X-Spam-Score: 0.84
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: Re: [saag] Reminder: BOF proposals by May 22
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 16 May 2007 20:49:32 -0000

Monday will be May 21st (not May 22nd or May 222nd).

According to http://www.ietf.org/meetings/69-cutoff_dates.html
the cut off time is 5:00 PM Eastern time.

Russ

At 03:27 PM 5/16/2007, Sam Hartman wrote:

>Tim and I just wanted to remind people who are considering proposing
>new work in the security area that the deadline for BOF proposals to
>the ADs is next Monday, May 222.
>
>By this point you need to have an initial draft and a mailing list for
>discussion.  You ideally should already have discussion on your list.
>
>--Sam
>
>_______________________________________________
>saag mailing list
>saag@mit.edu
>http://mailman.mit.edu/mailman/listinfo/saag


From narten@us.ibm.com Thu May 17 10:02:55 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4HE2toi026474
	for ; Thu, 17 May 2007 10:02:55 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4HE2r2R002955
	for ; Thu, 17 May 2007 10:02:53 -0400 (EDT)
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id BA35B58631B
	for ; Thu, 17 May 2007 10:02:52 -0400 (EDT)
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l4HE2qcX032262
	for ; Thu, 17 May 2007 10:02:52 -0400
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id
	l4HE2pVM554052 for ; Thu, 17 May 2007 10:02:51 -0400
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1])
	by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id
	l4HE2oXd027109 for ; Thu, 17 May 2007 10:02:51 -0400
Received: from cichlid.raleigh.ibm.com (wecm-9-67-147-104.wecm.ibm.com
	[9.67.147.104])
	by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id
	l4HE2kdT026663
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Thu, 17 May 2007 10:02:50 -0400
Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1])
	by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id l4HE2c1Y032332
	for ; Thu, 17 May 2007 10:02:41 -0400
Message-Id: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
To: saag@mit.edu
Date: Thu, 17 May 2007 10:02:37 -0400
From: Thomas Narten 
X-Spam-Score: 3.7
X-Spam-Level: *** (3.7)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 17 May 2007 14:02:55 -0000

As many of you know the USG is developing profiles for IPv6 and
IPsec. For the DISA/JITC profiles, they have been discussing the need
for AH with OSPF, and the current profiles require OSPF support AH.

RFC 4301 is pretty clear about AH:

> 3.2.  How IPsec Works
> 
>    IPsec uses two protocols to provide traffic security services --
>    Authentication Header (AH) and Encapsulating Security Payload (ESP).
>    Both protocols are described in detail in their respective RFCs
>    [Ken05b, Ken05a].  IPsec implementations MUST support ESP and MAY
>    support AH. (Support for AH has been downgraded to MAY because
>    experience has shown that there are very few contexts in which ESP
>    cannot provide the requisite security services.  Note that ESP can be
>    used to provide only integrity, without confidentiality, making it
>    comparable to AH in most contexts.)

Also, OSPFv3 (RFC 4552) mandates ESP, but leaves AH optional:

>    In order to provide authentication to OSPFv3, implementations MUST
>    support ESP and MAY support AH.

In the current DISA/JITC Profiles, there is a statement that OSPFv3
routers MUST use AH for router-to-router integrity checking.  My
understanding is that the rational for this requirement is as follows:

> > > > AH is a requirement for OSPFv3 routers because, in the case of a
> > > > flooding protocol like OSPF, replayed updates from a different IPv6
> > > > address will cause problems and ESP-NULL will not help this.  That is
> > > > the simple answer.  As a result, please leave AH in for OSPF routers.
> > > 
> > > You are right, according to RFC 4552, that ESP-NULL will not help this.
> > > But you are wrong that AH will help this. Anyone who has access to the
> > > keys and can use the SA can forge a packet using AH or ESP. As I said
> > > before, AH is perfectly capable of authenticating a forged source address.
> > > It does not care.
> > > 
> > > The RFC 4552 work got backed into a corner on this one. Because IKEv2
> > > didn't handle their situation, they specified manual keying. But the IPsec
> > > people got nervous about using replay detection with manual keying,
> > > because there was no good choice when the counter wrapped around. But then
> > > the IPsec people invented 64-bit counters and the 4552 work said change
> > > keys every three months. So this is a false problem. Seems that one would
> > > avoid wrap-around even if sending many billions of messages a second for a
> > > thousand years. So short of fixing the problem in the standards, just use
> > > 64 bit counters and turn on replay detect with ESP (MUST) or with AH
> > > (MAY). The affect is the same. The extra overhead of supporting AH (code
> > > size and processing time) is as superfluous as ever.
> > > 
> > > Note, again, that the RFC 4552 authors are right: AH (MAY) does nothing to
> > > help solve this problem that ESP (MUST) doesn't do. Please stop making
> > > claims for AH capabilitities that are misleading.
> 
> > IMHO, if some one has access to your keys and is using them maliciously,
> > you have much larger security issues than a forged OSPF LSA.  No one
> > ever claimed that AH, or IPsec in general, in any way mitigates against
> > insider threats.  That is what background investigations,
> > non-repudiation and auditing are for.
> > 
> > As to the use of PKI (in specific IKE), as I said above, non-repudiation
> > takes care of this issue; however, PKI for authenticating routing
> > updates, or even router access, is not and cannot always be deployed.
> > As a result, the paradigm reverts to shared private keys.  Further,
> > conservation of laziness, along with the exigencies of configuration
> > management complexity, tends to push folks towards a single set of keys
> > mapped to the source address or even a single key.  As a result, if an
> > LSA is captured, it can be retransmitted with a different destination
> > address.  This would probably cause problems.
> > 
> > As a result, I am not making misleading claims about AH.  It appears
> > that you did not understand what I was claiming.  As a result, let me
> > recap:
> > 
> > 1. AH mitigates replay attacks in the absence of source/destination
> > unique shared private keys or PKI.
> > 2. AH, and IPsec in general, do not mitigate against insider threats,
> > configuration mistakes or general tomfoolery.
> > 
> > Agreed?
> 
> I think I now understand better what you mean by replay. I had thought,
> incorrectly, that you meant playing an old stale message back to to the
> same recipient. Instead, you mean playing a message intended for recipient
> A to recipient B. Right?
> 
> In most "ordinary uses" of IPsec, this can't work, of course, so this is
> different. I have to think about it more before having an opinion.

I'd welcome additional feedback on this issue. Does the use of AH with
OSPF provide significant additional checks compared with ESP and NULL
encryption?

Thomas

From vishwas.ietf@gmail.com Thu May 17 11:54:04 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4HFs4JG028607
	for ; Thu, 17 May 2007 11:54:04 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4HFs2gN023597
	for ; Thu, 17 May 2007 11:54:03 -0400 (EDT)
Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225])
	by mit.edu (Spam Firewall) with ESMTP id 046062C53B8
	for ; Thu, 17 May 2007 11:54:01 -0400 (EDT)
Received: by wr-out-0506.google.com with SMTP id i22so587236wra
	for ; Thu, 17 May 2007 08:54:01 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=EdsFRlPcOzFADvQl6Dox+zHgQElBDNHOSbDpsm9xQDXla99ECjG8tYR+RAEQhazgBvSWVeIEyPBCoYRPXYn2jZmbZoHcXelU5WeWL52Y7ffZVODWPYNmhH15Sbla5SN27cWjZyDavBeq1s04TWJ2jYm6rYGKWwTwKvXhTeAoqXY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=Tz1cL5gEWuHI5j25V9WmHK2MqpbygtnyPgytUDs2Itk/fl+1QF+R23qBEK4ymTnz1TVFNXkAPqxvICa/jRB8OBnGxbLzgoNqOOtBJ92HKIqHnkESHuTlCof78TwfyKsGfLgC7UQNt/qlmuOGIilPb6XCZx28dX4agiHma6UyjwM=
Received: by 10.114.174.2 with SMTP id w2mr284047wae.1179417240601;
	Thu, 17 May 2007 08:54:00 -0700 (PDT)
Received: by 10.114.24.9 with HTTP; Thu, 17 May 2007 08:54:00 -0700 (PDT)
Message-ID: <77ead0ec0705170854i2b95c3a5y74be8fd58325c542@mail.gmail.com>
Date: Thu, 17 May 2007 21:24:00 +0530
From: "Vishwas Manral" 
To: "Thomas Narten" 
In-Reply-To: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 17 May 2007 15:54:04 -0000

Hi Thomas,

I did not fully understand the question you have put forward. I have
worked on OSPF as well as IPsec, and am acknowledged in the IPsec for
OSPFv3 draft too.

The reason OSPF says support for AH is a may and ESP is a MUST is
because RFC4301 clearly states the same. Yes with Manual Keying Replay
protection cannot be given as again specified in RFC4301 and OSPF uses
Manual Keying.

I am unable to understand the statement
> > > > > AH is a requirement for OSPFv3 routers because, in the case of a
> > > > > flooding protocol like OSPF, replayed updates from a different IPv6
> > > > > address will cause problems and ESP-NULL will not help this.  That is
> > > > > the simple answer.  As a result, please leave AH in for OSPF routers.

Could you point me to the location of the thread archive if that will
help in anyway?

Thanks,
Vishwas

On 5/17/07, Thomas Narten  wrote:
> As many of you know the USG is developing profiles for IPv6 and
> IPsec. For the DISA/JITC profiles, they have been discussing the need
> for AH with OSPF, and the current profiles require OSPF support AH.
>
> RFC 4301 is pretty clear about AH:
>
> > 3.2.  How IPsec Works
> >
> >    IPsec uses two protocols to provide traffic security services --
> >    Authentication Header (AH) and Encapsulating Security Payload (ESP).
> >    Both protocols are described in detail in their respective RFCs
> >    [Ken05b, Ken05a].  IPsec implementations MUST support ESP and MAY
> >    support AH. (Support for AH has been downgraded to MAY because
> >    experience has shown that there are very few contexts in which ESP
> >    cannot provide the requisite security services.  Note that ESP can be
> >    used to provide only integrity, without confidentiality, making it
> >    comparable to AH in most contexts.)
>
> Also, OSPFv3 (RFC 4552) mandates ESP, but leaves AH optional:
>
> >    In order to provide authentication to OSPFv3, implementations MUST
> >    support ESP and MAY support AH.
>
> In the current DISA/JITC Profiles, there is a statement that OSPFv3
> routers MUST use AH for router-to-router integrity checking.  My
> understanding is that the rational for this requirement is as follows:
>
> > > > > AH is a requirement for OSPFv3 routers because, in the case of a
> > > > > flooding protocol like OSPF, replayed updates from a different IPv6
> > > > > address will cause problems and ESP-NULL will not help this.  That is
> > > > > the simple answer.  As a result, please leave AH in for OSPF routers.
> > > >
> > > > You are right, according to RFC 4552, that ESP-NULL will not help this.
> > > > But you are wrong that AH will help this. Anyone who has access to the
> > > > keys and can use the SA can forge a packet using AH or ESP. As I said
> > > > before, AH is perfectly capable of authenticating a forged source address.
> > > > It does not care.
> > > >
> > > > The RFC 4552 work got backed into a corner on this one. Because IKEv2
> > > > didn't handle their situation, they specified manual keying. But the IPsec
> > > > people got nervous about using replay detection with manual keying,
> > > > because there was no good choice when the counter wrapped around. But then
> > > > the IPsec people invented 64-bit counters and the 4552 work said change
> > > > keys every three months. So this is a false problem. Seems that one would
> > > > avoid wrap-around even if sending many billions of messages a second for a
> > > > thousand years. So short of fixing the problem in the standards, just use
> > > > 64 bit counters and turn on replay detect with ESP (MUST) or with AH
> > > > (MAY). The affect is the same. The extra overhead of supporting AH (code
> > > > size and processing time) is as superfluous as ever.
> > > >
> > > > Note, again, that the RFC 4552 authors are right: AH (MAY) does nothing to
> > > > help solve this problem that ESP (MUST) doesn't do. Please stop making
> > > > claims for AH capabilitities that are misleading.
> >
> > > IMHO, if some one has access to your keys and is using them maliciously,
> > > you have much larger security issues than a forged OSPF LSA.  No one
> > > ever claimed that AH, or IPsec in general, in any way mitigates against
> > > insider threats.  That is what background investigations,
> > > non-repudiation and auditing are for.
> > >
> > > As to the use of PKI (in specific IKE), as I said above, non-repudiation
> > > takes care of this issue; however, PKI for authenticating routing
> > > updates, or even router access, is not and cannot always be deployed.
> > > As a result, the paradigm reverts to shared private keys.  Further,
> > > conservation of laziness, along with the exigencies of configuration
> > > management complexity, tends to push folks towards a single set of keys
> > > mapped to the source address or even a single key.  As a result, if an
> > > LSA is captured, it can be retransmitted with a different destination
> > > address.  This would probably cause problems.
> > >
> > > As a result, I am not making misleading claims about AH.  It appears
> > > that you did not understand what I was claiming.  As a result, let me
> > > recap:
> > >
> > > 1. AH mitigates replay attacks in the absence of source/destination
> > > unique shared private keys or PKI.
> > > 2. AH, and IPsec in general, do not mitigate against insider threats,
> > > configuration mistakes or general tomfoolery.
> > >
> > > Agreed?
> >
> > I think I now understand better what you mean by replay. I had thought,
> > incorrectly, that you meant playing an old stale message back to to the
> > same recipient. Instead, you mean playing a message intended for recipient
> > A to recipient B. Right?
> >
> > In most "ordinary uses" of IPsec, this can't work, of course, so this is
> > different. I have to think about it more before having an opinion.
>
> I'd welcome additional feedback on this issue. Does the use of AH with
> OSPF provide significant additional checks compared with ESP and NULL
> encryption?
>
> Thomas

From narten@us.ibm.com Thu May 17 12:23:53 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4HGNr16004257
	for ; Thu, 17 May 2007 12:23:53 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4HGNquw026071
	for ; Thu, 17 May 2007 12:23:52 -0400 (EDT)
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 230FB58EEEE
	for ; Thu, 17 May 2007 12:23:51 -0400 (EDT)
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l4HGNla9006747
	for ; Thu, 17 May 2007 12:23:48 -0400
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215])
	by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id
	l4HGNlup518882 for ; Thu, 17 May 2007 12:23:47 -0400
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1])
	by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id
	l4HGNlrF007351 for ; Thu, 17 May 2007 12:23:47 -0400
Received: from cichlid.raleigh.ibm.com (wecm-9-67-147-104.wecm.ibm.com
	[9.67.147.104])
	by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id
	l4HGNkV4007300
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 17 May 2007 12:23:47 -0400
Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1])
	by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id l4HGNh5N006193;
	Thu, 17 May 2007 12:23:44 -0400
Message-Id: <200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com>
To: "Vishwas Manral" 
In-reply-to: <77ead0ec0705170854i2b95c3a5y74be8fd58325c542@mail.gmail.com> 
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	<77ead0ec0705170854i2b95c3a5y74be8fd58325c542@mail.gmail.com>
Comments: In-reply-to "Vishwas Manral" 
	message dated "Thu, 17 May 2007 21:24:00 +0530."
Date: Thu, 17 May 2007 12:23:43 -0400
From: Thomas Narten 
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 17 May 2007 16:23:54 -0000

> I did not fully understand the question you have put forward. I have
> worked on OSPF as well as IPsec, and am acknowledged in the IPsec for
> OSPFv3 draft too.

What I'm asking is what additional protections (if any) the use of AH
provides over using ESP with NULL encryption when IPsec is used to
protect OSPF.

That is, does it really make sense to require AH (as DISA/JITC
currently does)? Or does this in effect have little or no value.

> Could you point me to the location of the thread archive if that will
> help in anyway?

I've quoted what I think is the main exchange, but left it anonymous
because the list it occurred on is probably private, though by no
means would I assume anything posted there could reasonably be
expected to remain secret. :-)

Thomas

From kent@bbn.com Thu May 17 16:16:09 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4HKG9Wt021720
	for ; Thu, 17 May 2007 16:16:09 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4HKG7Ep020790
	for ; Thu, 17 May 2007 16:16:08 -0400 (EDT)
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80])
	by mit.edu (Spam Firewall) with ESMTP id C7188492E79
	for ; Thu, 17 May 2007 16:15:54 -0400 (EDT)
Received: from dhcp89-089-071.bbn.com ([128.89.89.71])
	by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from )
	id 1HomO9-0008DC-6I; Thu, 17 May 2007 16:15:54 -0400
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com>
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	<77ead0ec0705170854i2b95c3a5y74be8fd58325c542@mail.gmail.com>
	<200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com>
Date: Thu, 17 May 2007 16:15:53 -0400
To: Thomas Narten 
From: Stephen Kent 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 17 May 2007 20:16:09 -0000

At 12:23 PM -0400 5/17/07, Thomas Narten wrote:
>  > I did not fully understand the question you have put forward. I have
>>  worked on OSPF as well as IPsec, and am acknowledged in the IPsec for
>>  OSPFv3 draft too.
>
>What I'm asking is what additional protections (if any) the use of AH
>provides over using ESP with NULL encryption when IPsec is used to
>protect OSPF.
>
>That is, does it really make sense to require AH (as DISA/JITC
>currently does)? Or does this in effect have little or no value.
>
>>  Could you point me to the location of the thread archive if that will
>>  help in anyway?
>
>I've quoted what I think is the main exchange, but left it anonymous
>because the list it occurred on is probably private, though by no
>means would I assume anything posted there could reasonably be
>expected to remain secret. :-)
>
>Thomas

Thomas,

If the OSPF traffic is protected via tunnel mode, then there should 
be no difference in the security offered by AH vs. ESP-NULL.

If OSPF traffic is protected via transport mode, then there could be 
some differences, but only if there are security-critical fields in 
the IP header (vs. the IP payload). For most (user) traffic there are 
no significant differences, but one would have to look closely at the 
OSPF assumptions about IP header data that would be protected by AH 
to see if there were security-relevant differences.

Steve

From mbaugher@cisco.com Fri May 18 13:27:44 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4IHRiQL009385
	for ; Fri, 18 May 2007 13:27:44 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4IHRgYe005115
	for ; Fri, 18 May 2007 13:27:42 -0400 (EDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117])
	by mit.edu (Spam Firewall) with ESMTP id C7BDB2B01DB
	for ; Fri, 18 May 2007 13:27:41 -0400 (EDT)
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-6.cisco.com with ESMTP; 18 May 2007 10:27:40 -0700
X-IronPort-AV: i="4.14,553,1170662400"; 
	d="scan'208"; a="151099409:sNHT539544402"
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l4IHRea8022412; 
	Fri, 18 May 2007 10:27:40 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l4IHRctx004146;
	Fri, 18 May 2007 17:27:40 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 18 May 2007 10:27:33 -0700
Received: from [192.168.0.10] ([10.21.88.41]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 18 May 2007 10:27:32 -0700
In-Reply-To: <200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com>
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	<77ead0ec0705170854i2b95c3a5y74be8fd58325c542@mail.gmail.com>
	<200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Mark Baugher 
Date: Fri, 18 May 2007 10:27:29 -0700
To: Thomas Narten 
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 18 May 2007 17:27:32.0944 (UTC)
	FILETIME=[D18DE500:01C79971]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1094; t=1179509260;
	x=1180373260; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=mbaugher@cisco.com;
	z=From:=20Mark=20Baugher=20
	|Subject:=20Re=3A=20[saag]=20AH=20&=20OSPF |Sender:=20;
	bh=wxQ1H9ZoM1JUr0X8p5Kq5d2jVYfxbYgLfIuNTsuHdjg=;
	b=CkZjkiY+iqCcoMWe+lk+UyYijei8TGZEZRpedGcwoAhVjCNX+IBDSBdovp3SCEbwiM9PB1y7
	1wq6qqdBBWeD5X+ZUdv0vg0FHkXY6cnCR/hTNF5h7i8KBpic+xDtJc/q;
Authentication-Results: sj-dkim-4; header.From=mbaugher@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim4002 verified; ); 
X-Spam-Score: 0.13
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 18 May 2007 17:27:44 -0000


On May 17, 2007, at 9:23 AM, Thomas Narten wrote:

>> I did not fully understand the question you have put forward. I have
>> worked on OSPF as well as IPsec, and am acknowledged in the IPsec for
>> OSPFv3 draft too.
>
> What I'm asking is what additional protections (if any) the use of AH
> provides over using ESP with NULL encryption when IPsec is used to
> protect OSPF.

AH is inspectable by intermediate systems.  ESP NULL really isn't.

Mark

>
> That is, does it really make sense to require AH (as DISA/JITC
> currently does)? Or does this in effect have little or no value.
>
>> Could you point me to the location of the thread archive if that will
>> help in anyway?
>
> I've quoted what I think is the main exchange, but left it anonymous
> because the list it occurred on is probably private, though by no
> means would I assume anything posted there could reasonably be
> expected to remain secret. :-)
>
> Thomas
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://mailman.mit.edu/mailman/listinfo/saag

From paul.hoffman@vpnc.org Fri May 18 14:03:58 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4II3wd3015817
	for ; Fri, 18 May 2007 14:03:58 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4II3uEm017098
	for ; Fri, 18 May 2007 14:03:57 -0400 (EDT)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 600164EFB6A
	for ; Fri, 18 May 2007 14:03:52 -0400 (EDT)
Received: from [10.20.30.104] (adsl-66-125-125-65.dsl.pltn13.pacbell.net
	[66.125.125.65]) (authenticated bits=0)
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4II3jcq060275
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 18 May 2007 11:03:46 -0700 (MST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	<77ead0ec0705170854i2b95c3a5y74be8fd58325c542@mail.gmail.com>
	<200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com>
	
Date: Fri, 18 May 2007 11:03:38 -0700
To: Mark Baugher , Thomas Narten 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 18 May 2007 18:03:59 -0000

At 10:27 AM -0700 5/18/07, Mark Baugher wrote:
>On May 17, 2007, at 9:23 AM, Thomas Narten wrote:
>
>>>  I did not fully understand the question you have put forward. I have
>>>  worked on OSPF as well as IPsec, and am acknowledged in the IPsec for
>>>  OSPFv3 draft too.
>>
>>  What I'm asking is what additional protections (if any) the use of AH
>>  provides over using ESP with NULL encryption when IPsec is used to
>>  protect OSPF.
>
>AH is inspectable by intermediate systems.  ESP NULL really isn't.

Could you explain this in more detail? Why wouldn't an intermediary 
be able to read data in an ESP NULL packet?

--Paul Hoffman, Director
--VPN Consortium

From Nicolas.Williams@sun.com Fri May 18 14:22:06 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4IIM6Aj019378
	for ; Fri, 18 May 2007 14:22:06 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4IIM4HS019226
	for ; Fri, 18 May 2007 14:22:05 -0400 (EDT)
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	by mit.edu (Spam Firewall) with ESMTP id 864C44F2BDF
	for ; Fri, 18 May 2007 14:22:04 -0400 (EDT)
Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199])
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	l4IIM3o9021581 for ; Fri, 18 May 2007 18:22:03 GMT
Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104])
	by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id l4IIM3Qw012894
	for ; Fri, 18 May 2007 12:22:03 -0600 (MDT)
Received: from binky.central.sun.com (localhost [127.0.0.1])
	by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id
	l4IIKkuS021480; Fri, 18 May 2007 13:20:46 -0500 (CDT)
Received: (from nw141292@localhost)
	by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l4IIKig2021479; 
	Fri, 18 May 2007 13:20:44 -0500 (CDT)
X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to
	Nicolas.Williams@sun.com using -f
Date: Fri, 18 May 2007 13:20:44 -0500
From: Nicolas Williams 
To: Paul Hoffman 
Message-ID: <20070518182044.GJ20378@Sun.COM>
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	<77ead0ec0705170854i2b95c3a5y74be8fd58325c542@mail.gmail.com>
	<200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com>
	
	
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: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: Thomas Narten , saag@mit.edu,
	Mark Baugher 
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 18 May 2007 18:22:06 -0000

On Fri, May 18, 2007 at 11:03:38AM -0700, Paul Hoffman wrote:
> At 10:27 AM -0700 5/18/07, Mark Baugher wrote:
> >AH is inspectable by intermediate systems.  ESP NULL really isn't.
> 
> Could you explain this in more detail? Why wouldn't an intermediary 
> be able to read data in an ESP NULL packet?

Abstraction violation?

From smb@cs.columbia.edu Fri May 18 15:05:13 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4IJ5CFO026969
	for ; Fri, 18 May 2007 15:05:12 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4IJ5BoB010243
	for ; Fri, 18 May 2007 15:05:11 -0400 (EDT)
Received: from machshav.com (machshav.com [198.180.150.44])
	by mit.edu (Spam Firewall) with ESMTP id D320A4B345D
	for ; Fri, 18 May 2007 15:05:10 -0400 (EDT)
Received: from berkshire.machshav.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP id 585C6B552;
	Fri, 18 May 2007 19:05:10 +0000 (GMT)
Received: by berkshire.machshav.com (Postfix, from userid 54047)
	id 4DFB27666A3; Fri, 18 May 2007 15:05:09 -0400 (EDT)
Date: Fri, 18 May 2007 15:05:09 -0400
From: "Steven M. Bellovin" 
To: Mark Baugher 
In-Reply-To: 
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	<77ead0ec0705170854i2b95c3a5y74be8fd58325c542@mail.gmail.com>
	<200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com>
	
Organization: Columbia University
X-Mailer: Claws Mail 2.9.2 (GTK+ 2.10.12; i386--netbsdelf)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <20070518190509.4DFB27666A3@berkshire.machshav.com>
X-Spam-Score: 0.13
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: Thomas Narten , saag@mit.edu
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 18 May 2007 19:05:13 -0000

On Fri, 18 May 2007 10:27:29 -0700
Mark Baugher  wrote:

> 
> On May 17, 2007, at 9:23 AM, Thomas Narten wrote:
> 
> >> I did not fully understand the question you have put forward. I
> >> have worked on OSPF as well as IPsec, and am acknowledged in the
> >> IPsec for OSPFv3 draft too.
> >
> > What I'm asking is what additional protections (if any) the use of
> > AH provides over using ESP with NULL encryption when IPsec is used
> > to protect OSPF.
> 
> AH is inspectable by intermediate systems.  ESP NULL really isn't.
> 
>
What intermediate systems?  We're talking OSPF here, which isn't even
forwarded through routers.


		--Steve Bellovin, http://www.cs.columbia.edu/~smb

From mbaugher@cisco.com Fri May 18 15:59:18 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4IJxITI004002
	for ; Fri, 18 May 2007 15:59:18 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4IJxG3d029648
	for ; Fri, 18 May 2007 15:59:16 -0400 (EDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86])
	by mit.edu (Spam Firewall) with ESMTP id 4DCBF4B3A11
	for ; Fri, 18 May 2007 15:59:13 -0400 (EDT)
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-4.cisco.com with ESMTP; 18 May 2007 12:59:12 -0700
X-IronPort-AV: i="4.14,553,1170662400"; d="scan'208"; a="1514421:sNHT20656134"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4IJxCjw020625; 
	Fri, 18 May 2007 12:59:12 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4IJwt2S027569;
	Fri, 18 May 2007 19:59:12 GMT
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.1830); 
	Fri, 18 May 2007 12:59:06 -0700
Received: from [192.168.0.10] ([10.21.88.41]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 18 May 2007 12:59:06 -0700
In-Reply-To: 
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	<77ead0ec0705170854i2b95c3a5y74be8fd58325c542@mail.gmail.com>
	<200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com>
	
	
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Mark Baugher 
Date: Fri, 18 May 2007 12:59:05 -0700
To: Paul Hoffman 
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 18 May 2007 19:59:06.0528 (UTC)
	FILETIME=[FDC0B200:01C79986]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1945; t=1179518352;
	x=1180382352; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=mbaugher@cisco.com;
	z=From:=20Mark=20Baugher=20
	|Subject:=20Re=3A=20[saag]=20AH=20&=20OSPF |Sender:=20;
	bh=FCR5cZV/HkJhnCD28kI6mNzKukstec0koj5s40RhamQ=;
	b=CGfL6ar+HpZiAl4JlUkne9NHjqjwvbLWVCENXOvjgION3j8sgPREKXp6aUW8FvO49NaKeuCo
	ehUx7EZM50pkzBJD8OYszcLmCoWNMsCmWa+02Yd8faR+j7aVRURvDg/EI7VbgyKE2kMBmr/uUt
	LVEhcTHWGIjCzxssNiABrYPs8=;
Authentication-Results: sj-dkim-1; header.From=mbaugher@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: 0.01
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: Thomas Narten , saag@mit.edu
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 18 May 2007 19:59:20 -0000


On May 18, 2007, at 11:03 AM, Paul Hoffman wrote:

> Could you explain this in more detail? Why wouldn't an intermediary  
> be able to read data in an ESP NULL packet?

AH was designed to be inspected whereas ESP was not.  The first  
problem is discriminating between an ESP packet that is encrypted  
from an ESP NULL packet.  One might inspect the ESP fields for  
expected ESP NULL values. But ESP uses a trailer and the fields you  
want to inspect precede the variable-length ICV field.  So the  
intermediate device needs to assume a fixed-length ICV, which will  
make for a brittle solution, i.e. one that breaks when the ICV length  
varies.

So what if we assume the ICV is fixed length because it is today for  
all practical purposes?  You might use the next header field, inspect  
the padding, etc.  In general, Next Header can assume many potential  
values and each has a small probability of yielding a false positive  
if encrypted.  This is also true for the Pad Length, which has a  
1/256 probability of assuming zero when encrypted.  Another source of  
false positives, which may be reduced by combining this inspection  
with inspection of the encapsulated packet.  That's assuming that we  
can locate the packet.  If the particular authentication algorithm  
uses an IV or authentication data at the start of the payload, then  
that would be an potential source of false negatives.

This might work for passive monitoring of networks that run a static  
IPsec policy, restrict the types of protocols that run on the  
network, and don't disrupt operation if/when those policies are  
violated.  It won't support high-speed packet switching for a typical  
TCP or UDP router ACL, however, because the needed information is in  
a packet trailer rather than a header.  Routers typically inspect the  
first hundred bytes or so and make a forwarding decision based on that.


Mark

From mbaugher@cisco.com Fri May 18 16:17:56 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4IKHuJB011229
	for ; Fri, 18 May 2007 16:17:56 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4IKHgtK015640
	for ; Fri, 18 May 2007 16:17:46 -0400 (EDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87])
	by mit.edu (Spam Firewall) with ESMTP id B8BB02CEE49
	for ; Fri, 18 May 2007 16:15:46 -0400 (EDT)
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-5.cisco.com with ESMTP; 18 May 2007 13:15:46 -0700
X-IronPort-AV: i="4.14,553,1170662400"; 
	d="scan'208"; a="155138284:sNHT114597639"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4IKFkP4007670; 
	Fri, 18 May 2007 13:15:46 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4IKFdag002451;
	Fri, 18 May 2007 20:15:45 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 18 May 2007 13:15:45 -0700
Received: from [192.168.0.10] ([10.21.88.41]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 18 May 2007 13:15:45 -0700
In-Reply-To: <20070518190509.4DFB27666A3@berkshire.machshav.com>
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	<77ead0ec0705170854i2b95c3a5y74be8fd58325c542@mail.gmail.com>
	<200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com>
	
	<20070518190509.4DFB27666A3@berkshire.machshav.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <587F7B8C-C259-4D9A-BE55-5ACC4CD3C40E@cisco.com>
Content-Transfer-Encoding: 7bit
From: Mark Baugher 
Date: Fri, 18 May 2007 13:15:44 -0700
To: "Steven M. Bellovin" 
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 18 May 2007 20:15:45.0278 (UTC)
	FILETIME=[510DD9E0:01C79989]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=821; t=1179519346;
	x=1180383346; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=mbaugher@cisco.com;
	z=From:=20Mark=20Baugher=20
	|Subject:=20Re=3A=20[saag]=20AH=20&=20OSPF |Sender:=20;
	bh=7X7dxSYGkcgdr0B1Dqm0jq72VC5i+KHh6l9HuVUkfS4=;
	b=AyRx5ZSxAYVnxkg4svGRzcuAdPCj9tbUZHuUotEq5Nvyq1WpfuU9jiDKhI62GVF7gfycSFUT
	AQKIVVBlM3FEj6VN+uIG57g/d1p4GWP9GIpIk/Ul15JG3q67MDAyPi0D4mf8QkXSQQh5+/oU/C
	5KQVgyUla9ixGFknSWRfSuhsg=;
Authentication-Results: sj-dkim-1; header.From=mbaugher@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: 0.13
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: Thomas Narten , saag@mit.edu
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 18 May 2007 20:17:56 -0000

good point

Mark

On May 18, 2007, at 12:05 PM, Steven M. Bellovin wrote:

> On Fri, 18 May 2007 10:27:29 -0700
> Mark Baugher  wrote:
>
>>
>> On May 17, 2007, at 9:23 AM, Thomas Narten wrote:
>>
>>>> I did not fully understand the question you have put forward. I
>>>> have worked on OSPF as well as IPsec, and am acknowledged in the
>>>> IPsec for OSPFv3 draft too.
>>>
>>> What I'm asking is what additional protections (if any) the use of
>>> AH provides over using ESP with NULL encryption when IPsec is used
>>> to protect OSPF.
>>
>> AH is inspectable by intermediate systems.  ESP NULL really isn't.
>>
>>
> What intermediate systems?  We're talking OSPF here, which isn't even
> forwarded through routers.
>
>
> 		--Steve Bellovin, http://www.cs.columbia.edu/~smb

From kent@bbn.com Fri May 18 16:30:57 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4IKUvCb014965
	for ; Fri, 18 May 2007 16:30:57 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4IKUtfe014937
	for ; Fri, 18 May 2007 16:30:56 -0400 (EDT)
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80])
	by mit.edu (Spam Firewall) with ESMTP id A32C74E0BF3
	for ; Fri, 18 May 2007 16:30:55 -0400 (EDT)
Received: from dhcp89-089-071.bbn.com ([128.89.89.71])
	by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from )
	id 1Hp96E-0002K5-5u; Fri, 18 May 2007 16:30:55 -0400
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	<77ead0ec0705170854i2b95c3a5y74be8fd58325c542@mail.gmail.com>
	<200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com>
	
	
	
Date: Fri, 18 May 2007 16:30:39 -0400
To: Mark Baugher 
From: Stephen Kent 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: Thomas Narten , saag@mit.edu,
	Paul Hoffman 
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 18 May 2007 20:30:58 -0000


I am a bit puzzled by this line of discussion.

The question, I thought, was whether there were security differences 
between use of AH vs. ESP-NULL for OSPF protection.  I would expect 
that OSPF traffic, unlike subscriber traffic, would not be traversing 
firewalls and thus the question of inspection would be less relevant 
here.

Steve

From sandy@tislabs.com Fri May 18 18:15:55 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4IMFsEP001364
	for ; Fri, 18 May 2007 18:15:54 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4IMFq6L013785
	for ; Fri, 18 May 2007 18:15:52 -0400 (EDT)
Received: from nutshell.tislabs.com (sentry.gw.tislabs.com [192.94.214.100])
	by mit.edu (Spam Firewall) with ESMTP id 354B32C62FF
	for ; Fri, 18 May 2007 18:15:52 -0400 (EDT)
Received: (from uucp@localhost)
	by nutshell.tislabs.com (8.12.9/8.12.9) id l4IMDFSG008136;
	Fri, 18 May 2007 18:13:15 -0400 (EDT)
Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap
	(V6.0) id srcAAAuPaiWp; Fri, 18 May 07 18:12:29 -0400
Received: by pecan.tislabs.com (Postfix, from userid 2005)
	id 88E043F473; Fri, 18 May 2007 18:11:04 -0400 (EDT)
To: mbaugher@cisco.com, smb@cs.columbia.edu
In-Reply-To: <587F7B8C-C259-4D9A-BE55-5ACC4CD3C40E@cisco.com>
Message-Id: <20070518221104.88E043F473@pecan.tislabs.com>
Date: Fri, 18 May 2007 18:11:04 -0400 (EDT)
From: sandy@tislabs.com (Sandy Murphy)
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: narten@us.ibm.com, saag@mit.edu
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 18 May 2007 22:15:55 -0000

> What intermediate systems?  We're talking OSPF here, which isn't even
> forwarded through routers.

Well, except for virtual links, which is a special case.  And even so
you wouldn't think that the packets would be going through firewalls.

Except that I just found a disturbing reference on cisco that "if there is
a firewall in between the virtual-link routers, you need to enable the
OSPF (P protocol 89) port"

--Sandy

From mcr@marajade.sandelman.ca Fri May 18 20:07:27 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4J07R0B020880
	for ; Fri, 18 May 2007 20:07:27 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4J07PlS021488
	for ; Fri, 18 May 2007 20:07:25 -0400 (EDT)
Received: from cod.sandelman.ca (cod.sandelman.ca [192.139.46.42])
	by mit.edu (Spam Firewall) with ESMTP id B951E595BAB
	for ; Fri, 18 May 2007 20:07:24 -0400 (EDT)
Received: from sandelman.ottawa.on.ca (wlan196.sandelman.ca [205.150.200.196])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "marajade.sandelman.ca.",
	Issuer "Michael Richardson" (verified OK))
	by cod.sandelman.ca (Postfix) with ESMTP id C1E741237F;
	Fri, 18 May 2007 20:07:23 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1])
	by sandelman.ottawa.on.ca (Postfix) with ESMTP id 5E9D54E79B;
	Fri, 18 May 2007 15:50:50 -0400 (EDT)
From: Michael Richardson 
To: Thomas Narten 
In-Reply-To: Message from Thomas Narten  of "Thu,
	17 May 2007 12:23:43 EDT."
	<200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com> 
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	<77ead0ec0705170854i2b95c3a5y74be8fd58325c542@mail.gmail.com>
	<200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com> 
X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 19)
Date: Fri, 18 May 2007 15:50:50 -0400
Message-ID: <22215.1179517850@marajade.sandelman.ca>
Sender: mcr@marajade.sandelman.ca
X-Spam-Score: 0.13
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sat, 19 May 2007 00:07:27 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Thomas" == Thomas Narten  writes:
    Thomas> What I'm asking is what additional protections (if any) the
    Thomas> use of AH provides over using ESP with NULL encryption when
    Thomas> IPsec is used to protect OSPF.

  My understanding of OSPF is:
     a) it's multicast on the link, which is the reason why manual
	keying is used.
		
     b) the source IP address for the message is relevant to the
	message.

  I don't see (b) being discussed in rfc4552's security considerations.
Since transport mode is being used, the IP header will not be protected.
  
  If replay protection is off, (which part of the thread discussed this
as a red-herring), then one can be concerned that a payload could be
replayed with a different IP header.
  what is the effect of replaying a link down message at a later time?

  However, I think that since you believe (and I would agree) that
64-bit replay counters can be used, then I think things are okay.

  As I understand OSPF (I turned it on once), it is used primarily
within a single AS, and as such, it seems that eventual evolution from
manual keying to some kind of kerberos/KINK method would work easily.
(I know diddly squat about MSEC)

  The only advantage of AH over ESP-NULL is that one can be sure that
the header following the AH is cleartext.

  If you want a router that hasn't been provisioned with keys to be able
to just "skip" an AH header that it doesn't understand process the OSPF
frame *ANYWAY* (this is about making networks resilient), then I
recommend you think hard about AH. 
  Otherwise, ESP-NULL.

- -- 
]            Bear: "Me, I'm just the shape of a bear."          |  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.6 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRk4DmICLcPvd0N1lAQJpWwgAqSE9kyxsqt4pxMHUL08I+mUfasPuOjjO
YECjcEiWzzMB5NRNO9vuVDIC0VXVOdBY5i2VEEeCRWi/pogs/p31LadHZqwfoNps
r4Bzw03Ah0BsaB/0zfKPi0i5q+VPiipyUckVHAJLFtTnrGfhxwTD+vMlOnRSEm/d
2Sh32JWfcjzSThT7bfi+iPdpPH+CVdOVNH3gQZ/m1kB0YLNni5nWb5Gxpt8wsvwJ
5mnfpxa4kK38agYycYx7xROQSwwxT4NqM2Yn3WOBeGeX/+qM6Vmg33mn6ORTiWmg
XT6EMLL4d60QYemd160HbXui8ZGwjCHaFiwH6mFy+jugeI4RBIXgAg==
=f1bi
-----END PGP SIGNATURE-----

From mcr@marajade.sandelman.ca Fri May 18 20:32:13 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4J0WDjx025214
	for ; Fri, 18 May 2007 20:32:13 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4J0WBIx002495
	for ; Fri, 18 May 2007 20:32:11 -0400 (EDT)
Received: from cod.sandelman.ca (cod.sandelman.ca [192.139.46.42])
	by mit.edu (Spam Firewall) with ESMTP id 0D394581FE0
	for ; Fri, 18 May 2007 20:32:07 -0400 (EDT)
Received: from sandelman.ottawa.on.ca (wlan196.sandelman.ca [205.150.200.196])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "marajade.sandelman.ca.",
	Issuer "Michael Richardson" (verified OK))
	by cod.sandelman.ca (Postfix) with ESMTP id 5788212376;
	Fri, 18 May 2007 20:32:07 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1])
	by sandelman.ottawa.on.ca (Postfix) with ESMTP id 30E664E788;
	Fri, 18 May 2007 20:32:02 -0400 (EDT)
From: Michael Richardson 
To: saag@mit.edu
In-Reply-To: Message from Mark Baugher  of "Fri,
	18 May 2007 10:27:29 PDT."
	 
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	<77ead0ec0705170854i2b95c3a5y74be8fd58325c542@mail.gmail.com>
	<200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com>
	 
X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 19)
Date: Fri, 18 May 2007 20:32:02 -0400
Message-ID: <30207.1179534722@marajade.sandelman.ca>
Sender: mcr@marajade.sandelman.ca
X-Spam-Score: 0.13
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: Thomas Narten , Mark Baugher 
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sat, 19 May 2007 00:32:13 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Mark" == Mark Baugher  writes:
    >>> I did not fully understand the question you have put forward. I
    >>> have worked on OSPF as well as IPsec, and am acknowledged in the
    >>> IPsec for OSPFv3 draft too.
    >> What I'm asking is what additional protections (if any) the use
    >> of AH provides over using ESP with NULL encryption when IPsec is
    >> used to protect OSPF.

    Mark> AH is inspectable by intermediate systems.  ESP NULL really
    Mark> isn't.

  As I understand the OSPF use case, it never travels through
intermediate L3 systems.  

  The only situation I can see where it might matter is that it may
travel through some L2 switches which are L3 aware, and wish to give
precedence to routing traffic.  I've seen a device that was aware of
OSPF, only IGMP (or "HTTP") aware.
  I think if prioritizing OSPF traffic within L2-fabrics is important
that we do have a number of other standard mechanisms.

- -- 
]            Bear: "Me, I'm just the shape of a bear."          |  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.6 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRk5FdoCLcPvd0N1lAQJD9wgApBjkw4SD0AmrlJmsZ9tlqJbGwqO9lNPv
LtY4pEMbkJMEEPGcyPOdCrPRF/BZpX6TOWQpKMRU6wPWjUxXNOEvDrP/V9hlrX5h
QyW22y3miGHyPA1lt56TK7kMpYcztzC5n8L+6P8ASoshAxgZmlS9G9Xehk8EIG3r
vfzE8IDvlfcEHwYVC19rDa4IB1IHCqaMjPmpnjKBCAgIOjf3RCCbMjOtXNTXh9aD
CrsrHQMcgLhW5u0R8bxy6Q2Guks/GwU2g1Cwsq8/bNncUtU2xkaFipamodkwVN3G
GpIQFeF15jd5E8Q9FVdBWQkcaQsUiawA2HYbJZA7jgx3icqubjYuWQ==
=j+pz
-----END PGP SIGNATURE-----

From mcr@marajade.sandelman.ca Fri May 18 20:34:36 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4J0YaKw025921
	for ; Fri, 18 May 2007 20:34:36 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4J0YXEM020485
	for ; Fri, 18 May 2007 20:34:33 -0400 (EDT)
Received: from cod.sandelman.ca (cod.sandelman.ca [192.139.46.42])
	by mit.edu (Spam Firewall) with ESMTP id 1C5144A5BAA
	for ; Fri, 18 May 2007 20:34:33 -0400 (EDT)
Received: from sandelman.ottawa.on.ca (wlan196.sandelman.ca [205.150.200.196])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "marajade.sandelman.ca.",
	Issuer "Michael Richardson" (verified OK))
	by cod.sandelman.ca (Postfix) with ESMTP id 9EA0D1237C;
	Fri, 18 May 2007 20:34:32 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1])
	by sandelman.ottawa.on.ca (Postfix) with ESMTP id 665894E788;
	Fri, 18 May 2007 20:34:31 -0400 (EDT)
From: Michael Richardson 
To: saag@mit.edu, Paul Hoffman 
In-Reply-To: Message from Paul Hoffman  of "Fri,
	18 May 2007 11:03:38 PDT."  
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	<77ead0ec0705170854i2b95c3a5y74be8fd58325c542@mail.gmail.com>
	<200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com>
	
	 
X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 19)
Date: Fri, 18 May 2007 20:34:31 -0400
Message-ID: <30289.1179534871@marajade.sandelman.ca>
Sender: mcr@marajade.sandelman.ca
X-Spam-Score: 0.13
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: Thomas Narten , Mark Baugher 
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sat, 19 May 2007 00:34:36 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Paul" == Paul Hoffman  writes:
    >>>> I did not fully understand the question you have put forward. I
    >>>> have worked on OSPF as well as IPsec, and am acknowledged in
    >>>> the IPsec for OSPFv3 draft too.

    >>> What I'm asking is what additional protections (if any) the use
    >>> of AH provides over using ESP with NULL encryption when IPsec is
    >>> used to protect OSPF.

    >> AH is inspectable by intermediate systems.  ESP NULL really
    >> isn't.

    Paul> Could you explain this in more detail? Why wouldn't an
    Paul> intermediary be able to read data in an ESP NULL packet?

  There is no indication on the wire that the ESP packet is in fact a
"NULL" encryption.  It might be a VoIP packet that just happen to look
like an OSPF once encrypted. 
  With AH, you *KNOW* that what follows is not encrypted.

- -- 
]            Bear: "Me, I'm just the shape of a bear."          |  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.6 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRk5GDoCLcPvd0N1lAQIHGAf/RDfaJ5kCo7J+/3ks0DCkCkLxk+7fjM8k
aAylJ45y1j0frzw+DC6yRcxM2KULMy0QqjvICROkRnQGVgieu7lzbX21PXs/vzdD
cjWplMByc5Hocu5/PnnzGkSRZelRpXtxEv+FzGEJQ7K66dDseCBufnVNkXVAh58y
hMPvDE6/WBU1kIAv3ScNBTft0b+Ve0SPUhqXAZlzJErqHg64qN2xv21QIdHH+olv
1izKXPoTOv67/CNvs/w7Xf8aoHXkpBRxgF0bMbjsbxN56mXUY1IScxtohJ5IXTlq
EM7fqM53AkzJM+R0W9XNj7WTK7klTvyqWSsnKefzl5N0fZZ5H+3Yhw==
=dfvC
-----END PGP SIGNATURE-----

From paul.hoffman@vpnc.org Fri May 18 20:55:49 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4J0tm5H030021
	for ; Fri, 18 May 2007 20:55:48 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4J0tjXL013678
	for ; Fri, 18 May 2007 20:55:46 -0400 (EDT)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 268174E9E6E
	for ; Fri, 18 May 2007 20:55:44 -0400 (EDT)
Received: from [10.20.30.104] (dsl-63-249-108-169.cruzio.com [63.249.108.169])
	(authenticated bits=0)
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4J0tffO021204
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 18 May 2007 17:55:42 -0700 (MST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <30289.1179534871@marajade.sandelman.ca>
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	<77ead0ec0705170854i2b95c3a5y74be8fd58325c542@mail.gmail.com>
	<200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com>
	 
	
	<30289.1179534871@marajade.sandelman.ca>
Date: Fri, 18 May 2007 17:55:35 -0700
To: Michael Richardson , saag@mit.edu
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: Thomas Narten , Mark Baugher 
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sat, 19 May 2007 00:55:49 -0000

At 8:34 PM -0400 5/18/07, Michael Richardson wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>>>>>>  "Paul" == Paul Hoffman  writes:
>     >>>> I did not fully understand the question you have put forward. I
>     >>>> have worked on OSPF as well as IPsec, and am acknowledged in
>     >>>> the IPsec for OSPFv3 draft too.
>
>     >>> What I'm asking is what additional protections (if any) the use
>     >>> of AH provides over using ESP with NULL encryption when IPsec is
>     >>> used to protect OSPF.
>
>     >> AH is inspectable by intermediate systems.  ESP NULL really
>     >> isn't.
>
>     Paul> Could you explain this in more detail? Why wouldn't an
>     Paul> intermediary be able to read data in an ESP NULL packet?
>
>   There is no indication on the wire that the ESP packet is in fact a
>"NULL" encryption.  It might be a VoIP packet that just happen to look
>like an OSPF once encrypted.
>   With AH, you *KNOW* that what follows is not encrypted.

Of course. But Mark said "isn't inspectable", which is quite 
different from "is inspectable but you might be looking at something 
you can't interpret some of the time".

This is moot, of course, for this thread, because we are talking 
about OSPF, as others have pointed out.

--Paul Hoffman, Director
--VPN Consortium

From mcr@marajade.sandelman.ca Fri May 18 21:09:09 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4J199bd032476
	for ; Fri, 18 May 2007 21:09:09 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4J197Wn010249
	for ; Fri, 18 May 2007 21:09:08 -0400 (EDT)
Received: from cod.sandelman.ca (cod.sandelman.ca [192.139.46.42])
	by mit.edu (Spam Firewall) with ESMTP id 37A414A9AED
	for ; Fri, 18 May 2007 21:09:07 -0400 (EDT)
Received: from sandelman.ottawa.on.ca (wlan196.sandelman.ca [205.150.200.196])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "marajade.sandelman.ca.",
	Issuer "Michael Richardson" (verified OK))
	by cod.sandelman.ca (Postfix) with ESMTP id A23761235E;
	Fri, 18 May 2007 21:09:06 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1])
	by sandelman.ottawa.on.ca (Postfix) with ESMTP id 4D97D4E788;
	Fri, 18 May 2007 21:09:05 -0400 (EDT)
From: Michael Richardson 
To: Paul Hoffman 
In-Reply-To: Message from Paul Hoffman  of "Fri,
	18 May 2007 17:55:35 PDT."  
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	<77ead0ec0705170854i2b95c3a5y74be8fd58325c542@mail.gmail.com>
	<200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com>
	
	
	<30289.1179534871@marajade.sandelman.ca>
	 
X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 19)
Date: Fri, 18 May 2007 21:09:05 -0400
Message-ID: <32152.1179536945@marajade.sandelman.ca>
Sender: mcr@marajade.sandelman.ca
X-Spam-Score: 0.13
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, Thomas Narten ,
	Mark Baugher 
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sat, 19 May 2007 01:09:10 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Paul" == Paul Hoffman  writes:
    Paul> Could you explain this in more detail? Why wouldn't an
    Paul> intermediary be able to read data in an ESP NULL packet?

    >> There is no indication on the wire that the ESP packet is in fact
    >> a "NULL" encryption.  It might be a VoIP packet that just happen
    >> to look like an OSPF once encrypted.  With AH, you *KNOW* that
    >> what follows is not encrypted.

    Paul> Of course. But Mark said "isn't inspectable", which is quite
    Paul> different from "is inspectable but you might be looking at
    Paul> something you can't interpret some of the time".
 
  Not some of time, Mark went into detail.
  People have suggested that they can just guess, other nonsense, and I
usually ask them if they are going to do that in the fast path, and they
say, "no", and I say "denial of service"

    Paul> This is moot, of course, for this thread, because we are
    Paul> talking about OSPF, as others have pointed out.

  Not quite.
  See my other comment: do you want a router that has not been
configured with any keys (distinguish that from one that has the wrong
keys, because it's hard to tell wrong keys from corrupt packets) to
listen to authenticated traffic?

  AH permits this trivially, although that behaviour (skipping AH
headers that you have no SPI for) is not specified in 2401 or 4301, and
that's the main reason that SEND couldn't use AH. 

  You may need it to do that in order for it to get things working well
enough for it to contact some provisioning server so that it can get the
right keys.

- -- 
]            Bear: "Me, I'm just the shape of a bear."          |  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.6 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRk5OMICLcPvd0N1lAQIeGQgAhVz8IygD3kN2UULgW9PwCtBo2PPGkbob
E0MTMS97ZJH+DKm7e+IZjShZ4vyebdBJjjFsAtL2VqZnoEN1FMV4oC5uVFoWD2zi
bRFct6QC2D13NnoXKlwK95136TuSWgy2/s04OZ8Kh9W+yLQOonxW/MxyWfZLBjjf
XW9HbwgB7qMV5WNc0Bfp51ruJLwjmTtRmVuajXuMtYyi4q25SbHfi/aQ3g9lElGj
KKpZB9xRkxSfn4pTh2t4ccnBAnIoSOL8w00z+Ztw1yRiXwSXL4xLgPqWsufrAuJM
Sj2PmDgVgQ2paZAqUbdqpPD5tU6qPeRK+UrDkkII3iV9SsTFHlORpg==
=SxYZ
-----END PGP SIGNATURE-----

From vishwas.ietf@gmail.com Sat May 19 04:03:29 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4J83Txf007050
	for ; Sat, 19 May 2007 04:03:29 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4J83RKA021988
	for ; Sat, 19 May 2007 04:03:27 -0400 (EDT)
Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.238])
	by mit.edu (Spam Firewall) with ESMTP id 6D4E94F91D8
	for ; Sat, 19 May 2007 04:03:26 -0400 (EDT)
Received: by nz-out-0506.google.com with SMTP id x3so840615nzd
	for ; Sat, 19 May 2007 01:03:26 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=IMV+BUlx9JyWuhsdZe2g6a3l2NwFRT3NXw4LO9ovoftmGJ6179S8UMI7cuKxCx7N6IEumvk3k+xeb6zuyngXN1yuVpJeymT0ByiDK2lIptDgzCm1kdj+dEdrTPQv2vTXzWUa6/Xsx+qBK32Y2lqME+Ja2ubZMECLYl4q/9YHyjA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=iD5p20FFfl8ef4l87dmlfcwZkgFzeyMSXUxTjDvIcuN72OrWFleCSupZehEXHUK4GvzSo+VGjju4KLfHZ5IDfR25a1RDrRA4NTyoUjWpqT3Ar4/jtAJlSd8XgXga1yXcYK7PAiol2Bxe6vEygEUO0a5mztg5tXhbxkn0/SRcr8A=
Received: by 10.114.175.16 with SMTP id x16mr1351426wae.1179561805569;
	Sat, 19 May 2007 01:03:25 -0700 (PDT)
Received: by 10.114.24.9 with HTTP; Sat, 19 May 2007 01:03:25 -0700 (PDT)
Message-ID: <77ead0ec0705190103i5835a84v45ff8cc0e4f3acf3@mail.gmail.com>
Date: Sat, 19 May 2007 13:33:25 +0530
From: "Vishwas Manral" 
To: "Michael Richardson" 
In-Reply-To: <32152.1179536945@marajade.sandelman.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	<77ead0ec0705170854i2b95c3a5y74be8fd58325c542@mail.gmail.com>
	<200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com>
	
	
	<30289.1179534871@marajade.sandelman.ca> 
	
	<32152.1179536945@marajade.sandelman.ca>
X-Spam-Score: 0.12
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, Thomas Narten ,
	Paul Hoffman , Mark Baugher 
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sat, 19 May 2007 08:03:30 -0000

Hi Mike,

Thomas, Steven, Merike and I had a discussion on this offline
yesterday. Let me put down some interesting point for your benefit.

For tunnel mode the difference between AH and ESP-NULL does not matter
as such from a security perspective. Except for the case of deep
packet inspection by middleboxes. Currently all OSPF packets coming
from outside the domain are filtered and dropped. This helps because
offpath attacks on the routing infrastructure can be prevented (it is
another discussion about what it means to have replayed packets from a
previous session). However with ESP-NULL such packets cannot be caught
by the firewall as firewalls cannot look inside ESP packets, while
they can inside AH packets.

>From a perspective of transport mode, the outer IPv6 header is
protected by AH but not by ESP-NULL. This would mean if the source
address is changed and an older packet is sent, then the routing can
be disrupted for sometime. There are a few catches in this situation
too. The source IPv6 address for packets is however a link-local
address. This would mean offpath attacks from outside the network
would not be possible, as IPv6 will not forward Link-local IP source
address packets. Source address is used in OSPF
"   o  On all link types (e.g., broadcast, NBMA, point-to- point, etc),
     neighbors are identified solely by their OSPF Router ID. For all
     link types except virtual links, the Neighbor IP address is set to
     the IPv6 source address in the IPv6 header of the received OSPF
     Hello packet."
This is used for as the Destination IP address when protocol packets
are sent as unicasts along this adjacency.

Only for particular case of virtual links is the source address of
Global scope. Do let me know if this analysis is enough or we need
more information about the same?

Thanks,
Vishwas

On 5/19/07, Michael Richardson  wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> >>>>> "Paul" == Paul Hoffman  writes:
>     Paul> Could you explain this in more detail? Why wouldn't an
>     Paul> intermediary be able to read data in an ESP NULL packet?
>
>     >> There is no indication on the wire that the ESP packet is in fact
>     >> a "NULL" encryption.  It might be a VoIP packet that just happen
>     >> to look like an OSPF once encrypted.  With AH, you *KNOW* that
>     >> what follows is not encrypted.
>
>     Paul> Of course. But Mark said "isn't inspectable", which is quite
>     Paul> different from "is inspectable but you might be looking at
>     Paul> something you can't interpret some of the time".
>
>   Not some of time, Mark went into detail.
>   People have suggested that they can just guess, other nonsense, and I
> usually ask them if they are going to do that in the fast path, and they
> say, "no", and I say "denial of service"
>
>     Paul> This is moot, of course, for this thread, because we are
>     Paul> talking about OSPF, as others have pointed out.
>
>   Not quite.
>   See my other comment: do you want a router that has not been
> configured with any keys (distinguish that from one that has the wrong
> keys, because it's hard to tell wrong keys from corrupt packets) to
> listen to authenticated traffic?
>
>   AH permits this trivially, although that behaviour (skipping AH
> headers that you have no SPI for) is not specified in 2401 or 4301, and
> that's the main reason that SEND couldn't use AH.
>
>   You may need it to do that in order for it to get things working well
> enough for it to contact some provisioning server so that it can get the
> right keys.
>
> - --
> ]            Bear: "Me, I'm just the shape of a bear."          |  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.6 (GNU/Linux)
> Comment: Finger me for keys
>
> iQEVAwUBRk5OMICLcPvd0N1lAQIeGQgAhVz8IygD3kN2UULgW9PwCtBo2PPGkbob
> E0MTMS97ZJH+DKm7e+IZjShZ4vyebdBJjjFsAtL2VqZnoEN1FMV4oC5uVFoWD2zi
> bRFct6QC2D13NnoXKlwK95136TuSWgy2/s04OZ8Kh9W+yLQOonxW/MxyWfZLBjjf
> XW9HbwgB7qMV5WNc0Bfp51ruJLwjmTtRmVuajXuMtYyi4q25SbHfi/aQ3g9lElGj
> KKpZB9xRkxSfn4pTh2t4ccnBAnIoSOL8w00z+Ztw1yRiXwSXL4xLgPqWsufrAuJM
> Sj2PmDgVgQ2paZAqUbdqpPD5tU6qPeRK+UrDkkII3iV9SsTFHlORpg==
> =SxYZ
> -----END PGP SIGNATURE-----
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://mailman.mit.edu/mailman/listinfo/saag
>

From gdt@ir.bbn.com Sat May 19 08:35:57 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4JCZulX009688
	for ; Sat, 19 May 2007 08:35:56 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4JCZsGw001230
	for ; Sat, 19 May 2007 08:35:55 -0400 (EDT)
Received: from fnord.ir.bbn.com (fnord.ir.bbn.com [192.1.100.210])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 5C0214791AB
	for ; Sat, 19 May 2007 08:35:54 -0400 (EDT)
Received: by fnord.ir.bbn.com (Postfix, from userid 10853)
	id AA51F5297; Sat, 19 May 2007 08:35:53 -0400 (EDT)
From: Greg Troxel 
To: Michael Richardson 
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	<77ead0ec0705170854i2b95c3a5y74be8fd58325c542@mail.gmail.com>
	<200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com>
	<22215.1179517850@marajade.sandelman.ca>
X-Hashcash: 1:20:070519:narten@us.ibm.com::PI2GRN6146sL3Mh2:000000000000000000000000000000000000000000002Y+E
X-Hashcash: 1:20:070519:mcr@sandelman.ottawa.on.ca::hNwGvo8rCLrwp8p3:000000000000000000000000000000000005ZYq
X-Hashcash: 1:20:070519:saag@mit.edu::5xLs2vn2GvEmi6BQ:0000088uK
Date: Sat, 19 May 2007 08:35:53 -0400
In-Reply-To: <22215.1179517850@marajade.sandelman.ca> (Michael Richardson's
	message of "Fri, 18 May 2007 15:50:50 -0400")
Message-ID: 
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/21.4 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: Thomas Narten , saag@mit.edu
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sat, 19 May 2007 12:35:57 -0000

Michael Richardson  writes:

>   My understanding of OSPF is:
>      a) it's multicast on the link, which is the reason why manual
> 	keying is used.

Unless manual keying is MUST NOT, I think we need to consider the manual
keying case.

>      b) the source IP address for the message is relevant to the
> 	message.
>
>   I don't see (b) being discussed in rfc4552's security considerations.
> Since transport mode is being used, the IP header will not be protected.
>   
>   If replay protection is off, (which part of the thread discussed this
> as a red-herring), then one can be concerned that a payload could be
> replayed with a different IP header.
>   what is the effect of replaying a link down message at a later time?

Is it really the case that a proper OSPF implementation pays no
attention to the source address of incoming packets?  If transport-mode
AH is used and security claims are made, then unauthenticated fields
really should be ignored.

  From: "Vishwas Manral" 

  From a perspective of transport mode, the outer IPv6 header is
  protected by AH but not by ESP-NULL. This would mean if the source
  address is changed and an older packet is sent, then the routing can
  be disrupted for sometime. There are a few catches in this situation
  too. The source IPv6 address for packets is however a link-local
  address. This would mean offpath attacks from outside the network
  would not be possible, as IPv6 will not forward Link-local IP source
  address packets. Source address is used in OSPF
  "   o  On all link types (e.g., broadcast, NBMA, point-to- point, etc),
       neighbors are identified solely by their OSPF Router ID. For all
       link types except virtual links, the Neighbor IP address is set to
       the IPv6 source address in the IPv6 header of the received OSPF
       Hello packet."
  This is used for as the Destination IP address when protocol packets
  are sent as unicasts along this adjacency.

  Only for particular case of virtual links is the source address of
  Global scope. Do let me know if this analysis is enough or we need
  more information about the same?

I believe that you are arguing that the only substitutions possible are
for messages with other on-link link-local addresses, and virtual links
of Global scope.  That does not sound to me like "no cause for concern".
Your analysis seems enough to conclude that using transport-mode ESP
does not provide adequate security -- but I suspect that this isn't what
you meant.


From mcr@marajade.sandelman.ca Sat May 19 10:25:20 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4JEPKur006225
	for ; Sat, 19 May 2007 10:25:20 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4JEPHnj018412
	for ; Sat, 19 May 2007 10:25:17 -0400 (EDT)
Received: from cod.sandelman.ca (cod.sandelman.ca [192.139.46.42])
	by mit.edu (Spam Firewall) with ESMTP id 7553B4C6263
	for ; Sat, 19 May 2007 10:25:16 -0400 (EDT)
Received: from sandelman.ottawa.on.ca (wlan196.sandelman.ca [205.150.200.196])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "marajade.sandelman.ca.",
	Issuer "Michael Richardson" (verified OK))
	by cod.sandelman.ca (Postfix) with ESMTP id 803C01237B;
	Sat, 19 May 2007 10:25:15 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1])
	by sandelman.ottawa.on.ca (Postfix) with ESMTP id 288844E788;
	Sat, 19 May 2007 10:25:09 -0400 (EDT)
From: Michael Richardson 
To: Greg Troxel 
In-Reply-To: Message from Greg Troxel  
	of "Sat, 19 May 2007 08:35:53 EDT."  
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	<77ead0ec0705170854i2b95c3a5y74be8fd58325c542@mail.gmail.com>
	<200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com>
	<22215.1179517850@marajade.sandelman.ca>
	 
X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 19)
Date: Sat, 19 May 2007 10:25:08 -0400
Message-ID: <28624.1179584708@marajade.sandelman.ca>
Sender: mcr@marajade.sandelman.ca
X-Spam-Score: 0.13
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: Thomas Narten , saag@mit.edu
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sat, 19 May 2007 14:25:20 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Greg" == Greg Troxel  writes:
    Greg> catches in this situation too. The source IPv6 address for
    Greg> packets is however a link-local address. This would mean
    Greg> offpath attacks from outside the network would not be
    Greg> possible, as IPv6 will not forward Link-local IP source
    Greg> address packets. Source address is used in OSPF " o On all

  Right. What else on on-link?
  If it's all trusted routers with keys, then frankly... do you really
even need AH or ESP?

  If there are other nodes on that link, then they are also *ONLINK*
and can send on-link packets, and may well have an interest in diverting
traffic towards them.

    Greg>   Only for particular case of virtual links is the source
    Greg> address of Global scope. Do let me know if this analysis is
    Greg> enough or we need more information about the same?

  I don't know how OSPF is used with "virtual links"
  Can you give me a detailed use-case?

    Greg> I believe that you are arguing that the only substitutions
    Greg> possible are for messages with other on-link link-local
    Greg> addresses, and virtual links of Global scope.  That does not
    Greg> sound to me like "no cause for concern".  Your analysis seems
    Greg> enough to conclude that using transport-mode ESP does not
    Greg> provide adequate security -- but I suspect that this isn't
    Greg> what you meant.

  I don't know if substituted source addresses are a risk for OSPF.

  I would think that they are, in which case ESP-NULL should never have
even been considered.  

- -- 
]            Bear: "Me, I'm just the shape of a bear."          |  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.6 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRk8Iw4CLcPvd0N1lAQJerAgArYOEjiPGQmdFrrZUhzf8gCkyaunp1lbf
7kA6Lp6Fb2oChKl0P7cFvKtgM1PcI86nsbFp55ij/6n5Iav5+UeXzDCcTsFC6VpW
xlTXjmVtQoi3E6oOVL6wkxgSF0W7rMaDQX/3OhBSSZqaETVw2v359011RoTqfg2V
YhqECBysFG6C7mRclVjez2qvhWi/goeFGYgCRp2Az1PcK9eojdwXXBCyDo7Rq5Tc
cixx8wS0+HvGalIfJFFS60aXa8RG8iHyGopnLXHbh5GaY+b300VHTArsUdo/7G3k
khKaNG+P118dQ3NgR+VLg7l20h/HJ78kSgE+Siddu9r1ChhVOsAD/g==
=eolQ
-----END PGP SIGNATURE-----

From vishwas.ietf@gmail.com Sat May 19 10:37:05 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4JEb3D2008579
	for ; Sat, 19 May 2007 10:37:05 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4JEb1U7000630
	for ; Sat, 19 May 2007 10:37:01 -0400 (EDT)
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.238])
	by mit.edu (Spam Firewall) with ESMTP id 4CDB72BE7D5
	for ; Sat, 19 May 2007 10:37:00 -0400 (EDT)
Received: by wx-out-0506.google.com with SMTP id t8so1158190wxc
	for ; Sat, 19 May 2007 07:37:00 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=uSvLUfkTxZ9F8btU/PiuRb3PvLJDZVUsjBRtbfh3uL6gH7NMIfKjL8/fmLa83bk+33QG6chbPHYMjAC+Ndjz12mxbQMgnS+Ps8CCpA2iQFDMTCNzYSO/JccsKK83G3wMl89IgF62Xuelp2VxzxHvcKTbJEw/5Wp300etqeGvJGc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=lF/iwQnQnvhOgIPDo/vIoIcpYW29PGwVzrE1sUORunOI8HcC2BK7VYJ0f0073Z84OVKQk/jaWF4fhuvvCX80sVod2J6Q+WB8PeKwDyCA+tGeH1TUI26vkqYatv8KgOxGfBV79p5VJ3nRenc6rsnKjF25edTD08VaHZWRI1h+4n8=
Received: by 10.114.145.1 with SMTP id s1mr1459902wad.1179585419617;
	Sat, 19 May 2007 07:36:59 -0700 (PDT)
Received: by 10.114.24.9 with HTTP; Sat, 19 May 2007 07:36:59 -0700 (PDT)
Message-ID: <77ead0ec0705190736m6b5dfedcrf269cd35233aca5b@mail.gmail.com>
Date: Sat, 19 May 2007 20:06:59 +0530
From: "Vishwas Manral" 
To: "Michael Richardson" 
In-Reply-To: <28624.1179584708@marajade.sandelman.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	<77ead0ec0705170854i2b95c3a5y74be8fd58325c542@mail.gmail.com>
	<200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com>
	<22215.1179517850@marajade.sandelman.ca> 
	
	<28624.1179584708@marajade.sandelman.ca>
X-Spam-Score: 0.12
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: Thomas Narten , saag@mit.edu,
	Greg Troxel 
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sat, 19 May 2007 14:37:05 -0000

Hi Mike,

Let me fill you up witl details you need.

>   I don't know how OSPF is used with "virtual links"
>   Can you give me a detailed use-case?
An OSPF domain is divided into areas. Within the area we use
Link-state algorithm to calculate routes. For a loop free topology,
generally a hub and spoke configuration is used to connect the various
areas. Area 0 is a special area, which is like the backbone, or the
hub. However in certain cases the spoke area A1 is not connected
directly to the hub but to another spoke A2 (which may be connected to
the hub area). For this area A1 we actually construct a virtual link
running over area A2. So not all OSPF routers run Virtual links (only
special ones called ABR's).

On another note, for seeing the effects of replay attacks on routing
protocols you can read the draft
http://tools.ietf.org/html/draft-manral-rpsec-existing-crypto-04.
However as I said there are a lot of conditions that need to be
satisfied, before which a router accepts a packet as valid. For
example an LSUpdate packet received at random, which has no
corresponding router ID is simply rejected. That is an additional
security mechanism.

Thanks,
Vishwas

On 5/19/07, Michael Richardson  wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> >>>>> "Greg" == Greg Troxel  writes:
>     Greg> catches in this situation too. The source IPv6 address for
>     Greg> packets is however a link-local address. This would mean
>     Greg> offpath attacks from outside the network would not be
>     Greg> possible, as IPv6 will not forward Link-local IP source
>     Greg> address packets. Source address is used in OSPF " o On all
>
>   Right. What else on on-link?
>   If it's all trusted routers with keys, then frankly... do you really
> even need AH or ESP?
>
>   If there are other nodes on that link, then they are also *ONLINK*
> and can send on-link packets, and may well have an interest in diverting
> traffic towards them.
>
>     Greg>   Only for particular case of virtual links is the source
>     Greg> address of Global scope. Do let me know if this analysis is
>     Greg> enough or we need more information about the same?
>
>   I don't know how OSPF is used with "virtual links"
>   Can you give me a detailed use-case?
>
>     Greg> I believe that you are arguing that the only substitutions
>     Greg> possible are for messages with other on-link link-local
>     Greg> addresses, and virtual links of Global scope.  That does not
>     Greg> sound to me like "no cause for concern".  Your analysis seems
>     Greg> enough to conclude that using transport-mode ESP does not
>     Greg> provide adequate security -- but I suspect that this isn't
>     Greg> what you meant.
>
>   I don't know if substituted source addresses are a risk for OSPF.
>
>   I would think that they are, in which case ESP-NULL should never have
> even been considered.
>
> - --
> ]            Bear: "Me, I'm just the shape of a bear."          |  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.6 (GNU/Linux)
> Comment: Finger me for keys
>
> iQEVAwUBRk8Iw4CLcPvd0N1lAQJerAgArYOEjiPGQmdFrrZUhzf8gCkyaunp1lbf
> 7kA6Lp6Fb2oChKl0P7cFvKtgM1PcI86nsbFp55ij/6n5Iav5+UeXzDCcTsFC6VpW
> xlTXjmVtQoi3E6oOVL6wkxgSF0W7rMaDQX/3OhBSSZqaETVw2v359011RoTqfg2V
> YhqECBysFG6C7mRclVjez2qvhWi/goeFGYgCRp2Az1PcK9eojdwXXBCyDo7Rq5Tc
> cixx8wS0+HvGalIfJFFS60aXa8RG8iHyGopnLXHbh5GaY+b300VHTArsUdo/7G3k
> khKaNG+P118dQ3NgR+VLg7l20h/HJ78kSgE+Siddu9r1ChhVOsAD/g==
> =eolQ
> -----END PGP SIGNATURE-----
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://mailman.mit.edu/mailman/listinfo/saag
>

From mcr@marajade.sandelman.ca Sat May 19 22:54:26 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4K2sQvS031727
	for ; Sat, 19 May 2007 22:54:26 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4K2sNMB012063
	for ; Sat, 19 May 2007 22:54:24 -0400 (EDT)
Received: from cod.sandelman.ca (cod.sandelman.ca [192.139.46.42])
	by mit.edu (Spam Firewall) with ESMTP id F1BB54C0BC1
	for ; Sat, 19 May 2007 22:54:13 -0400 (EDT)
Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca
	[205.150.200.247])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "marajade.sandelman.ca.",
	Issuer "Michael Richardson" (verified OK))
	by cod.sandelman.ca (Postfix) with ESMTP id 754C412380;
	Sat, 19 May 2007 22:53:56 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1])
	by sandelman.ottawa.on.ca (Postfix) with ESMTP id C2A844E798;
	Sat, 19 May 2007 20:38:36 -0400 (EDT)
From: Michael Richardson 
To: "Vishwas Manral" 
In-Reply-To: Message from "Vishwas Manral"  of "Sat,
	19 May 2007 13:33:25 +0530."
	<77ead0ec0705190103i5835a84v45ff8cc0e4f3acf3@mail.gmail.com> 
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	<77ead0ec0705170854i2b95c3a5y74be8fd58325c542@mail.gmail.com>
	<200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com>
	
	
	<30289.1179534871@marajade.sandelman.ca>
	 
	<32152.1179536945@marajade.sandelman.ca>
	<77ead0ec0705190103i5835a84v45ff8cc0e4f3acf3@mail.gmail.com> 
X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 19)
Date: Sat, 19 May 2007 20:38:36 -0400
Message-ID: <4462.1179621516@marajade.sandelman.ca>
Sender: mcr@marajade.sandelman.ca
X-Spam-Score: 0.13
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, Thomas Narten ,
	Paul Hoffman , Mark Baugher 
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sun, 20 May 2007 02:54:26 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Vishwas" == Vishwas Manral  writes:
    Vishwas> too. The source IPv6 address for packets is however a link-local
    Vishwas> address. This would mean offpath attacks from outside the network
    Vishwas> would not be possible, as IPv6 will not forward Link-local
    Vishwas> IP source 
    Vishwas> address packets. Source address is used in OSPF
    Vishwas> "   o  On all link types (e.g., broadcast, NBMA, point-to-
    Vishwas> point, etc), 
    Vishwas> neighbors are identified solely by their OSPF Router ID. For all
    Vishwas> link types except virtual links, the Neighbor IP address is set to
    Vishwas> the IPv6 source address in the IPv6 header of the received OSPF
    Vishwas> Hello packet."

  I don't seem be able to parse this.
   
  Is the OSPF Router ID set from the Neighbour IP (therefore from the
IPv6 source address)?   You agree that a replay is possible using old 
packets with different addresses.

  This could be solved, I think, by repeating the neighbour IP inside
the OSPF message. (I understand that this means a change to the spec)

    Vishwas> Only for particular case of virtual links is the source address of
    Vishwas> Global scope. Do let me know if this analysis is enough or we need
    Vishwas> more information about the same?

  It seems to me that virtual links could use tunnel mode.
  It also seems to me that you could use ESP-NULL with tunnel mode.

- -- 
]            Bear: "Me, I'm just the shape of a bear."          |  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.6 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRk+YiYCLcPvd0N1lAQJ6hwgAnG1LpUPxcnFncdskg103Y+S9LA0VB+WO
x1oeFc0OnGmcgqgwUYXFbeazpbPsMLI8UY8fuz+0RTUazRE4JkKOz54br/DOw9dK
wsFC/fqghZBWFJZlOGmDbw8DhH2P6kr9fAaWDR+jNu11T0ySr9H12YXzuC24rEor
vxbC98ixdTm1lbrVryCYzN9lLo8XVi4TqWBn/BFlNTyGrhgNjXqa406/6mHRfmXq
LheVLQgsFngaLB34XS4wnls+Fh4xCBIBLD/Ms/CmPnKEoLevff7mmejOiYaKg7qO
KJNyrkyXL3nckmWsf3KV8k+YT+R1a0RcxKjX/hRXmNJC+x7/XPFFcg==
=KE2v
-----END PGP SIGNATURE-----

From vishwas.ietf@gmail.com Sat May 19 23:20:27 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4K3KQMF003795
	for ; Sat, 19 May 2007 23:20:26 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4K3KPsd003991
	for ; Sat, 19 May 2007 23:20:25 -0400 (EDT)
Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.226])
	by mit.edu (Spam Firewall) with ESMTP id 51DBF4B377B
	for ; Sat, 19 May 2007 23:20:24 -0400 (EDT)
Received: by nz-out-0506.google.com with SMTP id x3so919227nzd
	for ; Sat, 19 May 2007 20:20:24 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=dR/PTIZOD3akWjSCSmLx3EPQO8BW3h4mng8HJYrfXixihEf43lP/utHFRRf7AfMCyWmHD53RYUQgfeXOEWt+RluEI0lwhstoQfL0usTLbyQ2NjwJS1KVl5xHlvlMdWM8Q76c6/uZIWWtu0lt6m9CxRLjlDGX1385XDOKJvewx+k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=pdS72nogJ1zMAcmtdzBLNOMCVGh4/YzHaftLzMHushg7l1nDBm5X67jRFf51JY8l2Vul2hHH9HakdKVhO6jVEDS1CayqgNwZqFai9XBDYn6ciPPPRJTH8H8HvDG0OtvZyuBkuvZTzXb6x8Esb+hWB8FdcmFnlni3bOMH9ggB8mU=
Received: by 10.114.177.1 with SMTP id z1mr1826875wae.1179631223750;
	Sat, 19 May 2007 20:20:23 -0700 (PDT)
Received: by 10.114.24.9 with HTTP; Sat, 19 May 2007 20:20:23 -0700 (PDT)
Message-ID: <77ead0ec0705192020u67ccf6a6m4a705a22835ffa49@mail.gmail.com>
Date: Sun, 20 May 2007 08:50:23 +0530
From: "Vishwas Manral" 
To: "Michael Richardson" 
In-Reply-To: <4462.1179621516@marajade.sandelman.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	
	
	<30289.1179534871@marajade.sandelman.ca> 
	
	<32152.1179536945@marajade.sandelman.ca> 
	<77ead0ec0705190103i5835a84v45ff8cc0e4f3acf3@mail.gmail.com>
	<4462.1179621516@marajade.sandelman.ca>
X-Spam-Score: 0.12
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, Thomas Narten ,
	Paul Hoffman , Mark Baugher 
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sun, 20 May 2007 03:20:27 -0000

Hi Mike,

> >>>>> "Vishwas" == Vishwas Manral  writes:
>     Vishwas> too. The source IPv6 address for packets is however a link-local
>     Vishwas> address. This would mean offpath attacks from outside the network
>     Vishwas> would not be possible, as IPv6 will not forward Link-local
>     Vishwas> IP source
>     Vishwas> address packets. Source address is used in OSPF
>     Vishwas> "   o  On all link types (e.g., broadcast, NBMA, point-to-
>     Vishwas> point, etc),
>     Vishwas> neighbors are identified solely by their OSPF Router ID. For all
>     Vishwas> link types except virtual links, the Neighbor IP address is set to
>     Vishwas> the IPv6 source address in the IPv6 header of the received OSPF
>     Vishwas> Hello packet."
>
>   I don't seem be able to parse this.
>
>   Is the OSPF Router ID set from the Neighbour IP (therefore from the
> IPv6 source address)?   You agree that a replay is possible using old
> packets with different addresses.
>
>   This could be solved, I think, by repeating the neighbour IP inside
> the OSPF message. (I understand that this means a change to the spec)
A packets originator is identified by its Router ID (which is a unique
identifier of the router - generally a loopback interface(lo0)
address) and not by the source IP address. If we have to replay a
packet for a particular session, the Router ID should be valid. Let me
explain it further.

Different kinds of packets in OSPF come in particular order, depending
on the state of the FSM. If a random packet comes in out of order,
there is every probability it is discarded. However for example if an
adjacency is already established, and DB Description packet comes in
which is identified to belong to this adjacency (based on the router
ID), it could cause a restart of the adjacency process. Not all cases
would however cause an adjacency to drop.

>     Vishwas> Only for particular case of virtual links is the source address of
>     Vishwas> Global scope. Do let me know if this analysis is enough or we need
>     Vishwas> more information about the same?
>
>   It seems to me that virtual links could use tunnel mode.
>   It also seems to me that you could use ESP-NULL with tunnel mode.
Agree. The only fault with ESP-NULL with tunnel mode is that we cannot
firewall/ filter such packets (unlike with AH) if originating from
outside the domain. I had raised the same in December 2005,
http://www1.ietf.org/mail-archive/web/ipsec/current/msg01902.html
though not in this context.

Besides Virtual links are run on very few routers (ABR's) and most
times are not recommended, so we have that case too.

Thanks,
Vishwas

From vishwas.ietf@gmail.com Sat May 19 23:28:40 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4K3SdTG004935
	for ; Sat, 19 May 2007 23:28:39 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4K3Sbdr010923
	for ; Sat, 19 May 2007 23:28:37 -0400 (EDT)
Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.227])
	by mit.edu (Spam Firewall) with ESMTP id 8DD912B6AC5
	for ; Sat, 19 May 2007 23:28:36 -0400 (EDT)
Received: by nz-out-0506.google.com with SMTP id x3so919557nzd
	for ; Sat, 19 May 2007 20:28:36 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=qMlwA5CgHfDRetekP69k0qqWi4ubinbNvuLRdChYQKzQcOrKiz+O/BRecE7SPJZCaBeYWdJp/UnJFJF4P2a3lW/xApzc/qpZgI8IpiMw1i6tHJdN5oFcSdEOkcioOTVIARwudBcM7cjckro1+zsautrD9HZeBPjUeFm6pTMibs8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=J0pP4J0nMsTrefqphtd1gTeoC4vt507MWiv3ikEL6tH94Z3LwuSHwhtO9MivDlzlFUR13BaYr5F4eGe+xsh+h09P+L7ywX7HcLDRS/ADROmxsxMFp3/PF/B4lhUDYs1Y3W5ub1zWbWlSJtd0gyHPFTSCJr4VRieM8fGlLLS2Npg=
Received: by 10.115.109.1 with SMTP id l1mr1774375wam.1179631715730;
	Sat, 19 May 2007 20:28:35 -0700 (PDT)
Received: by 10.114.24.9 with HTTP; Sat, 19 May 2007 20:28:35 -0700 (PDT)
Message-ID: <77ead0ec0705192028u4157db31s4cc649c77c0c2228@mail.gmail.com>
Date: Sun, 20 May 2007 08:58:35 +0530
From: "Vishwas Manral" 
To: "Thomas Narten" 
In-Reply-To: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
X-Spam-Score: 0.12
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sun, 20 May 2007 03:28:40 -0000

Hi Thomas,

I have another set of concerns with respect to the protection
mechanism in general.

As the same Key is shared between multiple routers on the same
network, each router can fake the packet of another router in all OSPF
case. This however for IS-IS becomes a bigger issue as the same Key
isshared between the whole routing domain.

This is again listed in the draft I have written regarding security
issues with routing protocols.

Thanks,
Vishwas

On 5/17/07, Thomas Narten  wrote:
> As many of you know the USG is developing profiles for IPv6 and
> IPsec. For the DISA/JITC profiles, they have been discussing the need
> for AH with OSPF, and the current profiles require OSPF support AH.
>
> RFC 4301 is pretty clear about AH:
>
> > 3.2.  How IPsec Works
> >
> >    IPsec uses two protocols to provide traffic security services --
> >    Authentication Header (AH) and Encapsulating Security Payload (ESP).
> >    Both protocols are described in detail in their respective RFCs
> >    [Ken05b, Ken05a].  IPsec implementations MUST support ESP and MAY
> >    support AH. (Support for AH has been downgraded to MAY because
> >    experience has shown that there are very few contexts in which ESP
> >    cannot provide the requisite security services.  Note that ESP can be
> >    used to provide only integrity, without confidentiality, making it
> >    comparable to AH in most contexts.)
>
> Also, OSPFv3 (RFC 4552) mandates ESP, but leaves AH optional:
>
> >    In order to provide authentication to OSPFv3, implementations MUST
> >    support ESP and MAY support AH.
>
> In the current DISA/JITC Profiles, there is a statement that OSPFv3
> routers MUST use AH for router-to-router integrity checking.  My
> understanding is that the rational for this requirement is as follows:
>
> > > > > AH is a requirement for OSPFv3 routers because, in the case of a
> > > > > flooding protocol like OSPF, replayed updates from a different IPv6
> > > > > address will cause problems and ESP-NULL will not help this.  That is
> > > > > the simple answer.  As a result, please leave AH in for OSPF routers.
> > > >
> > > > You are right, according to RFC 4552, that ESP-NULL will not help this.
> > > > But you are wrong that AH will help this. Anyone who has access to the
> > > > keys and can use the SA can forge a packet using AH or ESP. As I said
> > > > before, AH is perfectly capable of authenticating a forged source address.
> > > > It does not care.
> > > >
> > > > The RFC 4552 work got backed into a corner on this one. Because IKEv2
> > > > didn't handle their situation, they specified manual keying. But the IPsec
> > > > people got nervous about using replay detection with manual keying,
> > > > because there was no good choice when the counter wrapped around. But then
> > > > the IPsec people invented 64-bit counters and the 4552 work said change
> > > > keys every three months. So this is a false problem. Seems that one would
> > > > avoid wrap-around even if sending many billions of messages a second for a
> > > > thousand years. So short of fixing the problem in the standards, just use
> > > > 64 bit counters and turn on replay detect with ESP (MUST) or with AH
> > > > (MAY). The affect is the same. The extra overhead of supporting AH (code
> > > > size and processing time) is as superfluous as ever.
> > > >
> > > > Note, again, that the RFC 4552 authors are right: AH (MAY) does nothing to
> > > > help solve this problem that ESP (MUST) doesn't do. Please stop making
> > > > claims for AH capabilitities that are misleading.
> >
> > > IMHO, if some one has access to your keys and is using them maliciously,
> > > you have much larger security issues than a forged OSPF LSA.  No one
> > > ever claimed that AH, or IPsec in general, in any way mitigates against
> > > insider threats.  That is what background investigations,
> > > non-repudiation and auditing are for.
> > >
> > > As to the use of PKI (in specific IKE), as I said above, non-repudiation
> > > takes care of this issue; however, PKI for authenticating routing
> > > updates, or even router access, is not and cannot always be deployed.
> > > As a result, the paradigm reverts to shared private keys.  Further,
> > > conservation of laziness, along with the exigencies of configuration
> > > management complexity, tends to push folks towards a single set of keys
> > > mapped to the source address or even a single key.  As a result, if an
> > > LSA is captured, it can be retransmitted with a different destination
> > > address.  This would probably cause problems.
> > >
> > > As a result, I am not making misleading claims about AH.  It appears
> > > that you did not understand what I was claiming.  As a result, let me
> > > recap:
> > >
> > > 1. AH mitigates replay attacks in the absence of source/destination
> > > unique shared private keys or PKI.
> > > 2. AH, and IPsec in general, do not mitigate against insider threats,
> > > configuration mistakes or general tomfoolery.
> > >
> > > Agreed?
> >
> > I think I now understand better what you mean by replay. I had thought,
> > incorrectly, that you meant playing an old stale message back to to the
> > same recipient. Instead, you mean playing a message intended for recipient
> > A to recipient B. Right?
> >
> > In most "ordinary uses" of IPsec, this can't work, of course, so this is
> > different. I have to think about it more before having an opinion.
>
> I'd welcome additional feedback on this issue. Does the use of AH with
> OSPF provide significant additional checks compared with ESP and NULL
> encryption?
>
> Thomas
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://mailman.mit.edu/mailman/listinfo/saag
>

From kivinen@iki.fi Mon May 21 09:23:18 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4LDNIPH024699
	for ; Mon, 21 May 2007 09:23:18 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4LDNF5s012834
	for ; Mon, 21 May 2007 09:23:15 -0400 (EDT)
Received: from mail.kivinen.iki.fi (unknown [83.145.195.1])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id DCBD15A84EE
	for ; Mon, 21 May 2007 09:23:13 -0400 (EDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1])
	by mail.kivinen.iki.fi (8.13.8/8.12.10) with ESMTP id l4LDMYE8026784
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 21 May 2007 16:22:34 +0300 (EEST)
Received: (from kivinen@localhost)
	by fireball.kivinen.iki.fi (8.13.8/8.12.11) id l4LDMTpH004525;
	Mon, 21 May 2007 16:22:29 +0300 (EEST)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to
	kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <18001.40213.565689.367357@fireball.kivinen.iki.fi>
Date: Mon, 21 May 2007 16:22:29 +0300
From: Tero Kivinen 
To: "Vishwas Manral" 
In-Reply-To: <77ead0ec0705190103i5835a84v45ff8cc0e4f3acf3@mail.gmail.com>
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	<77ead0ec0705170854i2b95c3a5y74be8fd58325c542@mail.gmail.com>
	<200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com>
	
	
	<30289.1179534871@marajade.sandelman.ca> 
	
	<32152.1179536945@marajade.sandelman.ca>
	<77ead0ec0705190103i5835a84v45ff8cc0e4f3acf3@mail.gmail.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 37 min
X-Total-Time: 37 min
X-Spam-Score: 0.01
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, Thomas Narten ,
	Michael Richardson ,
	Paul Hoffman , Mark Baugher 
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Mon, 21 May 2007 13:23:18 -0000

Vishwas Manral writes:
> For tunnel mode the difference between AH and ESP-NULL does not matter
> as such from a security perspective. Except for the case of deep
> packet inspection by middleboxes. Currently all OSPF packets coming
> from outside the domain are filtered and dropped. This helps because
> offpath attacks on the routing infrastructure can be prevented (it is
> another discussion about what it means to have replayed packets from a
> previous session). However with ESP-NULL such packets cannot be caught
> by the firewall as firewalls cannot look inside ESP packets, while
> they can inside AH packets.

If only ESP packets going to that destination are mandated of being
ESP-NULL you can look into them. Also if you make sure the destination
routers policy is set so that only ESP-NULL is acceptable for the OSFP
traffic, then you can even allow other ESP traffic, and still inspect
the ESP-NULL packets and discard all OSPF packets. 

One of the question is there, who are you trying to protect and
against what attack?

Does the attacker actually have valid IPsec SA to the end router?

If so, how was he able to create it? Did he have the keys or what?

If the attacker does not have valid IPsec SA why is it not enough for
the end node to drop the packet when it fails the IPsec processing?

If we assume that attacker has the keying material for the IPsec SA
(and the firewall does not ;-) and the firewall tries to protect the
end router from attackers packets.

The firewall can still do that. The end router simply needs to be
configured to use IPsec in so way that it only allows ESP-NULL for the
OSPF traffic, i.e. OSPF packets cannot ever be sent over any other
ESP-non-null SA. The firewall will know which algorithms are allowed
and used inside the zone it is trying to protect, thus it can know how
many bytes it needs to skip to skip the IV and sequence number. After
that there is IP header, so the firewall can simply check that if that
IP header is valid and if the other upper layer headers coming after
that are valid and if they match forbidden traffic (OSPF in this
case), it will drop the packet.

Only difference here to the AH is that it needs to skip some bytes
based on the algorithm it knows and that there is very small
probability that valid ESP-non-NULL traffic destioned to the end
router was dropped as it happened to encrypt to data that was
valid OSFP packet. Probability for that is very small, and upper level
retransmissions will take care of that (i.e. when packet was dropped
here, the upper level will retransmit it, in which case it is
reencrypted, and the new packet will look different, thus not going to
be dropped by the filters).

And all this just you do not need to configure the inner routers
properly to do access control based on where they get their packets.
-- 
kivinen@safenet-inc.com

From vishwas.ietf@gmail.com Tue May 22 00:34:22 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4M4YLwS002719
	for ; Tue, 22 May 2007 00:34:21 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4M4YJHU006449
	for ; Tue, 22 May 2007 00:34:19 -0400 (EDT)
Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.234])
	by mit.edu (Spam Firewall) with ESMTP id 0380F2CDB61
	for ; Tue, 22 May 2007 00:34:18 -0400 (EDT)
Received: by wr-out-0506.google.com with SMTP id i22so1457633wra
	for ; Mon, 21 May 2007 21:34:18 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=RloGd0f8+k4xPpi/eH7Hq7ivd0VEsdd8/758/m5kCiWhquPoE21J7QLhG3sw1/X6WAscSxuFVK8+54wd7jRkthTVOHhjb3VSqKOrWzzKq5eDY4M3X4BL0EK3D3CifBhlitcduMGOPZU0MO6JGbGcbx+g0487sR/XBJURo2Hv0hw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=SHh38dTqiWZ1FZHEVwmbH5gq5RC4Q/SxRFZJD4zEIJ2siQ4fp0iOUEDB0RCeLO0YDj9cOLfEp6liypE8oFn6lBaqNqQrSWFewItyLofdagHJJ6srUkQ1WOCS+haMFihJxm/+eh0iSt3oEwZYTxH2fbGjx02lu7nmkrIG/1Vc9+I=
Received: by 10.115.95.1 with SMTP id x1mr3089614wal.1179808458213;
	Mon, 21 May 2007 21:34:18 -0700 (PDT)
Received: by 10.114.24.9 with HTTP; Mon, 21 May 2007 21:34:18 -0700 (PDT)
Message-ID: <77ead0ec0705212134o63ad03a3r2edd0059ed2a11ff@mail.gmail.com>
Date: Tue, 22 May 2007 10:04:18 +0530
From: "Vishwas Manral" 
To: "Tero Kivinen" 
In-Reply-To: <18001.40213.565689.367357@fireball.kivinen.iki.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	<200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com>
	
	
	<30289.1179534871@marajade.sandelman.ca> 
	
	<32152.1179536945@marajade.sandelman.ca>
	<77ead0ec0705190103i5835a84v45ff8cc0e4f3acf3@mail.gmail.com>
	<18001.40213.565689.367357@fireball.kivinen.iki.fi>
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, Thomas Narten ,
	Michael Richardson ,
	Paul Hoffman , Mark Baugher 
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 22 May 2007 04:34:22 -0000

Hi Tero,

> One of the question is there, who are you trying to protect and
> against what attack?
The internal routers in the domain.

> Does the attacker actually have valid IPsec SA to the end router?
No the attacker does not have it. But he has packets that were sent on
the wire earlier. He can replay the packets from an earlier session.
As no Replay protection is there for manual keying, this might just be
an issue if the packets are not filtered at the edge.

I agree if firewalls can be configured to look into ESP-packets if the
packet is ESP-NULL (again through configuration) then there is no
difference at all, for the transport mode.

Thanks,
Vishwas

On 5/21/07, Tero Kivinen  wrote:
> Vishwas Manral writes:
> > For tunnel mode the difference between AH and ESP-NULL does not matter
> > as such from a security perspective. Except for the case of deep
> > packet inspection by middleboxes. Currently all OSPF packets coming
> > from outside the domain are filtered and dropped. This helps because
> > offpath attacks on the routing infrastructure can be prevented (it is
> > another discussion about what it means to have replayed packets from a
> > previous session). However with ESP-NULL such packets cannot be caught
> > by the firewall as firewalls cannot look inside ESP packets, while
> > they can inside AH packets.
>
> If only ESP packets going to that destination are mandated of being
> ESP-NULL you can look into them. Also if you make sure the destination
> routers policy is set so that only ESP-NULL is acceptable for the OSFP
> traffic, then you can even allow other ESP traffic, and still inspect
> the ESP-NULL packets and discard all OSPF packets.
>
> One of the question is there, who are you trying to protect and
> against what attack?
>
> Does the attacker actually have valid IPsec SA to the end router?
>
> If so, how was he able to create it? Did he have the keys or what?
>
> If the attacker does not have valid IPsec SA why is it not enough for
> the end node to drop the packet when it fails the IPsec processing?
>
> If we assume that attacker has the keying material for the IPsec SA
> (and the firewall does not ;-) and the firewall tries to protect the
> end router from attackers packets.
>
> The firewall can still do that. The end router simply needs to be
> configured to use IPsec in so way that it only allows ESP-NULL for the
> OSPF traffic, i.e. OSPF packets cannot ever be sent over any other
> ESP-non-null SA. The firewall will know which algorithms are allowed
> and used inside the zone it is trying to protect, thus it can know how
> many bytes it needs to skip to skip the IV and sequence number. After
> that there is IP header, so the firewall can simply check that if that
> IP header is valid and if the other upper layer headers coming after
> that are valid and if they match forbidden traffic (OSPF in this
> case), it will drop the packet.
>
> Only difference here to the AH is that it needs to skip some bytes
> based on the algorithm it knows and that there is very small
> probability that valid ESP-non-NULL traffic destioned to the end
> router was dropped as it happened to encrypt to data that was
> valid OSFP packet. Probability for that is very small, and upper level
> retransmissions will take care of that (i.e. when packet was dropped
> here, the upper level will retransmit it, in which case it is
> reencrypted, and the new packet will look different, thus not going to
> be dropped by the filters).
>
> And all this just you do not need to configure the inner routers
> properly to do access control based on where they get their packets.
> --
> kivinen@safenet-inc.com
>

From kivinen@iki.fi Wed May 23 08:52:19 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4NCqI37020527
	for ; Wed, 23 May 2007 08:52:18 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4NCq2ME024260
	for ; Wed, 23 May 2007 08:52:02 -0400 (EDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 4FC404D0106
	for ; Wed, 23 May 2007 08:52:01 -0400 (EDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1])
	by mail.kivinen.iki.fi (8.13.8/8.12.10) with ESMTP id l4NCpBur000125
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 23 May 2007 15:51:11 +0300 (EEST)
Received: (from kivinen@localhost)
	by fireball.kivinen.iki.fi (8.13.8/8.12.11) id l4NCp3ng027537;
	Wed, 23 May 2007 15:51:03 +0300 (EEST)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to
	kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <18004.14519.904451.460473@fireball.kivinen.iki.fi>
Date: Wed, 23 May 2007 15:51:03 +0300
From: Tero Kivinen 
To: "Vishwas Manral" 
In-Reply-To: <77ead0ec0705212134o63ad03a3r2edd0059ed2a11ff@mail.gmail.com>
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	<200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com>
	
	
	<30289.1179534871@marajade.sandelman.ca> 
	
	<32152.1179536945@marajade.sandelman.ca>
	<77ead0ec0705190103i5835a84v45ff8cc0e4f3acf3@mail.gmail.com>
	<18001.40213.565689.367357@fireball.kivinen.iki.fi>
	<77ead0ec0705212134o63ad03a3r2edd0059ed2a11ff@mail.gmail.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 4 min
X-Total-Time: 3 min
X-Spam-Score: 0.01
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, Thomas Narten ,
	Michael Richardson ,
	Paul Hoffman , Mark Baugher 
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 23 May 2007 12:52:19 -0000

Vishwas Manral writes:
> > Does the attacker actually have valid IPsec SA to the end router?
> No the attacker does not have it. But he has packets that were sent on
> the wire earlier. He can replay the packets from an earlier session.
> As no Replay protection is there for manual keying, this might just be
> an issue if the packets are not filtered at the edge.

If he have seen the earlier packets on the wire, why does he need to
send them again from the outside of the domain, if he is already on
the wire, he can replay them from that point too bypassing your
protections on the border gateways anyways.

Also does not normal ingress filters filter out those packets having
internal address as a source address coming from outside?

> I agree if firewalls can be configured to look into ESP-packets if the
> packet is ESP-NULL (again through configuration) then there is no
> difference at all, for the transport mode.

So it is not really the protocol problem it is the problem that
implementations do not have that support yet.
-- 
kivinen@safenet-inc.com

From gdt@ir.bbn.com Wed May 23 09:20:56 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4NDKui6027578
	for ; Wed, 23 May 2007 09:20:56 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4NDKlgB021201
	for ; Wed, 23 May 2007 09:20:47 -0400 (EDT)
Received: from fnord.ir.bbn.com (fnord.ir.bbn.com [192.1.100.210])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 316DD4E330A
	for ; Wed, 23 May 2007 09:20:45 -0400 (EDT)
Received: by fnord.ir.bbn.com (Postfix, from userid 10853)
	id 8858F5297; Wed, 23 May 2007 09:20:45 -0400 (EDT)
From: Greg Troxel 
To: "Vishwas Manral" 
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	<200705171623.l4HGNh5N006193@cichlid.raleigh.ibm.com>
	
	
	<30289.1179534871@marajade.sandelman.ca> 
	
	<32152.1179536945@marajade.sandelman.ca>
	<77ead0ec0705190103i5835a84v45ff8cc0e4f3acf3@mail.gmail.com>
	<18001.40213.565689.367357@fireball.kivinen.iki.fi>
	<77ead0ec0705212134o63ad03a3r2edd0059ed2a11ff@mail.gmail.com>
X-Hashcash: 1:20:070523:vishwas.ietf@gmail.com::qFzZOweyNvnPNP6/:0000000000000000000000000000000000000001MRL
X-Hashcash: 1:20:070523:saag@mit.edu::Q4pALM4tp+xN8DXQ:000004Ys7
Date: Wed, 23 May 2007 09:20:45 -0400
In-Reply-To: <77ead0ec0705212134o63ad03a3r2edd0059ed2a11ff@mail.gmail.com>
	(Vishwas Manral's message of "Tue, 22 May 2007 10:04:18 +0530")
Message-ID: 
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/21.4 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 23 May 2007 13:20:56 -0000

"Vishwas Manral"  writes:

> Hi Tero,
>
>> Does the attacker actually have valid IPsec SA to the end router?
> No the attacker does not have it. But he has packets that were sent on
> the wire earlier. He can replay the packets from an earlier session.
> As no Replay protection is there for manual keying, this might just be
> an issue if the packets are not filtered at the edge.

I think the threat model should include a compromised host inside the
domain that's on a link that is running OSPF.  (I realize that many
sites may be able to argue that this can't happen, but that's not a good
reason to exclude it from the threat model.)  Given such a threat, the
notion of blocking packets at the edge is unsatisfying.

Can the processing rules for OSPF be changed to say "MUST NOT use the IP
source address of incoming packets"?  If not, then transport-mode ESP
isn't protecting some of the data that's used by the receiver.

From vishwas.ietf@gmail.com Thu May 24 13:22:14 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4OHMENX027361
	for ; Thu, 24 May 2007 13:22:14 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4OHMCvB005160
	for ; Thu, 24 May 2007 13:22:12 -0400 (EDT)
Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.227])
	by mit.edu (Spam Firewall) with ESMTP id C120A2E4D98
	for ; Thu, 24 May 2007 13:22:11 -0400 (EDT)
Received: by nz-out-0506.google.com with SMTP id n1so553313nzf
	for ; Thu, 24 May 2007 10:22:11 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=S/JrOu7VOIsi7ag4M1OX/k8fKabi8dQzCGM5+H3eUuJyAa8v6EmjPO/IrgYP9gUbCDCKYCu47+reVXTjIhgFlpnePLc5Q1Sr+LKVFNVaudGQk8nHPpPIjHBHYWf+OUsEsyDOQFU+kJZasXucH4aIlhQclll/emn6/a0WDAF7O2g=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=FcIz3QLq0lJw90Z/LkmEbC0hVZlxLTlQMvUlsWAH9WffOwLrETjj3NsWkwysaCcdxOhs7elCthUFC3pCqL3Jd7p1A5rwwJVCh11uVT3xMiNiz5qxyEenEK9eEMbf12AiV5WugZpsB6ufqQfKmtDrQ4vZFhR3ABFNwI21aXf74P8=
Received: by 10.114.155.1 with SMTP id c1mr1021112wae.1180027331224;
	Thu, 24 May 2007 10:22:11 -0700 (PDT)
Received: by 10.114.24.9 with HTTP; Thu, 24 May 2007 10:22:11 -0700 (PDT)
Message-ID: <77ead0ec0705241022k5d13f7dem5ed913c19edfecbf@mail.gmail.com>
Date: Thu, 24 May 2007 10:22:11 -0700
From: "Vishwas Manral" 
To: "Tero Kivinen" 
In-Reply-To: <18004.14519.904451.460473@fireball.kivinen.iki.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	
	<30289.1179534871@marajade.sandelman.ca> 
	
	<32152.1179536945@marajade.sandelman.ca>
	<77ead0ec0705190103i5835a84v45ff8cc0e4f3acf3@mail.gmail.com>
	<18001.40213.565689.367357@fireball.kivinen.iki.fi>
	<77ead0ec0705212134o63ad03a3r2edd0059ed2a11ff@mail.gmail.com>
	<18004.14519.904451.460473@fireball.kivinen.iki.fi>
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, Thomas Narten ,
	Michael Richardson ,
	Paul Hoffman , Mark Baugher 
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 24 May 2007 17:22:14 -0000

Hi Tero,

> If he have seen the earlier packets on the wire, why does he need to
> send them again from the outside of the domain, if he is already on
> the wire, he can replay them from that point too bypassing your
> protections on the border gateways anyways.
>
> Also does not normal ingress filters filter out those packets having
> internal address as a source address coming from outside?
The actual use case of why filtering is done in the case of non
authenticated OSPF packtes  is because a packet sent from anywhere
across the internet can cause the OSPF router to go down. With
additional authentication checks the same can only be done for
replayed packets. Using the same scenario I made the assumption here.

> > I agree if firewalls can be configured to look into ESP-packets if the
> > packet is ESP-NULL (again through configuration) then there is no
> > difference at all, for the transport mode.
> So it is not really the protocol problem it is the problem that
> implementations do not have that support yet.
I guess you are right, if this is done then there is no difference for
the transport mode.

Thanks,
Vishwas

On 5/23/07, Tero Kivinen  wrote:
> Vishwas Manral writes:
> > > Does the attacker actually have valid IPsec SA to the end router?
> > No the attacker does not have it. But he has packets that were sent on
> > the wire earlier. He can replay the packets from an earlier session.
> > As no Replay protection is there for manual keying, this might just be
> > an issue if the packets are not filtered at the edge.
>
> If he have seen the earlier packets on the wire, why does he need to
> send them again from the outside of the domain, if he is already on
> the wire, he can replay them from that point too bypassing your
> protections on the border gateways anyways.
>
> Also does not normal ingress filters filter out those packets having
> internal address as a source address coming from outside?
>
> > I agree if firewalls can be configured to look into ESP-packets if the
> > packet is ESP-NULL (again through configuration) then there is no
> > difference at all, for the transport mode.
>
> So it is not really the protocol problem it is the problem that
> implementations do not have that support yet.
> --
> kivinen@safenet-inc.com
>

From vishwas.ietf@gmail.com Thu May 24 13:26:32 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4OHQW7D028091
	for ; Thu, 24 May 2007 13:26:32 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4OHQUr4028498
	for ; Thu, 24 May 2007 13:26:30 -0400 (EDT)
Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.236])
	by mit.edu (Spam Firewall) with ESMTP id 246544FBE4E
	for ; Thu, 24 May 2007 13:26:29 -0400 (EDT)
Received: by wr-out-0506.google.com with SMTP id i31so178459wra
	for ; Thu, 24 May 2007 10:26:29 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=R0YwoLFBVfPe6gp/A3zT2DkepjEpAXaNRrRdoWl4iqM0Wj9VAgGVpz1s6d+Bd/XAFJ/Y95al1rzpXI5nxfCIMXSJjIVPSb24mIV/2NFb/8vHQjObX5SHiPyczMEuOXGm7Ss/LgtBPO8uX9Zt3swgtLkW6QjxOMsQwOjw3bK0eZk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=Qsyvi9L0O2iLGScA0dNp9CRm+B9B2ylHuKLFrHQNLTSgRRZh1ntiHqlll2HZhnraTbR7EzvZNWshwI3MDEB7p0TZ3BndqYwxxL/iQVUjEdVHezfQc36RGXRtByz9zcJEwHJVbZOs0ez0XYPAoNGxxtsSnT8mcj7lO8nm+IXQ6Gk=
Received: by 10.115.79.1 with SMTP id g1mr1030952wal.1180027588197;
	Thu, 24 May 2007 10:26:28 -0700 (PDT)
Received: by 10.114.24.9 with HTTP; Thu, 24 May 2007 10:26:28 -0700 (PDT)
Message-ID: <77ead0ec0705241026q3246fb7aoa19c91efa28dd6f5@mail.gmail.com>
Date: Thu, 24 May 2007 10:26:28 -0700
From: "Vishwas Manral" 
To: "Greg Troxel" 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <200705171402.l4HE2c1Y032332@cichlid.raleigh.ibm.com>
	
	<30289.1179534871@marajade.sandelman.ca> 
	
	<32152.1179536945@marajade.sandelman.ca>
	<77ead0ec0705190103i5835a84v45ff8cc0e4f3acf3@mail.gmail.com>
	<18001.40213.565689.367357@fireball.kivinen.iki.fi>
	<77ead0ec0705212134o63ad03a3r2edd0059ed2a11ff@mail.gmail.com>
	
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 24 May 2007 17:26:32 -0000

Hi Greg,

> I think the threat model should include a compromised host inside the
> domain that's on a link that is running OSPF.  (I realize that many
> sites may be able to argue that this can't happen, but that's not a good
> reason to exclude it from the threat model.)  Given such a threat, the
> notion of blocking packets at the edge is unsatisfying.
>
> Can the processing rules for OSPF be changed to say "MUST NOT use the IP
> source address of incoming packets"?  If not, then transport-mode ESP
> isn't protecting some of the data that's used by the receiver.
You are right that is one case. The other case for onlink threat,
could as well be sending the older packets over again, without any
change, even though an older router is not there. So incase a valid DB
Description packet sent once an adjacency is up, breaks the adjacency
and disrupts the entire routing. However the difference between AH and
ESP-NULL is not there in such a case.

Thanks,
Vishwas

From paul.hoffman@vpnc.org Tue May 29 16:46:35 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4TKkZML029496
	for ; Tue, 29 May 2007 16:46:35 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4TKkUW3016122
	for ; Tue, 29 May 2007 16:46:30 -0400 (EDT)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 11B56503218
	for ; Tue, 29 May 2007 16:46:20 -0400 (EDT)
Received: from [10.20.30.108] (adsl-66-125-125-65.dsl.pltn13.pacbell.net
	[66.125.125.65]) (authenticated bits=0)
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4TKkEgW039362
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Tue, 29 May 2007 13:46:15 -0700 (MST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
Date: Tue, 29 May 2007 13:46:12 -0700
To: saag@mit.edu
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.12
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] New potential BoF and mailing list: trust anchors
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 29 May 2007 20:46:35 -0000

 From the description on the web site:

The ietf-trust-anchor mailing list is for discussing a standard 
protocol for trust anchor management. Many groups within the IETF, 
including PKIX, Kerberos, and SIDR, have all stated that trust anchor 
management is necessary, but outside the scope of their documents.

This is being proposed as a BoF for Chicago.

Subscription information is at .

--Paul Hoffman, Director
--VPN Consortium

From mikraus@cisco.com Thu May 31 12:11:07 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4VGB7FA029423
	for ; Thu, 31 May 2007 12:11:07 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4VGAoM1011952
	for ; Thu, 31 May 2007 12:10:50 -0400 (EDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149])
	by mit.edu (Spam Firewall) with ESMTP id 527092FA838
	for ; Thu, 31 May 2007 12:10:46 -0400 (EDT)
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 31 May 2007 12:10:43 -0400
X-IronPort-AV: i="4.14,599,1170651600"; 
	d="scan'208"; a="122469163:sNHT51945664"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4VGAgRn025580
	for ; Thu, 31 May 2007 12:10:42 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4VGAgBe001522
	for ; Thu, 31 May 2007 16:10:42 GMT
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 31 May 2007 12:10:38 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Thu, 31 May 2007 12:10:37 -0400
Message-ID: <249A89BAA060C94FA0B93EA6135CC93C038CAA03@xmb-rtp-20b.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [saag] AH & OSPF
Thread-Index: AcejnjnIbbFq/ihoTEWLzURuR5p5hw==
From: "Mike Kraus (mikraus)" 
To: 
X-OriginalArrivalTime: 31 May 2007 16:10:38.0668 (UTC)
	FILETIME=[3A9A00C0:01C7A39E]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=709; t=1180627842;
	x=1181491842; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=mikraus@cisco.com;
	z=From:=20=22Mike=20Kraus=20\(mikraus\)=22=20
	|Subject:=20[saag]=20AH=20&=20OSPF |Sender:=20
	|To:=20;
	bh=9B3nprl6GfrhTRZWqvE6ysU3hg3jFsDYDwtcY0R5ohQ=;
	b=O8F5+WemiK4p2JP7kJZDKHd2RZCZECwSN4L7JFC4C5Q2b6kHhgFeQG/4ACXqyHQE8rEwsTns
	K4VjCUWu+phCTqpg8he68o+CE3tU0orld9KkvXFsJ2fgMKSgxAyKvwlO;
Authentication-Results: rtp-dkim-1; header.From=mikraus@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 3.5
X-Spam-Level: *** (3.5)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id
	l4VGB7FA029423
Subject: [saag]  AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 31 May 2007 16:11:07 -0000

Virtual-links should not be seen as a "tunnel".  It is merely the
extension of OSPF area 0 through other areas.  This being the case, OSPF
would still need to be active on a given link for a virtual-link to
operate over it.
 
If you were to use a GRE or comparable tunneling method to extend area
0, then of course OSPF ports would not need to be opened.
 
>Well, except for virtual links, which is a special case.  And even so
>you wouldn't think that the packets would be going through firewalls.
>
>Except that I just found a disturbing reference on cisco that "if there
is
>a firewall in between the virtual-link routers, you need to enable the
>OSPF (P protocol 89) port"
>
>--Sandy


From sandy@tislabs.com Thu May 31 13:59:15 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4VHxF2p022417
	for ; Thu, 31 May 2007 13:59:15 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4VHwxPF024518
	for ; Thu, 31 May 2007 13:58:59 -0400 (EDT)
Received: from nutshell.tislabs.com (ns1.tislabs.com [192.94.214.100])
	by mit.edu (Spam Firewall) with ESMTP id 0EE412E81AE
	for ; Thu, 31 May 2007 13:58:58 -0400 (EDT)
Received: (from uucp@localhost)
	by nutshell.tislabs.com (8.12.9/8.12.9) id l4VHuw2d018193;
	Thu, 31 May 2007 13:56:58 -0400 (EDT)
Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap
	(V6.0) id srcAAAO7aGuJ; Thu, 31 May 07 13:55:45 -0400
Received: by pecan.tislabs.com (Postfix, from userid 2005)
	id AB85E3F450; Thu, 31 May 2007 13:54:14 -0400 (EDT)
To: mikraus@cisco.com, saag@mit.edu
In-Reply-To: <249A89BAA060C94FA0B93EA6135CC93C038CAA03@xmb-rtp-20b.amer.cisco.com>
Message-Id: <20070531175414.AB85E3F450@pecan.tislabs.com>
Date: Thu, 31 May 2007 13:54:14 -0400 (EDT)
From: sandy@tislabs.com (Sandy Murphy)
X-Spam-Score: 0
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: sandy@tislabs.com
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 31 May 2007 17:59:16 -0000

>Virtual-links should not be seen as a "tunnel". 

Yes, that is true.  But where did you get the idea that someone was
seeing this as a tunnel?

If you were confused by my comment:

>>Except that I just found a disturbing reference on cisco that "if there
>is
>>a firewall in between the virtual-link routers, you need to enable the
>>OSPF (P protocol 89) port"

The conversation so far had made conclusions about use of AH in OSPF
on the basis that OSPF packets would not be going through firewalls.
This cisco quote seemed to imply that there are circumstances where
OSPF packets would have to traverse firewalls.  The mind boggles at
such a topology, but there it is.

--Sandy

From mikraus@cisco.com Thu May 31 15:54:40 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4VJseAH017388
	for ; Thu, 31 May 2007 15:54:40 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4VJsN5f023653
	for ; Thu, 31 May 2007 15:54:23 -0400 (EDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148])
	by mit.edu (Spam Firewall) with ESMTP id 31CE230E533
	for ; Thu, 31 May 2007 15:51:53 -0400 (EDT)
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 31 May 2007 15:51:53 -0400
X-IronPort-AV: i="4.16,370,1175486400"; 
	d="scan'208"; a="61648771:sNHT54938832"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4VJprGC002116; 
	Thu, 31 May 2007 15:51:53 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4VJpZCI010748; 
	Thu, 31 May 2007 19:51:53 GMT
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 31 May 2007 15:51:51 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Thu, 31 May 2007 15:51:49 -0400
Message-ID: <249A89BAA060C94FA0B93EA6135CC93C038CAB68@xmb-rtp-20b.amer.cisco.com>
In-Reply-To: <20070531175414.AB85E3F450@pecan.tislabs.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [saag]  AH & OSPF
Thread-Index: AcejrV2pJdZZrgTAR4+K8XbyLjzrSAADn0qA
References: <249A89BAA060C94FA0B93EA6135CC93C038CAA03@xmb-rtp-20b.amer.cisco.com>
	<20070531175414.AB85E3F450@pecan.tislabs.com>
From: "Mike Kraus (mikraus)" 
To: "Sandy Murphy" , 
X-OriginalArrivalTime: 31 May 2007 19:51:51.0747 (UTC)
	FILETIME=[21F92130:01C7A3BD]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1420; t=1180641113;
	x=1181505113; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=mikraus@cisco.com;
	z=From:=20=22Mike=20Kraus=20\(mikraus\)=22=20
	|Subject:=20RE=3A=20[saag]=20=20AH=20&=20OSPF |Sender:=20
	|To:=20=22Sandy=20Murphy=22=20,=20;
	bh=qCMK127rpnyAs2zO7ykA8BmEKEx/GDiHfQ/etbNBZ+E=;
	b=WrI3nTGCCnH2pRVF2Quju0OqDeiHTaYTh6sJ4hxq7z1FvfauFW3HW3OsljATu8hzO4nWzn0l
	nmLN1h1NHgPlw0r98wKfIG6bmNlZmWVOR4S9bKWK/BGBhpzxiJ6xTR2R;
Authentication-Results: rtp-dkim-2; header.From=mikraus@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.60
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id
	l4VJseAH017388
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 31 May 2007 19:54:40 -0000

Sandy,

Yes I did misinterpret initial your comment, my mistake.

There would be two instances where I have seen OSPF traversing a
firewall.  Either with a router with an embedded firewall or, if there
is a transparent firewall in between OSPF peers.  Firewalling techniques
in secure environments are certainly used within the network, not only
at the perimeter.  (I do focus on DoD customers most recently, so maybe
my perception of the world has become tainted!) :)

Thanks,
  Mike
-----Original Message-----
From: Sandy Murphy [mailto:sandy@tislabs.com] 
Sent: Thursday, May 31, 2007 12:54 PM
To: Mike Kraus (mikraus); saag@mit.edu
Cc: sandy@tislabs.com
Subject: Re: [saag] AH & OSPF

>Virtual-links should not be seen as a "tunnel". 

Yes, that is true.  But where did you get the idea that someone was
seeing this as a tunnel?

If you were confused by my comment:

>>Except that I just found a disturbing reference on cisco that "if 
>>there
>is
>>a firewall in between the virtual-link routers, you need to enable the

>>OSPF (P protocol 89) port"

The conversation so far had made conclusions about use of AH in OSPF on
the basis that OSPF packets would not be going through firewalls.
This cisco quote seemed to imply that there are circumstances where OSPF
packets would have to traverse firewalls.  The mind boggles at such a
topology, but there it is.

--Sandy


From sandy@tislabs.com Thu May 31 16:44:14 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4VKiEn9025545
	for ; Thu, 31 May 2007 16:44:14 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4VKi7TM016746
	for ; Thu, 31 May 2007 16:44:07 -0400 (EDT)
Received: from nutshell.tislabs.com (ns1.tislabs.com [192.94.214.100])
	by mit.edu (Spam Firewall) with ESMTP id 9E26F2FE9A8
	for ; Thu, 31 May 2007 16:44:06 -0400 (EDT)
Received: (from uucp@localhost)
	by nutshell.tislabs.com (8.12.9/8.12.9) id l4VKg6MW000029;
	Thu, 31 May 2007 16:42:06 -0400 (EDT)
Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap
	(V6.0) id srcAAAlPaWba; Thu, 31 May 07 16:41:57 -0400
Received: by pecan.tislabs.com (Postfix, from userid 2005)
	id 3082B3F450; Thu, 31 May 2007 16:40:27 -0400 (EDT)
To: mikraus@cisco.com, saag@mit.edu, sandy@tislabs.com
In-Reply-To: <249A89BAA060C94FA0B93EA6135CC93C038CAB68@xmb-rtp-20b.amer.cisco.com>
Message-Id: <20070531204027.3082B3F450@pecan.tislabs.com>
Date: Thu, 31 May 2007 16:40:27 -0400 (EDT)
From: sandy@tislabs.com (Sandy Murphy)
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 31 May 2007 20:44:14 -0000

>There would be two instances where I have seen OSPF traversing a
>firewall.  

So do we need to reset the conversation about OSPF and AH vs ESP back
to "which allows packet inspection at firewalls"?

--Sandy

From mikraus@cisco.com Thu May 31 17:19:47 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4VLJljE031154
	for ; Thu, 31 May 2007 17:19:47 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4VLJZwx005862
	for ; Thu, 31 May 2007 17:19:36 -0400 (EDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149])
	by mit.edu (Spam Firewall) with ESMTP id 627AA52D558
	for ; Thu, 31 May 2007 17:19:35 -0400 (EDT)
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 31 May 2007 17:19:35 -0400
X-IronPort-AV: i="4.16,370,1175486400"; 
	d="scan'208"; a="122505571:sNHT56400612"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4VLJY9K024392; 
	Thu, 31 May 2007 17:19:34 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4VLIIC4006396; 
	Thu, 31 May 2007 21:19:34 GMT
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 31 May 2007 17:19:09 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Thu, 31 May 2007 17:19:06 -0400
Message-ID: <249A89BAA060C94FA0B93EA6135CC93C038CABE1@xmb-rtp-20b.amer.cisco.com>
In-Reply-To: <20070531204027.3082B3F450@pecan.tislabs.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [saag]  AH & OSPF
Thread-Index: AcejxHLsN2CLCoPVQVa4YXnECQU6bAAAyV/w
References: <249A89BAA060C94FA0B93EA6135CC93C038CAB68@xmb-rtp-20b.amer.cisco.com>
	<20070531204027.3082B3F450@pecan.tislabs.com>
From: "Mike Kraus (mikraus)" 
To: "Sandy Murphy" , 
X-OriginalArrivalTime: 31 May 2007 21:19:09.0221 (UTC)
	FILETIME=[53C03D50:01C7A3C9]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2240; t=1180646374;
	x=1181510374; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=mikraus@cisco.com;
	z=From:=20=22Mike=20Kraus=20\(mikraus\)=22=20
	|Subject:=20RE=3A=20[saag]=20=20AH=20&=20OSPF |Sender:=20
	|To:=20=22Sandy=20Murphy=22=20,=20;
	bh=yHzb/UTErWt/fDNejJ1P0HWLLKL6XRp5cxS3vSL2ct8=;
	b=iadO1G5Jdxgi8sapgk70PEiKtVAUOoFBA2K5ZzvjmSbXA8+fvctvyKo/js+OhErjfaACx3a+
	dx2emIXeceC7n07I2/Q8Ox10uA1AzuSK/w600Cvc1OZ25tOnCcO7xNVW;
Authentication-Results: rtp-dkim-1; header.From=mikraus@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.60
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id
	l4VLJljE031154
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 31 May 2007 21:19:47 -0000

Perhaps the below text may assist in the discussion:

"Cisco believes that as the Federal Government and others transition to
IPv6 in the coming years, they will primarily utilize "AH" for
authentication services because it accommodates critical network
services such as security inspection, QoS classification and marking,
and traffic management for intermediate network devices (e.g., routers,
switches, IPS, etc.). "ESP with NULL Encryption" would frustrate these
important, demanded, and required network services. Therefore, we expect
the availability and usage of AH will fit best in customer enterprise
network environments to meet operational, productivity, and mission
requirements." 

"To explain further, with "AH," the intermediate network devices can be
enhanced to recognize the "AH" traffic and continue to provide the
critical network services such as security inspection, QoS
classification and marking, and traffic management.  The use of "ESP
with NULL encryption" instead of "AH" introduces a number of significant
problems for these intermediate network devices.  Since the ESP packet
format contains no indication of whether or not NULL encryption or a
real encryption algorithm is in use, an intermediate device is forced to
use heuristics to guess which ESP packets contain NULL encryption.  Even
the best heuristic methods will too often fail making these methods, and
"ESP with NULL encryption", unsuitable for intermediate network devices
which need to provide critical network services such as security, QoS,
and traffic management.  Therefore, we expect the availability and usage
of "AH" will be the best fit for authentication services when used in
customer enterprise network environments to meet operational,
productivity, and mission needs.
"



-----Original Message-----
From: Sandy Murphy [mailto:sandy@tislabs.com] 
Sent: Thursday, May 31, 2007 3:40 PM
To: Mike Kraus (mikraus); saag@mit.edu; sandy@tislabs.com
Subject: RE: [saag] AH & OSPF

>There would be two instances where I have seen OSPF traversing a 
>firewall.

So do we need to reset the conversation about OSPF and AH vs ESP back to
"which allows packet inspection at firewalls"?

--Sandy


From kent@bbn.com Thu May 31 19:56:57 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l4VNuuAv022056
	for ; Thu, 31 May 2007 19:56:57 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l4VNutlg007704
	for ; Thu, 31 May 2007 19:56:55 -0400 (EDT)
Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81])
	by mit.edu (Spam Firewall) with ESMTP id 108D8525767
	for ; Thu, 31 May 2007 19:56:55 -0400 (EDT)
Received: from dommiel.bbn.com ([192.1.122.15] helo=[172.16.2.76])
	by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from )
	id 1HtuVh-0002E3-4x; Thu, 31 May 2007 19:56:54 -0400
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <249A89BAA060C94FA0B93EA6135CC93C038CABE1@xmb-rtp-20b.amer.cisco.com>
References: <249A89BAA060C94FA0B93EA6135CC93C038CAB68@xmb-rtp-20b.amer.cisco.com>
	<20070531204027.3082B3F450@pecan.tislabs.com>
	<249A89BAA060C94FA0B93EA6135CC93C038CABE1@xmb-rtp-20b.amer.cisco.com>
Date: Thu, 31 May 2007 19:54:40 -0400
To: "Mike Kraus (mikraus)" 
From: Stephen Kent 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, Sandy Murphy 
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 31 May 2007 23:56:57 -0000

Mike,

Its a pity that Cisco, who had several staff members actively 
participating in the IPsec WG, did not see fit to state these 
concerns during the multi-year interval during which RFC 4301 was 
being edited. It's a bit late to be suggesting that the status of AH 
support (MAY) in 4301 is not appropriate.

One could argue that the packet inspection features that AH allows, 
but which will not be readily available if ESP-NULL is used, are 
examples of layer violations :-). But, the real question is whether 
most traffic would benefit significantly from use of either AH or 
ESP-NULL, vs. ESP, since most traffic that merits layer 3 crypto 
protection probably requires confidentiality, as well as integrity 
and authentication.

Steve

From vishwas.ietf@gmail.com Thu May 31 20:16:47 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l510GlOk024987
	for ; Thu, 31 May 2007 20:16:47 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l510Gjp3025145
	for ; Thu, 31 May 2007 20:16:45 -0400 (EDT)
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179])
	by mit.edu (Spam Firewall) with ESMTP id 0FEE2524C90
	for ; Thu, 31 May 2007 20:16:44 -0400 (EDT)
Received: by wa-out-1112.google.com with SMTP id j37so506952waf
	for ; Thu, 31 May 2007 17:16:44 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=A4bFM/+Y0U5haY1FYTzuBdFEEjTBWPsbQ03dBACBnUfMwaSHTPXIx27SaXQu7nc0wp5OHQQVoor0n0Oc51z2JnYBDX5uDIpPfnqCUlHMpvcy+vVBERSH5aWj/ThPjkeprKm5YYWvUR5RVu/yQ9lnErG0gwiGz4W4SpbjpK8+p0o=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=c/kgOjPknYXNbN+jmY8FzDfsWzQ2juMVyqu2Ub/toJD4FweECELoKe+HXlhb1o//zwDiRvG7mSkf6eFNITNmGPZCQd+4fjrYYb4GbOs0EC6h/BHDgaSlL1yTqHIPD/yTFnvWtN91Q3cBM7OXmz53SIJcI0XADD+x3PwG8oxIy64=
Received: by 10.114.73.1 with SMTP id v1mr1225811waa.1180657004320;
	Thu, 31 May 2007 17:16:44 -0700 (PDT)
Received: by 10.114.24.9 with HTTP; Thu, 31 May 2007 17:16:44 -0700 (PDT)
Message-ID: <77ead0ec0705311716i4519dd2ai424f4467e76b54a1@mail.gmail.com>
Date: Thu, 31 May 2007 17:16:44 -0700
From: "Vishwas Manral" 
To: "Stephen Kent" 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <249A89BAA060C94FA0B93EA6135CC93C038CAB68@xmb-rtp-20b.amer.cisco.com>
	<20070531204027.3082B3F450@pecan.tislabs.com>
	<249A89BAA060C94FA0B93EA6135CC93C038CABE1@xmb-rtp-20b.amer.cisco.com>
	
X-Spam-Score: 0.12
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, "Mike Kraus \(mikraus\)" ,
	Sandy Murphy 
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 01 Jun 2007 00:16:47 -0000

Hi Mike,

I mostly agree with Stephen here about the usage of ESP-NULL and AH.
Though I had raised the same issue myself earlier(a couple of years
back), after what Tero explained to me, I agree that the firewall part
is not a big issue with ESP-NULL either.
http://www1.ietf.org/mail-archive/web/ipsec/current/msg01902.html

Like Tero said, if the SA is manually keyed, we will need to do the
same for firewalls too. If they are done using IKE, the same can be
achieved by snooping on the packets. I agree it is tougher (unlike
having a bit in ESP to state the same - which would have solved it
all) and is not done in current products. It is not that it cannot be
done at all.

Regarding the QoS part l think the DSCP field can be used for the
same, also if the inner packet is used by middle boxes in the AH case,
it also leads to a case where the same can be manipulated as the
middleboxes cannot verify the values in the packet either. For the
OSPF part however the same is not true as the packets are mostly sent
one hop away.

Thanks,
Vishwas

On 5/31/07, Stephen Kent  wrote:
> Mike,
>
> Its a pity that Cisco, who had several staff members actively
> participating in the IPsec WG, did not see fit to state these
> concerns during the multi-year interval during which RFC 4301 was
> being edited. It's a bit late to be suggesting that the status of AH
> support (MAY) in 4301 is not appropriate.
>
> One could argue that the packet inspection features that AH allows,
> but which will not be readily available if ESP-NULL is used, are
> examples of layer violations :-). But, the real question is whether
> most traffic would benefit significantly from use of either AH or
> ESP-NULL, vs. ESP, since most traffic that merits layer 3 crypto
> protection probably requires confidentiality, as well as integrity
> and authentication.
>
> Steve

From sandy@tislabs.com Fri Jun  1 15:45:07 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l51Jj7L7027744
	for ; Fri, 1 Jun 2007 15:45:07 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l51Jj6eW017996
	for ; Fri, 1 Jun 2007 15:45:06 -0400 (EDT)
Received: from nutshell.tislabs.com (ns1.tislabs.com [192.94.214.100])
	by mit.edu (Spam Firewall) with ESMTP id 09C2452CB8D
	for ; Fri,  1 Jun 2007 15:45:04 -0400 (EDT)
Received: (from uucp@localhost)
	by nutshell.tislabs.com (8.12.9/8.12.9) id l51Jgejq015621;
	Fri, 1 Jun 2007 15:42:40 -0400 (EDT)
Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap
	(V6.0) id srcAAAq5aaGE; Fri, 1 Jun 07 15:42:35 -0400
Received: by pecan.tislabs.com (Postfix, from userid 2005)
	id 125B73F472; Fri,  1 Jun 2007 15:41:05 -0400 (EDT)
To: kent@bbn.com, mikraus@cisco.com
In-Reply-To: 
Message-Id: <20070601194105.125B73F472@pecan.tislabs.com>
Date: Fri,  1 Jun 2007 15:41:05 -0400 (EDT)
From: sandy@tislabs.com (Sandy Murphy)
X-Spam-Score: 0
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 01 Jun 2007 19:45:08 -0000

>But, the real question is whether 
>most traffic would benefit significantly from use of either AH or 
>ESP-NULL, vs. ESP, since most traffic that merits layer 3 crypto 
>protection probably requires confidentiality, as well as integrity 
>and authentication.

In this particular discussion, we are talking about the protection
of OSPF with IPsec.  There have been some that have spoken for the
need for confidentiality protection in routing protocols, but they
haven't been the majority.  And even those who do see the need for
confidentiality have not been talking about intra-domain routing,
IIRC.

Not disagreeing with your comment in general, just keeping the
focus on this question.

--Sandy

From mbaugher@cisco.com Sat Jun  2 00:11:32 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l524BWiL030847
	for ; Sat, 2 Jun 2007 00:11:32 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l524BVZM022691
	for ; Sat, 2 Jun 2007 00:11:31 -0400 (EDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87])
	by mit.edu (Spam Firewall) with ESMTP id 96E46500FD1
	for ; Sat,  2 Jun 2007 00:11:30 -0400 (EDT)
Received: from sj-dkim-6.cisco.com ([171.68.10.81])
	by sj-iport-5.cisco.com with ESMTP; 01 Jun 2007 21:11:30 -0700
X-IronPort-AV: i="4.16,374,1175497200"; 
	d="scan'208"; a="160177566:sNHT43144065"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l524BTSp023416; 
	Fri, 1 Jun 2007 21:11:29 -0700
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l524BTV1019002;
	Sat, 2 Jun 2007 04:11:29 GMT
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.1830); 
	Sat, 2 Jun 2007 00:11:28 -0400
Received: from [192.168.0.10] ([10.82.242.67]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 2 Jun 2007 00:11:28 -0400
In-Reply-To: 
References: <249A89BAA060C94FA0B93EA6135CC93C038CAB68@xmb-rtp-20b.amer.cisco.com>
	<20070531204027.3082B3F450@pecan.tislabs.com>
	<249A89BAA060C94FA0B93EA6135CC93C038CABE1@xmb-rtp-20b.amer.cisco.com>
	
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Mark Baugher 
Date: Fri, 1 Jun 2007 21:11:26 -0700
To: Stephen Kent 
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 02 Jun 2007 04:11:28.0317 (UTC)
	FILETIME=[17D076D0:01C7A4CC]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1252; t=1180757489;
	x=1181621489; c=relaxed/simple; s=sjdkim6002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=mbaugher@cisco.com;
	z=From:=20Mark=20Baugher=20
	|Subject:=20Re=3A=20[saag]=20AH=20&=20OSPF |Sender:=20;
	bh=L0ZEuKRVGFUGIfqPdPauPM9OLXWS2N1NSfukJofCG1g=;
	b=n50+eSkwnfTTMElque4FB2zn5TADMED5171hhGxZsSNq6hrU0ZziWPu9zmku29mCFY7jQcmF
	nTSVhz0OAc8Mk6pwUvSxN4pY3poNoTuDIrrRvs+iRVd1zfIvEhyaC+QX;
Authentication-Results: sj-dkim-6; header.From=mbaugher@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim6002 verified; ); 
X-Spam-Score: 0.13
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, "Mike Kraus \(mikraus\)" ,
	Sandy Murphy 
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sat, 02 Jun 2007 04:11:33 -0000

Steve,

   Leaving aside the relevance of this discussion to OSPF...

On May 31, 2007, at 4:54 PM, Stephen Kent wrote:

> Mike,
>
> Its a pity that Cisco, who had several staff members actively
> participating in the IPsec WG, did not see fit to state these
> concerns during the multi-year interval during which RFC 4301 was
> being edited. It's a bit late to be suggesting that the status of AH
> support (MAY) in 4301 is not appropriate.
>
> One could argue that the packet inspection features that AH allows,
> but which will not be readily available if ESP-NULL is used, are
> examples of layer violations :-).

...is a TCP or UDP ACL a layer violation?

> But, the real question is whether
> most traffic would benefit significantly from use of either AH or
> ESP-NULL, vs. ESP, since most traffic that merits layer 3 crypto
> protection probably requires confidentiality, as well as integrity
> and authentication.

It seems to me that when a confidentiality service is provided
at a higher layer there is still value to providing access control
at layer 3.

Mark

>
> Steve
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://mailman.mit.edu/mailman/listinfo/saag

From mcr@marajade.sandelman.ca Mon Jun  4 09:55:22 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l54DtMIP005133
	for ; Mon, 4 Jun 2007 09:55:22 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l54DtAGX022938
	for ; Mon, 4 Jun 2007 09:55:11 -0400 (EDT)
Received: from cod.sandelman.ca (cod.sandelman.ca [192.139.46.42])
	by mit.edu (Spam Firewall) with ESMTP id 215B153E91F
	for ; Mon,  4 Jun 2007 09:36:11 -0400 (EDT)
Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca
	[205.150.200.247])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "marajade.sandelman.ca.",
	Issuer "Michael Richardson" (verified OK))
	by cod.sandelman.ca (Postfix) with ESMTP id 4A3A61236A
	for ; Mon,  4 Jun 2007 09:36:11 -0400 (EDT)
Received: from marajade.sandelman.ca (unknown [127.0.0.1])
	by sandelman.ottawa.on.ca (Postfix) with ESMTP id E81A23EC5
	for ; Mon,  4 Jun 2007 09:35:54 -0400 (EDT)
From: Michael Richardson 
To: saag@mit.edu
In-Reply-To: Message from Stephen Kent  of "Thu,
	31 May 2007 19:54:40 EDT."  
References: <249A89BAA060C94FA0B93EA6135CC93C038CAB68@xmb-rtp-20b.amer.cisco.com>
	<20070531204027.3082B3F450@pecan.tislabs.com>
	<249A89BAA060C94FA0B93EA6135CC93C038CABE1@xmb-rtp-20b.amer.cisco.com>
	 
X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 19)
Date: Mon, 04 Jun 2007 09:35:54 -0400
Message-ID: <27513.1180964154@marajade.sandelman.ca>
Sender: mcr@marajade.sandelman.ca
X-Spam-Score: 0.13
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Mon, 04 Jun 2007 13:55:22 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Stephen" == Stephen Kent  writes:
    Stephen> Its a pity that Cisco, who had several staff members
    Stephen> actively participating in the IPsec WG, did not see fit to
    Stephen> state these concerns during the multi-year interval during

  Be fair.
  CISCO is a very big organization.  

    Stephen> which RFC 4301 was being edited. It's a bit late to be
    Stephen> suggesting that the status of AH support (MAY) in 4301 is
    Stephen> not appropriate.

  RFC2401/4301 are base technology specifications.  95% of the people
who participated in the process were VPN people with little other
concern.
  (With the other 5% being David Black representing iSCSI)
  Frankly, it is a wonder that AH even made it into 4301.

  I think it was a mistake to ever think that they the MUST/MAY/SHOULD
in the broad parts of the specification mean anything without upper
layer protocol (layer 4 PLUS) specification input. 

    Stephen> One could argue that the packet inspection features that AH
    Stephen> allows, but which will not be readily available if ESP-NULL
    Stephen> is used, are examples of layer violations :-). But, the

  Yes. A very dangerous layer violation.
  In IPv6 AH is an extension header, not an upper-layer protocol header.

    Stephen> real question is whether most traffic would benefit
    Stephen> significantly from use of either AH or ESP-NULL, vs. ESP,
    Stephen> since most traffic that merits layer 3 crypto protection
    Stephen> probably requires confidentiality, as well as integrity and
    Stephen> authentication.

  I see no confidentiality requirements for OSPF. It's all integrity.

- -- 
]            Bear: "Me, I'm just the shape of a bear."          |  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.6 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRmQVLoCLcPvd0N1lAQJ7LQf/WVKhH5o9cTpv+Ht29cowes2gFHHOJ5Z/
FDJGaWZFiFbNt6ogh5tqIVh3rNjKidtb9gxHVKj+KCS0KK+2DAJDtfh9UmjjLUBs
aK6dTWTm5qEIHme+EUsQuuCaIZDXDQy+WDE/gt/5h5Yx+8H25lx6+bJZq390tIK6
GOhf6S7zmh5f9HQjBH9WqCg4GBlStmZrPqfR9tNjQBYoRqWX6wQEH4tHE9af//vt
YSVcyGAAR7tmV+b1Un+fJ0CD3vD3iVI0zMGCkMF3DZR/J7XKMYvToBRLyuKZ7G15
zG/i92xETQV2BxEcg2WbdY4JP2IDXVO8VAe0gBAQUcGo2xQEoLIJAw==
=4qIO
-----END PGP SIGNATURE-----

From kent@bbn.com Mon Jun  4 10:29:50 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l54ETotm014684
	for ; Mon, 4 Jun 2007 10:29:50 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l54ETbtk025731
	for ; Mon, 4 Jun 2007 10:29:38 -0400 (EDT)
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80])
	by mit.edu (Spam Firewall) with ESMTP id 36EA431634D
	for ; Mon,  4 Jun 2007 10:29:37 -0400 (EDT)
Received: from dhcp89-089-071.bbn.com ([128.89.89.71])
	by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from )
	id 1HvDYu-0004o2-3k; Mon, 04 Jun 2007 10:29:36 -0400
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <20070601194105.125B73F472@pecan.tislabs.com>
References: <20070601194105.125B73F472@pecan.tislabs.com>
Date: Mon, 4 Jun 2007 10:09:43 -0400
To: sandy@tislabs.com (Sandy Murphy)
From: Stephen Kent 
Content-Type: multipart/alternative;
	boundary="============_-1031155114==_ma============"
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, mikraus@cisco.com
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Mon, 04 Jun 2007 14:29:50 -0000

--============_-1031155114==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 3:41 PM -0400 6/1/07, Sandy Murphy wrote:
>  >But, the real question is whether
>>most traffic would benefit significantly from use of either AH or
>>ESP-NULL, vs. ESP, since most traffic that merits layer 3 crypto
>>protection probably requires confidentiality, as well as integrity
>>and authentication.
>
>In this particular discussion, we are talking about the protection
>of OSPF with IPsec.  There have been some that have spoken for the
>need for confidentiality protection in routing protocols, but they
>haven't been the majority.  And even those who do see the need for
>confidentiality have not been talking about intra-domain routing,
>IIRC.
>
>Not disagreeing with your comment in general, just keeping the
>focus on this question.
>
>--Sandy

We were talking about use of IPsec with OSPF. The message from 
Michael about Cisco's position on use of ESP-NULL vs. AH was not 
qualified by that context, hence my response was also more generic.

Steve
--============_-1031155114==_ma============
Content-Type: text/html; charset="us-ascii"


Re: [saag] AH & OSPF

At 3:41 PM -0400 6/1/07, Sandy Murphy wrote:


>But, the real question is whether

>most traffic would benefit significantly from use of either AH
or

>ESP-NULL, vs. ESP, since most traffic that merits layer 3
crypto

>protection probably requires confidentiality, as well as
integrity

>and authentication.



In this particular discussion, we are talking about the protection

of OSPF with IPsec.  There have been some that have spoken for
the

need for confidentiality protection in routing protocols, but they

haven't been the majority.  And even those who do see the need
for

confidentiality have not been talking about intra-domain routing,

IIRC.



Not disagreeing with your comment in general, just keeping the

focus on this question.




--Sandy





We were talking about use of IPsec with OSPF. The message
from Michael about Cisco's position on use of ESP-NULL vs. AH was not
qualified by that context, hence my response was also more
generic.





Steve



--============_-1031155114==_ma============--

From hartmans@MIT.EDU Mon Jun 11 20:18:12 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5C0IC3F010754
	for ; Mon, 11 Jun 2007 20:18:12 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5C0IAxo027306
	for ; Mon, 11 Jun 2007 20:18:11 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (m983336d0.tmodns.net
	[208.54.51.152]) by mit.edu (Spam Firewall) with ESMTP id 71EF757E464
	for ; Mon, 11 Jun 2007 20:18:09 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042)
	id 5A646C4013; Mon, 11 Jun 2007 18:25:02 -0400 (EDT)
From: Sam Hartman 
To: ietf-ipsec-failover@vpnc.org
Date: Mon, 11 Jun 2007 18:25:02 -0400
Message-ID: 
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 3.635
X-Spam-Level: *** (3.635)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: [saag] Declining the ifare bof for Chicago
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 12 Jun 2007 00:18:12 -0000



Regretfully, I have chosen to decline to sponsor the ifare bof for
Chicago.

I think there is a lot of interest.  However I don't think we have
come far enough in working with people who disagree with the ifare
proposal or who don't see the value for a productive second BOF.
Remember that if this second BOF doesn't get us the face to face time
we need to get a charter, our options are very limited.  Proposals are
given at most two BOFs.

According to the MIP6 chairs this effort has received little traction
in the MIP6 working group.  In order to use the current problem and
applicability statement you would need to show significant interest
from the MIP6 working group.


Also, there has been rather limited discussion on the BOF list.

I'd be happy to meet with proponents of this work in Chicago and
discuss how we can try and build the necessary support for a second
BOF.

Sam Hartman
Security Area Director


From ldondeti@qualcomm.com Mon Jun 11 21:55:13 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5C1tDG9025293
	for ; Mon, 11 Jun 2007 21:55:13 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5C1tAOH010625
	for ; Mon, 11 Jun 2007 21:55:10 -0400 (EDT)
Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP
	id 8A6E762CE85; Mon, 11 Jun 2007 21:55:09 -0400 (EDT)
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l5C1t78l026599
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 11 Jun 2007 18:55:08 -0700
Received: from [129.46.78.141] (ldondeti.na.qualcomm.com [129.46.78.141])
	by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l5C1t7GP006994
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 11 Jun 2007 18:55:07 -0700 (PDT)
Message-ID: <466DFCF8.8070305@qualcomm.com>
Date: Mon, 11 Jun 2007 18:55:04 -0700
From: Lakshminath Dondeti 
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Sam Hartman 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.12
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, ietf-ipsec-failover@vpnc.org
Subject: Re: [saag] Declining the ifare bof for Chicago
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 12 Jun 2007 01:55:14 -0000

Sam,

I don't understand your line of reasoning for turning away this work. 
You note that there is a lot of interest, and I know that there has only 
been one person who disagrees with the IFARE proposal (perhaps I* 
members' opinions are afforded special status?).  There was also some 
confusion at the last face to face meeting; some of it was in fact 
clarified at the meeting (e.g., Paging issues were raised by folks who 
thought gateway initiated operation was being proposed -- it was not -- 
and Tero from the audience clarified that it is a non-issue as the 
proposal on the table was only talking about client-initiated operation) 
and quite a bit of it in offline exchanges, I am told.

Given a lot of interest, one objection, and some confusion, what makes 
you draw the conclusion that the second BoF will not be productive?

The MIP6 working group developed the AUTH protocol (do I need to bring 
up the thing about using 128 bit keys with HMAC-SHA-1, which seems to be 
an oversight and not a conscious choice with reasoning) and they think 
it is fine as an alternative to IPsec.  I am surprised consensus in that 
group is the barrier for doing the IFARE work.

Please read the security considerations of
http://tools.ietf.org/html/draft-ietf-mip6-hareliability-01
http://tools.ietf.org/html/draft-ietf-mip6-ha-switch-03

One of them says use 4285 (one of the options listed, perhaps we should 
never mind the applicability statement on that RFC).
The other says add a random number to the ESP sequence number so binding 
updates pass replay verification.

What happens when we are in the mode of saying "it is not really clear 
to us," "we need  to support this work" or "one of the 
I* members does not like it?"  Other standards organizations are forced 
to make choices as they don't have time to wait until whenever the I* 
wants to wake up; often those involve using perhaps the wrong protocols 
(we have as clear cut a case as we are ever going to have here with 4285).

There are many things you could have done if you wanted to help here. 
You might have sent an intent to decline a few weeks ago or better yet, 
you might have posted the next steps after the Prague meeting.

If you really want to help, at least now, please schedule the BoF and 
make suggestions on how to build support for the work (we have more than 
a month before the Chicago meeting).  Otherwise, it might be worthwhile 
to remove the IESG note in 4285.

best regards,
Lakshminath

On 6/11/2007 3:25 PM, Sam Hartman wrote:
> 
> 
> Regretfully, I have chosen to decline to sponsor the ifare bof for
> Chicago.
> 
> I think there is a lot of interest.  However I don't think we have
> come far enough in working with people who disagree with the ifare
> proposal or who don't see the value for a productive second BOF.
> Remember that if this second BOF doesn't get us the face to face time
> we need to get a charter, our options are very limited.  Proposals are
> given at most two BOFs.
> 
> According to the MIP6 chairs this effort has received little traction
> in the MIP6 working group.  In order to use the current problem and
> applicability statement you would need to show significant interest
> from the MIP6 working group.
> 
> 
> Also, there has been rather limited discussion on the BOF list.
> 
> I'd be happy to meet with proponents of this work in Chicago and
> discuss how we can try and build the necessary support for a second
> BOF.
> 
> Sam Hartman
> Security Area Director
> 
> 

From narten@us.ibm.com Tue Jun 12 10:11:19 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5CEBFmR005960
	for ; Tue, 12 Jun 2007 10:11:15 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5CEB4E5009235
	for ; Tue, 12 Jun 2007 10:11:04 -0400 (EDT)
X-ASG-Whitelist: Barracuda Reputation
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP
	id 50A223341DA; Tue, 12 Jun 2007 10:11:04 -0400 (EDT)
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234])
	by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l5CEB2GY017927;
	Tue, 12 Jun 2007 10:11:02 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id
	l5CEB2tF528036; Tue, 12 Jun 2007 10:11:02 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1])
	by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id
	l5CEB13t016529; Tue, 12 Jun 2007 10:11:01 -0400
Received: from cichlid.raleigh.ibm.com (wecm-9-67-189-192.wecm.ibm.com
	[9.67.189.192])
	by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id
	l5CEB0Ya016380
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 12 Jun 2007 10:11:01 -0400
Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1])
	by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id l5CEArEb012556;
	Tue, 12 Jun 2007 10:10:57 -0400
Message-Id: <200706121410.l5CEArEb012556@cichlid.raleigh.ibm.com>
To: Lakshminath Dondeti 
In-reply-to: <466DFCF8.8070305@qualcomm.com> 
References:  <466DFCF8.8070305@qualcomm.com>
Comments: In-reply-to Lakshminath Dondeti 
	message dated "Mon, 11 Jun 2007 18:55:04 -0700."
Date: Tue, 12 Jun 2007 10:10:53 -0400
From: Thomas Narten 
X-Spam-Score: -2.599
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, Sam Hartman ,
	ietf-ipsec-failover@vpnc.org
Subject: Re: [saag] Declining the ifare bof for Chicago
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 12 Jun 2007 14:11:20 -0000

> I don't understand your line of reasoning for turning away this
  work.

Actually, I thought Sam's note was quite clear. And I applaud his
willingness to say no, if the effort isn't ready for another BOF.

Speaking as a former AD, it can be a very tough call to say yes/no to
a BOF. Unfortunately, there is often interest, but interest is most
definitely not enough. There needs to be more than interest. There
needs to be a reasonable chance of a positive, forward-moving
outcome. But in my experience, it is often the case with 2nd BOF
requests that substantative issues have been raised already (on the
list or in a previous BOF), but have not subsequently been adequately
addressed by the BOF proponents. In such cases, another BOF will
more-or-less just rehash what is already known, with no change in the
overall status. It is the AD's job to judge whether that is likely to
happen (in which case "no" is the right answer).

For a second BOF, a real danger with allowing it to go forward is that
it raises false expectations on where things are heading.  There is a
semi-written rule that says "no more than 2 BOFs". Thus, the second
BOF needs to lead to a WG or an end of the effort. Once the second BOF
has happened, there is (too often) an expectation that a WG will be
formed.

> You note that there is a lot of interest, and I know that there has only 
> been one person who disagrees with the IFARE proposal (perhaps I* 
> members' opinions are afforded special status?).

Yes, I* opinions are afforded special status. They are our chosen
leadership, and with leadership comes responsibility. Responsibility
to be sure that if the work goes forward, it is well scoped, has a
reasonable likelyhood of success, etc. And please remember, the IETF
is a meritocracy. So please don't raise the "I* has special status"
issue as if it were some kind of unfair or biased way of doing things.

> If you really want to help, at least now, please schedule the BoF and 
> make suggestions on how to build support for the work (we have more than 
> a month before the Chicago meeting).  Otherwise, it might be worthwhile 
> to remove the IESG note in 4285.

I'd suggest you read (or reread) draft-narten-successful-bof-02.txt.

It is the BOF proponent's job to build support for an effort. If they
cannot do so, that (for better or worse) says something about the
importance/interest in the work. And note that "support" means not
just finding those in favor of an effort, but getting those opposed to
the effort (as currently scoped) to be satisfied by rescoping the
effort or addressing their concerns (and again, there is a judgement
here). I.e., there needs to be a sufficient degree of consensus on
having the work go forward (with an agreed upon scope, etc.).

Thomas

From hartmans@MIT.EDU Tue Jun 12 10:53:03 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5CEr3Wa017514
	for ; Tue, 12 Jun 2007 10:53:03 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5CEqpo5003143
	for ; Tue, 12 Jun 2007 10:52:51 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (m1f1ffa48.tmodns.net
	[72.250.31.31]) by mit.edu (Spam Firewall) with ESMTP id 8402F575A59
	for ; Tue, 12 Jun 2007 10:52:47 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042)
	id C859848D6; Tue, 12 Jun 2007 09:53:07 -0400 (EDT)
From: Sam Hartman 
To: Lakshminath Dondeti 
References:  <466DFCF8.8070305@qualcomm.com>
Date: Tue, 12 Jun 2007 09:53:07 -0400
In-Reply-To: <466DFCF8.8070305@qualcomm.com> (Lakshminath Dondeti's message of
	"Mon, 11 Jun 2007 18:55:04 -0700")
Message-ID: 
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, ietf-ipsec-failover@vpnc.org
Subject: Re: [saag] Declining the ifare bof for Chicago
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 12 Jun 2007 14:53:03 -0000

>>>>> "Lakshminath" == Lakshminath Dondeti  writes:

    Lakshminath> Sam, I don't understand your line of reasoning for
    Lakshminath> turning away this work. You note that there is a lot
    Lakshminath> of interest, and I know that there has only been one
    Lakshminath> person who disagrees with the IFARE proposal (perhaps
    Lakshminath> I* members' opinions are afforded special status?).
I don't think that claiming ekr is the only one who disagreed is a
fair characterization of the bof.

    Lakshminath> There was also some confusion at the last face to
    Lakshminath> face meeting; some of it was in fact clarified at the
    Lakshminath> meeting (e.g., Paging issues were raised by folks who
    Lakshminath> thought gateway initiated operation was being
    Lakshminath> proposed -- it was not -- and Tero from the audience
    Lakshminath> clarified that it is a non-issue as the proposal on
    Lakshminath> the table was only talking about client-initiated
    Lakshminath> operation) and quite a bit of it in offline
    Lakshminath> exchanges, I am told.

I don't think this confusion has been cleared up.
Traffic on the bof list after the meeting brought up the paging issue again.

There is a huge difference between asserting a solution to someone's
objection and actually coming to closure with them.  I believe that
the proponents of the BOF have done the former and in some cases
claimed the ladder.  I understand your frustration; several of the
people you have tried to engage have not found the work compelling
enough to engage with you.

    Lakshminath> Given a lot of interest, one objection, and some
    Lakshminath> confusion, what makes you draw the conclusion that
    Lakshminath> the second BoF will not be productive?

Your problem statement hinges heavily on the use of the technology for
MIP.  However you have not convinced the working group that they are
interested in your proposal.  I think that you must either come up
with a compelling problem statement that does not discuss MIP or get
them on board.

I understand that you may have concerns about their current approach.
You should feel free to bring those concerns forward in the MIP6
working group.  Alternatively you can bring those concerns up with Tim
or I or Jari.


    Lakshminath> What happens when we are in the mode of saying "it is
    Lakshminath> not really clear to us," "we need 
    Lakshminath> to support this work" or "one of the I* members does
    Lakshminath> not like it?"  Other standards organizations are
    Lakshminath> forced to make choices as they don't have time to
    Lakshminath> wait until whenever the I* wants to wake up; often
    Lakshminath> those involve using perhaps the wrong protocols (we
    Lakshminath> have as clear cut a case as we are ever going to have
    Lakshminath> here with 4285).

The IETF operates by consensus.  The IESG and IAB cannot force the
MIP6 working group to adopt a particular solution.  We can block
solutions with certain classes of problem under some circumstances.
We do have significant latitude in whether to charter work and I
believe it entirely reasonable for me to insist that when a problem
statement points to a consumer in the IETF, that consumer be
interested in the solution.

    Lakshminath> There are many things you could have done if you
    Lakshminath> wanted to help here. You might have sent an intent to
    Lakshminath> decline a few weeks ago

I did send a rather late message to the BOF chairs indicating that I
had serous concerns.

You are correct that I have been rather busy lately and that I could
have done a much better job.


    Lakshminath>  or better yet, you might have
    Lakshminath> posted the next steps after the Prague meeting.

I did talk to the chairs about next steps.  You are correct that
making sure that conversation got summarized to the list would have
been a good idea.


From aboba@internaut.com Tue Jun 12 12:52:58 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5CGqw1u011782
	for ; Tue, 12 Jun 2007 12:52:58 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5CGqud8017247
	for ; Tue, 12 Jun 2007 12:52:56 -0400 (EDT)
Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP
	id EA4BE33BA19; Tue, 12 Jun 2007 12:52:55 -0400 (EDT)
Received: from c-24-16-66-58.hsd1.mn.comcast.net ([24.16.66.58]
	helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.63)
	(envelope-from )
	id 1Hy9bz-000GPD-2E; Tue, 12 Jun 2007 12:52:55 -0400
Received: by internaut.com (Postfix, from userid 1000)
	id 02A257099A; Tue, 12 Jun 2007 09:52:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by internaut.com (Postfix) with ESMTP id E6B941A689;
	Tue, 12 Jun 2007 09:52:53 -0700 (PDT)
X-MHO-User: U2FsdGVkX194KUz8SMI+AJh5iyudXVZc
X-MHO-User: U2FsdGVkX18V022VWQrdtpzeIIdTnwu/
X-MHO-User: U2FsdGVkX19aY9hIJ37ZdjwrUHSXpSIg
X-MHO-User: U2FsdGVkX1/2DGw1tJLrwotX8vuJr59Z
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 24.16.66.58
X-Report-Abuse-To: abuse@dyndns.com (see
	http://www.mailhop.org/outbound/abuse.html for abuse reporting
	information)
X-MHO-User: U2FsdGVkX190NMSleEWFm+xoewOmPzlh
Date: Tue, 12 Jun 2007 09:52:53 -0700 (PDT)
From: Bernard Aboba 
To: Thomas Narten 
In-Reply-To: <200706121410.l5CEArEb012556@cichlid.raleigh.ibm.com>
Message-ID: 
References:  <466DFCF8.8070305@qualcomm.com>
	<200706121410.l5CEArEb012556@cichlid.raleigh.ibm.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.12
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, Sam Hartman ,
	Lakshminath Dondeti , ietf-ipsec-failover@vpnc.org
Subject: Re: [saag] Declining the ifare bof for Chicago
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 12 Jun 2007 16:52:58 -0000

If we are going to have a more general discussion of the BOF process, I'd 
suggest that this would be better accomodated on the IETF list. 

On Tue, 12 Jun 2007, Thomas Narten wrote:

> > I don't understand your line of reasoning for turning away this
>   work.
> 
> Actually, I thought Sam's note was quite clear. And I applaud his
> willingness to say no, if the effort isn't ready for another BOF.
> 
> Speaking as a former AD, it can be a very tough call to say yes/no to
> a BOF. Unfortunately, there is often interest, but interest is most
> definitely not enough. There needs to be more than interest. There
> needs to be a reasonable chance of a positive, forward-moving
> outcome. But in my experience, it is often the case with 2nd BOF
> requests that substantative issues have been raised already (on the
> list or in a previous BOF), but have not subsequently been adequately
> addressed by the BOF proponents. In such cases, another BOF will
> more-or-less just rehash what is already known, with no change in the
> overall status. It is the AD's job to judge whether that is likely to
> happen (in which case "no" is the right answer).
> 
> For a second BOF, a real danger with allowing it to go forward is that
> it raises false expectations on where things are heading.  There is a
> semi-written rule that says "no more than 2 BOFs". Thus, the second
> BOF needs to lead to a WG or an end of the effort. Once the second BOF
> has happened, there is (too often) an expectation that a WG will be
> formed.
> 
> > You note that there is a lot of interest, and I know that there has only 
> > been one person who disagrees with the IFARE proposal (perhaps I* 
> > members' opinions are afforded special status?).
> 
> Yes, I* opinions are afforded special status. They are our chosen
> leadership, and with leadership comes responsibility. Responsibility
> to be sure that if the work goes forward, it is well scoped, has a
> reasonable likelyhood of success, etc. And please remember, the IETF
> is a meritocracy. So please don't raise the "I* has special status"
> issue as if it were some kind of unfair or biased way of doing things.
> 
> > If you really want to help, at least now, please schedule the BoF and 
> > make suggestions on how to build support for the work (we have more than 
> > a month before the Chicago meeting).  Otherwise, it might be worthwhile 
> > to remove the IESG note in 4285.
> 
> I'd suggest you read (or reread) draft-narten-successful-bof-02.txt.
> 
> It is the BOF proponent's job to build support for an effort. If they
> cannot do so, that (for better or worse) says something about the
> importance/interest in the work. And note that "support" means not
> just finding those in favor of an effort, but getting those opposed to
> the effort (as currently scoped) to be satisfied by rescoping the
> effort or addressing their concerns (and again, there is a judgement
> here). I.e., there needs to be a sufficient degree of consensus on
> having the work go forward (with an agreed upon scope, etc.).
> 
> Thomas
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://mailman.mit.edu/mailman/listinfo/saag
> 

From paul.hoffman@vpnc.org Tue Jun 12 13:55:59 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5CHtwhi012036
	for ; Tue, 12 Jun 2007 13:55:58 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5CHtuks013912
	for ; Tue, 12 Jun 2007 13:55:57 -0400 (EDT)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP
	id 63A6933545F; Tue, 12 Jun 2007 13:55:52 -0400 (EDT)
Received: from [10.20.30.108] (adsl-66-125-125-65.dsl.pltn13.pacbell.net
	[66.125.125.65]) (authenticated bits=0)
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5CHtjiT041458
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 12 Jun 2007 10:55:46 -0700 (MST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:  <466DFCF8.8070305@qualcomm.com>
	<200706121410.l5CEArEb012556@cichlid.raleigh.ibm.com>
	
Date: Tue, 12 Jun 2007 10:55:41 -0700
To: Bernard Aboba , Thomas Narten 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, Sam Hartman ,
	Lakshminath Dondeti , ietf-ipsec-failover@vpnc.org
Subject: Re: [saag] Declining the ifare bof for Chicago
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 12 Jun 2007 17:55:59 -0000

At 9:52 AM -0700 6/12/07, Bernard Aboba wrote:
>If we are going to have a more general discussion of the BOF process, I'd
>suggest that this would be better accomodated on the IETF list.

Yes, please. It would be good to keep using this list for the 
technical work that no longer has a BoF behind it but can hopefully 
still be discussed.

--Paul Hoffman, Director
--VPN Consortium

From paul.hoffman@vpnc.org Tue Jun 12 13:57:59 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5CHvwbC013003
	for ; Tue, 12 Jun 2007 13:57:58 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5CHvvUu025649
	for ; Tue, 12 Jun 2007 13:57:57 -0400 (EDT)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 77A1E572F9B
	for ; Tue, 12 Jun 2007 13:57:52 -0400 (EDT)
Received: from [10.20.30.108] (adsl-66-125-125-65.dsl.pltn13.pacbell.net
	[66.125.125.65]) (authenticated bits=0)
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5CHvoXm041562
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Tue, 12 Jun 2007 10:57:51 -0700 (MST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
Date: Tue, 12 Jun 2007 10:57:46 -0700
To: saag@mit.edu
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: Re: [saag] Declining the ifare bof for Chicago
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 12 Jun 2007 17:57:59 -0000

[[ Sorry, I meant to remove SAAG from the response. I want the 
ietf-ipsec-failover list to be able to continue to talk about the 
topic, not SAAG. ]]

At 9:52 AM -0700 6/12/07, Bernard Aboba wrote:
>If we are going to have a more general discussion of the BOF process, I'd
>suggest that this would be better accomodated on the IETF list.

Yes, please. It would be good to keep using this list for the 
technical work that no longer has a BoF behind it but can hopefully 
still be discussed.

--Paul Hoffman, Director
--VPN Consortium

From hartmans@MIT.EDU Tue Jun 12 14:03:22 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5CI3MMT015982
	for ; Tue, 12 Jun 2007 14:03:22 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5CI3Kho004530
	for ; Tue, 12 Jun 2007 14:03:20 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (unknown [192.42.249.122])
	by mit.edu (Spam Firewall) with ESMTP id EAE3A560EC5
	for ; Tue, 12 Jun 2007 14:03:19 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042)
	id 46AF048CE; Tue, 12 Jun 2007 14:03:19 -0400 (EDT)
From: Sam Hartman 
To: Paul Hoffman 
References:  <466DFCF8.8070305@qualcomm.com>
	<200706121410.l5CEArEb012556@cichlid.raleigh.ibm.com>
	
	
Date: Tue, 12 Jun 2007 14:03:19 -0400
In-Reply-To:  (Paul Hoffman's message of
	"Tue, 12 Jun 2007 10:55:41 -0700")
Message-ID: 
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: Thomas Narten , saag@mit.edu,
	ietf-ipsec-failover@vpnc.org, Lakshminath Dondeti ,
	Bernard Aboba 
Subject: Re: [saag] Declining the ifare bof for Chicago
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 12 Jun 2007 18:03:22 -0000

>>>>> "Paul" == Paul Hoffman  writes:

    Paul> At 9:52 AM -0700 6/12/07, Bernard Aboba wrote:
    >> If we are going to have a more general discussion of the BOF
    >> process, I'd suggest that this would be better accomodated on
    >> the IETF list.

    Paul> Yes, please. It would be good to keep using this list for
    Paul> the technical work that no longer has a BoF behind it but
    Paul> can hopefully still be discussed.

To clarify, I said that I was not approving a BOF for chicago.

I would be delighted if we get to a point where I can approve a BOF
for a future IETF.


From dvijay@gmail.com Tue Jun 12 16:25:49 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5CKPn1u027077
	for ; Tue, 12 Jun 2007 16:25:49 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5CKPlaG023038
	for ; Tue, 12 Jun 2007 16:25:47 -0400 (EDT)
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176])
	by mit.edu (Spam Firewall) with ESMTP id 3354E6207F2
	for ; Tue, 12 Jun 2007 16:25:47 -0400 (EDT)
Received: by wa-out-1112.google.com with SMTP id m16so2810396waf
	for ; Tue, 12 Jun 2007 13:25:46 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=sdxFVlyiOBErhIqOig6Q057LzyrStM56HwPMVV9cDGFCLNpkf3a19/3GvBkrmSp0L8bc2aApjXtjVCsqWqAyUo6c4yhs+lf1n2rGEmF2GZpkyKVPIg01JAgvaPgXOuufWBTB+zSGxhJWZmbwL7BTxjtH5+94Lr1hSQ9citIBQVM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=oOsyxmmyr+0tvZkc9N52fNJ2OLis2dYXt2I4cCXKJvrIejleBOOcQgPKASVEpVal3O3hWB1Ye4x28kN2vysPsFHxQkLpp1i9z/rSfZd24C565pwgy2q36zhLHbwEouv0W3EVuLbNADOfm1bNj4aHmDL2rcwqbuBS4hamH4RKcC4=
Received: by 10.114.149.2 with SMTP id w2mr7085040wad.1181679946832;
	Tue, 12 Jun 2007 13:25:46 -0700 (PDT)
Received: by 10.115.59.10 with HTTP; Tue, 12 Jun 2007 13:25:46 -0700 (PDT)
Message-ID: 
Date: Tue, 12 Jun 2007 13:25:46 -0700
From: "Vijay Devarapallli" 
To: "Lakshminath Dondeti" 
In-Reply-To: <466DFCF8.8070305@qualcomm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References:  <466DFCF8.8070305@qualcomm.com>
X-Spam-Score: 0
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, Sam Hartman ,
	ietf-ipsec-failover@vpnc.org
Subject: Re: [saag] Declining the ifare bof for Chicago
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 12 Jun 2007 20:25:49 -0000

Lakshminath,

On 6/11/07, Lakshminath Dondeti  wrote:

> The MIP6 working group developed the AUTH protocol (do I need to bring
> up the thing about using 128 bit keys with HMAC-SHA-1, which seems to be
> an oversight and not a conscious choice with reasoning) and they think
> it is fine as an alternative to IPsec.  I am surprised consensus in that
> group is the barrier for doing the IFARE work.

This is a mischaracterization of the security work done in the MIP6
WG. The AUTH protocol for MIPv6 (RFC 4285) was done as an
Informational document for one particular SDO (3GPP2). The default
mechanism is the use of IKEv2 to negotiate security associations
between the mobile node and the home agent and the use of ESP to
protect the signaling messages. The MIP6 WG has worked on more
extensions for bootstrapping security associations between the mobile
node and the home agent and all of them have assumed IPsec. Not RFC
4285.

If you have any specific concerns please bring them up on the MIP6 mailing list.

Vijay

From ldondeti@qualcomm.com Tue Jun 12 16:48:54 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5CKmsCQ006447
	for ; Tue, 12 Jun 2007 16:48:54 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5CKmpNp021769
	for ; Tue, 12 Jun 2007 16:48:52 -0400 (EDT)
Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP
	id 905D257C906; Tue, 12 Jun 2007 16:48:50 -0400 (EDT)
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l5CKmmOl014773
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 12 Jun 2007 13:48:48 -0700
Received: from [129.46.78.141] (ldondeti.na.qualcomm.com [129.46.78.141])
	by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l5CKmlnQ025749
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 12 Jun 2007 13:48:47 -0700 (PDT)
Message-ID: <466F06AD.1050505@qualcomm.com>
Date: Tue, 12 Jun 2007 13:48:45 -0700
From: Lakshminath Dondeti 
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Vijay Devarapallli 
References:  <466DFCF8.8070305@qualcomm.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, Sam Hartman ,
	ietf-ipsec-failover@vpnc.org
Subject: Re: [saag] Declining the ifare bof for Chicago
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 12 Jun 2007 20:48:54 -0000

Vijay,

I was not saying it without reason.  I brought up the 128-bit key issue 
a long while ago and there was silence.

More recently, draft-ietf-mip6-ha-switch-03 on which you are an author, 
says the following

++++++++++++
9. Security Considerations


    The Home Agent Switch message MUST be authenticated by one of the
    following methods:

         o The home agent to mobile node IPsec ESP authentication SA for
           integrity protection as described in [2].

         o A home agent to mobile node authentication option, such as
           [3].
+++++++++

Those two options are listed as equivalent choices.

So, how am I wrong?

regards,
Lakshminath

On 6/12/2007 1:25 PM, Vijay Devarapallli wrote:
> Lakshminath,
> 
> On 6/11/07, Lakshminath Dondeti  wrote:
> 
>> The MIP6 working group developed the AUTH protocol (do I need to bring
>> up the thing about using 128 bit keys with HMAC-SHA-1, which seems to be
>> an oversight and not a conscious choice with reasoning) and they think
>> it is fine as an alternative to IPsec.  I am surprised consensus in that
>> group is the barrier for doing the IFARE work.
> 
> This is a mischaracterization of the security work done in the MIP6
> WG. The AUTH protocol for MIPv6 (RFC 4285) was done as an
> Informational document for one particular SDO (3GPP2). The default
> mechanism is the use of IKEv2 to negotiate security associations
> between the mobile node and the home agent and the use of ESP to
> protect the signaling messages. The MIP6 WG has worked on more
> extensions for bootstrapping security associations between the mobile
> node and the home agent and all of them have assumed IPsec. Not RFC
> 4285.
> 
> If you have any specific concerns please bring them up on the MIP6 
> mailing list.
> 
> Vijay
> 

From ldondeti@qualcomm.com Tue Jun 12 16:56:43 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5CKugc0010263
	for ; Tue, 12 Jun 2007 16:56:42 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5CKue6X013257
	for ; Tue, 12 Jun 2007 16:56:41 -0400 (EDT)
Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP
	id A415532878D; Tue, 12 Jun 2007 16:56:39 -0400 (EDT)
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l5CKucT6024926
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 12 Jun 2007 13:56:38 -0700
Received: from [129.46.78.141] (ldondeti.na.qualcomm.com [129.46.78.141])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l5CKubDN026238
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 12 Jun 2007 13:56:37 -0700
Message-ID: <466F0883.6010306@qualcomm.com>
Date: Tue, 12 Jun 2007 13:56:35 -0700
From: Lakshminath Dondeti 
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Sam Hartman 
References:  <466DFCF8.8070305@qualcomm.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, ietf-ipsec-failover@vpnc.org
Subject: Re: [saag] Declining the ifare bof for Chicago
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 12 Jun 2007 20:56:43 -0000

Sam,

I appreciate your notes that you could have alerted the group earlier.
Thank you.

Furthermore, I can appreciate your viewpoint better.  In fact, I have
had some offline discussions where people were indeed supportive of the
work.  For whatever reason, they seem to be not sharing those opinions
here on the list.  Perhaps there has been the notion that this BoF was
going to happen and we can discuss in Chicago.  We have become somewhat
of a meeting based organization unfortunately.

On the nature of opposition, I am simply saying that a vast majority of
the discussions from my perspective were about scoping and
applicability.  Those discussions in my view can settle if we have
another BoF; face to face meetings seem to help us come together in that
way.

On the paging issue, it is very simple.  If the network-side/gateway
needs to initiate, paging the mobile is needed for any data to be sent
anyway and if the mobile-side/client initiates failover, paging is not
an issue.  Either people understand that one sentence or they don't.
There is very little I can do to explain that any better.

On MIP6 and AUTH protocol, it is up to you.  It looks like soon enough I
may be advising people to use that in the network design, so I might
have to become a supporter of that protocol.

I appreciate your offer that offline discussions in Chicago may
potentially lead to another BoF on this topic.  The problem is that
other standards organizations waiting for this work to be chartered
soon.  I was of the impression that the right way to approach this
problem is to generalize the problem space and develop an IETF consensus
solution.  I simply did not expect it to be this slow and in fact that
may lead to losing one of the customers for the work.

In any event, many thanks for all your support so far.

best regards,
Lakshminath

On 6/12/2007 6:53 AM, Sam Hartman wrote:
>>>>>> "Lakshminath" == Lakshminath Dondeti 
>>>>>>  writes:
> 
> Lakshminath> Sam, I don't understand your line of reasoning for 
> Lakshminath> turning away this work. You note that there is a lot 
> Lakshminath> of interest, and I know that there has only been one 
> Lakshminath> person who disagrees with the IFARE proposal (perhaps 
> Lakshminath> I* members' opinions are afforded special status?). I 
> don't think that claiming ekr is the only one who disagreed is a fair
>  characterization of the bof.
> 
> Lakshminath> There was also some confusion at the last face to 
> Lakshminath> face meeting; some of it was in fact clarified at the 
> Lakshminath> meeting (e.g., Paging issues were raised by folks who 
> Lakshminath> thought gateway initiated operation was being 
> Lakshminath> proposed -- it was not -- and Tero from the audience 
> Lakshminath> clarified that it is a non-issue as the proposal on 
> Lakshminath> the table was only talking about client-initiated 
> Lakshminath> operation) and quite a bit of it in offline Lakshminath>
>  exchanges, I am told.
> 
> I don't think this confusion has been cleared up. Traffic on the bof
>  list after the meeting brought up the paging issue again.
> 
> There is a huge difference between asserting a solution to someone's 
> objection and actually coming to closure with them.  I believe that 
> the proponents of the BOF have done the former and in some cases 
> claimed the ladder.  I understand your frustration; several of the 
> people you have tried to engage have not found the work compelling 
> enough to engage with you.
> 
> Lakshminath> Given a lot of interest, one objection, and some 
> Lakshminath> confusion, what makes you draw the conclusion that 
> Lakshminath> the second BoF will not be productive?
> 
> Your problem statement hinges heavily on the use of the technology 
> for MIP.  However you have not convinced the working group that they
>  are interested in your proposal.  I think that you must either come
>  up with a compelling problem statement that does not discuss MIP or
>  get them on board.
> 
> I understand that you may have concerns about their current approach.
>  You should feel free to bring those concerns forward in the MIP6 
> working group.  Alternatively you can bring those concerns up with 
> Tim or I or Jari.
> 
> 
> Lakshminath> What happens when we are in the mode of saying "it is 
> Lakshminath> not really clear to us," "we need  
> Lakshminath> to support this work" or "one of the I* members does 
> Lakshminath> not like it?"  Other standards organizations are 
> Lakshminath> forced to make choices as they don't have time to 
> Lakshminath> wait until whenever the I* wants to wake up; often 
> Lakshminath> those involve using perhaps the wrong protocols (we 
> Lakshminath> have as clear cut a case as we are ever going to have 
> Lakshminath> here with 4285).
> 
> The IETF operates by consensus.  The IESG and IAB cannot force the 
> MIP6 working group to adopt a particular solution.  We can block 
> solutions with certain classes of problem under some circumstances. 
> We do have significant latitude in whether to charter work and I 
> believe it entirely reasonable for me to insist that when a problem 
> statement points to a consumer in the IETF, that consumer be 
> interested in the solution.
> 
> Lakshminath> There are many things you could have done if you 
> Lakshminath> wanted to help here. You might have sent an intent to 
> Lakshminath> decline a few weeks ago
> 
> I did send a rather late message to the BOF chairs indicating that I 
> had serous concerns.
> 
> You are correct that I have been rather busy lately and that I could 
> have done a much better job.
> 
> 
> Lakshminath>  or better yet, you might have Lakshminath> posted the 
> next steps after the Prague meeting.
> 
> I did talk to the chairs about next steps.  You are correct that 
> making sure that conversation got summarized to the list would have 
> been a good idea.
> 
> 


From Vijay.Devarapalli@AzaireNet.com Tue Jun 12 17:09:06 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5CL96bg016932
	for ; Tue, 12 Jun 2007 17:09:06 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5CL95nE027494
	for ; Tue, 12 Jun 2007 17:09:05 -0400 (EDT)
Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6])
	by mit.edu (Spam Firewall) with ESMTP
	id 61E733135DE; Tue, 12 Jun 2007 17:09:04 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-15"
Date: Tue, 12 Jun 2007 14:09:02 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [saag] Declining the ifare bof for Chicago
thread-index: AcetMyTKK2gePa0HRnG2Lt5xZxWlvAAAR2Kw
References:  <466DFCF8.8070305@qualcomm.com>
	
	<466F06AD.1050505@qualcomm.com>
From: "Vijay Devarapalli" 
To: "Lakshminath Dondeti" ,
	"Vijay Devarapallli" 
X-Spam-Score: 0.60
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id
	l5CL96bg016932
Cc: saag@mit.edu, Sam Hartman ,
	ietf-ipsec-failover@vpnc.org
Subject: Re: [saag] Declining the ifare bof for Chicago
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 12 Jun 2007 21:09:07 -0000

> I was not saying it without reason.  I brought up the 128-bit 
> key issue 
> a long while ago and there was silence.

This was supposed to be fixed in 4285bis, but there hasn't been
much interest in revising 4285 so far.

> More recently, draft-ietf-mip6-ha-switch-03 on which you are 
> an author, 
> says the following
> 
> ++++++++++++
> 9. Security Considerations
> 
> 
>     The Home Agent Switch message MUST be authenticated by one of the
>     following methods:
> 
>          o The home agent to mobile node IPsec ESP 
> authentication SA for
>            integrity protection as described in [2].
> 
>          o A home agent to mobile node authentication option, such as
>            [3].
> +++++++++
> 
> Those two options are listed as equivalent choices.

It says nothing about whether the two choices are equivalent. 

If you want to, we can discuss this on the MIP6 mailing list. This
is not really relevant to the IFARE BOF discussion.

Vijay 

> 
> So, how am I wrong?
> 
> regards,
> Lakshminath
> 
> On 6/12/2007 1:25 PM, Vijay Devarapallli wrote:
> > Lakshminath,
> > 
> > On 6/11/07, Lakshminath Dondeti  wrote:
> > 
> >> The MIP6 working group developed the AUTH protocol (do I 
> need to bring
> >> up the thing about using 128 bit keys with HMAC-SHA-1, 
> which seems to be
> >> an oversight and not a conscious choice with reasoning) 
> and they think
> >> it is fine as an alternative to IPsec.  I am surprised 
> consensus in that
> >> group is the barrier for doing the IFARE work.
> > 
> > This is a mischaracterization of the security work done in the MIP6
> > WG. The AUTH protocol for MIPv6 (RFC 4285) was done as an
> > Informational document for one particular SDO (3GPP2). The default
> > mechanism is the use of IKEv2 to negotiate security associations
> > between the mobile node and the home agent and the use of ESP to
> > protect the signaling messages. The MIP6 WG has worked on more
> > extensions for bootstrapping security associations between 
> the mobile
> > node and the home agent and all of them have assumed IPsec. Not RFC
> > 4285.
> > 
> > If you have any specific concerns please bring them up on the MIP6 
> > mailing list.
> > 
> > Vijay
> > 
> 
> 


From yaronf@checkpoint.com Tue Jun 12 17:10:33 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5CLAXeW017720
	for ; Tue, 12 Jun 2007 17:10:33 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5CLAVKH018839
	for ; Tue, 12 Jun 2007 17:10:31 -0400 (EDT)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68])
	by mit.edu (Spam Firewall) with ESMTP
	id CCF4C322996; Tue, 12 Jun 2007 17:10:29 -0400 (EDT)
Received: from [172.31.21.179] (localhost [127.0.0.1])
	by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id
	l5CLAPW7017516; Wed, 13 Jun 2007 00:10:27 +0300 (IDT)
Message-ID: <466F0BC1.306@checkpoint.com>
Date: Wed, 13 Jun 2007 00:10:25 +0300
From: Yaron Sheffer 
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Sam Hartman 
References: 
In-Reply-To: 
Content-Type: multipart/alternative;
	boundary="------------060507070103000300020304"
X-Spam-Score: 4.089
X-Spam-Level: **** (4.089)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, ietf-ipsec-failover@vpnc.org
Subject: Re: [saag] Declining the ifare bof for Chicago
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 12 Jun 2007 21:10:33 -0000

This is a multi-part message in MIME format.
--------------060507070103000300020304
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Sam,


the IPsec failover work originated with the IPsec VPN community. There 
is massive industry support behind the current problem statement, as 
witness the list of contributors on 
http://www.ietf.org/internet-drafts/draft-vidya-ipsec-failover-ps-02.txt.


With all due respect to the MIP6 activities, the need for this solution 
in the IPsec space exists today, whereas there are at best few large 
scale deployments of MIP6. So it makes little sense to block this 
activity, or even delay it by 4 months, because of the lack of interest 
in the MIP6 community. I do realize MIP6 is a big chunk of the 
problem/applicability statement, and we certainly need to solicit their 
support.  But just as Lakshminath noted that SDOs are awaiting this 
solution, there are actual deployment architectures that can benefit 
from it today.


Best regards,


    Yaron



Sam Hartman wrote:

>
> Regretfully, I have chosen to decline to sponsor the ifare bof for
> Chicago.
>
> I think there is a lot of interest.  However I don't think we have
> come far enough in working with people who disagree with the ifare
> proposal or who don't see the value for a productive second BOF.
> Remember that if this second BOF doesn't get us the face to face time
> we need to get a charter, our options are very limited.  Proposals are
> given at most two BOFs.
>
> According to the MIP6 chairs this effort has received little traction
> in the MIP6 working group.  In order to use the current problem and
> applicability statement you would need to show significant interest
> from the MIP6 working group.
>
>
> Also, there has been rather limited discussion on the BOF list.
>
> I'd be happy to meet with proponents of this work in Chicago and
> discuss how we can try and build the necessary support for a second
> BOF.
>
> Sam Hartman
> Security Area Director
>
>
>   

--------------060507070103000300020304
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  
  



Hi Sam,







the IPsec failover work
originated with the IPsec VPN community. There is massive industry
support behind the current problem statement, as witness the list of
contributors on http://www.ietf.org/internet-drafts/draft-vidya-ipsec-failover-ps-02.txt.







With all due respect to
the MIP6 activities, the need for this solution in the IPsec space
exists today, whereas there are at best few large scale deployments of
MIP6. So it makes little sense to block this activity, or even delay it
by 4 months, because of the lack of interest in the MIP6 community. I
do realize MIP6 is a big chunk of the problem/applicability statement,
and we certainly need to solicit their support.  But just as
Lakshminath noted that SDOs are awaiting this solution, there are
actual deployment architectures that can benefit from it today. 









Best regards,






    Yaron





Sam Hartman wrote:





  

Regretfully, I have chosen to decline to sponsor the ifare bof for
Chicago.

I think there is a lot of interest.  However I don't think we have
come far enough in working with people who disagree with the ifare
proposal or who don't see the value for a productive second BOF.
Remember that if this second BOF doesn't get us the face to face time
we need to get a charter, our options are very limited.  Proposals are
given at most two BOFs.

According to the MIP6 chairs this effort has received little traction
in the MIP6 working group.  In order to use the current problem and
applicability statement you would need to show significant interest
from the MIP6 working group.


Also, there has been rather limited discussion on the BOF list.

I'd be happy to meet with proponents of this work in Chicago and
discuss how we can try and build the necessary support for a second
BOF.

Sam Hartman
Security Area Director


  






--------------060507070103000300020304--

From vidyan@qualcomm.com Tue Jun 12 18:03:45 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5CM3jhx011092
	for ; Tue, 12 Jun 2007 18:03:45 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5CM3hpX028592
	for ; Tue, 12 Jun 2007 18:03:43 -0400 (EDT)
Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP
	id C1D046112F8; Tue, 12 Jun 2007 18:03:42 -0400 (EDT)
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l5CM3eqF023276
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 12 Jun 2007 15:03:40 -0700
Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com
	[172.30.36.175])
	by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l5CM3bvr027613; Tue, 12 Jun 2007 15:03:39 -0700
Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by
	sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 12 Jun 2007 15:02:13 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Tue, 12 Jun 2007 15:02:08 -0700
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Declining the ifare bof for Chicago
Thread-Index: Acesh7lpfqEP/xj/Qaywyl6sVZLRUAAp+oBA
References: 
From: "Narayanan, Vidya" 
To: "Sam Hartman" , 
X-OriginalArrivalTime: 12 Jun 2007 22:02:13.0046 (UTC)
	FILETIME=[54C9A560:01C7AD3D]
X-Spam-Score: 0.60
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id
	l5CM3jhx011092
Cc: saag@mit.edu
Subject: Re: [saag] Declining the ifare bof for Chicago
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 12 Jun 2007 22:03:45 -0000

Hi Sam,
I'm sorry to see that none of my offline clarifications have helped the
decision here.  After the IFARE BoF in Prague, I had written a note to
the IESG/IAB describing where I thought we were and what the next steps
were.  The only response I got for that was from Ekr, with whom I had
tried following up since then.  

As I noted in my email therein, I had followed up on my part on the next
steps with several one-on-one discussions with folks from the MIP6
working group who had attended the IFARE BoF and had voiced different
opinions on the problem statement and/or requirements.  As I felt that
the initial follow-up was best done with each person individually to
understand their comments, this is the path I chose and it was very
helpful in revising the problem statement document with their input.
Subsequently, I had sent the document out for review on the MIP6 mailing
list.  But, please note that I had no idea that this was expected to be
discussed on the MIP6 mailing list.  I had, in fact, specifically
requested that folks send reviews and comments to the IFARE mailing list
and not to the MIP6 mailing list.  As to the MIP6 chairs, they did not
attend the IFARE BoF and I did not also speak to them individually on
the IFARE topic.  

As I shared some of the private responses I received with you last week,
several people, either by email or phone conversations, are now much
more inline with the problem statement than in Prague.  I have requested
reviews, but, for some reason, we have not seen those yet.  You had
further asked me about implementation plans from vendors and I don't see
how that can be a criteria for work at the IETF.  We cannot expect
vendors to share their implementation plans with us.  The only thing we
can see is that there is a lot of vendor interest in standardization.  

Unfortunately, this work is already progressing a bit too slowly for it
to be useful in other SDOs.  The topic of MIP6 security is already under
discussion in those SDOs and making a case for IKEv2/IPsec being the
IETF's "recommended" solution for MIP6 security is very difficult
without a session resumption solution being available.  A second BoF in
Vancouver and solutions after that will be effort wasted, because, the
market would have moved on by then.  

I believe it is our responsibility at the IETF to have the solution
defined well, when we say something is the recommended solution.  Saying
that IKEv2/IPsec is recommended for MIP6 without addressing the issues
with latency involved is not helping.  Security is almost always traded
off for latency in practice.  It is one thing to say that if an
alternative low latency solution is infeasible. That is not the case
here.  

I understand your point of view about not having seen much debates on
the mailing list.  I am also hoping that the people who had discussed
with me offline will actually review and post their comments soon, but,
they seem to be busy with other things at the moment.  However, a
face-to-face meeting should definitely bring out whether the offline
discussions have helped convergence or not.  Also, given the nature of
BoFs, several people tend to hold out the discussions for the actual
meeting and that may again be reason to meet.  

Unfortunately, IETF's lack of ability to standardize such solutions
often forces us to consider options of standardizing such solutions in
other SDOs, while the topic clearly belongs much more at the IETF.  I
was hoping this is not another such case, but, it seems to be shaping up
to be exactly that.  

Regards,
Vidya

> -----Original Message-----
> From: owner-ietf-ipsec-failover@mail.vpnc.org 
> [mailto:owner-ietf-ipsec-failover@mail.vpnc.org] On Behalf Of 
> Sam Hartman
> Sent: Monday, June 11, 2007 3:25 PM
> To: ietf-ipsec-failover@vpnc.org
> Cc: saag@mit.edu
> Subject: Declining the ifare bof for Chicago
> 
> 
> 
> 
> Regretfully, I have chosen to decline to sponsor the ifare 
> bof for Chicago.
> 
> I think there is a lot of interest.  However I don't think we 
> have come far enough in working with people who disagree with 
> the ifare proposal or who don't see the value for a 
> productive second BOF.
> Remember that if this second BOF doesn't get us the face to 
> face time we need to get a charter, our options are very 
> limited.  Proposals are given at most two BOFs.
> 
> According to the MIP6 chairs this effort has received little 
> traction in the MIP6 working group.  In order to use the 
> current problem and applicability statement you would need to 
> show significant interest from the MIP6 working group.
> 
> 
> Also, there has been rather limited discussion on the BOF list.
> 
> I'd be happy to meet with proponents of this work in Chicago 
> and discuss how we can try and build the necessary support 
> for a second BOF.
> 
> Sam Hartman
> Security Area Director
> 
> 


From hartmans@MIT.EDU Tue Jun 12 18:24:42 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5CMOgdI021031
	for ; Tue, 12 Jun 2007 18:24:42 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5CMOecu009085
	for ; Tue, 12 Jun 2007 18:24:40 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (unknown [192.42.249.121])
	by mit.edu (Spam Firewall) with ESMTP id DFB7C579558
	for ; Tue, 12 Jun 2007 18:24:39 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042)
	id EE1DF4013; Tue, 12 Jun 2007 18:24:42 -0400 (EDT)
From: Sam Hartman 
To: "Mike Kraus (mikraus)" , saag@MIT.EDU,
	Sandy Murphy 
References: <249A89BAA060C94FA0B93EA6135CC93C038CAB68@xmb-rtp-20b.amer.cisco.com>
	<20070531204027.3082B3F450@pecan.tislabs.com>
	<249A89BAA060C94FA0B93EA6135CC93C038CABE1@xmb-rtp-20b.amer.cisco.com>
	
Date: Tue, 12 Jun 2007 18:24:42 -0400
In-Reply-To:  (Stephen Kent's message of
	"Thu, 31 May 2007 19:54:40 -0400")
Message-ID: 
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 12 Jun 2007 22:24:42 -0000

>>>>> "Stephen" == Stephen Kent  writes:

    Stephen> . It's a
    Stephen> bit late to be suggesting that the status of AH support
    Stephen> (MAY) in 4301 is not appropriate.

RFC 4301 is only an RFC:-) It's not written in stone.  If we got
something wrong we can fix it.  Yes, we do need to consider the
interoperability implications of what we do.  But we make mistakes at
all phases of the process.

--Sam


From alcaraz@lcc.uma.es Wed Jun 13 06:21:36 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5DALaos019652
	for ; Wed, 13 Jun 2007 06:21:36 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5DALYIO019305
	for ; Wed, 13 Jun 2007 06:21:34 -0400 (EDT)
Received: from nala.ctima.uma.es (nala.ctima.uma.es [150.214.57.23])
	by mit.edu (Spam Firewall) with ESMTP id 23CAA31E124
	for ; Wed, 13 Jun 2007 06:21:33 -0400 (EDT)
Received: from nala.ctima.uma.es (localhost [127.0.0.1])
	by localhost.ctima.uma.es (Postfix) with ESMTP id 41445B266
	for ; Wed, 13 Jun 2007 12:21:32 +0200 (CEST)
Received: from sol10.lcc.uma.es (sol10.lcc.uma.es [150.214.108.1])by 
	nala.ctima.uma.es (Postfix) with ESMTP id 1E245B265for ;
	Wed, 13 Jun 2007 12:21:32 +0200 (CEST)
Received: from [127.0.0.1] (unknown [150.214.56.144])by sol10.lcc.uma.es 
	(Postfix) with ESMTP id A736E38D0Ffor ; Wed, 13 Jun 2007 
	12:21:30 +0200 (CEST)
Message-ID: <466FC52E.40609@lcc.uma.es>
Date: Wed, 13 Jun 2007 12:21:34 +0200
From: Cristina Alcaraz Tello 
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: saag@mit.edu
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 000748-4, 12/06/2007), Outbound message
X-Antivirus-Status: Clean
X-imss-version: 2.047
X-imss-result: Passed
X-imss-approveListMatch: *@*.uma.es
X-Spam-Score: 0.78
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] 2nd International Workshop on Critical Information
	InfrastructuresSecurity (CRITIS'07)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 13 Jun 2007 10:21:37 -0000

** Apologies for multiple copies **

C a l l     F o r     P a p e r s

2nd International Workshop on Critical
Information Infrastructures Security (CRITIS'07)
October 3-5, 2007
Benalmadena-Costa, Malaga, Spain

http://critis07.lcc.uma.es/


CRITIS'07, co-sponsored by IFIP WG 11.10 on Critical Infrastructures
Protection, IEEE Computer Society Task Force on Information Assurance,
and Joint Research Center Ispra of the European Commission, wants
to bring together researchers and professionals from universities,

private
companies and Public Administrations interested or involved in all
security-related heterogeneous aspects of Critical

InformationInfrastructures.

The program of the event will include invited
talks by the following distinguished speakers:
- Jacques Bus, European Commission, INFSO Unit "Security"
- Adrian Gheorghe, Old Dominion University, US
- Paulo Veríssimo, Universidade de Lisboa, Portugal.

Additionally, the program will include the following panel:
"Resilient Critical Information Infrastructures: a myth or a

realistictarget?"
chaired by Jacques Bus.

We invite research papers, work-in-progress reports, R&D projects

results,
surveying works and industrial experiences describing significant

security
advances in the following (non-exclusive) areas of Critical Information
Infrastructures for which we plan to have sessions:

- Code of Practice and Metrics
- Communication Risk & Assurance
- Early Warning Systems
- Economics on CIP
- R&D Agenda
- SCADA and Embedded Security
- National and Cross Border Issues
- Information Sharing and Exchange
- Policy Options Elaboration
- Threats and Attacks Modeling

Furthermore, the following topics are within the scope of CRITIS'07:

- Continuity of Services and Resiliency
- Dependable Infrastructure Communications
- Internet-based remote control
- Forensic Techniques
- Incident Response
- Network Survivability
- Trust Models in Critical Scenarios
- Security Logistics


* Instructions for paper submission

All submissions will be subjected to a thorough blind review by at least
three reviewers. Papers should be up to 12 pages in English, including
bibliography and well-marked appendices.
As in the case of CRITIS'06, post-proceedings will be published
by Springer in the Lecture Notes in Computer Science (LNCS) series.
Pre-proceedings will appear at the time of the conference.
To submit a paper, follow the specific instructions on the Workshop

website

The submitted paper (in PDF or PostScript format), which should follow

the
template indicated by Springer
,
must start with a title, a short abstract, and a list of keywords.
However, it should be anonymous without author(s), affiliations,
acknowledgements, nor obvious references.


* Important dates

Submission of papers: July 2nd, 2007
Notification to authors: July 30th, 2007
Camera-ready copies: August 24th, 2007


* Program Committee Co-Chairs
Bernhard Hämmerli, HTA Luzern, Switzerland
Javier Lopez, University of Malaga, Spain

* General Co-Chair
Sokratis Katsikas, University of the Aegean, Greece
Saifur Rahman, Advanced Research Institute, Virginia Tech, US

* Sponsorship Co-Chairs
Marcelo Masera, IPSC, Italy
Stephen D. Wolthusen, Royal Holloway, UK

* Program Committee
Fabrizio Baiardi, Università de Pisa, Italy
Stefan Brem, Federal Office for Civil Protection, Switzerland
Jim Clarke, Waterford Institute of Technology, Ireland
Jorge Cuellar, Siemens, Germany
Weidong Cui, Microsoft Research, US
Yvo Desmedt, University College London, UK
Ed Dawson, QUT, Australia
Myriam Dunn, ETH Zurich, Switzerland
Paul Friessem, Fraunhofer, Germany
Urs Gattiker, CyTRAP Labs, Switzerland
Adrian Gheorghe, Old Dominion University, US
Eric Goetz, Dartmouth College, US
Solange Ghernaouti-Hélie, Univ. de Lausanne, Switzerland
Janusz Gorski, Gdansk University of Technology, Poland
Rune Gustavsson, Blekinge Inst. of Technology, Sweden
John Griffin, IBM T.J. Watson, US
Stefanos Gritzalis, University of the Aegean, Greece
Ming-Yuh Huang, Boeing, US
Håkan Kvarnström, TeliaSonera, Sweden
Diego Lopez, RedIRIS, Spain
Eric Luiijf, TNO, Netherlands
Tom McCutcheon, NISCC, UK
Yuko Murayama, Iwate Prefectural University, Japan
Simin Nadjm-Tehrani, Linköping University, Sweden
Syed Naqvi, CETIC, Belgium
Eiji Okamoto, Univ. of Tsukuba, Japan
Andrew Powell, CPNI, UK
Kai Rannenberg, Goethe University Frankfurt, Germany
Dirk Reinermann, BSI, Germany
Michel Riguidel, ENST, France
Roberto Setola, Univ. Campus Bio-Medico di Roma, Italy
Sujeet Shenoi, University of Tulsa, US
Robin Sommer, LBNL/ICSI, US
Paulo Veríssimo, Universidade de Lisboa, Portugal
Yuliang Zheng, University of North Carolina, US
Jianying Zhou, I2R, Singapore


* Information about past CRITIS'06

http://critis06.lcc.uma.es


From kivinen@iki.fi Wed Jun 13 08:24:23 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5DCON7P026110
	for ; Wed, 13 Jun 2007 08:24:23 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5DCOLST013087
	for ; Wed, 13 Jun 2007 08:24:21 -0400 (EDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP
	id 409D2618335; Wed, 13 Jun 2007 08:24:19 -0400 (EDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1])
	by mail.kivinen.iki.fi (8.13.8/8.12.10) with ESMTP id l5DCNr3e020381
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Jun 2007 15:23:53 +0300 (EEST)
Received: (from kivinen@localhost)
	by fireball.kivinen.iki.fi (8.13.8/8.12.11) id l5DCNqm9013215;
	Wed, 13 Jun 2007 15:23:52 +0300 (EEST)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to
	kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <18031.57816.759091.488737@fireball.kivinen.iki.fi>
Date: Wed, 13 Jun 2007 15:23:52 +0300
From: Tero Kivinen 
To: Sam Hartman 
In-Reply-To: 
References: <249A89BAA060C94FA0B93EA6135CC93C038CAB68@xmb-rtp-20b.amer.cisco.com>
	<20070531204027.3082B3F450@pecan.tislabs.com>
	<249A89BAA060C94FA0B93EA6135CC93C038CABE1@xmb-rtp-20b.amer.cisco.com>
	 
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 3 min
X-Total-Time: 3 min
X-Spam-Score: 0.01
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, "Mike Kraus \(mikraus\)" ,
	Sandy Murphy 
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 13 Jun 2007 12:24:23 -0000

Sam Hartman writes:
> >>>>> "Stephen" == Stephen Kent  writes:
> 
>     Stephen> . It's a
>     Stephen> bit late to be suggesting that the status of AH support
>     Stephen> (MAY) in 4301 is not appropriate.
> 
> RFC 4301 is only an RFC:-) It's not written in stone.  If we got
> something wrong we can fix it.  Yes, we do need to consider the
> interoperability implications of what we do.  But we make mistakes at
> all phases of the process.

And I do not think all feature some protocol wants to implement needs
to be MUST. One of the reasons for moving AH to MAY was that most of
the VPN vendors didn't see need for it, thus they didn't want to
implement it.

If OSPF or some other protocol do require AH, they can say that they
do require it, thus the IPsec implementiation used for that protocol
needs to support that MAY feature of IPsec protocol. Most of the
implementations of IPsec do support quite a lot of different SHOULD
and MAY features too, and for example IPsec VPN clients needs to
support all kind of optional features to be usable.

I.e. I do not see any reason to change AH from MAY to anything else
even if it would be used in OSPF or some other protocol.
-- 
kivinen@safenet-inc.com

From rja@extremenetworks.com Wed Jun 13 09:53:35 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5DDrZKN012263
	for ; Wed, 13 Jun 2007 09:53:35 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5DDrVFR011651
	for ; Wed, 13 Jun 2007 09:53:31 -0400 (EDT)
Received: from eastrmmtao105.cox.net (eastrmmtao105.cox.net [68.230.240.47])
	by mit.edu (Spam Firewall) with ESMTP id 667D462B67D
	for ; Wed, 13 Jun 2007 09:53:30 -0400 (EDT)
Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao105.cox.net
	(InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP
	id <20070613135331.QRWK8837.eastrmmtao105.cox.net@eastrmimpo02.cox.net>
	for ; Wed, 13 Jun 2007 09:53:31 -0400
Received: from [10.30.20.240] ([68.10.118.38])
	by eastrmimpo02.cox.net with bizsmtp
	id B1tV1X00F0pnMhQ0000000; Wed, 13 Jun 2007 09:53:29 -0400
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Transfer-Encoding: 7bit
Message-Id: 
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: IETF Security Area WG 
From: RJ Atkinson 
Date: Wed, 13 Jun 2007 09:53:29 -0400
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.01
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 13 Jun 2007 13:53:35 -0000


A long-standing issue with the IPsec WG is that it has been
overwhelmingly dominated by "VPN appliance" vendors, to the
extent that ordinary user inputs and other IPsec implementers
have somewhat been drowned out.

So Sam Hartman's note of earlier today seems entirely on-point
and entirely appropriate.

In particular, the IPsec WG deciding that not all IPsec
implementations need to implement AH is unrelated and orthogonal
to (potential) decisions by other IETF WGs that implementations
of some other protocol (e.g. IPv6, OSPFv2, OSPFv3, other)
MUST also implement AH for specific use with that other protocol.
Even if some other WG made such a decision, that would
not require the IPsec WG to undertake anything.  That other
WG's mandate can be placed in RFCs generated by that other WG,
without changing the IPsec WG's documents.

Discussions with network operations folks various places
(e.g. within DoD, MoD, enterprises, and ISPs) indicate a fair
(and growing) amount of interest in moving away from all forms
of integrated routing protocol authentication (e.g. TCP Auth,
OSPFv2 Auth, RIPv2 Auth) and towards use of AH to protect
those routing protocols.[1]  The same folks also seem to have
converged on a strong preference for algorithms/modes that
are acceptable to US NIST.[2]  They also seem interested in
exploring whether MIKEY work might be suitable for key
management of OSPF/RIP.  IKEvX already seems suitable for
key management to protect BGP sessions, since those are
already pair-wise SAs.  To my mind, all of the topics
within this paragraph belong to the sundry Routing Area
WGs (and aren't particularly IPsec WG topics), but the
IESG ultimately makes whatever charter/scope decisions
need to be made about which work is undertaken where.

Yours,

Ran
rja@extremenetworks.com

[1] I/IS-IS sits directly on the link-layer, and is not sent
over IP, so AH it isn't obvious that AH is applicable to I/IS-IS.
[2] One commercial firm said that their insurers were pushing them
to only use NIST-approved algorithms/modes.


From vishwas.ietf@gmail.com Wed Jun 13 12:54:44 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5DGsiFi023369
	for ; Wed, 13 Jun 2007 12:54:44 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5DGsX3g001559
	for ; Wed, 13 Jun 2007 12:54:33 -0400 (EDT)
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182])
	by mit.edu (Spam Firewall) with ESMTP id E941855DC6B
	for ; Wed, 13 Jun 2007 12:54:32 -0400 (EDT)
Received: by wa-out-1112.google.com with SMTP id m16so329405waf
	for ; Wed, 13 Jun 2007 09:54:32 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=D8ZrDobdKn1YSg64d5RvL1rQNzYYI6ZfjiRK0fp11QIw+sePVzByzltanmS8i62JubMdg8q7BL7a8sOCE5pYOokMLGtjXErsD4y02MJqNMdpAjclWa5CI55f3uoAky60OOw6W3EUpL7eIa2Ym4RadG8MTlpKO9tfH8YGyEvHG2c=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=KnruYtJeVOYKnbCsYc6GyvpIjO1kp0c44kTjT9vlnGSFwrt0/2+KuXOoSWQnG+bozSRhyp0330DFD3I4QGGidZ88tsSuY88pl7uUXxo4M9oVPhVRk7p7UCt+UUXeHVGsJwhmqhealdaYz6UcfDpVwHFcoz4znKEgojd0KfhAwUw=
Received: by 10.115.32.1 with SMTP id k1mr829612waj.1181753672364;
	Wed, 13 Jun 2007 09:54:32 -0700 (PDT)
Received: by 10.114.154.5 with HTTP; Wed, 13 Jun 2007 09:54:32 -0700 (PDT)
Message-ID: <77ead0ec0706130954r4c14f6cra1b29c86ae2380ef@mail.gmail.com>
Date: Wed, 13 Jun 2007 09:54:32 -0700
From: "Vishwas Manral" 
To: "RJ Atkinson" 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: 
X-Spam-Score: 0.001
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: IETF Security Area WG 
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 13 Jun 2007 16:54:45 -0000

Hi Ran,

I too agree with Sam, that if there is a requirement to update
RFC4301, we can do it.

It would however be great if you could point out some technical
reasons of why AH vs ESP-NULL, rather than pointing to anonymous
vendors. I think that can come in the purview of this group. For a
previous technical discussion on the same, you can have a look at the
archives.

Thanks,
Vishwas

On 6/13/07, RJ Atkinson  wrote:
>
> A long-standing issue with the IPsec WG is that it has been
> overwhelmingly dominated by "VPN appliance" vendors, to the
> extent that ordinary user inputs and other IPsec implementers
> have somewhat been drowned out.
>
> So Sam Hartman's note of earlier today seems entirely on-point
> and entirely appropriate.
>
> In particular, the IPsec WG deciding that not all IPsec
> implementations need to implement AH is unrelated and orthogonal
> to (potential) decisions by other IETF WGs that implementations
> of some other protocol (e.g. IPv6, OSPFv2, OSPFv3, other)
> MUST also implement AH for specific use with that other protocol.
> Even if some other WG made such a decision, that would
> not require the IPsec WG to undertake anything.  That other
> WG's mandate can be placed in RFCs generated by that other WG,
> without changing the IPsec WG's documents.
>
> Discussions with network operations folks various places
> (e.g. within DoD, MoD, enterprises, and ISPs) indicate a fair
> (and growing) amount of interest in moving away from all forms
> of integrated routing protocol authentication (e.g. TCP Auth,
> OSPFv2 Auth, RIPv2 Auth) and towards use of AH to protect
> those routing protocols.[1]  The same folks also seem to have
> converged on a strong preference for algorithms/modes that
> are acceptable to US NIST.[2]  They also seem interested in
> exploring whether MIKEY work might be suitable for key
> management of OSPF/RIP.  IKEvX already seems suitable for
> key management to protect BGP sessions, since those are
> already pair-wise SAs.  To my mind, all of the topics
> within this paragraph belong to the sundry Routing Area
> WGs (and aren't particularly IPsec WG topics), but the
> IESG ultimately makes whatever charter/scope decisions
> need to be made about which work is undertaken where.
>
> Yours,
>
> Ran
> rja@extremenetworks.com
>
> [1] I/IS-IS sits directly on the link-layer, and is not sent
> over IP, so AH it isn't obvious that AH is applicable to I/IS-IS.
> [2] One commercial firm said that their insurers were pushing them
> to only use NIST-approved algorithms/modes.
>

From kent@bbn.com Thu Jun 14 17:29:12 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5ELTAVq030624
	for ; Thu, 14 Jun 2007 17:29:10 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5ELSwJc020104
	for ; Thu, 14 Jun 2007 17:28:58 -0400 (EDT)
Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81])
	by mit.edu (Spam Firewall) with ESMTP id 667B655481A
	for ; Thu, 14 Jun 2007 17:28:54 -0400 (EDT)
Received: from dhcp89-089-071.bbn.com ([128.89.89.71])
	by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from )
	id 1Hyws9-0000yR-5Q; Thu, 14 Jun 2007 17:28:53 -0400
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <27513.1180964154@marajade.sandelman.ca>
References: <249A89BAA060C94FA0B93EA6135CC93C038CAB68@xmb-rtp-20b.amer.cisco.com>
	<20070531204027.3082B3F450@pecan.tislabs.com>
	<249A89BAA060C94FA0B93EA6135CC93C038CABE1@xmb-rtp-20b.amer.cisco.com>
	
	<27513.1180964154@marajade.sandelman.ca>
Date: Thu, 14 Jun 2007 17:28:50 -0400
To: Michael Richardson 
From: Stephen Kent 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 14 Jun 2007 21:29:14 -0000

At 9:35 AM -0400 6/4/07, Michael Richardson wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>>>>>>  "Stephen" == Stephen Kent  writes:
>     Stephen> Its a pity that Cisco, who had several staff members
>     Stephen> actively participating in the IPsec WG, did not see fit to
>     Stephen> state these concerns during the multi-year interval during
>
>   Be fair.
>   CISCO is a very big organization.

it is because the comment was made by a very big organization, and 
expressed in the form "we, the very big organization, believe that 
out customers will primarily use AH ..." that prompted the response.

>
>     Stephen> which RFC 4301 was being edited. It's a bit late to be
>     Stephen> suggesting that the status of AH support (MAY) in 4301 is
>     Stephen> not appropriate.
>
>   RFC2401/4301 are base technology specifications.  95% of the people
>who participated in the process were VPN people with little other
>concern.
>   (With the other 5% being David Black representing iSCSI)
>   Frankly, it is a wonder that AH even made it into 4301.

The folks from Microsoft who actively participated probably count as 
other than "VPN people." :-)

>   I think it was a mistake to ever think that they the MUST/MAY/SHOULD
>in the broad parts of the specification mean anything without upper
>layer protocol (layer 4 PLUS) specification input.

4301 is an architecture document and distinguishes between host and 
gateway requirements.  A good spec for a layer N protocol takes into 
account the layer N+1 users, but it also tries to be general.

There is a tradeoff: we have to decide when to try to accommodate an 
application by making change to a lower layer protocol, and when we 
should suggest the application needs to reconsider the use of the 
lower layer protocol.  Based on the lengthy discussions Sam and I had 
re how OSPF wants to use IPsec (not an AH vs. ESP-NULL debate), it 
come close to falling into the latter category. This is primarily 
because OSPF does not really seem to want to use the access control 
facilities that are a central part of the protocol.

>
>     Stephen> real question is whether most traffic would benefit
>     Stephen> significantly from use of either AH or ESP-NULL, vs. ESP,
>     Stephen> since most traffic that merits layer 3 crypto protection
>     Stephen> probably requires confidentiality, as well as integrity and
>     Stephen> authentication.
>
>   I see no confidentiality requirements for OSPF. It's all integrity.

As I noted in a response to Sandy, the discussion moved beyond OSPF 
when Mike made his comment without reference to the OSPF context.

Steve

From sandy@tislabs.com Thu Jun 14 18:44:00 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5EMi0lS011844
	for ; Thu, 14 Jun 2007 18:44:00 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5EMhmxw018872
	for ; Thu, 14 Jun 2007 18:43:49 -0400 (EDT)
Received: from nutshell.tislabs.com (ns1.tislabs.com [192.94.214.100])
	by mit.edu (Spam Firewall) with ESMTP id 2A22756732D
	for ; Thu, 14 Jun 2007 18:43:47 -0400 (EDT)
Received: (from uucp@localhost)
	by nutshell.tislabs.com (8.12.9/8.12.9) id l5EMfV0r015981;
	Thu, 14 Jun 2007 18:41:31 -0400 (EDT)
Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap
	(V6.0) id srcAAAjOaqnF; Thu, 14 Jun 07 18:41:27 -0400
Received: by pecan.tislabs.com (Postfix, from userid 2005)
	id 7B0FB3F475; Thu, 14 Jun 2007 18:39:49 -0400 (EDT)
To: kent@bbn.com, mcr@sandelman.ottawa.on.ca
In-Reply-To: 
Message-Id: <20070614223949.7B0FB3F475@pecan.tislabs.com>
Date: Thu, 14 Jun 2007 18:39:49 -0400 (EDT)
From: sandy@tislabs.com (Sandy Murphy)
X-Spam-Score: 0
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 14 Jun 2007 22:44:00 -0000

>>   I see no confidentiality requirements for OSPF. It's all integrity.
>
>As I noted in a response to Sandy, the discussion moved beyond OSPF 
>when Mike made his comment without reference to the OSPF context.

So we can all agree that Steve's observation

(a) is true in the general case in many/most networks

but

(b) does not hold (for most networks) when we re-focus on this particular
    problem.



--Sandy

From rja@extremenetworks.com Fri Jun 15 10:18:28 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5FEIS1w004594
	for ; Fri, 15 Jun 2007 10:18:28 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5FEIGEf016907
	for ; Fri, 15 Jun 2007 10:18:16 -0400 (EDT)
Received: from eastrmmtao101.cox.net (eastrmmtao101.cox.net [68.230.240.7])
	by mit.edu (Spam Firewall) with ESMTP id 6EBDA57AC25
	for ; Fri, 15 Jun 2007 10:18:05 -0400 (EDT)
Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao101.cox.net
	(InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id
	<20070615141753.BVEX13718.eastrmmtao101.cox.net@eastrmimpo01.cox.net>
	for ; Fri, 15 Jun 2007 10:17:53 -0400
Received: from [10.30.20.61] ([68.10.118.38])
	by eastrmimpo01.cox.net with bizsmtp
	id BqHt1X00a0pnMhQ0000000; Fri, 15 Jun 2007 10:17:53 -0400
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <4A280291-EF5A-47E7-90BA-9AD7DC7748EE@extremenetworks.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: IETF Security Area WG 
From: RJ Atkinson 
Date: Fri, 15 Jun 2007 10:17:52 -0400
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.01
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 15 Jun 2007 14:18:28 -0000

Earlier, Steve Kent wrote:
% Based on the lengthy discussions Sam and I had  re how OSPF
% wants to use IPsec (not an AH vs. ESP-NULL debate), it come
% close to falling into the latter category. This is primarily
% because OSPF does not really seem to want to use the access
% control facilities that are a central part of the protocol.

Hmm.  My understanding from a number of OSPF users is that
one of the attractions of an IPsec-based approach is that
the users operating an OSPF domain can use the access control
facilities that IPsec provides (e.g. packets without valid
IPsec authentication would be dropped within ipsec_ah_input(),
instead of being handed up to the OSPF task).

Perhaps I misunderstood what you wrote above ?

Yours,

Ran
rja@extremenetworks.com



From kent@bbn.com Fri Jun 15 11:46:49 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5FFknxP026848
	for ; Fri, 15 Jun 2007 11:46:49 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5FFkZGQ003743
	for ; Fri, 15 Jun 2007 11:46:35 -0400 (EDT)
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80])
	by mit.edu (Spam Firewall) with ESMTP id AA1C231959E
	for ; Fri, 15 Jun 2007 11:46:34 -0400 (EDT)
Received: from dhcp89-089-071.bbn.com ([128.89.89.71])
	by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from )
	id 1HzE0Q-0001sg-3O; Fri, 15 Jun 2007 11:46:34 -0400
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <4A280291-EF5A-47E7-90BA-9AD7DC7748EE@extremenetworks.com>
References: <4A280291-EF5A-47E7-90BA-9AD7DC7748EE@extremenetworks.com>
Date: Fri, 15 Jun 2007 11:46:26 -0400
To: RJ Atkinson 
From: Stephen Kent 
Content-Type: multipart/alternative;
	boundary="============_-1030200103==_ma============"
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: IETF Security Area WG 
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 15 Jun 2007 15:46:49 -0000

--============_-1030200103==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 10:17 AM -0400 6/15/07, RJ Atkinson wrote:
>Earlier, Steve Kent wrote:
>% Based on the lengthy discussions Sam and I had  re how OSPF
>% wants to use IPsec (not an AH vs. ESP-NULL debate), it come
>% close to falling into the latter category. This is primarily
>% because OSPF does not really seem to want to use the access
>% control facilities that are a central part of the protocol.
>
>Hmm.  My understanding from a number of OSPF users is that
>one of the attractions of an IPsec-based approach is that
>the users operating an OSPF domain can use the access control
>facilities that IPsec provides (e.g. packets without valid
>IPsec authentication would be dropped within ipsec_ah_input(),
>instead of being handed up to the OSPF task).
>
>Perhaps I misunderstood what you wrote above ?


My comment is based on the discussions I had with the authors of the 
"how to use IPsec with OSPF" document last year. I raised questions 
about how they would configure the SPD to enforce certain access 
control constraints that appear to be needed as part of OSPF 
security. The response was that OSPF would make the requisite checks, 
based on its knowledge of the interface via which a packet was 
received, and thus the SPD checking mechanisms would not be employed.

The example you provide above is not the sort of access control 
function to which I was referring. The example is an integrity 
function applied to traffic on an SA, not the access control check 
(against 5-tuple that defines traffic selectors for an SA) for 
packets that pass the integrity check.

Steve

--============_-1030200103==_ma============
Content-Type: text/html; charset="us-ascii"


Re: [saag] AH & OSPF

At 10:17 AM -0400 6/15/07, RJ Atkinson wrote:


Earlier, Steve Kent wrote:

% Based on the lengthy discussions Sam and I had  re how OSPF

% wants to use IPsec (not an AH vs. ESP-NULL debate), it come

% close to falling into the latter category. This is primarily

% because OSPF does not really seem to want to use the access

% control facilities that are a central part of the protocol.



Hmm.  My understanding from a number of OSPF users is that

one of the attractions of an IPsec-based approach is that

the users operating an OSPF domain can use the access control

facilities that IPsec provides (e.g. packets without valid

IPsec authentication would be dropped within ipsec_ah_input(),

instead of being handed up to the OSPF task).


Perhaps I misunderstood what you wrote above
?










My comment is based on the discussions I had with the authors of
the "how to use IPsec with OSPF" document last year. I
raised questions about how they would configure the SPD to enforce
certain access control constraints that appear to be needed as part of
OSPF security. The response was that OSPF would make the requisite
checks, based on its knowledge of the interface via which a packet was
received, and thus the SPD checking mechanisms would not be
employed.





The example you provide above is not the sort of access control
function to which I was referring. The example is an integrity
function applied to traffic on an SA, not the access control check
(against 5-tuple that defines traffic selectors for an SA) for packets
that pass the integrity check.





Steve






--============_-1030200103==_ma============--

From rja@extremenetworks.com Fri Jun 15 13:00:13 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5FH0D1X016752
	for ; Fri, 15 Jun 2007 13:00:13 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5FH01iD019510
	for ; Fri, 15 Jun 2007 13:00:02 -0400 (EDT)
Received: from eastrmmtao103.cox.net (eastrmmtao103.cox.net [68.230.240.9])
	by mit.edu (Spam Firewall) with ESMTP id D8D5932F213
	for ; Fri, 15 Jun 2007 13:00:00 -0400 (EDT)
Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao103.cox.net
	(InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP
	id <20070615170001.HPMW8543.eastrmmtao103.cox.net@eastrmimpo01.cox.net>;
	Fri, 15 Jun 2007 13:00:01 -0400
Received: from [10.30.20.61] ([68.10.118.38])
	by eastrmimpo01.cox.net with bizsmtp
	id Bszz1X00P0pnMhQ0000000; Fri, 15 Jun 2007 12:59:59 -0400
In-Reply-To: 
References: <4A280291-EF5A-47E7-90BA-9AD7DC7748EE@extremenetworks.com>
	
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <9125255E-DB3F-4B8B-8BF0-A90A5C8690CD@extremenetworks.com>
Content-Transfer-Encoding: 7bit
From: RJ Atkinson 
Date: Fri, 15 Jun 2007 12:59:59 -0400
To: Stephen Kent 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.01
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: IETF Security Area WG 
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 15 Jun 2007 17:00:13 -0000


On  15 Jun 2007, at 11:46, Stephen Kent wrote:
> My comment is based on the discussions I had with the authors
> of the "how to use IPsec with OSPF" document last year. I raised
> questions about how they would configure the SPD to enforce certain
> access control constraints that appear to be needed as part of OSPF
> security. The response was that OSPF would make the requisite checks,
> based on its knowledge of the interface via which a packet was
> received, and thus the SPD checking mechanisms would not be employed.
>
> The example you provide above is not the sort of access control  
> function
> to which I was referring. The example is an integrity function applied
> to traffic on an SA, not the access control check (against 5-tuple  
> that
> defines traffic selectors for an SA) for packets that pass the  
> integrity
> check.

	Mea culpa.  Poor phrasing on my part.  Thank you for
clarifying things.

	Indeed, the potential to use SPD access control checks
(in addition to, rather than replacing, OSPF checks) also seems
to be interesting, at least to some folks who have OSPF deployed
as their IGP.   A good question would be how many care about
the SPD access control checks and how many are indifferent.

	One of the things I've been learning is how complex the
deployed world is these days.  The rapid growth in various sorts
of layer-2 logical network overlays really seems to challenge
lots of assumptions (including security assumptions) about how
OSPF routers are connected.  There seem to be lots of OSPF peers
that are not directly connected on the same physical link,
but instead are connected via some (potentially wide-area and
even cross-domain) logical link instead.  At least some folks
with such deployments are much more concerned about a wider range
of potential threats than they were back when OSPF peers
connected via a yellow coax Ethernet cable.

Thanks very much.

Yours,

Ran
rja@extremenetworks.com


From kent@bbn.com Fri Jun 15 13:15:55 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5FHFtKB020437
	for ; Fri, 15 Jun 2007 13:15:55 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5FHFhpw016020
	for ; Fri, 15 Jun 2007 13:15:43 -0400 (EDT)
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80])
	by mit.edu (Spam Firewall) with ESMTP id 2ED1456BB7C
	for ; Fri, 15 Jun 2007 13:14:53 -0400 (EDT)
Received: from dhcp89-089-071.bbn.com ([128.89.89.71])
	by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from )
	id 1HzFNo-00035K-58; Fri, 15 Jun 2007 13:14:48 -0400
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <9125255E-DB3F-4B8B-8BF0-A90A5C8690CD@extremenetworks.com>
References: <4A280291-EF5A-47E7-90BA-9AD7DC7748EE@extremenetworks.com>
	
	<9125255E-DB3F-4B8B-8BF0-A90A5C8690CD@extremenetworks.com>
Date: Fri, 15 Jun 2007 13:13:10 -0400
To: RJ Atkinson 
From: Stephen Kent 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: IETF Security Area WG 
Subject: Re: [saag] AH & OSPF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 15 Jun 2007 17:15:55 -0000

At 12:59 PM -0400 6/15/07, RJ Atkinson wrote:
>On  15 Jun 2007, at 11:46, Stephen Kent wrote:
>>  My comment is based on the discussions I had with the authors
>>  of the "how to use IPsec with OSPF" document last year. I raised
>>  questions about how they would configure the SPD to enforce certain
>>  access control constraints that appear to be needed as part of OSPF
>>  security. The response was that OSPF would make the requisite checks,
>>  based on its knowledge of the interface via which a packet was
>>  received, and thus the SPD checking mechanisms would not be employed.
>>
>>  The example you provide above is not the sort of access control 
>>  function
>>  to which I was referring. The example is an integrity function applied
>>  to traffic on an SA, not the access control check (against 5-tuple 
>>  that
>>  defines traffic selectors for an SA) for packets that pass the 
>>  integrity
>>  check.
>
>	Mea culpa.  Poor phrasing on my part.  Thank you for
>clarifying things.

no problem. just trying to keep the discussion precise, to avoid 
disagreement that are based just on terminology.

>
>	Indeed, the potential to use SPD access control checks
>(in addition to, rather than replacing, OSPF checks) also seems
>to be interesting, at least to some folks who have OSPF deployed
>as their IGP.   A good question would be how many care about
>the SPD access control checks and how many are indifferent.

yes, that is a central question in my mind.  It gets back to what I 
said previously about the applicability of a given security protocol 
to a specific application. IPsec is not a crypto protocol; it is an 
architecture for using two crypto protocols (AH and ESP) to achieve 
certain security services, with a very strong emphasis on access 
control. If one wants to apply only per-packet, crypto-based 
integrity and authentication controls, DTLS may be an appropriate 
choice for datagram environments, and TLS is already a very popular 
choice for many application contexts.

>
>	One of the things I've been learning is how complex the
>deployed world is these days.  The rapid growth in various sorts
>of layer-2 logical network overlays really seems to challenge
>lots of assumptions (including security assumptions) about how
>OSPF routers are connected.  There seem to be lots of OSPF peers
>that are not directly connected on the same physical link,
>but instead are connected via some (potentially wide-area and
>even cross-domain) logical link instead.  At least some folks
>with such deployments are much more concerned about a wider range
>of potential threats than they were back when OSPF peers
>connected via a yellow coax Ethernet cable.

yep, the world can be an ugly place :-).

Steve

From hartmans@MIT.EDU Thu Jun 21 10:09:17 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5LE9HNa013858
	for ; Thu, 21 Jun 2007 10:09:17 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5LE95UU013326
	for ; Thu, 21 Jun 2007 10:09:06 -0400 (EDT)
Received: from luminous.suchdamage.org (luminous.suchdamage.org
	[69.25.196.179]) by mit.edu (Spam Firewall) with ESMTP id 25D813397DC
	for ; Thu, 21 Jun 2007 10:09:05 -0400 (EDT)
Received: by luminous.suchdamage.org (Postfix, from userid 8042)
	id 70D73A6C04D; Thu, 21 Jun 2007 10:11:11 -0400 (EDT)
From: Sam Hartman 
To: saag@MIT.EDU
Date: Thu, 21 Jun 2007 10:11:11 -0400
Message-ID: 
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.12
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] W3c Workshop announcement
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 21 Jun 2007 14:09:17 -0000



This is consistent with the presentation we had in Prague on what is
going on in W3C.

> W3C is holding the following Workshop to gather experiences and next
> steps for
> the XML Signature and XML Encryption suites of specifications [1]:
>
>     W3C Workshop on Next Steps for XML Signature and XML Encryption
>
>     25-26 September 2007
>     Mountain View, California, USA
>     Hosted by VeriSign
>
>     Workshop Chairs:
>     Frederick Hirsch (Nokia), and
>     Thomas Roessler (W3C)
>
> Please see the Call for Participation for complete details:
>     http://www.w3.org/2007/xmlsec/ws/cfp
>
> Important Dates
> ===============
>
>    * 14 August        Deadline for position papers
>    * 1 September      Acceptance notices
>    * 10 September     Final Workshop Program available
>    * 10 September     Deadline for registration
>    * 25-26 September  Workshop
>
> Workshop Goals and Scope
> ========================
>
> The goal of this Workshop is to make recommendations to W3C and the
> recently
> chartered XML Security Specifications Maintenance Working Group [1],
> and to
> build community consensus about possible next steps for the XML
> security
> specifications. XML Signature and XML Encryption have seen broad
> deployment,
> and form the basis for a number of security related specifications
> in the Web
> and Web services worlds. The Workshop will review the issues and
> lessons
> learned in implementation, deployment and development of
> specifications based
> on these standards and will investigate:
>
>     * Interoperability and robustness, such as spurious validation
> errors
>     * Performance aspects of implementations
>     * Use cases and requirements such as legal requirements for
> digital
>       signature formats
>     * Experience and consequences of building other specifications or
>       standards based on the XML Signature and XML Encryption suites
>     * Interaction with the evolving XML environment in general as
> well as
>       specifically XML 1.1 and Efficient XML Interchange (EXI)
>
> Participation
> =============
>
> The Workshop is free, and open to both W3C Members and to non-
> members. Public
> proceedings will be published after the event. Space is limited and
> participation may be limited by organization. Position papers are
> required.
>
> We are looking forward to your participation. If you should have any
> questions, please contact Thomas Roessler, Security Activity Lead, at
> .
>
> This announcement follows section 9 of the W3C Process Document on
> Workshops
> and Symposia.
>     http://www.w3.org/2005/10/Process-20051014/events#GAEvents
>
> Thank you,
>
> For Ralph Swick, Technology and Society Domain Leader; and
> Frederick Hirsch and Thomas Roessler, Workshop Chairs;
> Susan Lesch, W3C Communications Team
>
> [1] http://www.w3.org/2007/xmlsec/
>
>


From paul.hoffman@vpnc.org Mon Jun 25 12:56:23 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l5PGuLjR030787
	for ; Mon, 25 Jun 2007 12:56:23 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l5PGu9px004775
	for ; Mon, 25 Jun 2007 12:56:10 -0400 (EDT)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 3815359D832
	for ; Mon, 25 Jun 2007 12:56:08 -0400 (EDT)
Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169])
	(authenticated bits=0)
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5PGu6NY079162
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Mon, 25 Jun 2007 09:56:07 -0700 (MST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
Date: Mon, 25 Jun 2007 09:55:46 -0700
To: saag@mit.edu
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] SHA-2 patent status
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Mon, 25 Jun 2007 16:56:23 -0000

Of possible interest (but hopefully no concern) to this list: a new 
IPR statement from the NSA to the IETF. 


--Paul Hoffman, Director
--VPN Consortium

From tim.polk@nist.gov Mon Jul 23 13:12:55 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l6NHCk6Q030211
	for ; Mon, 23 Jul 2007 13:12:55 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l6NEGku0011754
	for ; Mon, 23 Jul 2007 10:16:47 -0400 (EDT)
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP
	id 9DECD3DE536; Mon, 23 Jul 2007 10:16:42 -0400 (EDT)
Received: from [129.6.222.154] ([129.6.222.154])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id l6NEGVda010912;
	Mon, 23 Jul 2007 10:16:34 -0400
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <3889FE88-788B-45AB-8F3F-EC022D4C2494@nist.gov>
Content-Transfer-Encoding: 7bit
From: Tim Polk 
Date: Mon, 23 Jul 2007 09:16:30 -0500
To: saag@mit.edu
X-Mailer: Apple Mail (2.752.2)
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: tim.polk@nist.gov
X-Spam-Score: 1
X-Spam-Level: * (1)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: Sam Hartman 
Subject: [saag] ITU-T Identity Management actvities
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Mon, 23 Jul 2007 17:12:55 -0000

Folks,

Herb Bertine, the chairman of ITU-T Study Group 17, recently  
contacted Sam and I
about IETF activities in the area of "Identity Management".   They  
have established a
new focus group, and all the information regarding the focus group  
activities is
available on line.

> 1)  The ITU-T has established a Focus Group on Identity Management
> (IdM).  Information is available from the ITU at:
> http://www.itu.int/ITU-T/studygroups/com17/fgidm/index.html (User  
> Name:
> fgidmuse; Password: fgidmuse) and also from wiki at
> http://www.ituwiki.com/index.php? 
> title=Focus_Group_on_Identity_Managemen
> t.  The Focus Group is open to all interested parties.   The next
> meeting is scheduled for 27-30 August 2007 in Boston-Cambridge.
>

They are also sponsoring a one day workshop on this topic, and have  
invited
the IETF to participate/present.

> 2)  The ITU-T is one of three sponsors of a one-day Workshop on  
> Identity
> Management to be held 30 September 2007 in Lucerne, Switzerland.
> Details are available in TSB Circular 163 at
> http://www.itu.int/md/T05-TSB-CIR-163/en.  The IETF is invited to
> participate in the workshop and make a presentation.  Please let me  
> know
> your interest.

If any IETFers are currently planning on attending this workshop,  
please contact
Sam or I.  We would like to be responsive to Herb's request, but  
attendance by
either of the ADs could be problematic.

Thanks,

Tim Polk



From tim.polk@nist.gov Mon Jul 23 13:13:33 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l6NHCk7o030211
	for ; Mon, 23 Jul 2007 13:13:33 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l6NEV9Z1000744
	for ; Mon, 23 Jul 2007 10:31:09 -0400 (EDT)
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id AB8CE711E06
	for ; Mon, 23 Jul 2007 10:31:08 -0400 (EDT)
Received: from [129.6.222.154] ([129.6.222.154])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id l6NEUuc3026191;
	Mon, 23 Jul 2007 10:30:58 -0400
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Tim Polk 
Date: Mon, 23 Jul 2007 09:30:55 -0500
To: saag@mit.edu
X-Mailer: Apple Mail (2.752.2)
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: tim.polk@nist.gov
X-Spam-Score: 0.01
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] saag agenda
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Mon, 23 Jul 2007 17:13:33 -0000


Folks,

I neglected to email this week's saag agenda to the list when I  
uploaded it to the meeting materials website.  I wanted to correct  
that situation, since we have a very interesting agenda, and I'm  
hoping for a big turnout!

Here is the agenda:

SAAG Agenda, IETF 69
26 July 2007, 1300-1500 State Ballroom

     WG Reports

     BOF Reports

     Invited Presentations

         - Internationalization and Security
           (John Klensin)

        - Proposed Variant of Galois Counter Mode
          (Morrie Dworkin)

     Open Microphone


Sam and I hope to see you all there!

Thanks,

Tim Polk


From tim.polk@nist.gov Mon Jul 23 13:30:00 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l6NHG0G6002047
	for ; Mon, 23 Jul 2007 13:30:00 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l6NEk4Mu001420
	for ; Mon, 23 Jul 2007 10:46:05 -0400 (EDT)
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 8B340629D1E
	for ; Mon, 23 Jul 2007 10:44:12 -0400 (EDT)
Received: from [129.6.222.154] ([129.6.222.154])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id l6NEhqtZ001626;
	Mon, 23 Jul 2007 10:43:54 -0400
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <038B6EC4-B2C8-4D44-818A-8676564CB389@nist.gov>
Content-Transfer-Encoding: 7bit
From: Tim Polk 
Date: Mon, 23 Jul 2007 09:43:52 -0500
To: saag@mit.edu
X-Mailer: Apple Mail (2.752.2)
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: tim.polk@nist.gov
X-Spam-Score: 0.13
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: cfrg@ietf.org
Subject: [saag] background for SAAG presentation for on variant of GCM
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Mon, 23 Jul 2007 17:30:02 -0000

Folks,

Here is some background on the GCM variant under consideration by  
NIST which will be discussed at SAAG this week.  (I have CC'ed the  
cfrg in case their participants find this interesting as well...)

NIST Special Publication 800-38D specifies the Galois/Counter Mode  
(GCM) of the AES algorithm, restricted to large tag sizes. GCM  
combines the counter mode for confidentiality with authentication  
that is based on a universal hash function. GCM is intended for high- 
throughput applications that can take advantage of its  
parallelizability while tolerating its tag size restrictions.  GCM  
was proposed to NIST for considerations by David McGrew and John Viega.

Anton Joux submitted public comments on the first draft of the  
document.  The complete comment submission is available at
   http://csrc.nist.gov/CryptoToolkit/modes/comments/800-38_Series- 
Drafts/GCM/Joux_comments.pdf
To quote the conclusions section:


> In this paper, we have shown an important attack of the NIST version
> GCM mode. This stems from the fact that GCM excessively relies on
> the hypothesis that IVs are never repeating. Moreover, the  
> modification
> introduced by NIST turns this fact into a effective attack when  
> variable
> length IVs are used.
>
>

Joux made some concrete suggestions for changing GCM at the end of   
Section 5:

1.  replace the counter encryption for MACs by the classical   
encryption with the block cipher usually used with Wegman-Carter MACs.
2.  use a strong key derivation at the beginning of the algorithm  
and  computing a different key for each different purpose (one for   
encryption, one for intiializing J, one for the keyed hash and one   
for the MAC encryption).

The current draft of SP 800-38D did not accept Joux's modifications  
to the algorithm, but responded to the Joux comments in several  
concrete ways:
(a) the provision for variable-length IVs is omitted from the new  
draft, and
(b) the draft elaborates on the requirement that initialization  
vectors (IVs) must be unique across all implementations with a given  
key:
        (i) The critical importance of this requirement is indicated.
        (ii) For validation of a module to the requirements of FIPS  
140-2, an IV "generation unit" is required to be within the  
cryptographic boundary of the module.
        (iii) Two IV constructions are outlined: one that relies on  
deterministic elements to meet the uniqueness requirement, and one  
that relies on an output string from a random bit generator.
        (iv) Some design and implementation considerations with  
respect to IVs are discussed.

The current draft of SP 800-38D is available at
     http://csrc.nist.gov/CryptoToolkit/modes/ 
800-38_Series_Publications/ 
NIST_SP_800-38D_June_2007_for_public_comment.pdf

One important note:  I expect to see one additional change in this  
publication when it is officially published.  NIST will be adding a  
section 8.3 that permits use of a KDF to generate both the key and  
the IV to support RFC 4106 and some other AES-based protocols.  These  
protocols ensure that IVs are (statistically) unique across all  
implementations with a given key by generating a new key-IV pair for  
every protocol run.  (It was my assertion that these protocols  
already met the requirements in Section 8 of SP 800-38D, but it was  
decided that an explicit statement was preferable.)

While NIST determined that the GCM mode should be added to the "NIST  
Crypto Standards Toolkit", there have been extensive discussions with  
respect to the utility of the Joux submission.  There is a  
possibility that NIST might recognize the Joux variant as well.  I  
suggested that the needs of protocol developers be considered as a  
primary driver for this decision.  As a result, Morrie Dworkin (the  
author of 800-38D) will be presenting at SAAG to get a feel for the  
level of interest in such a mode.

Thanks,

Tim Polk

From turners@ieca.com Tue Jul 24 19:59:55 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l6ONxtCC006102
	for ; Tue, 24 Jul 2007 19:59:55 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l6ONxrGl016717
	for ; Tue, 24 Jul 2007 19:59:53 -0400 (EDT)
Received: from smtp106.biz.mail.mud.yahoo.com (smtp106.biz.mail.mud.yahoo.com
	[68.142.200.254]) by mit.edu (Spam Firewall) with SMTP id 49EA67063A9
	for ; Tue, 24 Jul 2007 19:59:51 -0400 (EDT)
Received: (qmail 36180 invoked from network); 24 Jul 2007 23:59:51 -0000
Received: from unknown (HELO Wylie) (turners@ieca.com@130.129.21.166 with
	login)
	by smtp106.biz.mail.mud.yahoo.com with SMTP; 24 Jul 2007 23:59:51 -0000
X-YMail-OSG: .q8ikRsVM1k6kdaWR2xlNUQK88CvivP9xZSbO62GSEIoecEA3sIAo1oby3I1Xoc8gyzA5pJ53w--
From: "Turner, Sean P." 
To: 
Date: Tue, 24 Jul 2007 18:49:48 -0500
Organization: IECA, Inc.
Message-ID: <000401c7ce4d$52986070$a6158182@Wylie>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0005_01C7CE23.69C25870"
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
Thread-Index: AcfOTVGNty8M6MnAQFy5aiUJOOvuUg==
X-Spam-Score: 0.31
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] IETF 69 SMIME WG Summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: turners@ieca.com
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 24 Jul 2007 23:59:55 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C7CE23.69C25870
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The S/MIME WG meet Tuesday, 24 July 2007 in the afternoon session III.

Sean Turner (that's me) presented the agenda and WG summary.  No new topics
were added as a result of agenda bashing.  

1 RFC has been published since IETF 68.  There are two documents with the
RFC Editor.  Five drafts made it to WG last call.  2
(Authenticated-Enveloped content type and aes-gcm/ccm with CMS) have been
forwarded to the Security AD for review.  3 IDs are not being progressed due
to ASN.1 module compile issues (2 IBE drafts and 1 RSA-KEM). 

The draft is ready for another WG LC after the next update, which will be
draft -03.

Multiple Signatures attribute draft (-02) has been submitted to the
ID-editor and is likewise ready for WG LC.

The Using SHA2 algorithms with CMS draft will be updated to include DSA,
ECDSA, and RSA use with SHA2 algorithms.  The one issue is that the FIPS
186-3 draft on which the DSA with SHA-224 and SHA-256 draft is not final and
there is a concern that publishing prior to a final version may cause
interoperability problems - i.e., we might publish some OIDs and NIST might
change it in the final. A note will be to the draft to indicate as much.

Feature support for a free-BSD license 2002 ASN.1 compiler was also
discussed. 

spt


------=_NextPart_000_0005_01C7CE23.69C25870
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable






IETF 69 SMIME WG Summary





The S/MIME WG meet Tuesday, 24 =
July 2007 in the afternoon session III.




Sean Turner (that's me) presented =
the agenda and WG summary.  No new topics were added as a result of =
agenda bashing.  




1 RFC has been published since =
IETF 68.  There are two documents with the RFC Editor.  Five =
drafts made it to WG last call.  2 (Authenticated-Enveloped content =
type and aes-gcm/ccm with CMS) have been forwarded to the Security AD =
for review.  3 IDs are not being progressed due to ASN.1 module =
compile issues (2 IBE drafts and 1 RSA-KEM). 



The draft is ready for another WG =
LC after the next update, which will be draft -03.




Multiple Signatures attribute =
draft (-02) has been submitted to the ID-editor and is likewise ready =
for WG LC.




The Using SHA2 algorithms with =
CMS draft will be updated to include DSA, ECDSA, and RSA use with SHA2 =
algorithms.  The one issue is that the FIPS 186-3 draft on which =
the DSA with SHA-224 and SHA-256 draft is not final and there is a =
concern that publishing prior to a final version may cause =
interoperability problems - i.e., we might publish some OIDs and NIST =
might change it in the final. A note will be to the draft to indicate as =
much.



Feature support for a free-BSD =
license 2002 ASN.1 compiler was also discussed. 




spt





------=_NextPart_000_0005_01C7CE23.69C25870--


From leiba@watson.ibm.com Wed Jul 25 12:20:17 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l6PGKGOd022791
	for ; Wed, 25 Jul 2007 12:20:17 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l6PGKE6e024097
	for ; Wed, 25 Jul 2007 12:20:14 -0400 (EDT)
X-ASG-Whitelist: Barracuda Reputation
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 22AC969566D
	for ; Wed, 25 Jul 2007 12:15:47 -0400 (EDT)
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6PGFksX001956
	for ; Wed, 25 Jul 2007 12:15:46 -0400
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217])
	by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id
	l6PGFkN7543554 for ; Wed, 25 Jul 2007 12:15:46 -0400
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1])
	by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id
	l6PGFkGG007658 for ; Wed, 25 Jul 2007 12:15:46 -0400
Received: from poplar (poplar.watson.ibm.com [9.2.40.57])
	by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id
	l6PGFkqC007647 for ; Wed, 25 Jul 2007 12:15:46 -0400
Received: from wecm-9-67-45-92.wecm.ibm.com ([9.67.45.92])
	by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw)
	with SMTP ID IMFd1185380145.2536; Wed, 25 Jul 2007 12:15:45 -0400
Date: Wed, 25 Jul 2007 12:15:43 -0400
From: Barry Leiba 
To: saag@mit.edu
Message-ID: 
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.479
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] IETF 69 DKIM working group summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 25 Jul 2007 16:20:17 -0000

The DKIM working group session was held on Monday afternoon, with Stephen Farrell 
and Barry Leiba co-chairing.  56 people signed the blue sheets.

The meeting's goals were to move the Sender Signing Practices specification 
along, and to highlight the Overview document and bring the working group's focus 
to it.  We started with a review of document status:
* DKIM base protocol specification is now RFC 4871.
* SSP requirements document is with the IESG, working out some last-call 
comments and an AD "discuss".

Jim Fenton gave a review of the SSP specification, the latest version of which 
has just been accepted as a working group document, draft-ietf-dkim-ssp-00.  Jim 
covered the principal changes to the document since the last review, in Prague, 
and discussed three main items in detail:
* Issues involving DNS wildcards.
* The SSP lookup algorithm, as documented in the current spec.
* What SSP publishers can say, outlining, in particular, a new option called 
"strong", in addition to the original "strict" (if it stays, the name will 
change).

There was some discussion of the algorithm, but most of the discussion was about 
what can be stated, and what the relative meanings of "strict" and "strong" are. 
We considered the idea that we have developed statements that we think the 
signers will need, but we have to validate them with those who will benefit the 
most from signing and declaring signing practices.  Dave Crocker and Phillip 
Hallam-Baker agreed to interface with MAAWG and APWG, respectively, to try to get 
their opinions on this.  Phill also stressed his opinion that SSP statements 
should be declarative, not imperative ("I am a financial institution," rather 
than, "I would like you to delete mail that appears to be from me that is 
suspicious.").

Tony Hansen presented the status of the DKIM Overview document, currently 
draft-ietf-dkim-overview-05, which has had a lot of work from its authors but 
which has had relatively little feedback from the working group.  The discussion 
centered on the goals of the document, and strengthened the result from the 
Prague meeting: the document should be split into multiple ones, to better 
achieve its several goals.  In particlar, there's normative text in the document 
now, which isn't appropriate for an informational document.  Some of that will be 
resolved by changes to the text, but some may be resolved by splitting a BCP or 
standards-track document off from the informational portion.  The authors will 
work on this, and we'll keep the ADs involved as we consider changes to the 
charter for this.

In the few minutes at the end, Murray Kucherawy led a brief discussion of his 
authentication-results draft, which the working group will follow, and will 
consider adding to its charter if we (and the ADs) decide it's appropriate.


Barry

--
Barry Leiba, DKIM working group chair  (leiba@watson.ibm.com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam



From clancy@ltsnet.net Wed Jul 25 15:46:58 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l6PJkuY5005186
	for ; Wed, 25 Jul 2007 15:46:58 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l6PJkrwC022076
	for ; Wed, 25 Jul 2007 15:46:53 -0400 (EDT)
Received: from dispatch.cs.umd.edu (dispatch.cs.umd.edu [128.8.128.60])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id EEB6F40E3A1
	for ; Wed, 25 Jul 2007 15:46:52 -0400 (EDT)
Received: from [127.0.0.1] (dhcp-10ad.ietf69.org [130.129.16.173])
	(authenticated bits=0)
	by dispatch.cs.umd.edu (8.13.1/8.12.5) with ESMTP id l6PJkjPv005718
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 25 Jul 2007 15:46:47 -0400
Message-ID: <46A7A8A1.6040904@ltsnet.net>
Date: Wed, 25 Jul 2007 15:46:41 -0400
From: Charles Clancy 
User-Agent: Thunderbird 2.0.0.5 (Windows/20070716)
MIME-Version: 1.0
To: saag@mit.edu
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more
	information
X-CSD-MailScanner: Found to be clean
X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached,
	score=-4.392, required 5, autolearn=not spam, ALL_TRUSTED -1.80,
	AWL 0.01, BAYES_00 -2.60)
X-CSD-MailScanner-From: clancy@ltsnet.net
X-Spam-Status: No
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] HOKEY WG Meeting Summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 25 Jul 2007 19:46:58 -0000

HOKEY Working Group Summary, IETF 69

For meeting materials, including agenda and minutes, see:

     https://datatracker.ietf.org/meeting/69/materials.html#wg-hokey

We discussed the EMSK hierarchy at length, and seem to have general 
consensus that leaving things alone was sufficient, provided additional 
text was provided in the document for security considerations of the DSRK.

We then discussed the key management and delivery document, which 
parallels the keying hierarchy by providing a 3-party protocol to 
securely manage and deliver keys.  We took a vote on whether to use 
hop-by-hop security (i.e. AAA model) with channel bindings for the 
distribution of keys, develop a new key provisioning protocol for 
end-to-end security, or investigate using cross-realm Kerberos for key 
distribution.  The consensus was to stick with hop-by-hop AAA security.

The ERX presentation gave an update on recent revisions to the document. 
  Tim stressed that we should avoid developing signaling that looked 
like "EAPv2", as it was beyond the scope of our charter.

Preauthentication was discussed -- the preauth proponents feel simply 
developing recommendations for preauth within HOKEY is sufficient, 
rather than a protocol, and there seems to be general agreement with 
that as a course of action for the gruop.

-- 
t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  eng.umd.edu/~tcc


From shanna@juniper.net Wed Jul 25 23:58:08 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l6Q3w8dx004841
	for ; Wed, 25 Jul 2007 23:58:08 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l6Q3w5aY002364
	for ; Wed, 25 Jul 2007 23:58:05 -0400 (EDT)
Received: from smtpa.juniper.net (smtpa.juniper.net [207.17.137.120])
	by mit.edu (Spam Firewall) with ESMTP id 2E00B71A613
	for ; Wed, 25 Jul 2007 23:58:04 -0400 (EDT)
Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37])
	by smtpa.juniper.net with ESMTP; 25 Jul 2007 20:58:04 -0700
X-IronPort-AV: i="4.16,582,1175497200"; 
	d="scan'208"; a="43737852:sNHT32577324"
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Wed, 25 Jul 2007 23:58:09 -0400
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IETF 69 NEA WG Summary
Thread-Index: AcfO2aorBpkLaHrSRn2w+nGWTn03rgAXy+UQ
From: "Stephen Hanna" 
To: 
X-Spam-Score: 0.60
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id
	l6Q3w8dx004841
Subject: [saag] IETF 69 NEA WG Summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 26 Jul 2007 03:58:08 -0000

The NEA WG met Monday, 23 July 2007, 1-3 PM CDT.

The NEA Requirements I-D 
is in WGLC. Several good comments have been received but more
were solicited. Seven new reviewers were signed up. Tim Polk
promised to help find more, especially from outside the WG.

Kaushik Narayan gave an overview of the current requirements
document, including a review of changes since IETF 68 and a
review of all the requirements. He raised several open issues
for discussion such as whether the requirements document
should contain non-normative design guidance. Consensus on
these items will be confirmed on the list. One question needs
more external input: whether the Privacy Considerations section
of the draft is adequate. Tim Polk will help us get input from
some privacy experts. Open discussion on the requirements
document ensued.

Steve Hanna reviewed the next steps for the WG. We'll finish
the WGLC on the requirements document and issue a revised I-D.
If the changes were major, we'll do another WGLC. When we have
WG consensus on the requirements document, we'll submit it to
the IESG for IETF LC and eventual publication as Informational.
When the document is ready, we'll revise our milestones and
begin work on the PA and PB protocols.


From tlyu@MIT.EDU Thu Jul 26 01:02:16 2007
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU
	[18.7.7.80])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l6Q52Gv6012469
	for ; Thu, 26 Jul 2007 01:02:16 -0400
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])
	by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l6Q529bo012175; Thu, 26 Jul 2007 01:02:09 -0400 (EDT)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU
	[18.18.1.96]) (authenticated bits=56)
	(User authenticated as tlyu@ATHENA.MIT.EDU)
	by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l6Q528Bj026195
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 26 Jul 2007 01:02:09 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308)
	id l6Q5270Y007070; Thu, 26 Jul 2007 01:02:07 -0400 (EDT)
To: saag@MIT.EDU
From: Tom Yu 
Date: Thu, 26 Jul 2007 01:02:07 -0400
Message-ID: 
Lines: 58
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
X-Spam-Flag: NO
X-Spam-Score: 0.00
Cc: ietf-sasl@imc.org
Subject: [saag] IETF69 SASL WG summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 26 Jul 2007 05:02:16 -0000

SASL WG
Wednesday, July 25, 2007, at 09:00-11:30

SUMMARY
=======

Thanks to Tony Hansen for scribing.

Document Status:

draft-ietf-sasl-crammd5-08	- needs writeup
draft-ietf-sasl-gs2-08		- needs publication request
draft-ietf-sasl-rfc2831bis-12	- needs document to designate as Historic
draft-cridland-sasl-hexa-00	- to merge with SCRAM
draft-newman-auth-scram-04	- to merge with HEXA
draft-zeilenga-sasl-yap-00	- probably to proceed as individual submission

Charter Discussion:

There is general agreement for charter as posted to list.  Add item
for document moving DIGEST-MD5 to Historic status.  We will poll WG
list on updated charter proposal.

Persue YAP as experimental or not?

As an individual, Sam would like SCRAM/HEXA to be implementable as a
GSS-API mechanism.  He would like to see the WG commit to this.  Needs
both GSS and SASL people to look at it to ensure it's sane from each
perspective.  Chris Newman, Nico Williams will help review this
aspect.

Milestones:

Document for moving DIGEST-MD5 to Historic - Alexey

Aug 2007:	-00 version
Sep 2007:	WGLC
Nov 2007:	to IESG

Implementation Report

Oct 2007:	initial implementation report questionnaire
Jan 2008:	send out questionnaire
Feb 2008:	compile results
Mar 2008:	discuss results
Apr 2008:	prepare final report & submit [also submit 4422bis]

rfc4422bis

Oct 2007:	-00 rev rfc4422 acap ref etc. correction - Kurt
Feb 2008:	WGLC 4422bis
Apr 2008:	submit 4422bis

SCRAM/HEXA

oct 2007:	-00 for combined HEXA/SCRAM
feb 2008:	WGLC HEXA/SCRAM
apr 2008:	combined HEXA/SCRAM to IESG

From ekr@networkresonance.com Thu Jul 26 09:19:59 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l6QDJxqG022414
	for ; Thu, 26 Jul 2007 09:19:59 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l6QDJunD009878
	for ; Thu, 26 Jul 2007 09:19:56 -0400 (EDT)
Received: from delta.rtfm.com (dhcp-11b6.ietf69.org [130.129.17.182])
	by mit.edu (Spam Firewall) with ESMTP id 86BA8719D57
	for ; Thu, 26 Jul 2007 09:19:51 -0400 (EDT)
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1])
	by delta.rtfm.com (Postfix) with ESMTP id 61E0F33C55
	for ; Thu, 26 Jul 2007 06:17:43 -0700 (PDT)
Date: Thu, 26 Jul 2007 06:17:42 -0700
From: Eric Rescorla 
To: saag@mit.edu
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20070726131743.61E0F33C55@delta.rtfm.com>
X-Spam-Score: 0
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] TLS WG Report
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 26 Jul 2007 13:19:59 -0000

TLS met in the first session on Tuesday Jul 24.

Agenda:

Document status       - chairs
TLS 1.2               - Eric Rescorla  (draft-ietf-tls-rfc4346bis-04)
TLS RSA-AES-GCM       - Joe Salowey    (draft-ietf-tls-rsa-aes-gcm-00)
Opaque PRF background - Tim Polk       (draft-rescorla-tls-opaque-prf-input-00)
GSS-API use cases     - Larry Zhu      (draft-santesson-tls-gssapi-02)


Eric Rescorla gave a report on the current state of TLS 1.2. 
There are no really contentious issues here. The biggest issues
are the precise rules for when alerts must be sent, and the
formats for carrying signatures. The signature issue is small
but detailed and important, so we'll take it to the list.
Then there's a new section on implementation pitfalls and then
we expect a fairly polished revision in fairly short order.

Joe Salowey presented on TLS RSA-AES-GCM, which is AES-GCM for
TLS. Nothing controversial here, but it became clear that some
generic text on how to handle CTR mode needs to be moved to TLS
1.2 and EKR took the action item for that.

Tim Polk gave a presentation about what he called making TLS
more useful for applications. His theme was that applications
wanted to [0]:

1. Contribute randomness to the TLS PRF (draft-rescorla-tls-opaque-prf-input)
2. Extract keying material out of the TLS handshake (draft-rescorla-tls-extractor)
There was quite a bit of pushback on (1) but modest levels of agreement
on (2). Pasi and I are discussing how to move forward on (2). Tim
agreed to go back and see if he can produce a better rationale
for (1).

Larry Zhu presented the use cases for a GSS-API integration with
TLS. This was very contentious. While this may turn out to be
worthwhile there doesn't seem to be consensus to move forward at this
time. We've talked to Larry a bit about what it would take to build
such a consensus.

[0] Note: the present author is the author of both drafts.

-Ekr


From julien.laganier@gmail.com Thu Jul 26 11:05:31 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l6QF5UBe011116
	for ; Thu, 26 Jul 2007 11:05:31 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l6QF5T6r011045
	for ; Thu, 26 Jul 2007 11:05:29 -0400 (EDT)
Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.190])
	by mit.edu (Spam Firewall) with ESMTP id 2FAB361815E
	for ; Thu, 26 Jul 2007 11:05:27 -0400 (EDT)
Received: by rv-out-0910.google.com with SMTP id g11so39293rvb
	for ; Thu, 26 Jul 2007 08:05:27 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender;
	b=cniT69FoEqagb8OhrMJf1ibHT1JsD7nKUZ0TGQDY3JubptdYay2rxzchMwzlZ0jAqbvArXiuq7QOkPr/K7TCc+33X6M/HhGmZE/efKJCxMj0BsSMMeEYmnMoQkHhD4qbLw92vsZIfO1enwJkRyCmbp7QeskNMg5/tNVgM/jRlYA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:from:to:subject:date:user-agent:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender;
	b=mDMUlVbLj+RVDL+AbCcGO4leesMCEO5YymqU2m1bOVyQuv+xtILwZWqM/EikZePyc9FgDMRzdNljPDQuq06peMls8iUwDbyiNEPgzlwYwd3IEsxcDj6MHIN/mIvOxciJXrpZiRT25LBBjMnImqBsmmsozLAvFhYbz0aoWInlDFc=
Received: by 10.141.1.2 with SMTP id d2mr576134rvi.1185462327396;
	Thu, 26 Jul 2007 08:05:27 -0700 (PDT)
Received: from ?130.129.99.249? ( [130.129.99.249])
	by mx.google.com with ESMTPS id l32sm3143633rvb.2007.07.26.08.05.25
	(version=SSLv3 cipher=OTHER); Thu, 26 Jul 2007 08:05:26 -0700 (PDT)
From: Julien Laganier 
To: SAAG mailing list 
Date: Thu, 26 Jul 2007 17:05:23 +0200
User-Agent: KMail/1.9.6
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200707261705.23858.julien.IETF@laposte.net>
Sender: julien laganier 
X-Spam-Score: 0.20
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: Love =?iso-8859-1?q?H=F6rnquist_=C5strand?= 
Subject: [saag] BTNS@IETF69 summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 26 Jul 2007 15:05:31 -0000

The BTNS WG met for one hour on Wednesday at IETF69. We 
had a short update on document status. So far, the WG 
milestones are met. 

Our AD Sam Hartman explained the issues he has with the 
problem and applicability statement document ruling 
mobility, NAT and multihoming out of scope. The WG 
will now discuss whether it wants to make those 
in-scope and solve associated issues, or whether they 
will remain out-of-scope.

The core document describing BTNS has been submitted to 
IESG for publication. Steve Kent also sent to the 
mailing list a bunch of comments on the document 
(Thanks Steve!), that may require the draft to be 
returned to the WG to address them.

Nicolas Williams gave a brief status update on the 
connexion latching document describing how to bind a 
given ULP communication (e.g. a TCP connexion) to a 
BTNS SA. Document needs an update to take into account 
IETF68 and mailing list discussions. It will then be 
WGLC'ed.

Michael Richardson gave a brief update on the design of 
the abstract BTNS API. The C-bindings API document was 
not presented but a new version has been submitted 
prior to the meeting. API documents would need more 
reviews, especially from application folks.

Best,

-- Julien & Love / BTNS chairs

From Shawn.Emery@Sun.COM Thu Jul 26 11:21:42 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l6QFLg3k014529
	for ; Thu, 26 Jul 2007 11:21:42 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l6QFLda1006994
	for ; Thu, 26 Jul 2007 11:21:39 -0400 (EDT)
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	by mit.edu (Spam Firewall) with ESMTP id CEE6E639133
	for ; Thu, 26 Jul 2007 11:21:38 -0400 (EDT)
Received: from fe-amer-04.sun.com ([192.18.108.178])
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	l6QFLbpx017115 for ; Thu, 26 Jul 2007 15:21:37 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
	(Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
	id <0JLS00501L1VLJ00@mail-amer.sun.com>
	(original mail from Shawn.Emery@Sun.COM) for saag@mit.edu; Thu,
	26 Jul 2007 09:21:37 -0600 (MDT)
Received: from shawn-emerys-computer.local ([129.150.35.207])
	by mail-amer.sun.com
	(Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
	with ESMTPSA id <0JLS00CZKLC1GS88@mail-amer.sun.com> for saag@mit.edu;
	Thu, 26 Jul 2007 09:21:37 -0600 (MDT)
Date: Thu, 26 Jul 2007 09:19:01 -0600
From: "Shawn M. Emery" 
Sender: Shawn.Emery@Sun.COM
To: saag@mit.edu
Message-id: <46A8BB65.9080008@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604)
X-Spam-Score: 0.001
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
X-Mailman-Approved-At: Thu, 26 Jul 2007 12:26:03 -0400
Subject: [saag] IETF 69 Kitten Working Group Summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 26 Jul 2007 15:21:42 -0000


The kitten-wg met Wednesday, 7/25/07, during the first afternoon session.

Two new co-chairs were announced; Alexey Melnikov and Shawn Emery.

The goals of the meeting were to go over the active working items and 
milestones.

A majority of the discussion of the session was on the two drafts that 
are currently in IESG:
draft-ietf-kitten-gssapi-domain-based-names
draft-ietf-kitten-gssapi-krb5-domain-based-names

specifically the topic on i18n in regards to domain name and host name 
slots.  It was decided that both would be defined as domain-names.  We 
are deferring the question to the krb-wg on how to handle encoding.

We decided to drop the pseudo-mech draft for now on the grounds that 
applications do a better job at negotiating mechanisms than negotiating 
mechanisms.  Work may pick up when mechanisms such as PFS and 
compression begin to materialize.

We've added a new milestone for the IANA document.

The naming extensions draft was also discussed and needs work in regards 
to breaking up Kerberos and PKIX examples into separate documents and to 
keep the core document with C-bindings.

Updates will be made to the Java bindings bis draft to include an 
appendix with the differences from RFC.

No volunteers for fostering the C-# bindings draft, will go to the 
mailing list for consensus on whether we should drop this item from the 
charter

We also had an open mic session which including a discussion on a need 
to having partially established tokens that are exported.  There was 
agreement that separate APIs would be needed to produce tokens with 
specific OIDs.

Shawn.
--

From gogwim@unijos.edu.ng Thu Jul 26 13:17:55 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l6QHHtpq016091
	for ; Thu, 26 Jul 2007 13:17:55 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l6QHHnDo001326
	for ; Thu, 26 Jul 2007 13:17:50 -0400 (EDT)
Received: from smtp.unijos.edu.ng (unknown [82.206.136.75])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 191BC63F316
	for ; Thu, 26 Jul 2007 13:10:17 -0400 (EDT)
Received: from localhost (smtp.unijos.edu.ng [127.0.0.1])
	by smtp.unijos.edu.ng (Postfix) with ESMTP id 938E76809B;
	Thu, 26 Jul 2007 17:49:08 +0100 (WAT)
X-Spam-Score: 0.40
X-Spam-Status: No, score=-3.758 tagged_above=-999 required=5
	tests=[ALL_TRUSTED=-1.8, AWL=0.641, BAYES_00=-2.599]
Received: from smtp.unijos.edu.ng ([127.0.0.1])
	by localhost (smtp.unijos.edu.ng [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id xo7OMdzl06sh; Thu, 26 Jul 2007 17:49:00 +0100 (WAT)
Received: from imap.unijos.edu.ng (imap.unijos.edu.ng [10.0.0.4])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp.unijos.edu.ng (Postfix) with ESMTP id D37E26809F;
	Thu, 26 Jul 2007 17:49:00 +0100 (WAT)
Received: from webmail.unijos.edu.ng (localhost [127.0.0.1])
	by imap.unijos.edu.ng (Postfix) with ESMTP id EFA402849E;
	Thu, 26 Jul 2007 18:32:23 +0100 (WAT)
Received: from 192.168.128.178 (SquirrelMail authenticated user gogwim)
	by webmail.unijos.edu.ng with HTTP;
	Thu, 26 Jul 2007 18:32:23 +0100 (WAT)
Message-ID: <2830.192.168.128.178.1185471143.squirrel@webmail.unijos.edu.ng>
In-Reply-To: <46A8BB65.9080008@sun.com>
References: <46A8BB65.9080008@sun.com>
Date: Thu, 26 Jul 2007 18:32:23 +0100 (WAT)
From: "GOGWIM, JOEL GODWIN" 
To: "Shawn M. Emery" 
User-Agent: SquirrelMail/1.4.4
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] IETF 69 Kitten Working Group Summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: gogwim@unijos.edu.ng
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 26 Jul 2007 17:17:55 -0000

A big congratulations to Alexey Melnikov and Shawn Emery.

On Thu, July 26, 2007 4:19 pm, Shawn M. Emery said:
>
> The kitten-wg met Wednesday, 7/25/07, during the first afternoon session.
>
> Two new co-chairs were announced; Alexey Melnikov and Shawn Emery.
>
> The goals of the meeting were to go over the active working items and
> milestones.
>
> A majority of the discussion of the session was on the two drafts that
> are currently in IESG:
> draft-ietf-kitten-gssapi-domain-based-names
> draft-ietf-kitten-gssapi-krb5-domain-based-names
>
> specifically the topic on i18n in regards to domain name and host name
> slots.  It was decided that both would be defined as domain-names.  We
> are deferring the question to the krb-wg on how to handle encoding.
>
> We decided to drop the pseudo-mech draft for now on the grounds that
> applications do a better job at negotiating mechanisms than negotiating
> mechanisms.  Work may pick up when mechanisms such as PFS and
> compression begin to materialize.
>
> We've added a new milestone for the IANA document.
>
> The naming extensions draft was also discussed and needs work in regards
> to breaking up Kerberos and PKIX examples into separate documents and to
> keep the core document with C-bindings.
>
> Updates will be made to the Java bindings bis draft to include an
> appendix with the differences from RFC.
>
> No volunteers for fostering the C-# bindings draft, will go to the
> mailing list for consensus on whether we should drop this item from the
> charter
>
> We also had an open mic session which including a discussion on a need
> to having partially established tokens that are exported.  There was
> agreement that separate APIs would be needed to produce tokens with
> specific OIDs.
>
> Shawn.
> --
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://mailman.mit.edu/mailman/listinfo/saag
>


       ~          Gogwim, Joel Godwin
      *.*         UNIVERSITY OF JOS, NIGERIA
     / v \        NETWORK DEPARTMENT, CISCO RA.
    /(..) \       TEL: +234-8036058175
   / < - > \      E-mail: gogwim@unijos.edu.ng,
  /^^^^-^^^^\             gogwim2000@yahoo.com,
 /~~~~~~~~~~~\            gogwim@gmail.com
  |Thank God|     URL: http://www.unijos.edu.ng
  |for my   |
  |House.   |
  ====| |====


From jsalowey@cisco.com Thu Jul 26 13:59:37 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l6QHxbKF003610
	for ; Thu, 26 Jul 2007 13:59:37 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l6QHxZI8004394
	for ; Thu, 26 Jul 2007 13:59:35 -0400 (EDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86])
	by mit.edu (Spam Firewall) with ESMTP id 7D57A40A6E3
	for ; Thu, 26 Jul 2007 13:59:34 -0400 (EDT)
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-4.cisco.com with ESMTP; 26 Jul 2007 10:59:33 -0700
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CAD13qEarR7PD/2dsb2JhbAA
X-IronPort-AV: i="4.16,584,1175497200"; d="scan'208"; a="7313973:sNHT14938350"
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6QHxXcv018819
	for ; Thu, 26 Jul 2007 10:59:33 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6QHxKSt004027
	for ; Thu, 26 Jul 2007 17:59:33 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 26 Jul 2007 10:59:28 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Thu, 26 Jul 2007 10:59:34 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IETF 69 EMU WG Summary
Thread-Index: AcfPrrlUwqK6YPZaTQKY5NlIrMYgPg==
From: "Joseph Salowey (jsalowey)" 
To: 
X-OriginalArrivalTime: 26 Jul 2007 17:59:28.0430 (UTC)
	FILETIME=[B5C69CE0:01C7CFAE]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=674; t=1185472773;
	x=1186336773; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jsalowey@cisco.com;
	z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20
	|Subject:=20IETF=2069=20EMU=20WG=20Summary |Sender:=20;
	bh=vWJzTL1tNUJo7bWXBAPxW7aVTAHx67ncwLZiyjgHWzM=;
	b=oND9Ovxk9K0Q2DWhFwV4gsLMHC5K59gR0kLPWlNjTtgg8tDbo3ujCVOdIwXlVxrlhiOZA2CC
	zH/HrkH2NbAIkNx+6hZNEt9+wnjuLcLVyAEKizquVLxNBjfhgCxqDnEF;
Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: 0.60
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id
	l6QHxbKF003610
Subject: [saag] IETF 69 EMU WG Summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 26 Jul 2007 17:59:37 -0000

EMU meet on Tuesday Afternoon
-------------------------------

RFC2716bis (EAP-TLS) is ready to go to the IESG and EAP-GPSK should be
soon to follow.   We had a liaison presentation from 802.11u on the
requirements for an EAP method for emergency services.  We then had two
presentations on Password based EAP-Methods; PP-EAP and EAP-TTLS.  Both
approaches were focusing beyond password mechanisms to providing general
tunneling capabilities. There was rough consensus in the room to focus
on a password mechanism.  There was interest in the room in basing this
mechanism on EAP-TTLS.   The next step is to find consensus on the list
and plot a way forward.  


From jhutz@cmu.edu Thu Jul 26 15:32:14 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l6QJWEAB002175
	for ; Thu, 26 Jul 2007 15:32:14 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l6QJWCAC017350
	for ; Thu, 26 Jul 2007 15:32:12 -0400 (EDT)
Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161])
	by mit.edu (Spam Firewall) with SMTP id 65FCD3FB1D9
	for ; Thu, 26 Jul 2007 15:32:10 -0400 (EDT)
Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu
	id aa18716; 26 Jul 2007 15:31 EDT
Date: Thu, 26 Jul 2007 15:31:30 -0400 (EDT)
From: Jeffrey Hutzelman 
X-X-Sender: 
To: , 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] Summary of krb-wg sessions at IETF 69
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 26 Jul 2007 19:32:14 -0000

Kerberos Working Group - IETF 69 meeting summary

ACTION ITEMS:

* jhutz: Send updated milestones to IESG secretary
* jhutz: Send PKINIT ECC to IESG
* jhutz: Review set/change password and send to AD (pending update from nico)
* jhutz: Send naming to IESG (holding to send with anon)
* jhutz: Start WGLC on anonymous
* lzhu: Start WGLC on GSS-KRB5 hash agility
* nico: Submit corrected version of set/change password
* lha: Finish work on PKINIT hash agility implementation and update document
* leif: Update data model document to reflect feedback
* hartmans/lzhu: Update preauth-fw document to reflect feedback
* jhutz/lzhu: Find co-editors for i18n/negotiation doc
* sakane: Request review of cross-realm on the mailing list, and update the
  document to reflect comments from the meeting plus any received on the list.

DECISIONS (to be validated):

* preauth-fw: add a pa-data item to PA-AUTHENTICATION-SET-ELEM
* cross-realm: include problems of interest, even if we won't solve them
* cross-realm: all six points currently included are problems of interest


SESSION SUMMARY:

The Kerberos WG met twice this week.  During the first session, Sam
Hartman and Tom Yu presented a proposal they are putting forward along
with Nicolas Williams and Larry Zhu, to change the direction of work on
the next revision of the Kerberos specification.  The remainder of the
session was spent on discussion of the proposal.

The second session began with a brief review of the WG's active documents,
including several which are in the queue to go to WGLC, some which have
passed WGLC and are waiting for a writeup, and a few that need a bit more
work before they are ready to go.

Leif Johansson gave us an update on the KDC data model document, and raised
a few open issues on which he wanted input from the working group.  This
was followed by discussion, and Leif will submit a new version of the
document based on feedback received.

Sam and Larry gave an update on the preauth framework document.  They
reviewed the resolution of several previously-open issues, and discussed
some on which input was still needed.  There will be further discussion on
the mailing list, followed by an updated version of the document.  This
document should be nearly ready for WGLC, except that it will likely need
changes if the v5.3-via-FAST proposal from Monday is adopted.

Shoichi Sakane gave an overview of the cross-realm problems document, and
asked for input from the WG on whether we agree that all of the listed
items are in fact problems which should be discussed here.  The sense of
the room was that all six items listed are indeed problems, and that they
should be included in the document regardless of whether the working group
intends to find solutions for them.


From tlr+bounce@w3.org Sat Jul 28 15:06:35 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l6SJ6ZC9001033
	for ; Sat, 28 Jul 2007 15:06:35 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l6SJ6SRs025317
	for ; Sat, 28 Jul 2007 15:06:28 -0400 (EDT)
Received: from homer.w3.org (homer.w3.org [128.30.52.30])
	by mit.edu (Spam Firewall) with ESMTP id 494767246C6
	for ; Sat, 28 Jul 2007 15:06:28 -0400 (EDT)
Received: from raktajino.does-not-exist.org (homer.w3.org [128.30.52.30])
	by homer.w3.org (Postfix) with ESMTP id C81594EFB8;
	Sat, 28 Jul 2007 15:06:27 -0400 (EDT)
Received: from roessler by raktajino.does-not-exist.org with local (Exim 4.66)
	(envelope-from )
	id 1IErcM-0005Nf-0O; Sat, 28 Jul 2007 15:06:22 -0400
Date: Sat, 28 Jul 2007 15:06:21 -0400
From: Thomas Roessler 
To: saag@mit.edu
Message-ID: <20070728190621.GP2974@raktajino.does-not-exist.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.16 (2007-07-16)
X-Spam-Score: 0.12
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id
	l6SJ6ZC9001033
Cc: tlr@w3.org
Subject: [saag] W3C work on XML Signature
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sat, 28 Jul 2007 19:06:35 -0000

(In sending this message, I'm assuming that the earlier one
mistakenly sent to saag@ietf.org went into some black hole.  This is
a quick summary of what I said during the open mike period at
Thursday's SAAG meeting.)

W3C is working on a second edition of XML Signature Syntax and
Processing, mostly focused on editorial changes and clarifications
without affecting conformance.  The one significantly
conformance-affecting change that is expected concerns a changeover
from C14N 1.0 to C14N 1.1.  This is done by recommending use of
existing extensibility mechanisms; we are not expecting to change
the semantics of existing messages.

You can glance over the editor's shoulder here:

  http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/ 

This version has change marks, so it should be easy enough to figure
out what we're up to.  Comments welcome.


To assess what steps to take next, we're organizing a workshop for
25/26 September in Mountain View:

  http://www.w3.org/2007/xmlsec/ws/cfp

Participants must be affiliated with (short) position papers; these
should have 1-5 pages and are due 14 August.  Please do not send 30
page scientific treatises as position papers. ;-)

If you have any questions about the workshop, please don't hesitate
to ask.

Thanks,
-- 
Thomas Roessler, W3C  


From bernard_aboba@hotmail.com Sat Aug  4 15:52:54 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l74JqsJv009347
	for ; Sat, 4 Aug 2007 15:52:54 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l74JqqAL026883
	for ; Sat, 4 Aug 2007 15:52:52 -0400 (EDT)
Received: from bay0-omc3-s35.bay0.hotmail.com (bay0-omc3-s35.bay0.hotmail.com
	[65.54.246.235]) by mit.edu (Spam Firewall) with ESMTP id 1451762E41F
	for ; Sat,  4 Aug 2007 15:52:51 -0400 (EDT)
Received: from hotmail.com ([207.46.8.98]) by bay0-omc3-s35.bay0.hotmail.com
	with Microsoft SMTPSVC(6.0.3790.2668); 
	Sat, 4 Aug 2007 12:52:51 -0700
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	Sat, 4 Aug 2007 12:52:50 -0700
Message-ID: 
Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP;
	Sat, 04 Aug 2007 19:52:46 GMT
X-Originating-IP: [71.197.208.131]
X-Originating-Email: [bernard_aboba@hotmail.com]
X-Sender: bernard_aboba@hotmail.com
From: "Bernard Aboba" 
To: saag@mit.edu
Date: Sat, 04 Aug 2007 12:52:46 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 04 Aug 2007 19:52:50.0954 (UTC)
	FILETIME=[0A1D26A0:01C7D6D1]
X-Spam-Score: 0.12
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
X-Mailman-Approved-At: Mon, 06 Aug 2007 09:08:54 -0400
Subject: [saag] Security review of RADIUS crypto-agility proposals?
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sat, 04 Aug 2007 19:52:54 -0000

The RADEXT WG is debating the merits of several proposals for RADIUS 
crypto-agility.  Since the selection process will substantially impact the 
future of RADIUS, we are looking to solicit reviews of one or more of the 
proposals:

RADIUS over DTLS: 
http://www.ietf.org/internet-drafts/draft-dekok-radext-dtls-00.txt
RADIUS over TCP/TLS: 
http://www.ietf.org/internet-drafts/draft-winter-radsec-00.txt
RADIUS Crypto-agility:
http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-13.txt
http://www.ietf.org/internet-drafts/draft-zorn-radius-encattr-06.txt
HOKEY key distribution:
http://www.ietf.org/internet-drafts/draft-gaonkar-radext-erp-attrs-00.txt

The selection process is summarized here:
http://ops.ietf.org/lists/radiusext/2007/msg00048.html
The protocol requirements are available here:
http://ops.ietf.org/lists/radiusext/2007/msg00053.html



From Craemer@isoc.org Mon Aug  6 13:56:21 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l76HuL0p016320
	for ; Mon, 6 Aug 2007 13:56:21 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l76HuIr0008401
	for ; Mon, 6 Aug 2007 13:56:18 -0400 (EDT)
Received: from smtp120.iad.emailsrvr.com (smtp120.iad.emailsrvr.com
	[207.97.245.120])
	by mit.edu (Spam Firewall) with ESMTP id 677A666DC32
	for ; Mon,  6 Aug 2007 13:56:17 -0400 (EDT)
Received: by relay2.r2.iad.emailsrvr.com (Authenticated sender:
	craemer-AT-isoc.org) with ESMTP id E6A5644C371
	for ; Mon,  6 Aug 2007 13:56:16 -0400 (EDT)
From: "Kevin Craemer" 
To: 
Date: Mon, 6 Aug 2007 14:01:56 -0400
Message-ID: <003801c7d853$e0945090$f601a8c0@ISOC.local>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
Thread-Index: AcfYU+Bf765g6P3QR0qt4GWvOOuIeA==
X-Spam-Score: 0.43
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id
	l76HuL0p016320
X-Mailman-Approved-At: Mon, 06 Aug 2007 14:28:01 -0400
Subject: [saag] 15th Annual Network & Distributed System Security Symposium
	- Call for Papers
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Mon, 06 Aug 2007 17:56:21 -0000


Please consider responding to this Call for Papers.

Kevin Craemer
Internet Society

= = = = = = = = =

CALL FOR PAPERS

The 15th Annual Network and Distributed System Security Symposium
The Dana on Mission Bay, San Diego, California
February 10-13, 2008

IMPORTANT DATES:
Paper & panel submissions due: 11:59pm PDT, Friday, Sep 21, 2007.
Author notification: Monday, Nov 5, 2007.
Final version of papers and panels due: Dec 15, 2007.

GOAL:
The symposium fosters information exchange among research scientists and practitioners of network and distributed system security services.  The target audience includes those interested in practical aspects of network and distributed system security, with a focus on actual system design and implementation (rather than theory). A major goal is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. This year's symposium continues our theme of "theory meets practice" so we encourage submission both from traditional academic researchers as well as industrial practitioners of applied security with innovative insights.

The proceedings are published by the Internet Society.

HOW TO SUBMIT:
Submission instructions are available at
http://www.isoc.org/tools/conferences/NDSS08

SUBMISSIONS:
Both technical papers and panel proposals are solicited. Technical papers must not substantially overlap with papers that have been published or that are simultaneously submitted to a journal or a conference with proceedings.  All papers from authors perpetrating such "double submissions" will be immediately rejected from the symposium. The Program Committee reserves the right to share information with other conference chairs and journal editors so as to detect such cases.

Technical papers should be at most 12 pages excluding the bibliography and well-marked appendices (using 11-point font, single column format, and reasonable margins on 8.5"x11" or A4 paper), and at most 20 pages total.  Committee members are not required to read the appendices, so the paper should be intelligible without them. Technical papers will appear in the proceedings.  Panel proposals should be one page and must describe the topic, identify the panel chair, explain the panel format, and list three to four potential panelists. A description of each panel will appear in the proceedings, and may, at the discretion of the panel chair, include written position statements from the panelists.

Submissions are solicited in, but not limited to, the following areas:

- Integrating security in Internet protocols: routing, naming, TCP/IP, multicast, network management, and the Web.
- Intrusion prevention, detection, and response: systems, experiences and architectures.
- Privacy and anonymity technologies.
- Network perimeter controls: firewalls, packet filters, application gateways.
- Virtual private networks.
- Security for emerging technologies: sensor networks, specialized testbeds, wireless/mobile (and ad hoc) networks, personal communication systems.
- ID systems, peer-to-peer and overlay network systems.
- Secure electronic commerce: e.g., payment, barter, EDI, notarization, timestamping, endorsement, and licensing.
- Supporting security mechanisms and APIs; audit trails; accountability.
- Implementation, deployment and management of network security policies.
- Intellectual property protection: protocols, implementations, metering, watermarking, digital rights management.
- Fundamental services on network and distributed systems: authentication, data integrity, confidentiality, authorization, non-repudiation, and availability.
- Integrating security services with system and application security facilities and protocols: e.g., message handling, file transport/ access, directories, time synchronization, data base management, boot services, mobile computing.
- Public key infrastructure, key management, certification, and revocation.
- Special problems and case studies: e.g., tradeoffs between security and efficiency, usability, reliability and cost.
- Security for collaborative applications: teleconferencing and video-conferencing, electronic voting, groupwork, etc.
- Software hardening: e.g., detecting and defending against software bugs (overflows, etc.)
- Security for large-scale systems and critical infrastructures.
- Security of Web-based applications and services.

Each submission must be accompanied by a separate, electronically submitted Submission Over-view specifying the submission type (paper or panel), the title or topic, author names with organizational affiliations, and must specify a contact author along with corresponding phone number, FAX number, postal address and email address.

Submissions must be received by 11:59pm PDT, September 21, 2007, and must be made electronically in PDF format (for example, by using pdflatex). Each submission will be acknowledged by e-mail; if acknowledgment is not received within seven days, contact a program co-chair (see below). Authors and panelists will be notified of acceptance by November 5th, 2007, and given instructions for preparing the camera-ready copy.

PROGRAM COMMITTEE:
- Crispin Cowan, Novell (Program co-chair)
- Giovanni Vigna, UC Santa Barbara (Program co-chair)
- Lujo Bauer, Carnegie Mellon University
- Konstantin Beznosov, UBC
- John Black, University of Colorado
- David Brumley, Carnegie Mellon University
- Jon Callas, PGP
- Hao Chen, UC Davis
- Charles Clarke, University of Waterloo
- Vinod Ganapathy, University of Wisconsin
- Jonathon Giffin, Georgia Tech
- Farnam Jahanian, University of Michigan
- Angelos Keromytis, Columbia University
- Engin Kirda, Vienna University of Technology
- Christopher Kruegel, Vienna University of Technology
- Ben Laurie, Google
- Wenke Lee, Georgia Tech
- Michael Locasto, Columbia University
- Fabian Monrose, Johns Hopkins University
- Niels Provos, Google
- Len Sassaman, Katholieke Universiteit Leuven
- R. Sekar, SUNY Stonybrook
- Sean Smith, Dartmouth College
- Zhendong Su, UC Davis
- Nick Weaver, ICSI

Additional details on the Symposium can be found at:
http://www.isoc.org/isoc/conferences/ndss/08/




From Jeff.Hodges@KingsMountain.com Wed Aug 15 13:15:35 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l7FHFZiW010327
	for ; Wed, 15 Aug 2007 13:15:35 -0400
Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l7FHFULi000585
	for ; Wed, 15 Aug 2007 13:15:31 -0400 (EDT)
Received: from smtp2.stanford.edu (smtp2.stanford.edu [171.67.20.25])
	by mit.edu (Spam Firewall) with ESMTP id BF914450F06
	for ; Wed, 15 Aug 2007 13:14:57 -0400 (EDT)
Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1])
	by localhost (Postfix) with SMTP id F12FF4CCB5
	for ; Wed, 15 Aug 2007 10:14:56 -0700 (PDT)
Received: from networking.Stanford.EDU (networking.Stanford.EDU [171.64.20.23])
	by smtp2.stanford.edu (Postfix) with ESMTP id CDA814CC37
	for ; Wed, 15 Aug 2007 10:14:56 -0700 (PDT)
Received: from networking.Stanford.EDU (hodges@localhost)
	by networking.Stanford.EDU (8.11.7/8.11.6) with ESMTP id l7FHEuY22190
	for ; Wed, 15 Aug 2007 10:14:56 -0700 (PDT)
Message-Id: <200708151714.l7FHEuY22190@networking.Stanford.EDU>
X-Authentication-Warning: networking.Stanford.EDU: hodges owned process doing
	-bs
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2
To: Security Area Advisory Group 
From: Jeff.Hodges@KingsMountain.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 15 Aug 2007 10:14:56 -0700
X-Spam-Score: 0.68
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] fyi: CFP: Trust and the Future of the Internet
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: Security Area Advisory Group 
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 15 Aug 2007 17:15:35 -0000

I don't see this on the list as yet, so here goes just in case...

=JeffH

http://www.isoc.org/isoc/general/trustees/headlines/20070809.shtml

Call for Participation: Trust and the Future of the Internet

The Internet Society (ISOC) Board of Trustees is currently engaged in a 
discovery process to define a long term Major Strategic Initiative to ensure 
that the Internet of the future remains accessible to everyone. The Board 
believes that Trust is an essential component of all successful relationships 
and that an erosion of Trust: in individuals, networks, or computing 
platforms, will undermine the continued health and success of the Internet.

The Board will meet in special session the first week October of 2007 for 
intensive study focused on the subject of trust within the context of network 
enabled relationships. As part of this process, the Board is hereby issuing a 
call for subject experts who can participate in the two day discussion. Topics 
of interest include: the changing nature of trust, security, privacy, control 
and protection of personal data, methods for establishing authenticity and 
providing assurance, management of threats, and dealing with unwanted traffic.

Participants will be selected based on a short paper summarizing individual 
interests and qualifications as well as availability. The retreat will be held 
in Toronto, Ontario (CA) . Travel and accommodation costs will be covered by 
ISOC and participants should expect to arrive October 4th and depart on the 
6th or 7th. Expressions of interest may be emailed to: 
oct07-retreat@elists.isoc.org and papers should not exceed three pages. Papers 
must received by August 24th, 2007 and the Program Committee will make their 
selections on or before September 7th, 2007. Subject experts will be allotted 
one hour for presentation on October 5th and will be included in the days 
round-table discussions. In order to facilitate open discussion, final 
presentation materials should be forwarded to ISOC no later than September 
21st, 2007.

We look forward to a lively and informative meeting on this important topic 
and encourage you to share this announcement with your communities of 
interest."

Lucy Lynch
Director of Technical Projects
Internet Society (ISOC)

---
end



From hartmans@MIT.EDU Tue Aug 21 14:32:16 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l7LIWGFV019199
	for ; Tue, 21 Aug 2007 14:32:16 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l7LIWEB9007736
	for ; Tue, 21 Aug 2007 14:32:14 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (STRATTON-SIX-THIRTY.MIT.EDU
	[18.187.7.119]) by mit.edu (Spam Firewall) with ESMTP id 6331A6C9221
	for ; Tue, 21 Aug 2007 14:32:14 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042)
	id D2B6048C5; Tue, 21 Aug 2007 14:32:13 -0400 (EDT)
From: Sam Hartman 
To: "Bernard Aboba" 
References: 
Date: Tue, 21 Aug 2007 14:32:13 -0400
In-Reply-To:  (Bernard Aboba's
	message of "Sat, 04 Aug 2007 12:52:46 -0700")
Message-ID: 
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] Security review of RADIUS crypto-agility proposals?
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 21 Aug 2007 18:32:17 -0000

Bernard, if you want secdir reviews of any of these drafts feel free
to correspond with secdir-secretary@mit.edu

From hartmans@MIT.EDU Wed Aug 22 15:46:03 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l7MJjxgg017352
	for ; Wed, 22 Aug 2007 15:46:03 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l7MJjwxr014808
	for ; Wed, 22 Aug 2007 15:45:58 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (localhost [127.0.0.1])
	by mit.edu (Spam Firewall) with ESMTP id 8A210820E68
	for ; Wed, 22 Aug 2007 15:45:57 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (dhcp-18-188-10-61.dyn.MIT.EDU
	[18.188.10.61]) by mit.edu with ESMTP id p1k8TQPAxyyfWzRe for
	; Wed, 22 Aug 2007 15:45:57 -0400 (EDT)
Received-SPF: softfail (mit.edu: domain of transitioning hartmans@mit.edu does
	not designate 18.188.10.61 as permitted sender)
	receiver=mit.edu; client_ip=18.188.10.61;
	envelope-from=hartmans@mit.edu; 
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042)
	id 1CFC848C3; Wed, 22 Aug 2007 15:45:57 -0400 (EDT)
From: Sam Hartman 
To: saag@MIT.EDU
Date: Wed, 22 Aug 2007 15:45:57 -0400
Message-ID: 
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: tim.polk@nist.gov
Subject: [saag] draft minutes uploaded
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 22 Aug 2007 19:46:04 -0000



Hi.  I've uploaded minutes.  They were kind of sparse; please let me
know if I missed something critical or you have other improvements.

The minutes can be found in the IETF 69 meeting materials tool.

From kent@bbn.com Thu Aug 23 13:57:55 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l7NHvseX016785
	for ; Thu, 23 Aug 2007 13:57:55 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l7NHvopu026123
	for ; Thu, 23 Aug 2007 13:57:50 -0400 (EDT)
Received: from mx12.bbn.com (localhost [127.0.0.1])
	by mit.edu (Spam Firewall) with ESMTP id 8F98C55B568
	for ; Thu, 23 Aug 2007 13:57:49 -0400 (EDT)
Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by mit.edu with ESMTP
	id zZQDDm9dJ4LHCy9g for ;
	Thu, 23 Aug 2007 13:57:49 -0400 (EDT)
Received-SPF: pass (mit.edu: domain of kent@bbn.com designates 128.33.0.81 as
	permitted sender) receiver=mit.edu; client_ip=128.33.0.81;
	envelope-from=kent@bbn.com; 
Received: from dhcp89-089-071.bbn.com ([128.89.89.71])
	by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from )
	id 1IOGwH-0000KK-4B for saag@mit.edu; Thu, 23 Aug 2007 13:57:49 -0400
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <200708151714.l7FHEuY22190@networking.Stanford.EDU>
References: <200708151714.l7FHEuY22190@networking.Stanford.EDU>
Date: Thu, 23 Aug 2007 13:46:43 -0400
To: Security Area Advisory Group 
From: Stephen Kent 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: Re: [saag] fyi: CFP: Trust and the Future of the Internet
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 23 Aug 2007 17:57:55 -0000

Lucy,

I would normally respond to this CFP, but I will be on vacation in 
the Galapagos for most of October.

Hope the meeting goes well,

Steve

From hartmans@MIT.EDU Fri Sep  7 21:17:48 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l881HmD0020770
	for ; Fri, 7 Sep 2007 21:17:48 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l881HgVS005622
	for ; Fri, 7 Sep 2007 21:17:43 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org
	(STRATTON-ONE-TWENTY-TWO.MIT.EDU [18.187.5.122])
	by mit.edu (Spam Firewall) with ESMTP id 482D7C0910D
	for ; Fri,  7 Sep 2007 21:17:20 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042)
	id 5FA1E48C4; Fri,  7 Sep 2007 21:16:55 -0400 (EDT)
From: Sam Hartman 
To: saag@MIT.EDU
Date: Fri, 07 Sep 2007 21:16:55 -0400
Message-ID: 
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.28
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] [Lakshminath Dondeti] Nomcom 2007-8: Nominations Close on
	Sep 10, 2007
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sat, 08 Sep 2007 01:17:48 -0000

--=-=-=



Folks, I think it is important to our process that nomcom have a strong set of candidates.
I'd appreciate it if you would take the time Monday to look over the people you think contribute to the security area and nominate those who you think would make a good AD.

--Sam


--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline

Return-Path: 
Received: from localhost ([unix socket])
	by mail.suchdamage.org (Cyrus v2.2.13-Debian-2.2.13-10) with LMTPA;
	Fri, 07 Sep 2007 15:52:45 -0400
X-Sieve: CMU Sieve 2.2
Received: from south-station-annex.mit.edu (SOUTH-STATION-ANNEX.MIT.EDU
	[18.72.1.2])
	by mail.suchdamage.org (Postfix) with ESMTP id 3C716230E1
	for ; Fri,  7 Sep 2007 15:52:44 -0400 (EDT)
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by south-station-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l87JqhiK023579
	for ; Fri, 7 Sep 2007 15:52:43 -0400 (EDT)
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l87Jqaxp023402
	for ; Fri, 7 Sep 2007 15:52:36 -0400 (EDT)
Received: from megatron.ietf.org (stiedprmman1.ietf.ORG [156.154.16.145])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 21DB573501F
	for ; Fri,  7 Sep 2007 15:52:36 -0400 (EDT)
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1ITjsZ-0006fV-Hx; Fri, 07 Sep 2007 15:52:35 -0400
Received: from iesg by megatron.ietf.org with local (Exim 4.43)
	id 1ITjsY-0006Wu-EU
	for iesg-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 15:52:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1ITjsY-0006Ua-3P; Fri, 07 Sep 2007 15:52:34 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1ITjsW-00027j-QH; Fri, 07 Sep 2007 15:52:34 -0400
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l87JqT0H017541
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 7 Sep 2007 12:52:30 -0700
Received: from [10.50.69.196] (qconnect-10-50-69-196.qualcomm.com
	[10.50.69.196])
	by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l87JqSO1025798
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 7 Sep 2007 12:52:29 -0700
Message-ID: <46E1AC01.3050800@qualcomm.com>
Date: Fri, 07 Sep 2007 12:52:33 -0700
From: Lakshminath Dondeti 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
To: ietf-announce@ietf.org, wgchairs@ietf.org, IESG IESG ,
	IAB IAB 
X-Spam-Score: 0.28
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: 
Subject: Nomcom 2007-8: Nominations Close on Sep 10, 2007
X-BeenThere: iesg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: iesg.ietf.org
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: iesg-bounces@ietf.org
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
X-DSPAM-Result: Whitelisted
X-DSPAM-Processed: Fri Sep  7 15:52:45 2007
X-DSPAM-Confidence: 0.9997
X-DSPAM-Probability: 0.0000
X-DSPAM-Signature: 46e1ac0d65861052712533
X-DSPAM-Factors: 27,
	List-Archive*, 0.00010,
	List-Unsubscribe*, 0.00010,
	List-Id*iesg.ietf.org, 0.00010, List-Help*iesg, 0.00010,
	X-BeenThere*iesg+ietf.org, 0.00010,
	List-Subscribe*//www1.ietf.org/mailman/listinfo/iesg>, 0.00010,
	List-Unsubscribe*//www1.ietf.org/mailman/listinfo/iesg>, 0.00010,
	List-Subscribe*, 0.00010, 
	Errors-To*iesg, 0.00010, List-Help*, 0.00010, X-BeenThere*iesg, 0.00010,
	Received*for+iesg, 0.00010, Received*iesg, 0.00010,
	Received*iesg, 0.00010, Errors-To*iesg+bounces, 0.00010,
	List-Post*iesg, 0.00010,
	List-Archive*//www1.ietf.org/mailman/private/iesg>, 0.00010,
	From*Lakshminath Dondeti , 0.00012,
	IESG, 0.00022, To*, 0.00028,
	IAB, 0.00042, IAB, 0.00042, IESG+and, 0.00053
MIME-Version: 1.0

WGchairs, IESG and IAB members

Please forward this request to the lists you manage and request feedback 
and nominations.

All,

Here is the link to nominate: 
https://tools.ietf.org/group/nomcom/07/nominate

You may also send nominations or comments via email to nomcom07@ietf.org 
or ldondeti@qualcomm.com.

We have received very few nominations (1, 2, 2, 2, 3, 4, 8, 8, 19) and 
even fewer accepted (1-2 people in each area, IAB acceptances is 4 at 
last count).

I request the community to provide feedback on the incumbents (send 
email or send notes via the web page).

1) If you think that the incumbent is doing a good job
     a) provide feedback AND
     b) nominate similar people just in case there is strong negative 
feedback on the incumbent

2) If you think the incumbent can do somethings better
    a) provide feedback AND
    b) nominate someone who you think might do better

Candidates, if time commitment is the only issue, please indicate that 
to the nomcom and accept the nominations.

thanks,
Lakshminath




--=-=-=--

From ekr@networkresonance.com Sat Sep  8 16:57:28 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l88KvGOE010922
	for ; Sat, 8 Sep 2007 16:57:16 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l88Kv6Wj026572
	for ; Sat, 8 Sep 2007 16:57:10 -0400 (EDT)
Received: from delta.rtfm.com (unknown [74.95.2.169])
	by mit.edu (Spam Firewall) with ESMTP id 83D529B82E4
	for ; Sat,  8 Sep 2007 16:57:03 -0400 (EDT)
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1])
	by delta.rtfm.com (Postfix) with ESMTP id 82EC933C39;
	Sat,  8 Sep 2007 13:53:37 -0700 (PDT)
Date: Sat, 08 Sep 2007 13:53:36 -0700
From: Eric Rescorla 
To: Alexey Melnikov 
In-Reply-To: <46E2E54A.2050406@isode.com>
	<86bqcc3nkk.wl%ekr@networkresonance.com>
References: <46E2E54A.2050406@isode.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20070908205337.82EC933C39@delta.rtfm.com>
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: ietf-http-auth@osafoundation.org, discuss@apps.ietf.org, saag@mit.edu,
	ietf@ietf.org, ietf-http-wg@w3.org
Subject: Re: [saag] [Ietf-http-auth] Next step on web phishing draft
	(draft-hartman-webauth-phishing-05.txt)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sat, 08 Sep 2007 20:57:29 -0000

Alexey wrote:
> This message is trying to summarize recent discussions on 
> draft-hartman-webauth-phishing-05.txt.
> 
> Several people voiced their support for the document (on IETF mailing 
> list and in various other off-list discussions). Ekr doesn't think that 
> the document should be published in the current form and he has some 
> good technical points that need to be addressed. At least one more 
> revision is needed to addressed recent comments from Ekr and SecDir review.
> 
> It is quite clear that some people got confused about intended status of 
> this document and whether it represents IETF consensus. Sam has 
> clarified what was his intention, but another consensus call is needed 
> to make sure people agree with Sam.
> 
> Subsequent discussions and consensus calls on the document would happen 
> on .
> 
> Alexey,
> in my capacity of shepherd for draft-hartman-webauth-phishing


I object to this procedure.

This document has already had an IETF Last Call, where it failed to
achieve consensus. At this point, it doesn't need additional last
calls to "make sure that people agree with Sam", but rather to go back
to the authors to try to build support in the community. Not liking
the result of the previous Last Call is not a sufficient basis for
issuing another one.

At some point in the future, it may be appropriate to issue another
consensus call, but since this is not a WG mailing list--indeed, the
IESG has twice declined to charter a WG in this area--nor are you the
chair, it doesn't seem to me that you have standing to do that. When
that time comes, I would expect the IESG to designate an appropriate
time and place.

-Ekr

From aboba@internaut.com Sat Sep  8 19:52:18 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l88NqIEP026033
	for ; Sat, 8 Sep 2007 19:52:18 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l88NqCtt018738
	for ; Sat, 8 Sep 2007 19:52:12 -0400 (EDT)
Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id C71CFC3DCC1
	for ; Sat,  8 Sep 2007 19:52:10 -0400 (EDT)
Received: from c-71-197-208-131.hsd1.or.comcast.net ([71.197.208.131]
	helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.68)
	(envelope-from )
	id 1IUA5w-0006pm-Mc; Sat, 08 Sep 2007 19:52:08 -0400
Received: by internaut.com (Postfix, from userid 1000)
	id B396381655; Sat,  8 Sep 2007 16:52:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by internaut.com (Postfix) with ESMTP id A41DB81654;
	Sat,  8 Sep 2007 16:52:06 -0700 (PDT)
X-MHO-User: U2FsdGVkX184jXpDBRJ/N75Pb1xP8J9V
X-MHO-User: U2FsdGVkX1/27vVy7QY5/gspMU/k084B
X-MHO-User: U2FsdGVkX1+cDCrRQP07gypHk95QiNLX
X-MHO-User: U2FsdGVkX1/fV+tn3A0+k0KZLZVN3IZG
X-MHO-User: U2FsdGVkX1+CTyNy0T6ai9BAu5giTwfz
X-MHO-User: U2FsdGVkX183YJrzzFtRnN2/+eRvmR4P
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 71.197.208.131
X-Report-Abuse-To: abuse@dyndns.com (see
	http://www.mailhop.org/outbound/abuse.html for abuse reporting
	information)
X-MHO-User: U2FsdGVkX1+ryUWKv8RrLUjmWioTHZCW
Date: Sat, 8 Sep 2007 16:52:06 -0700 (PDT)
From: Bernard Aboba 
To: Eric Rescorla 
In-Reply-To: <20070908205337.82EC933C39@delta.rtfm.com>
Message-ID: 
References: <46E2E54A.2050406@isode.com>
	<20070908205337.82EC933C39@delta.rtfm.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, ietf-http-wg@w3.org, discuss@apps.ietf.org,
	ietf-http-auth@osafoundation.org,
	Alexey Melnikov , ietf@ietf.org
Subject: Re: [saag] [Ietf-http-auth] Next step on web phishing draft
 (draft-hartman-webauth-phishing-05.txt)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sat, 08 Sep 2007 23:52:18 -0000

> I object to this procedure.
> 
> This document has already had an IETF Last Call, where it failed to
> achieve consensus. At this point, it doesn't need additional last
> calls to "make sure that people agree with Sam", but rather to go back
> to the authors to try to build support in the community. Not liking
> the result of the previous Last Call is not a sufficient basis for
> issuing another one.
> 
> At some point in the future, it may be appropriate to issue another
> consensus call, but since this is not a WG mailing list--indeed, the
> IESG has twice declined to charter a WG in this area--nor are you the
> chair, it doesn't seem to me that you have standing to do that. When
> that time comes, I would expect the IESG to designate an appropriate
> time and place.

I agree with EKR here.  Failed consensus is failed consensus.  RFC 2026 
does not support the process that has been recommended here. 

From pbaker@verisign.com Sun Sep  9 21:50:57 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l8A1ouYM014021
	for ; Sun, 9 Sep 2007 21:50:57 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l8A1oqox007454
	for ; Sun, 9 Sep 2007 21:50:52 -0400 (EDT)
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 55FE17874C5
	for ; Sun,  9 Sep 2007 21:50:51 -0400 (EDT)
Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com
	[65.205.251.35])
	by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l8A1nDiV004852;
	Sun, 9 Sep 2007 18:49:13 -0700
Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by
	MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft
	SMTPSVC(6.0.3790.1830); Sun, 9 Sep 2007 18:50:39 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Sun, 9 Sep 2007 18:47:58 -0700
Message-ID: <198A730C2044DE4A96749D13E167AD37013EDBE0@MOU1WNEXMB04.vcorp.ad.vrsn.com>
In-Reply-To: <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Next step on web phishing
	draft(draft-hartman-webauth-phishing-05.txt)
Thread-Index: AcfzKj6eDFp6Aj4DQNKi/PQmpOaVfQAIVdHQ
From: "Hallam-Baker, Phillip" 
To: "Iljitsch van Beijnum" ,
	"Alexey Melnikov" 
X-OriginalArrivalTime: 10 Sep 2007 01:50:39.0347 (UTC)
	FILETIME=[FD24F430:01C7F34C]
X-Spam-Score: 0.02
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id
	l8A1ouYM014021
Cc: ietf-http-auth@osafoundation.org, discuss@apps.ietf.org,
	ietf-http-wg@w3.org, ietf@ietf.org, saag@mit.edu
Subject: Re: [saag] Next step on web phishing
	draft(draft-hartman-webauth-phishing-05.txt)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Mon, 10 Sep 2007 01:50:57 -0000

> From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] 

> During the reading of this document, it occurred to me that 
> HTTP digest authentication (RFC 2617) rather than the widely 
> used practice of having security credentials be typed into an 
> HTTP form would achieve 90% of the requirements all by 
> itself. 

Well maybe if people had listened to me then :-)

But at this point fifteen years later Digest is not the way to go. First Digest was designed under the express constraint of avoiding patent encumberances. RSA and D-H were both off the table at the time.

If I was to redo Digest today or expand its scope I would do it differently. The main reason I would not is that SAML and WS-* both provide an excellent solution. I very much like and support the Cardspace idea of building into the O/S platform. I very much like the OpenID concept of making the barrier to entry very low. I would like to arrive at a happy combination of the existing proposals not see more proposals put on the table at this point.



From alexey.melnikov@isode.com Sat Sep  8 14:08:41 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l88I8f9r010381
	for ; Sat, 8 Sep 2007 14:08:41 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l88I8Z9I021456
	for ; Sat, 8 Sep 2007 14:08:35 -0400 (EDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251])
	by mit.edu (Spam Firewall) with ESMTP id C09AA78A9CD
	for ; Sat,  8 Sep 2007 14:08:34 -0400 (EDT)
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com (submission channel) via TCP with ESMTPA 
	id ; Sat, 8 Sep 2007 19:08:33 +0100
Message-ID: <46E2E54A.2050406@isode.com>
Date: Sat, 08 Sep 2007 19:09:14 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
To: ietf@ietf.org, discuss@apps.ietf.org, ietf-http-wg@w3.org,
	ietf-http-auth@osafoundation.org, saag@mit.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.65
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
X-Mailman-Approved-At: Mon, 10 Sep 2007 09:17:56 -0400
Subject: [saag] Next step on web phishing draft
 (draft-hartman-webauth-phishing-05.txt)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sat, 08 Sep 2007 18:08:42 -0000

This message is trying to summarize recent discussions on 
draft-hartman-webauth-phishing-05.txt.

Several people voiced their support for the document (on IETF mailing 
list and in various other off-list discussions). Ekr doesn't think that 
the document should be published in the current form and he has some 
good technical points that need to be addressed. At least one more 
revision is needed to addressed recent comments from Ekr and SecDir review.

It is quite clear that some people got confused about intended status of 
this document and whether it represents IETF consensus. Sam has 
clarified what was his intention, but another consensus call is needed 
to make sure people agree with Sam.

Subsequent discussions and consensus calls on the document would happen 
on .

Alexey,
in my capacity of shepherd for draft-hartman-webauth-phishing

From alexey.melnikov@isode.com Sun Sep  9 14:29:34 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l89ITWa2032358
	for ; Sun, 9 Sep 2007 14:29:32 -0400
Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l89ITQAm021474
	for ; Sun, 9 Sep 2007 14:29:26 -0400 (EDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251])
	by mit.edu (Spam Firewall) with ESMTP id 8DCB559C0C9
	for ; Sun,  9 Sep 2007 14:29:23 -0400 (EDT)
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com (submission channel) via TCP with ESMTPA 
	id ; Sun, 9 Sep 2007 19:29:20 +0100
Message-ID: <46E43BA9.3080407@isode.com>
Date: Sun, 09 Sep 2007 19:30:01 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
To: Eric Rescorla 
References: <46E2E54A.2050406@isode.com>
	<20070908205337.82EC933C39@delta.rtfm.com>
In-Reply-To: <20070908205337.82EC933C39@delta.rtfm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.65
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
X-Mailman-Approved-At: Mon, 10 Sep 2007 09:17:56 -0400
Cc: ietf-http-auth@osafoundation.org, discuss@apps.ietf.org, saag@mit.edu,
	ietf@ietf.org, ietf-http-wg@w3.org
Subject: Re: [saag] [Ietf-http-auth] Next step on web phishing draft
 (draft-hartman-webauth-phishing-05.txt)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sun, 09 Sep 2007 18:29:34 -0000

Eric Rescorla wrote:

>Alexey wrote:
>  
>
>>This message is trying to summarize recent discussions on 
>>draft-hartman-webauth-phishing-05.txt.
>>
>>Several people voiced their support for the document (on IETF mailing 
>>list and in various other off-list discussions). Ekr doesn't think that 
>>the document should be published in the current form and he has some 
>>good technical points that need to be addressed. At least one more 
>>revision is needed to addressed recent comments from Ekr and SecDir review.
>>
>>It is quite clear that some people got confused about intended status of 
>>this document and whether it represents IETF consensus. Sam has 
>>clarified what was his intention, but another consensus call is needed 
>>to make sure people agree with Sam.
>>
>>Subsequent discussions and consensus calls on the document would happen 
>>on .
>>
>>Alexey,
>>in my capacity of shepherd for draft-hartman-webauth-phishing
>>    
>>
>I object to this procedure.
>
>This document has already had an IETF Last Call, where it failed to
>achieve consensus.
>
Ekr, I have to disagree with you.
One objection about the document and one objection about the intended 
status doesn't constitute "failed consensus", considering there are at 
least 8 other people who are in favor of publishing the document. I can 
publish the list of reviewers, if you insist.

>At this point, it doesn't need additional last
>calls to "make sure that people agree with Sam", but rather to go back
>to the authors to try to build support in the community.
>
I was probably not clear enough in my previous message:
1). The document needs more work.
2). The document needs more reviews. Discussions of future revisions 
should happen on ietf-http-auth@osafoundation.org
3). The document was effectively reset to pre-IETF LC state.

>Not liking the result of the previous Last Call is not a sufficient basis for
>issuing another one.
>  
>
This statement taken in isolation is certainly correct. However if the 
original LC didn't ask the right question, don't you think this makes 
answers meaningless?

>At some point in the future, it may be appropriate to issue another
>consensus call, but since this is not a WG mailing list--indeed, the
>IESG has twice declined to charter a WG in this area--nor are you the
>chair, it doesn't seem to me that you have standing to do that. When
>that time comes, I would expect the IESG to designate an appropriate
>time and place.
>  
>
I have support of the shepherding AD.
Do you think this is insufficient?


From iljitsch@muada.com Sun Sep  9 17:40:38 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l89LebGJ000388
	for ; Sun, 9 Sep 2007 17:40:37 -0400
Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l89LeWpw007158
	for ; Sun, 9 Sep 2007 17:40:32 -0400 (EDT)
Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 0B5385AACC1
	for ; Sun,  9 Sep 2007 17:40:29 -0400 (EDT)
Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28])
	(authenticated bits=0)
	by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l89LZHTG073622
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Sun, 9 Sep 2007 23:35:17 +0200 (CEST)
	(envelope-from iljitsch@muada.com)
In-Reply-To: <46E2E54A.2050406@isode.com>
References: <46E2E54A.2050406@isode.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com>
Content-Transfer-Encoding: 7bit
From: Iljitsch van Beijnum 
Date: Sun, 9 Sep 2007 23:37:45 +0200
To: Alexey Melnikov 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.01
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
X-Mailman-Approved-At: Mon, 10 Sep 2007 09:17:56 -0400
Cc: ietf-http-auth@osafoundation.org, discuss@apps.ietf.org, saag@mit.edu,
	ietf@ietf.org, ietf-http-wg@w3.org
Subject: Re: [saag] Next step on web phishing draft
	(draft-hartman-webauth-phishing-05.txt)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sun, 09 Sep 2007 21:40:38 -0000

On 8-sep-2007, at 20:09, Alexey Melnikov wrote:

> This message is trying to summarize recent discussions on draft- 
> hartman-webauth-phishing-05.txt.

> Several people voiced their support for the document (on IETF  
> mailing list and in various other off-list discussions). Ekr  
> doesn't think that the document should be published in the current  
> form and he has some good technical points that need to be  
> addressed. At least one more revision is needed to addressed recent  
> comments from Ekr and SecDir review.

Here's an outsider review.

What's an Ekr, btw?

I really dislike the use of "fishing" with creative spelling in a  
document prepared for an international standards organization. The  
world certainly doesn't need more words that sound the same and  
differ in meaning only by the way they're written, and I'm not sure  
how prevalent this terminology is outside the US and/or the English  
speaking world. Please come up with something more descriptive.

During the reading of this document, it occurred to me that HTTP  
digest authentication (RFC 2617) rather than the widely used practice  
of having security credentials be typed into an HTTP form would  
achieve 90% of the requirements all by itself. (More or less the same  
thing for S/MIME in mail.) The main part that's missing there is  
protection against a man in the middle. Obviously TLS goes through  
great pains to avoid men in the middle, but the document has no  
trouble throwing that out of the window:

    The attacker can also spoof trust markers
    such as the security lock, URL bar and other parts of the browser  
UI.

And:

    Users do not typically understand
    certificates and cannot make informed decisions about whether the
    subject name in a certificate corresponds to the entity they are
    attempting to communicate with.  As a consequence of this  
assumption,
    users will likely be fooled by strings either in website names or
    certificates that look visually similar but that are composed of
    different code points.

Although I agree that a system that can work even under these  
assumptions would be great, I think it's harmful to adopt them in  
this way, because it sends a number of very bad messages:

- it's ok for browser vendors to play fast and loose with security  
related UI elements such as the lock icon and the URL bar (i.e., have  
them controlled by the remote server)

- it's ok for domain vendors to sell domains that use IDN trickery

- it's ok for certificate vendors to sell certificates that seem to  
be tied to some known entity but are in reality tied to a different  
entity

All of these are unacceptable and we as users of these services,  
community members, engineers and IETF members should do what we can  
to make sure that they don't happen.

Last but not least, I'm guessing that "ben Laurie" is actually "Ben  
Laurie".

From iljitsch@muada.com Sun Sep  9 19:21:15 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l89NLEA7023971
	for ; Sun, 9 Sep 2007 19:21:14 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l89NL99U005730
	for ; Sun, 9 Sep 2007 19:21:09 -0400 (EDT)
Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 5B8B89B37F4
	for ; Sun,  9 Sep 2007 19:21:07 -0400 (EDT)
Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28])
	(authenticated bits=0)
	by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l89NIYqS075023
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Mon, 10 Sep 2007 01:18:34 +0200 (CEST)
	(envelope-from iljitsch@muada.com)
In-Reply-To: <420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com>
References: <46E2E54A.2050406@isode.com>
	<8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com>
	<420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com>
Content-Transfer-Encoding: 7bit
From: Iljitsch van Beijnum 
Date: Mon, 10 Sep 2007 01:21:00 +0200
To: Marshall Eubanks 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.01
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
X-Mailman-Approved-At: Mon, 10 Sep 2007 09:17:56 -0400
Cc: discuss@apps.ietf.org, ietf@ietf.org, saag@mit.edu,
	Alexey Melnikov ,
	ietf-http-auth@osafoundation.org, ietf-http-wg@w3.org
Subject: Re: [saag] Next step on web phishing draft
	(draft-hartman-webauth-phishing-05.txt)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sun, 09 Sep 2007 23:21:17 -0000

On 10-sep-2007, at 0:51, Marshall Eubanks wrote:

> I tend to rely on Dictionaries to sort these things out - from  
> Dictionary.com

Dictionaries are useless, when in doubt they just add definitions.  
For instance, try figuring out how many bytes there are in a megabyte  
from a few dictionaries.

From mouse@Sparkle.Rodents.Montreal.QC.CA Mon Sep 10 10:27:11 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l8AERBsJ016148
	for ; Mon, 10 Sep 2007 10:27:11 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l8AER3tY028003
	for ; Mon, 10 Sep 2007 10:27:05 -0400 (EDT)
Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA
	[216.46.5.7]) by mit.edu (Spam Firewall) with ESMTP id 8D863C35E70
	for ; Mon, 10 Sep 2007 10:27:02 -0400 (EDT)
Received: (from mouse@localhost)
	by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id KAA03299;
	Mon, 10 Sep 2007 10:26:53 -0400 (EDT)
From: der Mouse 
Message-Id: <200709101426.KAA03299@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 botnet zombies.
Date: Mon, 10 Sep 2007 10:14:07 -0400 (EDT)
To: ietf-http-auth@osafoundation.org, discuss@apps.ietf.org, saag@mit.edu,
	ietf@ietf.org, ietf-http-wg@w3.org
In-Reply-To: <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com>
References: <46E2E54A.2050406@isode.com>
	<8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com>
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: Re: [saag] Next step on web phishing
	draft	(draft-hartman-webauth-phishing-05.txt)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Mon, 10 Sep 2007 14:27:11 -0000

> I really dislike the use of "fishing" with creative spelling in a
> document prepared for an international standards organization.

Perhaps unfortunately, that is *the* word for the behaviour in
question, at least in English.  It was not invented for the draft, and
"com[ing] up with something [else]" would be *less* descriptive and
would render the document cryptic to the people who's been working
against phishing for years.  Perhaps it's a bad word to use in other
languages, but that should be addressed by the translator(s) in
question, not by mangling the original.

> [...], because it sends a number of very bad messages:

> - it's ok for browser vendors to play fast and loose with security
>   related UI elements such as the lock icon and the URL bar (i.e.,
>   have them controlled by the remote server)

> - it's ok for domain vendors to sell domains that use IDN trickery

> - it's ok for certificate vendors to sell certificates that seem to
>   be tied to some known entity but are in reality tied to a different
>   entity

It appears they *are* OK, pragmatically; at least, the first and third
- and quite possibly the second, for all I know - are continuing with
no apparent backlash.

> All of these are unacceptable and we as users of these services,
> community members, engineers and IETF members should do what we can
> to make sure that they don't happen.

Ideally, yes.  Let me know when you manage to get users to drop every
major Web browser and every major cert vendor because they're insecure
against these attacks - never mind when you find users competent to
even understand the issue, much less evaluate Web browsers and cert
vendors in these regards.

In the meantime, I see nothing wrong (and much right) with a draft that
addresses this problem - or at least tries to - in the world as it is,
rather than the world as you, me, and a tiny minority of other people
would like it to be.

/~\ 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 bmanning@ISI.EDU Mon Sep 10 13:05:30 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l8AH5UN9018027
	for ; Mon, 10 Sep 2007 13:05:30 -0400
Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l8AH5Ohx018143
	for ; Mon, 10 Sep 2007 13:05:24 -0400 (EDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 59CF85845C3
	for ; Sun,  9 Sep 2007 19:49:54 -0400 (EDT)
Received: from boreas.isi.edu (localhost [127.0.0.1])
	by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l89NmxZa003908
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sun, 9 Sep 2007 16:48:59 -0700 (PDT)
Received: (from bmanning@localhost)
	by boreas.isi.edu (8.13.8/8.13.8/Submit) id l89NmdbV003547;
	Sun, 9 Sep 2007 16:48:39 -0700 (PDT)
Date: Sun, 9 Sep 2007 16:48:39 -0700
From: Bill Manning 
To: Iljitsch van Beijnum 
Message-ID: <20070909234839.GA2020@boreas.isi.edu>
References: <46E2E54A.2050406@isode.com>
	<8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com>
	<420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com>
	<26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com>
User-Agent: Mutt/1.4.2.2i
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: bmanning@boreas.isi.edu
X-Spam-Score: 3.501
X-Spam-Level: *** (3.501)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
X-Mailman-Approved-At: Mon, 10 Sep 2007 14:31:39 -0400
Cc: discuss@apps.ietf.org, Marshall Eubanks ,
	ietf@ietf.org, saag@mit.edu, Alexey Melnikov ,
	ietf-http-auth@osafoundation.org, ietf-http-wg@w3.org
Subject: Re: [saag] Next step on web phishing draft
	(draft-hartman-webauth-phishing-05.txt)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Mon, 10 Sep 2007 17:05:31 -0000

On Mon, Sep 10, 2007 at 01:21:00AM +0200, Iljitsch van Beijnum wrote:
> On 10-sep-2007, at 0:51, Marshall Eubanks wrote:
> 
> >I tend to rely on Dictionaries to sort these things out - from  
> >Dictionary.com
> 
> Dictionaries are useless, when in doubt they just add definitions.  
> For instance, try figuring out how many bytes there are in a megabyte  
> from a few dictionaries.
> 

`When I use a word,' Humpty Dumpty said, in rather a scornful tone, 
`it means just what I choose it to mean -- neither more nor less.'

 
--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).


From jhutz@cmu.edu Mon Sep 10 16:52:52 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l8AKqqYf017508
	for ; Mon, 10 Sep 2007 16:52:52 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l8AKqk2x026328
	for ; Mon, 10 Sep 2007 16:52:46 -0400 (EDT)
Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.201.52])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id A71B8C4463C
	for ; Mon, 10 Sep 2007 16:52:45 -0400 (EDT)
Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170])
	(authenticated bits=0)
	by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l8AKqZmM006409
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2007 16:52:36 -0400 (EDT)
Date: Mon, 10 Sep 2007 16:52:35 -0400
From: Jeffrey Hutzelman 
To: Eric Rescorla ,
	Alexey Melnikov 
Message-ID: <2FF98D1CD1230EA56262CB32@sirius.fac.cs.cmu.edu>
In-Reply-To: <20070908205337.82EC933C39@delta.rtfm.com>
References: <46E2E54A.2050406@isode.com>
	<20070908205337.82EC933C39@delta.rtfm.com>
Originator-Info: login-token=Mulberry:01jx+E6vmH+V7bavxrwp20WSaRuxUWU/38lLJPxZ8=;
	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: 0.01
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: discuss@apps.ietf.org, ietf@ietf.org, ietf-http-wg@w3.org, saag@mit.edu,
	ietf-http-auth@osafoundation.org
Subject: Re: [saag] [Ietf-http-auth] Next step on web phishing
 draft	(draft-hartman-webauth-phishing-05.txt)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Mon, 10 Sep 2007 20:52:52 -0000



On Saturday, September 08, 2007 01:53:36 PM -0700 Eric Rescorla 
 wrote:

> Alexey wrote:
>> This message is trying to summarize recent discussions on
>> draft-hartman-webauth-phishing-05.txt.
>>
>> Several people voiced their support for the document (on IETF mailing
>> list and in various other off-list discussions). Ekr doesn't think that
>> the document should be published in the current form and he has some
>> good technical points that need to be addressed. At least one more
>> revision is needed to addressed recent comments from Ekr and SecDir
>> review.
>>
>> It is quite clear that some people got confused about intended status of
>> this document and whether it represents IETF consensus. Sam has
>> clarified what was his intention, but another consensus call is needed
>> to make sure people agree with Sam.
>>
>> Subsequent discussions and consensus calls on the document would happen
>> on .
>>
>> Alexey,
>> in my capacity of shepherd for draft-hartman-webauth-phishing
>
>
> I object to this procedure.
shep>
> This document has already had an IETF Last Call, where it failed to
> achieve consensus. At this point, it doesn't need additional last
> calls to "make sure that people agree with Sam", but rather to go back
> to the authors to try to build support in the community. Not liking
> the result of the previous Last Call is not a sufficient basis for
> issuing another one.
>
> At some point in the future, it may be appropriate to issue another
> consensus call, but since this is not a WG mailing list--indeed, the
> IESG has twice declined to charter a WG in this area--nor are you the
> chair, it doesn't seem to me that you have standing to do that. When
> that time comes, I would expect the IESG to designate an appropriate
> time and place.


I think you're overreacting, possibly due to a misinterpretation of what 
Alexey said and/or of the current state of the document.

My reading of the IESG evaluation record suggests that there are indeed 
some issues that the community feels need to be addressed before the 
document can move forward.  Its current state is "IESG Evaluation::Revised 
ID Needed", which, along with the evaluation record, suggests that the 
responsible AD has asked the author and shepherd to get these issues 
resolved and submit a new document.  I don't know what will happen once 
this is done, but unless the IESG feels we already have _rough_ consensus 
to publish the document _and_ there are no major changes, I would expect to 
see a new last call on the revised document.  Of course, that last call may 
see renewed objections from the same individuals, or from others; that does 
not necessarily mean the last call "failed" -- remember, we operate on 
_rough_ consensus.

Now, given that the responsible AD has asked for a new document, it seems 
to me that Alexey, as the shepherd of an individual submission, has quite a 
bit of latitude in how to get there and what it will take before he is 
willing to take the document back to the IESG.  Given that this document is 
a group effort, it's entirely reasonable for Alexey to want to know that 
people contributing to the work agree with any changes Sam makes, and to 
issue consensus cals in an appropriate forum to do this.  No one is 
laboring under the impression that such a call would serve to "override" 
the "failed" IETF LC.  Instead, when Alexey in his role as shepherd 
believes the document is ready to go back to the IESG, he will inform Lisa 
of that fact, and the IESG will decide what to do next.


-- Jeff
-- Jeff

From cfinss@dial.pipex.com Mon Sep 10 15:09:30 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l8AJ9UkY006674
	for ; Mon, 10 Sep 2007 15:09:30 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l8AJ9O88009071
	for ; Mon, 10 Sep 2007 15:09:24 -0400 (EDT)
Received: from ranger.systems.pipex.net (ranger.systems.pipex.net
	[62.241.162.32]) by mit.edu (Spam Firewall) with ESMTP id 56CC399DF83
	for ; Mon, 10 Sep 2007 15:09:22 -0400 (EDT)
Received: from pc6 (1Cust35.tnt29.lnd3.gbr.da.uu.net [62.188.120.35])
	by ranger.systems.pipex.net (Postfix) with SMTP id 9FF6EE000718;
	Mon, 10 Sep 2007 20:09:14 +0100 (BST)
Message-ID: <017301c7f3d4$d6e9a080$0601a8c0@pc6>
From: "tom.petch" 
To: "der Mouse" ,
	, ,
	, , 
References: <46E2E54A.2050406@isode.com><8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com>
	<200709101426.KAA03299@Sparkle.Rodents.Montreal.QC.CA>
Date: Mon, 10 Sep 2007 16:45:36 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.01
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
X-Mailman-Approved-At: Tue, 11 Sep 2007 08:54:29 -0400
Subject: Re: [saag] Next step on web phishing
	draft(draft-hartman-webauth-phishing-05.txt)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "tom.petch" 
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Mon, 10 Sep 2007 19:09:30 -0000

----- Original Message -----
From: "der Mouse" 
To: ; ; ;
; 
Sent: Monday, September 10, 2007 4:14 PM
Subject: Re: [saag] Next step on web phishing
draft(draft-hartman-webauth-phishing-05.txt)


> > I really dislike the use of "fishing" with creative spelling in a
> > document prepared for an international standards organization.
>
> Perhaps unfortunately, that is *the* word for the behaviour in
> question, at least in English.  It was not invented for the draft, and
> "com[ing] up with something [else]" would be *less* descriptive and
> would render the document cryptic to the people who's been working
> against phishing for years.  Perhaps it's a bad word to use in other
> languages, but that should be addressed by the translator(s) in
> question, not by mangling the original.
>

Stick the word in quotes which conveys the message that we know that this is not
a good piece of terminology, but that we are pragmatic enough to recognise that
using it will convey the right meaning to most people.

But on the other strand under this Subject:, I am with those who think that the
IETF has demonstrated an absence of consensus and that the proposed way forward
to try and achieve it by other means in plain wrong.

Tom Petch


From paulle@windows.microsoft.com Mon Sep 10 19:30:55 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l8ANUsLO023513
	for ; Mon, 10 Sep 2007 19:30:54 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l8ANUlpg015553
	for ; Mon, 10 Sep 2007 19:30:47 -0400 (EDT)
X-ASG-Whitelist: Barracuda Reputation
Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 2C6C7C50249
	for ; Mon, 10 Sep 2007 19:30:46 -0400 (EDT)
Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by
	TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with
	Microsoft
	SMTP Server (TLS) id 8.1.177.2; Mon, 10 Sep 2007 16:30:45 -0700
Received: from tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com
	(157.54.70.14) by tk1-exhub-c102.redmond.corp.microsoft.com
	(157.56.116.113)
	with Microsoft SMTP Server id 8.1.177.1; Mon, 10 Sep 2007 16:29:34 -0700
Received: from tk5-exmlt-w600.wingroup.windeploy.ntdev.microsoft.com
	(157.54.70.135) by
	TK5-EXMLT-W602.wingroup.windeploy.ntdev.microsoft.com
	(157.54.70.14) with Microsoft SMTP Server (TLS) id 8.1.122.1;
	Mon, 10 Sep 2007 16:29:26 -0700
Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com
	([fe80:0000:0000:0000:0000:5efe:10.255.255.2]) by
	tk5-exmlt-w600.wingroup.windeploy.ntdev.microsoft.com ([157.54.70.135])
	with mapi; Mon, 10 Sep 2007 16:29:26 -0700
From: Paul Leach 
To: Alexey Melnikov , Eric Rescorla
	
Date: Mon, 10 Sep 2007 16:29:24 -0700
Thread-Topic: [Ietf-http-auth] Next step on web phishing draft
	(draft-hartman-webauth-phishing-05.txt)
Thread-Index: AcfzD3vfxFQpumfXQdihbeQBR2+gcgA8rMtQ
Message-ID: <042C7D611172EE4A98E7B9AF81D1178C7623734415@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
References: <46E2E54A.2050406@isode.com>
	<20070908205337.82EC933C39@delta.rtfm.com>
	<46E43BA9.3080407@isode.com>
In-Reply-To: <46E43BA9.3080407@isode.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-Spam-Score: 0.201
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id
	l8ANUsLO023513
X-Mailman-Approved-At: Tue, 11 Sep 2007 08:54:29 -0400
Cc: "ietf-http-auth@osafoundation.org" ,
	"discuss@apps.ietf.org" ,
	"saag@mit.edu" , "ietf@ietf.org" ,
	"ietf-http-wg@w3.org" 
Subject: Re: [saag] [Ietf-http-auth] Next step on web phishing draft
 (draft-hartman-webauth-phishing-05.txt)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Mon, 10 Sep 2007 23:30:55 -0000

I've read the I-D and EKR's responses, and while I don't agree with all of them I agree with enough of them that I think that the draft could use a further revision that takes them into consideration.


From prvs=177446d652=debbie@ictmarketing.co.uk Tue Sep 11 07:20:06 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l8BBK3t9008516
	for ; Tue, 11 Sep 2007 07:20:05 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l8BBJu67013646
	for ; Tue, 11 Sep 2007 07:19:57 -0400 (EDT)
Received: from mx1.nexbyte.net (132.nexbyte.net [62.197.41.132])
	by mit.edu (Spam Firewall) with ESMTP id 303549BA9E5
	for ; Tue, 11 Sep 2007 07:19:52 -0400 (EDT)
Received: from 145.nexbyte.net ([62.197.41.145])
	by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132])
	(MDaemon PRO v9.6.2) with ESMTP id md50007212400.msg
	for ; Tue, 11 Sep 2007 12:22:33 +0100
Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with
	MailEnable ESMTP; Tue, 11 Sep 2007 12:19:39 +0100
From: "Debbie Garside" 
To: , "'Iljitsch van Beijnum'" 
References: <46E2E54A.2050406@isode.com><8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com><420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com><26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com>
	<20070909234839.GA2020@boreas.isi.edu>
Date: Tue, 11 Sep 2007 12:19:22 +0100
Message-ID: <003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110>
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <20070909234839.GA2020@boreas.isi.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
Thread-Index: AcfzPISBSDu20IiKR2a5/YMXUw05bQBKNACA
X-Spam-Processed: mx1.nexbyte.net, Tue, 11 Sep 2007 12:22:33 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 62.197.41.145
X-Return-Path: prvs=177446d652=debbie@ictmarketing.co.uk
X-Envelope-From: debbie@ictmarketing.co.uk
X-MDaemon-Deliver-To: saag@mit.edu
X-MDAV-Processed: mx1.nexbyte.net, Tue, 11 Sep 2007 12:22:34 +0100
X-Spam-Score: 0.02
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
X-Mailman-Approved-At: Tue, 11 Sep 2007 08:54:29 -0400
Cc: discuss@apps.ietf.org, ietf@ietf.org, saag@mit.edu,
	'Alexey Melnikov' ,
	ietf-http-auth@osafoundation.org, ietf-http-wg@w3.org
Subject: Re: [saag] Next step on web phishing
	draft(draft-hartman-webauth-phishing-05.txt)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: debbie@ictmarketing.co.uk
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 11 Sep 2007 11:20:06 -0000

Bill wrote:

> `When I use a word,' Humpty Dumpty said, in rather a scornful tone,
> `it means just what I choose it to mean -- neither more nor less.'

There has been a discussion recently on LTRU as to whether a Terms and
Definitions section should be introduced within RFCs - much like those
within ISO Standards.

Best regards

Debbie Garside

> -----Original Message-----
> From: Bill Manning [mailto:bmanning@ISI.EDU]
> Sent: 10 September 2007 00:49
> To: Iljitsch van Beijnum
> Cc: ietf@ietf.org; discuss@apps.ietf.org;
> ietf-http-wg@w3.org; saag@mit.edu; Alexey Melnikov;
> ietf-http-auth@osafoundation.org
> Subject: Re: Next step on web phishing
> draft(draft-hartman-webauth-phishing-05.txt)
>
> On Mon, Sep 10, 2007 at 01:21:00AM +0200, Iljitsch van Beijnum wrote:
> > On 10-sep-2007, at 0:51, Marshall Eubanks wrote:
> >
> > >I tend to rely on Dictionaries to sort these things out - from
> > >Dictionary.com
> >
> > Dictionaries are useless, when in doubt they just add definitions.
> > For instance, try figuring out how many bytes there are in
> a megabyte
> > from a few dictionaries.
> >
>
> `When I use a word,' Humpty Dumpty said, in rather a scornful tone,
> `it means just what I choose it to mean -- neither more nor less.'
>
>
> --bill
>
> Opinions expressed may not even be mine by the time you read them, and
> certainly don't reflect those of any other entity (legal or
> otherwise).
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>
>
>





From shuque@isc.upenn.edu Tue Sep 11 15:39:29 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l8BJdTTW009190
	for ; Tue, 11 Sep 2007 15:39:29 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l8BJdNM7028641
	for ; Tue, 11 Sep 2007 15:39:23 -0400 (EDT)
Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu
	[128.91.197.188])
	by mit.edu (Spam Firewall) with ESMTP id E839F9BDE88
	for ; Tue, 11 Sep 2007 15:39:22 -0400 (EDT)
Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127)
	id 981A01CDC; Tue, 11 Sep 2007 15:39:22 -0400 (EDT)
Date: Tue, 11 Sep 2007 15:39:22 -0400
From: Shumon Huque 
To: Paul Leach 
Message-ID: <20070911193922.GA13450@isc.upenn.edu>
References: <46E2E54A.2050406@isode.com>
	<20070908205337.82EC933C39@delta.rtfm.com>
	<46E43BA9.3080407@isode.com>
	<042C7D611172EE4A98E7B9AF81D1178C7623734415@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <042C7D611172EE4A98E7B9AF81D1178C7623734415@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
User-Agent: Mutt/1.4.2.1i
Organization: University of Pennsylvania
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: "ietf-http-auth@osafoundation.org" ,
	"discuss@apps.ietf.org" ,
	"ietf-http-wg@w3.org" ,
	"ietf@ietf.org" , "saag@mit.edu" 
Subject: Re: [saag] [Ietf-http-auth] Next step on web phishing draft
	(draft-hartman-webauth-phishing-05.txt)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 11 Sep 2007 19:39:29 -0000

On Mon, Sep 10, 2007 at 04:29:24PM -0700, Paul Leach wrote:
> I've read the I-D and EKR's responses, and while I don't agree with all of them I agree with enough of them that I think that the draft could use a further revision that takes them into consideration.
> 

Would someone send a pointer to Eric Rescorla's critique of the
draft? I couldn't find it, although I found comments by various 
other folks on the IETF draft tracker.

--Shumon.

From moore@cs.utk.edu Tue Sep 11 16:11:45 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l8BKBj1F014741
	for ; Tue, 11 Sep 2007 16:11:45 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l8BKBZHe021574
	for ; Tue, 11 Sep 2007 16:11:37 -0400 (EDT)
Received: from bes.cs.utk.edu (bes.cs.utk.edu [160.36.56.220])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id D6B69C57DAB
	for ; Tue, 11 Sep 2007 16:11:26 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by bes.cs.utk.edu (Postfix) with ESMTP id DA83E1035D0;
	Tue, 11 Sep 2007 16:11:24 -0400 (EDT)
Received: from bes.cs.utk.edu ([127.0.0.1])
	by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id yEkug96Ucdqd; Tue, 11 Sep 2007 16:11:22 -0400 (EDT)
Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com
	[66.149.133.182])
	by bes.cs.utk.edu (Postfix) with ESMTP id 858511034D9;
	Tue, 11 Sep 2007 16:11:06 -0400 (EDT)
Message-ID: <46E6F657.4040204@cs.utk.edu>
Date: Tue, 11 Sep 2007 16:11:03 -0400
From: Keith Moore 
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: Ned Freed 
References: <46E2E54A.2050406@isode.com>	<8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com>	<420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com>	<26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com>	<20070909234839.GA2020@boreas.isi.edu>	<003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110>
	<01ML8DYIHPJQ003GRV@mauve.mrochek.com>
In-Reply-To: <01ML8DYIHPJQ003GRV@mauve.mrochek.com>
X-Enigmail-Version: 0.95.3
OpenPGP: id=E1473978
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: discuss@apps.ietf.org, 'Iljitsch van Beijnum' ,
	ietf@ietf.org, bmanning@isi.edu, saag@mit.edu,
	Debbie Garside ,
	ietf-http-auth@osafoundation.org, ietf-http-wg@w3.org
Subject: Re: [saag] Next step on web
	phishing	draft(draft-hartman-webauth-phishing-05.txt)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 11 Sep 2007 20:11:46 -0000


>> There has been a discussion recently on LTRU as to whether a Terms and
>> Definitions section should be introduced within RFCs - much like those
>> within ISO Standards.
>>     
>
> And my response to this suggestion is the same as it was for the "IANA
> considerations" or "Internationalization considerations" section suggestions:
> By all means have a "terms and definitions" section or whatever in the document
> if there's a need for one, but don't make having one mandatory in all
> documents.
>
> We already have more than enough useless (from a technical content
> perspective) boilerplate in our documents. 
+1

Actually I don't have so much of a problem with having such sections in
drafts at review time, but I hate to see them clutter up published
RFCs.    There are a lot of times when these sections aren't applicable,
and having them in the final document just interferes with readability. 

I also think that a Terms and Definitions section might encourage
document authors to make up new terms when they're not necessary, which
would also interfere with readability.  (geeks love to create new language.)


From ned.freed@mrochek.com Tue Sep 11 15:30:25 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l8BJUODZ007370
	for ; Tue, 11 Sep 2007 15:30:24 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l8BJUJmR029149
	for ; Tue, 11 Sep 2007 15:30:19 -0400 (EDT)
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com
	[66.59.230.40]) by mit.edu (Spam Firewall) with ESMTP id E93719ACD44
	for ; Tue, 11 Sep 2007 15:30:17 -0400 (EDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com
	(PMDF V6.1-1 #35243) id <01ML8DYK2FIO00ALEH@mauve.mrochek.com> for
	saag@mit.edu; Tue, 11 Sep 2007 12:30:10 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
	id <01ML8D10E8SW003GRV@mauve.mrochek.com> for saag@mit.edu; Tue,
	11 Sep 2007 12:30:04 -0700 (PDT)
Message-id: <01ML8DYIHPJQ003GRV@mauve.mrochek.com>
Date: Tue, 11 Sep 2007 12:04:01 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Tue, 11 Sep 2007 12:19:22 +0100"
	<003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110>
MIME-version: 1.0
References: <46E2E54A.2050406@isode.com>
	<8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com>
	<420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com>
	<26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com>
	<20070909234839.GA2020@boreas.isi.edu>
	<003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110>
To: Debbie Garside 
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1189539010;
	h=Date:	 From:Subject:MIME-version;
	b=DOsZLJxXlTdOCbTYNXnlBjIoOwNw/7GN3WPbXT
	TFKfocjktbiaTbwf/zhsgKnCIRYLhj+p8AWegEgWJc+xwnQA==
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
X-Mailman-Approved-At: Tue, 11 Sep 2007 16:35:57 -0400
Cc: discuss@apps.ietf.org, 'Iljitsch van Beijnum' ,
	ietf-http-wg@w3.org, bmanning@isi.edu, saag@mit.edu,
	'Alexey Melnikov' ,
	ietf-http-auth@osafoundation.org, ietf@ietf.org
Subject: Re: [saag] Next step on web
	phishing	draft(draft-hartman-webauth-phishing-05.txt)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 11 Sep 2007 19:30:25 -0000

> > `When I use a word,' Humpty Dumpty said, in rather a scornful tone,
> > `it means just what I choose it to mean -- neither more nor less.'

> There has been a discussion recently on LTRU as to whether a Terms and
> Definitions section should be introduced within RFCs - much like those
> within ISO Standards.

And my response to this suggestion is the same as it was for the "IANA
considerations" or "Internationalization considerations" section suggestions:
By all means have a "terms and definitions" section or whatever in the document
if there's a need for one, but don't make having one mandatory in all
documents.

We already have more than enough useless (from a technical content
perspective) boilerplate in our documents. We don't need any more, and
when such sections are always present but usually say "no such and such
are present" they aren't helping.

The last time this came up in the context of IANA considerations it was
asserted that having such sections act as a useful check to make sure there are
no needed definitions or considerations. The problem is people don't work this
way. If the section is mandatory they'll add it when the document is first
created. Sometimes they'll remember to keep it up to date and sometimes they
won't. But when someone reviews the document they'll see that section
and assume its presence means whatever has been checked. So the mandatory
section approach can actually result in more errors and omissions, not less.

It took me only a few minutes the last time we had one of these discussions
to find a documentt (in the RFE Editor's queue, as I recall) where
this had happened: A "there are no IANA considerations" section had been
added early on but when the document acquired IANA considerations it
wasn't updated. And nobody who reviewed the document caught it.

				Ned

P.S. I've read a lot of ISO and CCITT specifications and I have found
their terms and definitions material to be fairly hit or miss in terms of
utility.

From ned.freed@mrochek.com Tue Sep 11 16:42:08 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l8BKg7rI020095
	for ; Tue, 11 Sep 2007 16:42:07 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l8BKg33k023195
	for ; Tue, 11 Sep 2007 16:42:04 -0400 (EDT)
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com
	[66.59.230.40]) by mit.edu (Spam Firewall) with ESMTP id A2DC469B50F
	for ; Tue, 11 Sep 2007 16:42:02 -0400 (EDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com
	(PMDF V6.1-1 #35243) id <01ML8GHFYYXC00AKLQ@mauve.mrochek.com> for
	saag@mit.edu; Tue, 11 Sep 2007 13:41:55 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
	id <01ML884VNBDC00005F@mauve.mrochek.com> for saag@mit.edu; Tue,
	11 Sep 2007 13:41:45 -0700 (PDT)
Message-id: <01ML8GHD48YO00005F@mauve.mrochek.com>
Date: Tue, 11 Sep 2007 13:27:15 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Tue, 11 Sep 2007 16:11:03 -0400"
	<46E6F657.4040204@cs.utk.edu>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1
References: <46E2E54A.2050406@isode.com>
	<8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com>
	<420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com>
	<26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com>
	<20070909234839.GA2020@boreas.isi.edu>
	<003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110>
	<01ML8DYIHPJQ003GRV@mauve.mrochek.com> <46E6F657.4040204@cs.utk.edu>
To: Keith Moore 
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1189543314;
	h=Date:	 From:Subject:MIME-version:Content-type;
	b=ItY1VLQMRZX/n3fbKi2T77Jdi
	HzpvpbfI71F1nYjhMNCabcy0gnw5qItlDo0gfmACgpbVNyLWrHhricX49nfQg==
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
X-Mailman-Approved-At: Tue, 11 Sep 2007 16:47:10 -0400
Cc: discuss@apps.ietf.org, 'Iljitsch van Beijnum' ,
	Ned Freed , ietf@ietf.org,
	bmanning@isi.edu, saag@mit.edu, Debbie Garside ,
	ietf-http-auth@osafoundation.org, ietf-http-wg@w3.org
Subject: Re: [saag] Next step on web
	phishing	draft(draft-hartman-webauth-phishing-05.txt)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 11 Sep 2007 20:42:08 -0000


> >> There has been a discussion recently on LTRU as to whether a Terms and
> >> Definitions section should be introduced within RFCs - much like those
> >> within ISO Standards.
> >>
> >
> > And my response to this suggestion is the same as it was for the "IANA
> > considerations" or "Internationalization considerations" section suggestions:
> > By all means have a "terms and definitions" section or whatever in the document
> > if there's a need for one, but don't make having one mandatory in all
> > documents.
> >
> > We already have more than enough useless (from a technical content
> > perspective) boilerplate in our documents.
> +1

> Actually I don't have so much of a problem with having such sections in
> drafts at review time, but I hate to see them clutter up published
> RFCs.

My position is the exact opposite. Full and complete review of drafts it of
paramount importance and anything thqt interferes with that is unacceptable.
And as I have pointed out, we have "running code" demonstrating that these
things are at best distracting and at worst actively interfere with proper
review.

What's appropriate to appear in the final RFC is up to the RFC Editor. That's
what the word "editor" implies. If the RFC Editor deems it appropriate to
remove null sections that's fine, if they feel they should be retained that's
fine too. Someone reading an RFC to learn how to implement something has a
definite goal in mind and isn't going to be (or at least shouldn't be)
distracted by boilerplate in the same way a reviewer looking for issues - a far
more nebulous proposition - can be.

> There are a lot of times when these sections aren't applicable,
> and having them in the final document just interferes with readability.

It depends on what sort of reading you're doing.

> I also think that a Terms and Definitions section might encourage
> document authors to make up new terms when they're not necessary, which
> would also interfere with readability.  (geeks love to create new language.)

Very good point. Having lots of slightly varying definitions of various terms
could be hugely harmful.

RFC 2119 is a case in point. While I have some small issues with how RFC 2119
defines its terms, I've come to realize that having consistent meanings for
these terms is far more important.

				Ned

From moore@cs.utk.edu Tue Sep 11 16:56:16 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l8BKuGub022460
	for ; Tue, 11 Sep 2007 16:56:16 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l8BKuBP8019246
	for ; Tue, 11 Sep 2007 16:56:11 -0400 (EDT)
Received: from bes.cs.utk.edu (bes.cs.utk.edu [160.36.56.220])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 7795CC40673
	for ; Tue, 11 Sep 2007 16:56:10 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by bes.cs.utk.edu (Postfix) with ESMTP id 4AB991034D6;
	Tue, 11 Sep 2007 16:56:03 -0400 (EDT)
Received: from bes.cs.utk.edu ([127.0.0.1])
	by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id uQivNrcGHr2m; Tue, 11 Sep 2007 16:56:01 -0400 (EDT)
Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com
	[66.149.133.182])
	by bes.cs.utk.edu (Postfix) with ESMTP id F0EE8103610;
	Tue, 11 Sep 2007 16:55:57 -0400 (EDT)
Message-ID: <46E700DD.50802@cs.utk.edu>
Date: Tue, 11 Sep 2007 16:55:57 -0400
From: Keith Moore 
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: Ned Freed 
References: <46E2E54A.2050406@isode.com>
	<8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com>
	<420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com>
	<26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com>
	<20070909234839.GA2020@boreas.isi.edu>
	<003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110>
	<01ML8DYIHPJQ003GRV@mauve.mrochek.com>
	<46E6F657.4040204@cs.utk.edu>
	<01ML8GHD48YO00005F@mauve.mrochek.com>
In-Reply-To: <01ML8GHD48YO00005F@mauve.mrochek.com>
X-Enigmail-Version: 0.95.3
OpenPGP: id=E1473978
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: discuss@apps.ietf.org, 'Iljitsch van Beijnum' ,
	ietf@ietf.org, bmanning@isi.edu, saag@mit.edu,
	Debbie Garside ,
	ietf-http-auth@osafoundation.org, ietf-http-wg@w3.org
Subject: Re: [saag] Next step on web
	phishing	draft(draft-hartman-webauth-phishing-05.txt)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 11 Sep 2007 20:56:17 -0000

Ned Freed wrote:
>>>> There has been a discussion recently on LTRU as to whether a Terms and
>>>> Definitions section should be introduced within RFCs - much like those
>>>> within ISO Standards.
>>>>
>>>>         
>>> And my response to this suggestion is the same as it was for the "IANA
>>> considerations" or "Internationalization considerations" section suggestions:
>>> By all means have a "terms and definitions" section or whatever in the document
>>> if there's a need for one, but don't make having one mandatory in all
>>> documents.
>>>
>>> We already have more than enough useless (from a technical content
>>> perspective) boilerplate in our documents.
>>>       
>> +1
>>     
>
>   
>> Actually I don't have so much of a problem with having such sections in
>> drafts at review time, but I hate to see them clutter up published
>> RFCs.
>>     
>
> My position is the exact opposite. Full and complete review of drafts it of
> paramount importance and anything thqt interferes with that is unacceptable.
> And as I have pointed out, we have "running code" demonstrating that these
> things are at best distracting and at worst actively interfere with proper
> review.
>
> What's appropriate to appear in the final RFC is up to the RFC Editor. That's
> what the word "editor" implies. If the RFC Editor deems it appropriate to
> remove null sections that's fine, if they feel they should be retained that's
> fine too. Someone reading an RFC to learn how to implement something has a
> definite goal in mind and isn't going to be (or at least shouldn't be)
> distracted by boilerplate in the same way a reviewer looking for issues - a far
> more nebulous proposition - can be.
>   

Well, I guess we do disagree here to some extent.  For me, every
sentence of a document that doesn't contribute to the technical
knowledge that needs to be conferred, interferes with readability, and
ultimately, interoperability.  That applies to the copyright
boilerplate, that applies to checkoff sections that are just there to
get approval, it applies to information that is needed only by IANA. 
And I wasn't aware that our processes allowed the RFC Editor to delete,
say, a meaningless IANA considerations section.  (I've never checked to
see whether has happened.)

However I don't have a problem with IESG wanting additional supporting
information to help it decide whether to approve documents and to decide
what additional processing is needed.  If the best place to put such
information is in the I-D, fine; if the best place to put that
information is in a separate form, that's also fine with me.  (And I'd
far prefer that we not impose unnecessary burdens on authors of early
I-Ds - the fewer hoops they have to jump through, the better.)

In general, I think that I-Ds and RFCs really serve very different
purposes, and trying to make them be (almost) the same causes us to make
less readable end product.  I'd like to see more use of "NOTEs IN DRAFT"
and similar devices to separate supporting material from material that
belongs in the final publication.  I'm concerned about readability
throughout the document cycle, but am especially concerned about
readability of our published documents - as many more people read them
at this stage and those people have less context to aid them in sorting
through the crap.

Keith


From prvs=177446d652=debbie@ictmarketing.co.uk Tue Sep 11 16:57:48 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l8BKvmqq022766
	for ; Tue, 11 Sep 2007 16:57:48 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l8BKviCR018191
	for ; Tue, 11 Sep 2007 16:57:44 -0400 (EDT)
Received: from mx1.nexbyte.net (132.nexbyte.net [62.197.41.132])
	by mit.edu (Spam Firewall) with ESMTP id 2B64C9B867B
	for ; Tue, 11 Sep 2007 16:57:35 -0400 (EDT)
Received: from 145.nexbyte.net ([62.197.41.145])
	by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132])
	(MDaemon PRO v9.6.2) with ESMTP id md50007214839.msg
	for ; Tue, 11 Sep 2007 22:00:07 +0100
Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with
	MailEnable ESMTP; Tue, 11 Sep 2007 21:57:17 +0100
From: "Debbie Garside" 
To: , "'Keith Moore'" 
References: <46E2E54A.2050406@isode.com>
	<8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com>
	<420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com>
	<26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com>
	<20070909234839.GA2020@boreas.isi.edu>
	<003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110>
	<01ML8DYIHPJQ003GRV@mauve.mrochek.com>
	<46E6F657.4040204@cs.utk.edu>
	<01ML8GHD48YO00005F@mauve.mrochek.com>
Date: Tue, 11 Sep 2007 21:56:49 +0100
Message-ID: <012801c7f4b6$4b2faf70$0b00a8c0@CPQ86763045110>
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <01ML8GHD48YO00005F@mauve.mrochek.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
Thread-Index: Acf0tHbuUjgnFndgS1K93T2ZSOfPrwAASNWw
X-Spam-Processed: mx1.nexbyte.net, Tue, 11 Sep 2007 22:00:07 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 62.197.41.145
X-Return-Path: prvs=177446d652=debbie@ictmarketing.co.uk
X-Envelope-From: debbie@ictmarketing.co.uk
X-MDaemon-Deliver-To: saag@mit.edu
X-MDAV-Processed: mx1.nexbyte.net, Tue, 11 Sep 2007 22:00:08 +0100
X-Spam-Score: 0.02
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
X-Mailman-Approved-At: Tue, 11 Sep 2007 17:01:15 -0400
Cc: discuss@apps.ietf.org, 'Iljitsch van Beijnum' ,
	ietf@ietf.org, bmanning@isi.edu, saag@mit.edu,
	ietf-http-auth@osafoundation.org, ietf-http-wg@w3.org
Subject: Re: [saag] Next step on web
	phishingdraft(draft-hartman-webauth-phishing-05.txt)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: debbie@ictmarketing.co.uk
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 11 Sep 2007 20:57:48 -0000

 Ned wrote:

> Very good point. Having lots of slightly varying definitions
> of various terms could be hugely harmful.

I agree.  Which is why a Terms and Definitions section is darn useful as is
an overall Term Bank.  However, I will not labour the point as I have long
ago found that trying to sell Terminology standardization to industry is
practically impossible - unless you rename it as Knowledge Management.

Suffice to say, if I you were to write "Humpty Dumpty" and envisage a boiled
egg and I, in interpreting your request, presented you with scrambled egg...
You may be somewhat disappointed at breakfast! ;-)

Best regards

Debbie Garside

> -----Original Message-----
> From: Ned Freed [mailto:ned.freed@mrochek.com]
> Sent: 11 September 2007 21:27
> To: Keith Moore
> Cc: Ned Freed; Debbie Garside; ietf@ietf.org;
> discuss@apps.ietf.org; 'Iljitsch van Beijnum';
> ietf-http-wg@w3.org; bmanning@ISI.EDU; saag@mit.edu;
> ietf-http-auth@osafoundation.org
> Subject: Re: Next step on web
> phishingdraft(draft-hartman-webauth-phishing-05.txt)
>
>
> > >> There has been a discussion recently on LTRU as to
> whether a Terms
> > >> and Definitions section should be introduced within RFCs - much
> > >> like those within ISO Standards.
> > >>
> > >
> > > And my response to this suggestion is the same as it was for the
> > > "IANA considerations" or "Internationalization
> considerations" section suggestions:
> > > By all means have a "terms and definitions" section or
> whatever in
> > > the document if there's a need for one, but don't make having one
> > > mandatory in all documents.
> > >
> > > We already have more than enough useless (from a technical content
> > > perspective) boilerplate in our documents.
> > +1
>
> > Actually I don't have so much of a problem with having such
> sections
> > in drafts at review time, but I hate to see them clutter up
> published
> > RFCs.
>
> My position is the exact opposite. Full and complete review
> of drafts it of paramount importance and anything thqt
> interferes with that is unacceptable.
> And as I have pointed out, we have "running code"
> demonstrating that these things are at best distracting and
> at worst actively interfere with proper review.
>
> What's appropriate to appear in the final RFC is up to the
> RFC Editor. That's what the word "editor" implies. If the RFC
> Editor deems it appropriate to remove null sections that's
> fine, if they feel they should be retained that's fine too.
> Someone reading an RFC to learn how to implement something
> has a definite goal in mind and isn't going to be (or at
> least shouldn't be) distracted by boilerplate in the same way
> a reviewer looking for issues - a far more nebulous
> proposition - can be.
>
> > There are a lot of times when these sections aren't applicable, and
> > having them in the final document just interferes with readability.
>
> It depends on what sort of reading you're doing.
>
> > I also think that a Terms and Definitions section might encourage
> > document authors to make up new terms when they're not necessary,
> > which would also interfere with readability.  (geeks love to create
> > new language.)
>
> Very good point. Having lots of slightly varying definitions
> of various terms could be hugely harmful.
>
> RFC 2119 is a case in point. While I have some small issues
> with how RFC 2119 defines its terms, I've come to realize
> that having consistent meanings for these terms is far more important.
>
> 				Ned
>
>
>





From moore@cs.utk.edu Tue Sep 11 17:05:28 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l8BL5Scp025189
	for ; Tue, 11 Sep 2007 17:05:28 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l8BL5NfZ002318
	for ; Tue, 11 Sep 2007 17:05:23 -0400 (EDT)
Received: from bes.cs.utk.edu (bes.cs.utk.edu [160.36.56.220])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 90A9EA3EDF7
	for ; Tue, 11 Sep 2007 17:05:22 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by bes.cs.utk.edu (Postfix) with ESMTP id 31708103648;
	Tue, 11 Sep 2007 17:05:20 -0400 (EDT)
Received: from bes.cs.utk.edu ([127.0.0.1])
	by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id YkyNCOm84XO5; Tue, 11 Sep 2007 17:05:18 -0400 (EDT)
Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com
	[66.149.133.182])
	by bes.cs.utk.edu (Postfix) with ESMTP id E27C6103118;
	Tue, 11 Sep 2007 17:05:12 -0400 (EDT)
Message-ID: <46E70307.3090909@cs.utk.edu>
Date: Tue, 11 Sep 2007 17:05:11 -0400
From: Keith Moore 
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: debbie@ictmarketing.co.uk
References: <46E2E54A.2050406@isode.com>
	<8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com>
	<420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com>
	<26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com>
	<20070909234839.GA2020@boreas.isi.edu>
	<003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110>
	<01ML8DYIHPJQ003GRV@mauve.mrochek.com>
	<46E6F657.4040204@cs.utk.edu>
	<01ML8GHD48YO00005F@mauve.mrochek.com>
	<012801c7f4b6$4b2faf70$0b00a8c0@CPQ86763045110>
In-Reply-To: <012801c7f4b6$4b2faf70$0b00a8c0@CPQ86763045110>
X-Enigmail-Version: 0.95.3
OpenPGP: id=E1473978
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: discuss@apps.ietf.org, 'Iljitsch van Beijnum' ,
	ned.freed@mrochek.com, ietf@ietf.org, bmanning@isi.edu,
	saag@mit.edu, ietf-http-auth@osafoundation.org, ietf-http-wg@w3.org
Subject: Re: [saag] Next step on web
	phishingdraft(draft-hartman-webauth-phishing-05.txt)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 11 Sep 2007 21:05:28 -0000

Oh, it's very useful to have consistent terminology. And if a document
needs to use new terms, they should definitely be defined before use.  I
just don't want to encourage people to make up new terms (or more
likely, whole new paradigms with their own lexicons) when existing ones
will do.  I'm reminded of recent work in NEA, but they're not the only ones.
> I agree.  Which is why a Terms and Definitions section is darn useful as is
> an overall Term Bank.  However, I will not labour the point as I have long
> ago found that trying to sell Terminology standardization to industry is
> practically impossible - unless you rename it as Knowledge Management.
>   

From Nicolas.Williams@sun.com Tue Sep 11 17:10:37 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l8BLAaUc026139
	for ; Tue, 11 Sep 2007 17:10:36 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l8BLAU1v006685
	for ; Tue, 11 Sep 2007 17:10:31 -0400 (EDT)
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22])
	by mit.edu (Spam Firewall) with ESMTP id 28720A2DD33
	for ; Tue, 11 Sep 2007 17:10:29 -0400 (EDT)
Received: from centralmail4brm.Central.Sun.COM ([129.147.62.198])
	by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	l8BLATOa015534 for ; Tue, 11 Sep 2007 21:10:29 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail4brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id l8BLARn6024462
	for ; Tue, 11 Sep 2007 15:10:29 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id
	l8BLANH6029217; Tue, 11 Sep 2007 16:10:23 -0500 (CDT)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l8BLALVa029216; 
	Tue, 11 Sep 2007 16:10:21 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to
	Nicolas.Williams@sun.com using -f
Date: Tue, 11 Sep 2007 16:10:21 -0500
From: Nicolas Williams 
To: Ned Freed 
Message-ID: <20070911211021.GP28329@Sun.COM>
References: <46E2E54A.2050406@isode.com>
	<8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com>
	<420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com>
	<26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com>
	<20070909234839.GA2020@boreas.isi.edu>
	<003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110>
	<01ML8DYIHPJQ003GRV@mauve.mrochek.com>
	<46E6F657.4040204@cs.utk.edu>
	<01ML8GHD48YO00005F@mauve.mrochek.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <01ML8GHD48YO00005F@mauve.mrochek.com>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: discuss@apps.ietf.org, 'Iljitsch van Beijnum' ,
	Keith Moore , ietf@ietf.org, bmanning@isi.edu,
	saag@mit.edu, Debbie Garside ,
	ietf-http-auth@osafoundation.org, ietf-http-wg@w3.org
Subject: [saag] Required doc sections (Re: Next step on web	phishing
	draft(draft-hartman-webauth-phishing-05.txt))
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 11 Sep 2007 21:10:37 -0000

This thread has morphed into something else entirely.  Please change the
subject and move it to an appropriate list (I've set Reply-To:
ietf@ietf.org; please respect it).

For the record, things like IANA considerations sections should be
required of I-Ds, even if to say that there aren't any.  A single such
section gathering several such sub-sections should do ("Misc
Considerations.  This draft has no IANA considerations.  This draft has
no ...").  And some such sections might be removed by the RFC Editor, or
not (e.g., remove IANA considerations sections that say there are no
IANA considerations).

Nico
-- 

From tony@att.com Wed Sep 12 13:35:35 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l8CHZZIO030542
	for ; Wed, 12 Sep 2007 13:35:35 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l8CHZSq2017786
	for ; Wed, 12 Sep 2007 13:35:28 -0400 (EDT)
Received: from mail120.messagelabs.com (mail120.messagelabs.com
	[216.82.250.83])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 109C97B23D0
	for ; Wed, 12 Sep 2007 13:35:27 -0400 (EDT)
X-VirusChecked: Checked
X-Env-Sender: tony@att.com
X-Msg-Ref: server-14.tower-120.messagelabs.com!1189618525!24300202!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.160.20.53]
Received: (qmail 17136 invoked from network); 12 Sep 2007 17:35:26 -0000
Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com)
	(144.160.20.53)
	by server-14.tower-120.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Sep 2007 17:35:26 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1])
	by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id
	l8CHZPOF009276 for ; Wed, 12 Sep 2007 13:35:25 -0400
Received: from mlph070.sfdc.sbc.com (mlph070.sfdc.sbc.com [144.155.224.139])
	by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id
	l8CHZM8Z009263 for ; Wed, 12 Sep 2007 13:35:22 -0400
Received: from sfdc.sbc.com (localhost.localdomain [127.0.0.1])
	by mlph070.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l8CHZLs3002476
	for ; Wed, 12 Sep 2007 13:35:22 -0400
Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99])
	by mlph070.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l8CHZI13002411
	for ; Wed, 12 Sep 2007 13:35:18 -0400
Received: from [135.25.188.57] (unknown[135.25.188.57](misconfigured sender))
	by maillennium.att.com (mailgw1) with ESMTP
	id <20070912173517gw10010gnee> (Authid: tony);
	Wed, 12 Sep 2007 17:35:18 +0000
Message-ID: <46E8230F.7080004@att.com>
Date: Wed, 12 Sep 2007 13:34:07 -0400
From: Tony Hansen 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
References: <46E2E54A.2050406@isode.com>	<8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com>	<420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com>	<26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com>	<20070909234839.GA2020@boreas.isi.edu>	<003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110>	<01ML8DYIHPJQ003GRV@mauve.mrochek.com>
	<46E6F657.4040204@cs.utk.edu>
	<01ML8GHD48YO00005F@mauve.mrochek.com>
In-Reply-To: <01ML8GHD48YO00005F@mauve.mrochek.com>
X-Enigmail-Version: 0.95.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.19
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
X-Mailman-Approved-At: Wed, 12 Sep 2007 14:16:05 -0400
Cc: saag@mit.edu, discuss@apps.ietf.org, ietf-http-auth@osafoundation.org,
	ietf@ietf.org, ietf-http-wg@w3.org
Subject: Re: [saag] mandatory draft sections (was Next step on web phishing
	draft(draft-hartman-webauth-phishing-05.txt))
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 12 Sep 2007 17:35:35 -0000

My viewpoint is somewhat in between. The sections need to be there, but
only in the final draft(s) that are intended for Last Call. Prior to
that, those sections don't need anything more than a "To Be Determined"
notation. Prior to the Last Call, those sections usually don't add
anything to the technical meat of the draft and aren't necessary.
(Unless of course, the draft is dealing with IANA issues throughout.)

During Last Calls, there are many people reviewing the drafts from many
angles, including the protocol point of view and the IANA point of view
and the internationalization point of view and ....

	Tony Hansen
	tony@att.com

Ned Freed wrote:
> 
>> Actually I don't have so much of a problem with having such sections in
>> drafts at review time, but I hate to see them clutter up published
>> RFCs.
> 
> My position is the exact opposite. Full and complete review of drafts it of
> paramount importance and anything thqt interferes with that is unacceptable.
> And as I have pointed out, we have "running code" demonstrating that these
> things are at best distracting and at worst actively interfere with proper
> review.


From thrashor@gmail.com Tue Sep 18 17:08:49 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l8IL8nF0019459
	for ; Tue, 18 Sep 2007 17:08:49 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l8IL8idS009305
	for ; Tue, 18 Sep 2007 17:08:44 -0400 (EDT)
Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.237])
	by mit.edu (Spam Firewall) with ESMTP id 4ED2E9DAB87
	for ; Tue, 18 Sep 2007 17:08:41 -0400 (EDT)
Received: by nz-out-0506.google.com with SMTP id i11so1117507nzh
	for ; Tue, 18 Sep 2007 14:08:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
	bh=PN1Wym/ZSESLsMWeyfEIrXNM6C7cdh7VyOoZWI3teIA=;
	b=GwVv8A9W+eJJxekLoZdNy/jJ/Zwl1wRQ9iPGH80FMy3Xlx3+Ye8Y1vPpPiZL+9iYX3gXbxtpNKgJbNVqYp6C+5rNs3RzweEK15P7AFtNw9dXsAKl+diWaDHi/r/swb2o5w7k4MErAf/ccvzlJsQ+6pn/BrD46AZGxKZjr6yIQ0Y=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
	b=dfbqBklgO5zB+F32/N0BtatWAKNxCodXLr+76NFwIR7oWSKB91jY4JFATuhSA2Nn6wLmIeGX7K8eZ/ncmwXERCAUwDprmKT+zaeyHcal0wTEY1Ubq3aCcj4kreK+TVtfjMF9HTqWWm3vaKaO42v64Kbs+en0kO2MRPzni1aWhKc=
Received: by 10.65.141.18 with SMTP id t18mr13944746qbn.1190149720923;
	Tue, 18 Sep 2007 14:08:40 -0700 (PDT)
Received: by 10.64.193.9 with HTTP; Tue, 18 Sep 2007 14:08:40 -0700 (PDT)
Message-ID: 
Date: Wed, 19 Sep 2007 09:08:40 +1200
From: "Chris Hammond-Thrasher" 
To: saag@mit.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.12
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] Required doc sections (Re: Next step on web phishing
	draft(draft-hartman-webauth-phishing-05.txt))
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 18 Sep 2007 21:08:49 -0000

Greetings all,

I am new to the saag list. While I don't know exactly what I was
expecting to find being discussed here, I did not think it would be
document acceptance workflow, which sections are required to be
included in documents, and especially whether technical documents
ought to use technical terminology! Surely, and remember I am new to
ietf business, there is some other group outside the saag that
determines these matters?

I am intrigued by Phillip's September 9 comment regarding combining
the best of openid, saml, cardspace, and ws-* to arrive at a better
http authentication mechanism that is resistent to man-in-the-middle
attacks. How might that work? It seems to me that it comes down to
solving the who-do-you-trust question - a certificate authority, a 3rd
party authenticator like Google, Yahoo, etc., or is there another way?

-cht

Chris Hammond-Thrasher, MLIS, CISSP
blogger, librarian, and so much more

-- 

The lastest story at Digital Fiji:
Is blogging a dead issue in Fiji?


--Blogsigs.com, Link your own blog posts.
http://www.blogsigs.com

From Nicolas.Williams@sun.com Tue Sep 18 17:46:38 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l8ILkcdP028033
	for ; Tue, 18 Sep 2007 17:46:38 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l8ILkVPk000233
	for ; Tue, 18 Sep 2007 17:46:32 -0400 (EDT)
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43])
	by mit.edu (Spam Firewall) with ESMTP id DA7E47C1834
	for ; Tue, 18 Sep 2007 17:46:30 -0400 (EDT)
Received: from centralmail4brm.Central.Sun.COM ([129.147.62.198])
	by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	l8ILkURk013168 for ; Tue, 18 Sep 2007 21:46:30 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail4brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id l8ILkTs5010627
	for ; Tue, 18 Sep 2007 15:46:29 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id
	l8ILkTMu004795; Tue, 18 Sep 2007 16:46:29 -0500 (CDT)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l8ILkSoC004794; 
	Tue, 18 Sep 2007 16:46:28 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to
	Nicolas.Williams@sun.com using -f
Date: Tue, 18 Sep 2007 16:46:28 -0500
From: Nicolas Williams 
To: Chris Hammond-Thrasher 
Message-ID: <20070918214628.GO3122@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: 3.501
X-Spam-Level: *** (3.501)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] Required doc sections (Re: Next step on web phishing
	draft(draft-hartman-webauth-phishing-05.txt))
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 18 Sep 2007 21:46:38 -0000

On Wed, Sep 19, 2007 at 09:08:40AM +1200, Chris Hammond-Thrasher wrote:
> I am intrigued by Phillip's September 9 comment regarding combining
> the best of openid, saml, cardspace, and ws-* to arrive at a better
> http authentication mechanism that is resistent to man-in-the-middle
> attacks. How might that work? It seems to me that it comes down to
> solving the who-do-you-trust question - a certificate authority, a 3rd
> party authenticator like Google, Yahoo, etc., or is there another way?

I think the thing to do is: use TLS for "transport security"[0] and use
anything else for authentication but with channel binding to TLS[1].

Strong, federatable authentication + channel binding to TLS => less
concern over the lack of a true PKI, and improved situation w.r.t.
phishing (because the authentication and channel binding must succeed;
the server's TLS certificate becomes much less interesting).

[0]  Every once in a while someone will point out that TLS is not a
     transport.  I don't care, but to avoid the issue I'm using scare
     quotes.

[1]  See:

     http://www.ietf.org/internet-drafts/draft-williams-on-channel-binding-04.txt

     (currently in the RFC-Editor's queue)

     and

     http://www.ietf.org/internet-drafts/draft-johansson-http-gss-00.txt
     http://www.ietf.org/internet-drafts/draft-johansson-http-tls-cb-00.txt

     The latter two provide a way to do authentication based on the
     GSS-API (but it could be SAML if you like) and channel binding to
     TLS from such authentication, respectively.

     I've got a draft document somewhere of how to extend the
     XMLHttpRequest JavaScript object to put some UI control over
     GSS/SAML/whatever authentication in the hands of the web developer,
     + UI control over enrolment, + the above.  I need to turn it into a
     blog post or something.

Nico
-- 

From Nicolas.Williams@sun.com Tue Sep 18 17:47:08 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l8ILl8O4028211
	for ; Tue, 18 Sep 2007 17:47:08 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l8ILl3WV002330
	for ; Tue, 18 Sep 2007 17:47:04 -0400 (EDT)
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43])
	by mit.edu (Spam Firewall) with ESMTP id 2092AA66217
	for ; Tue, 18 Sep 2007 17:47:02 -0400 (EDT)
Received: from centralmail4brm.Central.Sun.COM ([129.147.62.198])
	by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	l8ILl2ER013332 for ; Tue, 18 Sep 2007 21:47:02 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail4brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id l8ILl1gC010801
	for ; Tue, 18 Sep 2007 15:47:02 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id
	l8ILl1Aw004802; Tue, 18 Sep 2007 16:47:01 -0500 (CDT)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l8ILl16f004801; 
	Tue, 18 Sep 2007 16:47:01 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to
	Nicolas.Williams@sun.com using -f
Date: Tue, 18 Sep 2007 16:47:01 -0500
From: Nicolas Williams 
To: Chris Hammond-Thrasher 
Message-ID: <20070918214701.GE3328@Sun.COM>
References: 
	<20070918214628.GO3122@Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20070918214628.GO3122@Sun.COM>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] Required doc sections (Re: Next step on web phishing
	draft(draft-hartman-webauth-phishing-05.txt))
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 18 Sep 2007 21:47:08 -0000

Sigh.  I should have changed the subject line.



From dimitri.warnez@nxp.com Wed Sep 19 22:59:32 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l8K2xVhN014904
	for ; Wed, 19 Sep 2007 22:59:32 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l8K2xPtI010717
	for ; Wed, 19 Sep 2007 22:59:25 -0400 (EDT)
Received: from gw-eur4.philips.com (gw-eur4.philips.com [161.85.125.10])
	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 53550A43F60
	for ; Wed, 19 Sep 2007 22:59:24 -0400 (EDT)
Received: from smtpscan-eur6.philips.com (smtpscan-eur6.mail.philips.com
	[130.144.57.169])
	by gw-eur4.philips.com (Postfix) with ESMTP id 63DDA49753
	for ; Thu, 20 Sep 2007 02:59:11 +0000 (UTC)
Received: from smtpscan-eur6.philips.com (localhost [127.0.0.1])
	by localhost.philips.com (Postfix) with ESMTP id 2C06E1073
	for ; Thu, 20 Sep 2007 02:59:22 +0000 (GMT)
Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com
	[130.144.57.171])
	by smtpscan-eur6.philips.com (Postfix) with ESMTP id C7BAF1062
	for ; Thu, 20 Sep 2007 02:59:21 +0000 (GMT)
Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com
	[130.139.27.125])
	by smtprelay-eur2.philips.com (Postfix) with ESMTP id 6949AA7
	for ; Thu, 20 Sep 2007 02:59:21 +0000 (GMT)
From: Dimitri Warnez 
To: saag@mit.edu
Message-ID: 
Date: Thu, 20 Sep 2007 05:02:51 +0200
X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release
	6.5.5FP2HF329 | April 6, 2007) at 20/09/2007 05:02:53
MIME-Version: 1.0
Content-type: multipart/alternative; 
	Boundary="0__=4EBBF9CFDF833B728f9e8a93df938690918c4EBBF9CFDF833B72"
Content-Disposition: inline
X-Spam-Score: 0.95
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] Dimitri Warnez is out of the office.
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 20 Sep 2007 02:59:32 -0000

--0__=4EBBF9CFDF833B728f9e8a93df938690918c4EBBF9CFDF833B72
Content-type: text/plain; charset=US-ASCII


I will be out of the office starting  2007-09-14 and will not return until
2007-10-08.

For urgent matters, feel free to contact Stefaan Motte
(stefaan.motte@nxp.com).
--0__=4EBBF9CFDF833B728f9e8a93df938690918c4EBBF9CFDF833B72
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline



I will be out of the office starting  2007-09-14 and will not return until 2007-10-08.



For urgent matters, feel free to contact Stefaan Motte (stefaan.motte@nxp.com).
--0__=4EBBF9CFDF833B728f9e8a93df938690918c4EBBF9CFDF833B72--


From magnus.westerlund@ericsson.com Thu Sep 27 07:33:41 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l8RBXeUY006090
	for ; Thu, 27 Sep 2007 07:33:40 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l8RBXX9A004090
	for ; Thu, 27 Sep 2007 07:33:33 -0400 (EDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id B498D9D2F5C
	for ; Thu, 27 Sep 2007 07:33:32 -0400 (EDT)
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	5686120B72; Thu, 27 Sep 2007 13:33:31 +0200 (CEST)
X-AuditID: c1b4fb3c-afe7ebb0000007e1-90-46fb950b7cdf
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	3455720B6C; Thu, 27 Sep 2007 13:33:31 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 27 Sep 2007 13:33:31 +0200
Received: from [147.214.30.247] ([147.214.30.247]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 27 Sep 2007 13:33:30 +0200
Message-ID: <46FB950A.6020401@ericsson.com>
Date: Thu, 27 Sep 2007 13:33:30 +0200
From: Magnus Westerlund 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Internet Area , ops-area@ietf.org,
	discuss@apps.ietf.org, routing-discussion@ietf.org, SAAG 
X-Enigmail-Version: 0.95.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Sep 2007 11:33:30.0993 (UTC)
	FILETIME=[3AE46610:01C800FA]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.12
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: tsvwg 
Subject: [saag] Guidelines for protocol designers using UDP
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: tsvwg 
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 27 Sep 2007 11:33:41 -0000

Hi,

In the TSVWG we have been developing a guidelines document for UDP. It
is intended for protocol designers that consider using UDP in their
protocol. We do hope that it will help remove some of the misconception
that UDP is a simple protocol to use. It might look that way because
most of the features necessary for being acceptable to deploy on the
general internet needs to be specified by the one using UDP. It is also
something that the Transport ADs already started using as help in
explaining why and what to fix when we put a DISCUSS on your document
that is using UDP.

http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp-guidelines-03.txt

So TSVWG is still working on this document but we are now considering it
quite complete. So we are looking for feedback from you. Are there
things that are unclear, missing, wrong, etc. Please provide your
feedback to TSVWG (tsvwg@ietf.org).

Thanks

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From tlr+bounce@w3.org Tue Oct 23 13:43:19 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l9NHhJm6016177
	for ; Tue, 23 Oct 2007 13:43:19 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l9NHhBN7021994
	for ; Tue, 23 Oct 2007 13:43:12 -0400 (EDT)
Received: from homer.w3.org (homer.w3.org [128.30.52.30])
	by mit.edu (Spam Firewall) with ESMTP id F0AED905D20
	for ; Tue, 23 Oct 2007 13:43:10 -0400 (EDT)
Received: from raktajino.does-not-exist.org (homer.w3.org [128.30.52.30])
	by homer.w3.org (Postfix) with ESMTP id 6CB0E4F2EF;
	Tue, 23 Oct 2007 13:43:10 -0400 (EDT)
Received: from roessler by raktajino.does-not-exist.org with local (Exim 4.66)
	(envelope-from )
	id 1IkNmY-0004AU-UI; Tue, 23 Oct 2007 19:43:10 +0200
Date: Tue, 23 Oct 2007 19:43:10 +0200
From: Thomas Roessler 
To: saag@mit.edu
Message-ID: <20071023174310.GQ9742@raktajino.does-not-exist.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.16 (2007-10-11)
X-Spam-Score: 0.32
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id
	l9NHhJm6016177
Subject: [saag] [fwd] Report on Workshop on Next Steps for XML Signature and
	XML	Encryption (from: tlr@w3.org)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 23 Oct 2007 17:43:19 -0000

FYI.
-- 
Thomas Roessler, W3C  




----- Forwarded message from Thomas Roessler  -----

From: Thomas Roessler 
To: public-xmlsec-discuss@w3.org
Date: Tue, 23 Oct 2007 19:40:41 +0200
Subject: Report on Workshop on Next Steps for XML Signature and XML
	Encryption

On 25 and 26 September 2007, W3C held a Workshop on Next Steps for
XML Signature and XML Encryption [1] in Mountain View, CA, USA,
hosted by VeriSign. The group has published its summary report [2].

The Workshop report indicates strong interest in additional work on
XML security and interest in a Working Group. Attendees identified
the areas of highest interest:

   - Create a basic profile of XML Signature
   - Review and possibly update the referencing
     model using xml:id and other mechanisms
   - Update cryptographic algorithms
   - Revisit XML canonicalization
   - Update the transform model.

Areas of ongoing and medium interest that were identified are scalable
profiling, implementation guidance, key management issues, XKMS, XML 1.1, EXI,
and interaction with other security organizations.

The Workshop report will serve as input for the deliverable of the XML
Security Specification Maintenance Working Group to propose a draft charter
for possible follow-up work. 


To enable discussion among Workshop attendees, Working Group
participants, and the broader community, this mailing list,
public-xmlsec-discuss@w3.org (public archive [3]), has been created.

Participation in the mailing list is open to all interested parties.

Current list subscribers include the members of the XML Security
Specifications Maintenance Working Group, and workshop participants.
If you want to be removed from the list, please let me know.

[1] http://www.w3.org/2007/xmlsec/ws/cfp
[2] http://www.w3.org/2007/xmlsec/ws/report
[3] http://lists.w3.org/Archives/Public/public-xmlsec-discuss/2007Oct/

-- 
Thomas Roessler, W3C  



----- End forwarded message -----


From hartmans@MIT.EDU Mon Oct 29 13:27:45 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l9THRjcL013654
	for ; Mon, 29 Oct 2007 13:27:45 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	l9THRaTB020299
	for ; Mon, 29 Oct 2007 13:27:36 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (dhcp-18-188-10-61.dyn.mit.edu
	[18.188.10.61]) by mit.edu (Spam Firewall) with ESMTP id 816FAB5667E
	for ; Mon, 29 Oct 2007 13:27:36 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042)
	id F2C264A45; Mon, 29 Oct 2007 13:27:35 -0400 (EDT)
From: Sam Hartman 
To: ietf@ietf.org, iesg@ietf.org, nicolas.williams@sun.com
Date: Mon, 29 Oct 2007 13:27:35 -0400
Message-ID: 
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: [saag] Minor addition to draft-williams-on-channel-binding;
	one week to respond
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Mon, 29 Oct 2007 17:27:45 -0000



Folks, while attempting to use draft-williams-on-channel-binding in
the SASL working group, we came across an ambiguity.

In response to IETF last call comments we added the concept of a
unique prefix and a registry of prefixes for channel binding type.  We
added a requirement that applications make sure that one channel could
not conflict with another channel type.  However we didn't specify how
the prefix was to be used.

This ambiguity made using specifications more complex than needed.
So, we propose to actually say that the prefix needs to be a prefix.
This change has the support of the authors, myself, and members of the
SASL community including the author of the document trying to use this
mechanism.

In particular, we propose adding the following text:


    >> "Under this framework, channel bindings MUST start with the
    >> channel binding unique prefix followed by a colon (ASCII 0x3A).
    >> "


The document is currently in auth48.  I will approve this change if
there are not objections in a week.


From hartmans@MIT.EDU Mon Oct 29 13:54:56 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l9THsu2O023188
	for ; Mon, 29 Oct 2007 13:54:56 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l9THsnko002774
	for ; Mon, 29 Oct 2007 13:54:49 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (dhcp-18-188-10-61.dyn.MIT.EDU
	[18.188.10.61]) by mit.edu (Spam Firewall) with ESMTP id 02F4194D35A
	for ; Mon, 29 Oct 2007 13:54:48 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042)
	id 8C40E4A45; Mon, 29 Oct 2007 13:54:48 -0400 (EDT)
From: Sam Hartman 
To: saag@MIT.EDU
Date: Mon, 29 Oct 2007 13:54:48 -0400
Message-ID: 
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: iesg@ietf.org
Subject: [saag] Stepping down in March
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Mon, 29 Oct 2007 17:54:56 -0000


It's with very mixed feelings that I'm writing to announce that I will
be stepping down in March from my position as a security area director.

These days, the IESG is an incredibly rewarding experience.  I've
gotten to a point where I can efficiently review documents.  The rest
of the IESG is great to work with and we're getting a lot done.  I
feel that my work is making a difference.

However I don't believe I'll have the necessary time to continue in
the security area director role.  I'm looking forward to the birth of
my first child in early February.  I've also taken on the role of
Chief Technologist at the MIT Kerberos Consortium.  I don't think I
will have time for my family obligations, for the consortium role and
to continue as area director.  So, I have chosen to step down as
security area director.


I do plan on continuing significant involvement in the IETF.  I'll
definitely be involved because of my Kerberos work and I may have time
for leadership roles that require less of a commitment than the IESG.


As you may be aware, the IESG asked area directors not to inform the
community about whether they were returning to make sure the nomcom
had a good list of potential candidates.  The nomcom has informed me
that now would be a good time to make an announcement, so I'm doing
so.


It has been a pleasure to work with you all and I will look forward to
working together in the future, while missing working as part of the
IESG.


Sam Hartman
Security Area Director

From housley@vigilsec.com Mon Oct 29 14:06:40 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l9TI6eJH026690
	for ; Mon, 29 Oct 2007 14:06:40 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l9TI6X4v025237
	for ; Mon, 29 Oct 2007 14:06:33 -0400 (EDT)
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152])
	by mit.edu (Spam Firewall) with SMTP id AEFB5D8D365
	for ; Mon, 29 Oct 2007 14:06:32 -0400 (EDT)
Received: (qmail 27077 invoked by uid 0); 29 Oct 2007 18:06:27 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.231.48.203)
	by woodstock.binhost.com with SMTP; 29 Oct 2007 18:06:27 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 29 Oct 2007 14:06:29 -0400
To: Sam Hartman 
From: Russ Housley 
In-Reply-To: 
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-Id: <20071029180632.AEFB5D8D365@mit.edu>
X-Spam-Score: 0.788
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, iesg@ietf.org
Subject: Re: [saag] Stepping down in March
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Mon, 29 Oct 2007 18:06:40 -0000

Sam:

We value the contribution you have made to the IETF Community as 
Security AD, and we look forward to you continued involvement.

Best wishes with your new role and fatherhood,
   Russ


At 01:54 PM 10/29/2007, Sam Hartman wrote:

>It's with very mixed feelings that I'm writing to announce that I will
>be stepping down in March from my position as a security area director.
>
>These days, the IESG is an incredibly rewarding experience.  I've
>gotten to a point where I can efficiently review documents.  The rest
>of the IESG is great to work with and we're getting a lot done.  I
>feel that my work is making a difference.
>
>However I don't believe I'll have the necessary time to continue in
>the security area director role.  I'm looking forward to the birth of
>my first child in early February.  I've also taken on the role of
>Chief Technologist at the MIT Kerberos Consortium.  I don't think I
>will have time for my family obligations, for the consortium role and
>to continue as area director.  So, I have chosen to step down as
>security area director.
>
>
>I do plan on continuing significant involvement in the IETF.  I'll
>definitely be involved because of my Kerberos work and I may have time
>for leadership roles that require less of a commitment than the IESG.
>
>
>As you may be aware, the IESG asked area directors not to inform the
>community about whether they were returning to make sure the nomcom
>had a good list of potential candidates.  The nomcom has informed me
>that now would be a good time to make an announcement, so I'm doing
>so.
>
>
>It has been a pleasure to work with you all and I will look forward to
>working together in the future, while missing working as part of the
>IESG.
>
>
>Sam Hartman
>Security Area Director


From tim.polk@nist.gov Tue Oct 30 10:23:06 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l9UEN6FQ029392
	for ; Tue, 30 Oct 2007 10:23:06 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l9UEMxrp000435
	for ; Tue, 30 Oct 2007 10:22:59 -0400 (EDT)
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP
	id 7AB51DA39B9; Tue, 30 Oct 2007 10:22:58 -0400 (EDT)
Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id l9UEMRr3011560;
	Tue, 30 Oct 2007 10:22:27 -0400
In-Reply-To: 
References: 
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <554EBFCD-B8FE-429C-8A84-EE7A4544E939@nist.gov>
Content-Transfer-Encoding: 7bit
From: Tim Polk 
Date: Tue, 30 Oct 2007 10:22:27 -0400
To: Sam Hartman 
X-Mailer: Apple Mail (2.752.2)
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: tim.polk@nist.gov
X-Spam-Score: 0.01
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, iesg@ietf.org
Subject: Re: [saag] Stepping down in March
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 30 Oct 2007 14:23:06 -0000

Sam,

You are not the only one experiencing very mixed feelings!  As your  
co-AD, I have
personally benefited from you experience and insight in security,  
IETF protocols,
and the IETF process.  As a community, we have all benefited from  
those qualities,
and your leadership.  Your shoes will be hard to fill.

However, I am delighted for you and your new role as a father.   
Congratulations!
The joys and rewards of parenthood continue to amaze me, and should  
not be
missed even for something as important as the IETF!

I am also pleased - make that relieved - to hear that you intend to  
remain involved
in the IETF.  I am sure that many in the IETF community will be  
looking for
opportunities to leverage your considerable talents in new ways after  
March.

Thanks,

Tim Polk


On Oct 29, 2007, at 1:54 PM, Sam Hartman wrote:

>
> It's with very mixed feelings that I'm writing to announce that I will
> be stepping down in March from my position as a security area  
> director.
>
> These days, the IESG is an incredibly rewarding experience.  I've
> gotten to a point where I can efficiently review documents.  The rest
> of the IESG is great to work with and we're getting a lot done.  I
> feel that my work is making a difference.
>
> However I don't believe I'll have the necessary time to continue in
> the security area director role.  I'm looking forward to the birth of
> my first child in early February.  I've also taken on the role of
> Chief Technologist at the MIT Kerberos Consortium.  I don't think I
> will have time for my family obligations, for the consortium role and
> to continue as area director.  So, I have chosen to step down as
> security area director.
>
>
> I do plan on continuing significant involvement in the IETF.  I'll
> definitely be involved because of my Kerberos work and I may have time
> for leadership roles that require less of a commitment than the IESG.
>
>
> As you may be aware, the IESG asked area directors not to inform the
> community about whether they were returning to make sure the nomcom
> had a good list of potential candidates.  The nomcom has informed me
> that now would be a good time to make an announcement, so I'm doing
> so.
>
>
> It has been a pleasure to work with you all and I will look forward to
> working together in the future, while missing working as part of the
> IESG.
>
>
> Sam Hartman
> Security Area Director
>
>


From housley@vigilsec.com Tue Oct 30 11:52:09 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l9UFq8Oc030448
	for ; Tue, 30 Oct 2007 11:52:09 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	l9UFq1NB022615
	for ; Tue, 30 Oct 2007 11:52:01 -0400 (EDT)
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152])
	by mit.edu (Spam Firewall) with SMTP id 27681B6E33F
	for ; Tue, 30 Oct 2007 11:52:00 -0400 (EDT)
Received: (qmail 2910 invoked by uid 0); 30 Oct 2007 15:51:55 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.231.48.203)
	by woodstock.binhost.com with SMTP; 30 Oct 2007 15:51:55 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 30 Oct 2007 10:43:16 -0400
To: Sam Hartman , iesg@ietf.org
From: Russ Housley 
In-Reply-To: 
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-Id: <20071030155200.27681B6E33F@mit.edu>
X-Spam-Score: 0.84
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] Minor addition to  draft-williams-on-channel-binding;
 one week to respond
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 30 Oct 2007 15:52:09 -0000

I support this late addition.

Russ


At 01:27 PM 10/29/2007, Sam Hartman wrote:


>Folks, while attempting to use draft-williams-on-channel-binding in
>the SASL working group, we came across an ambiguity.
>
>In response to IETF last call comments we added the concept of a
>unique prefix and a registry of prefixes for channel binding type.  We
>added a requirement that applications make sure that one channel could
>not conflict with another channel type.  However we didn't specify how
>the prefix was to be used.
>
>This ambiguity made using specifications more complex than needed.
>So, we propose to actually say that the prefix needs to be a prefix.
>This change has the support of the authors, myself, and members of the
>SASL community including the author of the document trying to use this
>mechanism.
>
>In particular, we propose adding the following text:
>
>
>     >> "Under this framework, channel bindings MUST start with the
>     >> channel binding unique prefix followed by a colon (ASCII 0x3A).
>     >> "
>
>
>The document is currently in auth48.  I will approve this change if
>there are not objections in a week.
>
>_______________________________________________
>saag mailing list
>saag@mit.edu
>http://mailman.mit.edu/mailman/listinfo/saag


From jhutz@cmu.edu Thu Nov  1 13:05:13 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lA1H5C40014771
	for ; Thu, 1 Nov 2007 13:05:12 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	lA1H55rA000832
	for ; Thu, 1 Nov 2007 13:05:05 -0400 (EDT)
Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.201.52])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP
	id E1C82970A37; Thu,  1 Nov 2007 13:05:04 -0400 (EDT)
Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170])
	(authenticated bits=0)
	by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id lA1H4gvh006577
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 1 Nov 2007 13:04:43 -0400 (EDT)
Date: Thu, 01 Nov 2007 13:04:42 -0400
From: Jeffrey Hutzelman 
To: Sam Hartman , ietf@ietf.org, iesg@ietf.org,
	nicolas.williams@sun.com
Message-ID: <13B63C84E8025BD559512B33@sirius.fac.cs.cmu.edu>
In-Reply-To: 
References: 
Originator-Info: login-token=Mulberry:01CiqOW3SSA89WdQbcPai+yqGcxYaRXgd3n7zAQKo=;
	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: 0.01
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] Minor addition to draft-williams-on-channel-binding;
 one week to respond
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 01 Nov 2007 17:05:13 -0000



On Monday, October 29, 2007 01:27:35 PM -0400 Sam Hartman 
 wrote:

>
>
> Folks, while attempting to use draft-williams-on-channel-binding in
> the SASL working group, we came across an ambiguity.
>
> In response to IETF last call comments we added the concept of a
> unique prefix and a registry of prefixes for channel binding type.  We
> added a requirement that applications make sure that one channel could
> not conflict with another channel type.  However we didn't specify how
> the prefix was to be used.
>
> This ambiguity made using specifications more complex than needed.
> So, we propose to actually say that the prefix needs to be a prefix.
> This change has the support of the authors, myself, and members of the
> SASL community including the author of the document trying to use this
> mechanism.
>
> In particular, we propose adding the following text:
>
>
>     >> "Under this framework, channel bindings MUST start with the
>     >> channel binding unique prefix followed by a colon (ASCII 0x3A).
>     >> "
>
>
> The document is currently in auth48.  I will approve this change if
> there are not objections in a week.

+1

From turners@ieca.com Wed Dec  5 13:53:19 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lB5IrJcJ005977
	for ; Wed, 5 Dec 2007 13:53:19 -0500
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	lB5Ir6vM025760
	for ; Wed, 5 Dec 2007 13:53:06 -0500 (EST)
Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com
	[206.190.52.173]) by mit.edu (Spam Firewall) with SMTP id 4D320A953FC
	for ; Wed,  5 Dec 2007 13:52:44 -0500 (EST)
Received: (qmail 93344 invoked from network); 5 Dec 2007 18:52:44 -0000
Received: from unknown (HELO Wylie) (turners@ieca.com@216.18.3.1 with login)
	by smtp104.biz.mail.re2.yahoo.com with SMTP; 5 Dec 2007 18:52:44 -0000
X-YMail-OSG: tghf5FUVM1lx8zCH5wKloLElwsJLqF9X_dPAi8fJ0VOcT60wwpcohmL_dTGQYiy7IcpExgRwc49.ZiEt752Lk74oClUsEqsP0XY0Ak9RtecwGfhbd65.Lc4Ozqhath6Sp7pRBAUBukUT_g--
From: "Turner, Sean P." 
To: , 
Date: Wed, 5 Dec 2007 10:48:30 -0800
Organization: IECA, Inc.
Message-ID: <01b501c8376f$6e931690$e8f9a8c0@Wylie>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_01B6_01C8372C.606FD690"
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: Acg3b23R0yRMW7g/TWO9eO0tMj16SA==
X-Spam-Score: 0.02
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] summary of smime-wg session at IETF 70
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 05 Dec 2007 18:53:20 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_01B6_01C8372C.606FD690
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

S/MIME Minutes/Summary - IETF 70

3 drafts were published:
   RFC5055 (ESSCertId update),
   RFC 5083 (AuthEnvelopedData content type),
   RFC5084 (aes-ccm/aes-gcm use of AuthEnvelopedData content type)
2 with RFC editor symkeydist and cades
3 addressing IESG LC comments rsa-kem, ibearch, bfibecms
4 active IDs:
   Multiple Signatures Attribute,
   SHA2 Algorithms,
   S/MIME V3.2 MSG,
   S/MIME v3.2 CERT

Jim Schaad discussed the Multiple Signatures Attribute draft
Only updates were to security considerations section. Consider work complete
and move to issue 4-week WG LC (accounts for holidaze)

Sean Turner discussed the SHA2 algorithms draft 
The draft was updated to include object identifiers for RSA and ECDSA
algorithms. Consider work complete and move to issue 4-week WG LC

Sean Turner discussed the S/MIME v3.2 drafts
Intent of drafts is to update algorithms. Adopted IKEv2 language with
respect to MUST, SHOULD+, and SHOULD- to provide implementors more
information. Dropped RC2 support, made SHA-256 MUST, SHA-1 SHOULD-, AES 128
MUST, etc. Two comments were raised about IPR: SHA2 and ECDSA. Should we
have an IPR statement from NIST (or whoever) about SHA2? Since we made ECDSA
a SHOULD+ is there any IPR with respect to ECDSA and issuing certificates or
using it with S/MIME?

Paul Hoffman discussed draft-hoffman-cms-new-asn1-00
Developed an ID to include ASN.1 for most S/MIME WG ASN.1 modules. Moving to
support the latest ASN.1 which is made possible by the A2C compiler they
have developed. Question was whether WG should adopt the draft as a WG item.
The WG felt that it should be because a) the WG is place where S/MIME
implmentors should discuss implementation issues b) it will be listed on the
WG charter page and therefore will be easier to find. There were no
objections to adding it to the WG.  

Wrap-up discussion
WG LCs will be issued for SHA2 and Mutliple Signatures.
Ask WG what key sizes should be required, track down IPR issues.
Accept ASN ID as work item.

------=_NextPart_000_01B6_01C8372C.606FD690
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable






summary of smime-wg session at IETF 70





S/MIME Minutes/Summary - IETF 70




3 drafts were published:


   RFC5055 (ESSCertId =
update),


   RFC 5083 =
(AuthEnvelopedData content type),


   RFC5084 (aes-ccm/aes-gcm =
use of AuthEnvelopedData content type)


2 with RFC editor symkeydist and =
cades


3 addressing IESG LC comments rsa-kem, =
ibearch, bfibecms


4 active IDs:


   Multiple Signatures =
Attribute,


   SHA2 Algorithms,


   S/MIME V3.2 MSG,


   S/MIME v3.2 CERT




Jim Schaad discussed the Multiple =
Signatures Attribute draft


Only updates were to security =
considerations section. Consider work complete and move to issue 4-week =
WG LC (accounts for holidaze)



Sean Turner discussed the SHA2 =
algorithms draft 


The draft was updated to include =
object identifiers for RSA and ECDSA algorithms. Consider work complete =
and move to issue 4-week WG LC



Sean Turner discussed the S/MIME v3.2 =
drafts


Intent of drafts is to update =
algorithms. Adopted IKEv2 language with respect to MUST, SHOULD+, and =
SHOULD- to provide implementors more information. Dropped RC2 support, =
made SHA-256 MUST, SHA-1 SHOULD-, AES 128 MUST, etc. Two comments were =
raised about IPR: SHA2 and ECDSA. Should we have an IPR statement from =
NIST (or whoever) about SHA2? Since we made ECDSA a SHOULD+ is there any =
IPR with respect to ECDSA and issuing certificates or using it with =
S/MIME?



Paul Hoffman discussed =
draft-hoffman-cms-new-asn1-00


Developed an ID to include ASN.1 for =
most S/MIME WG ASN.1 modules. Moving to support the latest ASN.1 which =
is made possible by the A2C compiler they have developed. Question was =
whether WG should adopt the draft as a WG item. The WG felt that it =
should be because a) the WG is place where S/MIME implmentors should =
discuss implementation issues b) it will be listed on the WG charter =
page and therefore will be easier to find. There were no objections to =
adding it to the WG.  



Wrap-up discussion


WG LCs will be issued for SHA2 and =
Mutliple Signatures.


Ask WG what key sizes should be =
required, track down IPR issues.


Accept ASN ID as work item.





------=_NextPart_000_01B6_01C8372C.606FD690--


From tgondrom@opentext.com Wed Dec  5 17:28:47 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lB5MSl6s002138
	for ; Wed, 5 Dec 2007 17:28:47 -0500
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	lB5MSYaj002276
	for ; Wed, 5 Dec 2007 17:28:35 -0500 (EST)
Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48])
	by mit.edu (Spam Firewall) with ESMTP id 793C0C4761F
	for ; Wed,  5 Dec 2007 17:28:33 -0500 (EST)
Received: from mucpm01.smtp.dmz.opentext.com (localhost [127.0.0.1])
	by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id lB5MSUE3018666; 
	Wed, 5 Dec 2007 23:28:30 +0100 (MET)
Received: from MUCXGC2.opentext.net (mucxg04.opentext.net [149.235.128.138])
	by mucpm01.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id
	lB5MSTOH011957; Wed, 5 Dec 2007 17:28:29 -0500
	(envelope-from tgondrom@opentext.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C8378E.290512C5"
Date: Wed, 5 Dec 2007 23:28:27 +0100
Message-ID: <2666EB2A846BAC4BB2D7F593301A786801F19FFE@MUCXGC2.opentext.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [saag] Summary of LTANS WG meeting at IETF 70th in Vancouver
Thread-Index: Acg3jigIqLZ2p8AHTI2xqzq3Ft+gFw==
From: "Tobias Gondrom" 
To: 
X-Archived: msg.AOHYkGL:2007-12-05:mucpm01.smtp.dmz.opentext.com
X-Spam-Score: 0.14
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: Carl Wallace 
Subject: [saag]  Summary of LTANS WG meeting at IETF 70th in Vancouver
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 05 Dec 2007 22:28:47 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8378E.290512C5
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Summary of LTANS WG meeting 12/4/2007 - 70th IETF - Vancouver:=20
(Detailed minutes have been published on the meeting materials page.)

Current work of LTANS WG focuses on finishing existing drafts to bring =
them to IETF LC.=20
There are currently five I-Ds in progress:=20
- ERS/SCVP is closing WG LC right after 70th IETF and will proceed to =
IETF LC.=20
- DSSC (info about algorithm lifetimes) will go into WG LC soon
- XMLERS (had a larger revision and may go into WG LC in Jan/Feb)
- validate has been revised and may go to WG LC in Jan/Feb)
- LTAP: WG plans to move from planned status "proposed standard" to =
"experimental" as we do not see sufficient number of implementations - =
planned WG LC in Feb

Further comments:=20
- as SCVP has now moved to RFC, ERS/SCVP will continue to proceed as =
well. Sample ERS/SCVP artifacts will be made available shortly after the =
IETF meeting and a responder may be made available in January for =
interop testing.
- XMLERS has be revised and its XML structure now closely matches ERS =
ASN.1
- invitation for additional XMLERS implementations to run interop tests
- search for government authorities (that provide info on suitability of =
algorithms and their pararmeters) who want to use and provide data in =
the dssc format.=20
- LTAP will change status to "experimental"
- currently tbd whether LTANS shall re-continue work on architecture I-D =
to explain how the standards work together and outline the architecture =
of an overall system

Cheers, Tobias


__________________________________________
Tobias Gondrom
Head of Open Text Security Team
Director, Product Security

Open Text
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:tobias.gondrom@opentext.com=20
Internet: http://www.opentext.com/ =20

Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, =
Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 =
4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: =
M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number =
/USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John =
Shackleton, Walter K=F6hler



------_=_NextPart_001_01C8378E.290512C5
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






[saag] Summary of LTANS WG meeting at IETF 70th in =
Vancouver





Summary of LTANS WG meeting 12/4/2007 - 70th IETF – Vancouver: 



(Detailed minutes have been published on the meeting materials =
page.)



Current =
work of LTANS WG focuses on finishing existing drafts to bring them to IETF LC. =




There =
are currently five I-Ds in progress: =




- ERS/SCVP is closing WG LC right after =
70th IETF and will proceed to IETF LC. 



- =
DSSC (info about algorithm lifetimes) will go into WG LC =
soon



- =
XMLERS (had a larger revision and may go into WG LC in =
Jan/Feb)



- =
validate has been revised and may go to WG LC in =
Jan/Feb)



- =
LTAP: WG plans =
to move from planned status “proposed standard” to “experimental” =
as we do not see sufficient number of implementations – =
planned WG LC in Feb



Further comments: 



- as =
SCVP has now moved to RFC, ERS/SCVP will continue to proceed as well. Sample ERS/SCVP artifacts will be made available shortly after the IETF =
meeting and a responder may be made available in January for interop =
testing.



- XMLERS has be revised and its XML structure now closely =
matches ERS ASN.1



- invitation for additional XMLERS implementations to run =
interop tests



- search for government authorities (that provide info on suitability =
of algorithms and their pararmeters) who want to use and provide data in the dssc =
format. 



- =
LTAP will change status to “experimental”



- =
currently tbd whether LTANS shall re-continue work on architecture I-D to explain how the standards work together and outline the architecture of an overall system



Cheers, Tobias





__________________________________________

Tobias =
Gondrom

Head of =
Open Text Security Team

Director, Product Security



Open =
Text

Technopark 2

Werner-von-Siemens-Ring 20

D-85630 Grasbrunn





Phone: +49 (0) 89 4629-1816

Mobile: +49 (0) 173 5942987

Telefax: +49 (0) 89 4629-33-1816

eMail: mailto:tobias.gondrom@opentex=
t.com

Internet: http://www.opentext.com/  =




Place =
of Incorporation / Sitz der Gesellschaft: Open Text GmbH, =
Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 =
4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: =
M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number =
/USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John =
Shackleton, Walter K=F6hler







------_=_NextPart_001_01C8378E.290512C5--

From ekr@networkresonance.com Wed Dec  5 18:30:46 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lB5NUkmI014715
	for ; Wed, 5 Dec 2007 18:30:46 -0500
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	lB5NUb07015623
	for ; Wed, 5 Dec 2007 18:30:37 -0500 (EST)
Received: from delta.rtfm.com (dhcp-11b6.ietf70.org [130.129.17.182])
	by mit.edu (Spam Firewall) with ESMTP id C9E1DC67B4C
	for ; Wed,  5 Dec 2007 18:30:36 -0500 (EST)
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1])
	by delta.rtfm.com (Postfix) with ESMTP id EC8AE33C61
	for ; Wed,  5 Dec 2007 15:25:16 -0800 (PST)
Date: Wed, 05 Dec 2007 15:25:16 -0800
From: Eric Rescorla 
To: saag@mit.edu
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20071205232516.EC8AE33C61@delta.rtfm.com>
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] TLS WG Report
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 05 Dec 2007 23:30:46 -0000

TLS WG Report
$Id: tls-saag.txt,v 1.1 2007/12/05 23:22:34 ekr Exp $

TLS WG met 9 AM Monday Dec 3. 

- TLS 1.2

TLS 1.2 is currently in WGLC. We went over the current LC comments,
most of which were editorial. One issue was semi-contentious:
what to do with IDEA, should it be SHOULD NOT or MUST NOT. This
will go to the list.


- Extension definitions

This document hasn't seen any significant changes. It turns out
there are significant IDN issues. Paul Hoffman agreed to take a
look. We discussed hash agility for the SHA-1 in the certificate
URL extension but didn't close on it.


- RSA-AES-SIV

Dan Harkins presented SIV, another AEAD algorithm that is slower
than, but more resilient to misuse, than GCM. There was no consenus
about whether to adopt this, so it was taken to the list.


- ECDHE_PSK Ciphersuites

Mohama d Badra presented this. We'll take it to the list.


- TLS using EAP Auth

Yaron Sheffer presented this. There was a fair amount of discussion,
some pro, some con. No progress can be made here until the issue of
the EAP applicability statement can be resolved, which is an AD issue.


- TLS Extractors

There was general enthusiasm for this. Some discussion of extractor
label registration policies. Consensus to take this as a WG item.
To confirm on the mailing list.

-Ekr








  
  
  




From kent@bbn.com Wed Dec  5 19:16:56 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lB60GuMp024559
	for ; Wed, 5 Dec 2007 19:16:56 -0500
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	lB60GjFh011614
	for ; Wed, 5 Dec 2007 19:16:45 -0500 (EST)
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80])
	by mit.edu (Spam Firewall) with ESMTP id 215F5C6BB15
	for ; Wed,  5 Dec 2007 19:15:53 -0500 (EST)
Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.65.93])
	by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from )
	id 1J04PA-00007y-56; Wed, 05 Dec 2007 19:15:52 -0500
Mime-Version: 1.0
Message-Id: 
Date: Wed, 5 Dec 2007 18:58:40 -0500
To: saag@mit.edu, ietf-pkix@imc.org
From: Stephen Kent 
Content-Type: multipart/alternative;
	boundary="============_-1015222342==_ma============"
X-Spam-Score: 1.20
X-Spam-Level: * (1.20)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] summary of PKIX session on 12.3.2007
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 06 Dec 2007 00:16:56 -0000

--============_-1015222342==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

PKIX WG Summary for IETF 70

Ongoing WG Activities

- SCVP was approved and is in AUTH 48 now.

- The CMC trio has been revised by Jim, and was approved by Tim on Wednesday.

- 3280bis is undergoing minor fixes in response to IETF last call 
with the intent that the fixes will be agreed to by the Wg by the 
time the IET last call is completed. The WG is now trying to finalize 
the requisite text.

- The EC algorithm info design team , lead by Tim Polk, presented a 
new proposal, which requires an update to RFC 4055 and 3279, but is 
in keeping with the spirit of 4055. The proposal would make 
PKIX-compliant representation of ECC algorithm info a compatible 
subset of what ANSI X9.62 proposed. The WG has been asked to agree to 
this proposed way forward, which will require two new documents (one 
very small).

- PHB proposed an optional extension to OCSP to facilitate agility 
for both hash and signature algorithms, thus removing some ambiguity 
I the current specs. The WG will be asked to consider this as a new 
work item, once Phil has posted an I-D describing his proposal.

Other Actions

- PKIX will respond to two liaison statements from ITU-T. The first 
statement deals with removing the upper bound from X.520 attributes 
used in DNs.  The PKIX position is "just say no (to unbounded strings 
in DNs)." He second statement deals with he real world situation of 
DN collisions in CA and EE Subject names in the global context. Here 
the PKIX position is that yes, this does happen and no, we are not 
going to try to fix the problem (e.g., by creating guidelines for CA 
name selection or by establishing a list of extant CA names).

- Paul Hoffman and Jim Schaad have developed an open source ASN.1 
compiler for the 1998/2002 versions of ASN.1. PKIX needs to determine 
if it wants to update its specs to use the newer syntax.

- PKIX was briefed on a proposal for a model for trust anchor 
management, and a companion management protocol. The WG will decide 
if it wishes to pursue this as a work item. A straw poll was 
initiated on Wednesday.

- PRPQ was briefed again by Max, and will be considered by the WG as 
a possible Experimental RFC work item. A straw poll was initiated on 
Wednesday.

--============_-1015222342==_ma============
Content-Type: text/html; charset="us-ascii"


summary of PKIX session on
12.3.2007

PKIX WG Summary for IETF 70




Ongoing WG Activities



- SCVP was approved and is in AUTH 48 now.



- The CMC trio has been revised by Jim, and was approved by Tim on
Wednesday.



- 3280bis is undergoing minor fixes in response to IETF last call with
the intent that the fixes will be agreed to by the Wg by the time the
IET last call is completed. The WG is now trying to finalize the
requisite text.



- The EC algorithm info design team , lead by Tim Polk, presented a
new proposal, which requires an update to RFC 4055 and 3279, but is in
keeping with the spirit of 4055. The proposal would make
PKIX-compliant representation of ECC algorithm info a compatible
subset of what ANSI X9.62 proposed. The WG has been asked to agree to
this proposed way forward, which will require two new documents (one
very small).



- PHB proposed an optional extension to OCSP to facilitate agility for
both hash and signature algorithms, thus removing some ambiguity I the
current specs. The WG will be asked to consider this as a new work
item, once Phil has posted an I-D describing his proposal.



Other Actions



- PKIX will respond to two liaison statements from ITU-T. The first
statement deals with removing the upper bound from X.520 attributes
used in DNs.  The PKIX position is "just say no (to unbounded
strings in DNs)." He second statement deals with he real world
situation of DN collisions in CA and EE Subject names in the global
context. Here the PKIX position is that yes, this does happen and no,
we are not going to try to fix the problem (e.g., by creating
guidelines for CA name selection or by establishing a list of extant
CA names).



- Paul Hoffman and Jim Schaad have developed an open source ASN.1
compiler for the 1998/2002 versions of ASN.1. PKIX needs to determine
if it wants to update its specs to use the newer syntax.



- PKIX was briefed on a proposal for a model for trust anchor
management, and a companion management protocol. The WG will decide if
it wishes to pursue this as a work item. A straw poll was initiated on
Wednesday.




- PRPQ was briefed again by Max, and will
be considered by the WG as a possible Experimental RFC work item. A
straw poll was initiated on Wednesday.





--============_-1015222342==_ma============--

From shanna@juniper.net Wed Dec  5 19:58:45 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lB60wjVT032149
	for ; Wed, 5 Dec 2007 19:58:45 -0500
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	lB60wYeF017681
	for ; Wed, 5 Dec 2007 19:58:34 -0500 (EST)
Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 2AB84C6870A
	for ; Wed,  5 Dec 2007 19:58:33 -0500 (EST)
Received: from source ([66.129.224.36]) by exprod7ob112.postini.com
	([64.18.6.12]) with SMTP; Wed, 05 Dec 2007 16:58:27 PST
Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp55.jnpr.net with
	Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 16:58:02 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Date: Wed, 5 Dec 2007 19:56:24 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: NEA WG Report
Thread-Index: Acg3otMNIxzLR+qwTV2w3gVWFBL5tQ==
From: "Stephen Hanna" 
To: 
X-OriginalArrivalTime: 06 Dec 2007 00:58:02.0571 (UTC)
	FILETIME=[0D7F69B0:01C837A3]
X-Spam-Score: 0.02
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id
	lB60wjVT032149
Subject: [saag] NEA WG Report
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 06 Dec 2007 00:58:45 -0000

The Network Endpoint Assessment (NEA) WG met Wednesday,
December 5, 2007 at 1 PM PST.

Just completed WGLC on draft-ietf-nea-requirements-05.txt.
One comment was received and it was positive. We reviewed
the document, including a review of recent changes and
all of the requirements. Questions were asked and answered
about the internationalization requirements (C-9 and C-10)
and a few other points. At the end of the discussion, there
was a hum on whether the document is ready for submission
to IESG, IETF Last Call, and eventual publication as an
Informational RFC. The hum was 100% in favor. Based on
this hum and on previous discussion on the mailing list,
the chairs declared that there is WG consensus for submitting
the document.

Draft milestones for the next year were discussed.
As required by our charter, the focus will be on
soliciting proposals for the PA and PB protocols,
selecting PA and PB protocol specs, refining the
specs, and getting WG and IETF consensus on them.
We hope to have the specs ready for IESG consideration
about January 2009. The draft milestones will be
discussed further on the email list and sent to
our AD for approval when they're ready.

Finally, we discussed the MNEA requirements document
(draft-wei-nea-mnea-00.txt). Everyone agreed that
this is cool stuff but should not be a NEA WG item
because it's still research and out of scope for us.


From leiba@watson.ibm.com Wed Dec  5 20:49:28 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lB61nSAh012478
	for ; Wed, 5 Dec 2007 20:49:28 -0500
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	lB61nHcS024829
	for ; Wed, 5 Dec 2007 20:49:17 -0500 (EST)
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 14178C6D219
	for ; Wed,  5 Dec 2007 20:49:06 -0500 (EST)
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id lB61n3tI012357
	for ; Wed, 5 Dec 2007 20:49:03 -0500
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215])
	by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id
	lB61n3JH115348 for ; Wed, 5 Dec 2007 20:49:03 -0500
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1])
	by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id
	lB61n36I005526 for ; Wed, 5 Dec 2007 20:49:03 -0500
Received: from poplar (poplar.watson.ibm.com [9.2.40.57])
	by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id
	lB61n2iT005523 for ; Wed, 5 Dec 2007 20:49:03 -0500
Received: from wecm-9-67-220-76.wecm.ibm.com ([9.67.220.76])
	by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw)
	with SMTP ID IMFd1196905742.4087; Wed, 05 Dec 2007 20:49:02 -0400
Date: Wed, 05 Dec 2007 20:49:20 -0500
From: Barry Leiba 
To: saag@mit.edu
Message-ID: <8083571C26108B1257F10E26@Uranus.local>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
X-Spam-Score: 0.01
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id
	lB61nSAh012478
Subject: [saag] DKIM working group summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 06 Dec 2007 01:49:28 -0000

The DKIM working group session was called to order at about 15:20 PST on Tuesday, 
4 December 2007, with 55 attendees.  Stephen Farrell presented the agenda, and 
covered document status: SSP Requirements is now RFC 5016, and there are three 
active working-group drafts, each of which will be presented later.

Tony Hansen and Murray Kucherawy presented the results of a DKIM interoperability 
workshop that was recently held in the Dallas area.  20 companies and 
organizations participated, and the interoperability results were generally very 
good.  A few minor issues were uncovered: edge conditions in the "relaxed" 
canonicalization algorithm, an ABNF error, and similar things.  We will submit 
errata to correct most of these issues, and add text to the "deployment" document 
for some others.

Jim Fenton presented a status update on the SSP draft, giving a review of recent 
changes and going over the open issues.  Jim used quotes from two "customers" 
early in his presentation, which prompted Dave Crocker to comment, and there was 
some significant discussion of the appropriateness of optimism in this regard, of 
some aspects of the SSP draft that Dave considers wrong, and of Dave's review of 
SSP, which he'd posted to the DKIM and Apps-Review mailing lists earlier that 
day.  Further discussion of the review has been taken to the DKIM list (and that 
discussion has already been quite active).

On the open issues: there was some discussion here and there, but a lot of 
discussion on one issue in particular: #1399: Clarify i= vs. SSP, “...need to 
provide the exact semantics in SSP of how a receiver determines whether a DKIM 
signature satisfies the SSP criteria or not.† The result of the discussion is 
that the chairs think we need one more round, no more than a week, of discussion 
on the mailing list before we determine a closure for this issue.

We plan to start working-group last call after issue 1399 is closed and after 
discussion has finished on Dave Crocker's comments.

Doug Otis presented a (non-WG) draft, "DKIM Third-Party Authorization for Sender 
Signer Practices".

Murray Kucherawy presented (non-WG) drafts dealing with passing authentication 
results down the line (including all the way to the MUA).  There was brief 
discussion about his draft for using an ESMTP extension to pass the information, 
in order to reduce attacks against MUAs behind non-compliant MTAs.

Tony Hansen presented a very drief status report (and call for reviews) on the 
Overview document and the new spin-off, Deployment and Operations.

The session was adjourned at about 17:20.

-- Barry Leiba, DKIM working group co-chair



From Shawn.Emery@Sun.COM Thu Dec  6 00:04:42 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lB654gwx017259
	for ; Thu, 6 Dec 2007 00:04:42 -0500
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	lB654VJv025572
	for ; Thu, 6 Dec 2007 00:04:31 -0500 (EST)
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by mit.edu (Spam Firewall) with ESMTP id 3DB86BF955F
	for ; Thu,  6 Dec 2007 00:04:08 -0500 (EST)
Received: from fe-amer-09.sun.com ([192.18.109.79])
	by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	lB6548ei007819 for ; Thu, 6 Dec 2007 05:04:08 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
	(Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
	id <0JSM00G013BCM600@mail-amer.sun.com>
	(original mail from Shawn.Emery@Sun.COM) for saag@mit.edu; Wed,
	05 Dec 2007 22:04:08 -0700 (MST)
Received: from shawn-emerys-computer.local ([129.150.33.139])
	by mail-amer.sun.com
	(Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
	with ESMTPSA id <0JSM002YX3EOZKE0@mail-amer.sun.com> for saag@mit.edu;
	Wed, 05 Dec 2007 22:04:08 -0700 (MST)
Date: Wed, 05 Dec 2007 22:03:25 -0700
From: "Shawn M. Emery" 
Sender: Shawn.Emery@Sun.COM
To: saag@mit.edu
Message-id: <4757829D.4090906@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
X-Spam-Score: 3.501
X-Spam-Level: *** (3.501)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
X-Mailman-Approved-At: Thu, 06 Dec 2007 13:44:58 -0500
Subject: [saag] IETF 70 Kitten Working Group Summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 06 Dec 2007 05:04:42 -0000


The kitten-wg met Tuesday, 12/4/07, during the first afternoon session.

Co-chairs: Alexey Melnikov and Shawn Emery

The goals of the meeting were to go over the active working items and 
Milestones.

A majority of the discussion of the session was on the two drafts that 
are currently in IESG:
draft-ietf-kitten-gssapi-domain-based-names
draft-ietf-kitten-gssapi-krb5-domain-based-names

04 of draft-ietf-kitten-gssapi-domain-based-names had taken care of some 
of the DISCUSS issues in regards to I18N comments, but still has some 
outstanding issues that will be fixed:

1) include ABNF for service slot in IANA-registry draft that 
domain-based would reference
2) include ABNF in domain-based draft for host and domain slots
3) change the example names and clean up references

We decided to drop the pseudo-mech draft back at the last IETF. We will 
drop this and will add the IANA-registry draft to the Milestones.  We 
will submit this change and drop the C# bindings work item for the 
Charter update.

The naming extensions draft was also discussed and needs work in regards 
to breaking up Kerberos and PKIX sections into separate documents and to 
keep the core document with C-bindings.

Updates were made to the Java bindings bis draft which now includes an 
appendix with the differences from the RFC.

Shawn.
--

From tlyu@MIT.EDU Thu Dec  6 14:24:52 2007
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU
	[18.7.7.80])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lB6JOqcr009893
	for ; Thu, 6 Dec 2007 14:24:52 -0500
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])
	by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	lB6JOqXN017577
	for ; Thu, 6 Dec 2007 14:24:52 -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.6/8.12.4) with ESMTP id lB6JOpJ1004704
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
	for ; Thu, 6 Dec 2007 14:24:51 -0500 (EST)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308)
	id lB6JOpHQ029553; Thu, 6 Dec 2007 14:24:51 -0500 (EST)
To: saag@MIT.EDU
From: Tom Yu 
Date: Thu, 06 Dec 2007 14:24:51 -0500
Message-ID: 
Lines: 73
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
X-Spam-Flag: NO
X-Spam-Score: 0.00
Subject: [saag] IETF70 SASL summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 06 Dec 2007 19:24:53 -0000

Simple Authentication And Security Layer (SASL)
IETF70, Vancouver, BC, Canada

Wednesday, December 5, 2007, at 1300-1500
=========================================

Chairs:

Tom Yu 
Kurt Zeilenga 

SUMMARY
=======

Thanks to Jeff Hutzelman for scribing.

Document Status:

draft-ietf-sasl-crammd5-09	- needs writeup
draft-ietf-sasl-gs2-09		- needs publication request
draft-ietf-sasl-rfc2831bis-12	- (to Historic)
draft-josefsson-password-auth-00 - expired
draft-cridland-sasl-hexa-00	- merged with SCRAM
draft-newman-auth-scram-05	- new rev. submitted, not yet in repos.
draft-zeilenga-sasl-yap-02	- individual submission

Due to the chairs' errors, CRAM is still missing WGLC writeup.  Kurt
will follow up.  Sam did AD review on GS2; he has some issues
regarding detection of channel binding failure.  YAP will proceed as
an invivdual submission; Sam will ask the WG about conflicts when the
RFC Editor makes pre-publication contact with the IESG about YAP.
Simon Josefsson has indicated he is not interested in purusing his
password-based mech draft at this time; some of the text describing
how to produce a GS2-compatible wire encoding will be copied into
SCRAM.

Abhijit Menon-Sen submitted a new revision of SCRAM which includes
some material from Dave Cridland.  This revision has not yet reached
the repository.  Alexey Melnikov relays some questions from Abhijit
about protecting secret channel binding data.  Some further discussion
about channel bindings.  Answer for Abhijit: "Do what GS2 does".

Alexey will produce text about how to make SCRAM into a GS2 mechanism
(probably based on text from Simon's expired draft); Nico Williams and
Chris Newman will review.  Nico is also willing write about how to
turn SCRAM into a full GSS-API mechanism.

We will slip milestones about 4 months for most items (due to
holidays, not 3 months).  Can WGLC on "digest-to-historic"
immediately.

Open Microphone:

Mark Crispin has concerns with how certain IMAP implementations handle
SASL vs legacy non-SASL auth; issue is larger than SASL and might be
more appropriate for an IMAP spec. revision.

Milestones:

Done	initial I-D for DIGEST-MD5 to Historic
Done	WGLC I-D for DIGEST-MD5 to Historic
Feb 08	initial impl. report questionnaire
Feb 08	initial RFC4422bis
Feb 08	initial I-D for DIGEST-MD5 successor
Feb 08	DIGEST-MD5 to Historic I-D to IESG
Mar 08	send impl. report questionnaire
Apr 08	compile impl. questionnaire responses
Jun 08	WGLC RFC4422bis
Jun 08	WGLC DIGEST-MD5 successor
Jul 08	discuss impl. questionnaire responses
Aug 08	final impl. report
Aug 08	RFC4422bis to IESG
Aug 08	DIGEST-MD5 successor to IESG

From jsalowey@cisco.com Thu Dec  6 14:40:57 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lB6JevXU014354
	for ; Thu, 6 Dec 2007 14:40:57 -0500
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	lB6JelZU019289
	for ; Thu, 6 Dec 2007 14:40:47 -0500 (EST)
Received: from sj-iport-6.cisco.com (unknown [171.71.176.117])
	by mit.edu (Spam Firewall) with ESMTP id BC1ABAD7120
	for ; Thu,  6 Dec 2007 12:22:39 -0500 (EST)
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-6.cisco.com with ESMTP; 06 Dec 2007 09:22:13 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lB6HMDkg006383
	for ; Thu, 6 Dec 2007 09:22:13 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lB6HMB1f011239
	for ; Thu, 6 Dec 2007 17:22:13 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 6 Dec 2007 09:22:11 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Thu, 6 Dec 2007 09:22:35 -0800
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: EMU working group summary
Thread-Index: Acg4LJeYZCIKxKw8S/e9RPGrnIVPjg==
From: "Joseph Salowey (jsalowey)" 
To: 
X-OriginalArrivalTime: 06 Dec 2007 17:22:11.0780 (UTC)
	FILETIME=[8991A840:01C8382C]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=529; t=1196961733;
	x=1197825733; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jsalowey@cisco.com;
	z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20
	|Subject:=20EMU=20working=20group=20summary |Sender:=20;
	bh=yKFb4FjBdzqo6Tvu09noAr0C8xY9jkrGGDsDAKMj2pI=;
	b=B/t3v9QiewoSCYEOKUE1qyGD7+URm2J3VEZmklzy5wmtEHyvL2FS4Y2xeF36S8m67NLv25MD
	BuQUTh1QHL+LFoeuyHzfUmF6hy+z44Qo2wvP7oXJCyIcJKzzwg+gqwXj;
Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim4002 verified; ); 
X-Spam-Score: 0.02
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id
	lB6JevXU014354
Subject: [saag] EMU working group summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 06 Dec 2007 19:40:57 -0000

The EMU (EAP Method Update) working group met on Tuesday morning.
RFC2716bis (EAP-TLS) has started IETF Last Call.  EAP-GPSK (Generalized
Pre-Shared Key) has completed working group review and will be sent to
the IESG shortly.  In the meeting we discussed a charter revision to add
a work item to deliver a standards track EAP Tunnel method based on TLS
that supports passwords and other authentication mechanisms.  Discussion
of the charter and of the requirements for a tunnel method will continue
on the EMU list.  



From clancy@ltsnet.net Thu Dec  6 16:00:34 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lB6L0Y9T009287
	for ; Thu, 6 Dec 2007 16:00:34 -0500
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	lB6L0NEK014138
	for ; Thu, 6 Dec 2007 16:00:23 -0500 (EST)
Received: from bacon.cs.umd.edu (server-nat-4.cs.umd.edu [128.8.127.147])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 0464AC83041
	for ; Thu,  6 Dec 2007 16:00:21 -0500 (EST)
Received: from [127.0.0.1] (dhcp-15e1.ietf70.org [130.129.21.225])
	(authenticated bits=0)
	by bacon.cs.umd.edu (8.13.1/8.12.5) with ESMTP id lB6L0G3q005882
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Thu, 6 Dec 2007 16:00:18 -0500
Message-ID: <475862DA.5020109@ltsnet.net>
Date: Thu, 06 Dec 2007 16:00:10 -0500
From: Charles Clancy 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: saag@mit.edu
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more
	information
X-CSD-MailScanner: Found to be clean
X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached,
	score=-4.399, required 5, autolearn=not spam, ALL_TRUSTED -1.80,
	AWL 0.00, BAYES_00 -2.60)
X-CSD-MailScanner-From: clancy@ltsnet.net
X-Spam-Status: No
X-Spam-Score: 0.60
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] HOKEY WG summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 06 Dec 2007 21:00:34 -0000

Since IETF 69, the re-authentication problem statement and 
re-authentication protocol (ERP) have been completed advanced to the 
IESG.  The EMSK keying hierarchy and pre-authentication problem 
statement are both close to completion, and will hopefully complete WGLC 
in the coming months.  The HOKEY back-end key delivery protocol remains 
as our major work item.

At IETF 70, most discussion revolved around AAA keying issues related to 
HOKEY.  A variety of existing documents apply to how HOKEY distributes 
keys, most notably RFC 4962.  During the HOKEY meeting, Russ Housley 
gave a personal interpretation of RFC 4962 and its applicability to 
HOKEY and possible use of AAA proxies.  The WG intends to revise their 
documents to support hop-by-hop security but not prevent use of 
end-to-end security relationships.

-- 
Charles Clancy  <>  eng.umd.edu/~tcc

From gregory.ietf@gmail.com Thu Dec  6 17:56:26 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lB6MuOcc025422
	for ; Thu, 6 Dec 2007 17:56:24 -0500
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	lB6MuEP7015707
	for ; Thu, 6 Dec 2007 17:56:15 -0500 (EST)
Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.190])
	by mit.edu (Spam Firewall) with ESMTP id 1AC4EAC4D37
	for ; Thu,  6 Dec 2007 16:50:21 -0500 (EST)
Received: by rv-out-0910.google.com with SMTP id k15so390153rvb
	for ; Thu, 06 Dec 2007 13:50:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:received:received:x-mailer:date:to:from:subject:mime-version:content-type:message-id;
	bh=gGsZgvnDDabhV9W6CSfpviApTTdy3vcRr69Spe5ObUY=;
	b=JdbiBBnfDESOJ0DFXhal5vsdi+g8wQKO6xihqYHsg0d435uSIwd68jppzqDNa7lcLhzlaIjpt+mnbsGOFmoLOGB06d7BaddjAyXNTc7jytCPHXzBBmgvgLkzGqLlNQZ2WtwprqZ0N+eS2P0vn4/Yph0PE6R4hYh9ifi49Lm/DFU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=x-mailer:date:to:from:subject:mime-version:content-type:message-id;
	b=UK/r1Pi0J1PY+zyLDrYPFdHjjBUhuNdTAZ31++4ddWVo0KIBwFGNqQS030IEax8fN9B+1I94GwBf6IkXMbTlV9QAOx9pRPO2Z96lyL5BJdnRWEbAX6Cj0KfmQb09e04+XwJ8hnKMjOo6qkxVjE2TKrkKCxSEmJXZ7WKjBIrj3nE=
Received: by 10.140.142.6 with SMTP id p6mr2282804rvd.1196977821639;
	Thu, 06 Dec 2007 13:50:21 -0800 (PST)
Received: from Gregory-T60.gmail.com ( [66.129.225.151])
	by mx.google.com with ESMTPS id k14sm100656rvb.2007.12.06.13.50.18
	(version=SSLv3 cipher=OTHER); Thu, 06 Dec 2007 13:50:20 -0800 (PST)
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 06 Dec 2007 13:50:15 -0800
To: saag@mit.edu
From: "Gregory M. Lebovitz" 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <47586e9c.0e578c0a.0845.2fb3@mx.google.com>
X-Spam-Score: 0.01
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] Automated Keying for Routing Protocols (AKRaP?)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 06 Dec 2007 22:56:27 -0000

It seems to be getting pretty clear that we need some dedicated focus 
on keying mechanisms for routing protocols. There is significant work 
going on for both OSPF and BGP.

I'm simply agreeing here, on list, that Security Area should take up 
both these efforts in some form.

I'm also affirming that the vendors, well, at least my employer, is 
interested in implementing the outcomes, and in fact has already 
implemented a few different mechanisms in these areas.

Thinking operations: though I'd like to keep like things together, it 
is not clear to me that we could do both OSPF and BGP at the same 
time efficiently in one working group. Maybe we should do one BoF and 
then create two focused WG's, one for each of the very different OSPF 
and BGP protocols.

Gregory.

+++++++++++++++++++++++
IETF-related email from
Gregory M. Lebovitz
Juniper Networks
g r e go r  y d o t  i e tf a t  g m a i l  do t c o  m 


From Jeff.Hodges@neustar.biz Tue Dec 18 15:14:32 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBIKEWPS006715
	for ; Tue, 18 Dec 2007 15:14:32 -0500
Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBIKEJrU025596
	for ; Tue, 18 Dec 2007 15:14:20 -0500 (EST)
Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 88CF2640C5D
	for ; Tue, 18 Dec 2007 15:14:18 -0500 (EST)
Received: from [156.154.5.164] (unknown [156.154.5.164])
	by ns3.neustar.com (Postfix) with ESMTP id 52018175BD;
	Tue, 18 Dec 2007 20:14:16 +0000 (GMT)
Message-ID: <47682A17.1040609@neustar.biz>
Date: Tue, 18 Dec 2007 12:14:15 -0800
From: =JeffH 
User-Agent: Thunderbird 1.5.0.14pre (X11/20071023)
MIME-Version: 1.0
To: IETF Security Area Advisory Group ,
	IETF HTTP Auth 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.12
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] [security-services] fyi: Technical Comparison: OpenID and
 SAML (Draft 05)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 18 Dec 2007 20:14:32 -0000

Of possible interest...


blogpost: (Draft) Technical Comparison: OpenID and SAML



document: Technical Comparison: OpenID and SAML - Draft 05
http://identitymeme.org/doc/draft-hodges-saml-openid-compare-05.html

Abstract

This document presents a technical comparison of the OpenID Authentication
protocol and the Security Assertion Markup Language (SAML) Web Browser SSO
Profile and the SAML framework itself. Topics addressed include design centers,
terminology, specification set contents and scope, user identifier treatment,
web single sign-on profiles, trust, security, identity provider discovery
mechanisms, key agreement approaches, as well as message formats and protocol
bindings. An executive summary targeting various audiences, and presented from
the perspectives of end-users, implementors, tna deployers, is provided. We do
not attempt to assign relative value between OpenID and SAML, e.g. which is
"better"; rather, it attempts to present an objective technical comparison.


=JeffH




From bew@cisco.com Tue Dec 18 19:23:56 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBJ0Nuec001803
	for ; Tue, 18 Dec 2007 19:23:56 -0500
Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBJ0NkCK028809
	for ; Tue, 18 Dec 2007 19:23:46 -0500 (EST)
Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71])
	by mit.edu (Spam Firewall) with ESMTP id 0DD9B66FF7C
	for ; Tue, 18 Dec 2007 19:23:44 -0500 (EST)
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-2.cisco.com with ESMTP; 18 Dec 2007 16:23:44 -0800
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBJ0NhOO029774
	for ; Tue, 18 Dec 2007 16:23:43 -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 lBJ0NO4b028793
	for ; Wed, 19 Dec 2007 00:23:43 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 18 Dec 2007 16:23:41 -0800
Received: from [10.253.144.125] ([10.21.147.209]) by
	xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 18 Dec 2007 16:23:40 -0800
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <98FA6BE8-0825-41F6-8DAA-1A5706D974A9@cisco.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: saag@mit.edu
From: Brian Weis 
Date: Tue, 18 Dec 2007 16:23:51 -0800
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 19 Dec 2007 00:23:40.0918 (UTC)
	FILETIME=[6806E160:01C841D5]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=830; t=1198023824; x=1198887824;
	c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=bew@cisco.com;
	z=From:=20Brian=20Weis=20
	|Subject:=20TCP-AO=20MAC=20algorithms |Sender:=20;
	bh=Xwhz/4zdUSli0tCxBB/G+vOnAGFLz+aa/jGSgN7Z/4o=;
	b=F9D4jPBord49JoLDy75BNEK8ttkLWxixWCFPIy/mAswwSTZZ6Nwr1d5RA6
	awEzaNUnFrQ9A5R5kbkVVeBeGnQUMzZbq9pMbRirTjjVFxutLG+GY6eDNV0H
	1KJ2Galdcy;
Authentication-Results: sj-dkim-2; header.From=bew@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: 0.01
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] TCP-AO MAC algorithms
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 19 Dec 2007 00:23:57 -0000

Greetings,

The TCPM WG seeks advice from SAAG on which MACs to include as  
required MACs for the TCP Authentication Option (draft-ietf-tcpm-tcp- 
auth-opt-00). Two MACs with differing internal constructions are  
desired.

In my opinion, it is also important that MACs defined by an Internet  
standard as required to be implemented be based on NIST-approved  
algorithms and modes, and also be generally available in both  
software and cryptographic hardware.

The following two MACs are reasonable recommendations that taken  
together easily meet the above criteria: HMAC-SHA-1 and AES-CMAC. I  
propose that these be the algorithms provided to the TCPM WG.

Brian

-- 
Brian Weis
Advanced Security Development, Security Technology Group, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com

From touch@ISI.EDU Tue Dec 18 23:24:47 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBJ4OlHx025586
	for ; Tue, 18 Dec 2007 23:24:47 -0500
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBJ4Odo5016266
	for ; Tue, 18 Dec 2007 23:24:40 -0500 (EST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id AE867C94889
	for ; Tue, 18 Dec 2007 23:24:16 -0500 (EST)
Received: from [192.168.1.44] (pool-71-106-88-149.lsanca.dsl-w.verizon.net
	[71.106.88.149])
	by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lBJ4O590027199;
	Tue, 18 Dec 2007 20:24:06 -0800 (PST)
Message-ID: <47689CE3.3020804@isi.edu>
Date: Tue, 18 Dec 2007 20:24:03 -0800
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: saag@mit.edu
References: <98FA6BE8-0825-41F6-8DAA-1A5706D974A9@cisco.com>
In-Reply-To: <98FA6BE8-0825-41F6-8DAA-1A5706D974A9@cisco.com>
X-Enigmail-Version: 0.95.5
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enigDB947D35A3C978B412F5C88C"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 3.5
X-Spam-Level: *** (3.5)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: Re: [saag] TCP-AO MAC algorithms
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 19 Dec 2007 04:24:47 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigDB947D35A3C978B412F5C88C
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

As a followup, draft-ietf-tcpm-tcp-auth-opt-00 also needs to define a
default MAC length, and seeks advice from SAAG on this as well. We
presumed that the default MAC length would apply to either (i.e., both)
mandatory-to-implement (i.e., required) MAC algorithms as a default.

Joe

Brian Weis wrote:
> Greetings,
>=20
> The TCPM WG seeks advice from SAAG on which MACs to include as =20
> required MACs for the TCP Authentication Option (draft-ietf-tcpm-tcp-=20
> auth-opt-00). Two MACs with differing internal constructions are =20
> desired.
>=20
> In my opinion, it is also important that MACs defined by an Internet =20
> standard as required to be implemented be based on NIST-approved =20
> algorithms and modes, and also be generally available in both =20
> software and cryptographic hardware.
>=20
> The following two MACs are reasonable recommendations that taken =20
> together easily meet the above criteria: HMAC-SHA-1 and AES-CMAC. I =20
> propose that these be the algorithms provided to the TCPM WG.
>=20
> Brian
>=20


--------------enigDB947D35A3C978B412F5C88C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHaJzjE5f5cImnZrsRAlNjAKCimpmpU/+SyKXS3ImsT2NygbIF/wCg9jnN
aPj7gQQYWnE9jYERSlVMFPs=
=h+kI
-----END PGP SIGNATURE-----

--------------enigDB947D35A3C978B412F5C88C--

From kent@bbn.com Wed Dec 19 08:51:56 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBJDpuaC012390
	for ; Wed, 19 Dec 2007 08:51:56 -0500
Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBJDpkcu026757
	for ; Wed, 19 Dec 2007 08:51:46 -0500 (EST)
Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81])
	by mit.edu (Spam Firewall) with ESMTP id 53FA167844B
	for ; Wed, 19 Dec 2007 08:51:44 -0500 (EST)
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.0.102])
	by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from )
	id 1J4zKo-0004lS-6C; Wed, 19 Dec 2007 08:51:43 -0500
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <47689CE3.3020804@isi.edu>
References: <98FA6BE8-0825-41F6-8DAA-1A5706D974A9@cisco.com>
	<47689CE3.3020804@isi.edu>
Date: Wed, 19 Dec 2007 08:51:47 -0500
To: Joe Touch 
From: Stephen Kent 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] TCP-AO MAC algorithms
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 19 Dec 2007 13:51:56 -0000

At 8:24 PM -0800 12/18/07, Joe Touch wrote:
>Content-Type: multipart/signed; micalg=pgp-sha1;
>	protocol="application/pgp-signature";
>	boundary="------------enigDB947D35A3C978B412F5C88C"
>
>As a followup, draft-ietf-tcpm-tcp-auth-opt-00 also needs to define a
>default MAC length, and seeks advice from SAAG on this as well. We
>presumed that the default MAC length would apply to either (i.e., both)
>mandatory-to-implement (i.e., required) MAC algorithms as a default.
>
>Joe
>

Joe,

Until there is a clear statement of the scope for TCP-AO, I don't 
think we can have a meaningful discussion of the default MAC length. 
For example, if the scope is security only for inter-router 
communication, there may be operational arguments that motivate a 
smaller MAC size than if the scope is any form of TCP communication 
between a pair of hosts.

I made an analogous point during the SAAG meeting, but let me repeat 
it here: Until there is a clear statement of the scope for TCP-AO, 
the work on the protocol cannot be consider complete.  The rationale 
is that some details of the protocol depend on assumptions of how key 
management will be performed, and those assumptions, in turn, depend 
on the scope for TCP-AO.

	- For example, we have been told that key rollover for a TCP 
session carrying BGP traffic between two routers MUST NOT cause the 
connection to drop.
We also have been told that TCP connections between routers may 
remain stable for very long time intervals, long enough for TCP 
sequence numbers to cycle. Normal security practice would say that we 
should change keys before TCP sequence numbers cycle, IF we rely on 
these numbers to provide anti-replay protection. SO, there is an 
engineering tradeoff to be addressed in this context, one that might 
not be a big deal in more generic TCP contexts.

	- This issue is further complicated by the fact that some of 
the ways one might address the key rollover problem are dependent on 
the larger key management capabilities that are available. We have 
been told that there are a lot of operational constraints that key 
management must meet if it is to be viable in this BGP context. But, 
until those constraints are articulated and agreed upon, with input 
from the ISP operations community, we will not know what options are 
available to us.

This sort of analysis is what leads me to say that we need to agree 
upon the scope for this TCP security option, and have an agreed upon 
key management model, before we can be confident that the option 
design is complete, and we can choose values like the default MAC 
size. I realize that folks who want to commit to silicon want to move 
ahead quickly, but ...


Steve

From touch@ISI.EDU Wed Dec 19 10:16:07 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBJFG7Ff009804
	for ; Wed, 19 Dec 2007 10:16:07 -0500
Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBJFFvRs013585
	for ; Wed, 19 Dec 2007 10:15:57 -0500 (EST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 77A5E67EA00
	for ; Wed, 19 Dec 2007 10:11:30 -0500 (EST)
Received: from [192.168.1.44] (pool-71-106-88-149.lsanca.dsl-w.verizon.net
	[71.106.88.149])
	by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lBJF8Eaq004430;
	Wed, 19 Dec 2007 07:08:15 -0800 (PST)
Message-ID: <476933DC.6010701@isi.edu>
Date: Wed, 19 Dec 2007 07:08:12 -0800
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Stephen Kent 
References: <98FA6BE8-0825-41F6-8DAA-1A5706D974A9@cisco.com>
	<47689CE3.3020804@isi.edu> 
In-Reply-To: 
X-Enigmail-Version: 0.95.5
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig20A75EFEC1C250A7922BBF9A"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] TCP-AO MAC algorithms
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 19 Dec 2007 15:16:07 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig20A75EFEC1C250A7922BBF9A
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Stephen Kent wrote:
> At 8:24 PM -0800 12/18/07, Joe Touch wrote:
>> Content-Type: multipart/signed; micalg=3Dpgp-sha1;
>>     protocol=3D"application/pgp-signature";
>>     boundary=3D"------------enigDB947D35A3C978B412F5C88C"
>>
>> As a followup, draft-ietf-tcpm-tcp-auth-opt-00 also needs to define a
>> default MAC length, and seeks advice from SAAG on this as well. We
>> presumed that the default MAC length would apply to either (i.e., both=
)
>> mandatory-to-implement (i.e., required) MAC algorithms as a default.
>>
>> Joe
>>
>=20
> Joe,
>=20
> Until there is a clear statement of the scope for TCP-AO, I don't think=

> we can have a meaningful discussion of the default MAC length.=20

The TCP-AO document has such a statement of scope, summarized in the
abstract:

--
This document specifies a TCP Authentication Option (TCP-AO) which is
intended to replace the TCP MD5 Signature option of RFC-2385 (TCP MD5).
=2E.. The result is intended to be a simple modification to support
current infrastructure uses of TCP MD5, such as to protect BGP and LDP,
and to support a larger set of MACs with minimal other system and
operational changes. ...
--

This is further discussed in the intro:

--
   This document is not intended to replace the use of the IPsec suite
   (IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In
   fact, we recommend the use of IPsec and IKE, especially where IKE's
   level of existing support for parameter negotiation, session key
   negotiation, or rekeying are desired. TCP-AO is intended for use only
   where the IPsec suite would not be feasible, e.g., as has been
   suggested is the case for some routing protocols, or in cases where
   keys need to be tightly coordinated with individual transport
   sessions [Be07].
--

Is there some reason this is not sufficient as a declaration of scope?

A more specific statement would be:

	MUST be useful for BGP
	further limitations MUST be indicated
		the TCP-AO spec has no such limitations,
		i.e., it is intended to be acceptable
		for use on any TCP connection

It's fair to say we're 'optimizing' for BGP, though.

=2E..
>     - For example, we have been told that key rollover for a TCP sessio=
n
> carrying BGP traffic between two routers MUST NOT cause the connection
> to drop.
> We also have been told that TCP connections between routers may remain
> stable for very long time intervals, long enough for TCP sequence
> numbers to cycle. Normal security practice would say that we should
> change keys before TCP sequence numbers cycle, IF we rely on these
> numbers to provide anti-replay protection. SO, there is an engineering
> tradeoff to be addressed in this context, one that might not be a big
> deal in more generic TCP contexts.

Right - thus we're definitely making sure it's useful for BGP, as noted
in the abstract. We can certainly reiterate that in the intro.

>     - This issue is further complicated by the fact that some of the
> ways one might address the key rollover problem are dependent on the
> larger key management capabilities that are available. We have been tol=
d
> that there are a lot of operational constraints that key management mus=
t
> meet if it is to be viable in this BGP context. But, until those
> constraints are articulated and agreed upon, with input from the ISP
> operations community, we will not know what options are available to us=
=2E

That is input from the BGP community to SAAG, not from TCPM. Although
the members overlap, TCPM is not issuing those requirements AFAICT.

Joe


--------------enig20A75EFEC1C250A7922BBF9A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHaTPcE5f5cImnZrsRAk4AAKCarxNj006Rlala2Gp1Nk1b5+1j8QCfdDFt
TNyNYBTuBmcj+fNFUlUwF5s=
=IAXk
-----END PGP SIGNATURE-----

--------------enig20A75EFEC1C250A7922BBF9A--

From rja@extremenetworks.com Wed Dec 19 10:36:30 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBJFaUJL019753
	for ; Wed, 19 Dec 2007 10:36:30 -0500
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBJFaK7e000361
	for ; Wed, 19 Dec 2007 10:36:20 -0500 (EST)
Received: from eastrmmtao103.cox.net (eastrmmtao103.cox.net [68.230.240.9])
	by mit.edu (Spam Firewall) with ESMTP id D3371B502FF
	for ; Wed, 19 Dec 2007 10:10:13 -0500 (EST)
Received: from eastrmimpo03.cox.net ([68.1.16.126]) by eastrmmtao103.cox.net
	(InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id
	<20071219151012.FBBX24467.eastrmmtao103.cox.net@eastrmimpo03.cox.net>
	for ; Wed, 19 Dec 2007 10:10:12 -0500
Received: from [10.30.20.71] ([68.10.115.26])
	by eastrmimpo03.cox.net with bizsmtp
	id Sf1R1Y00F0aEP1Q0000000; Wed, 19 Dec 2007 10:01:26 -0500
Message-Id: <736D9406-8066-4743-8E6F-3A0EE18765F6@extremenetworks.com>
From: RJ Atkinson 
To: IETF Security Area WG 
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Date: Wed, 19 Dec 2007 10:10:12 -0500
X-Mailer: Apple Mail (2.915)
X-Spam-Score: 0.01
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] TCP Authentication & BGP protection goals
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 19 Dec 2007 15:36:30 -0000

All,

Let me suggest that protection against replay attacks
is not properly a goal for use of TCP Authentication
in the context of BGP protection.

Proposals to design perfect security for IETF protocols
have nearly always resulted in specifications that were
difficult to implement and to deploy (and nearly always
ended up not being deployed, for example PEM historically
and SEND at present).

The goal for TCP Authentication in the context of BGP
ought simply be to gain "significant risk reduction
that is widely implemented and widely deployed,
without seeking perfect security".

The existing "seen in the deployed Internet" attacks
are of the "TCP Session Stealing" variety.  A simple
replay attack won't permit TCP Session Stealing, which
is most or all of the current observed-in-the-wild threat.

Now, if some folks want to work on more perfect forms
of security for BGP, there is a quite separate existing
IETF WG that covers that topic and such efforts at perfection
should be focused there (and not try to entangle or delay
TCP Authentication).

However, we ought not delay the progress of TCP Authentication
for BGP any further.   While some might have that delay as a
personal objective, the overall good of the Internet is harmed
by any further delay with the TCP Authentication enhancements.

Separate from the above, I support Brian Weis' proposal
to start with algorithms and modes that are acceptable to NIST
under FIPS-140 rules.  Aside from the USG, many international
banks and financial institutions are asking implementers to
support FIPS-140-qualified algorithms/modes -- and even to
take their networking products through a FIPS-140 evaluation.
(The driver for this is reportedly the insurance industry,
who see FIPS-140 as a public measure that the cryptographic
module is reasonable correctly implemented -- hence lower risk).
There are also a wide range of other countries (notably not
including France) who have accepted NIST's FIPS-140 processes
and specifications as acceptable to them.

Yours,

Ran
rja@extremenetworks.com

Disclaimer: Speaking for myself, not my employer.  I am never
authorised to speak for my employer.  I don't know whether my
employer has, hasn't, or plans to implement any of the above,
since I'm on the research side rather than the product side
of the firm.






From kent@bbn.com Wed Dec 19 13:16:35 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBJIGZwN015308
	for ; Wed, 19 Dec 2007 13:16:35 -0500
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBJID0kO023575
	for ; Wed, 19 Dec 2007 13:13:00 -0500 (EST)
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80])
	by mit.edu (Spam Firewall) with ESMTP id AA047C72B4C
	for ; Wed, 19 Dec 2007 13:12:35 -0500 (EST)
Received: from dhcp89-089-071.bbn.com ([128.89.89.71])
	by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from )
	id 1J53PH-0004T1-3p; Wed, 19 Dec 2007 13:12:35 -0500
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <476933DC.6010701@isi.edu>
References: <98FA6BE8-0825-41F6-8DAA-1A5706D974A9@cisco.com>
	<47689CE3.3020804@isi.edu> 
	<476933DC.6010701@isi.edu>
Date: Wed, 19 Dec 2007 12:45:48 -0500
To: Joe Touch 
From: Stephen Kent 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] TCP-AO MAC algorithms
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 19 Dec 2007 18:16:35 -0000

At 7:08 AM -0800 12/19/07, Joe Touch wrote:
>...
>
>The TCP-AO document has such a statement of scope, summarized in the
>abstract:
>
>--
>This document specifies a TCP Authentication Option (TCP-AO) which is
>intended to replace the TCP MD5 Signature option of RFC-2385 (TCP MD5).
>... The result is intended to be a simple modification to support
>current infrastructure uses of TCP MD5, such as to protect BGP and LDP,
>and to support a larger set of MACs with minimal other system and
>operational changes. ...

Good. I did not recall that scope declaration in the briefing you and 
Sandy provided at SAAG.

>--
>
>This is further discussed in the intro:
>
>--
>    This document is not intended to replace the use of the IPsec suite
>    (IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In
>    fact, we recommend the use of IPsec and IKE, especially where IKE's
>    level of existing support for parameter negotiation, session key
>    negotiation, or rekeying are desired. TCP-AO is intended for use only
>    where the IPsec suite would not be feasible, e.g., as has been
>    suggested is the case for some routing protocols, or in cases where
>    keys need to be tightly coordinated with individual transport
>    sessions [Be07].

great.

>--
>
>Is there some reason this is not sufficient as a declaration of scope?

no, but it was not briefed, and the document is an I-D in TCPM, not 
any security area WG, so I had not read it.

>
>A more specific statement would be:
>
>	MUST be useful for BGP
>	further limitations MUST be indicated
>		the TCP-AO spec has no such limitations,
>		i.e., it is intended to be acceptable
>		for use on any TCP connection
>
>It's fair to say we're 'optimizing' for BGP, though.

That text is counter productive, i.e., it expands the scope and makes 
it vague, rather than being limited and crisp.

>
>...
>>      - For example, we have been told that key rollover for a TCP session
>>  carrying BGP traffic between two routers MUST NOT cause the connection
>>  to drop.
>>  We also have been told that TCP connections between routers may remain
>>  stable for very long time intervals, long enough for TCP sequence
>>  numbers to cycle. Normal security practice would say that we should
>>  change keys before TCP sequence numbers cycle, IF we rely on these
>>  numbers to provide anti-replay protection. SO, there is an engineering
>>  tradeoff to be addressed in this context, one that might not be a big
>>  deal in more generic TCP contexts.
>
>Right - thus we're definitely making sure it's useful for BGP, as noted
>in the abstract. We can certainly reiterate that in the intro.

The I-D text you cited above (as opposed to the text you said could 
be provided)  allayed my concerns over the scope.  However, until 
there is a design for the key management complement to the TCP 
option, one cannot be confident that the option has the right hooks 
to support whatever the key management requires.

>
>>      - This issue is further complicated by the fact that some of the
>>  ways one might address the key rollover problem are dependent on the
>>  larger key management capabilities that are available. We have been told
>>  that there are a lot of operational constraints that key management must
>>  meet if it is to be viable in this BGP context. But, until those
>>  constraints are articulated and agreed upon, with input from the ISP
>>  operations community, we will not know what options are available to us.
>
>That is input from the BGP community to SAAG, not from TCPM. Although
>the members overlap, TCPM is not issuing those requirements AFAICT.
>
>Joe

I think such input from that community is essential, and must be 
considered in developing viable key management procedures/protocols. 
Moreover, as I noted, absent agreement on such procedures and 
protocols, one cannot be confident that the TCP option design is done.

Steve

From kent@bbn.com Wed Dec 19 13:19:36 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBJIJatF016205
	for ; Wed, 19 Dec 2007 13:19:36 -0500
Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBJIJPBI005054
	for ; Wed, 19 Dec 2007 13:19:25 -0500 (EST)
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80])
	by mit.edu (Spam Firewall) with ESMTP id D7C07681B65
	for ; Wed, 19 Dec 2007 13:12:37 -0500 (EST)
Received: from dhcp89-089-071.bbn.com ([128.89.89.71])
	by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from )
	id 1J53PI-0004T1-4n; Wed, 19 Dec 2007 13:12:36 -0500
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <736D9406-8066-4743-8E6F-3A0EE18765F6@extremenetworks.com>
References: <736D9406-8066-4743-8E6F-3A0EE18765F6@extremenetworks.com>
Date: Wed, 19 Dec 2007 13:04:07 -0500
To: RJ Atkinson 
From: Stephen Kent 
Content-Type: multipart/alternative;
	boundary="============_-1014034531==_ma============"
X-Spam-Score: 3.501
X-Spam-Level: *** (3.501)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: IETF Security Area WG 
Subject: Re: [saag] TCP Authentication & BGP protection goals
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 19 Dec 2007 18:19:36 -0000

--============_-1014034531==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 10:10 AM -0500 12/19/07, RJ Atkinson wrote:
>All,
>
>Let me suggest that protection against replay attacks
>is not properly a goal for use of TCP Authentication
>in the context of BGP protection.

That may be a reasonable suggestion.  
draft-ietf-tcpm-tcp-auth-opt-00.txt does not appear to contain a 
discussion of a threat model, so it's hard to tell if anti-replay 
should be a concern or should be ignored in this context.

>Proposals to design perfect security for IETF protocols
>have nearly always resulted in specifications that were
>difficult to implement and to deploy (and nearly always
>ended up not being deployed, for example PEM historically
>and SEND at present).
>
>The goal for TCP Authentication in the context of BGP
>ought simply be to gain "significant risk reduction
>that is widely implemented and widely deployed,
>without seeking perfect security".
>
>The existing "seen in the deployed Internet" attacks
>are of the "TCP Session Stealing" variety.  A simple
>replay attack won't permit TCP Session Stealing, which
>is most or all of the current observed-in-the-wild threat.

if session stealing from off link sources is the primary threat, then 
GTSM suffices and is much simpler. There must a different class of 
threats to be addressed, and they should be articulated.

I'll refrain from commenting on the sniping and offensive innuendos 
in the middle of the message, but will close with this observation:

My recollection from the early days of IPsec is that the initial 
protocol work was done without attention to this type of 
interdependence. The resulting security protocol specs, absent an 
architectural framework and a key management model, did not yield 
useful, interoperable implementations. Hopefully we don't want to 
repeat that experience.

Steve
--============_-1014034531==_ma============
Content-Type: text/html; charset="us-ascii"


Re: [saag] TCP Authentication & BGP protection
goals

At 10:10 AM -0500 12/19/07, RJ Atkinson wrote:


All,



Let me suggest that protection against replay attacks

is not properly a goal for use of TCP Authentication

in the context of BGP protection.





That may be a reasonable suggestion. 
draft-ietf-tcpm-tcp-auth-opt-00.txt does not appear to contain a
discussion of a threat model, so it's hard to tell if anti-replay
should be a concern or should be ignored in this context.





Proposals to design perfect security for
IETF protocols

have nearly always resulted in specifications that were

difficult to implement and to deploy (and nearly always

ended up not being deployed, for example PEM historically

and SEND at present).



The goal for TCP Authentication in the context of BGP

ought simply be to gain "significant risk reduction

that is widely implemented and widely deployed,

without seeking perfect security".



The existing "seen in the deployed Internet" attacks

are of the "TCP Session Stealing" variety.  A
simple

replay attack won't permit TCP Session Stealing, which

is most or all of the current observed-in-the-wild
threat.





if session stealing from off link sources is the primary threat,
then GTSM suffices and is much simpler. There must a different class
of threats to be addressed, and they should be articulated.





I'll refrain from commenting on the sniping and offensive
innuendos in the middle of the message, but will close with this
observation:





My recollection from the early days of IPsec is that the initial
protocol work was done without attention to this type of
interdependence. The resulting security protocol specs, absent an
architectural framework and a key management model, did not yield
useful, interoperable implementations. Hopefully we don't want to
repeat that experience.





Steve



--============_-1014034531==_ma============--

From touch@ISI.EDU Wed Dec 19 14:05:00 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBJJ50fj032480
	for ; Wed, 19 Dec 2007 14:05:00 -0500
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBJJ4mAD021705
	for ; Wed, 19 Dec 2007 14:04:48 -0500 (EST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 701EBCBE8D0
	for ; Wed, 19 Dec 2007 14:04:27 -0500 (EST)
Received: from [192.168.1.44] (pool-71-106-88-149.lsanca.dsl-w.verizon.net
	[71.106.88.149])
	by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lBJJ3oaM015430;
	Wed, 19 Dec 2007 11:03:51 -0800 (PST)
Message-ID: <47696B14.1050903@isi.edu>
Date: Wed, 19 Dec 2007 11:03:48 -0800
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Stephen Kent 
References: <736D9406-8066-4743-8E6F-3A0EE18765F6@extremenetworks.com>
	
In-Reply-To: 
X-Enigmail-Version: 0.95.5
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enigA918665CC4E2FA07D1D02CBD"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: IETF Security Area WG , RJ Atkinson 
Subject: Re: [saag] TCP Authentication & BGP protection goals
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 19 Dec 2007 19:05:00 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA918665CC4E2FA07D1D02CBD
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Stephen Kent wrote:
> At 10:10 AM -0500 12/19/07, RJ Atkinson wrote:
>> All,
>>
>> Let me suggest that protection against replay attacks
>> is not properly a goal for use of TCP Authentication
>> in the context of BGP protection.
>=20
> That may be a reasonable suggestion. *
> draft-ietf-tcpm-tcp-auth-opt-00.txt* does not appear to contain a
> discussion of a threat model, so it's hard to tell if anti-replay shoul=
d
> be a concern or should be ignored in this context.

Please see the security section of that document. In specific, replays
are not necessarily in-scope since TCP should already protect from that.

=2E..
> if session stealing from off link sources is the primary threat, then
> GTSM suffices and is much simpler. There must a different class of
> threats to be addressed, and they should be articulated.

GTSM prevents forgeries only on direct links. On shared-access media, it
is not effective, and on multi-hop links, it is of limited applicability.=


Joe


--------------enigA918665CC4E2FA07D1D02CBD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHaWsVE5f5cImnZrsRAiwVAKDKjsbKFhgtV7NU971ucU+kK5F7nwCgiuD/
3BINgk3w5mycvodrgKoUSTc=
=Ym0p
-----END PGP SIGNATURE-----

--------------enigA918665CC4E2FA07D1D02CBD--

From touch@ISI.EDU Wed Dec 19 16:29:43 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBJLThqY027614
	for ; Wed, 19 Dec 2007 16:29:43 -0500
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBJLTXMP017495
	for ; Wed, 19 Dec 2007 16:29:33 -0500 (EST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 12A42CD477B
	for ; Wed, 19 Dec 2007 16:28:47 -0500 (EST)
Received: from [192.168.1.44] (pool-71-106-88-149.lsanca.dsl-w.verizon.net
	[71.106.88.149])
	by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lBJLS4mA005605;
	Wed, 19 Dec 2007 13:28:05 -0800 (PST)
Message-ID: <47698CDB.2090408@isi.edu>
Date: Wed, 19 Dec 2007 13:27:55 -0800
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Stephen Kent 
References: <736D9406-8066-4743-8E6F-3A0EE18765F6@extremenetworks.com>
	 <47696B14.1050903@isi.edu>
	
In-Reply-To: 
X-Enigmail-Version: 0.95.5
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enigE561B491E9C37FA3A20D8139"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: IETF Security Area WG , RJ Atkinson 
Subject: Re: [saag] TCP Authentication & BGP protection goals
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 19 Dec 2007 21:29:43 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE561B491E9C37FA3A20D8139
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Stephen Kent wrote:
> At 11:03 AM -0800 12/19/07, Joe Touch wrote:
>> Stephen Kent wrote:
>>>  At 10:10 AM -0500 12/19/07, RJ Atkinson wrote:
>>>>  All,
>>>>
>>>>  Let me suggest that protection against replay attacks
>>>>  is not properly a goal for use of TCP Authentication
>>>>  in the context of BGP protection.
>>>
>>>  That may be a reasonable suggestion. *
>>>  draft-ietf-tcpm-tcp-auth-opt-00.txt* does not appear to contain a
>>>  discussion of a threat model, so it's hard to tell if anti-replay
>>> should
>>>  be a concern or should be ignored in this context.
>>
>> Please see the security section of that document. In specific, replays=

>> are not necessarily in-scope since TCP should already protect from tha=
t.
>=20
> I read the security considerations section.  It says " ... isn't needed=

> due to TCP's Sequence Number, which is used to reorder received
> segments."  This is not an accurate statement. TCP sequence numbers
> protect against replays in a benign context. In a hostile environment,
> one assumes an attacker could replay a previous TCP segment  transmitte=
d
> by the peer and the segment would be accepted if the replayed segment
> falls within the current transmit window AND if no key change has
> occurred.  A rationale to justify a decision to not address replay
> attacks should state which of the preconditions cited above for a
> successful replay attack are deemed infeasible for an attacker in this
> context, for example.

Agreed.

> Also note that at the top of page 15 the text says "TSAD entries for TC=
P
> connections not in the CLOSED state are deleted indirectly using the
> CLOSE or ABORT commands. This avoids key reuse, which could contribute
> to packet replays."  This text makes the counter-argument, i.e., if a
> key is reused it makes a session susceptible to replay attacks (which i=
s
> true)! =20

Keys are not reused within a connection; that is addressed elsewhere in
the document. It is probably useful to augment that discussion with the
requirements for key rollover.

> Of course on page 4, where AO is compared to IPsec/IKE, there is
> a bullet saying that AO does not protect from replay attacks. But that
> is not a rationale, just an observation, and it does not indicate what
> sort of replay attacks, since both IPsec (presumably ESP and AH) and IK=
E
> are mentioned together.  So, for example, one does not know if the
> replay attacks against which no protection is offered are one having to=

> do with secure session/association creation, or ones in which individua=
l
> packets in a session/association are replayed by an atacker.

TCP-AO does not create secure associations; the key management mechanism
would do that. I'll augment the text to point that out.

>> ...
>>>  if session stealing from off link sources is the primary threat, the=
n
>>>  GTSM suffices and is much simpler. There must a different class of
>>>  threats to be addressed, and they should be articulated.
>>
>> GTSM prevents forgeries only on direct links. On shared-access media, =
it
>> is not effective, and on multi-hop links, it is of limited applicabili=
ty.
>=20
> agreed. and a good threat model discussion would cite that justificatio=
n
> for developing AO instead of relying on GTSM.

We can certainly add that. Note, though, that the GTSM document doesn't
distinguish its TTL mechanism from IP address filtering; for
directly-connected paths, if the upstream party is enforcing TTL, it
might as well enforce the "don't forward packets that have my source IP
address" rule as easily.

Some of these points will be summarized and posted to TCPM for WG
consensus there. To that end, it might be useful to point out:

	- discussions of TCP-AO should occur on the TCPM mailing list
	- discussions of key management solutions, default algorithms,
	and default MAC lengths should occur here

Some of the points you've raised overlap groups, admittedly. Thanks for
pointing them out.

Also, work in RPSEC is relevant to these discussions, in specific,
documents on BGP security requirements there.

Joe


--------------enigE561B491E9C37FA3A20D8139
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHaYziE5f5cImnZrsRApCqAJ9vmuUdclYkGxv62wiLOKfFtpTthACePNxL
bYHrifG6ygEOBWENiNHJeaE=
=4RQD
-----END PGP SIGNATURE-----

--------------enigE561B491E9C37FA3A20D8139--

From kent@bbn.com Wed Dec 19 16:36:51 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBJLaplj031262
	for ; Wed, 19 Dec 2007 16:36:51 -0500
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBJLafDM004056
	for ; Wed, 19 Dec 2007 16:36:41 -0500 (EST)
Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81])
	by mit.edu (Spam Firewall) with ESMTP id 87917B59EAB
	for ; Wed, 19 Dec 2007 16:13:40 -0500 (EST)
Received: from dhcp89-089-071.bbn.com ([128.89.89.71])
	by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from )
	id 1J56ET-0002cF-5O; Wed, 19 Dec 2007 16:13:37 -0500
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <47696B14.1050903@isi.edu>
References: <736D9406-8066-4743-8E6F-3A0EE18765F6@extremenetworks.com>
	 <47696B14.1050903@isi.edu>
Date: Wed, 19 Dec 2007 15:14:19 -0500
To: Joe Touch 
From: Stephen Kent 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 3.5
X-Spam-Level: *** (3.5)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: IETF Security Area WG , RJ Atkinson 
Subject: Re: [saag] TCP Authentication & BGP protection goals
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 19 Dec 2007 21:36:51 -0000

At 11:03 AM -0800 12/19/07, Joe Touch wrote:
>Stephen Kent wrote:
>>  At 10:10 AM -0500 12/19/07, RJ Atkinson wrote:
>>>  All,
>>>
>>>  Let me suggest that protection against replay attacks
>>>  is not properly a goal for use of TCP Authentication
>>>  in the context of BGP protection.
>>
>>  That may be a reasonable suggestion. *
>>  draft-ietf-tcpm-tcp-auth-opt-00.txt* does not appear to contain a
>>  discussion of a threat model, so it's hard to tell if anti-replay should
>>  be a concern or should be ignored in this context.
>
>Please see the security section of that document. In specific, replays
>are not necessarily in-scope since TCP should already protect from that.

I read the security considerations section.  It says " ... isn't 
needed due to TCP's Sequence Number, which is used to reorder 
received segments."  This is not an accurate statement. TCP sequence 
numbers protect against replays in a benign context. In a hostile 
environment, one assumes an attacker could replay a previous TCP 
segment  transmitted by the peer and the segment would be accepted if 
the replayed segment falls within the current transmit window AND if 
no key change has occurred.  A rationale to justify a decision to not 
address replay attacks should state which of the preconditions cited 
above for a successful replay attack are deemed infeasible for an 
attacker in this context, for example.

Also note that at the top of page 15 the text says "TSAD entries for 
TCP connections not in the CLOSED state are deleted indirectly using 
the CLOSE or ABORT commands. This avoids key reuse, which could 
contribute to packet replays."  This text makes the counter-argument, 
i.e., if a key is reused it makes a session susceptible to replay 
attacks (which is true)!  Of course on page 4, where AO is compared 
to IPsec/IKE, there is a bullet saying that AO does not protect from 
replay attacks. But that is not a rationale, just an observation, and 
it does not indicate what sort of replay attacks, since both IPsec 
(presumably ESP and AH) and IKE are mentioned together.  So, for 
example, one does not know if the replay attacks against which no 
protection is offered are one having to do with secure 
session/association creation, or ones in which individual packets in 
a session/association are replayed by an atacker.

>...
>>  if session stealing from off link sources is the primary threat, then
>>  GTSM suffices and is much simpler. There must a different class of
>>  threats to be addressed, and they should be articulated.
>
>GTSM prevents forgeries only on direct links. On shared-access media, it
>is not effective, and on multi-hop links, it is of limited applicability.
>

agreed. and a good threat model discussion would cite that 
justification for developing AO instead of relying on GTSM.

Steve

From rja@extremenetworks.com Wed Dec 19 16:44:46 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBJLik5J003086
	for ; Wed, 19 Dec 2007 16:44:46 -0500
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBJLiX2d001282
	for ; Wed, 19 Dec 2007 16:44:33 -0500 (EST)
Received: from eastrmmtao105.cox.net (eastrmmtao105.cox.net [68.230.240.47])
	by mit.edu (Spam Firewall) with ESMTP id 0E5B2C5688F
	for ; Wed, 19 Dec 2007 16:43:57 -0500 (EST)
Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao105.cox.net
	(InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id
	<20071219214357.LGCC15951.eastrmmtao105.cox.net@eastrmimpo01.cox.net>
	for ; Wed, 19 Dec 2007 16:43:57 -0500
Received: from [10.30.20.71] ([68.10.115.26])
	by eastrmimpo01.cox.net with bizsmtp
	id SljB1Y00E0aEP1Q0000000; Wed, 19 Dec 2007 16:43:12 -0500
Message-Id: <1BE837E8-90B9-40CA-B4E8-C182B268DD25@extremenetworks.com>
From: RJ Atkinson 
To: IETF Security Area WG 
In-Reply-To: 
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Date: Wed, 19 Dec 2007 16:43:56 -0500
References: <736D9406-8066-4743-8E6F-3A0EE18765F6@extremenetworks.com>
	
X-Mailer: Apple Mail (2.915)
X-Spam-Score: 0.01
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: Re: [saag] History and recollection
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 19 Dec 2007 21:44:46 -0000


Earlier, it was written:
> My recollection from the early days of IPsec is that the
> initial protocol work was done without attention to this
> type of interdependence. The resulting security protocol specs,
> absent an architectural framework and a key management model,
> did not yield useful, interoperable implementations.
> Hopefully we don't want to repeat that experience.

Curiously enough, given the quoted text above, there were
several independent interoperable implementations of IPsec
by the end of 1995.  The first pair were NRL and Network Systems,
as I recall, roughly in September 1995.  I'd have to rummage
in my notes to find a more precise date for that first successful
test of multiple implementations.

There were also several multi-implementation deployments
of IPsec in daily use during the same 1995/1996 timeframe.

Further, the PF_KEY Key Management API developed (by others
at NRL) way back then is still in use (with some enhancements,
as one might ordinarily expect over a decade of time) today
in many {free, commercial} UNIX systems.  Had the key management
model been so underdeveloped as claimed above, then implementers
would not have been able to use an API developed before ISAKMP/IKE
went to RFC with the ISAKMP/IKE implementations, as they did
so long ago.  Beyond that, most UNIX systems still use that same API
today (again: with only a few minor API additions over a decade
of time).

So if early IPsec is any sort of model, then it was a very good
model since IPsec actually deployed (both early on and continuing
today).  This contrasts with several efforts in the security
area that have never deployed, despite intense efforts on the
standards by numerous people over some years of time.  I think
it might have been Tony Li who originally said long ago (talking
about standards generally, rather than about security specifically)
that "At the end of the day, deployment is what matters."

All protocols change over time.  Routing protocols today differ
from routing protocols of a decade ago, or two decades ago,
in various ways.  TCP changed a fair bit over the past two
decades, particularly with the invention of Slow Start.  Today
we have SCTP in addition to TCP and UDP, which many people
were surprised to see happen.

I grasp that people's mileage necessarily will vary somewhat
on this (seemingly tangential to the original TCP Authentication
thread) topic of IPsec history.  It isn't at all surprising
to me that different folks, who had different inputs, over
roughly a decade of time, would have differing recollections
of the history -- of any openly specified protocol(s).   :-)

Cheers,

Ran
rja@extremenetworks.com



From Nicolas.Williams@sun.com Wed Dec 19 16:48:57 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBJLmvmc005749
	for ; Wed, 19 Dec 2007 16:48:57 -0500
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBJLmjuI000618
	for ; Wed, 19 Dec 2007 16:48:46 -0500 (EST)
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25])
	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 3E059C74986
	for ; Wed, 19 Dec 2007 16:48:25 -0500 (EST)
Received: from dm-central-02.central.sun.com ([129.147.62.5])
	by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id
	lBJLmN1E008781 for ; Wed, 19 Dec 2007 21:48:23 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,
	v2.2) with ESMTP id lBJLmM1S023671
	for ; Wed, 19 Dec 2007 14:48:23 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id
	lBJLmMAM019906; Wed, 19 Dec 2007 15:48:22 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lBJLmL8v019905; 
	Wed, 19 Dec 2007 15:48:21 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to
	Nicolas.Williams@sun.com using -f
Date: Wed, 19 Dec 2007 15:48:21 -0600
From: Nicolas Williams 
To: Joe Touch 
Message-ID: <20071219214821.GH14367@Sun.COM>
References: <736D9406-8066-4743-8E6F-3A0EE18765F6@extremenetworks.com>
	 <47696B14.1050903@isi.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <47696B14.1050903@isi.edu>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: IETF Security Area WG , RJ Atkinson 
Subject: Re: [saag] TCP Authentication & BGP protection goals
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 19 Dec 2007 21:48:57 -0000

On Wed, Dec 19, 2007 at 11:03:48AM -0800, Joe Touch wrote:
> 
> 
> Stephen Kent wrote:
> > At 10:10 AM -0500 12/19/07, RJ Atkinson wrote:
> >> All,
> >>
> >> Let me suggest that protection against replay attacks
> >> is not properly a goal for use of TCP Authentication
> >> in the context of BGP protection.
> > 
> > That may be a reasonable suggestion. *
> > draft-ietf-tcpm-tcp-auth-opt-00.txt* does not appear to contain a
> > discussion of a threat model, so it's hard to tell if anti-replay should
> > be a concern or should be ignored in this context.
> 
> Please see the security section of that document. In specific, replays
> are not necessarily in-scope since TCP should already protect from that.
> 
> ...
> > if session stealing from off link sources is the primary threat, then
> > GTSM suffices and is much simpler. There must a different class of
> > threats to be addressed, and they should be articulated.
> 
> GTSM prevents forgeries only on direct links. On shared-access media, it
> is not effective, and on multi-hop links, it is of limited applicability.

Attackers with access to on-path shared-media links can mount replay
attacks (as well as other active attacks).

If such attackers are part of the threat model then leaving replay
attacks out of scope seems... wrong.  Either you don't concern yourself
with such attackers or you bring all the attacks that they can mount
into the threat model.

Nico
-- 

From kent@bbn.com Wed Dec 19 17:21:37 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBJMLb7B021143
	for ; Wed, 19 Dec 2007 17:21:37 -0500
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBJMLROu010733
	for ; Wed, 19 Dec 2007 17:21:27 -0500 (EST)
Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81])
	by mit.edu (Spam Firewall) with ESMTP id 61615C72C40
	for ; Wed, 19 Dec 2007 17:21:05 -0500 (EST)
Received: from dhcp89-089-071.bbn.com ([128.89.89.71])
	by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from )
	id 1J57Hh-0003VZ-4H; Wed, 19 Dec 2007 17:21:04 -0500
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <47698CDB.2090408@isi.edu>
References: <736D9406-8066-4743-8E6F-3A0EE18765F6@extremenetworks.com>
	 <47696B14.1050903@isi.edu>
	 <47698CDB.2090408@isi.edu>
Date: Wed, 19 Dec 2007 16:44:19 -0500
To: Joe Touch 
From: Stephen Kent 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: IETF Security Area WG 
Subject: Re: [saag] TCP Authentication & BGP protection goals
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 19 Dec 2007 22:21:37 -0000

Joe,

Thanks for the quick response.  I think we're getting closer to 
documenting the assumptions that underlie the current design, which 
is a good thing. It will make it easier for others to appreciate the 
context assumptions that the design team has used.

Steve

From touch@ISI.EDU Wed Dec 19 17:26:00 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBJMQ0XY023179
	for ; Wed, 19 Dec 2007 17:26:00 -0500
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBJMPoPZ024013
	for ; Wed, 19 Dec 2007 17:25:50 -0500 (EST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id A8D38C75B7B
	for ; Wed, 19 Dec 2007 17:25:29 -0500 (EST)
Received: from [192.168.1.44] (pool-71-106-88-149.lsanca.dsl-w.verizon.net
	[71.106.88.149])
	by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lBJMOluo022716;
	Wed, 19 Dec 2007 14:24:48 -0800 (PST)
Message-ID: <47699A2D.1040607@isi.edu>
Date: Wed, 19 Dec 2007 14:24:45 -0800
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Nicolas Williams 
References: <736D9406-8066-4743-8E6F-3A0EE18765F6@extremenetworks.com>
	
	<47696B14.1050903@isi.edu> <20071219214821.GH14367@Sun.COM>
In-Reply-To: <20071219214821.GH14367@Sun.COM>
X-Enigmail-Version: 0.95.5
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig8993C5711AC2CAE570EA18EC"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: IETF Security Area WG , RJ Atkinson 
Subject: Re: [saag] TCP Authentication & BGP protection goals
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 19 Dec 2007 22:26:00 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig8993C5711AC2CAE570EA18EC
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Nicolas Williams wrote:
=2E..
> Attackers with access to on-path shared-media links can mount replay
> attacks (as well as other active attacks).
>=20
> If such attackers are part of the threat model then leaving replay
> attacks out of scope seems... wrong.  Either you don't concern yourself=

> with such attackers or you bring all the attacks that they can mount
> into the threat model.

The point wasn't that the threat model doesn't include replays, but that
the requirement for anti-replay in an authenticated TCP stream is
different than in IP. In particular, TCP already has a sequence number,
so as long as the session key changes when the seq space wraps (beyond
ISN, not beyond zero) TCP's existing mechanisms defeat replay as a
content attack.

Joe


--------------enig8993C5711AC2CAE570EA18EC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHaZotE5f5cImnZrsRAhZgAJ4rX43mMGcP66Z9noU4lC1TkH7LCwCcDRRQ
e8ZppZXss9CrGxmoORfBsOw=
=bRUm
-----END PGP SIGNATURE-----

--------------enig8993C5711AC2CAE570EA18EC--

From mcgrew@cisco.com Thu Dec 20 10:52:32 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBKFqW8H006259
	for ; Thu, 20 Dec 2007 10:52:32 -0500
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBKFqJkF013284
	for ; Thu, 20 Dec 2007 10:52:19 -0500 (EST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149])
	by mit.edu (Spam Firewall) with ESMTP id C413FB7C5AA
	for ; Thu, 20 Dec 2007 10:50:55 -0500 (EST)
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-2.cisco.com with ESMTP; 20 Dec 2007 10:50:56 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBKFotGW004710; 
	Thu, 20 Dec 2007 10:50:55 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBKFoagF014028; 
	Thu, 20 Dec 2007 15:50:55 GMT
Received: from xmb-rtp-20c.amer.cisco.com ([64.102.31.57]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 20 Dec 2007 10:50:40 -0500
Received: from 10.32.254.210 ([10.32.254.210]) by xmb-rtp-20c.amer.cisco.com
	([64.102.31.57]) with Microsoft Exchange Server HTTP-DAV ; 
	Thu, 20 Dec 2007 15:50:29 +0000
User-Agent: Microsoft-Entourage/11.2.4.060510
Date: Thu, 20 Dec 2007 07:50:27 -0800
From: mcgrew 
To: Brian Weis 
Message-ID: 
Thread-Topic: [saag] TCP-AO MAC algorithms
Thread-Index: AchDIAo/SQgSTa8TEdyWUgAUUQnMFg==
In-Reply-To: <98FA6BE8-0825-41F6-8DAA-1A5706D974A9@cisco.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 20 Dec 2007 15:50:40.0029 (UTC)
	FILETIME=[120374D0:01C84320]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2437; t=1198165855;
	x=1199029855; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=mcgrew@cisco.com;
	z=From:=20mcgrew=20
	|Subject:=20Re=3A=20[saag]=20TCP-AO=20MAC=20algorithms
	|Sender:=20 |To:=20Brian=20Weis=20;
	bh=db5yKbeVVV4lKEPvRBXFGIk+0ika4jSDScmCbRTSXKk=;
	b=JOyrLJNdEkzXE37ydTR2kd8nqKdU2Ea5lfLaI4LLx/i0U6gCatjo5Fa8ND
	+9LFs2CY6+tW2ybrfPmoPtUjKbcx9V3GEIV47PPh2z/8ErbDRad/l+oq2yCO
	xWaIpi9qoR;
Authentication-Results: rtp-dkim-2; header.From=mcgrew@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.14
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, cfrg@ietf.org
Subject: Re: [saag] TCP-AO MAC algorithms
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 20 Dec 2007 15:52:32 -0000

Hi Brian,

I've cross-posted to CFRG to tie the TCP Auth work in with
draft-irtf-cfrg-fast-mac-requirements draft.

On 12/18/07 4:23 PM, "Brian Weis"  wrote:

> Greetings,
> 
> The TCPM WG seeks advice from SAAG on which MACs to include as
> required MACs for the TCP Authentication Option (draft-ietf-tcpm-tcp-
> auth-opt-00). Two MACs with differing internal constructions are
> desired.

I assume that the reason for having two mandatory-to-implement MACs is to
ensure algorithm agility.

> 
> In my opinion, it is also important that MACs defined by an Internet
> standard as required to be implemented be based on NIST-approved
> algorithms and modes, and also be generally available in both
> software and cryptographic hardware.
> 
> The following two MACs are reasonable recommendations that taken
> together easily meet the above criteria: HMAC-SHA-1 and AES-CMAC. I
> propose that these be the algorithms provided to the TCPM WG.
> 
> Brian

Sounds like reasonable choices to me.

It would be good to have a MAC that performs exceptionally well in software,
along the lines of what we've targeted in
draft-irtf-cfrg-fast-mac-requirements, but if the choice of MACs has to be
made *today*, there may not be a suitable candidate that has been
sufficiently specified and/or reviewed.  I expect that MACs that will be
more suitable for use in TCP Authentication will be developed (candidates
include [1] and [2]).  I trust that there is a path for the adoption of new
MACs in TCP Auth.  

Probably the biggest open question is the length of the MAC.  The CMAC
specification states that lengths 64 bits and higher are acceptable, but
that smaller values "shall only be used in conjunction
with a careful analysis of the risks" [1].  It would be good to do this
analysis for TCP Auth, of course, but it is encouraging that AES-128-CMAC
could be used with a 64-bit tag and still meet the conformance goals that
you outlined. 

Best regards, 

David


[1] J. Black and M. Cochran, "MAC Reforgeability",
http://eprint.iacr.org/2006/095

[2] D.J. Bernstein, "Polynomial evaluation and message authentication",
http://cr.yp.to/antiforgery/pema-20071022.pdf

[3] M. Dworkin, NIST Special Publication 800-38B, "Recommendation for Block
Cipher Modes of Operation: The CMAC Mode for Authentication"
http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf

From touch@ISI.EDU Thu Dec 20 11:22:53 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBKGMr6W017118
	for ; Thu, 20 Dec 2007 11:22:53 -0500
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBKGMfoB011060
	for ; Thu, 20 Dec 2007 11:22:41 -0500 (EST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id CBD9FB722DD
	for ; Thu, 20 Dec 2007 11:22:20 -0500 (EST)
Received: from [192.168.1.44] (pool-71-106-88-149.lsanca.dsl-w.verizon.net
	[71.106.88.149])
	by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lBKGM3nm025049;
	Thu, 20 Dec 2007 08:22:04 -0800 (PST)
Message-ID: <476A96A1.70108@isi.edu>
Date: Thu, 20 Dec 2007 08:21:53 -0800
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: mcgrew 
References: 
In-Reply-To: 
X-Enigmail-Version: 0.95.5
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig52E6B2220B945A5C09D61EA8"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, cfrg@ietf.org
Subject: Re: [saag] TCP-AO MAC algorithms
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 20 Dec 2007 16:22:53 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig52E6B2220B945A5C09D61EA8
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



mcgrew wrote:
> Hi Brian,
>=20
> I've cross-posted to CFRG to tie the TCP Auth work in with
> draft-irtf-cfrg-fast-mac-requirements draft.
>=20
> On 12/18/07 4:23 PM, "Brian Weis"  wrote:
>=20
>> Greetings,
>>
>> The TCPM WG seeks advice from SAAG on which MACs to include as
>> required MACs for the TCP Authentication Option (draft-ietf-tcpm-tcp-
>> auth-opt-00). Two MACs with differing internal constructions are
>> desired.
>=20
> I assume that the reason for having two mandatory-to-implement MACs is =
to
> ensure algorithm agility.

It's primarily to ensure a backup is already in place if one algorithm
is determined as compromised.

=2E..
> Probably the biggest open question is the length of the MAC.  The CMAC
> specification states that lengths 64 bits and higher are acceptable, bu=
t
> that smaller values "shall only be used in conjunction
> with a careful analysis of the risks" [1].  It would be good to do this=

> analysis for TCP Auth, of course, but it is encouraging that AES-128-CM=
AC
> could be used with a 64-bit tag and still meet the conformance goals th=
at
> you outlined.=20

The use of specific values for each algorithm when used for TCP-AO is
important, but may not be necessary for the initial document. We're
looking for a default that could apply to either mandatory algorithm,
but not necessarily the optimal value for those algorithms.

Joe


--------------enig52E6B2220B945A5C09D61EA8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHaparE5f5cImnZrsRAszbAJ9IBAFWejjQRs3fUBll6AWUdf0AMACeJTa3
QuUUCGe7UxgRHLzfZmYHBH8=
=5HW+
-----END PGP SIGNATURE-----

--------------enig52E6B2220B945A5C09D61EA8--

From Craemer@isoc.org Wed Dec 19 12:58:06 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBJHw5AI009428
	for ; Wed, 19 Dec 2007 12:58:06 -0500
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBJHvs70020560
	for ; Wed, 19 Dec 2007 12:57:54 -0500 (EST)
Received: from smtp130.iad.emailsrvr.com (smtp130.iad.emailsrvr.com
	[207.97.245.130])
	by mit.edu (Spam Firewall) with ESMTP id 0BDE4B555C2
	for ; Wed, 19 Dec 2007 12:41:12 -0500 (EST)
Received: from relay3.r3.iad.emailsrvr.com (localhost [127.0.0.1])
	by relay3.r3.iad.emailsrvr.com (SMTP Server) with ESMTP id CF76944CF27
	for ; Wed, 19 Dec 2007 12:41:11 -0500 (EST)
Received: by relay3.r3.iad.emailsrvr.com (Authenticated sender:
	craemer-AT-isoc.org) with ESMTP id 62DA744CDA6
	for ; Wed, 19 Dec 2007 12:41:11 -0500 (EST)
From: "Kevin Craemer" 
To: 
Date: Wed, 19 Dec 2007 12:46:05 -0500
Message-ID: <001e01c84267$084da4b0$03320a0a@ISOC.local>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AchCZwchGlzETzB/SXGEGbaNfhryQQ==
X-Spam-Score: 0.14
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
X-Mailman-Approved-At: Thu, 20 Dec 2007 13:04:20 -0500
Subject: [saag] NDSS Security Symposium - Registration Reminder
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 19 Dec 2007 17:58:06 -0000

Please note the December 21 deadline for early registration for NDSS '08 in
San Diego.
 
Kevin Craemer
Internet Society
 
= = = = = = = = =
 
The 15th Annual Network and Distributed System Security Symposium
The Dana on Mission Bay
San Diego, California
10-13 February, 2008

The Symposium fosters information exchange among research scientists and
practitioners of network and distributed system security services.
Participants include those interested in practical aspects of network and
distributed system security, with a focus on actual system design and
implementation (rather than theory). A major goal is to encourage and enable
the Internet community to apply, deploy, and advance the state of available
security technology.

Bot sniffers, malware hooking behaviors and attribute-based cryptosystems
are just a few of the topics to be examined this year. Register early and
save.  More information on the program, paper presentations, hotel and
online registration can be found at: http://www.isoc.org/ndss08.



 


From huitema@windows.microsoft.com Wed Dec 19 18:07:36 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBJN7aY4003706
	for ; Wed, 19 Dec 2007 18:07:36 -0500
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBJN7RQg021454
	for ; Wed, 19 Dec 2007 18:07:27 -0500 (EST)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 25FECB32DA5
	for ; Wed, 19 Dec 2007 18:07:06 -0500 (EST)
Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by
	TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with
	Microsoft
	SMTP Server (TLS) id 8.1.222.3; Wed, 19 Dec 2007 15:07:04 -0800
Received: from TK5-EXMLT-W604.wingroup.windeploy.ntdev.microsoft.com
	(157.54.18.7) by tk1-exhub-c104.redmond.corp.microsoft.com
	(157.56.116.117)
	with Microsoft SMTP Server id 8.1.222.3; Wed, 19 Dec 2007 15:06:31 -0800
Received: from NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com
	([157.54.62.196]) by
	TK5-EXMLT-W604.wingroup.windeploy.ntdev.microsoft.com
	([157.54.18.7]) with mapi; Wed, 19 Dec 2007 14:58:08 -0800
From: Christian Huitema 
To: Joe Touch , Nicolas Williams 
Date: Wed, 19 Dec 2007 14:58:06 -0800
Thread-Topic: [saag] TCP Authentication & BGP protection goals
Thread-Index: AchCjs4somVUPpa4SMKC/ckuOYREuAAA3Fnw
Message-ID: 
References: <736D9406-8066-4743-8E6F-3A0EE18765F6@extremenetworks.com>
		<47696B14.1050903@isi.edu>
	<20071219214821.GH14367@Sun.COM> <47699A2D.1040607@isi.edu>
In-Reply-To: <47699A2D.1040607@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-Spam-Score: 0.02
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id
	lBJN7aY4003706
X-Mailman-Approved-At: Thu, 20 Dec 2007 13:04:20 -0500
Cc: IETF Security Area WG , RJ Atkinson 
Subject: Re: [saag] TCP Authentication & BGP protection goals
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Wed, 19 Dec 2007 23:07:36 -0000

> The point wasn't that the threat model doesn't include replays, but
> that the requirement for anti-replay in an authenticated TCP stream is
> different than in IP. In particular, TCP already has a sequence number,
> so as long as the session key changes when the seq space wraps (beyond
> ISN, not beyond zero) TCP's existing mechanisms defeat replay as a
> content attack.

TCP sequence numbers protect against the repetition of data packets, but they do not protect against the repetition of acknowledgements. Are you not concerned with duplicate acknowledgements?

-- Christian Huitema




From slesch_mn1@comcast.net Wed Dec 19 21:58:23 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBK2wNTm029056
	for ; Wed, 19 Dec 2007 21:58:23 -0500
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBK2w99a009589
	for ; Wed, 19 Dec 2007 21:58:09 -0500 (EST)
Received: from QMTA02.emeryville.ca.mail.comcast.net
	(qmta02.emeryville.ca.mail.comcast.net [76.96.30.24])
	by mit.edu (Spam Firewall) with ESMTP id E466DB59C50
	for ; Wed, 19 Dec 2007 21:57:45 -0500 (EST)
Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44])
	by QMTA02.emeryville.ca.mail.comcast.net with comcast
	id Squa1Y0070x6nqc0A00W00; Thu, 20 Dec 2007 02:57:51 +0000
Received: from Susan-Leschs-Computer.local ([66.41.243.130])
	by OMTA12.emeryville.ca.mail.comcast.net with comcast
	id Sqxp1Y0092pXAXW8Y00000; Thu, 20 Dec 2007 02:57:51 +0000
X-Authority-Analysis: v=1.0 c=1 a=8pif782wAAAA:8 a=eTbczjxfuqc-UMiLi_MA:9
	a=iwlaOq5titYii2L5OwcA:7 a=e-vMINaSaq1nY_TYn4Ho_JWJGFkA:4
	a=si9q_4b84H0A:10 a=HzqeS-Dt6hYA:10 a=b8hG5vVbyAkA:10
	a=xe8BsctaAAAA:8 a=7C1nKWIAtAEwAAZKOtMA:9
	a=Evy7DOpJ99dVnJNn8Shl0YS-PosA:4 a=rPt6xJ-oxjAA:10
Message-ID: <4769DA1E.6080509@comcast.net>
Date: Wed, 19 Dec 2007 20:57:34 -0600
From: "Susan G. Lesch" 
Organization: none
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: saag@mit.edu
X-Enigmail-Version: 0.95.5
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig41FC5D348E55FA6B0B8B3E67"
X-Spam-Score: 5.634
X-Spam-Level: ***** (5.634)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
X-Mailman-Approved-At: Thu, 20 Dec 2007 13:38:36 -0500
Subject: [saag] [Fwd: IETF Wikipedia entry [resend]]
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: susan@textet.com
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 20 Dec 2007 02:58:23 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig41FC5D348E55FA6B0B8B3E67
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello,

Third try to send this to your list.

Please pardon the bcc's this time.

Best wishes,
Susan Lesch

-------- Original Message --------
Subject: IETF Wikipedia entry [resend]
Date: Mon, 17 Dec 2007 21:05:00 -0600
From: Susan G. Lesch 
Reply-To: susan@textet.com
Organization: none
To: saag@mit.edu, sgl@textet.com

Hello,

Only a new subscriber here. I am not a security expert. I added a small a=
mount
of information about your list to the English Wikipedia at the following =
URL:

http://en.wikipedia.org/wiki/Internet_Engineering_Task_Force

Best wishes for the holiday season and the new year.

--=20
Susan G. Lesch
TEXTET
San Diego, California and Minneapolis, Minnesota, USA
mailto:susan@textet.com


--------------enig41FC5D348E55FA6B0B8B3E67
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHadonfPWQQKYo3rkRApznAJ4sGbb6cTR9SwFjAF5nGVh9UvXNFwCgsfrz
saMBI9VBbcP0m46hrmz6l6c=
=bBme
-----END PGP SIGNATURE-----

--------------enig41FC5D348E55FA6B0B8B3E67--

From kent@bbn.com Thu Dec 20 18:20:15 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBKNKFqs030665
	for ; Thu, 20 Dec 2007 18:20:15 -0500
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBKNK504014924
	for ; Thu, 20 Dec 2007 18:20:05 -0500 (EST)
Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81])
	by mit.edu (Spam Firewall) with ESMTP id 389B2CC925A
	for ; Thu, 20 Dec 2007 18:19:44 -0500 (EST)
Received: from dhcp89-089-071.bbn.com ([128.89.89.71])
	by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from )
	id 1J5Ug3-0001pk-3w; Thu, 20 Dec 2007 18:19:43 -0500
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <1BE837E8-90B9-40CA-B4E8-C182B268DD25@extremenetworks.com>
References: <736D9406-8066-4743-8E6F-3A0EE18765F6@extremenetworks.com>
	
	<1BE837E8-90B9-40CA-B4E8-C182B268DD25@extremenetworks.com>
Date: Thu, 20 Dec 2007 18:19:49 -0500
To: RJ Atkinson 
From: Stephen Kent 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: IETF Security Area WG 
Subject: Re: [saag] History and recollection
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Thu, 20 Dec 2007 23:20:18 -0000

Ran,

Our recollection of that periods differs in several important 
respects.  I recall that (most?) vendors failed to achieve 
interoperable implementations based on the 1995 set of RFCs.

There was no document to guide an implementer or user to know what to 
expect with regard to protection of traffic by AH or ESP, from a 
security policy  perspective, or how key and SA management would be 
performed to implement such policies. Since the goal of using IPsec 
is to afford protection for some set of traffic, a lack of a way to 
characterize what traffic is to be protected was a serious omission. 
It precluded having a standard way to negotiate protection parameters 
for an SA. Thus only manual configuration, based on non-standard 
characterizations of what was being protected and how were possible, 
based on these RFCs. That may be fine for "hobbyist 
interoperability," but it's not suitable for enterprise users. I 
think we all agree that manual SA establishment scales so poorly as 
to be not viable for enterprise use. And, for most individuals, the 
lack of vendor support or a GUI for management made IPsec too hard to 
use as well.  Thus the market for the version of IPsec defined by the 
RFCs published in 1995 was pretty small, at best.

More specifically, RFC 1825 (the Architecture spec) failed to 
describe how one could configure a database to say what traffic would 
be protected vs. bypassed, or how traffic would be protected. Thus 
there was no standard way for an administrator or user to express a 
security policy, or for two IPsec implementations to exchange traffic 
selectors to enable them to establish an SA compatible with both 
local policies, an important aspects of interoperation.

RFC 1825 also fails to provide a concrete definition for an SAD 
entry. It provides an informal list of parameters that might 
"normally" be used, but the only MUSTs for an SAD entry are the 
destination address and the SPI. There is an incomplete description 
on how to perform outbound processing based on userid, which is not 
compatible with a security gateway implementations, even though such 
implementations are explicitly included in the document.

The reserved standards word "MUST" appears only 5 times in 1825, 
other than in references to algorithm requirements and the MLS 
features discussion. In contrast to the death of MUSTs, the term 
"normally," which does not do much to ensure interoperability, 
appears 6 times. MLS gets way too much attention, as it was of no 
interest to mainstream  users of IPsec. The RFC also encouraged 
support for IPSO labels. Even though I am the author of RFC 1108 Ithe 
IPSO spec), we both know that these labels were of little or no 
interest to the broader Internet population. The DoD users who might 
have been the target for MLS language here didn't seem to care 
either, i.e., no NSA-certified crypto was ever built based on these 
specs. (Only the most recent version of the HAIPE will be 
IPsec-based, and it relies on the most recent RFCs.)

In the RFC 1827, ESP was defined to allow encryption and optional 
integrity, but the format defined for ESP did not specify the order 
in which these two services would be applied if both were selected. 
The only transform defined for ESP provided only encryption, so the 
issue was not resolved in this set of specs. This lead to folks 
believing that the right way to offer both confidentiality and 
integrity was by using both AH and ESP, a very inefficient 
combination that probably contributed the the perception that IPsec 
was an expensive way to secure traffic for many years. The decision 
to defer further definition of the ESP format to individual transform 
specs was a bad one. CBC, CFB, and OFB modes of DES, triple-DES and 
AES all can and do use the same basic format that was later defined 
in 2306. It was not until cryptographers came to agreement on 
non-encumbered modes that integrate integrity and confidentiality 
that we had to define a second, less-specific format for ESP, in the 
205 specs.

You cite PF_KEY, but it is an API, not a protocol, and it never 
became a standards track RFC. Moreover, the Informaitonal RFC (2367) 
for PF_Key (v2) was published in 1998, not the 1995 time frame you 
described.  So perhaps you are referring to folks who informally used 
PF-KEY v1 to get hosts to talk to one another independent of any 
published IETF standards, which also is not inconsistent with my 
recollection.

The IPsec implementations that are more or less universally available 
today in mainstream end user and security gateway products are all 
based on the second set of IPsec standards, from 1998, and may 
migrate to the third set, from 2005.

What we should learn from the early IPsec experience is that the 
hardest parts of creating a viable security protocol standard are NOT 
the definition of the formats for traffic protection, but rather the 
key and SA management aspects of the solution. Moreover, until we 
have defined these latter aspects of the solution, we cannot be 
confident that the syntax and state machine for traffic protection 
are correct.

Steve

Steve


From rja@extremenetworks.com Fri Dec 21 08:16:32 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBLDGWHk030155
	for ; Fri, 21 Dec 2007 08:16:32 -0500
Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBLDGLFt018440
	for ; Fri, 21 Dec 2007 08:16:22 -0500 (EST)
Received: from eastrmmtao101.cox.net (eastrmmtao101.cox.net [68.230.240.7])
	by mit.edu (Spam Firewall) with ESMTP id 0AC1768696D
	for ; Fri, 21 Dec 2007 08:16:19 -0500 (EST)
Received: from eastrmimpo03.cox.net ([68.1.16.126]) by eastrmmtao101.cox.net
	(InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP
	id <20071221131618.LVIJ6098.eastrmmtao101.cox.net@eastrmimpo03.cox.net>
	for ; Fri, 21 Dec 2007 08:16:18 -0500
Received: from [10.30.20.71] ([68.10.115.26])
	by eastrmimpo03.cox.net with bizsmtp
	id TR711Y0090aEP1Q0000000; Fri, 21 Dec 2007 08:07:06 -0500
Message-Id: <2411C3BD-B437-406F-A81F-3282CF219A55@extremenetworks.com>
From: RJ Atkinson 
To: IETF Security Area WG 
In-Reply-To: 
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Date: Fri, 21 Dec 2007 08:16:13 -0500
References: <736D9406-8066-4743-8E6F-3A0EE18765F6@extremenetworks.com>
	
	<1BE837E8-90B9-40CA-B4E8-C182B268DD25@extremenetworks.com>
	
X-Mailer: Apple Mail (2.915)
X-Spam-Score: 0.01
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: Re: [saag] History and recollection
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 21 Dec 2007 13:16:32 -0000


It will surprise no one that I disagree with Steve's note.

(Rather than boring folks here with a point-by-point response,
I'll just say that in the unlikely event anyone on this list
really cares about any of this historical discussion, then
I'm happy to chat about it off list -- where it won't bother
the vast majority of folks on this list who don't care either way. :-)

Anyway, this excursion into history has reminded me about
Steve Bellovin's paper in ACM Computer Communications Review
(ACM CCR) from just about 20 years ago:
	"Security Problems in the TCP/IP Protocol Suite"
	ACM CCR, Volume 19, Issue 2  (April 1989), Pages 32 - 48

I'd encourage everyone to read that paper, and also to be fair,
to also read Steve Kent's rebuttal paper, which was published
not long afterwards:
	"Comments on 'Security Problems in the TCP/IP Protocol Suite'"
	ACM CCR, Volume 19, Issue 3 (July 1989), Pages 10-19

And then mull over in your own heads whether this community
has made very much headway in the intervening two decades,
which risk reduction methods are deployed now that were
not deployed then, and which areas seem ripe for new effort.

Merry Christmas !


Ran


From touch@ISI.EDU Fri Dec 21 09:33:54 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBLEXsFw018641
	for ; Fri, 21 Dec 2007 09:33:54 -0500
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBLEXguK002763
	for ; Fri, 21 Dec 2007 09:33:42 -0500 (EST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id BFACBC7D27F
	for ; Fri, 21 Dec 2007 09:33:13 -0500 (EST)
Received: from [192.168.1.44] (pool-71-106-88-149.lsanca.dsl-w.verizon.net
	[71.106.88.149])
	by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lBLEWthO029755;
	Fri, 21 Dec 2007 06:32:56 -0800 (PST)
Message-ID: <476BCE95.7000907@isi.edu>
Date: Fri, 21 Dec 2007 06:32:53 -0800
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: RJ Atkinson 
References: <736D9406-8066-4743-8E6F-3A0EE18765F6@extremenetworks.com>		<1BE837E8-90B9-40CA-B4E8-C182B268DD25@extremenetworks.com>	
	<2411C3BD-B437-406F-A81F-3282CF219A55@extremenetworks.com>
In-Reply-To: <2411C3BD-B437-406F-A81F-3282CF219A55@extremenetworks.com>
X-Enigmail-Version: 0.95.5
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig238944BC0BEA15B32DB08170"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.12
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: IETF Security Area WG 
Subject: Re: [saag] History and recollection
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 21 Dec 2007 14:33:54 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig238944BC0BEA15B32DB08170
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

RJ Atkinson wrote:
> (Rather than boring folks here with a point-by-point response,
> I'll just say that in the unlikely event anyone on this list
> really cares about any of this historical discussion, then
> I'm happy to chat about it off list -- where it won't bother
> the vast majority of folks on this list who don't care either way. :-)

If that's what either of you prefer, may I recommend:

http://www.postel.org/internet-history.htm

I'd be glad to have you both cross-post your previous posts here to that
list, if you like as well.

Thanks,

Joe (as list admin of internet-history@postel.org)


--------------enig238944BC0BEA15B32DB08170
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHa86WE5f5cImnZrsRAo6EAKDGkEh9qam4ygr/PY8HlUSu6FCtYQCfblJg
rz9tyZ5TzBhI5IRML1JqNn8=
=ATd5
-----END PGP SIGNATURE-----

--------------enig238944BC0BEA15B32DB08170--

From smb@cs.columbia.edu Fri Dec 21 12:38:38 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBLHcc5U020788
	for ; Fri, 21 Dec 2007 12:38:38 -0500
Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBLHcRGK022325
	for ; Fri, 21 Dec 2007 12:38:27 -0500 (EST)
Received: from machshav.com (machshav.com [198.180.150.44])
	by mit.edu (Spam Firewall) with ESMTP id 752D368A820
	for ; Fri, 21 Dec 2007 12:38:23 -0500 (EST)
Received: by machshav.com (Postfix, from userid 512)
	id CE5B7619; Fri, 21 Dec 2007 17:38:22 +0000 (GMT)
Received: from berkshire.machshav.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP id 11A785B3;
	Fri, 21 Dec 2007 17:38:22 +0000 (GMT)
Received: from cs.columbia.edu (localhost [127.0.0.1])
	by berkshire.machshav.com (Postfix) with ESMTP id A017D7661BF;
	Fri, 21 Dec 2007 12:38:20 -0500 (EST)
Date: Fri, 21 Dec 2007 12:38:20 -0500
From: "Steven M. Bellovin" 
To: RJ Atkinson 
Message-ID: <20071221123820.24bc181f@cs.columbia.edu>
In-Reply-To: <2411C3BD-B437-406F-A81F-3282CF219A55@extremenetworks.com>
References: <736D9406-8066-4743-8E6F-3A0EE18765F6@extremenetworks.com>
	
	<1BE837E8-90B9-40CA-B4E8-C182B268DD25@extremenetworks.com>
	
	<2411C3BD-B437-406F-A81F-3282CF219A55@extremenetworks.com>
Organization: Columbia University
X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.0; i386--netbsdelf)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.13
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: IETF Security Area WG 
Subject: Re: [saag] History and recollection
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 21 Dec 2007 17:38:39 -0000

On Fri, 21 Dec 2007 08:16:13 -0500
RJ Atkinson  wrote:

> 
> It will surprise no one that I disagree with Steve's note.
> 
> (Rather than boring folks here with a point-by-point response,
> I'll just say that in the unlikely event anyone on this list
> really cares about any of this historical discussion, then
> I'm happy to chat about it off list -- where it won't bother
> the vast majority of folks on this list who don't care either way. :-)
> 
> Anyway, this excursion into history has reminded me about
> Steve Bellovin's paper in ACM Computer Communications Review
> (ACM CCR) from just about 20 years ago:
> 	"Security Problems in the TCP/IP Protocol Suite"
> 	ACM CCR, Volume 19, Issue 2  (April 1989), Pages 32 - 48

http://www.cs.columbia.edu/~smb/papers/ipext.pdf if you care.
> 
> I'd encourage everyone to read that paper, and also to be fair,
> to also read Steve Kent's rebuttal paper, which was published
> not long afterwards:
> 	"Comments on 'Security Problems in the TCP/IP Protocol Suite'"
> 	ACM CCR, Volume 19, Issue 3 (July 1989), Pages 10-19
> 
> And then mull over in your own heads whether this community
> has made very much headway in the intervening two decades,
> which risk reduction methods are deployed now that were
> not deployed then, and which areas seem ripe for new effort.
> 
Also see http://www.cs.columbia.edu/~smb/papers/acsac-ipext.pdf -- my
own retrospective look at my paper.  It's an annotated version of the
original.


		--Steve Bellovin, http://www.cs.columbia.edu/~smb

From kent@bbn.com Fri Dec 21 12:56:57 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBLHuvON025465
	for ; Fri, 21 Dec 2007 12:56:57 -0500
Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBLHuksP022642
	for ; Fri, 21 Dec 2007 12:56:47 -0500 (EST)
Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81])
	by mit.edu (Spam Firewall) with ESMTP id 4F693434502
	for ; Fri, 21 Dec 2007 12:56:23 -0500 (EST)
Received: from dhcp89-089-071.bbn.com ([128.89.89.71])
	by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from )
	id 1J5m6g-0003Lw-4f; Fri, 21 Dec 2007 12:56:22 -0500
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <2411C3BD-B437-406F-A81F-3282CF219A55@extremenetworks.com>
References: <736D9406-8066-4743-8E6F-3A0EE18765F6@extremenetworks.com>
	
	<1BE837E8-90B9-40CA-B4E8-C182B268DD25@extremenetworks.com>
	
	<2411C3BD-B437-406F-A81F-3282CF219A55@extremenetworks.com>
Date: Fri, 21 Dec 2007 09:39:46 -0500
To: RJ Atkinson 
From: Stephen Kent 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.12
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: IETF Security Area WG 
Subject: Re: [saag] History and recollection
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 21 Dec 2007 17:56:57 -0000

And if folks want to read the first published papers on how to apply 
crypto mechanisms to transport protocols, feel free to look at the 
paper I co-authored in 1982: 
http://www.cs.jhu.edu/~rubin/courses/sp03/papers/voydock.kent.pdf

If anything, this illustrates what I said, i.e., the hard part is not 
developing security mechanisms to apply to packets; it is developing 
the rest of the management infrastructure to make use of them.


Srece

From rja@extremenetworks.com Fri Dec 21 17:02:16 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBLM2Gqq032033
	for ; Fri, 21 Dec 2007 17:02:16 -0500
Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBLM25U1007772
	for ; Fri, 21 Dec 2007 17:02:05 -0500 (EST)
Received: from eastrmmtao103.cox.net (eastrmmtao103.cox.net [68.230.240.9])
	by mit.edu (Spam Firewall) with ESMTP id D2A2068E5D6
	for ; Fri, 21 Dec 2007 17:02:03 -0500 (EST)
Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao103.cox.net
	(InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id
	<20071221220203.QAMW24467.eastrmmtao103.cox.net@eastrmimpo02.cox.net>
	for ; Fri, 21 Dec 2007 17:02:03 -0500
Received: from [10.30.20.71] ([68.10.115.26])
	by eastrmimpo02.cox.net with bizsmtp
	id Ta1c1Y0030aEP1Q0000000; Fri, 21 Dec 2007 17:01:36 -0500
Message-Id: 
From: RJ Atkinson 
To: IETF Security Area WG 
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Date: Fri, 21 Dec 2007 17:02:02 -0500
X-Mailer: Apple Mail (2.915)
X-Spam-Score: 0.01
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] An aside on algorithms & modes
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 21 Dec 2007 22:02:16 -0000


	Part of my job involves travelling around and talking
with various users (ISPs, enterprises, academia, and others).
I spend a fair amount of time doing this on several continents
each year.

	In the course of my travels this decade I've been
hearing a pretty clear, and growing, trend from a wide range
of users that favours use of cryptographic algorithms & modes
that are acceptable to (US) NIST under the FIPS-140 rules.

	Prior to 2000, virtually all of the requests for use
of FIPS-140 compliant algorithms & modes came from the US
geographically, and specifically from either the US Government
or closely related organisations.

	This decade many global financial institutions (e.g. banks,
insurance firms, credit unions, and so forth) have said that their
commercial (re-)insurers are pressuring them to deploy only FIPS-140
compliant algorithms & modes.

	In a growing number of cases, there is even pressure from
insurers onto major commercial firms, particularly financial firms,
to use only equipment (including ordinary routers and switches,
not just "security appliances") that actually has obtained
a FIPS-140 approval for the cryptographic module inside.

	Further, a number of governments other than the US
government have declared that implementations using cryptographic
modules that have been approved under FIPS-140 are also acceptable
for deployment within their country or government or both.
The number of countries in this group appears to be growing,
and seems visibly larger now than 8 years ago.

	In turn, all of this creates clear user-demand pressures
on implementers (both for open source implementations and for
commercial products) to implement in a manner mindful of
the FIPS-140 requirements, including the basic step of using
algorithms and modes acceptable under FIPS-140.[1]

	So while I remain a believer in algorithm independent
protocol design, I also think that there are good solid user,
deployment, and business reasons why at least one algorithm/mode
combination supported in any new cryptographically-related protocol
would be a FIPS-140 compliant algorithm and mode.  This in no way
suggests that ought be the only implementation or deployment
option, merely that there ought to be a FIPS-compliant option
available that is openly specified.

	Also, personally, I don't have any opinion about any
particular algorithm or mode, not being a mathematician.
I do believe in listening to the users when they have inputs,
as many seem to have on this narrow topic.

Yours,

Ran Atkinson
rja@extremenetworks.com

[1] I was not involved in the IEEE 802.11i wireless security
efforts, but I note that it appears to be possible to implement
an interoperable subset of 802.11i in an entirely FIPS-140
compliant manner.  I doubt this is an accidental result from
the IEEE's 802.11i efforts.  Someone directly involved in the
IEEE's 802.11i work might be able to correct me on this guess.



From smb@cs.columbia.edu Fri Dec 21 20:38:46 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBM1ckRA029602
	for ; Fri, 21 Dec 2007 20:38:46 -0500
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBM1cYL8016593
	for ; Fri, 21 Dec 2007 20:38:34 -0500 (EST)
Received: from machshav.com (machshav.com [198.180.150.44])
	by mit.edu (Spam Firewall) with ESMTP id CCDC1C7945B
	for ; Fri, 21 Dec 2007 20:38:10 -0500 (EST)
Received: by machshav.com (Postfix, from userid 512)
	id 75C925A6; Sat, 22 Dec 2007 01:38:10 +0000 (GMT)
Received: from berkshire.machshav.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP id 21FF556D;
	Sat, 22 Dec 2007 01:38:10 +0000 (GMT)
Received: from cs.columbia.edu (localhost [127.0.0.1])
	by berkshire.machshav.com (Postfix) with ESMTP id 356287661CE;
	Fri, 21 Dec 2007 20:38:08 -0500 (EST)
Date: Fri, 21 Dec 2007 20:38:08 -0500
From: "Steven M. Bellovin" 
To: RJ Atkinson 
Message-ID: <20071221203808.5ada4602@cs.columbia.edu>
In-Reply-To: 
References: 
Organization: Columbia University
X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.0; i386--netbsdelf)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.13
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: IETF Security Area WG 
Subject: Re: [saag] An aside on algorithms & modes
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sat, 22 Dec 2007 01:38:46 -0000

On Fri, 21 Dec 2007 17:02:02 -0500
RJ Atkinson  wrote:
 
> 	In the course of my travels this decade I've been
> hearing a pretty clear, and growing, trend from a wide range
> of users that favours use of cryptographic algorithms & modes
> that are acceptable to (US) NIST under the FIPS-140 rules.

I'm not surprised.  People are realizing that there's a lot of subtlety
in the design of such things, and the AES competition reassured many
people that the US government wasn't trying to create back doors.  I
wonder if the possibility of a back door in a NIST-approved PRNG will
change that: http://www.schneier.com/essay-198.html

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

From rja@extremenetworks.com Sat Dec 22 08:19:18 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBMDJI5J023799
	for ; Sat, 22 Dec 2007 08:19:18 -0500
Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBMDJ7gH000741
	for ; Sat, 22 Dec 2007 08:19:08 -0500 (EST)
Received: from eastrmmtao107.cox.net (eastrmmtao107.cox.net [68.230.240.59])
	by mit.edu (Spam Firewall) with ESMTP id F1C9868D0E7
	for ; Sat, 22 Dec 2007 08:19:06 -0500 (EST)
Received: from eastrmimpo03.cox.net ([68.1.16.126]) by eastrmmtao107.cox.net
	(InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP
	id <20071222131905.WAJQ8815.eastrmmtao107.cox.net@eastrmimpo03.cox.net>;
	Sat, 22 Dec 2007 08:19:05 -0500
Received: from [10.30.20.71] ([68.10.115.26])
	by eastrmimpo03.cox.net with bizsmtp
	id Tp9g1Y0070aEP1Q0000000; Sat, 22 Dec 2007 08:09:41 -0500
Message-Id: <0B1222E2-2EF7-4E4F-8ABA-926CBA3F562B@extremenetworks.com>
From: RJ Atkinson 
To: "Steven M. Bellovin" 
In-Reply-To: <20071221203808.5ada4602@cs.columbia.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Date: Sat, 22 Dec 2007 08:19:05 -0500
References: 
	<20071221203808.5ada4602@cs.columbia.edu>
X-Mailer: Apple Mail (2.915)
X-Spam-Score: 3.5
X-Spam-Level: *** (3.5)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: IETF Security Area WG 
Subject: Re: [saag] An aside on algorithms & modes
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sat, 22 Dec 2007 13:19:18 -0000


On  21 Dec 2007, at 20:38, Steven M. Bellovin wrote:
>  People are realizing that there's a lot of subtlety
> in the design of such things, and the AES competition reassured many
> people that the US government wasn't trying to create back doors.

One might imagine that the published Biham-Shamir results on
differential cryptanalysis and the design of the DES S-boxes
might have also helped make some folks more comfortable.

Ran


From sshen@huawei.com Fri Dec 28 02:00:48 2007
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBS70mtl016709
	for ; Fri, 28 Dec 2007 02:00:48 -0500
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBS70axM009089
	for ; Fri, 28 Dec 2007 02:00:37 -0500 (EST)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [61.144.161.55])
	by mit.edu (Spam Firewall) with ESMTP id BA945EDEBD0
	for ; Fri, 28 Dec 2007 02:00:08 -0500 (EST)
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0JTQ007I5ZG5TN@szxga03-in.huawei.com> for
	saag@mit.edu; Fri, 28 Dec 2007 15:00:05 +0800 (CST)
Received: from huawei.com ([172.24.1.18])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0JTQ00BEBZG4EQ@szxga03-in.huawei.com> for
	saag@mit.edu; Fri, 28 Dec 2007 15:00:05 +0800 (CST)
Received: from s102542 ([10.111.12.53])
	by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTPA id <0JTQ00D4SZFZOD@szxml03-in.huawei.com> for
	saag@mit.edu; Fri, 28 Dec 2007 15:00:04 +0800 (CST)
Date: Fri, 28 Dec 2007 15:00:00 +0800
From: Sean Shuo Shen 
In-reply-to: 
To: "'mcgrew'" , "'Brian Weis'" 
Message-id: <000901c8491f$43da4150$350c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AchDIAo/SQgSTa8TEdyWUgAUUQnMFgF/NZAg
X-Spam-Score: 0.14
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, cfrg@ietf.org
Subject: Re: [saag] [Cfrg] Re:  TCP-AO MAC algorithms
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 28 Dec 2007 07:00:48 -0000

Dear David,
I read the draft-irtf-cfrg-fast-mac-requirements and believe the draft gives
good security and efficiency description for TCP AO MAC. I have a few
thoughts according the following issues in the draft:

1. interface:
I agree that MAC interface without a nonce may make implementation easier.
But nonce may not expand the size of MAC because it can be generated by both
sides of a TCP connection. For example, the nonce in UMAC can simply be a
counter from 0 to a certain upper bound. Even if nonce requires randomness,
a PRFed value of a counter or sequence number (I remember Joe Touch
mentioned in Vancouver that key generation of TCP AO should not use any
bytes of TCP packets, but I think nonce should be ok.) can provide
randomness. Noticing the good performance of MACs like UMAC, maybe we should
keep the door open to MACs with nonce.

2. incremental MAC
I understand the use of incrementality for virus protection but can not see
the benefit of incrementality for TCP AO, at least in the BGP situation. In
tcpm-tcp-auth-op, the MAC is computed over "TCP pseudo header + TCP header +
TCP data", the first two parts (totally about 32 bytes or more for ipv4, 60
bytes or more for ipv6) are fixed for a connection, while the length of BGP
part (that part that will change) will be ranged from 19 to 4096 bytes. Thus
difference of packets is not small. Please let me know if there are good
ways to use incrementality in BGP or other scenarios.

Thank you and happy new year to all!
Regards,

Sean

-----Original Message-----
From: mcgrew [mailto:mcgrew@cisco.com] 
Sent: Thursday, December 20, 2007 11:50 PM
To: Brian Weis
Cc: saag@mit.edu; cfrg@ietf.org
Subject: [Cfrg] Re: [saag] TCP-AO MAC algorithms

Hi Brian,

I've cross-posted to CFRG to tie the TCP Auth work in with
draft-irtf-cfrg-fast-mac-requirements draft.

On 12/18/07 4:23 PM, "Brian Weis"  wrote:

> Greetings,
> 
> The TCPM WG seeks advice from SAAG on which MACs to include as
> required MACs for the TCP Authentication Option (draft-ietf-tcpm-tcp-
> auth-opt-00). Two MACs with differing internal constructions are
> desired.

I assume that the reason for having two mandatory-to-implement MACs is to
ensure algorithm agility.

> 
> In my opinion, it is also important that MACs defined by an Internet
> standard as required to be implemented be based on NIST-approved
> algorithms and modes, and also be generally available in both
> software and cryptographic hardware.
> 
> The following two MACs are reasonable recommendations that taken
> together easily meet the above criteria: HMAC-SHA-1 and AES-CMAC. I
> propose that these be the algorithms provided to the TCPM WG.
> 
> Brian

Sounds like reasonable choices to me.

It would be good to have a MAC that performs exceptionally well in software,
along the lines of what we've targeted in
draft-irtf-cfrg-fast-mac-requirements, but if the choice of MACs has to be
made *today*, there may not be a suitable candidate that has been
sufficiently specified and/or reviewed.  I expect that MACs that will be
more suitable for use in TCP Authentication will be developed (candidates
include [1] and [2]).  I trust that there is a path for the adoption of new
MACs in TCP Auth.  

Probably the biggest open question is the length of the MAC.  The CMAC
specification states that lengths 64 bits and higher are acceptable, but
that smaller values "shall only be used in conjunction
with a careful analysis of the risks" [1].  It would be good to do this
analysis for TCP Auth, of course, but it is encouraging that AES-128-CMAC
could be used with a 64-bit tag and still meet the conformance goals that
you outlined. 

Best regards, 

David


[1] J. Black and M. Cochran, "MAC Reforgeability",
http://eprint.iacr.org/2006/095

[2] D.J. Bernstein, "Polynomial evaluation and message authentication",
http://cr.yp.to/antiforgery/pema-20071022.pdf

[3] M. Dworkin, NIST Special Publication 800-38B, "Recommendation for Block
Cipher Modes of Operation: The CMAC Mode for Authentication"
http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf

_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg



From touch@ISI.EDU Fri Dec 28 12:38:58 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id lBSHcw8p002353
	for ; Fri, 28 Dec 2007 12:38:58 -0500
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	lBSHcojQ009455
	for ; Fri, 28 Dec 2007 12:38:50 -0500 (EST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 8248FC945A6
	for ; Fri, 28 Dec 2007 12:38:26 -0500 (EST)
Received: from [192.168.1.44] (pool-71-106-88-149.lsanca.dsl-w.verizon.net
	[71.106.88.149])
	by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lBSHbOvP026194;
	Fri, 28 Dec 2007 09:37:26 -0800 (PST)
Message-ID: <4775344B.7020105@isi.edu>
Date: Fri, 28 Dec 2007 09:37:15 -0800
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Sean Shuo Shen 
References: <000901c8491f$43da4150$350c6f0a@china.huawei.com>
In-Reply-To: <000901c8491f$43da4150$350c6f0a@china.huawei.com>
X-Enigmail-Version: 0.95.5
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig3CDDC1EE4C2F7FD95EC4A6F5"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, 'mcgrew' , cfrg@ietf.org
Subject: Re: [saag] [Cfrg] Re:  TCP-AO MAC algorithms
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Fri, 28 Dec 2007 17:38:58 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3CDDC1EE4C2F7FD95EC4A6F5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi, Sean,

Sean Shuo Shen wrote:
> Dear David,
> I read the draft-irtf-cfrg-fast-mac-requirements and believe the draft =
gives
> good security and efficiency description for TCP AO MAC. I have a few
> thoughts according the following issues in the draft:
>=20
> 1. interface:
> I agree that MAC interface without a nonce may make implementation easi=
er.
> But nonce may not expand the size of MAC because it can be generated by=
 both
> sides of a TCP connection. For example, the nonce in UMAC can simply be=
 a
> counter from 0 to a certain upper bound. Even if nonce requires randomn=
ess,
> a PRFed value of a counter or sequence number (I remember Joe Touch
> mentioned in Vancouver that key generation of TCP AO should not use any=

> bytes of TCP packets, but I think nonce should be ok.) can provide
> randomness. Noticing the good performance of MACs like UMAC, maybe we s=
hould
> keep the door open to MACs with nonce.

The TCP fields must not be used as a nonce for the MAC; although they do
change, the ways they change are not ensured to be predictable (e.g.,
TCP can validly send overlapping segments). As such, a per-packet nonce
would need to be sent in the TCP option field, and there is insufficient
space to do that on a per-packet basis (which is why there is no such
field in TCP-AO).

> 2. incremental MAC
> I understand the use of incrementality for virus protection but can not=
 see
> the benefit of incrementality for TCP AO, at least in the BGP situation=
=2E In
> tcpm-tcp-auth-op, the MAC is computed over "TCP pseudo header + TCP hea=
der +
> TCP data", the first two parts (totally about 32 bytes or more for ipv4=
, 60
> bytes or more for ipv6) are fixed for a connection,=20

The TCP sequence number varies during a connection, but it can wrap
around. It's entirely possible to have two segments that have the same
sequence number at different times in a connection, however. This is why
we probably need to explicitly require that the connection key change
whenever the sequence number rolls over (through the ISN).

Joe


--------------enig3CDDC1EE4C2F7FD95EC4A6F5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHdTRRE5f5cImnZrsRAgWRAKDO/01w6Z4Xcw4BUFMk4s+YKUP/WACdESkM
/PUq2YigqkIqM9zLUFWduSE=
=RzJc
-----END PGP SIGNATURE-----

--------------enig3CDDC1EE4C2F7FD95EC4A6F5--

From ekr@networkresonance.com Mon Dec 31 21:06:29 2007
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m0126Txb025763
	for ; Mon, 31 Dec 2007 21:06:29 -0500
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
	m0126KLa022466
	for ; Mon, 31 Dec 2007 21:06:20 -0500 (EST)
Received: from romeo.rtfm.com (unknown [74.95.2.173])
	by mit.edu (Spam Firewall) with ESMTP id 05CCEC8E8FE
	for ; Mon, 31 Dec 2007 21:05:59 -0500 (EST)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1])
	by romeo.rtfm.com (Postfix) with ESMTP id CBFAE5081A;
	Mon, 31 Dec 2007 18:06:27 -0800 (PST)
Date: Mon, 31 Dec 2007 18:06:27 -0800
From: Eric Rescorla 
To: Brian Weis 
In-Reply-To: <98FA6BE8-0825-41F6-8DAA-1A5706D974A9@cisco.com>
References: <98FA6BE8-0825-41F6-8DAA-1A5706D974A9@cisco.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20080101020627.CBFAE5081A@romeo.rtfm.com>
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu
Subject: Re: [saag] TCP-AO MAC algorithms
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Tue, 01 Jan 2008 02:06:29 -0000

At Tue, 18 Dec 2007 16:23:51 -0800,
Brian Weis wrote:
> 
> Greetings,
> 
> The TCPM WG seeks advice from SAAG on which MACs to include as  
> required MACs for the TCP Authentication Option (draft-ietf-tcpm-tcp- 
> auth-opt-00). 

I would note that TLS has one MTI MAC (HMAC-SHA1) and based on RFC
4835, so does ESP/AH (HMAC-SHA1-96). What's the rationale for why
TCP-AO should have stricter MTI requirements than we have for
our dedicated security protocols?


> Two MACs with differing internal constructions are  
> desired.

I don't understand this either. Most modern MACs are constructed from
two pieces:

- An underlying cryptographic function
- A composition operation

Thus, for instance, HMAC-SHA1 is constructed by using the HMAC
composition operation with SHA-1. In general, the security properties
of the composition operations are well understood (often with some
kind of reduction proof) where the security properties of the
underlying function are unproven. So, while it might make sense
to have two different base cryptographic functions (e.g.,
SHA-1 and SHA-256), it's not at all clear that it's of that
much value to have two different constructions.

-Ekr