IPsecME WG Friday, 2009-03-27 Minutes taken by Gabriel Montenegro and Guy Snyder Thanks to both of them! (Instead of picking the best of each, we present both as-is) ===================================================================== Next time, one, perhaps more docs to go to WG last call. New WG doc next time it's published: heuristics draft Slides Session introduction IPsec Roadmap IKEv2 session resumption ESP traffic visibility IKEv2 redirect IPsec API requirements IKEv2 bis Agenda Welcome, scribe, bluesheets, issue tracking process - 5 mins Will have another interim. Roadmap - 15 mins - draft-ietf-ipsecme-roadmap possibly ready for WG LC next rev * add intro material * add security levels for other than crypto * add SEED crypto issues: * some RFCs characterized as "not widely adopted" * no apparent heartburn about this * Dan McDonald - 3884 - Transport mode for dynamic rtg * implemented in solaris, bsd * nw interface for IPinIP and use transport mode to protect it * Wes Hardaker: * not for sure but 4025 (IPsec keying in DNS) might be * MIB in 4807, not that he knows of * Shoichi Sakane: What is being said about KINK 4430? Not recommend? * in the future, KINK will be widely deployed, I think * Tero - the text says "not widely used", so even if it is implemented, it could remain on this list some reorganization of material was done Should the draft be changed to indicate that the destination address is used as an SA selector for inbound packet in IPsecv3? * No: Destination address is used to confirm that the inbound packet conforms to the SPD, not as an SA selector * Steve Kent: the current wording in the draft is correct required algorithms for old IPsec-v2? * is this relevant to new implementations? not really, just need to document what is correct * 4835 on crypto obsoleted 4305 (crypto algs for ESP/AH), which obsoleted old IPsec * so what specifies IPsecv2 crypto? * does 4835 change algos for old IPsec v2? * if not, what are they? * Paul: I read it to say that 4835 modifies IPsecv2, so draft is fine as is * Guy Sneider: in new IPsec section you referred to 4301 etc as "updated", not "obsoleted", why? * Sheila: slopiness, if that's so we should change it to "obsolete" Session Resumption - 15 mins - draft-ietf-ipsecme-ikev2-resumption 2 new versions since the last IETF -02 proposes solutions for all open issues. * Issue #69: Clarify behavior of SPI and sequence numbers * not controversial * Issue #70: Ticket lifetime - explicit or not? (and ticket push from gateway) * lifetime field had clear meaning when ticket went from gw to the node * so now 2 payloads * one with lifetime field * one without it * much clearer now * should the ticket have lifetime at all? * gw uses it as hint to initiator as to when the ticket is valid * Issue #73: Ticket location: prefer server-side ticket * Issue #74: Extend IKE_SA_INIT instead of new exchange type * Issue #75: Make "by reference" a first class citizen * 3 issues discussed widely on the ML * ticket structure itself is opaque per previous agreement * but what if it includes a ticket reference? * made it a first class citizen * Steve Kent: while it's opaque, there might be options, sure, but including text in the appendix as to what that structure might include is a bad idea. either it's opaque or not * Hannes: some text as example of what the minimum you should include * but appendix also includes recommendation as to the reference option * Pasi - in the related TLS ticket RFC, initially, no such structure as it does not affect interoperability * feedback to include examples as they would be helpful * so they ended up having that example, but people can ignore it if they so wish * Yaron - main reason is to ensure that *default* implementations are secure * Pasi - might help if you do NOT have an actual structure, but just mention what you might want to include * SK - I don't buy that this will assure security. If they're so stupid to need this there's no guarantee on the rest of the system. * Hannes - so far nobody complained * Paul - downgrade from recommended to "example" and don't show pseudo code, number of bytes, etc, just textual info * still useful as this has been contentious in the WG * Issue #76: IPsec child SAs during resumption * Tero had asked for more clarity, added it. * Issue #77: Identities in draft-ietf-ipsecme-ikev2-resumption remaining issue: ticket "push" * initiator starts the whole thing * not possible for gw to asynchronously "push" tickets to the initiator * Tero asked for this, but no real discussion * Tero: this is required after rekeying of the IKE SA. We need to issue a new ticket to avoid keeping the old IKE SA info at the GW. * Yaron: this would complicate things. Lifetime of the ticket is limited to IKE SA. If rekeying, you then just remove the ticket, and request a new ticket, if we're not saying that then we should. * Paul: one of the goals at the beginning of the document talks about pushing "state" * Hannes: that talks about something else. * Hannes: I think it's too complexity, ticket is limited lifetime anyways * Tero: depends on lifetime. few hours? push not needed. couple of months? yes we would need it. * Hannes: not a long lifetime, no. Not a good idea to change your keys more frequently than ticket lifetime * Hannes: prefer to making it more explicit upon rekeying and void "push" * Tero: hard to understand use case * connection breaks down, use ticket to avoid DH * "no, for other things, mon morning scenario..." * still not clear to me what it's for * please add more text as to scenario * Pasi: plenary had good observation that one can't predict what things are used for, so scenarios. Some are unpredictable, some not: * mon morning * laptop close/resume * crappy WLAN breaks connection * MPLS breaks my connection... Pasi review after revised version, need feedback on: * Resumptions vs. the old IKE_SA * Pasi compares with TLS session resumption * in ipsec old SAs are replaced * in TLS, instead, "new" connections are created, independent of previous ones * Pasi: better accomodates predictable (laptop sleep/resume) scenario * Vidya: for that scenario, you're expected to log in anyways * this is more for unpredictable (crappy WLAN) scenarios * Yaron: agree, expect to login again, concerned about using my IPsec material on two SAs * Pasi - GW could kill the old SA if new one is discovered, but this is tough to do on a cluster * Paul: open up an issue for it and take to the list, too many options * Replays in 1-rtt protocol vs 2-RTT * under DoS can dynamically switch to 2-rtt (stronger than IKEv2 cookies) * but also backend state and effects (DHCP, DNS, AAA, routing) * Vidya: if storing tickets has state issues, counter can be used to alleviate it * Pasi: huge security bug not being described (DoS on state including backend). at least describe. if it's a single GW, then counter or something can help, but in a cluster other solutions, go to 1-RTT perhaps. * Yaron: tradeoff between iffy security and one more RTT, I'd prefer going to 2-RTT always * Pasi: I've said it for two years: the draft would be much simpler to implement and much shorter and specify if we always had 2-RTT ESP NULL visibility - 15 mins - draft-ietf-ipsecme-traffic-visibility main discussion was on heuristics vs deterministic approach minimal changes this rev within the last week: feedback from Charlie Kaufman tickets: #83 - Support for WESP negotiation in IKEv1 or IKEv2 * Closed - the document assumes IKEv2 #85 - clarify the units for WESP header * Added length of fields in bits, units still to be added #86 - clarify WESP follows RFC 4303 for IPv6 (and IPv4) considerations * Added text to refer to RFC 4303, closed #84 - Scope of WESP Should WESP be applicable to encrypted and ESP-NULL traffic? * Uniform, single protocol * 'Integrity bit' incorporation in flags * Next Header security concerns * TrailerLen visibility security concerns Steve Kent: I remember asking this question. If we're going to revert that then we want to keep parity with ESP. Advantages: * Consistent extension for encrypted / clear traffic * Future extension to handle encrypted data also Paul: just do a draft with this in place, flag it as an issue and see what happens. just asking the question quickly degrades #88 UDP Encapsulation diagram is wrong * It's not a 32-bit Checksum * It's 16-bit Length + 16-bit Checksum! #89 Version field in the flags: what is it set to? * It's shown as “Version” but there is no numerical value! #90 shorter WESP negotiation * along the lines of the USE_TRANSPORT_MODE of rfc4306 * one end suggests and the other end accepts or declines * Pro: * leads to shorter proposal encodings * cons: * less flexible Tero: good idea to use notification, good for backward compatibility * if modify SA payloads and not supported, they can crash * with unknown notifications, implementations know how to deal with it, if they don't know it they'll just fall back to regular ESP * Ken: agree, perhaps easier on existing implementations #91 Use of Next Header field should not be optional if using ESP-NULL with WESP * Not hiding anything * Simply negates the use of WESP * So if using WESP, MUST use the Next Header #92 Specify clearly how to treat the bits in the flag field * Already say they MUST be set to 0 in this spec * Must also specify treatment upon reception * e.g., If Version is not 00, drop. * What to do about the other 6 bits if they are set? * ignore all? * drop for some? * Not treat all the same? e.g., ignore? * cons: complexity * pro: flexibility Tero: this could be negotiated in IKEv2 anyways, so it could be safe to say "ignore" the flags that you don't understand David Black: IKEv2 has a variant of the critical payload, just like Tero said Ken: from an intermediary perspective, it may not be part of the IKEv2 critical payload consideration #93 Next Header field to provide the value for the tunneled packet if using tunnel mode. Might also want to point at inner payload. * Pro * saves some parsing to inspecting middle boxes * Con * additional complexity (Next Header is not populated in the same way always) * Middle boxes may still want to look at external header * May be too little gain, given that WESP already makes the parsing problem very easy for middle boxes. This might represent too little a gain for the complexity it introduces. SK: since this was mostly for intermediaries, what are end devices doing with this? * I can point this to some point in the intermediary traffic that I know a firewall is happier with * what will the end node do with this? could it have received this by virtue of it being modified on purspose to have the firewall see something * is there a consistency check? * Paul: must bring this up on the security considerations, not sure if we want to have a consistency check * Tero: did we have something about next header fields being different? * but what about length fields, so the intermediary device stops parsing before * MIchael Richardson - 2 peers can always build a covert channel * Paul: still we should make sure both sets of fields are consistent * Ken: we should open up a new issue on this Redirect - 15 mins - draft-ietf-ipsecme-ikev2-redirect Delete of SAs after REDIRECT Once the client receives the REDIRECT message from the gateway, it sends an acknowledgement to the gateway The client MUST delete the IKEv2 SA and the IPsec SAs (if any) If client does not, the gateway may delete the SAs The gateway must allow sufficient time for the client to authenticate and establish security associations with the new gateway In both cases an explicit INFORMATIONAL message with DELETE payload is sent REDIRECT_ACK payload An explicit REDIRECT_ACK is not required for gateway-initiated redirects An empty INFORMATIONAL message is used to acknowledge the REDIRECT from the gateway REDIRECT_ACK notification payload removed Redirect between IKEv2 Peers There was a proposal to use the REDIRECT mechanism between any two IKEv2 peers The document mainly focuses on clientgateway scenarios Consensus was to restrict this to the case where the original responder redirects the original initiator to another responder Yaron: Tero commented that this is very complex if both parties move at the same time Gab: might want to look at what HIP does before we dismiss this DoS attacks using REDIRECT messages It is possible for an attacker to inject IKE_SA_INIT responses with REDIRECT payload and causes DoS attacks on the initiator Proposal is to have the responder echo the Nonce from the Ni payload in the REDIRECT payload The initiator matches the nonce in the REDIRECT payload with the nonce it sent in the Ni payload Open Issue - Redirect and PAD entries When a gateway redirects the client to another gateway, is the new gateway subject to the same PAD entry or is a new PAD entry created for the new gateway? Discussion on the mailing list supports the view that the new gateway is subject to the same PAD entry However, a scenario where GW1.example.com redirects the client to GW2.example.com needs to be supported for the REDIRECT message to be useful Having all the gateways share the same FQDN is too limiting One solution is to add all the gateways to the PAD entry on the mobile node But this creates an issue when the service provider adds or removes gateways Proposed Solution: Add text that says the original gateway and the new gateway are subject to the same PAD entry To support the scenario above, have a a wild card that says *.example.com in the PAD entry on the client David Black: like this direction. On the client if you don't like the PAD entry, restart which allows all your policy to apply. * for redirect you'd rather not have any PAD entry changes, right Open Issue - Redirect during IKE_AUTH Redirect during IKE_AUTH exchange was added to the document If re-direct is based on the user's subscription profile or the client-indicated IDr, then the re-direct has to happen during the IKE_AUTH exchange REDIRECT payload is sent in the IKE_AUTH response If EAP or Multiple Authentications [RFC 4739] is used, the IKE_AUTH exchange is much more complicated The gateway might decide to redirect based on the EAP authenticated ID, interaction with the AAA server or due to interaction with the external authentication server Solution alternative 1 The gateway completes the IKE_AUTH exchange An INFORMATIONAL message with the REDIRECT payload is then sent Solution alternative 2 The gateway sends the REDIRECT payload in the IKE_AUTH response that also carries the EAP Success message Open Issue - Redirect and the Security Associations If REDIRECT payload is sent during IKE_SA_INIT exchange, the IKEv2 SA is not created If the REDIRECT happens during the IKE_AUTH exchange, is the IKEv2 SA valid? DH completed, but authentication has not happened yet Assume IKEv2 SA is created and needs to be torn down? IPsec SA is not created If EAP is used the REDIRECT goes along with EAP Success Assume both IKEv2 SA and IPsec SAs are created? Tero: probably EAP_SUCCESS is the wrong place, gotta wait until IKE SAs are created with final traffic selectors etc * should be final message of IKE_AUTH, not EAP Pasi: only allow either in first or lasat IKE_AUTH exchange Tero: rather have only in one place, if at first exchange people don't want to redirect based on an unauthenticated identity Yoav: makes sense in 1st on unauth but if both are allowed that would be fine IPsec API requirements (off-charter item) - draft-mglt-btns-ipsec-api-requirements - 15 mins want apps to take full advantage of IPsec layer Pasi: surprised to see a requirements draft when we've had a solutions draft in BTNS for a long time Daniel: not competing, but completing Pasi: not clear which reqs are not yet covered by BTNS draft Daniel: we want more interaction betw apps and IPsec layer, not just socket Pasi: seems like it's already there Yaron: not the intent to replace BTNS, just an informational/guest presentation Dan McDonald: why would you want to have an application delete an SA? supported in 4306 with unique SA Stephen Kent: one of the goals is for apps to have more control. How do you describe in an API in an OS-independent fashion how they fiddle with stuff in the SAD, etc such that they don't affect other applications? Daniel: wish to define an app priviledge SK: that's a meta SPD cuz it constrains what apps can do, and underlying OS support it? Yaron: IPv6 configuration draft. * very little progress * very little enthusiasm * should we continue it? Tero: it's better than what we have now. Let's put it out now Gab: might be valuable, but as informational/experimental and move to PS as we actually get experience Pasi: it's ok to do as either Thomas Narten: instead of demoting it, it seems important to have full v6 spec, so bring this up with IPv6 directorate Vijay: I looked at the doc, and it seems complete Paul: a couple of TBDs like the Security Considerations… But I like Thomas' idea IKEv2bis open issues - remaining time - draft-ietf-ipsecme-ikev2bis Many issues discussed on the ML. Some issues here: #43 and #49 and #56 Lifetime of configured IP address * Accepted * Change 3.15.1 from “The requested address is valid until there are no IKE_SAs between the peers” to “The requested address is valid as long as the IKE SA that requested the address is valid. The Initiator of any rekeyed IKE SAs SHOULD request an address again, and the Responder SHOULD grant the same address again, if this is possible.” * Also add sentence in 1.1.3 referring to 3.15.1. Tero: you should say renegotiate or something not rekey as rekey won't necessarily change your IP address #2 Where does N(SET_WINDOW_SIZE) go? * From Appendix C: The specification does not say which messages can contain N(SET_WINDOW_SIZE). It can possibly be included in any message, but it is not yet shown below. Paul: wherever you wish. #12 Traffic selectors or the packet that triggered the rekeying * Maybe the traffic selectors for the rekeying should have those selectors from the packet. * To allow responder to do intelligent narrowing of the traffic selector the responder should know which packet triggered the rekeying, so it will not narrow the traffic selectors to set which is not usable for the packet triggering the rekeying. #53 Handling of INITIAL_CONTACT * 2.4: Clarif-7.9 is unclear: “however, receiving parties need to deal with it in other requests” - what requests? How? Why should it ever happen? * The text says that the notification MUST be in the first IKE_AUTH request. David Black: if you put initial_contact in anything other than an IKE_AUTH something is wrong, do you have the critical bit on it? Tero: comes from IKEv1 Greg Lebowitz: clarify: only pay attention to it if it arrives in IKE_AUTH Others that need more ML discussion: #61 Security considerations of admission control * Some more text added. #63 Position of arbitrary notify payloads #80 UDP encapsulation needs to be negotiated ===================================================================== IPSECME WG Notes - 27 March 2009 IETF-74 Welcome, scribe, bluesheets, issue tracking process - 5 mins One document - last call One document to be added in the near future 1-2 documents expected to go last call by Stockholm (75) Would like to have 2 more virtual calls before IETF75. Roadmap - 15 mins - draft-ietf-ipsecme-roadmap David Donald - RCFC 3884 is implemented. BSDs and Solaris use this. Les ?? - Open Swan - maybe include this. 3884 3585 - maybe in future Yaron - not list ramping up. should be dropped Sherges - KINK not widely deployed, therefore not list. change to "currently not widely adopted" Sheila - they will stay in draft, but stay in list as "not widely adopted" Tero - implemented, but not used Paul - re: alg for 2402,2406, agrees with the way it is currently documented in draft Guy - "new ipsec" section should we use "Obsoletes" instead of "updates" pg. 10 and pg. 18 of document Session Resumption - 15 mins - draft-ietf-ipsecme-ikev2-resumption Status review Steve K. - while it viewed as opaque, should not be here. Pasi - TLS ticket no such structures, does not affect, opaque, if they have a clue they can do something else. can put something in appendix. Yaron - main reason for appendix, default implement are secure Pasi - might help to not have data structure, more abstract Paul - bit by bit, more abstract Steve K. - if people are too stupid, what do you thing the rest of the implementation will be Paul - defined as recommended, downgrade to example and keep there. Ticket Push Tero - I think this is required especially after rekeying, we have to key around forever Yaron - I think ticket push would complicate, lifetime if limited, we don't say request a new ticket Paul - you have ticket push as a requirement, then don't mention it again. Tero - depends on lifetime, original thought was a couple hours, someone said it could be month, hard to understand document, what is use case. more text on what this is for. Pasi - plenary had some on what this would be for. arrive at work on Monday morning. shut down computer, bad lan breaks connection. Unpredictable failures. Resumptions vs. the old IKE_SA Pasi - 2 parts - current text says you can't use session can't use shut down laptop case Vidya - scenario you mean shut down laptop and opening up again. unpredictably shutdowns are better Yaron - one time pw again - rehashing old Pasi - gw must close down old one, tricky in clustered env. Tero - init contact can be used here, you don't have old IKE SA 1-RTT vs. 2-RTT Pasi - this is about RAM at VPN gw. text is not correct in that way. Vidya - draft not enough text. slide enough text. many choices what would you like the draft to say. Pasi - the draft doesn't say anything after 2 years. solution - describe this, not realistic in cluster, more comments about security in draft Yaron - 2 round draft trip Pasi - much better that way Vidya - vpn gw backend network or not. take to list ESP NULL visibility - 15 mins - draft-ietf-ipsecme-traffic-visibility Steve Kent -#84 are we doing encrypted, if this is not esp-null, don't put things in there encrypted Tero - #90 good idea to use current implementations, backward compatibility Yaron - only for transport mode, not tunnel mode #92 Gregory L. - if you don't understand TCP just skip it. Have to assume to ignore flag. Gabriel - 2 options ignore or spaces. don't know how to treat you drop. Tero - we already a process IKEv2 - should be able to ignore safely Paul - we also have to do something in IKEv2 also David Black - if you have to do something you will not get an SA which is what you want #93 Steve Kent - what attention is the end device paying to it. possible attack?? intermediate device has 2 different views. Is it possible to that type of inconsistency. Paul - need to bring up in security considerations Tero - we already said something about checking port numbers. next header field, must be same. people should be checking on both sides. Redirect - 15 mins - draft-ietf-ipsecme-ikev2-redirect Yaron - complicated, consensus we use this for planned maint. which one can be used for and which not Tero - mobike example - very complicated. redirect can work in some cases, but there are many cases it doesn't work. Gabriel - I've seen this pattern, mobike ended asymmetric. see what HIP is doing. not gw to client protocol, but IKEv2 Tero - IKEv2 is asymmetric Open issue-redirect&pad David Black - drop SA, client policy issue and out of protocol, can you put *.gw redirect during IKE_auth redirect and the SA Tero - when the EAP msg sent, we don't know Man in M, should be final message. don't like adding to IKE_AUTH, but if add anywhere add to final msg of IKE_AUTH. Pasi - allow first or last IKE_AUTH, not in middle Tero - many said can't do this unauthenticated. would like only one place IPsec API requirements (off-charter item) - draft-mglt-btns-ipsec-api-requirements - 15 mins Pasi - btns has api document with solution. what is the difference. what requirements are not covered by current draft. Daniel - we want app to get response. Dan McDonald - why would you want app to have that granularity. what problem solving? Steven K. - how do you describe in API that cannot affect other applications. meta spd. IPv6 Config Draft Tero - better than what we have no. needed in future. very few working on IKEv2 and IPv6 Gabriel - is this going to informational or proposed std. - suggest informational. Pasi - we could do experimental?? The 4306 and this uses different numbers. Tero - we implement this now and it works now. Thomas - are these new features or closing gaps. closing gaps is the answer. Pasi - is there interest in this and is there someone to work on this. Vijay - there are no comments, security considerations IKEv2bis open issues - remaining time - draft-ietf-ipsecme-ikev2bis slide 15 - 43, 49, 56 Tero - rekeyed sa should be re-authentication David - #53- something is wrong is you do this. Tero - one of the reasons, because of IKEv1 Gregory - can we make it clear here as opposed to not.