From miika at iki.fi Mon Feb 12 00:11:54 2007 From: miika at iki.fi (Miika Komu) Date: Mon, 12 Feb 2007 10:11:54 +0200 (EET) Subject: [anonsec] btns-api-01 preversion Message-ID: Hi folks, Julien requested an preversion of the BTNS API draft. Here it goes: Abstract IPsec based security is usually transparent for applications and they may not be sure when network connections are protected. This document specifies an API that increases the visibility of IPsec to applications. The API allows applications to use the Stand-alone BTNS mode, control the channel bindigs and control also other network security properties related to IPsec. http://www.iki.fi/miika/docs/draft-komu-btns-api-01-pre1.txt Short diff between 00 and 01-pre1: rewritten almost from scratch and now also contains some real API definitions. The API is not based on GSS and native API anymore. I would like to thank Michael Richardson, Love Hoernquist Aestrand, Nicolas Williams and Julien Laganier for good ideas and input for draft. For the mistakes, you can blame only me :) Todo list: * Lack of details in error values, different attribute types etc. Please provide your suggestions on these. * Storing of channel bindigs to reboot-resistant media (files). * Show compatibility with GSS and SASL (e.g. code by examples) * Server side code examples I hope the basic API design makes sense for you. Please see the appendix for some code examples that hopefully tie all of the functions together in a meaningful way. -- Miika Komu http://www.iki.fi/miika/ From Internet-Drafts at ietf.org Wed Feb 14 12:50:02 2007 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed, 14 Feb 2007 15:50:02 -0500 Subject: [anonsec] I-D ACTION:draft-ietf-btns-prob-and-applic-05.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-btns-prob-and-applic-05.txt -------------- next part -------------- From julien.IETF at laposte.net Thu Feb 15 03:19:52 2007 From: julien.IETF at laposte.net (BTNS co-chair (Julien Laganier)) Date: Thu, 15 Feb 2007 12:19:52 +0100 Subject: [anonsec] Past due milestones of BTNS Message-ID: <200702151219.53678.julien.IETF@laposte.net> Folks, We currently have two past due milestones: 1. Dec 2006 Submit problem and applicability statement to IESG (a+b) 2. Dec 2006 First version of IPsec interfaces draft (e) W.r.t. milestone 1, the problem and applicability statement deliverable, draft-ietf-btns-prob-and-applic has completed WGLC, and the authors have submitted an updated version resolving WGLC comments. The document will soon be submitted to IESG for publication as an Informational RFC, thus completing milestone 1. W.r.t. milestone 2, Miika Komu has kindly agreed to post on the ML a pre-version of his candidate proposal for deliverable (e), and will submit the draft before the cut-off date. Since this is so far the only proposal we've had for deliverable (e), I'd like to encourage people to read it and post comments on the ML. That way Miika can already take them into account in the version he will submit, and we can have a useful discussion in Prague. Hopefully we will then be able to complete milestone 2. Best, --julien From Nicolas.Williams at sun.com Sun Feb 18 20:39:06 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sun, 18 Feb 2007 22:39:06 -0600 Subject: [anonsec] core doc outstanding issues Message-ID: <20070219043906.GR9435@binky.central.sun.com> At IETF66 there was one substantial comment made on draft-ietf-btns-core-01. It was a comment by Stephen Kent about an inconsistency in the PAD tables given in the examples. You can find Stephen's comment at 45:50 and 58:40 in the recording of the meeting[1]. Roughly, it went like this: "I was just going to look it up in RFC4301, but I was surprised in the previous slide [the PAD in example 1] that you had child SAs constrained by network addresses but then said we were doing SPD searches by ID, that's not what occurs to me as the combination of things we'd have there, but I was going to go back and check the spec to see." I seemed to understand what he meant, but I've since lost that understanding. So I've listened to the recording of the meeting and re-read section 4.4.3 of RFC4301 (the one that deals with the PAD) and I can't figure out what Stephen meant or what I'd understood. Specifically I cannot find text in RFC4301, section 4.4.3, that states that the "search SPD by" field of a PAD entry must be correlated with anything else about the PAD entry. Perhaps what Stephen meant was that in our examples we conflated the symbolic name and remote traffic selector fields of the SPD? We did that on purpose to keep the example tables _small_ and legible, but perhaps this merits a note in the text of the I-D, or perhaps we should just have separate columns for this. Once we resolve this I think we can request a WGLC (or perhaps resolve this during a WGLC?). Nico -- From julien.IETF at laposte.net Mon Feb 19 03:01:14 2007 From: julien.IETF at laposte.net (BTNS co-chair (Julien Laganier)) Date: Mon, 19 Feb 2007 12:01:14 +0100 Subject: [anonsec] (no subject) Message-ID: <200702191201.15217.julien.IETF@laposte.net> Folks, we will soon be drafting the agenda for the Prague meeting. Please send us agenda requests. Thanks. From kent at bbn.com Tue Feb 20 06:26:13 2007 From: kent at bbn.com (Stephen Kent) Date: Tue, 20 Feb 2007 09:26:13 -0500 Subject: [anonsec] core doc outstanding issues In-Reply-To: <20070219043906.GR9435@binky.central.sun.com> References: <20070219043906.GR9435@binky.central.sun.com> Message-ID: At 10:39 PM -0600 2/18/07, Nicolas Williams wrote: >At IETF66 there was one substantial comment made on >draft-ietf-btns-core-01. > >It was a comment by Stephen Kent about an inconsistency in the PAD >tables given in the examples. > >You can find Stephen's comment at 45:50 and 58:40 in the recording of >the meeting[1]. Roughly, it went like this: > > "I was just going to look it up in RFC4301, but I was surprised in > the previous slide [the PAD in example 1] that you had child SAs > constrained by network addresses but then said we were doing SPD > searches by ID, that's not what occurs to me as the combination of > things we'd have there, but I was going to go back and check the > spec to see." > 4301 introduced the PAD as a way to ensure that after peer IKE entity was authenticated, it was not allowed to make unconstrained assertions about the set of users that it represented. The PAD provides two ways to impose constraints on what an IKE entity can assert when it negotiates to create SAs: - IDs asserts via the IKE ID - it can impose constraints on the addresses asserted as traffic selectors The relevant text in 4301 is: "Each entry also specifies whether the IKE ID payload will be used as a symbolic name for SPD lookup, or whether the remote IP address provided in traffic selector payloads will be used for SPD lookups when child SAs are created." You have indicated that the example PAD (on the slide in question) was: Child SA Rule Remote ID IDs allowed SPD Search by ---- --------- ----------- ------------- 1 ID 2 ID 3 PUBLICKEY:any ANY by-IP I still find this a somewhat confusing table. For example, in entry #1 it seems to say that the PAD says search by ID, but it also says that child SAs are to be allowed based on "B's network." The 4301 text quoted above provides an exclusive OR option for how to constrain SPD searches, i.e., you either constrain IDs or addresses, so why are there two columns, one for "Child SA ID's allowed" and one for "SPD Search by?" Also, what is an example of an ID (vs. an address) for "B's network?" In 4301 names are defined in 4.4.1.1 and none of the defined name types refers to a network, per se, as opposed to a machine or a person. So there is some ambiguity here. I think we need a table that is more easily mapped to the PAD description in 4301 so as to avoid the sort of ambiguities that I note here, and that I assume prompted my comments during the BTNS meeting. Steve From Nicolas.Williams at sun.com Tue Feb 20 10:30:26 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 20 Feb 2007 12:30:26 -0600 Subject: [anonsec] core doc outstanding issues In-Reply-To: References: <20070219043906.GR9435@binky.central.sun.com> Message-ID: <20070220183026.GI18346@binky.central.sun.com> On Tue, Feb 20, 2007 at 09:26:13AM -0500, Stephen Kent wrote: > At 10:39 PM -0600 2/18/07, Nicolas Williams wrote: > >At IETF66 there was one substantial comment made on > >draft-ietf-btns-core-01. > > > >It was a comment by Stephen Kent about an inconsistency in the PAD > >tables given in the examples. > > > >You can find Stephen's comment at 45:50 and 58:40 in the recording of > >the meeting[1]. Roughly, it went like this: > > > > "I was just going to look it up in RFC4301, but I was surprised in > > the previous slide [the PAD in example 1] that you had child SAs > > constrained by network addresses but then said we were doing SPD > > searches by ID, that's not what occurs to me as the combination of > > things we'd have there, but I was going to go back and check the > > spec to see." > > > > 4301 introduced the PAD as a way to ensure that after peer IKE entity > was authenticated, it was not allowed to make unconstrained > assertions about the set of users that it represented. The PAD > provides two ways to impose constraints on what an IKE entity can > assert when it negotiates to create SAs: > - IDs asserts via the IKE ID > - it can impose constraints on the addresses asserted as > traffic selectors > > The relevant text in 4301 is: > > "Each entry also specifies whether the IKE ID payload will be used as > a symbolic name for SPD lookup, or whether the remote IP address > provided in traffic selector payloads will be used for SPD lookups > when child SAs are created." > > You have indicated that the example PAD (on the slide in question) was: > > Child SA > Rule Remote ID IDs allowed SPD Search by > ---- --------- ----------- ------------- > 1 ID > 2 ID > 3 PUBLICKEY:any ANY by-IP > > > I still find this a somewhat confusing table. For example, in entry > #1 it seems to say that the PAD says search by ID, but it also says > that child SAs are to be allowed based on "B's network." OK, I see that for rules #1 and #2 we should probably search the SPD by IP address (because SPD searching by name is intended for road warriors, which Q and B clearly are not). But I don't think it's actually wrong to search it by peer IP address in those two cases either. I also see that searching the SPD by ID in the case of entry 3, and having wildcard matching in the SPD, would also help simplify writing the SPD. > The 4301 > text quoted above provides an exclusive OR option for how to > constrain SPD searches, i.e., you either constrain IDs or addresses, > so why are there two columns, one for "Child SA ID's allowed" and one > for "SPD Search by?" I don't see how the text you quoted says this. I read the RFC4301 section 4.4.3 text as saying that PAD entries are obtained by matching against the peer ID and then the matched PAD entry constrains the peer's TSes and specifies how to search the SPD -- but I see no correlation betwee those two items (constraints on peer TSes and how to search the SPD). > Also, what is an example of an ID (vs. an > address) for "B's network?" In 4301 names are defined in 4.4.1.1 and > none of the defined name types refers to a network, per se, as > opposed to a machine or a person. So there is some ambiguity here. Huh? RFC4301, section 4.4.1.1 lists these types of SPD symbolic names for when searching the SPD by ID: | For case 1, responder, the identifiers employed in named SPD | entries are one of the following four types: | | a. a fully qualified user name string (email), e.g., | mozart at foo.example.com | (this corresponds to ID_RFC822_ADDR in IKEv2) | | b. a fully qualified DNS name, e.g., | foo.example.com | (this corresponds to ID_FQDN in IKEv2) | | c. X.500 distinguished name, e.g., [WaKiHo97], | CN = Stephen T. Kent, O = BBN Technologies, | SP = MA, C = US | (this corresponds to ID_DER_ASN1_DN in IKEv2, after | decoding) | | d. a byte string | (this corresponds to Key_ID in IKEv2) > I > think we need a table that is more easily mapped to the PAD > description in 4301 so as to avoid the sort of ambiguities that I > note here, and that I assume prompted my comments during the BTNS > meeting. It would help to have a more formal description of the PAD. Nico -- From kent at bbn.com Wed Feb 21 06:22:02 2007 From: kent at bbn.com (Stephen Kent) Date: Wed, 21 Feb 2007 09:22:02 -0500 Subject: [anonsec] core doc outstanding issues In-Reply-To: <20070220183026.GI18346@binky.central.sun.com> References: <20070219043906.GR9435@binky.central.sun.com> <20070220183026.GI18346@binky.central.sun.com> Message-ID: At 12:30 PM -0600 2/20/07, Nicolas Williams wrote: >...as: > > >> Child SA >> Rule Remote ID IDs allowed SPD Search by >> ---- --------- ----------- ------------- >> 1 ID >> 2 ID >> 3 PUBLICKEY:any ANY by-IP >> >> >> I still find this a somewhat confusing table. For example, in entry >> #1 it seems to say that the PAD says search by ID, but it also says >> that child SAs are to be allowed based on "B's network." > >OK, I see that for rules #1 and #2 we should probably search the SPD by >IP address (because SPD searching by name is intended for road warriors, >which Q and B clearly are not). But I don't think it's actually wrong >to search it by peer IP address in those two cases either. If you want to use a peer's IP address in the search, then you should mark the PAD entry to indicate search by address vs. search by ID and then set the address constraints part of the PAD entry appropriately. That is accommodated by the text in 4301; I just noted that the table in the example is inconsistent. >I also see that searching the SPD by ID in the case of entry 3, and >having wildcard matching in the SPD, would also help simplify writing >the SPD. I didn't comment on entry #3. It it clearly designed to allow any public key to be acceptable, which is OK for a last entry in a system supporting BTNS-style authorization. The next column in the table says ANY, which means any address, given that the third column says search by IP address. That is consistent too, so I see no problem with this PAD entry example. The SPD does allow wildcard matching, via the ANY construct for IP addresses, which is what this entry calls for, so I'm not sure what you're getting at here? > > The 4301 > > text quoted above provides an exclusive OR option for how to > > constrain SPD searches, i.e., you either constrain IDs or addresses, >> so why are there two columns, one for "Child SA ID's allowed" and one >> for "SPD Search by?" > >I don't see how the text you quoted says this. > >I read the RFC4301 section 4.4.3 text as saying that PAD entries are >obtained by matching against the peer ID and then the matched PAD entry >constrains the peer's TSes and specifies how to search the SPD -- but I >see no correlation betwee those two items (constraints on peer TSes and >how to search the SPD). Sorry for being a bit sloppy in my text above. Section 4.4.4.3 says that one can use either the IKE ID for SPD searches by name, OR one can use the traffic selector addresses for SPD searches. So the first part of what i said above is clearly correct. However, my comment about the two columns in the example is off the mark. > >> Also, what is an example of an ID (vs. an >> address) for "B's network?" In 4301 names are defined in 4.4.1.1 and >> none of the defined name types refers to a network, per se, as >> opposed to a machine or a person. So there is some ambiguity here. > >Huh? RFC4301, section 4.4.1.1 lists these types of SPD symbolic names >for when searching the SPD by ID: > >| For case 1, responder, the identifiers employed in named SPD >| entries are one of the following four types: >| >| a. a fully qualified user name string (email), e.g., >| mozart at foo.example.com >| (this corresponds to ID_RFC822_ADDR in IKEv2) >| >| b. a fully qualified DNS name, e.g., >| foo.example.com >| (this corresponds to ID_FQDN in IKEv2) >| >| c. X.500 distinguished name, e.g., [WaKiHo97], >| CN = Stephen T. Kent, O = BBN Technologies, >| SP = MA, C = US >| (this corresponds to ID_DER_ASN1_DN in IKEv2, after >| decoding) >| >| d. a byte string >| (this corresponds to Key_ID in IKEv2) yes, these are the name types in 4301 that IU was referring to. It seems clear that "a" and "b" are not names for networks. I'd argue that "c" is also not generally thought of as a name type to be used to spevcify a network. So, that leaves only "d" which is a name for a key, and I also don't think of that as a name for a network. So, my observation still stands. > > I think we need a table that is more easily mapped to the PAD > > description in 4301 so as to avoid the sort of ambiguities that I >> note here, and that I assume prompted my comments during the BTNS >> meeting. > >It would help to have a more formal description of the PAD. yes, that could help, but I think I've pointed to text in 4301 that shows why the example on the slide was not a good one. Steve From Nicolas.Williams at sun.com Wed Feb 21 06:47:16 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 21 Feb 2007 08:47:16 -0600 Subject: [anonsec] core doc outstanding issues In-Reply-To: References: <20070219043906.GR9435@binky.central.sun.com> <20070220183026.GI18346@binky.central.sun.com> Message-ID: <20070221144714.GS18346@binky.central.sun.com> On Wed, Feb 21, 2007 at 09:22:02AM -0500, Stephen Kent wrote: > At 12:30 PM -0600 2/20/07, Nicolas Williams wrote: > >It would help to have a more formal description of the PAD. > > yes, that could help, but I think I've pointed to text in 4301 that > shows why the example on the slide was not a good one. Not a good one, perhaps, but not incorrect either (below I think out loud to convince myself that it's not a good example). As I explained at the meeting at IETF66 one might prefer to to use names instead of TSes for SPD searches if referential integrity between the PAD and the SPD using IP addresses is harder to maintain than using IDs -- which it might well be. I'll make the following changes to the I-D and submit: - change those example PAD entries (all non-BTNS ones) to search the SPD by IP address - change the example SPDs to have a separate column for name, if I still have any PAD entries specifying tha the SPD be searched by ID - add a better description of how the whole PAD constrains the TSes that BTNS peers can assert for their child SAs Now for the thinking out loud... Suppose we use certs with iPAddress SANs, then the PAD can be very simple, and the SPD can be very simple also, with only the PAD mentioning any IP addresses, if at all, and if it does then only, perhaps, to deal with lack of suitable name constraints in the relevant CA certs. The first thought that comes to mind is that given such certs and peers that assert such IDs and nodes that enforce iPAddress == peer IP address (modulo NAT) then there is no real distinction between searching the SPD by peer ID or by peer IP! Also, RFC4301 section 4.4.1.1 does not mention iPAddress SANs, but is that an omission? or are FQDNs really sufficient? And are there real-world deployments of PKIs that support iPAddress SANs and matching name constraints? And why would there be any if IPsec didn't support iPAddress SANs (well, RFC4301 doesn't mention them AFAICS)? Cheers, Nico -- From kent at bbn.com Wed Feb 28 19:25:28 2007 From: kent at bbn.com (Stephen Kent) Date: Wed, 28 Feb 2007 22:25:28 -0500 Subject: [anonsec] core doc outstanding issues In-Reply-To: <20070221144714.GS18346@binky.central.sun.com> References: <20070219043906.GR9435@binky.central.sun.com> <20070220183026.GI18346@binky.central.sun.com> <20070221144714.GS18346@binky.central.sun.com> Message-ID: At 8:47 AM -0600 2/21/07, Nicolas Williams wrote: >On Wed, Feb 21, 2007 at 09:22:02AM -0500, Stephen Kent wrote: >> At 12:30 PM -0600 2/20/07, Nicolas Williams wrote: >> >It would help to have a more formal description of the PAD. >> >> yes, that could help, but I think I've pointed to text in 4301 that >> shows why the example on the slide was not a good one. > >Not a good one, perhaps, but not incorrect either (below I think out >loud to convince myself that it's not a good example). As I explained >at the meeting at IETF66 one might prefer to to use names instead of >TSes for SPD searches if referential integrity between the PAD and the >SPD using IP addresses is harder to maintain than using IDs -- which it >might well be. > >I'll make the following changes to the I-D and submit: > > - change those example PAD entries (all non-BTNS ones) to search the > SPD by IP address > > - change the example SPDs to have a separate column for name, if I > still have any PAD entries specifying tha the SPD be searched by ID > > - add a better description of how the whole PAD constrains the TSes > that BTNS peers can assert for their child SAs > >Now for the thinking out loud... > >Suppose we use certs with iPAddress SANs, then the PAD can be very >simple, and the SPD can be very simple also, with only the PAD >mentioning any IP addresses, if at all, and if it does then only, >perhaps, to deal with lack of suitable name constraints in the relevant >CA certs. Is the idea that a CA will issue certs where each one has an IPaddress as a SAN, and the PAD will say "if you can verify the cert using this trust anchor, then it's OK; perform the SPD entry search using the SAN value (which happens to be an address in this case)? You suggest that one motivation for issuing such certs may be a problem getting suitable name constraints in certs issued by this CA. So, I assume the intent here is to construct PAD entries that achieve the effect of the missing name constraints, as applied to the IP address SAN, right? >The first thought that comes to mind is that given such certs and peers >that assert such IDs and nodes that enforce iPAddress == peer IP address >(modulo NAT) then there is no real distinction between searching the SPD >by peer ID or by peer IP! Your are right that in this case the two forms of searching might be equivalent, if the SPD allowed use of names that were IP addresses, but the SPD makes no provision to use an IPaddress as a name. Page 29 describes the four name types allowed, and IPaddresses are notably absent. >Also, RFC4301 section 4.4.1.1 does not mention iPAddress SANs, but is >that an omission? or are FQDNs really sufficient? And are there >real-world deployments of PKIs that support iPAddress SANs and matching >name constraints? And why would there be any if IPsec didn't support >iPAddress SANs (well, RFC4301 doesn't mention them AFAICS)? 4.4.1.1 says that the use of names for responder lookups in the SPD is designed to accommodate circumstances where use of the address from the initiator's IP address would not be appropriate for a lookup, e.g., because it might not be determinable in advance. The example you gave is one where the address is known in advance, since you described putting it in a cert, but that means the example does not fit the notion that motivates support for name-based searches of the SPD by a responder. So, the question is whether this example is sufficiently compelling to warrant a change to the PAD and SPD text too accommodate it. Also, we need to note that this is not intended to be used by SGs, just by individual hosts, right? Steve From Nicolas.Williams at sun.com Wed Feb 28 20:26:42 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 28 Feb 2007 22:26:42 -0600 Subject: [anonsec] core doc outstanding issues In-Reply-To: References: <20070219043906.GR9435@binky.central.sun.com> <20070220183026.GI18346@binky.central.sun.com> <20070221144714.GS18346@binky.central.sun.com> Message-ID: <20070301042641.GH18346@binky.central.sun.com> On Wed, Feb 28, 2007 at 10:25:28PM -0500, Stephen Kent wrote: > So, the question is whether this example is sufficiently compelling > to warrant a change to the PAD and SPD text too accommodate it. Also, > we need to note that this is not intended to be used by SGs, just by > individual hosts, right? No, it's not sufficiently compelling -- as I wrote, that was a stream of consciousness whereby I convinced myself that the example in our I-D was not a good one. It sufficed to have validation of that thought process; answers to the additional questions therein would be a plus, but not necessary. From Nicolas.Williams at sun.com Wed Feb 28 20:44:16 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 28 Feb 2007 22:44:16 -0600 Subject: [anonsec] core doc outstanding issues In-Reply-To: References: <20070219043906.GR9435@binky.central.sun.com> <20070220183026.GI18346@binky.central.sun.com> <20070221144714.GS18346@binky.central.sun.com> Message-ID: <20070301044415.GJ18346@binky.central.sun.com> BTW, I've submitted a new version of btns-core. And also a new version of btns-connection-latching.