From weiler at tislabs.com Thu Apr 7 11:54:45 2005 From: weiler at tislabs.com (Samuel Weiler) Date: Thu, 7 Apr 2005 14:54:45 -0400 (EDT) Subject: [anonsec] Draft BTNS BOF minutes from IETF-62 Message-ID: Apologies for not getting these to the list earlier. Please send any corrections to me by tomorrow, Friday, April 8th. ------- Sam Weiler (chair): Today is mostly for charter bashing. Joe will give a brief overview presentation Then we'll go through list of items in the charter, milestones. Joe Touch - (Overview Presentation) Sam Hartman (AD) (respond to one of the slides) - From mailing list discussion: self-sign cert & raw RSA keys are only things we are doing, others not in charter. (end of slides) Steve Kent (Kent) - IKE is essentially supporting IPsec, so changing IKE is the same as changing IPsec. IPsec also does access control in SPD which seemed missing. Why not start with TLS. Why start (or target) only with IPsec? Joe Touch (Joe) - Attack against transport, we could either protect the network layer or change all transport layers. Transport layer headers also have copies of network header layer as the authentication of network identities. Kent - How about IPsec access control, exactly about who you are talking to. Joe - Identity in this case means "network layer" identity. Chair - Is this too dangerous? Kent - No, but starting from changing IPsec/IKE is not good. AD - Should focus on the charter. The decision/scope from DC bof is narrower than what Joe would like to do. But since we focus on IPsec, there is a sense of access control based on the first pkt. Kent - That's not access control, that's continuation of auth or session association. Chair - ...(?) Pekka Salova (Savola) - Please clarify how this deal with issues where valid (RST?) packets generated by firewall on path. Joe - Third party should not be sending packet to me. That should be considered an attack. Paul Hoffman (Paul) - We should reset the discussion according to the charter, not Joe's presentation. Kent - What is the purpose of the presentation? Chair - for those who weren't in dc, or who lost the context. Kent - go back to agenda, why are we discussion details? Chair - To find out if items are of sufficient interests and find people to work on. Kent - we should do charter bashing now. Chair - I want to show the list, and let people say we want to do this. Eric Resocorla (Eric) - Something has been snuck in there: "various security protocols in general". We have somewhere btn 10-57 security protocols. Chair - Real work items are c & d. Eric - Should we strike everything and change those to IKE/IPsec? Joe - Basically says that it will not just work/apply to IPsec/IKE, but also to all other security protocols. Chair - Is that ok? Eric - Fine. But "framework" is misleading, Don't think it's a framework. Chair - Do we need a framework according Joe's anonsec doc, or is problem statement ok? AD - App statement is also needed, there are times we do care about identities. it's important to scope the work. Eric - This is a problem, this is a app statement, I don't know what it is so can't decide what i want or not. Chair - Do we want problem statement & framework in the charter? Kent - Why do we say changing IPsec/IKE? Paul - (c) specifically says profile, it's not changing or extending IPsec/IKE. I don't see changing IPsec/IKE. Kent - Profile is part of standard. Chair - Other security protocols are also in the target, why is IPsec sacred? Kent - Should clarify what we want to do with IPsec. Sam - DC BOF already discussed all these issues and most wanted this work. From a process standpoint, want to see how to process your objection without stopping the progress. Kent - Someone who want to do this overall thing...(?) Nicolas William (Nico) - IPsec is the right thing to do here. We heard the arguments, there may be issues. Charlie Kauffman (Charlie) Issue 1 is a bit vague. Does it say we look at IPsec or include other possibilities? And whether now or later to look at other protocols. Chair - Just IPsec for this group and move forward or re-charter. Charlie - Should prevent other people from hijacking this group to do others. Joe - I do this because DC BOF asked what Steve said, don't make it too broad or it will be like IRTF. I also want to continue draft-anonsec, address Steve's concerns on why IPsec. I believe other protocols are already doing/allowing this. I'll address why not transport layer do this problem. Chair - Who else wants to work? Uri Blumenthal(?) - Will read drafts. Paul - Should discuss (d) first. Salova - (b) is the really important. (something about framework...) Chair - Who think this is important enough to take on. Write, not review. Nico - c, d, e Chair - Ff we don't do c/d/e, a/b may be lost. Chair - Blue sheet? David Black (David) - Half a hand for b & e. Chair - Protocol work: Paul - Strong preference on profiles over extensions, easier to implement. But which IKE? Probably IKEv2. Lets decide on which works. Must clarify. IKEv2 already had a bake-off. So should also be considered. Chair - Not a volunteer. Need volunteers. Charlie - Don't believe this needs extension nor profiles, and happy to write down the couter-doc. Chair - If tech analysis (shows it's not needed, ...?) Paul - WIll co-write profiles, probably very short profile needed. Chair - ... Nico - Just a short ID/cert type, should be short. An issue of processing mode, not much work to do there. AD - Didn't I get this text from you? Do you volunteer? Nico - Will do c/d/e. Joe what are you working on? Joe: (a), and maybe b which should be merged to (a). Not c/d/e. Not an expert and don't know how to make IPsec community happy. Paul - Me and Charlie for c/d. not a,b,e. AD - For (b). Russ pointed out what we asked for is unclear. If we want to do (d), we have to clarify. Assume 2401bis, one is a flag, not to be strongly auth. if two people want to talk securely, and flag set, they can communicate securely. Would not be susceptible to MITM attacks, once IKE is established, can do it securely. Another flag in SPD says I am willing to negotiate an SA for traffic that falls into this selector, but access bypass traffic. Implications for SAD/SPD caches. Another flag for SA, will bypass the traffic when failed. People had done this. But that's the 3 types of changes we should provide semantics for. In addition to asking if people want to do this, which of these SPD changes are important? Nico - Too details. Many OS's have this. It is possible to involve link or transport for SA negotiations. Already similar binding to other objects. Just need some interfaces to IPsec. Bill Sommerfeld's draft on IPsec interface requirement. Either do it in this wg, or make sure it's revived. Pekka Nikander (Nikander) - Interface to IPsec crypto services for identity is an important issue. Willing to work on (b). Chair: thanks. Russ Housley (Russ) - (c) is not huge, (d) is the one that concerned me. Where in the SPD & packet processing is unclear. Is it appropriate for DNS lookup? Another choice is plugging both together. A host that has some bypass, some auth, some the best we could do. AD - Implicit to me that we must do that for this to be useful, alongside IPsec. Chair: Who would be happy with ipsec but not this? (about 10 people) Chair: who want both ipsec & btns? (about 40-50) Bill - Produce implementations that could do either, but should not explode when seeing the other. Greg Lebovitz (Greg) - Might need to change local implementations, store/read/match, don't mod the protocol bits-on-the-wire. AD - Agree with the requirement, but stating would be complex. Greg - IKEv2 is not mature enough. Could do this on IKEv2. Chair - So it's bad for v1, why? Greg - Would affect v1 users if we add new id types. Nico - For unknown id type, would the responder blow up, or just doesn't care? The fomer is a bug, the later shouldn't matter for btns. Just mean that we can't do it. Why is that we can't add new id types for IKEv1? Greg - Not can't, just would not like to. Nico - This is optional, so failure is ok. Just don't do btns. Chair - Move on. Bill Sommerfeld (Bill) - (d) wouldn't be a simple extension. Extension to PAD(?) might be right. Chair - Should move on to milestones. Why we don't need ...(?) Paul - Even if BTNS can't coexist with IPsec VPNs, still would like to proceed. AD - Can not guarentee apps to separate usage. Chair - App that can do both? Nico - btns must/must not co-exist? Chair - Question: do we require them to co-exist? AD - Want to place requirements on the 3 options that I said. No. Chair: Nico/Bill/Pekka Nikander for c/d/e. Last one information doc. AD - Won't get consenses on standard track for interfaces, so informational. Will move there. Eric - If (e) is for general (security protocols), why here? AD - For channel binding stuff, must do it somewhere. Eric - Don't read that here. David - Mostly channel binding, and giving advice to design of higher auth. Bill - Standard track concerns. Either define an API or a model of API for information flow. Think it's critical to be on STD track. Paul - Not STD track and not in this wg. Kent worry about we are too far down the track. Other can use non-IPsec. might be generating an API for what we are doing, might include others. might not be a working group. Chair - Not here? how about infomational not API? Chair - who wants (e)? Bill, Nico, Charlie, Pekka N. Chair - who thinks it's bad? Steve? Kent - Issues for secure gateways. Nico - This is API, starts out abstract. Necessary for btns to be useful. Can be elsewhere. AD - Issues for STD track(?), but we will find out when we are done. Don't want to do it here. Chair - Who cares enough to read? West(?): API is more than btns, should not be here. if it's optional, why do apps care? Argue against. Bill - Need an abstract API to channel binding for interop. btns without API is still useful. But channel binding makes it much more useful. Not critical, but reasonable place to do that work. Chair - Stop the line and go to milestones. David - Need spec on what the bits are and what makes it work, not details. Could left for implementations. Eric - don't want 2nd thing David said. Not sure about 1st. Chair - What else do ADs need? AD - Steve are you uncomfortable with this work? Kent - Most people (3 groups) want different thing with same mechanism, but not overlapping motivation. Two of those three don't need IPsec. Joe did address the need for IPsec. AD - charter? Kent - As long as it's not affecting orig IPsec, I am not uncomfortable. AD - Would-be chairs should email Russ & Sam. Chair - Milestones: how long, might be unrealistic. First drafts in 2 month? Nico - Some already exist. First draft (in two months) should be fine. Chair - Like to see if authors agree. Joe - Will write the first two. Chair - Others? No one is saying not realistic. AD - We are done. From iesg-secretary at ietf.org Fri Apr 8 07:45:18 2005 From: iesg-secretary at ietf.org (The IESG) Date: Fri, 08 Apr 2005 10:45:18 -0400 Subject: [anonsec] WG Action: Better-Than-Nothing Security (btns) Message-ID: <200504081445.KAA27353@ietf.org> A new IETF working group has been formed in the Security Area. For additional information, please contact the Area Directors or the WG Chairs. +++ Better-Than-Nothing Security (btns) ====================================== Current Status: Active Working Group Chair(s): Pekka Nikander Love Hornquist Astrand Security Area Director(s): Russell Housley Sam Hartman Security Area Advisor: Sam Hartman Mailing Lists: General Discussion: anonsec at postel.org To Subscribe: http://www.postel.org/anonsec Archive: http://www.postel.org/anonsec Description of Working Group: Current Internet Protocol security protocol (IPsec) and Internet Key Exchange protocol (IKE) present somewhat of an all-or-nothing alternative; these protocols provide protection from a wide array of possible threats, but are sometimes not deployed because of the need for pre-existing credentials. There is significant interest in providing anonymous (unauthenticated) keying for IPsec to create security associations (SAs) with peers who do not possess authentication credentials that can be validated. Examples of such credentials include self-signed certificates or "bare" public keys. This mode would protect against passive attacks but would be vulnerable to active attacks. The primary purpose of this working group is to specify extensions to the IPsec architecture, and possibly extensions or profiles of IKE, so that IPsec will support creation of unauthenticated SAs. The goal of the resulting RFCs is to enable and encourage simpler and more rapid deployment of IPsec in contexts where use of unauthenticated SAs is deemed appropriate, to enable and encourage the use of network security where it has been difficult to deploy--notably, to enable simpler, more rapid deployment. Any IKE and IPsec extensions/profiles developed in this WG MUST NOT undermine the security facilities already defined for IPsec. Specifically, the access control facilities that are central to IPsec must not be degraded when unauthenticated SAs are employed concurrently with authenticated SAs in the same IPsec implementation. Two related problems emerged during the discussion of this problem. First, there is a desire in the KITTEN, RDDP, NFSv4 and potentially other working groups to make use of unauthenticated IPsec SAs, and later cryptographically bind these SAs to applications, which perform their own authentication. The specification of how this binding is performed for IPsec and the specification of how the binding interacts with application authentication protocols are out of scope for this working group. However, interactions between this cryptographic channel binding and IPsec (e.g., the PAD, SPD, SAD, etc.) are expected to be similar to those for the unauthenticated mode with no binding. To avoid duplication of effort, This working group needs to consider how to support channel bindings when developing extensions to IPsec, specifically the PAD and SPD elements. Secondly, BTNS and the channel bindings work both encourage IPsec to be used to secure higher layer protocols. As such we need to determine what information these higher layer protocols need from IPsec. Two proposals are under discussion for providing unauthenticated SA support for IPsec: bare RSA keys transported by IKE and self-signed certificates transported by IKE. The WG has the following specific goals: a) Develop an informational framework document to describe the motivation and goals for having security protocols that support anonymous keying of security associations in general, and IPsec and IKE in particular b) Develop an informational applicability statement, describing a set of threat models with relaxed adversary capability assumptions, to characterize the contexts in which use of unauthenticated SAs is appropriate c) If necessary, specify standards-track IKE extensions or profiles that support one or both of the bare RSA keys or self-signed certificates d) Specify standards-track extensions to the SPD and PAD to support unauthenticated SAs for IPsec and cryptographic channel bindings for IPsec e) Develop an informational document describing the interfaces that IPsec implementations should provide to allow IPsec SAs to be used to secure higher layer protocols The final goal is expected to complement work going on elsewhere in establishing best current practice for higher layer protocols secured by IPsec. From mcr at sandelman.ottawa.on.ca Fri Apr 8 08:46:24 2005 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Fri, 08 Apr 2005 11:46:24 -0400 Subject: [anonsec] Automatic detection of BTNS capability References: <20050314163135.BB59C28507@sierra.rtfm.com> <1110824268.27077.155.camel@thunk> Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20050408/79128073/attachment.bin From mcr at sandelman.ottawa.on.ca Fri Apr 8 08:55:03 2005 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Fri, 08 Apr 2005 11:55:03 -0400 Subject: [anonsec] when to give up on BTNS References: Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20050408/7cb54fbc/attachment.bin From mcr at sandelman.ottawa.on.ca Fri Apr 8 09:10:42 2005 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Fri, 08 Apr 2005 12:10:42 -0400 Subject: [anonsec] Automatic detection of BTNS capability References: <4235DDB4.5020205@isi.edu> <20050314192721.0772D28529@sierra.rtfm.com> <20050314191900.GN1007@binky.Central.Sun.COM> Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20050408/1ea9fbc7/attachment.bin From mcr at sandelman.ottawa.on.ca Fri Apr 8 09:40:55 2005 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Fri, 08 Apr 2005 12:40:55 -0400 Subject: [anonsec] what kind of phase 2 SAs are we negotiating? Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20050408/d1634c94/attachment.bin From Nicolas.Williams at sun.com Fri Apr 8 10:35:00 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 8 Apr 2005 12:35:00 -0500 Subject: [anonsec] what kind of phase 2 SAs are we negotiating? In-Reply-To: References: Message-ID: <20050408173500.GD5837@binky.Central.Sun.COM> On Fri, Apr 08, 2005 at 12:40:55PM -0400, Michael Richardson wrote: > > Here is a question that I wish to pose: > what kind of phase 2 things are we negotiating? > > Fundamentally, this is a question about tunnel vs transport mode, but > there are now significant additional items to concern oneself > about. IMO, transport only. > Given two full-citizen (non-NAT'ed, globally routable, globally unique) nodes > on the internet, they could negotiate anything they wish. They can offer a > multitude of possibilities up to 64K UDP packet size for IKE. > That's not what concerns me. > > What I want to know is if an initiator node using NAT-Traversal is allowed to > participate. (double-NAT out of scope for this message) NAT-T brings into the matter the same issues as mobility and credential changes. Namely, BTNS, in BITS-mode implementations anyways, will have to rely on making new PAD entries in a leap-of-faith manner, but these PAD entries have to persist and be unique (one PAD entry per-peer IP address), which clearly conflicts with NAT-T and mobility scenarios in which multiple peers can share a single address either concurrently or sequentially. Therefore, BTNS, in BITS-mode implementations anyways, will be useful only in scenarios where you know a priori which peer addresses will be used with BTNS -- i.e., the usefulness of this is rather limited; it's just enough to cover Joe's primary use case. Now, I can see BTNS as working somewhat (Ok, significantly) differently in native mode IPsec implementations, where we can involve the transport protocols (and applications) in policy matters. When I stated, at the last BoF, that BTNS would not be very useful without APIs, what I meant is that for BTNS to be really useful we need native IPsec... ...that with native IPsec, and the interfaces between IPsec and transport and application layers that that (in my mind) implies, we can express temporary, rather than persistent, peer/public key bindings on a per-connection or per-datagram basis, with application knowledge of peers' BTNS credentials (raw public keys), such that responsibility for authorization is moved from l3 to l7. (Channel bindings then simplify matters for applications.) Cheers, Nico -- From hartmans-ietf at mit.edu Fri Apr 8 11:40:45 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Fri, 08 Apr 2005 14:40:45 -0400 Subject: [anonsec] what kind of phase 2 SAs are we negotiating? In-Reply-To: (Michael Richardson's message of "Fri, 08 Apr 2005 12:40:55 -0400") References: Message-ID: >>>>> "Michael" == Michael Richardson writes: Michael> Here is a question that I wish to pose: what kind of Michael> phase 2 things are we negotiating? Michael> Fundamentally, this is a question about tunnel vs Michael> transport mode, but there are now significant additional Michael> items to concern oneself about. In general I'd expect transport mode SAs to be used. There was discussion on the list earlier suggesting that transport or tunnel was OK provided it was end-to-end. I.E. you should not use BTNS to "securely" route a network. I'm OK if that's what we decide. However I'd encourage people to read draft-ietf-l3vpn-ipsec-2547 and draft-ietf-l3vpn-gre-2547. These drafts are best not read on a full stomach and should perhaps not be read with sharp objects near by. Briefly the l3vpn people want a way of tunneling a certain kind of MPLS VPN over IP. I'm blocking draft-ietf-l3vpn-gre-2547 because there's no security solution at all and because draft-ietf-l3vpn-ipsec-2547 makes it clear that static configuration is not appropriate. The security goals are fairly limited: it needs to be as secure as existing MPLS. I.E. an off-path attacker should not be able to inject packets. It may well be that BTNS tunnels is the best solution we can come up with for the L3VPN folks. They seem to think configuring a full IKE infrastructure is too much work. Just some food for thought, --Sam From touch at ISI.EDU Fri Apr 8 11:49:26 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 08 Apr 2005 11:49:26 -0700 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: References: <20050314163135.BB59C28507@sierra.rtfm.com> <1110824268.27077.155.camel@thunk> Message-ID: <4256D236.6020708@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Richardson wrote: >>>>>>"Bill" == Bill Sommerfeld writes: > > Bill> On Mon, 2005-03-14 at 11:12, Eric Rescorla wrote: > >> The other option is to start sending traffic right away and do the IKE > >> handshake in parallel. Then if the IKE handshake completes you switch > >> over. Obviously, this makes sense in the face of the "no active > >> attacks" assumption, but it seems like a fairly substantial change to > >> the IPsec model... > > Bill> yes, though I believe the some of the opportunistic IPsec folk may > Bill> already have running code for the latter model. > > No, our version of OE does not do IKE in parallel with traffic. > > We thought about that a lot, but decided not to do that for complexity > reasons. > > My opinion: > a) either BTNS is configured on a per-IP/per-block basis, > with 0.0.0.0/0 being an option. > > b) ability to do BTNS is communicated in-band to another protocol. > I.e. via TCP option or IP option. Or IKE. ... > (b) is potentially architecturally cleaner. Agreed. Yes, there are problems with IKE and firewalls, NATs, etc. But layering IKE on top of other protocols (e.g., DNS ;-) just to get around filters seems unproductive. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVtI2E5f5cImnZrsRAvJnAJ0bQ2JLr8MOSiZVCBjaFzWg4RirKACgzer4 lmLfuxzUu3pDPr/NnnKKfhg= =dJmu -----END PGP SIGNATURE----- From touch at ISI.EDU Fri Apr 8 11:52:21 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 08 Apr 2005 11:52:21 -0700 Subject: [anonsec] what kind of phase 2 SAs are we negotiating? In-Reply-To: <20050408173500.GD5837@binky.Central.Sun.COM> References: <20050408173500.GD5837@binky.Central.Sun.COM> Message-ID: <4256D2E5.1000603@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Williams wrote: > On Fri, Apr 08, 2005 at 12:40:55PM -0400, Michael Richardson wrote: > >>Here is a question that I wish to pose: >> what kind of phase 2 things are we negotiating? >> >>Fundamentally, this is a question about tunnel vs transport mode, but >> there are now significant additional items to concern oneself >> about. > > > IMO, transport only. I don't see how it matters. Yes, there are security implications to setting up tunnels with BTNS, but ditto for tunnels with improperly secured passwords. I don't think the technology ought to set policy; that's for the user to determine. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVtLlE5f5cImnZrsRAp3IAKDpXTm/UTT9rAvtencPJvoHW8rq/wCdFP2A Jyr/TKzjByBjWn81ar7mLww= =EEMc -----END PGP SIGNATURE----- From touch at ISI.EDU Fri Apr 8 11:54:11 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 08 Apr 2005 11:54:11 -0700 Subject: [anonsec] what kind of phase 2 SAs are we negotiating? In-Reply-To: References: Message-ID: <4256D353.8020507@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sam Hartman wrote: >>>>>>"Michael" == Michael Richardson writes: > > > Michael> Here is a question that I wish to pose: what kind of > Michael> phase 2 things are we negotiating? > > Michael> Fundamentally, this is a question about tunnel vs > Michael> transport mode, but there are now significant additional > Michael> items to concern oneself about. > > > In general I'd expect transport mode SAs to be used. There was > discussion on the list earlier suggesting that transport or tunnel was > OK provided it was end-to-end. I.E. you should not use BTNS to > "securely" route a network. Agreed. But that's not something, IMO, that the technology can enforce (vs. using tunnels to the endpoint for whatever reason). While we can avoid that by forcing tunnel mode to be forbidden for BTNS, users can always tunnel over transport mode anyway, so there's no real point to pushing the recommendation into the specification, IMO. Yes, the applicability statement should address this, but, IMO, not the solution. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVtNTE5f5cImnZrsRAgUNAJ9E7OFltJW2dbYJ7LASKnPrGGK9rQCeJqfy GPtMoCAwyJ4hMTLcwKlfhGU= =Tc8x -----END PGP SIGNATURE----- From hartmans-ietf at mit.edu Fri Apr 8 11:58:27 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Fri, 08 Apr 2005 14:58:27 -0400 Subject: [anonsec] what kind of phase 2 SAs are we negotiating? In-Reply-To: <4256D2E5.1000603@isi.edu> (Joe Touch's message of "Fri, 08 Apr 2005 11:52:21 -0700") References: <20050408173500.GD5837@binky.Central.Sun.COM> <4256D2E5.1000603@isi.edu> Message-ID: >>>>> "Joe" == Joe Touch writes: Joe> I don't see how it matters. Yes, there are security Joe> implications to setting up tunnels with BTNS, but ditto for Joe> tunnels with improperly secured passwords. I don't think the Joe> technology ought to set policy; that's for the user to Joe> determine. One of the things we signed up to deliver is an applicability statement to help users figure out when BTNS is an appropriate technology. So, yes, it is our job to set policy at that level. Similarly it is our job to give the IETF advice on when BTNS is the right technology to use. It would be reasonable for us to have explicit rules or general advice. From sommerfeld at sun.com Fri Apr 8 12:42:14 2005 From: sommerfeld at sun.com (Bill Sommerfeld) Date: Fri, 08 Apr 2005 15:42:14 -0400 Subject: [anonsec] what kind of phase 2 SAs are we negotiating? In-Reply-To: <4256D353.8020507@isi.edu> References: <4256D353.8020507@isi.edu> Message-ID: <1112989333.10649.14.camel@thunk> On Fri, 2005-04-08 at 14:54, Joe Touch wrote: > Agreed. But that's not something, IMO, that the technology can enforce > (vs. using tunnels to the endpoint for whatever reason). While we can > avoid that by forcing tunnel mode to be forbidden for BTNS, users can > always tunnel over transport mode anyway, so there's no real point to > pushing the recommendation into the specification, IMO. Actually, there is, and it comes down to the difference between "tunneling in transport mode" (by mutual consent) and true tunnel mode. If the tunnel inside address != the tunnel outside address, a malicious initiator could potentially subvert routing and steal traffic. i.e., i initiate from whatever address I'm at and say my inner selectors are 198.41.0.4; if the peer's policy accepts those selectors, the peer may wind up sending traffic for a.root-servers.net to me through the tunnel. (On the other hand, if the inner addresses are configured on each end -- with the tunnel just being an application running over BTNS/ipsec then BTNS would be a fine way to set up an encrypted tunnel by mutual consent.) to avoid traffic-vacuuming attacks we're going to need to tightly constrain the selectors for tunnel mode if we allow tunnel mode at all. for btns use we presumably want to limit the src and dst addresses such that the inner and outer addresses are the same, so the capabilities are pretty much the same as transport mode with the exception that the packets are bigger.. - Bill From touch at ISI.EDU Fri Apr 8 13:39:33 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 08 Apr 2005 13:39:33 -0700 Subject: [anonsec] what kind of phase 2 SAs are we negotiating? In-Reply-To: <1112989333.10649.14.camel@thunk> References: <4256D353.8020507@isi.edu> <1112989333.10649.14.camel@thunk> Message-ID: <4256EC05.1080408@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Sommerfeld wrote: > On Fri, 2005-04-08 at 14:54, Joe Touch wrote: > >>Agreed. But that's not something, IMO, that the technology can enforce >>(vs. using tunnels to the endpoint for whatever reason). While we can >>avoid that by forcing tunnel mode to be forbidden for BTNS, users can >>always tunnel over transport mode anyway, so there's no real point to >>pushing the recommendation into the specification, IMO. > > Actually, there is, and it comes down to the difference between > "tunneling in transport mode" (by mutual consent) and true tunnel mode. This is only because transport mode isn't - it applies only to certain payload (transport) protocols (TCP, SCTP, UDP); if it were truly 'transport', it would accomodate any IP payload (transport) protocol and verify contents as needed. IP inside IP isn't properly checked, so yes, this is different, but also known. But that has nothing to do with telling people not to use tunnel mode with BTNS; it might in fact force them to use tunnels over transport where that's not what they wanted to do. > If the tunnel inside address != the tunnel outside address, a malicious > initiator could potentially subvert routing and steal traffic. > > i.e., i initiate from whatever address I'm at and say my inner selectors > are 198.41.0.4; if the peer's policy accepts those selectors, the peer > may wind up sending traffic for a.root-servers.net to me through the > tunnel. > > (On the other hand, if the inner addresses are configured on each end -- > with the tunnel just being an application running over BTNS/ipsec then > BTNS would be a fine way to set up an encrypted tunnel by mutual > consent.) You just said this wasn't any good because addresses outside the tunnel could leak in (which is true), or at least that IPsec wouldn't validate them. So no, mutual consent is insufficient. You need additional checks of the inner address to be equivalent. > to avoid traffic-vacuuming attacks we're going to need to tightly > constrain the selectors for tunnel mode if we allow tunnel mode at all. Not any more than any other tunnel-mode use needs to, IMO. I.e., there's no difference between using BTNS vs. using a key with a different level of trust; in both cases, the streams can cross. That sort of policy management framework doesn't exist elsewhere in the IPsec framework, and I don't see why this is a new version that needs more attention. > for btns use we presumably want to limit the src and dst addresses such > that the inner and outer addresses are the same, so the capabilities are > pretty much the same as transport mode with the exception that the > packets are bigger.. > > - Bill BTNS could still be useful (or as useful as anything else, IMO) for tunnels that had separately negotiated addresses; the key issue is that the addresses are checked. So that would mean tunnel mode with [*,*] addresses might be considered dangerous, but they are already anyway, IMO. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVuwFE5f5cImnZrsRAv6bAJoCUIIk4l8FPhRJO2fajtUsknlE4gCg+HWV 2ByH3Qjk1OwOZEWJa6KecjI= =wLuX -----END PGP SIGNATURE----- From mcr at sandelman.ottawa.on.ca Sat Apr 9 08:39:31 2005 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Sat, 09 Apr 2005 11:39:31 -0400 Subject: [anonsec] what kind of phase 2 SAs are we negotiating? References: <20050408173500.GD5837@binky.Central.Sun.COM> Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20050409/c9153cfe/attachment.bin From mcr at sandelman.ottawa.on.ca Sat Apr 9 08:44:31 2005 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Sat, 09 Apr 2005 11:44:31 -0400 Subject: [anonsec] Automatic detection of BTNS capability References: <20050314163135.BB59C28507@sierra.rtfm.com> <1110824268.27077.155.camel@thunk> <4256D236.6020708@isi.edu> Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20050409/7d981017/attachment.bin From Nicolas.Williams at sun.com Mon Apr 11 08:16:06 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 11 Apr 2005 10:16:06 -0500 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: References: <20050314163135.BB59C28507@sierra.rtfm.com> <1110824268.27077.155.camel@thunk> <4256D236.6020708@isi.edu> Message-ID: <20050411151605.GD5837@binky.Central.Sun.COM> On Sat, Apr 09, 2005 at 11:44:31AM -0400, Michael Richardson wrote: > > >>>>> "Joe" == Joe Touch writes: > >> b) ability to do BTNS is communicated in-band to another protocol. > >> I.e. via TCP option or IP option. > > Joe> Or IKE. > > That was option (a). You just try IKE. > > The point is, if the IKE port is blocked (perhaps by an attacker!) you have > an effective bid-down attack. We need a way for the end points to say, "I > could have done BTNS". But you need a way to get the "I could have done BTNS" message across with integrity protection. If you're not doing that at the IPsec layer, you kinda have to do it at the application layer. Since the attacker is active, in this scenario, you need a way to authenticate the peers (which BTNS doesn't provide). Except in the case where you would have used channel bindings in an application that can do authentication at the app layer, you can't protect the message, and the best you can do then is to trade off between DoS and downgrade attacks. > >> (b) is potentially architecturally cleaner. > > Joe> Agreed. > > Joe> Yes, there are problems with IKE and firewalls, NATs, etc. But > Joe> layering IKE on top of other protocols (e.g., DNS ;-) just to get > Joe> around filters seems unproductive. > > I think you think I suggested running IKE in port 53 or something. > Is that what you think I said? Hmmm. Or port 80 ;) Nico -- From touch at ISI.EDU Mon Apr 11 09:26:55 2005 From: touch at ISI.EDU (Joe Touch) Date: Mon, 11 Apr 2005 09:26:55 -0700 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: References: <20050314163135.BB59C28507@sierra.rtfm.com> <1110824268.27077.155.camel@thunk> <4256D236.6020708@isi.edu> Message-ID: <425AA54F.8040607@isi.edu> Michael Richardson wrote: >>>>>>"Joe" == Joe Touch writes: > > >> b) ability to do BTNS is communicated in-band to another protocol. > >> I.e. via TCP option or IP option. > > Joe> Or IKE. > > That was option (a). You just try IKE. > > The point is, if the IKE port is blocked (perhaps by an attacker!) you have > an effective bid-down attack. We need a way for the end points to say, "I > could have done BTNS". If IKE is blocked, I can reinvent IKE on a non-blocked port, but otherwise all I'm doing is fighting a port block. That's not what security protocols are designed to address. > >> (b) is potentially architecturally cleaner. > > Joe> Agreed. > > Joe> Yes, there are problems with IKE and firewalls, NATs, etc. But > Joe> layering IKE on top of other protocols (e.g., DNS ;-) just to get > Joe> around filters seems unproductive. > > I think you think I suggested running IKE in port 53 or something. > Is that what you think I said? That's what OE does (IMO, effectively) by using DNS messages. ;-) Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050411/5fff3cb6/signature.bin From kent at bbn.com Mon Apr 11 09:22:37 2005 From: kent at bbn.com (Stephen Kent) Date: Mon, 11 Apr 2005 12:22:37 -0400 Subject: [anonsec] what kind of phase 2 SAs are we negotiating? In-Reply-To: <4256EC05.1080408@isi.edu> References: <4256D353.8020507@isi.edu> <1112989333.10649.14.camel@thunk> <4256EC05.1080408@isi.edu> Message-ID: At 1:39 PM -0700 4/8/05, Joe Touch wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > > >Bill Sommerfeld wrote: >> On Fri, 2005-04-08 at 14:54, Joe Touch wrote: >> >>>Agreed. But that's not something, IMO, that the technology can enforce >>>(vs. using tunnels to the endpoint for whatever reason). While we can >>>avoid that by forcing tunnel mode to be forbidden for BTNS, users can >>>always tunnel over transport mode anyway, so there's no real point to >>>pushing the recommendation into the specification, IMO. >> >> Actually, there is, and it comes down to the difference between >> "tunneling in transport mode" (by mutual consent) and true tunnel mode. > >This is only because transport mode isn't - it applies only to certain >payload (transport) protocols (TCP, SCTP, UDP); if it were truly >'transport', it would accomodate any IP payload (transport) protocol and >verify contents as needed. IP inside IP isn't properly checked, so yes, >this is different, but also known. The term "transport" was chosen explicitly to indicate that it was designed to carry transport layer protocols of the sort cited above. The term is appropriate and evocative. Steve From lha at it.su.se Wed Apr 13 11:32:34 2005 From: lha at it.su.se (=?iso-8859-1?q?Love_H=F6rnquist_=C5strand?=) Date: Wed, 13 Apr 2005 20:32:34 +0200 Subject: [anonsec] Introducing the chairs Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 477 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20050413/2b0349f8/attachment.bin From hartmans-ietf at mit.edu Wed Apr 13 14:39:21 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Wed, 13 Apr 2005 17:39:21 -0400 Subject: [anonsec] Introducing the chairs In-Reply-To: (Love =?iso-8859-1?q?H=F6rnquist_=C5strand's?= message of "Wed, 13 Apr 2005 20:32:34 +0200") References: Message-ID: >>>>> "Love" == Love H?rnquist ?strand writes: Love> Folks, Love> As you should now by now, the BTNS working group has now Love> been chartered. Pekka and I have been assigned as the Love> co-chairs. We had a brief face to face meeting in Stockholm Love> last week, and talked about the next few months until the Love> Paris meeting; more about that later. I'd like to thank both Pekka and Love for agreeing to be chairs. I think they are both going to be great chairs and I look forward to working with them and with the working group. I've previously worked with Love in the krb-wg and in implementing Kerberos. He has been an important voice for limiting complexity and for following through on making sure we addressed potential security issues. Love has also done a great job of doing security analysis for ongoing work in secure shell and in Kerberos. I have not had the pleasure of working with Pekka before. However I have watched his work in HIP and have had some interactions since he joined the IAB. Together I think we've found a great group of chairs. From mcr at sandelman.ottawa.on.ca Thu Apr 28 06:31:46 2005 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Thu, 28 Apr 2005 09:31:46 -0400 Subject: [anonsec] what kind of phase 2 SAs are we negotiating? References: <20050408173500.GD5837@binky.Central.Sun.COM> Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20050428/0c926c9b/attachment.bin From mcr at sandelman.ottawa.on.ca Thu Apr 28 06:43:29 2005 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Thu, 28 Apr 2005 09:43:29 -0400 Subject: [anonsec] Automatic detection of BTNS capability References: <20050314163135.BB59C28507@sierra.rtfm.com> <1110824268.27077.155.camel@thunk> <4256D236.6020708@isi.edu> <425AA54F.8040607@isi.edu> Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20050428/12ba8f12/attachment.bin From touch at ISI.EDU Thu Apr 28 07:54:10 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 28 Apr 2005 07:54:10 -0700 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: References: <20050314163135.BB59C28507@sierra.rtfm.com> <1110824268.27077.155.camel@thunk> <4256D236.6020708@isi.edu> <425AA54F.8040607@isi.edu> Message-ID: <4270F912.3050503@isi.edu> Michael Richardson wrote: >>>>>>"Joe" == Joe Touch writes: > > >> The point is, if the IKE port is blocked (perhaps by an attacker!) you > >> have an effective bid-down attack. We need a way for the end points > >> to say, "I could have done BTNS". > > Joe> If IKE is blocked, I can reinvent IKE on a non-blocked port, but > Joe> otherwise all I'm doing is fighting a port block. That's not what > Joe> security protocols are designed to address. > > Yes, but in the VPN situation, one knows a-priori that there should be a > VPN, and one can respond to a port-blocked by not transmitting sensitive > traffic. IMO, that should be done anyway. > I think, btw, we should proceed with "just try IKE". > Like OE, I think we to describe an abstracted concecptual model that one > can have different classes of traffic (implementable in current SPD). Can you explain this further? > We may want to describe a way of caching both positive and negative > discoveries about the peer (including ssh-type leap-of-faith). That seems like a useful extension to IKE but orthogonal to BTNS. I.e., all IKE conversatins benefit from such caching, don't they? If so, that seems like it could be factored out... > I would like to have us describe TCP and SCTP options that say "I could > have done BTNS", which may optionally be sent. We may also want to describe > similiar options for protocols that are important to us (BGP, SMTP) that > could say the same thing. In many cases, these notifications could certainly > be removed by an attacker --- but we are no worse than before, and the > notifications may serve to remove non-malicious blocks. These seem like 'channel binding options' - though I don't know in what protocol they might appear, they are part of the transport or application protocol knowing that security is happening at other layers, right? If so, that'd be part of the channel bindings doc(s), right? > Joe> Yes, there are problems with IKE and firewalls, NATs, etc. But > Joe> layering IKE on top of other protocols (e.g., DNS ;-) just to get > Joe> around filters seems unproductive. > > >> I think you think I suggested running IKE in port 53 or something. Is > >> that what you think I said? > > Joe> That's what OE does (IMO, effectively) by using DNS messages. ;-) > > Yes, I agree. > But, I'm asking *you* if that's what you meant: run IKE on port 53. I'm > trying to understand your above statement. It was reductio ad absurdum. The point was that protocols for network management and configuration, which is what I consider IKE and OE, need to be able to run on well-known ports. The fact that ports are blocked is NOT a reason to create per-protocol designs to get around that; all that would mean is that ports cease to be the way we identify application protocols. We already know a few ways to hide traffic from one port in another, to run DNS over HTTP, or HTTP over DNS, etc. If we need to run IKE over these protocols to get around port blocking, so be it, but that's orthogonal to _their_ design. However, I beleive that OE chose to put key info in the DNS partly to combine IKE-like keying, opportunistic distribution of keys, AND a mechanism that natively used the DNS port. I don't see us doing that here; IMO, we ought to extend IKE as little as possible to get what we want done. If then there are equivalent OE extensions to support BTNS, that's fine too. > The difference between running DNS on port 53 (to get capability > information) vs running IKE on port 53 is that it uses cacheable, proxy-able, > NAT'able, well published protocol. How is DNS NAT'able? What does it mean to ask someone behind a NAT about an IP address, and how does it get translated? Sure, it's cacheable, and proxyable, but the DNS isn't NAT'able. If you don't like 53, pick 446 (HTTPS). The point is more that we already know how to bury protocols behind non-native ports (and their limitations) as a separate issue. > (No surprises for any net-admins, no queries to machines that aren't > expected to receive traffic). > > The communication is with another node (the DNS server), which may not be > on the same forwarding path (vulnerable to the same attackers), and for which > we have a published protocol that explains how to do do integrity protection. Same for HTTPS, which might be a better example of what I was getting at. We understand some of the reasons you chose to put the info in the DNS, but we're starting with IKE, and BTNS isn't about solving the IKE port blocking problem any more than OE is about solving the DNS port blocking problem. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050428/0aa4451a/signature.bin From pekka.nikander at nomadiclab.com Fri Apr 29 05:57:55 2005 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Fri, 29 Apr 2005 15:57:55 +0300 Subject: [anonsec] rfc2401bis-06: Why there are no names in SAs? Message-ID: [Excuse for cross-posting; followups to ipsec only.] Folks, While reading rfc2401bis-06 for considering BTNS, I came up with one serious architectural question. At this point of time I don't know if this really relates to BTNS or not, but it seems to have some larger relevance in any case. The essence of this question boils down to the nature of IP addresses. While reading rfc2401bis, it becomes apparent that it is very much build around the model that the IP addresses used by different hosts are considered to be stable, or at least divisible into different security classes in a static manner. While that may be fine for most if not all current purposes of IPsec, I am afraid that the Internet in general is moving away from that notion. However, in addition to the selectors based on this world view, the SPD and PAD also have now support for "names", mainly meant to be used in situations where at least one of the IPsec devices is an end-host (rather than a security gateway). The support for these higher-layer, symbolic identifiers seems to be sufficient for key management and outgoing traffic. What seems to be especially good is the use of names in linking PAD and SPD entries together (end of section 4.4.3.4). What seems to be missing is support for incoming traffic. More specifically, what I am missing is either a) names embedded in (inbound) SAD entries, or b) back pointers from (inbound) SAD entries to corresponding SPD entries If either of them were in place, that would allow incoming packets to be tagged with names. Those names could then, optionally, be available to apps above. Furthermore, and probably more importantly, tagging the SAs with names would make it also easier to handle with potential stale SAs as the SPD is dynamically changed. Now, is there a specific reason why the (inbound) SAD entries are not tagged/linked with their corresponding SPD entries? --Pekka Nikander From pekka.nikander at nomadiclab.com Fri Apr 29 06:16:29 2005 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Fri, 29 Apr 2005 16:16:29 +0300 Subject: [anonsec] Milestone to be filled: Decision on whether SPD/PAD extensions are needed Message-ID: Folks, According to our charter we should soon make a decision whether SPD and/or PAD extensions are likely to be needed in order to implement the purported BTNS functionality (which of course, is still to be defined). The purpose of this decision is to make sure that we don't initiate unnecessary work, and on the other hand, if the work is indeed needed, make sure that we do initiate the work. Now, based on my fresh reading of rfc2401bis, to me it seems that most of what we will technically need are already there in the form of "name" selectors. What may be missing is linking back inbound SAs to names, a question which I (partially) asked in the other mail, cross-posted and directed to the IPsec WG ML. However, there seems to be also some problematic normative text, especially the last paragraph of Section 4.4.3.4: > Note that because the PAD is checked before searching for an SPD > entry, this safeguard protects an initiator against spoofing > attacks. > For example, assume that IKE A receives an outbound packet destined > for IP address X, a host served by a security gateway. RFC 2401 and > 2401bis do not specify how A determines the address of the IKE peer > serving X. However, any peer contacted by A as the presumed > representative for X must be registered in the PAD in order to allow > the IKE exchange to be authenticated. Moreover, when the > authenticated peer asserts that it represents X in its traffic > selector exchange, the PAD will be consulted to determine if the > peer > in question is authorized to represent X. Thus the PAD provides a > binding of address ranges (or name sub-spaces) to peers, to counter > such attacks. Now, if I understand the situation correctly, in BTNS we want to support a situation where peer need not be authorised to represent X. On the other hand, we want to make sure that at the given configuration nobody else (i.e. no other PAD/SPD entry) can claim authority over X. Other than that, it looks to me that we may need to have a) ordering rules for correlated PAD/SPD entries, stating that specific BTNS entries MUST be after non-BTNS entries and b) specification of a "generic" or "opportunistic" BTNS entry for SPD/PAD Opinions? Especially, what am I missing or misunderstanding? --Pekka From Nicolas.Williams at sun.com Fri Apr 29 06:33:31 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 29 Apr 2005 08:33:31 -0500 Subject: [anonsec] Milestone to be filled: Decision on whether SPD/PAD extensions are needed In-Reply-To: References: Message-ID: <20050429133331.GE14398@binky.Central.Sun.COM> I wrote an I-D a while back that I just haven't published -- I'll publish it today, as a personal submission. It deals with BTNS in BITS mode only, not native mode -- I thought it best to start small. It does involve some such PAD extensions, as you'll see, though only to specify for which addresses BTNS is OK. Nico -- From Nicolas.Williams at sun.com Fri Apr 29 10:07:26 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 29 Apr 2005 12:07:26 -0500 Subject: [anonsec] Milestone to be filled: Decision on whether SPD/PAD extensions are needed In-Reply-To: <20050429133331.GE14398@binky.Central.Sun.COM> References: <20050429133331.GE14398@binky.Central.Sun.COM> Message-ID: <20050429170726.GA15124@binky.Central.Sun.COM> On Fri, Apr 29, 2005 at 08:33:31AM -0500, Nicolas Williams wrote: > I wrote an I-D a while back that I just haven't published -- I'll > publish it today, as a personal submission. It deals with BTNS in BITS > mode only, not native mode -- I thought it best to start small. > > It does involve some such PAD extensions, as you'll see, though only to > specify for which addresses BTNS is OK. Until the I-D appears in the I-D repository you can find a copy here: http://blogs.sun.com/roller/resources/nico/williams-unauth-ike.txt Nico -- From touch at ISI.EDU Fri Apr 29 13:12:08 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 29 Apr 2005 13:12:08 -0700 Subject: [anonsec] Milestone to be filled: Decision on whether SPD/PAD extensions are needed In-Reply-To: References: Message-ID: <42729518.50502@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pekka Nikander wrote: > Folks, > > According to our charter we should soon make a decision > whether SPD and/or PAD extensions are likely to be needed > in order to implement the purported BTNS functionality > (which of course, is still to be defined). The purpose > of this decision is to make sure that we don't initiate > unnecessary work, and on the other hand, if the work is > indeed needed, make sure that we do initiate the work. > > Now, based on my fresh reading of rfc2401bis, to me it > seems that most of what we will technically need are already > there in the form of "name" selectors. What may be missing > is linking back inbound SAs to names, a question which I > (partially) asked in the other mail, cross-posted and > directed to the IPsec WG ML. > > However, there seems to be also some problematic > normative text, especially the last paragraph of > Section 4.4.3.4: > > >> Note that because the PAD is checked before searching for an SPD >> entry, this safeguard protects an initiator against spoofing >>attacks. >> For example, assume that IKE A receives an outbound packet destined >> for IP address X, a host served by a security gateway. RFC 2401 and >> 2401bis do not specify how A determines the address of the IKE peer >> serving X. However, any peer contacted by A as the presumed >> representative for X must be registered in the PAD in order to allow >> the IKE exchange to be authenticated. Moreover, when the >> authenticated peer asserts that it represents X in its traffic >> selector exchange, the PAD will be consulted to determine if the >>peer >> in question is authorized to represent X. Thus the PAD provides a >> binding of address ranges (or name sub-spaces) to peers, to counter >> such attacks. > > > Now, if I understand the situation correctly, in BTNS > we want to support a situation where peer need not be > authorised to represent X. On the other hand, we want to > make sure that at the given configuration nobody else (i.e. > no other PAD/SPD entry) can claim authority over X. I'm not clear on that; BTNS means you're not authorized to represent X; it also means that whatever you say you're representing (e.g., X) is irrelevant, IMO. If we restrict BTNS as above, it means that once a host uses conventional authorization, _that host_ can't use BTNS for other associations (e.g., other ports). Unless, of course, X includes the full policy, in which case this just means that policies don't collide, which is understood (and assumed, I would hope). > Other than that, it looks to me that we may need to have > > a) ordering rules for correlated PAD/SPD entries, stating that > specific BTNS entries MUST be after non-BTNS entries > > and > > b) specification of a "generic" or "opportunistic" BTNS > entry for SPD/PAD > > Opinions? Especially, what am I missing or misunderstanding? > > --Pekka > > _______________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCcpUYE5f5cImnZrsRAsIaAJ96l/vgwfEJoW6Dryv3x81FJPY91QCgvFfq 2j+IBdzUeawKsCWF6hpNgQg= =Y1D/ -----END PGP SIGNATURE-----