From hartmans-ietf at mit.edu Thu Jan 3 05:48:03 2008 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Thu, 03 Jan 2008 08:48:03 -0500 Subject: [anonsec] Please submit a new draft with the minor corrections I asked for Message-ID: Authors, if a new version of the core draft can be submitted with the two corrections I requested then I can place it on the agenda of the next IESG telechat. It would need to happen today or tomorrow. If it is not on next week's telechat then it may end up waiting until I return from paternity leave. From julien.IETF at laposte.net Thu Jan 3 08:59:17 2008 From: julien.IETF at laposte.net (Julien Laganier) Date: Thu, 3 Jan 2008 17:59:17 +0100 Subject: [anonsec] LC: draft-ietf-btns-core (Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec) to Proposed Standard In-Reply-To: References: Message-ID: <200801031759.19353.julien.IETF@laposte.net> That note was sent to the list but dropped. Here it comes. --julien ---------------------------------------------------------------- The IESG has received a request from the Better-Than-Nothing Security WG (btns) to consider the following document: - 'Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec ' ? ? as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. ?Please send substantive comments to the ietf at ietf.org mailing lists by 2008-01-09. Exceptionally, comments may be sent to iesg at ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-btns-core-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14291&rfc_flag=0 From julien.IETF at laposte.net Thu Jan 3 10:11:28 2008 From: julien.IETF at laposte.net (Julien Laganier) Date: Thu, 3 Jan 2008 19:11:28 +0100 Subject: [anonsec] Please submit a new draft with the minor corrections I asked for In-Reply-To: References: Message-ID: <200801031911.28708.julien.IETF@laposte.net> On Thursday 03 January 2008, Sam Hartman wrote: > Authors, if a new version of the core draft can be submitted with the > two corrections I requested then I can place it on the agenda of the > next IESG telechat. It would need to happen today or tomorrow. If > it is not on next week's telechat then it may end up waiting until I > return from paternity leave. I contacted Nico and he said he will try to meet the deadline. Let's wait and see. --julien From Nicolas.Williams at sun.com Thu Jan 3 21:51:41 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 3 Jan 2008 23:51:41 -0600 Subject: [anonsec] AD review comments on draft-ietf-btns-core In-Reply-To: References: Message-ID: <20080104055141.GK22538@Sun.COM> On Thu, Dec 20, 2007 at 03:25:07PM -0500, Sam Hartman wrote: > > > Hi. I've sent the core document to last call. It was not as readable > as I would like. If you get a bunch of comments back from people who > do not understand you probably should take a style and readability > pass. > > I have two changes I'd like te request as last call comments myself. > > First, when you require bare RSA cert payloads, please reference a > specific section of the IKE V2 spec for a definition of this. Also, OK (RFC4306, section 3.6). > how can BTNS work with DSA if nodes are required to include RSA > payloads? A bare DSA payload would have to be defined. We could change the language to require the use of a bare public key payload and point out that currently there is only a bare RSA key payload. > Please replace the statement in section 4.2 that leap of faith is > being handled by BTNS with a statement that it is an item for future > work. This is already done in -05. I'll make the other changes and post -06. From Internet-Drafts at ietf.org Thu Jan 3 22:10:01 2008 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Fri, 04 Jan 2008 01:10:01 -0500 Subject: [anonsec] I-D Action:draft-ietf-btns-core-06.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-btns-core-06.txt -------------- next part -------------- From kent at bbn.com Mon Jan 7 12:18:09 2008 From: kent at bbn.com (Stephen Kent) Date: Mon, 7 Jan 2008 15:18:09 -0500 Subject: [anonsec] review comments on draft-ietf-btns-prob-and-applic-06.txt Message-ID: I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is not well structured, i.e., in many places it rambles. The document has more of an architectural framework feel to it than the title suggests. It spends too much time saying how BTNS will work, rather than focusing on the nominal topic of the document, i.e., the problem to be solved and the anticipated applicability of the solution. It never provides a clear, concise characterization of the problem to be solved, and why the functionality offered by BTNS-IPsec is the preferred way to solve the problem. (I believe this problem arises because, from the beginning, there were been multiple, independent motivations for the BTNS work and the WG never reconciled them.) There seem to be two types of problems/solutions that motivate BTNS, both starting with the assumption that use of IPsec is the goal (an assumption that needs to be justified itself, as noted below). The solutions are presented before examples of the problems, which does not help matters, but I'll characterize the problems in terms of the solutions, in keeping with the style of the I-D: - creating IPsec/IKE SAs w/o authentication, for use in contexts where it is perceived that IPsec is not used because the effort to deploy an authentication infrastructure compatible with IKE is too great a burden AND the confidentiality and integrity offered by unauthenticated SAs is "better than nothing." Since IKE supports use of passwords, this presumes that the threshold for what constitutes too great a burden is pretty low, but this is not explicitly stated. Also, the BGP use case was disputed, when this work started, and has proven to be a bad example given continuing developments, but it persists in the document. There is also a not-well-articulated argument that TLS/DTLS is not a suitable alternative, presumably because those protocols do not protect the transport protocol per se. It's true that IPsec does a better job here, but the need for using it (vs. TLS) in such circumstances does not seem to be widely accepted. - creating IPsec/IKE SAs w/o authentication, for use in contexts where an application will perform its own authentication, but wants the layer 3 confidentiality, integrity and continuity of authentication offered by ESP. Here a critical part of the argument is that these applications cannot use the authentication provided by IKE, but the explanation for this is poor. For example there is no recognition of the use of EAP authentication methods with IKE. The text also does not address the possibility that a suitable API could allow an application to acquire and track the ID asserted during an IKE exchange, in lieu of the unauthenticated SA approach that is being motivated. The document fails to introduce important concepts like continuity of authentication and channel binding near the beginning. If leap of faith authentication is important enough to be included, then it too needs to be described early in the document. The document never provides a clear, concise definition of channel binding, and the definition of LoF is mostly by example. The failure to define these terms early in the document leads to ambiguity and confusion in the problem statement sections. Several of the examples provided in the applicability section do not seem congruent with security efforts in the relevant areas. I mentioned the BGP connection example above, which is even less relevant today, given the ongoing TCPM work on TCP-AO. There is also an assertion that BTNS-IPsec is a good way to protect VoIP media, yet the RTP folks never believed that and the RAI area has recently reaffirmed its commitment to use of SRTP for this purpose, with DTLS for key management. Another questionable example is the suggestion to use both BTNS-IPsec and TLS to protect client/server connections against TCP RST attacks. This is theoretically a valid use of BTNS-IPsec, but there is no indication that web server operators believe this is a "necessary" capability, as the I-D argues. The security considerations section is too long, mostly because much of the material should be earlier, e.g., the CB discussion. One might also move the rekeying attack example (which I expanded to be more accurate) to the CB document, and just reference the notion here. I am unable to attach a copy of the I-D, with MS Word charge tracking for detailed comments and edits, because it is too big for these lists. A copy of that file was sent to tge cognizant Security AD, WG chairs, and authors. Steve From Black_David at emc.com Tue Jan 8 08:22:54 2008 From: Black_David at emc.com (Black_David@emc.com) Date: Tue, 8 Jan 2008 11:22:54 -0500 Subject: [anonsec] Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt) Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> This message is an attempt to kill two review "birds" with one email "stone" - I meant to review the connection latching draft some time ago, and in addition, this is a transport directorate review of the connection latching draft. For the latter purpose, the following paragraph applies: - I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The result is a mix of transport and security comments in this email - the transport ADs should pay particular attention to the service-orientation and NAT comments. In general, this is a good draft, and I think it should go forward. -- Service Orientation The introduction considerably undersells the architectural impact of this draft. IPsec architecture has been based on inclusion of a logical firewall. This results in the configuration of security services being somewhat disconnected from the higher level protocols and applications that benefit from those services by the use of the SPD to configure the logical firewall (see Sections 3 and 3.1 of RFC 4301). This disconnection has been an important feature of IPsec, as it has enabled consistent application of security policy to all traffic crossing an IPsec boundary (e.g., to/from a specific network node, to/from an otherwise unprotected [untrusted] network at a network node), but it has made use of IPsec by higher layer applications and protocols more difficult because application usage requests for IPsec have to be expressed in terms of a firewall-like configuration through an API of some form, and conflicts are possible. The connection latching draft is aimed at precisely this gap between effective application usage and the logical firewall architecture of IPsec; in essence, the draft is defining the functional service interface through which higher layer applications and protocols should be obtaining IPsec services for themselves instead of setting up SPD (and possibly PAD) entries directly. This change from logical firewall orientation to service orientation is (IMHO) an important step towards making IPsec effectively usable for protocols such as iSCSI and NFSv4, and should be explained in the Introduction of this draft. -- NATs p.5 says: o Implementations that provide such programming interfaces SHOULD make available to applications any available NAT-related information about the peer: whether it is behind a NAT and, if it is, the inner and outer tunnel addresses of the peer. Is that serious? I don't think inflicting NAT awareness on additional protocols and applications is a good idea unless it's absolutely necessary (i.e., protocol/app won't work through a NAT that it doesn't know about). In general, IPsec NAT traversal ought to work transparently with respect to connection latching, and (IMHO), this transparency should be the preferred approach whenever feasible. -- Key Manager/Key Management The draft talks about a key manager. It should state what functions the key manager is performing with respect to the IPsec architecture (RFC 4301). While IKEv2 would clearly be inside the key manager, where is responsibility for the SPD and PAD placed and/or how is that responsibility divided? While not exactly key management, how does connection latch state lifetime relate to the lifetime of the IKE_SA for the latched SA? This is the infamous "dangling SAs" issue applied to connection latch state. I think that connection latch state does not survive termination without replacement of the IKE_SA (e.g., key management entity containing IKE/IKEv2 implementation crashes), but ought to survive replacement of the IKE_SA. In any case, this topic needs to be covered. -- Nits idnits 2.05.03 found a bunch of nits, mostly in the references. tmp/draft-ietf-btns-connection-latching-04.txt: Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748: ------------------------------------------------------------------------ ---- No issues found here. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: ------------------------------------------------------------------------ ---- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to http://www.ietf.org/ID-Checklist.html: ------------------------------------------------------------------------ ---- No issues found here. Miscellaneous warnings: ------------------------------------------------------------------------ ---- == The copyright year in the IETF Trust Copyright Line does not match the current year Checking references for intended status: Proposed Standard ------------------------------------------------------------------------ ---- (See RFC 3967 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.bellovin-useipsec' is defined on line 632, but no explicit reference was found in the text == Unused Reference: 'RFC4322' is defined on line 642, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-btns-abstract-api' (No intended status found in state file of draft-ietf-btns-abstract-api) == Outdated reference: A later version (-06) exists of draft-ietf-btns-core-05 == Outdated reference: A later version (-06) exists of draft-ietf-btns-prob-and-applic-05 ** Downref: Normative reference to an Informational draft: draft-ietf-btns-prob-and-applic (ref. 'I-D.ietf-btns-prob-and-applic') ** Downref: Normative reference to an Informational RFC: RFC 2367 == Outdated reference: A later version (-07) exists of draft-bellovin-useipsec-06 == Outdated reference: draft-williams-on-channel-binding has been published as RFC 5056 Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david at emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From Nicolas.Williams at sun.com Tue Jan 8 13:18:47 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 8 Jan 2008 15:18:47 -0600 Subject: [anonsec] Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt) In-Reply-To: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> References: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> Message-ID: <20080108211846.GT22538@Sun.COM> On Tue, Jan 08, 2008 at 11:22:54AM -0500, Black_David at emc.com wrote: > This message is an attempt to kill two review "birds" with > one email "stone" - I meant to review the connection latching > draft some time ago, and in addition, this is a transport > directorate review of the connection latching draft. Thank you. > -- Service Orientation > > The introduction considerably undersells the architectural > impact of this draft. [...] I agree, ... > The connection latching draft is aimed at precisely this > gap between effective application usage and the logical > firewall architecture of IPsec; in essence, the draft is > defining the functional service interface through which > higher layer applications and protocols should be > obtaining IPsec services for themselves instead of setting > up SPD (and possibly PAD) entries directly. This change > from logical firewall orientation to service orientation is > (IMHO) an important step towards making IPsec effectively > usable for protocols such as iSCSI and NFSv4, and should > be explained in the Introduction of this draft. ... but connection latching is one of a multi-prong approach to closing that gap. The other main prong is IPsec APIs. A third, optional prong, is channel binding. I fear that to correct this undersell while the IPsec APIs documents are not complete might be to oversell the architectural impact of this document. Comments? > -- NATs > > p.5 says: > > o Implementations that provide such programming interfaces > SHOULD make available to applications any available > NAT-related information about the peer: whether it is > behind a NAT and, if it is, the inner and outer tunnel > addresses of the peer. > > Is that serious? I don't think inflicting NAT awareness on > additional protocols and applications is a good idea unless > it's absolutely necessary (i.e., protocol/app won't work through > a NAT that it doesn't know about). In general, IPsec NAT > traversal ought to work transparently with respect to > connection latching, and (IMHO), this transparency should > be the preferred approach whenever feasible. Well, does it hurt to have this? I suppose this could be a MAY, if implementors object (or it could be downgraded to MAY or removed altogether when in the progression to Standard). I don't feel too strongly about it, but I also don't feel too strongly about discouraging the use of NATs (face it: NATs are here to stay, at least in the IPv4 world). > -- Key Manager/Key Management > > The draft talks about a key manager. It should state what > functions the key manager is performing with respect to the > IPsec architecture (RFC 4301). While IKEv2 would clearly > be inside the key manager, where is responsibility for the > SPD and PAD placed and/or how is that responsibility divided? RFC4301 does not speak of a key manager, but does speak of key management -- see section 4.5. I'll clarify in the I-D, and here: the key manager is the part of the implementation that manages the SAD. The KE protocols (IKEv2, KINK, ...) are associated with the key manager, but what really matters here is the component of the system through which all SAD updates are done. > While not exactly key management, how does connection latch > state lifetime relate to the lifetime of the IKE_SA for the > latched SA? It doesn't. > This is the infamous "dangling SAs" issue > applied to connection latch state. What is this infamous issue? > I think that connection > latch state does not survive termination without replacement > of the IKE_SA (e.g., key management entity containing > IKE/IKEv2 implementation crashes), but ought to survive > replacement of the IKE_SA. In any case, this topic needs to > be covered. It is absolutely desirable that connection latch state survive IKE_SA and even child SA expiration. The document does describe latch termination, but -05 will do so in much more detail. Basically a latch terminates when the ULP requests it (which may be when the application requests it, or when an RST is received protected by a suitable SA) and, in the normative model, whenever the key manager adds an SA to the SAD which conflicts with the latch. > -- Nits > > ---- > > == No 'Intended status' indicated for this document; assuming Proposed > Standard Thanks. I'll fix this. > == The copyright year in the IETF Trust Copyright Line does not match > the > current year It matches the year in which it was submitted. -05 will be submitted in 2008, so its IETF Trust Copyright notice will say "2008." > (See RFC 3967 for information about using normative references to > lower-maturity documents in RFCs) > > == Unused Reference: 'I-D.bellovin-useipsec' is defined on line 632, > but no > explicit reference was found in the text If I correct the "undersell" then there will definitely be a mention of bellovin-useipsec! > == Unused Reference: 'RFC4322' is defined on line 642, but no explicit > reference was found in the text Suggestions? > -- Possible downref: Normative reference to a draft: ref. > 'I-D.ietf-btns-abstract-api' (No intended status found in state > file of > draft-ietf-btns-abstract-api) That should probably be informative, yes. > == Outdated reference: A later version (-06) exists of > draft-ietf-btns-core-05 > > == Outdated reference: A later version (-06) exists of > draft-ietf-btns-prob-and-applic-05 > > ** Downref: Normative reference to an Informational draft: > draft-ietf-btns-prob-and-applic (ref. > 'I-D.ietf-btns-prob-and-applic') > > ** Downref: Normative reference to an Informational RFC: RFC 2367 > > == Outdated reference: A later version (-07) exists of > draft-bellovin-useipsec-06 > > == Outdated reference: draft-williams-on-channel-binding has been > published > as RFC 5056 Will fix. Thanks! Nico -- From Black_David at emc.com Tue Jan 8 14:31:39 2008 From: Black_David at emc.com (Black_David@emc.com) Date: Tue, 8 Jan 2008 17:31:39 -0500 Subject: [anonsec] Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt) In-Reply-To: <20080108211846.GT22538@Sun.COM> References: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> <20080108211846.GT22538@Sun.COM> Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91085EB3@CORPUSMX20A.corp.emc.com> Nico, Some quick responses: > > -- Service Orientation > > > > The introduction considerably undersells the architectural > > impact of this draft. [...] > > I agree, ... > > ... but connection latching is one of a multi-prong approach to closing > that gap. The other main prong is IPsec APIs. A third, optional prong, > is channel binding. Describing this overall multi-prong structure and connection latching's role in it would be a "good thing" to do in the introduction and should position the connection latching draft correctly. > > -- NATs > > > > p.5 says: > > > > o Implementations that provide such programming interfaces > > SHOULD make available to applications any available > > NAT-related information about the peer: whether it is > > behind a NAT and, if it is, the inner and outer tunnel > > addresses of the peer. > > > > Is that serious? I don't think inflicting NAT awareness on > > additional protocols and applications is a good idea unless > > it's absolutely necessary (i.e., protocol/app won't work through > > a NAT that it doesn't know about). In general, IPsec NAT > > traversal ought to work transparently with respect to > > connection latching, and (IMHO), this transparency should > > be the preferred approach whenever feasible. > > Well, does it hurt to have this? I suppose this could be a MAY, if > implementors object (or it could be downgraded to MAY or removed > altogether when in the progression to Standard). > > I don't feel too strongly about it, but I also don't feel too strongly > about discouraging the use of NATs (face it: NATs are here to stay, at > least in the IPv4 world). This isn't about discouraging use of NATs; I completely agree that NATs are a fact of life for IPv4. This is about avoiding encouragement of NAT-specific code in protocols and applications that don't need it (i.e., work just fine with IPsec NAT traversal). Think of the goal as "damage containment" - it does hurt to encourage unnecessary attempts to deal with NATs. It may be ok to have the interface if the interface adds value to what apps already have to do to cope with NATs, but there should be a rationale for the added value. > > -- Key Manager/Key Management [... snip ...] > > This is the infamous "dangling SAs" issue > > applied to connection latch state. > > What is this infamous issue? Does a CHILD_SA survive termination of the IKE_SA used to create the CHILD_SA? [... snip ...] > It is absolutely desirable that connection latch state survive IKE_SA > and even child SA expiration. > > The document does describe latch termination, but -05 will do > so in much more detail. > > Basically a latch terminates when the ULP requests it (which may be when > the application requests it, or when an RST is received protected by a > suitable SA) and, in the normative model, whenever the key manager adds > an SA to the SAD which conflicts with the latch. I think that's ok, just write it up in -05, and explain why the disconnection from the IKE_SA lifetime/fate is important. I was making intelligent guesses in the absence of detail, and I guessed wrong :-). Thanks, --David > -----Original Message----- > From: Nicolas Williams [mailto:Nicolas.Williams at sun.com] > Sent: Tuesday, January 08, 2008 4:19 PM > To: Black, David > Cc: anonsec at postel.org; tsv-dir at ietf.org > Subject: Re: [anonsec] Connection Latching draft review > (draft-ietf-btns-connection-latching-04.txt) > > On Tue, Jan 08, 2008 at 11:22:54AM -0500, Black_David at emc.com wrote: > > This message is an attempt to kill two review "birds" with > > one email "stone" - I meant to review the connection latching > > draft some time ago, and in addition, this is a transport > > directorate review of the connection latching draft. > > Thank you. > > > -- Service Orientation > > > > The introduction considerably undersells the architectural > > impact of this draft. [...] > > I agree, ... > > > The connection latching draft is aimed at precisely this > > gap between effective application usage and the logical > > firewall architecture of IPsec; in essence, the draft is > > defining the functional service interface through which > > higher layer applications and protocols should be > > obtaining IPsec services for themselves instead of setting > > up SPD (and possibly PAD) entries directly. This change > > from logical firewall orientation to service orientation is > > (IMHO) an important step towards making IPsec effectively > > usable for protocols such as iSCSI and NFSv4, and should > > be explained in the Introduction of this draft. > > ... but connection latching is one of a multi-prong approach > to closing > that gap. The other main prong is IPsec APIs. A third, > optional prong, > is channel binding. > > I fear that to correct this undersell while the IPsec APIs > documents are > not complete might be to oversell the architectural impact of this > document. > > Comments? > > > -- NATs > > > > p.5 says: > > > > o Implementations that provide such programming interfaces > > SHOULD make available to applications any available > > NAT-related information about the peer: whether it is > > behind a NAT and, if it is, the inner and outer tunnel > > addresses of the peer. > > > > Is that serious? I don't think inflicting NAT awareness on > > additional protocols and applications is a good idea unless > > it's absolutely necessary (i.e., protocol/app won't work through > > a NAT that it doesn't know about). In general, IPsec NAT > > traversal ought to work transparently with respect to > > connection latching, and (IMHO), this transparency should > > be the preferred approach whenever feasible. > > Well, does it hurt to have this? I suppose this could be a MAY, if > implementors object (or it could be downgraded to MAY or removed > altogether when in the progression to Standard). > > I don't feel too strongly about it, but I also don't feel too strongly > about discouraging the use of NATs (face it: NATs are here to stay, at > least in the IPv4 world). > > > -- Key Manager/Key Management > > > > The draft talks about a key manager. It should state what > > functions the key manager is performing with respect to the > > IPsec architecture (RFC 4301). While IKEv2 would clearly > > be inside the key manager, where is responsibility for the > > SPD and PAD placed and/or how is that responsibility divided? > > RFC4301 does not speak of a key manager, but does speak of key > management -- see section 4.5. I'll clarify in the I-D, and here: the > key manager is the part of the implementation that manages > the SAD. The > KE protocols (IKEv2, KINK, ...) are associated with the key > manager, but > what really matters here is the component of the system through which > all SAD updates are done. > > > While not exactly key management, how does connection latch > > state lifetime relate to the lifetime of the IKE_SA for the > > latched SA? > > It doesn't. > > > This is the infamous "dangling SAs" issue > > applied to connection latch state. > > What is this infamous issue? > > > I think that connection > > latch state does not survive termination without replacement > > of the IKE_SA (e.g., key management entity containing > > IKE/IKEv2 implementation crashes), but ought to survive > > replacement of the IKE_SA. In any case, this topic needs to > > be covered. > > It is absolutely desirable that connection latch state survive IKE_SA > and even child SA expiration. > > The document does describe latch termination, but -05 will do > so in much > more detail. > > Basically a latch terminates when the ULP requests it (which > may be when > the application requests it, or when an RST is received protected by a > suitable SA) and, in the normative model, whenever the key > manager adds > an SA to the SAD which conflicts with the latch. > > > -- Nits > > > > ---- > > > > == No 'Intended status' indicated for this document; > assuming Proposed > > Standard > > Thanks. I'll fix this. > > > == The copyright year in the IETF Trust Copyright Line > does not match > > the > > current year > > It matches the year in which it was submitted. -05 will be > submitted in > 2008, so its IETF Trust Copyright notice will say "2008." > > > (See RFC 3967 for information about using normative > references to > > lower-maturity documents in RFCs) > > > > == Unused Reference: 'I-D.bellovin-useipsec' is defined > on line 632, > > but no > > explicit reference was found in the text > > If I correct the "undersell" then there will definitely be a > mention of > bellovin-useipsec! > > > == Unused Reference: 'RFC4322' is defined on line 642, > but no explicit > > reference was found in the text > > Suggestions? > > > -- Possible downref: Normative reference to a draft: ref. > > 'I-D.ietf-btns-abstract-api' (No intended status > found in state > > file of > > draft-ietf-btns-abstract-api) > > That should probably be informative, yes. > > > == Outdated reference: A later version (-06) exists of > > draft-ietf-btns-core-05 > > > > == Outdated reference: A later version (-06) exists of > > draft-ietf-btns-prob-and-applic-05 > > > > ** Downref: Normative reference to an Informational draft: > > draft-ietf-btns-prob-and-applic (ref. > > 'I-D.ietf-btns-prob-and-applic') > > > > ** Downref: Normative reference to an Informational RFC: RFC 2367 > > > > == Outdated reference: A later version (-07) exists of > > draft-bellovin-useipsec-06 > > > > == Outdated reference: draft-williams-on-channel-binding has been > > published > > as RFC 5056 > > Will fix. > > Thanks! > > Nico > -- > > From Nicolas.Williams at sun.com Tue Jan 8 14:52:08 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 8 Jan 2008 16:52:08 -0600 Subject: [anonsec] Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt) In-Reply-To: <8CC6CEAB44F131478D3A7B429ECACD91085EB3@CORPUSMX20A.corp.emc.com> References: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> <20080108211846.GT22538@Sun.COM> <8CC6CEAB44F131478D3A7B429ECACD91085EB3@CORPUSMX20A.corp.emc.com> Message-ID: <20080108225208.GW22538@Sun.COM> On Tue, Jan 08, 2008 at 05:31:39PM -0500, Black_David at emc.com wrote: > > > The introduction considerably undersells the architectural > > > impact of this draft. [...] > > > > I agree, ... > > > > ... but connection latching is one of a multi-prong approach to > closing > > that gap. The other main prong is IPsec APIs. A third, optional > prong, > > is channel binding. > > Describing this overall multi-prong structure and connection > latching's role in it would be a "good thing" to do in the > introduction and should position the connection latching draft > correctly. OK, I will do so. > > > -- NATs > > > > > > p.5 says: > > > > Well, does it hurt to have this? I suppose this could be a MAY, if > > implementors object (or it could be downgraded to MAY or removed > > altogether when in the progression to Standard). > > > > I don't feel too strongly about it, but I also don't feel too strongly > > about discouraging the use of NATs (face it: NATs are here to stay, at > > least in the IPv4 world). > > This isn't about discouraging use of NATs; I completely agree > that NATs are a fact of life for IPv4. This is about avoiding > encouragement of NAT-specific code in protocols and applications > that don't need it (i.e., work just fine with IPsec NAT traversal). I think this text doesn't do that at all. Why would application developers bother to ask about NAT-related information when they already know that their app works with IPsec NAT traversal? > Think of the goal as "damage containment" - it does hurt to > encourage unnecessary attempts to deal with NATs. It may be ok > to have the interface if the interface adds value to what apps > already have to do to cope with NATs, but there should be a > rationale for the added value. But also, and more to the point, as long as we accept the existence of NATs we might as well accept the existence of protocols which need help to traverse them, and then we should accept some of the responsibility for helping them. I'd reverse your question and ask how making this information available to the application developer encourages the development of new applications that need help in order to traverse NATs. > > > -- Key Manager/Key Management > > [... snip ...] > > > > This is the infamous "dangling SAs" issue > > > applied to connection latch state. > > > > What is this infamous issue? > > Does a CHILD_SA survive termination of the IKE_SA used to create > the CHILD_SA? Right, that problem is irrelevant to connection latching as specified. That said, that problem is relevant to the construction of IPsec channel bindings. But that's a topic for a different I-D. Thanks, Nico -- From Black_David at emc.com Wed Jan 9 08:22:31 2008 From: Black_David at emc.com (Black_David@emc.com) Date: Wed, 9 Jan 2008 11:22:31 -0500 Subject: [anonsec] Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt) In-Reply-To: <20080108225208.GW22538@Sun.COM> References: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> <20080108211846.GT22538@Sun.COM> <8CC6CEAB44F131478D3A7B429ECACD91085EB3@CORPUSMX20A.corp.emc.com> <20080108225208.GW22538@Sun.COM> Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91085EC0@CORPUSMX20A.corp.emc.com> Nico, > > > > -- NATs > > > > > > > > p.5 says: > > > > > > Well, does it hurt to have this? I suppose this could be a MAY, if > > > implementors object (or it could be downgraded to MAY or removed > > > altogether when in the progression to Standard). > > > > > > I don't feel too strongly about it, but I also don't feel too strongly > > > about discouraging the use of NATs (face it: NATs are here to stay, at > > > least in the IPv4 world). > > > > This isn't about discouraging use of NATs; I completely agree > > that NATs are a fact of life for IPv4. This is about avoiding > > encouragement of NAT-specific code in protocols and applications > > that don't need it (i.e., work just fine with IPsec NAT traversal). > > I think this text doesn't do that at all. Why would application > developers bother to ask about NAT-related information when > they already know that their app works with IPsec NAT traversal? Because there's a "SHOULD" in the standard written by people who may have more of a clue about NATs. > > Think of the goal as "damage containment" - it does hurt to > > encourage unnecessary attempts to deal with NATs. It may be ok > > to have the interface if the interface adds value to what apps > > already have to do to cope with NATs, but there should be a > > rationale for the added value. > > But also, and more to the point, as long as we accept the existence of > NATs we might as well accept the existence of protocols which need help > to traverse them, and then we should accept some of the responsibility for > helping them. > > I'd reverse your question and ask how making this information available > to the application developer encourages the development of new > applications that need help in order to traverse NATs. I hereby renew my membership in the "if in doubt, leave it out" design camp ;-). In any case, I'm ok with making the requirement a MAY, at least for now. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david at emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From Internet-Drafts at ietf.org Thu Jan 10 14:30:02 2008 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Thu, 10 Jan 2008 17:30:02 -0500 Subject: [anonsec] I-D Action:draft-ietf-btns-connection-latching-05.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-btns-connection-latching-05.txt -------------- next part -------------- From Nicolas.Williams at sun.com Thu Jan 10 14:32:47 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 10 Jan 2008 16:32:47 -0600 Subject: [anonsec] Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt) In-Reply-To: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> References: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> Message-ID: <20080110223247.GZ810@Sun.COM> I've uploaded a new version, -05, that addresses most of your comments, as well as most of Dan McDonald's comments (made off-list; I'll forward those exchanges to the list, with Dan's permission, shortly). I still have some TODOs, but I wanted to submit a new version sooner, rather than later. I've made few changes to the design of connection latching, but several significant and substantive changes to the document. Design changes: - removed LARVAL state (it was imaginary) - added requirement for API option for conflict resolution: wait for the conflict to go away or break the latch - added SUSPENDED state corresponding to "wait for the conflict to go away" (see above) Text changes: - moved connection latch state into its own sub-section and greatly expanded it, including state transition details - I've not yet written a state diagram - added more text about the normative/informative model split - added text to the introduction about the significance of this work - added text on simultaneous latching (corresponding to TCP simultaneous opens) - added more text on connection latching in BITS and SG Thank you, David, and thank you, Dan, for your helpful comments! In particular, given that Dan and connection latching go back a long time (at least ten years) and that Dan had much to do with the Solaris implementation of connection latching, I now feel quite certain that this document is on track as far as the technical details are concerned. Nico -- From Nicolas.Williams at sun.com Thu Jan 10 15:16:10 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 10 Jan 2008 17:16:10 -0600 Subject: [anonsec] Dan's comments (Re: Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt)) In-Reply-To: <20080110223247.GZ810@Sun.COM> References: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> <20080110223247.GZ810@Sun.COM> Message-ID: <20080110231609.GD810@Sun.COM> On Thu, Jan 10, 2008 at 04:32:47PM -0600, Nicolas Williams wrote: > I've uploaded a new version, -05, that addresses most of your comments, > as well as most of Dan McDonald's comments (made off-list; I'll forward > those exchanges to the list, with Dan's permission, shortly). Attached are Dan's comments and my replies. Nico -- -------------- next part -------------- >From danmcd at Sun.COM Tue Jan 8 12:23:33 2008 Date: Tue, 08 Jan 2008 13:08:17 -0500 From: Dan McDonald Subject: Pass-0 check of -05 of connection latching In-reply-to: <20080107203639.GG22538 at Sun.COM> To: Nicolas Williams Cc: Dan McDonald , Julien Laganier Message-id: <20080108180817.GB999 at kebe.east.sun.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <200712211008.07706.julien.laganier at gmail.com> <20080107130220.GA1290 at sun.com> <20080107203639.GG22538 at Sun.COM> Here are some pass-0 (first breezy read-through) comments: * The whole normative/informative split irks me... it feels like you're trying to assuage the Steve Kents of the world. (Perhaps that is its purpose?) * If this is "a description of how it works today", as mentioned on phone conversations - it's not. The draft points out what SHOULD be there, not what IS. I don't mind this quirk, but I just wanted to make sure it's not claiming to be entirely implemented in running code today. * Perhaps my first deep reading will answer this, but do you cover the unconnected datagram socket case at all? There are potential ways to convey the information latching requires on inbound datagrams and on outbound datagrams in the disconnected socket case, but It's Hard (TM) and would require XNET (aka UNIX98 or later) sockets using cmsg data. I don't know how that would fit into your informative model, never mind your normative one. * Maybe I need to re-read 4301, but I thought the SPD was a non-persistent repository, but you make it sound like it's persistent across boots... again, perhaps my next reading will make things clearer. I will be giving the document a second, deeper, reading later today or tomorrow. I may give it a third one if it's particularly bothersome, or if we arrive at any noteworthy changes. Just consider this a progress check of sorts! :) Dan >From Nicolas.Williams at sun.com Tue Jan 8 14:32:34 2008 Date: Tue, 8 Jan 2008 14:32:33 -0600 From: Nicolas Williams To: Dan McDonald Cc: Julien Laganier Subject: Re: Pass-0 check of -05 of connection latching Message-ID: <20080108203233.GS22538 at Sun.COM> References: <200712211008.07706.julien.laganier at gmail.com> <20080107130220.GA1290 at sun.com> <20080107203639.GG22538 at Sun.COM> <20080108180817.GB999 at kebe.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080108180817.GB999 at kebe.east.sun.com> On Tue, Jan 08, 2008 at 01:08:17PM -0500, Dan McDonald wrote: > Here are some pass-0 (first breezy read-through) comments: > > * The whole normative/informative split irks me... it feels like > you're trying to assuage the Steve Kents of the world. (Perhaps > that is its purpose?) That's partly it. I'm following the lead of RFC4301: lay out a reference model and any other model that provides equivalent security guarantees or better is OK. A model that might please the Steve Kents of the world is, in the IETF anyways, a big plus. Whether this one is such a model, I don't know -- Steve has indicated that he doesn't care to review this I-D :/ > * If this is "a description of how it works today", as mentioned on > phone conversations - it's not. The draft points out what SHOULD I'm aware. The informative section is meant to be the "how it works today" part. > be there, not what IS. I don't mind this quirk, but I just wanted > to make sure it's not claiming to be entirely implemented in > running code today. I did this primarily because a model that works for hybrid BITS/native implementations seemed desirable. Think of NICS that offload ESP/AH, like RNICs (NICs that implement the RDDP parts of iSER (iSCSI + RDDP) and NFSv4 -- iSCSI requires IPsec). Now put the firmware beyond your reach. And, to top it off, make it so that NIC doesn't tag incoming packets with information about what SAs protected them. How would you implement connection latching? The Solaris approach won't work, but the normative scheme laid out in the I-D does. Now, maybe *all* NICs with ESP/AH offload actually tag incoming packets with the SAs that protected them (and, conversely, allow the OS to tag outgoing packets with what SAs to use to protect them). With the normative model given we just don't have to ask anyone what the heck their NICs do in this regard. To switch to the Solaris model as the normative model would require asking lots of questions of people who we may not even know are building such NICs. > * Perhaps my first deep reading will answer this, but do you cover > the unconnected datagram socket case at all? There are potential > ways to convey the information latching requires on inbound > datagrams and on outbound datagrams in the disconnected socket > case, but It's Hard (TM) and would require XNET (aka UNIX98 or > later) sockets using cmsg data. I don't know how that would fit > into your informative model, never mind your normative one. It covers the connected datagram socket case but not the unconnected datagram case. I believe the only way to deal with the latter is through the informative packet-tagging model. > * Maybe I need to re-read 4301, but I thought the SPD was a > non-persistent repository, but you make it sound like it's > persistent across boots... again, perhaps my next reading will make > things clearer. The PAD (roughly svc:/network/ipsec/ike:default's config file) and SPD (roughly svc:/network/ipsec/policy:default's config file) are persistent. The SADB is dynamic and non-persisting across reboots (though you might think of manually keyed SADB entries as persistent). > I will be giving the document a second, deeper, reading later today or > tomorrow. I may give it a third one if it's particularly bothersome, or if > we arrive at any noteworthy changes. > > Just consider this a progress check of sorts! :) Thanks! Nico -- >From danmcd at sun.com Wed Jan 9 15:18:00 2008 Date: Wed, 09 Jan 2008 16:02:54 -0500 From: Dan McDonald Subject: Pass-1 review of -05 In-reply-to: <20080108203233.GS22538 at Sun.COM> To: Nicolas Williams Cc: Dan McDonald , Julien Laganier Message-id: <20080109210254.GD1329 at sun.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <200712211008.07706.julien.laganier at gmail.com> <20080107130220.GA1290 at sun.com> <20080107203639.GG22538 at Sun.COM> <20080108180817.GB999 at kebe.east.sun.com> <20080108203233.GS22538 at Sun.COM> I said: > > I will be giving the document a second, deeper, reading later today or > > tomorrow. I may give it a third one if it's particularly bothersome, or > > if we arrive at any noteworthy changes. And here is pass 1 comments on draft-ietf-btns-connection-latching-05.txt. NOTE: Some pass 0 comments may be restated. This is merely because I didn't use different colored pens for marking up the paper copy. :) Dan ===================== (Cut up to and including here.) ===================== OVERALL ------- * Now that I understand the necessity for both normative and informative models, I actually like how both explain two different ways to solve the same problem. I like this document overall, and my comments are mostly centered around clarification and pitfall indication. * Any mention of OpenSolaris is made with two purposes. The first is to clarify to you, Nico, what's currently in OpenSolaris - since I believe you're drawing from us as a prototype connection-latching implementation. The second is to help me think about implementation issues. * The informative (packet-tagging) model isn't EXACTLY how OpenSolaris works today, and there will be several RFEs falling out of this draft, I think. I believe those RFEs should be covered in the context of RFC 430x work in OpenSolaris. * Implementations may store their various bits and pieces in different protection domains. (e.g. Our connection latches are auxiliary state to the conn_t, aka. control-block, but our certificates are in the IKE daemon.) You may need to acknowlege this fact somewhere. Per-section comments -------------------- Sec 2 I'm not very fond of the term "IPsec channel", because it's pg 4 more a "latch instance", but I can't think of a very good reason to rename it, so just consider that a bit of a style criticism you can ignore. pg 4 Latch parameters not in OpenSolaris today: Replay protection indicator Key lengths Peer identity information pg 5 Small descriptions with each state would be helpful. pg 5 You lead with "MUST NOT be sent unprotected" which seems obvious. You should probably stress "MUST match latch parameters" instead. (Applies to inbound and outbound processing bullets.) pg 6 You hint at section 3's "Optional Protection". I'll talk about that more later, but that's gonna be hard to get right, never mind specify. pg 6 OpenSolaris doesn't use PF_KEY mods at all for connection latching. Ours is totally centered on the IP_SEC_OPT socket option. See ipsec(7P) in the OpenSolaris man pages. I don't mind the citation, of course, but that wasn't one of the intended uses of PF_KEY. Sec 2.1 You've encountered what we found operationally in punchin! When pg 9 a NAT is involved all hell breaks loose with mistaken SA sharing. In OpenSolaris, the only way to workaround this is to specify UNIQUE SA policies (which means an SA must be tied to an entire 5-tuple) and have the aggressive breaking of latches by closing connections. pg 9 Speaking of latch breaking, I like the idea of closing the connection in these situations. The question is, what errno gets passed up to the socket? (e.g. ECONNRESET for TCP RST packets). pg 11 Phrasing nit: say "(i.e. the tags don't appear..." instead of "(the tags don't appear...". pg 11 Explain a little more that acquiring an SA means kicking Key Management in the pants to do its thing. Not everyone thinks like PF_KEY coders. :) Sec 3 Today, OpenSolaris allows IP_SEC_OPT to override any non-PASS SPD pg 14 entry for normal users - so long as the IP_SEC_OPT specifies some level of IPsec protection. Privilege is required to BYPASS any SPD entries using what you call "optional protection". pg 14 How does one specify "meets or exceeds" the quality of protection. I believe the answer is "at the discretion of the system policy", but that's hard to implement properly. pg 14 Your last paragraph talks about updates to the SPD. That might make sense in some implementations, but today if I do "ipsecconf -ln" I don't see all of the per-socket exceptions, nor do I plan to. OpenSolaris caches SPD results in the conn_t for connected sockets. They're ALSO latched implicitly. For example, if I have specified: # Telnet needs IPsec protection { rport 23 } ipsec {encr_algs aes encr_auth_algs sha1} and then I open an outbound telnet connection, that connection uses ESP with AES and HMAC-SHA1 for its duration - even if I come along halfway through its lifetime and flush the local SPD! >From Nicolas.Williams at sun.com Wed Jan 9 15:44:01 2008 Date: Wed, 9 Jan 2008 15:44:00 -0600 From: Nicolas Williams To: Dan McDonald Cc: Julien Laganier Subject: Re: Pass-1 review of -05 Message-ID: <20080109214400.GG810 at Sun.COM> References: <200712211008.07706.julien.laganier at gmail.com> <20080107130220.GA1290 at sun.com> <20080107203639.GG22538 at Sun.COM> <20080108180817.GB999 at kebe.east.sun.com> <20080108203233.GS22538 at Sun.COM> <20080109210254.GD1329 at sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080109210254.GD1329 at sun.com> On Wed, Jan 09, 2008 at 04:02:54PM -0500, Dan McDonald wrote: > OVERALL > ------- > > * Now that I understand the necessity for both normative and informative > models, I actually like how both explain two different ways to solve the > same problem. I like this document overall, and my comments are mostly > centered around clarification and pitfall indication. Thanks. And, if I may, *phew*. I like knowing that we're on the right track, and review has been so sorely missing here that I couldn't be quite sure... > * Any mention of OpenSolaris is made with two purposes. The first is to > clarify to you, Nico, what's currently in OpenSolaris - since I believe > you're drawing from us as a prototype connection-latching implementation. > The second is to help me think about implementation issues. I'll include my replies here, cc'ed to Julien, but Julien is free to ignore the OpenSolar-specific bits if he likes. > * The informative (packet-tagging) model isn't EXACTLY how OpenSolaris works > today, and there will be several RFEs falling out of this draft, I think. Yeah, I know. > I believe those RFEs should be covered in the context of RFC 430x work in > OpenSolaris. > > * Implementations may store their various bits and pieces in different > protection domains. (e.g. Our connection latches are auxiliary state to > the conn_t, aka. control-block, but our certificates are in the IKE > daemon.) You may need to acknowlege this fact somewhere. I think that's implied here: o Implementations that have a restartable key management process (or "daemon") MUST arrange for existing latched connections to either be broken and disconnected, or for them to survive the restart of key exchange processes. (This is implied by the above requirements.) IPsec state related to connection latches MUST be torn down when latched connections are torn down, even when the latter is implied, such as at crash/halt/reboot time. But I'll add something a bit more explicit. > Per-section comments > -------------------- > > Sec 2 I'm not very fond of the term "IPsec channel", because it's > pg 4 more a "latch instance", but I can't think of a very good reason to > rename it, so just consider that a bit of a style criticism you can > ignore. Yeah, well, we have the term "channel binding," which presupposes a channel. Connection latching provides an "IPsec channel" in that sense. Terminology is... painful. Different areas of the IETF use very different terminology and one cannot please everyone. The best I could do is have a glossary where every term like this one is explained, including its historical context. Say the word and I'll do it. I think it's too late to change from this term to something else. But since "IPsec channel" and "connection latch" are used fairly interchangeably, I could minimize all uses of "IPsec channel," relegating them to the introduction, say. > pg 4 Latch parameters not in OpenSolaris today: > > Replay protection indicator > > Key lengths > > Peer identity information We need to fix this :) > pg 5 Small descriptions with each state would be helpful. OK. I'll be adding one more state: SUSPENDED, for apps like BGP that want to avoid connection breaks as much as possible (and which expect no breaks). But connection latch breaking should probably be the default behaviour. > pg 5 You lead with "MUST NOT be sent unprotected" which seems obvious. > You should probably stress "MUST match latch parameters" instead. > (Applies to inbound and outbound processing bullets.) OK. > pg 6 You hint at section 3's "Optional Protection". I'll talk about that > more later, but that's gonna be hard to get right, never mind > specify. Earlier I called this "BYPASS OR PROTECT" and it gave Steve Kent, and, by extension, me, *heartburn*. > pg 6 OpenSolaris doesn't use PF_KEY mods at all for connection latching. > Ours is totally centered on the IP_SEC_OPT socket option. See > ipsec(7P) in the OpenSolaris man pages. I don't mind the citation, > of course, but that wasn't one of the intended uses of PF_KEY. I was hinting at kernel-driven ACQUIRE, since creating a latch can ultimately lead to that situation. But I'm happy to remove the comment and the reference, if you like. > Sec 2.1 You've encountered what we found operationally in punchin! When > pg 9 a NAT is involved all hell breaks loose with mistaken SA sharing. > In OpenSolaris, the only way to workaround this is to specify UNIQUE > SA policies (which means an SA must be tied to an entire 5-tuple) and > have the aggressive breaking of latches by closing connections. If I did it's because: a) this was probably in the back of my mind anyways, b) I definitely had IP_SEC_OPT in mind, c) Michael Richardson cares about NATs very much, so he'd have seen to it that this was there. > pg 9 Speaking of latch breaking, I like the idea of closing the connection > in these situations. The question is, what errno gets passed up to > the socket? (e.g. ECONNRESET for TCP RST packets). Yes, ECONNRESET. > pg 11 Phrasing nit: say "(i.e. the tags don't appear..." instead > of "(the tags don't appear...". OK. > pg 11 Explain a little more that acquiring an SA means kicking Key > Management in the pants to do its thing. Not everyone thinks like > PF_KEY coders. :) Heh. First he complains about a reference to PF_KEY, then... :) :) > Sec 3 Today, OpenSolaris allows IP_SEC_OPT to override any non-PASS SPD "PASS"? In RFC4301 parlance that'd be "PROTECT," right? > pg 14 entry for normal users - so long as the IP_SEC_OPT specifies some > level of IPsec protection. Privilege is required to BYPASS any > SPD entries using what you call "optional protection". It was my intent to capture this. Did I? > pg 14 How does one specify "meets or exceeds" the quality of protection. > I believe the answer is "at the discretion of the system policy", but That's pretty much what it means. In practice that's the only thing it can mean, because there's no way to algorithmically compare the strength of cipher suites. (The issue of relative strength comes up *often* in the IETF. This is my answer.) > that's hard to implement properly. Well, no, local/system policy is easy to implement. In the worst (or best) case you act as if there was no such policy, in which case you don't allow any deviation from what's in the SPD. > pg 14 Your last paragraph talks about updates to the SPD. That might make > sense in some implementations, but today if I do "ipsecconf -ln" I > don't see all of the per-socket exceptions, nor do I plan to. I did use the qualifier "logically." I believe that should suffice to allow the behaviour you describe. > OpenSolaris caches SPD results in the conn_t for connected sockets. > They're ALSO latched implicitly. For example, if I have specified: > > # Telnet needs IPsec protection > { rport 23 } ipsec {encr_algs aes encr_auth_algs sha1} > > and then I open an outbound telnet connection, that connection uses > ESP with AES and HMAC-SHA1 for its duration - even if I come along > halfway through its lifetime and flush the local SPD! Yes, I know. I should probably describe this too, and even RECOMMEND it. Not probably; I will, if I haven't already. Thanks! Nico -- >From danmcd at sun.com Thu Jan 10 12:54:16 2008 Date: Thu, 10 Jan 2008 13:38:49 -0500 From: Dan McDonald Subject: Re: Pass-1 review of -05 In-reply-to: <20080109214400.GG810 at Sun.COM> To: Nicolas Williams Cc: Dan McDonald , Julien Laganier Message-id: <20080110183849.GC781 at kebe.east.sun.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <200712211008.07706.julien.laganier at gmail.com> <20080107130220.GA1290 at sun.com> <20080107203639.GG22538 at Sun.COM> <20080108180817.GB999 at kebe.east.sun.com> <20080108203233.GS22538 at Sun.COM> <20080109210254.GD1329 at sun.com> <20080109214400.GG810 at Sun.COM> Content-Length: 5743 Lines: 148 On Wed, Jan 09, 2008 at 03:44:01PM -0600, Nicolas Williams wrote: > > * Implementations may store their various bits and pieces in different > > protection domains. (e.g. Our connection latches are auxiliary state to > > the conn_t, aka. control-block, but our certificates are in the IKE > > daemon.) You may need to acknowlege this fact somewhere. > > I think that's implied here: > > o Implementations that have a restartable key management process (or > "daemon") MUST arrange for existing latched connections to either > be broken and disconnected, or for them to survive the restart of > key exchange processes. (This is implied by the above > requirements.) IPsec state related to connection latches MUST be > torn down when latched connections are torn down, even when the > latter is implied, such as at crash/halt/reboot time. > > But I'll add something a bit more explicit. You mention nothing about how hard/easy this might be given where various bits of state may or may not be stored. That's what I'm worried about. > > Per-section comments > > -------------------- > > > > Sec 2 I'm not very fond of the term "IPsec channel", because it's > > pg 4 more a "latch instance", but I can't think of a very good reason to > > rename it, so just consider that a bit of a style criticism you can > > ignore. > > Yeah, well, we have the term "channel binding," which presupposes a > channel. Connection latching provides an "IPsec channel" in that sense. > Terminology is... painful. Different areas of the IETF use very > different terminology and one cannot please everyone. The best I could > do is have a glossary where every term like this one is explained, > including its historical context. Say the word and I'll do it. > > I think it's too late to change from this term to something else. > But since "IPsec channel" and "connection latch" are used fairly > interchangeably, I could minimize all uses of "IPsec channel," > relegating them to the introduction, say. It was more of a grouse than an actual constructive comment. I feel bad for including it. > > pg 4 Latch parameters not in OpenSolaris today: > > > > Replay protection indicator > > > > Key lengths > > > > Peer identity information > > We need to fix this :) Like I said... tons of RFEs fall out of this document. > > pg 5 Small descriptions with each state would be helpful. > > OK. I'll be adding one more state: SUSPENDED, for apps like BGP that > want to avoid connection breaks as much as possible (and which expect no > breaks). But connection latch breaking should probably be the default > behaviour. Thanks. > > pg 6 OpenSolaris doesn't use PF_KEY mods at all for connection latching. > > Ours is totally centered on the IP_SEC_OPT socket option. See > > ipsec(7P) in the OpenSolaris man pages. I don't mind the citation, > > of course, but that wasn't one of the intended uses of PF_KEY. > > I was hinting at kernel-driven ACQUIRE, since creating a latch can > ultimately lead to that situation. But I'm happy to remove the comment > and the reference, if you like. Your text made it sound like PF_KEY was the way to implement the connection-latching API, which probably isn't the case. > > pg 9 Speaking of latch breaking, I like the idea of closing the connection > > in these situations. The question is, what errno gets passed up to > > the socket? (e.g. ECONNRESET for TCP RST packets). > > Yes, ECONNRESET. I might argue the choice of errno value, but that it should manifest AS an error of some kind is what I was seeking. Thanks! > > Sec 3 Today, OpenSolaris allows IP_SEC_OPT to override any non-PASS > SPD > > "PASS"? In RFC4301 parlance that'd be "PROTECT," right? non-PASS == PROTECT. Today on OpenSolaris, if I've an SPD: # ESP with AES and HMAC-SHA-1 {} ipsec {encr_algs aes encr_auth_algs sha1} I could set a socket option (even as a normal user) to use AH with HMAC-MD5 without incident (assuming KM succeeded). > > pg 14 entry for normal users - so long as the IP_SEC_OPT specifies some > > level of IPsec protection. Privilege is required to BYPASS any > > SPD entries using what you call "optional protection". > > It was my intent to capture this. Did I? Mostly, except for the behaviors I specified above. > > pg 14 How does one specify "meets or exceeds" the quality of protection. > > I believe the answer is "at the discretion of the system policy", but > > That's pretty much what it means. In practice that's the only thing it > can mean, because there's no way to algorithmically compare the strength > of cipher suites. (The issue of relative strength comes up *often* in > the IETF. This is my answer.) Understood. > > pg 14 Your last paragraph talks about updates to the SPD. That might make > > sense in some implementations, but today if I do "ipsecconf -ln" I > > don't see all of the per-socket exceptions, nor do I plan to. > > I did use the qualifier "logically." I believe that should suffice to > allow the behaviour you describe. Phew! Okay. > > OpenSolaris caches SPD results in the conn_t for connected sockets. > > They're ALSO latched implicitly. For example, if I have specified: > > > > # Telnet needs IPsec protection > > { rport 23 } ipsec {encr_algs aes encr_auth_algs sha1} > > > > and then I open an outbound telnet connection, that connection uses > > ESP with AES and HMAC-SHA1 for its duration - even if I come along > > halfway through its lifetime and flush the local SPD! > > Yes, I know. I should probably describe this too, and even RECOMMEND > it. Not probably; I will, if I haven't already. Excellent! Thanks, Dan >From Nicolas.Williams at sun.com Thu Jan 10 15:41:53 2008 Date: Thu, 10 Jan 2008 15:41:53 -0600 From: Nicolas Williams To: Dan McDonald Cc: Julien Laganier Subject: Re: Pass-1 review of -05 Message-ID: <20080110214153.GY810 at Sun.COM> References: <200712211008.07706.julien.laganier at gmail.com> <20080107130220.GA1290 at sun.com> <20080107203639.GG22538 at Sun.COM> <20080108180817.GB999 at kebe.east.sun.com> <20080108203233.GS22538 at Sun.COM> <20080109210254.GD1329 at sun.com> <20080109214400.GG810 at Sun.COM> <20080110183849.GC781 at kebe.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080110183849.GC781 at kebe.east.sun.com> Content-Length: 3529 Lines: 82 On Thu, Jan 10, 2008 at 01:38:49PM -0500, Dan McDonald wrote: > On Wed, Jan 09, 2008 at 03:44:01PM -0600, Nicolas Williams wrote: > > > > > > * Implementations may store their various bits and pieces in different > > > protection domains. (e.g. Our connection latches are auxiliary state to > > > the conn_t, aka. control-block, but our certificates are in the IKE > > > daemon.) You may need to acknowlege this fact somewhere. > > > > I think that's implied here: > > > > o Implementations that have a restartable key management process (or > > "daemon") MUST arrange for existing latched connections to either > > be broken and disconnected, or for them to survive the restart of > > key exchange processes. (This is implied by the above > > requirements.) IPsec state related to connection latches MUST be > > torn down when latched connections are torn down, even when the > > latter is implied, such as at crash/halt/reboot time. > > > > But I'll add something a bit more explicit. > > You mention nothing about how hard/easy this might be given where various > bits of state may or may not be stored. That's what I'm worried about. Well, does it matter? Sure, it may not be easy for *some* implementation designs. So what? The question, for me, is whether this is always so hard that we should go back to the drawing board. I think the answer is no. > > I was hinting at kernel-driven ACQUIRE, since creating a latch can > > ultimately lead to that situation. But I'm happy to remove the comment > > and the reference, if you like. > > Your text made it sound like PF_KEY was the way to implement the > connection-latching API, which probably isn't the case. I've re-read, it says "Both models imply extensions to any PF_KEY-like" protocols that may be used internally ..." ^^^ ^^^^^ In practice the extensions for kernel-driven ACQUIRE were always needed, so I'll just remove this. > > "PASS"? In RFC4301 parlance that'd be "PROTECT," right? > > non-PASS == PROTECT. > > Today on OpenSolaris, if I've an SPD: > > # ESP with AES and HMAC-SHA-1 > {} ipsec {encr_algs aes encr_auth_algs sha1} > > I could set a socket option (even as a normal user) to use AH with HMAC-MD5 > without incident (assuming KM succeeded). Very confusing. RFC4301 uses "BYPASS" to mean "sent/accepted in the clear." Bottom-line: unprivileged apps should be able to request PROTECT (RFC4301 terms) when the policy would BYPASS (RFC4301 terms), but not BYPASS when PROTECT would be required, and neither BYPASS nor PROTECT when DISCARD (drop) would be required. Privileged apps should be able to do whatever their level of privilege allows them. > > > OpenSolaris caches SPD results in the conn_t for connected sockets. > > > They're ALSO latched implicitly. For example, if I have specified: > > > > > > # Telnet needs IPsec protection > > > { rport 23 } ipsec {encr_algs aes encr_auth_algs sha1} > > > > > > and then I open an outbound telnet connection, that connection uses > > > ESP with AES and HMAC-SHA1 for its duration - even if I come along > > > halfway through its lifetime and flush the local SPD! > > > > Yes, I know. I should probably describe this too, and even RECOMMEND > > it. Not probably; I will, if I haven't already. > > Excellent! Of course, to do this I need to figure out what the default latched parameters should be -- easy for everything except the new "break or suspend" option. From Nicolas.Williams at sun.com Thu Jan 10 15:45:05 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 10 Jan 2008 17:45:05 -0600 Subject: [anonsec] Connection latching by default? Message-ID: <20080110234505.GG810@Sun.COM> Solaris creates connection latches for all connected sockets by default, whether the application requested it or not. The just-submitted draft-ietf-btns-connection-latching-05.txt says: Implementations MAY create IPsec channels automatically by default when the application does not request an IPsec channel. But I see no reason not to make that a SHOULD. Dan thinks it should be a SHOULD. Others, however, may disagree. Comments? Nico -- From Black_David at emc.com Fri Jan 11 15:16:42 2008 From: Black_David at emc.com (Black_David@emc.com) Date: Fri, 11 Jan 2008 18:16:42 -0500 Subject: [anonsec] review comments on draft-ietf-btns-prob-and-applic-06.txt In-Reply-To: References: Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91085F06@CORPUSMX20A.corp.emc.com> As a co-author of this draft, I want to thank Steve for his review. While it's come along a bit later in the process than one might want ideally to receive these sorts of comments, it is far better to receive them now than after an RFC is published. There are enough issues raised here that I think a new revision of the draft is in order. In exchanging email with my other co-authors and Steve, the following has emerged as a likely set of actions to respond to Steve's review (the purpose of this message is to invite WG comments on these actions): - Extend the material on document structure at end of Section 1 to actually describe the structure. As Steve says, there are two problems based on presence vs. absence of higher level authentication. In turn, each of the two solutions has 3 possible modes of operation (both, one or neither end of SA is authenticated as part of SA setup). - Clearly state the restriction that IPsec is to be used as part of the problem statements. That restriction is in the btns WG charter, and in its absence, the WG would never have been chartered (IMHO). - Provide appropriate context around the examples. The examples were important motivations at the time, and BTNS is applicable to them in principle even if non- IPsec approaches are being pursued in practice. - Shorten the security considerations section by: o removing the Leap of Faith material (section 5.7) as a distraction o replacing the Rekeying attack material in section 5.8 with a short explanation of why BTNS can increase the need for connection latching, punctuated by a pointer to the connection latching draft. One thing that will not be done is to describe EAP's encapsulation in IKEv2 as a possible solution to the BTNS problems. There are two reasons for this: 1) The existence of authentication identities and associated secrets at the network level is part of the BTNS problems, making EAP (which continues their use) a poor solution approach. 2) EAP is inapplicable. Section 1.3 of RFC 3748 (EAP) says: EAP was designed for use in network access authentication, where IP layer connectivity may not be available. Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED. iSCSI and NFSv4 are examples of "bulk data transport" protocols to which BTNS is intended to be applicable. Instead, it would make more sense to add text that makes both of the above points so that issues about usage of EAP for BTNS purposes do not arise again. Comments? Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david at emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: anonsec-bounces at postel.org > [mailto:anonsec-bounces at postel.org] On Behalf Of Stephen Kent > Sent: Monday, January 07, 2008 3:18 PM > To: ietf at ietf.org; anonsec at postel.org > Subject: [anonsec] review comments on > draft-ietf-btns-prob-and-applic-06.txt > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document is not well structured, i.e., in many places it > rambles. The document has more of an architectural framework feel to > it than the title suggests. It spends too much time saying how BTNS > will work, rather than focusing on the nominal topic of the document, > i.e., the problem to be solved and the anticipated applicability of > the solution. It never provides a clear, concise characterization of > the problem to be solved, and why the functionality offered by > BTNS-IPsec is the preferred way to solve the problem. (I believe this > problem arises because, from the beginning, there were been > multiple, independent motivations for the BTNS work and the WG never > reconciled them.) > > There seem to be two types of problems/solutions that motivate BTNS, > both starting with the assumption that use of IPsec is the goal (an > assumption that needs to be justified itself, as noted below). The > solutions are presented before examples of the problems, which does > not help matters, but I'll characterize the problems in terms of the > solutions, in keeping with the style of the I-D: > > - creating IPsec/IKE SAs w/o authentication, for use > in contexts where > it is perceived that IPsec is not used because the > effort to deploy an > authentication infrastructure compatible with IKE is > too great a burden > AND the confidentiality and integrity offered by > unauthenticated SAs is > "better than nothing." Since IKE supports use of passwords, > this presumes > that the threshold for what constitutes too great a burden is > pretty low, > but this is not explicitly stated. Also, the BGP use > case was disputed, > when this work started, and has proven to be a bad example given > continuing developments, but it persists in the document. > There is also a > not-well-articulated argument that TLS/DTLS is not a suitable > alternative, > presumably because those protocols do not protect the > transport protocol > per se. It's true that IPsec does a better job here, > but the need for > using it (vs. TLS) in such circumstances does not seem to be > widely accepted. > > - creating IPsec/IKE SAs w/o authentication, for use > in contexts where an > application will perform its own authentication, but > wants the layer 3 > confidentiality, integrity and continuity of authentication > offered by ESP. > Here a critical part of the argument is that these > applications cannot use > the authentication provided by IKE, but the explanation for > this is poor. For > example there is no recognition of the use of EAP > authentication methods with > IKE. The text also does not address the possibility that a > suitable API could > allow an application to acquire and track the ID > asserted during an IKE > exchange, in lieu of the unauthenticated SA approach that is > being motivated. > > The document fails to introduce important concepts like continuity of > authentication and channel binding near the beginning. If leap of > faith authentication is important enough to be included, then it too > needs to be described early in the document. The document never > provides a clear, concise definition of channel binding, and the > definition of LoF is mostly by example. The failure to define these > terms early in the document leads to ambiguity and confusion in the > problem statement sections. > > Several of the examples provided in the applicability section do not > seem congruent with security efforts in the relevant areas. I > mentioned the BGP connection example above, which is even less > relevant today, given the ongoing TCPM work on TCP-AO. There is also > an assertion that BTNS-IPsec is a good way to protect VoIP media, yet > the RTP folks never believed that and the RAI area has recently > reaffirmed its commitment to use of SRTP for this purpose, with DTLS > for key management. Another questionable example is the suggestion to > use both BTNS-IPsec and TLS to protect client/server connections > against TCP RST attacks. This is theoretically a valid use of > BTNS-IPsec, but there is no indication that web server operators > believe this is a "necessary" capability, as the I-D argues. > > The security considerations section is too long, mostly because much > of the material should be earlier, e.g., the CB discussion. One > might also move the rekeying attack example (which I expanded to be > more accurate) to the CB document, and just reference the notion here. > > I am unable to attach a copy of the I-D, with MS Word charge tracking > for detailed comments and edits, because it is too big for these > lists. A copy of that file was sent to tge cognizant Security AD, WG > chairs, and authors. > > Steve > _______________________________________________ From Nicolas.Williams at sun.com Fri Jan 11 16:00:20 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 11 Jan 2008 18:00:20 -0600 Subject: [anonsec] review comments on draft-ietf-btns-prob-and-applic-06.txt In-Reply-To: References: Message-ID: <20080112000019.GX810@Sun.COM> [I've taken the liberty of re-formatting the quoted text for line wrapping and indentation.] On Mon, Jan 07, 2008 at 03:18:09PM -0500, Stephen Kent wrote: > - creating IPsec/IKE SAs w/o authentication, for use in > contexts where an application will perform its own > authentication, but wants the layer 3 confidentiality, > integrity and continuity of authentication offered by ESP. > > Here a critical part of the argument is that these > applications cannot use the authentication provided by IKE, > but the explanation for this is poor. I think one part of the answer to this is there, but the other part appears to be missing. > For example there is no > recognition of the use of EAP authentication methods with > IKE. EAP is not applicable. The applicability statement for EAP rules out use where end-to-end authentication is desired. Beyond that, the authentication infrastructure may not be suitable for use in IKE, even if that's merely an issue of lack of specifications or implementations. (This is mentioned in the I-D.) Finally, multi-user systems may need to authenticate individual users to other entities, in which case IPsec is inapplicable[*]. (I cannot find a mention of this in the I-D, not after a quick skim.) [*] At least to my reading of RFC4301, though I see no reason why a system couldn't negotiate narrow SAs, each with different local IDs and credentials, with other peers. But that wouldn't help applications that multiplex messages for many users' onto one TCP connection (e.g., NFS), in which case even if my readinf of RFC4301 is wrong IPsec is still not applicable for authentication. > The text also does not address the possibility that a > suitable API could allow an application to acquire and track > the ID asserted during an IKE exchange, in lieu of the > unauthenticated SA approach that is being motivated. Given the answers above such an API would be insufficient, though still quite welcome. Note that applications would care about the IDs of the SAs that protect their packets. But applications don't usually deal in packets. Connection latching is a simple method for tracking the IDs of the SAs that protect the apps' packets; the API that you suggest can be (and will be) built on top of connection latching. A non-connection-oriented version of connection latching is certainly feasible too. > The security considerations section is too long, mostly because much > of the material should be earlier, e.g., the CB discussion. One > might also move the rekeying attack example (which I expanded to be > more accurate) to the CB document, and just reference the notion here. Given that this is a problem and applicability statement for a security technology, the security considerations section might as well state that security considerations are discussed throughout the document, thus freeing the authors to structure the document like you suggest. Nico -- From Nicolas.Williams at sun.com Fri Jan 11 16:04:11 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 11 Jan 2008 18:04:11 -0600 Subject: [anonsec] review comments on draft-ietf-btns-prob-and-applic-06.txt In-Reply-To: <8CC6CEAB44F131478D3A7B429ECACD91085F06@CORPUSMX20A.corp.emc.com> References: <8CC6CEAB44F131478D3A7B429ECACD91085F06@CORPUSMX20A.corp.emc.com> Message-ID: <20080112000410.GY810@Sun.COM> On Fri, Jan 11, 2008 at 06:16:42PM -0500, Black_David at emc.com wrote: > One thing that will not be done is to describe EAP's > encapsulation in IKEv2 as a possible solution to the BTNS > problems. There are two reasons for this: Yes, EAP is not applciable, and I've just described separately the other major reasons why authentication at the IPsec layer is not always suitable. > Instead, it would make more sense to add text that makes > both of the above points so that issues about usage of EAP > for BTNS purposes do not arise again. > > Comments? Yes please. Also let's add the multi-user multi-plexing rationale. Nico -- From kent at bbn.com Mon Jan 14 08:56:04 2008 From: kent at bbn.com (Stephen Kent) Date: Mon, 14 Jan 2008 11:56:04 -0500 Subject: [anonsec] not so recent comments ... Message-ID: David, In your response to my last call comments, you began by noting that it would have been preferable to receive them much earlier in the process. In a message to you and the other authors on 12/9/205, I suggested several changes that, if addressed, might have avoided the most recent set of comments. I received only one reply to my comments, from you, and your message addressed only one of my comments. This two-year old exchange shows that, even two years ago, several of the motivations cited in the document were questionable. This is not an example of 20-20 hindsight. It is an example of authors who elect to not make changes. My comments from that message are in bold below. ----------- I noted that the argument about the need to use different sets of credentials for applications (vs. what IKE/Ipsec can use) needed to be improved. It still does. >>... >>We can't use application credentials for IPsec; the formats of the two >>may be incompatible. There's no API for injecting credentials into IPsec >>either. >> >Most IETF security standards have no API defined for this purpose, >so this argument, while true, seems a bit odd in the larger context. >Also, depending on the nature of the user credentials, they may be >compatible with IKE use, since IKE allows for shared secrets (e.g., >passwords) as well as certificates. I noted that the use of PKI terminology was poor, at best. >>... >> >>With regard to BGP in particular, it has been understood that the use >>of appropriate authentication is the preferred solution [1]. >>Supporting authentication, e.g., by using signed certificates, at one > All certificates are signed, so delete that modifier above The modifier was changed to "CA-signed" in the latest draft, which is still generally wrong. I also noted that using VoIP as an motivation for BTNS was a bad idea, yet the example persists in the most recent version. >>... >> >>VoIP may require efficiency but its bandwidth use is low (450 Kbps >>telephone-grade, typically less) and thus does not require substantial >>CPU resources to protect. We do not believe it is necessary to address this. >> >I agree that VoIP bandwidth is low, but the objection to using IPsec >for VoIP (which primarily calls for using SRTP) is the per-packet >overhead. That concern motivated those folks to develop SRTP, not >the amount of processing power needed to apply IPsec. (Also, they >can make a god case for not needing the access control facilities of >IPsec.) I objected to the sloppy analysis of why one might use BTNS to protect web access. > > The flash crowd and DDoS attack discussions seems like a red herring, >> given that they may saturate a link irrespective of the security >> protocol employed. > > >They were left in for completeness of discussion. > >If they are kept for completeness, the at least make sure that >readers understand that these attacks may pose problems irrespective >of the use of specific network layer security mechanisms, as I noted >above. The details of rationale in the analysis were changed in the current version of the I-D, but the rationale is still poor, i.e., now it argues for use of BTNS-IPsec to protects against TCP-layer reset attacks, a concern that does not seem to be widely shared. The only response to my comments was from you, and we had one further exchange related to the use of EAP with IKE, and how it relates to the BTNS context, in a message on 12/15/05: >> > Also, depending on the nature of the user credentials, they may >>be compatible >> > with IKE use, since IKE allows for shared secrets (e.g., >>passwords) as well as certificates. >> >>Did you really mean "e.g., passwords"? IMHO, anyone who uses anything >>as weak as a plain password directly as an IKE pre-shared key should >>be shot (or at least ignored when they complain about a security >>breach). I hope this wasn't what you had in mind. Beyond this, >>there are various problems with mechanisms that can handle >>a weak secret with IKE. For IKEv1, one has to resort to the XAUTH >>crock (not exactly interoperable), or other stuff that I don't recall >>as being much better - do you have something in mind here that's not >>embarrassing to talk about in public? For IKEv2, EAP is a much better >>answer, but even that framework doesn't seem to be there for all >>protocols (e.g., I don't think anyone's worked out the details, or >>is in any hurry to do so for how iSCSI and/or NFSv4 should play nice >>with EAP). For iSCSI, the hash function transition will probably >>force the retirement of CHAP, and EAP is certainly a possible approach >>to dealing with that problem, but it's not a slam-dunk certainty to be >>chosen, and in any case, the transition is not likely to happen quickly. > >You are right; I was not clear in my comment. What I should have >said was that IKE allows for use of passwords, SecurID >challenge-response, and other common methods of user authentication >via EAP (section 2.16 of IKE). Thus if one wants to argue that user >authentication credentials that might be used by an application >would not generally be suitable for use with IKE, one has to make >this argument in the face of this explicit provision for "legacy >authentication mechanisms" in IKEv2. Also, EAP is being extended >(the EMU BoF at the last IETF meeting) ... Your most recent message cited text fro RFC 3748 (EAP) and stated that the cited text argues against use of EAP with IPsec when the applications are "bulk data transfer." The reality is that use of EAP with IKE does happen, as well as in the TLS context, etc. So, given the widespread use of EAP, this document needs to explain why it is inapplicable. Your reference to network layer identities seems odd, as EAP usually makes use of individual IDs. A better rationale is still needed. Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/anonsec/attachments/20080114/276e1404/attachment.html From Nicolas.Williams at sun.com Mon Jan 14 09:37:19 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 14 Jan 2008 11:37:19 -0600 Subject: [anonsec] not so recent comments ... In-Reply-To: References: Message-ID: <20080114173719.GI810@Sun.COM> On Mon, Jan 14, 2008 at 11:56:04AM -0500, Stephen Kent wrote: > Your most recent message cited text fro RFC 3748 (EAP) and stated > that the cited text argues against use of EAP with IPsec when the > applications are "bulk data transfer." The reality is that use of EAP > with IKE does happen, as well as in the TLS context, etc. So, given > the widespread use of EAP, this document needs to explain why it is > inapplicable. Your reference to network layer identities seems odd, > as EAP usually makes use of individual IDs. A better rationale is > still needed. RFC348, section 1.3 says: EAP was designed for use in network access authentication, where IP layer connectivity may not be available. Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED. That means that EAP is OK for use in VPN-type IKEv2 uses, but not really for end-to-end uses of IKEv2. BTNS is meant for end-to-end use where "IP layer connectivity" _is_ already available. Ergo EAP is not applicable. The key isn't "bulk data transport" but "network access authentication" and "where IP layer connectivity may not be available." (I.e., I agree with David that EAP is not applicable, but disagree as to why.) If your comment re: EAP is that the BTNS problem and applicability statement needs to be specific as to why other alternatives were rejected, then I agree. W.r.t. use for BGP, VoIP and what not, I do tend to agree that the easiest sells for BTNS are the channel binding and leap-of-faith cases. I've been skeptical of other user cases before, and still am, for in most, if not all the non-channel binding, non-LoF cases there are alternatives that seem relatively low-cost to develop (relative to BTNS). Nico -- From kent at bbn.com Mon Jan 14 11:25:53 2008 From: kent at bbn.com (Stephen Kent) Date: Mon, 14 Jan 2008 14:25:53 -0500 Subject: [anonsec] review comments on draft-ietf-btns-prob-and-applic-06.txt In-Reply-To: <20080112000019.GX810@Sun.COM> References: <20080112000019.GX810@Sun.COM> Message-ID: At 6:00 PM -0600 1/11/08, Nicolas Williams wrote: >... > >Finally, multi-user systems may need to authenticate individual users to >other entities, in which case IPsec is inapplicable[*]. (I cannot find >a mention of this in the I-D, not after a quick skim.) > >[*] At least to my reading of RFC4301, though I see no reason why a > system couldn't negotiate narrow SAs, each with different local IDs > and credentials, with other peers. But that wouldn't help > applications that multiplex messages for many users' onto one TCP > connection (e.g., NFS), in which case even if my readinf of RFC4301 > is wrong IPsec is still not applicable for authentication. IPsec has always allowed two peers to negotiate multiple SAs between them, e.g., on a per-TCP connection basis. Ipsec does support per-user authentication if protocol ID and port pairs can be used to distinguish the sessions for different users. So, if you want to restrict the cited motivation to applications that multiplex different users onto a single TCP/UDP session, that would be accurate. Steve From kent at bbn.com Mon Jan 14 11:27:51 2008 From: kent at bbn.com (Stephen Kent) Date: Mon, 14 Jan 2008 14:27:51 -0500 Subject: [anonsec] not so recent comments ... In-Reply-To: <20080114173719.GI810@Sun.COM> References: <20080114173719.GI810@Sun.COM> Message-ID: At 11:37 AM -0600 1/14/08, Nicolas Williams wrote: >On Mon, Jan 14, 2008 at 11:56:04AM -0500, Stephen Kent wrote: >> Your most recent message cited text fro RFC 3748 (EAP) and stated >> that the cited text argues against use of EAP with IPsec when the >> applications are "bulk data transfer." The reality is that use of EAP >> with IKE does happen, as well as in the TLS context, etc. So, given >> the widespread use of EAP, this document needs to explain why it is >> inapplicable. Your reference to network layer identities seems odd, >> as EAP usually makes use of individual IDs. A better rationale is >> still needed. > >RFC348, section 1.3 says: > > EAP was designed for use in network access authentication, where IP > layer connectivity may not be available. Use of EAP for other > purposes, such as bulk data transport, is NOT RECOMMENDED. > >That means that EAP is OK for use in VPN-type IKEv2 uses, but not really >for end-to-end uses of IKEv2. > >BTNS is meant for end-to-end use where "IP layer connectivity" _is_ >already available. Ergo EAP is not applicable. > >The key isn't "bulk data transport" but "network access authentication" >and "where IP layer connectivity may not be available." (I.e., I agree >with David that EAP is not applicable, but disagree as to why.) Your rationale is better than what David cited. I suggest it be included in a discussion of why EAP is considered inappropriate hhere. >If your comment re: EAP is that the BTNS problem and applicability >statement needs to be specific as to why other alternatives were >rejected, then I agree. yes. > >W.r.t. use for BGP, VoIP and what not, I do tend to agree that the >easiest sells for BTNS are the channel binding and leap-of-faith cases. >I've been skeptical of other user cases before, and still am, for in >most, if not all the non-channel binding, non-LoF cases there are >alternatives that seem relatively low-cost to develop (relative to >BTNS). we agree on this issue as well. Steve From Nicolas.Williams at sun.com Mon Jan 14 12:06:23 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 14 Jan 2008 14:06:23 -0600 Subject: [anonsec] review comments on draft-ietf-btns-prob-and-applic-06.txt In-Reply-To: References: <20080112000019.GX810@Sun.COM> Message-ID: <20080114200623.GN810@Sun.COM> On Mon, Jan 14, 2008 at 02:25:53PM -0500, Stephen Kent wrote: > At 6:00 PM -0600 1/11/08, Nicolas Williams wrote: > >... > > > >Finally, multi-user systems may need to authenticate individual users to > >other entities, in which case IPsec is inapplicable[*]. (I cannot find > >a mention of this in the I-D, not after a quick skim.) > > > >[*] At least to my reading of RFC4301, though I see no reason why a > > system couldn't negotiate narrow SAs, each with different local IDs > > and credentials, with other peers. But that wouldn't help > > applications that multiplex messages for many users' onto one TCP > > connection (e.g., NFS), in which case even if my readinf of RFC4301 > > is wrong IPsec is still not applicable for authentication. > > IPsec has always allowed two peers to negotiate multiple SAs between > them, e.g., on a per-TCP connection basis. Right. > Ipsec does support ^^^^^ You're slipping :) :) > per-user authentication if protocol ID and port pairs can be used to > distinguish the sessions for different users. I thought this was feasible (see above) but I thought the RFC4301 model didn't quite deal with this (or at least Sam once convinced me that the name selector of the SPD didn't quite work the way I would think it should). I am glad to be wrong on this. (So then, the name selector in the SPD can be used to select the local ID and credentials?) > So, if you want to > restrict the cited motivation to applications that multiplex > different users onto a single TCP/UDP session, that would be accurate. I don't want to restrict it only to such applications, _no_. The set of applications I can see as standing to benefit from BTNS: - iSCSI -- because once revised to support use of connection latching, IPsec APIs and channel binding then configuring iSCSI to use IPsec will be a lot easier than it is today. - NFSv4 -- because of the multi-user multiplexing issue, and because reducing the number of distinct cryptographic keys and key states will improve performance, particularly for large timesharing servers (think SunRay servers). - Eventually, if BTNS takes off, we might find that using BTNS in LoF or CBB modes will be useful in apps that today do/would/should use any of SASL, GSS, TLS and/or SSHv2. This is definitely speculative, though it's certainly possible; I've no idea if it's probable. How likely this is will depend on lots of things that I cannot predict. E.g., if NICs w/ ESP/AH offload spread, then I think that will greatly help make BTNS enticing. OTOH, NICs with TCP&TLS offload will help not. CPUs like my employer's latest, with speedy on-board crypto accelerators will be neutral (which, effectively, means they will not help make BTNS popular where easier to adopt alternatives exist). - Of course, BTNS could be applicable to many new application protocols, such as new protocols that are remotely similar to iSCSI or NFS. Keep in mind that iSCSI is not all that special compared to apps that today use SASL or TLS (or both). The main difference is that iSCSI's designers felt that for a bulk data protocol it would be best (performance-wise, oer perhaps design effort-wise) to push crypto down to the lowest possible layer. So, if iSCSI can benefit from BTNS and/or related specs (connection latching, IPsec APIs), then it's not farfetched to believe that more apps will come along that can also benefit from our work. I think the examples that you object to can remain in the I-D, but it should be clear that BTNS is not 'RECOMMENDED' (nor 'NOT RECOMMENDED') for those -- that those examples are speculative. Provided that such examples are feasible. Nico -- From kent at bbn.com Mon Jan 14 13:07:52 2008 From: kent at bbn.com (Stephen Kent) Date: Mon, 14 Jan 2008 16:07:52 -0500 Subject: [anonsec] review comments on draft-ietf-btns-prob-and-applic-06.txt In-Reply-To: <20080114200623.GN810@Sun.COM> References: <20080112000019.GX810@Sun.COM> <20080114200623.GN810@Sun.COM> Message-ID: At 2:06 PM -0600 1/14/08, Nicolas Williams wrote: >... >> Ipsec does support > ^^^^^ >You're slipping :) :) oh my! > > per-user authentication if protocol ID and port pairs can be used to >> distinguish the sessions for different users. > >I thought this was feasible (see above) but I thought the RFC4301 model >didn't quite deal with this (or at least Sam once convinced me that the >name selector of the SPD didn't quite work the way I would think it >should). I am glad to be wrong on this. > >(So then, the name selector in the SPD can be used to select the local >ID and credentials?) The following text from pages 28-29 of 4301 seems pretty clear on this point. I have marked some of the text as bold, to call attention to especially relevant parts. - Name: This is not a selector like the others above. It is not acquired from a packet. A name may be used as a symbolic identifier for an IPsec Local or Remote address. Named SPD entries are used in two ways: 1. A named SPD entry is used by a responder (not an initiator) in support of access control when an IP address would not be appropriate for the Remote IP address selector, e.g., for "road warriors". The name used to match this field is communicated during the IKE negotiation in the ID payload. In this context, the initiator's Source IP address (inner IP header in tunnel mode) is bound to the Remote IP address in the SAD entry created by the IKE negotiation. This address overrides the Remote IP address value in the SPD, when the SPD entry is selected in this fashion. All IPsec implementations MUST support this use of names. 2. A named SPD entry may be used by an initiator to identify a user for whom an IPsec SA will be created (or for whom traffic may be bypassed). The initiator's IP source address (from inner IP header in tunnel mode) is used to replace the following if and when they are created: - local address in the SPD cache entry - local address in the outbound SAD entry - remote address in the inbound SAD entry Support for this use is optional for multi-user, native host implementations and not applicable to other implementations. Note that this name is used only locally; it is not communicated by the key management protocol. Also, name forms other than those used for case 1 above (responder) are applicable in the initiator context (see below). So, although support for this capability (for initiators) is not strictly required for a multi-user system, we do explain how it is intended to work in those systems. > >> So, if you want to >> restrict the cited motivation to applications that multiplex >> different users onto a single TCP/UDP session, that would be accurate. > >I don't want to restrict it only to such applications, _no_. Then you should include the sort of text you provided below, to justify why BTNS is appropriate in these circumstances, since it is not accurate to say that IPsec cannot provide the required support. >... > >I think the examples that you object to can remain in the I-D, but it >should be clear that BTNS is not 'RECOMMENDED' (nor 'NOT RECOMMENDED') >for those -- that those examples are speculative. Provided that such >examples are feasible. my only requirement is that the motivation text be factually accurate. Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/anonsec/attachments/20080114/bd15587b/attachment.html From kent at bbn.com Mon Jan 14 13:18:03 2008 From: kent at bbn.com (Stephen Kent) Date: Mon, 14 Jan 2008 16:18:03 -0500 Subject: [anonsec] Dan's comments (Re: Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt)) In-Reply-To: <20080110231609.GD810@Sun.COM> References: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> <20080110223247.GZ810@Sun.COM> <20080110231609.GD810@Sun.COM> Message-ID: Nico & Dan, the SPD has always been a persistent database. the newly added PAD also is persistent. It's the SAD that is transient, i.e., need not have any entries unless SAs have been created, and those entries vanish when the SAs they represent vanish. The notion of dynamic modification of the SPD is a relatively new concept, not part of the original design, but not ruled out by it. Also note that the de-correlated SPD model introduced in 4301 works very well for a persistent database, but could be costly to maintain if the SPD is frequently updated. Steve has indicated that he is tired of reviewing BTNS documents that often are hard to read and that too often are revised with only slight improvement. The BTNS problem statement is the most recent example, where comments from two years ago were not acted upon. Steve From Nicolas.Williams at sun.com Mon Jan 14 13:42:46 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 14 Jan 2008 15:42:46 -0600 Subject: [anonsec] Dan's comments (Re: Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt)) In-Reply-To: References: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> <20080110223247.GZ810@Sun.COM> <20080110231609.GD810@Sun.COM> Message-ID: <20080114214245.GB4374@Sun.COM> On Mon, Jan 14, 2008 at 04:18:03PM -0500, Stephen Kent wrote: > Nico & Dan, > > the SPD has always been a persistent database. the newly added PAD > also is persistent. It's the SAD that is transient, i.e., need not Had I gotten this wrong? No. Dan may not be totally up to speed with RFC4301 terminology, but I wouldn't dismiss what he has to say on account of that. > have any entries unless SAs have been created, and those entries > vanish when the SAs they represent vanish. The notion of dynamic > modification of the SPD is a relatively new concept, not part of the > original design, but not ruled out by it. Also note that the > de-correlated SPD model introduced in 4301 works very well for a > persistent database, but could be costly to maintain if the SPD is > frequently updated. Are you asking that the connection latching I-D address how to perform dynamic updates of a de-correlated SPD? From hartmans-ietf at mit.edu Mon Jan 14 14:18:52 2008 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Mon, 14 Jan 2008 17:18:52 -0500 Subject: [anonsec] Connection latching by default? In-Reply-To: <20080110234505.GG810@Sun.COM> (Nicolas Williams's message of "Thu, 10 Jan 2008 17:45:05 -0600") References: <20080110234505.GG810@Sun.COM> Message-ID: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> Solaris creates connection latches for all connected Nicolas> sockets by default, whether the application requested it Nicolas> or not. Nicolas> The just-submitted Nicolas> draft-ietf-btns-connection-latching-05.txt says: Nicolas> Implementations MAY create IPsec Nicolas> channels automatically by default when the application Nicolas> does not request an IPsec channel. Nicolas> But I see no reason not to make that a SHOULD. Dan Nicolas> thinks it should be a SHOULD. Nicolas> Others, however, may disagree. I think you need to have strong support for making it a should; silence is not enough on this point. From Nicolas.Williams at sun.com Mon Jan 14 14:46:26 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 14 Jan 2008 16:46:26 -0600 Subject: [anonsec] Connection latching by default? In-Reply-To: References: <20080110234505.GG810@Sun.COM> Message-ID: <20080114224626.GF4374@Sun.COM> On Mon, Jan 14, 2008 at 05:18:52PM -0500, Sam Hartman wrote: > I think you need to have strong support for making it a should; I'm asking who does support it (I know Dan does strongly support this, and there is one implementation that does this _today_, namely Solaris). > silence is not enough on this point. I'm not sure that I understand what you mean by "silence is not enough on this point" -- did I say something that indicated that silence would be taken to denote consent? Nico -- From hartmans-ietf at mit.edu Mon Jan 14 15:05:53 2008 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Mon, 14 Jan 2008 18:05:53 -0500 Subject: [anonsec] Connection latching by default? In-Reply-To: <20080114224626.GF4374@Sun.COM> (Nicolas Williams's message of "Mon, 14 Jan 2008 16:46:26 -0600") References: <20080110234505.GG810@Sun.COM> <20080114224626.GF4374@Sun.COM> Message-ID: >>>>> "Nicolas" == Nicolas Williams writes: >> silence is not enough on this point. Nicolas> I'm not sure that I understand what you mean by "silence Nicolas> is not enough on this point" -- did I say something that Nicolas> indicated that silence would be taken to denote consent? I mean that if you get no objections and it is just you and Dan in favor, that's not enough to make the change in this instance. From kent at bbn.com Mon Jan 14 13:57:29 2008 From: kent at bbn.com (Stephen Kent) Date: Mon, 14 Jan 2008 16:57:29 -0500 Subject: [anonsec] Dan's comments (Re: Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt)) In-Reply-To: <20080114214245.GB4374@Sun.COM> References: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> <20080110223247.GZ810@Sun.COM> <20080110231609.GD810@Sun.COM> <20080114214245.GB4374@Sun.COM> Message-ID: At 3:42 PM -0600 1/14/08, Nicolas Williams wrote: >On Mon, Jan 14, 2008 at 04:18:03PM -0500, Stephen Kent wrote: >> Nico & Dan, >> >> the SPD has always been a persistent database. the newly added PAD >> also is persistent. It's the SAD that is transient, i.e., need not > >Had I gotten this wrong? No. Dan may not be totally up to speed with >RFC4301 terminology, but I wouldn't dismiss what he has to say on >account of that. since, as I said, the SPD has ALWAYS been defined as persistent, this misunderstanding is not attributable to a lack of familiarity with 4301. > > have any entries unless SAs have been created, and those entries >> vanish when the SAs they represent vanish. The notion of dynamic >> modification of the SPD is a relatively new concept, not part of the >> original design, but not ruled out by it. Also note that the >> de-correlated SPD model introduced in 4301 works very well for a >> persistent database, but could be costly to maintain if the SPD is >> frequently updated. > >Are you asking that the connection latching I-D address how to perform >dynamic updates of a de-correlated SPD? no. I was just noting the most recent (2 years old) text supporting the fact that the SPD was not nominally viewed as dynamic. Steve From Nicolas.Williams at sun.com Mon Jan 14 23:34:36 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 15 Jan 2008 01:34:36 -0600 Subject: [anonsec] Connection latching by default? In-Reply-To: References: <20080110234505.GG810@Sun.COM> <20080114224626.GF4374@Sun.COM> Message-ID: <20080115073435.GG4374@Sun.COM> On Mon, Jan 14, 2008 at 06:05:53PM -0500, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > >> silence is not enough on this point. > > Nicolas> I'm not sure that I understand what you mean by "silence > Nicolas> is not enough on this point" -- did I say something that > Nicolas> indicated that silence would be taken to denote consent? > > I mean that if you get no objections and it is just you and Dan in > favor, that's not enough to make the change in this instance. I asked for a reason :) I don't know how many opinions we'll get. Also, recommending that connection latching be on by default can always be done later. Nico -- From hartmans-ietf at mit.edu Wed Jan 16 16:23:28 2008 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Wed, 16 Jan 2008 19:23:28 -0500 Subject: [anonsec] Typo in core draft Message-ID: + bind the same public key. These certificates need not to have been + pre-shared with their peers (e.g., because ephermal, self-signed). The current text sounds like a requirement that certificates are not shared with peers. I think it's more like "These certificates do not need to be " Am I correct on this point? If so, feel free to either submit a new ID or give me an rfc editor note to apply in the tracker. Either way I'll put this on the agenda for next week. From Nicolas.Williams at sun.com Thu Jan 17 02:16:38 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 17 Jan 2008 04:16:38 -0600 Subject: [anonsec] Typo in core draft In-Reply-To: References: Message-ID: <20080117101638.GB6591@Sun.COM> On Wed, Jan 16, 2008 at 07:23:28PM -0500, Sam Hartman wrote: > + bind the same public key. These certificates need not to have been > + pre-shared with their peers (e.g., because ephermal, self-signed). > > > The current text sounds like a requirement that certificates are not > shared with peers. I think it's more like "These certificates do not > need to be " Yes, that's correct -- the word "do" is missing and should be inserted before "need to be". > Am I correct on this point? If so, feel free to either submit a new > ID or give me an rfc editor note to apply in the tracker. The note is this: Add the word "do" before "need to" in the last sentence of the parapgraph that starts "Nodes wishing to be treated as BTNS nodes..." in section 2. > Either way I'll put this on the agenda for next week. Thanks. From hartmans-ietf at mit.edu Thu Jan 17 07:38:33 2008 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Thu, 17 Jan 2008 10:38:33 -0500 Subject: [anonsec] Typo in core draft In-Reply-To: <20080117101638.GB6591@Sun.COM> (Nicolas Williams's message of "Thu, 17 Jan 2008 04:16:38 -0600") References: <20080117101638.GB6591@Sun.COM> Message-ID: I've inserted the following into the ballot: Note to RFC Editor Section 2: old: bind the same public key. These certificates need not to have been new: bind the same public key. These certificates do not need to be