From Internet-Drafts at ietf.org Thu Mar 1 12:50:03 2007 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Thu, 01 Mar 2007 15:50:03 -0500 Subject: [anonsec] I-D ACTION:draft-ietf-btns-core-02.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-btns-core-02.txt -------------- next part -------------- From Internet-Drafts at ietf.org Thu Mar 1 12:50:03 2007 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Thu, 01 Mar 2007 15:50:03 -0500 Subject: [anonsec] I-D ACTION:draft-ietf-btns-connection-latching-01.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-btns-connection-latching-01.txt -------------- next part -------------- From Qingshan.ZHANG at alcatel-sbell.com.cn Thu Mar 1 18:58:33 2007 From: Qingshan.ZHANG at alcatel-sbell.com.cn (CTO ZHANG Qingshan) Date: Fri, 2 Mar 2007 10:58:33 +0800 Subject: [anonsec] draft-zhang-btns-icmp-sec-extension-01 References: <200701131456.PAA29445@TR-Sys.de> Message-ID: <9570C1261494D54D9D3115BC2C83429A01C2EB2B@asbmail2.sbell.com.cn> Hi, dear all, With great help of Alfred and other members of the group, the 2nd version of the I-D (Extension of ICMP Security Failures Messages) has been finished. Great thanks to them! :-) Any comments from you are appreciated. Best regards, Qingshan -----Original Message----- From: Alfred HÎnes [mailto:ah at tr-sys.de] Sent: ÐÇÆÚÁù 2007Äê1ÔÂ13ÈÕ 22:57 To: CTO ZHANG Qingshan Subject: draft-zhang-btns-icmp-sec-extension-00 Hello, after studying your Internet-Draft, draft-zhang-btns-icmp-sec-extension-00 , I would like to point out some substantial issues with that draft, and propose a couple of textual enhancements and corrections to textual issues. I'll undertake an almost linear walk-through of the text. Snippits are taken literally, and when showing context for proposed changes, I make use of the shorthand notation: --- or, if blank lines appear in the snippits: ----------- snip ---------- ^v^v^v^v^v^v^v^v^v^v^v^v^v^ ----------- snip ---------- I use change bars ('|' in column 1) and occasionally up/down pointing marker lines ('^^^'/'vvv') to emphasize the location of textual issues and/or proposed corrections. Modified text has generally been re-adjusted to match I-D / RFC formatting rules, where appropriate. I also have tried to adopt other currently enforced RFC-Ed. policy (e.g., punctuation style). (1) Abstract Please, either use "sub-types" or "subtypes" instead of "sub types" (and similarly for "sub kind" etc.). RFC2521 defines ICMP security failures messages for indicating failures when using IP Security Protocols (AH and ESP). This document presents extension of those messages, which make use of some reserved field to specify sub types of failures. --- | RFC 2521 defines ICMP security failures messages for indicating failures when using IP Security Protocols (AH and ESP). This document presents extension of those messages that make use of some | reserved field to specify subtypes of failures. (2) Section 2 [RFC2521] is intended for use with the Internet Security Protocols ([RFC2401] etc.) for authentication and privacy. These messages | covers all the failure types of IPSec traffic, but the granularity of some failures specified in the failure messages is larger than that | provided by IPSec protocol suite. --- [RFC2521] is intended for use with the Internet Security Protocols ([RFC2401] etc.) for authentication and privacy. These messages | cover all the failure types of IPSec traffic, but the granularity of some failures specified in the failure messages is larger than that | provided by the IPSec protocol suite. | In order to make full use of the IPSec traffic granularity, extension of the failure messages is introduced in this document, which subdivides some failure types according to the minimum granularity of IPSec traffic. --- | In order to make full use of the IPSec traffic granularity, an extension of the failure messages is introduced in this document, which subdivides some failure types according to the minimum granularity of IPSec traffic. (3) Section 3 In the figure, I propose to add the usual ruler lines above, andbetter reflect the current standard; in the explanation, I recommend making clear from the beginning what is taken unchanged from RFC 2521. Finally, I recommend to perform indentation to enhance the readability, and I have added a few additional clarifications, as well. Thus: Below is the format of ICMP security failures messages with the subcode extension. It is different from the original format ([RFC2521]) at the reserved field. The first half of the reserved field is used as the "Subcode" field, which indicates sub types of security failures specified by the "Code" field. --- Below is the format of ICMP security failures messages with the subcode extension. It is different from the original format ([RFC2521]) at the reserved field. The first half of the reserved | field is used as the "Subcode" field, which indicates sub-types of security failures specified by the "Code" field. ----------- snip ---------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subcode | Reserved | Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Original Internet Headers + 64 bits of Payload ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | 0 1 2 3 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subcode | Reserved | Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ~ Original Internet Headers + 64 bits of Payload (or more) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----------- snip ---------- Type: 40 Code: Indicates the kind of failure: 0 = Bad SPI 1 = Authentication Failed 2 = Decompression Failed 3 = Decryption Failed 4 = Need Authentication 5 = Need Authorization ^v^v^v^v^v^v^v^v^v^v^v^v^v^ Type: 40 Code: Indicates the kind of failure, as specified in RFC 2521: 0 = Bad SPI 1 = Authentication Failed 2 = Decompression Failed 3 = Decryption Failed 4 = Need Authentication 5 = Need Authorization ----------- snip ---------- ----------- snip ---------- Subcode: Indicates the sub kind of failure: 0 = Not Classified If Code = 0~4, values of the subcode MAY be defined in future if necessary. If Code = 5, the subcode is defined as below: 1 = Name Unauthorized 2 = Data Sensitivity Level Unauthorized 3 = Transport Layer Protocol Unauthorized 4 = Source Port Unauthorized 5 = Destination Port Unauthorized 4 = Source Port Unauthorized 5 = Destination Port Unauthorized Otherwise, the subcode MUST be set to zero. ^v^v^v^v^v^v^v^v^v^v^v^v^v^ Subcode: Indicates the sub-kind of failure. | There's a distinct namespace for subcode values, per Code. | For all values of Code, the following is defined: 0 = Not Classified | If Code = 0..4, other values of the subcode MAY be defined in the future if necessary. | If Code = 5, the following subcode values are defined: 1 = Name Unauthorized 2 = Data Sensitivity Level Unauthorized 3 = Transport Layer Protocol Unauthorized 4 = Source Port Unauthorized 5 = Destination Port Unauthorized Otherwise, the subcode MUST be set to zero. ----------- snip ---------- And the final paragraph of the section: The values of subcode for "Need Authorization" are defined according to different selectors provided by IPSec, which determine the granularity of IPSec traffics. Meanings of these values are elaborated as below. --- The values of subcode for "Need Authorization" are defined according to different selectors provided by IPSec, which determine the | granularity of IPSec traffics. The meanings of these values are elaborated as below. (4) Section 3.1 This value is used for all failure types (Code=0~5). It indicates that a received datagram will not be accepted because there is a failure with the datagram, but the receptor does not specify sub types of this failure. --- This value is used for all failure types (Code=0~5). It indicates that a received datagram will not be accepted because there is a | failure with the datagram, but the receptor does not specify the | sub-types of this failure. (5) Section 3.2 I try on a clarification. Perhaps, the whole section needs updates and clarifications for IKEv2 [RFC4306]. Indicates that a received datagram will not be accepted because either no name information, or inappropriate name information is presented. (There are 2 cases of name information supported in IPSec DOI - User ID and System Name.) --- | Indicates that a received IKE datagram will not be accepted because either no name information, or inappropriate name information is | presented. (There are 2 cases of name information supported in the | IPSec DoI for ISAKMP [RFC2407] - User ID and System Name.) I do not understand what you mean by the next paragraph: In the case of receipt of a datagram with an ESP header, the name information is "OPAQUE" before decryption. The receptor SHOULD check the name information in this datagram after decryption, and generate a "Name Unauthorized" message if the name information of the datagram mismatches the name selector. As far as I see, authentication and authorization are dealt entirely with in the establishment of the IPsec SA, typically making use of the key management protocols (IKEv1 or IKEv2 -- there are other proposals). In IKE, the matters of authentication and authorization for SAs is managed by the IPsec databases, SPD, SAD, and PAD. IPsec protocol messages just encapsulate the traffic within the IPsec SA identified by the SPI in the ESP (or AH) header inserted, and the IPsec architecture does not include any further authorization checks beyond matching against the SA selectors stored in the SAD. I am not aware of any "name information" contained per-packet in ESP/AH. Note also, for the first paragraph above: RFC 2521 appears to be *not* applicable to key management traffic (IKE etc.), it apparently is only intended for packets protected by IPsec SAs (ESP/AH packets). IKE packets are *not* protected by an IPsec SA, the bootstrapping of protection is granted for by the IKE SA carrying IKE packets. (6) Section 3.3 The selector "data sensitivity level" has been deprecated by the current IPsec Architecture document [RFC4301]. The whole section is void, and the subcode value 2 assigned is obsolete from the beginning. (7) References Most References given are much outdated. Update as follows: [RFC2401] --> [RFC4301] [RFC2402] --> [RFC4302] [RFC2406] --> [RFC4303] [RFC2463] --> [RFC4443] Urgently add approriate Normative References for ICMP(v4). The Ref. [RFC2463] does not appear in the text -- see (8) below! Add Ref's for IKEv2: [RFC4306], and IKEv1 (if still deemed necessary): [RFC2407], [RFC2408], and [RFC2409]. The latter cannot be specified as Normative References because the RFCs have been obsoleted last year. Delete Ref [RFC3232] -- it does not appear in the body of the draft, and give more specific reference to the particular IANA registry/ registries affected. (8) IPv6 awareness This is perhaps the most important topic of all: Your memo will perhaps not have any chance of being accepted in the IETF/IESG, as long it does not also specify a solution for IPv6, of the problem it supposes to solve for IPv4, unless it *clearly* explains why this problem is not applicable to IPv6. It does not suffice to include only a Ref. to the (previous) ICMPv6 specification without making use of that Ref. in the text, and without giving any ICPMv6 specific details. (9) IANA Considerations The draft does not contain the *required* IANA Considerations section. It really should -- detailing the new sub-registry of the icmp-parameters registry, and setting the policy for any further allocations therein. Best regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah at TR-Sys.de | +------------------------+--------------------------------------------+ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: draft-zhang-btns-icpm-sec-extension-01.txt Url: http://mailman.postel.org/pipermail/anonsec/attachments/20070302/e343d030/draft-zhang-btns-icpm-sec-extension-01-0001.txt From julien.IETF at laposte.net Fri Mar 2 05:37:59 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Fri, 2 Mar 2007 14:37:59 +0100 Subject: [anonsec] Preliminary Agenda for IETF68 In-Reply-To: <20070223141541.GZ18346@binky.central.sun.com> References: <26477.1171596804@sandelman.ottawa.on.ca> <200702231237.21728.julien.IETF@laposte.net> <20070223141541.GZ18346@binky.central.sun.com> Message-ID: <200703021437.59586.julien.IETF@laposte.net> Folks, Below is the prelimary agenda for IETF 68. Please tell us if something is missing/incorrect. Thanks. --julien ------------------------------------------------------- Better-Than-Nothing Security (btns) Agenda at IETF-68 ==================================== Chairs: Love Hornquist Astrand Julien Laganier AGENDA: Preliminaries - Chairs Core and Channel bindings - Nico Williams API - Michael Richardson & Miika Komu IKE Extensions - Michael Richardson From Nicolas.Williams at sun.com Fri Mar 2 07:55:39 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 2 Mar 2007 09:55:39 -0600 Subject: [anonsec] Preliminary Agenda for IETF68 In-Reply-To: <200703021437.59586.julien.IETF@laposte.net> References: <26477.1171596804@sandelman.ottawa.on.ca> <200702231237.21728.julien.IETF@laposte.net> <20070223141541.GZ18346@binky.central.sun.com> <200703021437.59586.julien.IETF@laposte.net> Message-ID: <20070302155539.GE18346@binky.central.sun.com> On Fri, Mar 02, 2007 at 02:37:59PM +0100, Julien Laganier wrote: > Folks, > > Below is the prelimary agenda for IETF 68. Please tell > us if something is missing/incorrect. [...] > Core and Channel bindings - Nico Williams ^^^^^^^^^^^^^^^^ connection latching Nico -- From julien.IETF at laposte.net Mon Mar 5 00:53:07 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Mon, 5 Mar 2007 09:53:07 +0100 Subject: [anonsec] Agenda for IETF68 posted In-Reply-To: <200703021437.59586.julien.IETF@laposte.net> References: <26477.1171596804@sandelman.ottawa.on.ca> <20070223141541.GZ18346@binky.central.sun.com> <200703021437.59586.julien.IETF@laposte.net> Message-ID: <200703050953.07479.julien.IETF@laposte.net> Folks, Below is the agenda for IETF 68 that we posted at Please sends us changes/addons no later than March 11th COB. -- BTNS chairs --------------------------------------------------------- Better-Than-Nothing Security (btns) Agenda at IETF-68 ==================================== Chairs: Love Hornquist Astrand Julien Laganier AGENDA: Preliminaries - Chairs Core and Connection Latching - Nico Williams API - Michael Richardson & Miika Komu IKE Extensions - Michael Richardson From wang.yushun at gmail.com Mon Mar 5 17:53:42 2007 From: wang.yushun at gmail.com (Yu-Shun Wang) Date: Mon, 05 Mar 2007 17:53:42 -0800 Subject: [anonsec] (resend) Problem/Applicability Statement WGLC summary and RFC publication request Message-ID: <45ECC9A6.8000208@gmail.com> Hi, The -05 version was submitted back in Feb. 13, which should address the few comments brought up during WGLC (ended Dec. 4, 2006): - Wording adjustment in the abstract to cover both pre-shared secret and CA-signed certs for authentication. Re: - Minor wording changes to regarding TCP-specific mods vs. HIP. Re: The full diffs between -04 and -05 The authors think the doc is ready and would like to request the publication of this doc as RFC. Thanks, yushun From miika at iki.fi Mon Mar 5 23:42:25 2007 From: miika at iki.fi (Miika Komu) Date: Tue, 6 Mar 2007 09:42:25 +0200 (EET) Subject: [anonsec] (resend) Problem/Applicability Statement WGLC summary and RFC publication request In-Reply-To: <45ECC9A6.8000208@gmail.com> References: <45ECC9A6.8000208@gmail.com> Message-ID: On Mon, 5 Mar 2007, Yu-Shun Wang wrote: Hi, sorry for the late comments, I somehow missed your original response. > Hi, > > The -05 version was submitted back in Feb. 13, which > should address the few comments brought up during WGLC > (ended Dec. 4, 2006): > > - Wording adjustment in the abstract to cover both pre-shared > secret and CA-signed certs for authentication. Re: > > > - Minor wording changes to regarding TCP-specific mods vs. HIP. Re: > > > The full diffs between -04 and -05 > > > > The authors think the doc is ready and would like to request > the publication of this doc as RFC. This was my original two-part comment: > > HIP is mentioned in section 2.2.1 briefly. Perhaps you could also > > mention that HIP has implicit channel binding mechanisms and reference > > RFC4423, HIP base draft or draft-ietf-hip-applications-00. In > > addition, the claim "such modifications are, at best, temporary > > patches to the ubiquitous vulnerability to spoofing attacks" requires > > some further explanation at least in the context of HIP. > > Agreed with HIP and channel binding part. But IMHO, these are > more subtle (you said "implicit" :-)) points that probably > should be covered in the CB doc for more details and comparison. The draft addresses my first consern but not the second. The section that I am referring to ends in this words: Some of these modifications are new to TCP, but have already been incorporated into other transport protocols (e.g., SCTP) or intermediate (so-called L3.5) protocols (e.g., HIP) [13][18]. and the following section continues: The TCP-specific modifications are, at best, temporary patches to the ubiquitous vulnerability to spoofing attacks. HIP is also based on IPsec, so the implicit suggestion here that HIP is vurnerable to TCP spoofing attacks is untrue. HIP modifies TCP checksums, but this occurs using IPsec. I'd just suggest dropping the HIP reference in the text. -- Miika Komu http://www.iki.fi/miika/ From wang.yushun at gmail.com Tue Mar 6 08:19:06 2007 From: wang.yushun at gmail.com (Yu-Shun Wang) Date: Tue, 06 Mar 2007 08:19:06 -0800 Subject: [anonsec] (resend) Problem/Applicability Statement WGLC summary and RFC publication request In-Reply-To: References: <45ECC9A6.8000208@gmail.com> Message-ID: <45ED947A.5090500@gmail.com> Hi, Comments below. Miika Komu wrote: > On Mon, 5 Mar 2007, Yu-Shun Wang wrote: <...> >> - Minor wording changes to regarding TCP-specific mods vs. HIP. Re: >> >> >> The full diffs between -04 and -05 >> >> >> >> >> The authors think the doc is ready and would like to request >> the publication of this doc as RFC. > > This was my original two-part comment: <...> > The draft addresses my first consern but not the second. The section > that I am referring to ends in this words: > > Some of these modifications are new to TCP, but have already been > incorporated into other transport protocols (e.g., SCTP) or intermediate > (so-called L3.5) protocols (e.g., HIP) [13][18]. > > and the following section continues: > > The TCP-specific modifications are, at best, temporary patches to the > ubiquitous vulnerability to spoofing attacks. > > HIP is also based on IPsec, so the implicit suggestion here that HIP is > vurnerable to TCP spoofing attacks is untrue. HIP modifies TCP > checksums, but this occurs using IPsec. I'd just suggest dropping the > HIP reference in the text. The new wording specifically says "TCP-specific modifications" which exclude SCTP and HIP, vs. the original text "Such modifications" which can mislead readers regarding your concern. I personally think the new wording is clear enough. Feel free to provide text if you think it's not clear. Thanks, yushun From miika at iki.fi Tue Mar 6 08:25:19 2007 From: miika at iki.fi (Miika Komu) Date: Tue, 6 Mar 2007 18:25:19 +0200 (EET) Subject: [anonsec] (resend) Problem/Applicability Statement WGLC summary and RFC publication request In-Reply-To: <45ED947A.5090500@gmail.com> References: <45ECC9A6.8000208@gmail.com> <45ED947A.5090500@gmail.com> Message-ID: On Tue, 6 Mar 2007, Yu-Shun Wang wrote: >> HIP is also based on IPsec, so the implicit suggestion here that HIP is >> vurnerable to TCP spoofing attacks is untrue. HIP modifies TCP checksums, >> but this occurs using IPsec. I'd just suggest dropping the HIP reference in >> the text. > > The new wording specifically says "TCP-specific modifications" > which exclude SCTP and HIP, vs. the original text "Such > modifications" which can mislead readers regarding your concern. > I personally think the new wording is clear enough. Feel free > to provide text if you think it's not clear. Ok, I agree now that the current text is fine. -- Miika Komu http://www.iki.fi/miika/ From julien.IETF at laposte.net Wed Mar 7 01:40:01 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Wed, 7 Mar 2007 10:40:01 +0100 Subject: [anonsec] (resend) Problem/Applicability Statement WGLC summary and RFC publication request In-Reply-To: <45ECC9A6.8000208@gmail.com> References: <45ECC9A6.8000208@gmail.com> Message-ID: <200703071040.01506.julien.IETF@laposte.net> Folks, If nobody objects to publication of draft-ietf-btns-prob-and-applic as an informational RFC before March 21st, we will submit the draft to the IESG. Best, --julien, BTNS co-chair On Tuesday 06 March 2007 02:53, Yu-Shun Wang wrote: > Hi, > > The -05 version was submitted back in Feb. 13, which > should address the few comments brought up during > WGLC (ended Dec. 4, 2006): > > - Wording adjustment in the abstract to cover both > pre-shared secret and CA-signed certs for > authentication. Re: > er/000913.html> > > - Minor wording changes to regarding TCP-specific > mods vs. HIP. Re: > er/000915.html> > > The full diffs between -04 and -05 > > f.org/id/draft-ietf-btns-prob-and-applic-05.txt> > > The authors think the doc is ready and would like to > request the publication of this doc as RFC. > > Thanks, > > yushun > > > _______________________________________________ From julien.IETF at laposte.net Fri Mar 9 01:40:24 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Fri, 9 Mar 2007 10:40:24 +0100 Subject: [anonsec] Fwd: I-D ACTION:draft-komu-btns-api-01.txt Message-ID: <200703091040.24922.julien.IETF@laposte.net> FYI, -------------- next part -------------- An embedded message was scrubbed... From: Internet-Drafts at ietf.org Subject: I-D ACTION:draft-komu-btns-api-01.txt Date: Thu, 08 Mar 2007 15:50:04 -0500 Size: 5644 Url: http://mailman.postel.org/pipermail/anonsec/attachments/20070309/612e8ae6/attachment.mht From julien.IETF at laposte.net Mon Mar 12 03:45:49 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Mon, 12 Mar 2007 11:45:49 +0100 Subject: [anonsec] Final agenda posted Message-ID: <200703121145.50158.julien.IETF@laposte.net> Folks, The final agenda has been posted at: It is copied below for your convenience. --julien, BTNS co-chair ---------------------------------------------------------- Better-Than-Nothing Security (btns) Agenda at IETF-68 ==================================== Chairs: Love Hornquist Astrand Julien Laganier AGENDA: Preliminaries - Chairs Core and Connection Latching - Nico Williams API - Michael Richardson & Miika Komu IKE Extensions - Michael Richardson From miika at iki.fi Mon Mar 12 05:08:49 2007 From: miika at iki.fi (Miika Komu) Date: Mon, 12 Mar 2007 14:08:49 +0200 (EET) Subject: [anonsec] Fwd: I-D ACTION:draft-komu-btns-api-01.txt In-Reply-To: <200703091040.24922.julien.IETF@laposte.net> References: <200703091040.24922.julien.IETF@laposte.net> Message-ID: On Fri, 9 Mar 2007, Julien Laganier wrote: Hi all, a lot of things have changed in the API draft. Most importantly, the draft is now more concrete instead of just outlining some ideas. It includes C-based programming interfaces for defining application ipsec policy attributes and channel bindings. The use of the interfaces is illustrated in the appendix with some code examples. I removed the dependency to draft-ietf-hip-native-api because the dependency is actually the other way around. The draft is not based on high layer interfaces (SASL or GSS) because they are more session or transport layer oriented, where as IPsec APIs should be working even at the datagram oriented level (sendmsg, sendto, etc). However, it should be ok to use e.g. GSS and the IPsec APIs at the same time in the same application. The changes are based on comments from Nicolas Williams, Michael Richardson, Love ?strand and Julien Laganier. Sasu Tarkoma gave a thorough review for the preversion and promised to participate in editing the next versions of the draft, so I added him as a co-author. Thanks for the commentors good feedback! Some things are still work in progress: * The exact set of policy attributes to be defined in the draft. * Code examples with SASL or GSS. Server side code examples. * Storing of channel bindings to long-term memory (disk?) * The comparison functions should allow comparison of attribute1 < attribute2, not just equality. * Querying of local / peer identitities * Forcing of IPsec based security vs. allow fallback to non-IPsec based communications? * Error values All further comments are welcome! http://www.ietf.org/internet-drafts/draft-komu-btns-api-01.txt -- Miika Komu http://www.iki.fi/miika/ From mcr at sandelman.ca Sun Mar 18 08:13:15 2007 From: mcr at sandelman.ca (Michael Richardson) Date: Sun, 18 Mar 2007 16:13:15 +0100 Subject: [anonsec] should IPsec policies be partially ordered? In-Reply-To: References: <200703091040.24922.julien.IETF@laposte.net> Message-ID: Miika Komu wrote: > * The comparison functions should allow comparison of attribute1 < > attribute2, not just equality. Maybe. Creating a partial order of various attributes is non-trivial, I think. Is AES128 > 3DES? (on what basis? faster? more secure? lower latency?) Is HMAC-MD5 > SHA2-256 ? (No, the comparsion isn't valid. HMAC and non-HMAC uses are not the same, and IPsec always uses HMAC... well. do we? We don't use it for XCBC-AES, right?) I would like to have the partial order. I am not certain that it is something that we will agree to. Perhaps I'm wrong, and the work is trivial. I also don't want applications to ever hard code things like "AES128". Instead, I want them to use something like "ENCRYPTION_STENGTH_MEDIUM", and have some files, a la /etc/services that defines what that means for this system. From paul at xelerance.com Sun Mar 18 10:45:42 2007 From: paul at xelerance.com (Paul Wouters) Date: Sun, 18 Mar 2007 18:45:42 +0100 (CET) Subject: [anonsec] should IPsec policies be partially ordered? In-Reply-To: References: <200703091040.24922.julien.IETF@laposte.net> Message-ID: On Sun, 18 Mar 2007, Michael Richardson wrote: > I also don't want applications to ever hard code things like "AES128". > Instead, I want them to use something like "ENCRYPTION_STENGTH_MEDIUM", > and have some files, a la /etc/services that defines what that means for this system. Reminds me of Draytek Vigor's, which had a "medium" setting meaning modp768 with 1DES...... Not only do you have to agree on the order of this list, you also have to maintain it in the light of faster hardware ove rtime. Paul From Nicolas.Williams at sun.com Sun Mar 18 14:07:43 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sun, 18 Mar 2007 16:07:43 -0500 Subject: [anonsec] should IPsec policies be partially ordered? In-Reply-To: References: <200703091040.24922.julien.IETF@laposte.net> Message-ID: <20070318210743.GL22445@Sun.COM> On Sun, Mar 18, 2007 at 06:45:42PM +0100, Paul Wouters wrote: > On Sun, 18 Mar 2007, Michael Richardson wrote: > > > I also don't want applications to ever hard code things like "AES128". > > Instead, I want them to use something like "ENCRYPTION_STENGTH_MEDIUM", > > and have some files, a la /etc/services that defines what that means for this system. > > Reminds me of Draytek Vigor's, which had a "medium" setting meaning modp768 > with 1DES...... > > Not only do you have to agree on the order of this list, you also have to > maintain it in the light of faster hardware ove rtime. And cryptanalytic advances. From rcteigao at gmail.com Mon Mar 19 03:04:19 2007 From: rcteigao at gmail.com (=?ISO-8859-1?Q?Rafael_Coninck_Teig=E3o?=) Date: Mon, 19 Mar 2007 07:04:19 -0300 Subject: [anonsec] should IPsec policies be partially ordered? In-Reply-To: <20070318210743.GL22445@Sun.COM> References: <200703091040.24922.julien.IETF@laposte.net> <20070318210743.GL22445@Sun.COM> Message-ID: <31b0299f0703190304x755a58edp2f8f27336edec931@mail.gmail.com> > > Not only do you have to agree on the order of this list, you also have to > > maintain it in the light of faster hardware ove rtime. > > And cryptanalytic advances. Maintaining the list in accordance to the cryptanalytic advances is a work that you would already perform. Despite actually having it stored on a file or not, someone would still need to review the policy in the light of new advances. I think having a file to configure BASIC, MEDIUM and HIGH strength encryption would not only improve code/policy readability, but also allow algorithm comparison, since we would already have a partial ordering defined (and better yet, it would be defined at the discretion of the administrator). []'s, Rafael. From miika at iki.fi Mon Mar 19 07:12:35 2007 From: miika at iki.fi (Miika Komu) Date: Mon, 19 Mar 2007 16:12:35 +0200 (EET) Subject: [anonsec] should IPsec policies be partially ordered? In-Reply-To: <31b0299f0703190304x755a58edp2f8f27336edec931@mail.gmail.com> References: <200703091040.24922.julien.IETF@laposte.net> <20070318210743.GL22445@Sun.COM> <31b0299f0703190304x755a58edp2f8f27336edec931@mail.gmail.com> Message-ID: On Mon, 19 Mar 2007, Rafael Coninck Teig?o wrote: > I think having a file to configure BASIC, MEDIUM and HIGH strength > encryption would not only improve code/policy readability, but also > allow algorithm comparison, since we would already have a partial > ordering defined (and better yet, it would be defined at the > discretion of the administrator). The BASIC, MEDIUM and HIGH will be added for the next version of the draft. -- Miika Komu http://www.iki.fi/miika/ From mcr at sandelman.ca Mon Mar 19 08:38:28 2007 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 19 Mar 2007 16:38:28 +0100 Subject: [anonsec] should IPsec policies be partially ordered? In-Reply-To: References: <200703091040.24922.julien.IETF@laposte.net> Message-ID: Paul Wouters wrote: > On Sun, 18 Mar 2007, Michael Richardson wrote: > >> I also don't want applications to ever hard code things like "AES128". >> Instead, I want them to use something like "ENCRYPTION_STENGTH_MEDIUM", >> and have some files, a la /etc/services that defines what that means for this system. > > Reminds me of Draytek Vigor's, which had a "medium" setting meaning modp768 > with 1DES...... > Not only do you have to agree on the order of this list, you also have to > maintain it in the light of faster hardware ove rtime. Not relevant. The choice is not between "medium" vs "3DES". Medium security *WAS* 1DES (vs RC4) ten plus years ago. Of course, there are maintenance issues. The choice is between replacing all the binaries on the machine that use the BTNS IPsec API, or replacing one file that defines what the "medium" profile is. From mcr at sandelman.ca Mon Mar 19 08:44:37 2007 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 19 Mar 2007 16:44:37 +0100 Subject: [anonsec] should IPsec policies be partially ordered? In-Reply-To: References: <200703091040.24922.julien.IETF@laposte.net> <20070318210743.GL22445@Sun.COM> <31b0299f0703190304x755a58edp2f8f27336edec931@mail.gmail.com> Message-ID: Miika Komu wrote: > On Mon, 19 Mar 2007, Rafael Coninck Teig?o wrote: > >> I think having a file to configure BASIC, MEDIUM and HIGH strength >> encryption would not only improve code/policy readability, but also >> allow algorithm comparison, since we would already have a partial >> ordering defined (and better yet, it would be defined at the >> discretion of the administrator). > > The BASIC, MEDIUM and HIGH will be added for the next version of the draft. There are two issues here, which are seperable: 1) should there be abstracted profiles instead of concrete protocols. I claim that applications should never do: if(cipher_algo == AES128) { /* trust user */ } else { /* user is insecure */ } http://www.sandelman.ca/SSW/ietf/ipsec/btns/ietf-btns-ipsec-apireq.html#anchor7 2) should there be a partial order. These are two decisions. I would appreciate feedback on section 7 of the API requirements draft. From rcteigao at gmail.com Mon Mar 19 09:08:39 2007 From: rcteigao at gmail.com (=?ISO-8859-1?Q?Rafael_Coninck_Teig=E3o?=) Date: Mon, 19 Mar 2007 13:08:39 -0300 Subject: [anonsec] should IPsec policies be partially ordered? In-Reply-To: References: <200703091040.24922.julien.IETF@laposte.net> <20070318210743.GL22445@Sun.COM> <31b0299f0703190304x755a58edp2f8f27336edec931@mail.gmail.com> Message-ID: <31b0299f0703190908w1f97e830p3a097a7c8f6e5de1@mail.gmail.com> > There are two issues here, which are seperable: > 1) should there be abstracted profiles instead of concrete protocols. > I claim that applications should never do: > if(cipher_algo == AES128) { /* trust user */ } > else { /* user is insecure */ } > > http://www.sandelman.ca/SSW/ietf/ipsec/btns/ietf-btns-ipsec-apireq.html#anchor7 To quote section 7: "Hard-coding algorithm names into applications should be actively discouraged; there SHOULD be generic "weak" or "strong" indications instead of specific algorithm identifiers." It think hard-coding algorithms should be forbidden, and identifiers should be mandatory. This adds a lot to configurability. We should just define correctly the identifiers and add special cases for when they are not defined (should we default to some algorithm? or return an error?) > 2) should there be a partial order. Yes. We certainly may want to accept stronger algorithms when available, but not always (e.g. when there's not enough processing power for using a strong cypher). []'s, Rafael. From mcr at sandelman.ca Wed Mar 21 09:46:03 2007 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 21 Mar 2007 17:46:03 +0100 Subject: [anonsec] details of IKE/IPsec channel binding Message-ID: <4601614B.3030207@sandelman.ca> At lunch I was discussing the question of what the IKE/IPsec channel binding blog would be. (Nico, did we really miss refreshing draft-ietf-btns-connection-latching-00.txt before it expired? okay... http://www.sandelman.ca/SSW/ietf/ipsec/btns/connection-latching-00.txt if someone needs a copy) oops, anyway, I want to refer to: draft-williams-on-channel-binding-01.txt, section 4.2 suggests to use the host keys. at lunch, I said that this kept making me queezy to have the channel binding only be what amount to be public information. I discovered that my queeziness was because I forgot that the application doing the channel binding itself was going to communicate the channel binding blog via an integral channel. I had previously thought that the channel binding was going to be some *secret*, which had to be communicated carefully or, at least had to have built-in integrity. This is wrong, the application is responsible for that. A GSSAPI application would already have a secure channel in which to put the channel binding. The question is, do we still need to have something as a channel binding that has a stronger binding to the Diffie-Hellman. My thought was to generate another key from SKEYSEED, and do: HMAC-prf(K, concatenation-of-public-keys); and send that as well. This would mean that comparing channel binding blogs is not just a memcpy(), but now involves getting the key (K), and checking the hash. Thoughts? This has API impacts, if we have to provide for checking a channel blog, not just communicating it to the applications for memcpy() check. From Francis.Dupont at fdupont.fr Wed Mar 21 10:05:37 2007 From: Francis.Dupont at fdupont.fr (Francis Dupont) Date: Wed, 21 Mar 2007 18:05:37 +0100 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: Your message of Wed, 21 Mar 2007 17:46:03 +0100. <4601614B.3030207@sandelman.ca> Message-ID: <200703211705.l2LH5bbI028522@tao.fdupont.fr> In your previous mail you wrote: My thought was to generate another key from SKEYSEED, and do: HMAC-prf(K, concatenation-of-public-keys); and send that as well. This would mean that comparing channel binding blogs is not just a memcpy(), but now involves getting the key (K), and checking the hash. Thoughts? => what about to use the INTEG (integrity algorithm) in place of the PRF (pseudo-random function) with the same arguments? (IMHO this is more appropriate to the intended usage.) Regards Francis.Dupont at fdupont.fr From Nicolas.Williams at sun.com Wed Mar 21 10:06:35 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 21 Mar 2007 12:06:35 -0500 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: <4601614B.3030207@sandelman.ca> References: <4601614B.3030207@sandelman.ca> Message-ID: <20070321170635.GD22445@Sun.COM> On Wed, Mar 21, 2007 at 05:46:03PM +0100, Michael Richardson wrote: > At lunch I was discussing the question of what the IKE/IPsec channel binding blog would be. I think you meant "blob" not "blog" :) We've discussed this before and the answer is: - the public key values of the two peers concatenated in this order: channel initiator || channel acceptor or some similar transformation of those two values. The connection latching I-D doesn't state this, but _could_ state this. I'd expected to put this into a separate document. Nico -- From Nicolas.Williams at sun.com Wed Mar 21 10:13:30 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 21 Mar 2007 12:13:30 -0500 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: <4601614B.3030207@sandelman.ca> References: <4601614B.3030207@sandelman.ca> Message-ID: <20070321171330.GE22445@Sun.COM> On Wed, Mar 21, 2007 at 05:46:03PM +0100, Michael Richardson wrote: > at lunch, I said that this kept making me queezy to have the channel binding only > be what amount to be public information. I discovered that my queeziness was because > I forgot that the application doing the channel binding itself was going to communicate > the channel binding blog via an integral channel. Exactly. > I had previously thought that the channel binding was going to be some *secret*, > which had to be communicated carefully or, at least had to have built-in > integrity. This is wrong, the application is responsible for that. A GSSAPI > application would already have a secure channel in which to put the channel > binding. Exactly. > The question is, do we still need to have something as a channel binding that > has a stronger binding to the Diffie-Hellman. No. It suffices that we have the keys used to "authenticate" the peers in IKE (when using BTNS we're not really authenticating them, but we still have such keys). This applies only when using traditional PKI-based IKE, not when using EAP. > My thought was to generate another key from SKEYSEED, and do: No can do. (Originally I'd proposed something just like that.) The reason is, as explained to me by Bill Sommerfeld right before my first presentation on this topic back at, IIRC, IETF59: - Imagine I send a SYN packet protected with some SA, say, SPI 1001, but the SYN|ACK does not arrive in time so I retransmit, only this time I use a new SA (SPI 1002, say) because, say, the old one expired. We can get into a weird situation: the SA that _I_ see as the one used to protect the channel creation trigger is _different_ from the one seen by my peer, so we fail to agree on channel binding! This is how I came to add the notion of "end-point channel bindings" vs. "unique channel bindings." Nico -- From julien.IETF at laposte.net Wed Mar 21 11:16:55 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Wed, 21 Mar 2007 19:16:55 +0100 Subject: [anonsec] IETF68 BTNS Summary Message-ID: <200703211916.55754.julien.IETF@laposte.net> The BTNS WG met shortly on Wednesday at IETF68. We had a short update on the problem and applicability statement, it will be submitted to IESG for publication as Experimental RFC after the IETF general meeting. The core document describing BTNS will be WGLC'ed after the IETF general meeting. The connexion latching describing how to bind a given ULP communication (e.g. a TCP connexion) to a single BTNS SA was presented by Nico Williams. It needs more review and discussion and will then be WGLC'ed. Two API documents were presented: an abstract API (by Michael Richardson) inspired by the GSS API and a C language one (by Miika Komu). They need to be reviewed and discussed on the mailing list before we adopt them as WG draft. Due to lack of time the IKE extensions document could not be presented by Michael Richardson. It needs discussion on the mailing list. Best, -- Julien & Love From julien.IETF at laposte.net Wed Mar 21 11:28:57 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Wed, 21 Mar 2007 19:28:57 +0100 Subject: [anonsec] Correction: IETF68 BTNS Summary Message-ID: <200703211928.58347.julien.IETF@laposte.net> [Apologize for resending, I made a slight error in the previous report] The BTNS WG met shortly on Wednesday at IETF68. The problem and applicability statement will be submitted to IESG for publication as Experimental RFC after the IETF general meeting. We had a short update on the core document describing BTNS, it will be WGLC'ed after the IETF general meeting. The connexion latching describing how to bind a given ULP communication (e.g. a TCP connexion) to a single BTNS SA was presented by Nico Williams. It needs more review and discussion and will then be WGLC'ed. Two API documents were presented: an abstract API (by Michael Richardson) inspired by the GSS API and a C language one (by Miika Komu). They need to be reviewed and discussed on the mailing list before we adopt them as WG draft. Due to lack of time the IKE extensions document could not be presented by Michael Richardson. It needs discussion on the mailing list. Best, -- Julien & Love From kivinen at iki.fi Wed Mar 21 11:52:09 2007 From: kivinen at iki.fi (Tero Kivinen) Date: Wed, 21 Mar 2007 20:52:09 +0200 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: <20070321171330.GE22445@Sun.COM> References: <4601614B.3030207@sandelman.ca> <20070321171330.GE22445@Sun.COM> Message-ID: <17921.32473.971082.12197@fireball.kivinen.iki.fi> Nicolas Williams writes: > - Imagine I send a SYN packet protected with some SA, say, SPI 1001, > but the SYN|ACK does not arrive in time so I retransmit, only this > time I use a new SA (SPI 1002, say) because, say, the old one > expired. > > We can get into a weird situation: the SA that _I_ see as the one > used to protect the channel creation trigger is _different_ from the > one seen by my peer, so we fail to agree on channel binding! > > This is how I came to add the notion of "end-point channel bindings" vs. > "unique channel bindings." As the first SPI 1001 already creted the IKE SA and generated the SKEYSEED, even if you crete new IPsec SA (using the same IKE SA, I assume) the value generated from the SKEYSEED stays same (it is tied to IKE SA not to the IPsec SAs). I assume we are only talking about IKEv2 here, as there is no point of doing any work on the obsoleted protocols. If you really destroyed the IKEv2 SA also between those two packets then you would be seeing different value, but on the other hand same happens, if you happen to recreate new private / public key pair between those exchanges (and as IKEv2 SA will probably be there for several minutes in any case, the only reason to tear it down quickly is the change of the authentication information, like private / public key pair, so that thing happening is not that uncommon when comparing to first case). Anyways you always need to take care of the case where some packet can have two different channels bound to it, for example if some fragments of the final packet arrived through the IPsec SA authenticated using public key X of IKEv2 SA 1, and other parts came from IPsec SA using public key Y of IKEv2 SA 2. This can happen if you use the fragmentation handling from the rfc4301 where you put non-first fragments to one SA (which might be created using the host public / private key pair X) and first fragments are put to the port specific IPsec SA which is created using users public / private key pair Y. So there we are not talking about two different packets having different channel binding values, we are talking of different parts of the one packet having different channel bindings. -- kivinen at safenet-inc.com From Nicolas.Williams at sun.com Wed Mar 21 12:33:34 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 21 Mar 2007 14:33:34 -0500 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: <17921.32473.971082.12197@fireball.kivinen.iki.fi> References: <4601614B.3030207@sandelman.ca> <20070321171330.GE22445@Sun.COM> <17921.32473.971082.12197@fireball.kivinen.iki.fi> Message-ID: <20070321193334.GH22445@Sun.COM> On Wed, Mar 21, 2007 at 08:52:09PM +0200, Tero Kivinen wrote: > Nicolas Williams writes: > > - Imagine I send a SYN packet protected with some SA, say, SPI 1001, > > but the SYN|ACK does not arrive in time so I retransmit, only this > > time I use a new SA (SPI 1002, say) because, say, the old one > > expired. > > > > We can get into a weird situation: the SA that _I_ see as the one > > used to protect the channel creation trigger is _different_ from the > > one seen by my peer, so we fail to agree on channel binding! > > > > This is how I came to add the notion of "end-point channel bindings" vs. > > "unique channel bindings." > > As the first SPI 1001 already creted the IKE SA and generated the > SKEYSEED, even if you crete new IPsec SA (using the same IKE SA, I > assume) the value generated from the SKEYSEED stays same (it is tied > to IKE SA not to the IPsec SAs). I assume we are only talking about > IKEv2 here, as there is no point of doing any work on the obsoleted > protocols. This needs to work for IKEv1. Assuming that the IKE_SA is still around is not a good assumption. Besides, the used of the public key values of the two peers as the channel binding suffices. Nico -- From Nicolas.Williams at sun.com Wed Mar 21 16:06:07 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 21 Mar 2007 18:06:07 -0500 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: <30C65F3A3407B943826897E025135BE67C5D652D96@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <4601614B.3030207@sandelman.ca> <20070321171330.GE22445@Sun.COM> <30C65F3A3407B943826897E025135BE67C5D652D96@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <20070321230606.GA25751@Sun.COM> On Wed, Mar 21, 2007 at 02:41:11PM -0700, Charlie Kaufman wrote: > As you both note, the channel bindings need not be secret. In fact, > life is much simpler if they are not. > > Basing the channel bindings on the public keys of the two endpoints is > secure *if* the two endpoints keep their private keys private (by > either generating them randomly on each run of the protocol and > promptly forgetting them or storing them in a safe place). This will > be true most of the time, so perhaps it's no great sacrifice to demand > it be true all the time. My biggest concern is that it doesn't work > with shared secret or EAP authentication. > > As Nicolas notes, there is a possible problem with winding in any of > the current session keys because the exchange could fail if it takes > place in the middle of a session key rollover. That's sufficiently > unlikely that one could choose to live with it, but it sure is ugly. > > The way I wish I had specified it in the original IKEv2 spec was that > channel bindings would be additional bytes taken from the key > expansion using PRF+ of SKEYSEED of the original IKE SA (i.e., it > would not change even if the IKE SA were rekeyed and all of the IPsec > SAs were rekeyed). This would be a good solution, but might be tricky > to implement depending on how your IPsec implementation is structured. Again, this has to work with IKEv1. Bill so insisted, and I agree. We could use this approach when using IKEv2 so it also works when using EAP, and fallback on public keys when IKEv1 is being used, and oh well if you ever get bitten by the problem I described. Nico -- From kivinen at iki.fi Thu Mar 22 03:12:21 2007 From: kivinen at iki.fi (Tero Kivinen) Date: Thu, 22 Mar 2007 12:12:21 +0200 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: <20070321230606.GA25751@Sun.COM> References: <4601614B.3030207@sandelman.ca> <20070321171330.GE22445@Sun.COM> <30C65F3A3407B943826897E025135BE67C5D652D96@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <20070321230606.GA25751@Sun.COM> Message-ID: <17922.22149.817081.353072@fireball.kivinen.iki.fi> Nicolas Williams writes: > Again, this has to work with IKEv1. Bill so insisted, and I agree. Hmm... the BTNS charter only talks about "Current Internet Protocol security protocol (IPsec) and Internet Key Exchange protocol (IKE)", it does not mention IKEv1 anywhere. The current IPsec and IKE is the RFC430x series, i.e. IKEv2. The old RFC240x series is obsoleted. Also the BTNS charter talks about RFC4301 / RFC4306 (IKEv2) concepts like PAD, and bare RSA keys. > We could use this approach when using IKEv2 so it also works when using > EAP, and fallback on public keys when IKEv1 is being used, and oh well > if you ever get bitten by the problem I described. I argue should we waste time at all to define anything else than the RFC4301 and IKEv2 use. Things were different few years back when this work was started... -- kivinen at safenet-inc.com From Nicolas.Williams at sun.com Thu Mar 22 04:47:48 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 22 Mar 2007 06:47:48 -0500 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: <17922.22149.817081.353072@fireball.kivinen.iki.fi> References: <4601614B.3030207@sandelman.ca> <20070321171330.GE22445@Sun.COM> <30C65F3A3407B943826897E025135BE67C5D652D96@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <20070321230606.GA25751@Sun.COM> <17922.22149.817081.353072@fireball.kivinen.iki.fi> Message-ID: <20070322114747.GF25751@Sun.COM> On Thu, Mar 22, 2007 at 12:12:21PM +0200, Tero Kivinen wrote: > Nicolas Williams writes: > > Again, this has to work with IKEv1. Bill so insisted, and I agree. > > Hmm... the BTNS charter only talks about "Current Internet Protocol > security protocol (IPsec) and Internet Key Exchange protocol (IKE)", > it does not mention IKEv1 anywhere. > > The current IPsec and IKE is the RFC430x series, i.e. IKEv2. The old > RFC240x series is obsoleted. IKEv1 is certainly not obsoleted. And RFC4301 does support IKEv1, does it not? > > We could use this approach when using IKEv2 so it also works when using > > EAP, and fallback on public keys when IKEv1 is being used, and oh well > > if you ever get bitten by the problem I described. > > I argue should we waste time at all to define anything else than the > RFC4301 and IKEv2 use. Things were different few years back when this > work was started... First I'd like to be convinced that the IKE_SA expiration in the middle of channel setup is no big deal. That is, I'd like to see consensus on this. And I'd like input from our AD about whether we need to support IKEv1. Nico -- From kivinen at iki.fi Thu Mar 22 05:26:30 2007 From: kivinen at iki.fi (Tero Kivinen) Date: Thu, 22 Mar 2007 14:26:30 +0200 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: <20070322114747.GF25751@Sun.COM> References: <4601614B.3030207@sandelman.ca> <20070321171330.GE22445@Sun.COM> <30C65F3A3407B943826897E025135BE67C5D652D96@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <20070321230606.GA25751@Sun.COM> <17922.22149.817081.353072@fireball.kivinen.iki.fi> <20070322114747.GF25751@Sun.COM> Message-ID: <17922.30198.844298.692285@fireball.kivinen.iki.fi> Nicolas Williams writes: > IKEv1 is certainly not obsoleted. All obsoleted: 2401 Security Architecture for the Internet Protocol. S. Kent, R. Atkinson. November 1998. (Format: TXT=168162 bytes) (Obsoletes RFC1825) (Obsoleted by RFC4301) (Updated by RFC3168) (Status: PROPOSED STANDARD) 2402 IP Authentication Header. S. Kent, R. Atkinson. November 1998. (Format: TXT=52831 bytes) (Obsoletes RFC1826) (Obsoleted by RFC4302, RFC4305) (Status: PROPOSED STANDARD) 2406 IP Encapsulating Security Payload (ESP). S. Kent, R. Atkinson. November 1998. (Format: TXT=54202 bytes) (Obsoletes RFC1827) (Obsoleted by RFC4303, RFC4305) (Status: PROPOSED STANDARD) 2407 The Internet IP Security Domain of Interpretation for ISAKMP. D. Piper. November 1998. (Format: TXT=67878 bytes) (Obsoleted by RFC4306) (Status: PROPOSED STANDARD) 2408 Internet Security Association and Key Management Protocol (ISAKMP). D. Maughan, M. Schertler, M. Schneider, J. Turner. November 1998. (Format: TXT=209175 bytes) (Obsoleted by RFC4306) (Status: PROPOSED STANDARD) 2409 The Internet Key Exchange (IKE). D. Harkins, D. Carrel. November 1998. (Format: TXT=94949 bytes) (Obsoleted by RFC4306) (Updated by RFC4109) (Status: PROPOSED STANDARD) > And RFC4301 does support IKEv1, does > it not? >From RFC4301: Note: This document mandates support for several features for which support is available in IKEv2 but not in IKEv1, e.g., negotiation of an SA representing ranges of local and remote ports or negotiation of multiple SAs with the same selectors. Therefore, this document assumes use of IKEv2 or a key and security association management system with comparable features. > First I'd like to be convinced that the IKE_SA expiration in the middle > of channel setup is no big deal. That is, I'd like to see consensus on > this. I need to think about this more before making my mind for this. My initial feeling do say that we should bind it to the IKE authentication, i.e. the to the Diffie-Hellman exchange. > And I'd like input from our AD about whether we need to support > IKEv1. Me too... -- kivinen at safenet-inc.com From kent at bbn.com Thu Mar 22 06:38:39 2007 From: kent at bbn.com (Stephen Kent) Date: Thu, 22 Mar 2007 09:38:39 -0400 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: <20070322114747.GF25751@Sun.COM> References: <4601614B.3030207@sandelman.ca> <20070321171330.GE22445@Sun.COM> <30C65F3A3407B943826897E025135BE67C5D652D96@DF-GRTDANE-MSG.exchange.corp.m icrosoft.com> <20070321230606.GA25751@Sun.COM> <17922.22149.817081.353072@fireball.kivinen.iki.fi> <20070322114747.GF25751@Sun.COM> Message-ID: At 6:47 AM -0500 3/22/07, Nicolas Williams wrote: >On Thu, Mar 22, 2007 at 12:12:21PM +0200, Tero Kivinen wrote: >> Nicolas Williams writes: >> > Again, this has to work with IKEv1. Bill so insisted, and I agree. >> >> Hmm... the BTNS charter only talks about "Current Internet Protocol >> security protocol (IPsec) and Internet Key Exchange protocol (IKE)", >> it does not mention IKEv1 anywhere. >> >> The current IPsec and IKE is the RFC430x series, i.e. IKEv2. The old >> RFC240x series is obsoleted. > >IKEv1 is certainly not obsoleted. And RFC4301 does support IKEv1, does >it not? 4301 includes mandatory features that IKEv1 cannot negotiate, so in that sense 4301 assumes use of IKEv2. Steve From Nicolas.Williams at sun.com Fri Mar 23 02:23:27 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 23 Mar 2007 04:23:27 -0500 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: References: <4601614B.3030207@sandelman.ca> <20070321171330.GE22445@Sun.COM> <20070321230606.GA25751@Sun.COM> <17922.22149.817081.353072@fireball.kivinen.iki.fi> <20070322114747.GF25751@Sun.COM> Message-ID: <20070323092326.GK25751@Sun.COM> On Thu, Mar 22, 2007 at 09:38:39AM -0400, Stephen Kent wrote: > >IKEv1 is certainly not obsoleted. And RFC4301 does support IKEv1, does > >it not? > > 4301 includes mandatory features that IKEv1 cannot negotiate, so in > that sense 4301 assumes use of IKEv2. But if we can write connection latching and channel binding specs in a sufficiently neutral way that IKEv1/RFC2401 can be used, wouldn't that be good? I did try to write the connection latching I-D that way. Nico -- From julien.IETF at laposte.net Mon Mar 26 05:03:45 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Mon, 26 Mar 2007 14:03:45 +0200 Subject: [anonsec] WGLC: "Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec" Message-ID: <200703261403.45625.julien.IETF@laposte.net> Folks, We would like to issue a WGLC on the following document before submitting it to IESG for publication as Proposed Standard: "Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec" If you have any comments, please send them to the list and authors without changing the subject line (OTOH if you want to discuss something not directly related to this WGLC please do change the subject line) The WGLC will end on 2007-04-09 (two weeks from now). Best, -- Julien & Love, BTNS chairs. From julien.IETF at laposte.net Mon Mar 26 07:47:54 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Mon, 26 Mar 2007 16:47:54 +0200 Subject: [anonsec] draft-ietf-btns-prob-and-applic submitted to IESG Message-ID: <200703261647.54734.julien.IETF@laposte.net> Folks, The following document has been submitted to IESG for publication as an Informational RFC: Problem and Applicability Statement for Better Than Nothing Security (BTNS) draft-ietf-btns-prob-and-applic-05.txt Attached is the Document Shepherd Write-up that was attached to the submission. Best, -- Julien & Love, BTNS Chairs. -------------- next part -------------- (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The Document Shepherd for this document is Julien Laganier, BTNS co-chair, who reviewed this version of the document and believes this version is ready for forwarding to the IESG. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes, the document had review from both inside and outside the WG. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG is behind this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes (The document has no normative references). (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Yes (The document has no IANA considerations). (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Yes (The document does not contain formal language). (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. The Internet network security protocol suite, IPsec, consisting of IKE, ESP, and AH, generally requires authentication of network layer entities to bootstrap security. This authentication can be based on mechanisms such as pre-shared symmetric keys, certificates and associated asymmetric keys, or the use of Kerberos. The need to deploy authentication information and its associated identities to network layer entities can be a significant obstacle to use of network security. This document explains the rationale for extending the Internet network security suite to enable use of IPsec security mechanisms without authentication. These extensions are intended to protect communication in a "better than nothing" (BTNS) fashion. The extensions may be used on their own (Stand Alone BTNS, or SAB), or may be useful in providing network layer security that can be authenticated by higher layers in the protocol stack, called Channel Bound BTNS (CBB). This document also explains situations in which use of SAB and CBB extensions are appropriate. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? This document is a product of the Better Than Nothing Security (BTNS) working group. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? No. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? The Document Shepherd for this document is Julien Laganier (BTNS co-chair) and the Responsible Area Director is Sam Hartman. From Nicolas.Williams at sun.com Wed Mar 28 15:59:02 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 28 Mar 2007 17:59:02 -0500 Subject: [anonsec] BYPASS OR PROTECT Message-ID: <20070328225901.GD1666@Sun.COM> As you may recall, at last week's IETF 68 meeting I presented the current state of the connection latching I-D. One thing I had added to it was a description of "BYPASS OR PROTECT" -- a way to negotiate the use/non-use of IPsec for packet flows associated with applications that are IPsec-aware and can handle the non-use of IPsec through such means as using TLS/SASL/GSS-API/... for session protection. Sam commented that he thought that Stephen would object, but Stephen did not make any objections at the meeting. Instead Stephen explained that his main concern is that nothing we do here be inconsistent with the access controls of IPsec [RFC4301] -- essentially restating what the WG charter says on this matter. You may also recall that in the case of the core BTNS document the access control issue had been about ensuring that BTNS peers not be allowed to assert traffic selectors that non-BTNS peers are allowed to assert. And recall that we addressed this by providing that the PAD be searched twice, once at authentication time and once at CHILD SA creation time, the latter to find that the asserted traffic selectors do not overlap with ones reserved for non-BTNS peers. My question to Stephen and others: does BYPASS OR PROTECT as specified in the current connection latching I-D fall foul of the RFC4301 access control model? My view is that no, it does not, though it is an extension of the SPD in the RFC4301 model, and that it is needed to in order to support channel binding applications. Without BYPASS OR PROTECT we'll likely see applications resort to using two port numbers: one for PROTECTed traffic and one for BYPASSed traffic -- if connect() on the protected port fails or times out try connect() on the bypassed port). The two-port alternative clearly does not fall foul of the RFC4301 access control model; it follows that use of BYPASS OR PROTECT _for IPsec-aware application port selectors_ does not either. Stephen, Sam, others, care to comment? Nico --