MIPSHOP WG Minutes IETF 67, San Diego Session I --------- Tuesday, November 7, 1300-1500 1. Agenda review, Blue sheets and volunteers for notes and Jabber 5 Mins 2. WG status and I-Ds update 15 Mins draft-ietf-mipshop-cga-cba-00.txt draft-ietf-mipshop-fmipv6-rfc4068bis-00.txt draft-kempf-mipshop-handover-key-00.txt draft-vidya-mipshop-handover-keys-aaa-03.txt draft-ietf-mipshop-fh80216e-00.txt draft-ietf-mipshop-3gfh-00.txt draft-soliman-mipshop-4140bis-00.txt draft-haddad-mipshop-hmipv6-security-06 Vidya : how can we have a last call on FMIPv6 before we know what the security solution is? Vijay : draft-kempf-mipshop-handover-key-00 -- waiting for mob dir review Alper Yegin: Have you received the mobility directorate review of draft-kempf-mipshop-handover-key James Kempf: I don't think it needs any more review. It is ready for WG adoption and last call. Alper: There are a couple of solutions for the same problem, shouldn't we review the alternatives? Vijay: If the alternatives provide a significant improvement, yes. Alper: Why aren't the others considered as equal options? Vijay: The WG has spent a lot of time working on this. It is up to the authors of the alternate solutions to convince the WG. James: we have been working on this document for 3 years. We should go forward with what we have, and once these are finished, we can look at the others. Vidya: Vidya - If we continue process and exhaust the solution space before we pick something, it's not possible. The SEND-based solution has been around a long time, and AAA 1 1/2 to 2 years. New proposals shouldn't be related to existing documents Alper: Shouldn't we evaluate all the proposed solutions now? Jari Arkko: Let's look at the presentations today and see how the alternatives are and make the decisions then. Vidya: The documents have been through WG last call on adoption. All the concerns have been fixed. Vijay: It would be good to see if there are any issues and if the alternative solutions address them better. Vijay: May-June timeframe on HMIPv6 solution. Vijay: 3g CDMA document is being brought closer to 3GPP2 specs Vijay: 802.16e doc is postponed for now to wait for 16ng to make more progress Stefano: MIH Solutions cannot be processed before adopting a problem statement 3. Applying Cryptographically Generated Addresses and Credit-Based Authorization to Mobile IPv6 Christian Vogt draft-ietf-mipshop-cga-cba-01.txt 10 Mins Wassim: Problem with minimum RSA key length of 384.. It might be possible to use integer factoring to break the private key at 384 bits. Three options for solving this. Hesham : Do you have a preference? I think the third one makes sense. Wassim: The 1st one, hard coded RSA key length and the 3rd one, encoding the key lngeth into CGA would make sense. Hesham : What if the CN doesn't agree with minimum and rejects it? I'm fine with 1st and3rd Zhen: 704 should be used as a minimum key length, application dependent Madison: There is research on thuis Jari A. : Option 3 would be the right way forward. Perhaps we could combine with option 1. But I don't know if that's really needed. These are keys only used for address ownership, not banking. 4. Integrating IBC with CGA in Mobile IPv6 Zhen Cao draft-cao-mipshop-ibc-cga-00.txt 15 Mins Hesham: Could you explain the autoconfig attack? Arkko: Attacker generates its own keypair and address. What is the attack? Cao: If the CGA is used for other purposes than address ownership, then this is a problem. Vidya: CGA is not meant to be used for authentication. Cao: IBC will allow to extend the use of CGAs for authentication. Vidya: Why is there a need to add authentication to CGA? Cao: Without authentication the end user cannot be authenticated as being trusted. Vidya: There are other alternatives for this. Cao: This allows to extend... Vidya: Entity authentication vs. message authentication. Entity authentication cannot be achieved without infrastructure. ?: Are the CGAs to be enhanced to be used to authenticate the user using the computer? Cao: Yes. Vidya: How is this diffreent from certificates? ?: You do have a TTP? Cao: yes. ?: What is the benefit over putting CGA keys to DNSSec? Hesham: What types of applications are you planning this for? Hesham: Is this the right WG for this work? Cao: IBC-identity can be used in place of public key for CGA signature with the help of a KDC. ?: Could be used for FMIPv6 authentication. J. Kempf: We have done lots of work on this area. Two fundmamental problems: 1. You cannot use this in an open world. Similar problems as with PKI. 2. Algorithms are not performing well, 1-2 orders of magnitude worse than RSA. Does not think that it is a general solution, although there are some special cases in which it could be used. Cao: Trust problem James Kempf: Address is probably not the right place to do this. James Kempf: Is tate-pairing needed? Cao: Depends on the ECC signature used? James Kempf: ECC also requires this generally, the exceptions have other problems. Ok for email, but not for IPsec. Cao: Tate-pairing is not used in the proposal. Stefano: Move the discussion to the mailing list. 5. Mobile IPv6 Fast Handovers for 3G CDMA Networks Hidetoshi Yokota draft-ietf-mipshop-3gfh-01.txt 20 Mins Intention to apply draft to network controlled handoffs in 3gpp2. Hesham:: (Immediate Fast handover slide 1) This is not fast handover? Author: No. Hesham: There is not one message from 4068. Author: still presenting the background Vijay: We are not going to standardize something that has already been done in 3Gpp2. You are going to show how 4068 can be extended to work with this? Author: yes. ?: Clarification, why does MN sends a BU in addition to proxy BU sent by NAR? Author: Proxy BU is temporary solution. ?: Isn't this redundant. Author: Both Simple IP and Mobile IP are supported. Vidya: Isn't this background? Author: yes. Hesham: Simple IP means there is no IP mobility? Author: 3gpp2 looks at both Simple IP and MIP. Hesham: Do you need an extension to Handover Initiate in FMIPv6? Author: Yes. Vijay: Multiple options: we have a document on this, it can be informational, or we can design a solution for 3gpp2 Vidya: Get list of requirements from 3gpp2. And make sure that FMIPv6 meets them if they are reasonable otherwise say so. Write a document, Hesham: Goal for FMIP was to be adopted. If you find that there's something missing, please let us know. Can you write a informational document on how you have used it in 3gpp2. Author: How much should I tweak the protocol? Hesham: If not too much, please give input for FMIP before it goes to last call. Vidya: The work is very useful, gives feedback. We need to get the requirements, so that we can get community feedback and see what extensions need to be done, which could benefit also other users than 3GPP2. If you describe how you have updated the protocol, we cannot easily derive the requirements from that. 6. Authenticating FMIPv6 Handovers Suresh Krishnan draft-haddad-mipshop-fmipv6-auth-02 5 Mins - Use one way hash chain with 128 bit hash values - Use SEND only in the beginning to anchor hash chain - 64 bits of OWHC are used for nCoAs. James Kempf: Is there any problem with using SEND with every AR? Suresh: It's computationally expensive. Kempf: Don't you need to do SEND for Neighbour dicosvery? Suresh: It's not necessary ?: You can do hash chains wrong in many ways, it's tricky. The hash chain is being computed? Suresh: In MN, only MN knows the hash chain, ARs know only the used values and can verify the future ones when receiving FBUs. ?: Let's take this to the m-l. What happens when you use the same key for generating an address and for the hash chain? Suresh: That's why we have X, a random number calculated by AR. 7. FMIPv6 extension for Multicast Handover Frank Xia draft-xia-mipshop-fmip-multicast-00.txt 10 Mins Mistake in signaling chart: should be NAR buffers multicast traffic ?: HI includes the multicast groups MN has joined? Frank: Yes. Frank: What does the WG think? Vijay: Clarification, this is new work. Vidya: I don't know if there is a problem here. FMIP provides a way of delivering packets. Are you trying to prevent a new multicast join message at NAR? Frank: The multicast packets wouldn't be delivered. Vidya: The context transfer is separate. Alexandru: Multicast traffic is not moved by FMIP. Vijay: Maybe it is time to use the CTX protocol, but that needs to be done later. ?: Preventing joins is context transfer. Temporarily moving MC traffic over FMIP traffic is a MC specific problem. Which of the two are we talking about. Vijay: The problem is how do we handle multicast traffic during FMIP handoff. Vidya: Can I rephrase: Part of the problem is how to deliver temporarily multicast traffic to MN at NAR. This could be handled by a small revision to RFC 4068. Second problem is how to prevent MC joins and this needs to b addressed with other context transfer. 8. Hierarchical Mobile IPv6 Mobility Management (HMIPv6) Hesham Soliman draft-soliman-mipshop-4140bis-01.txt Vijay: Two comments, to which node is LBu destined? Hesham: Source-routing could be used or a hop by hop option. Vidya: What information is the AR changing? Hesham: The LBU is is end to end, it is used as a trigger with extra information in addition to BU in the packet. Jari Arkko: This sounds like a micro optimziation Vidya: Agrees, not sure that this is necessary and probably shouldn't be done at IP layer. ?: Not sure that this is too much of an optimization Vijay: We will continue with this in tomorrow's session. Vijay: End of tomorrow, what we want to do with HMIPv6 security. 9. Handover Key Hierarchy for HMIPv6 Hui Deng draft-deng-mipshop-hmip-hhokey-00.txt 5 Mins Shall we consider handover keying to HMIPv6? Vijay: This would fit better with hokey. Vidya: Right now not in the charter of hokey. Vijay: Let's discuss this tomorrow with HMIPv6 security discussion. Session II ---------- WEDNESDAY, November 8, 1300-1500 1. Agenda review, Blue sheets and volunteers for notes and Jabber 5 Mins 2. HMIP and FMIP Security Association Alper Yegin draft-yegin-hmip-sa-00 10 Mins After EAP, NAS and MN share MSK HMIP-key derived from MSK SA distribution - on MAP side NAS will deliver the key to the MAP using the SA - IPsec PSK - rfc4285 for non EAP-based architecture you need to identify an equivalent of the MSK same applies to FMIP Lakshinath: NAS is an edge identity .... (lost.... the minute taker was standing at the mike) Vijay: this is different from what we have in MIPv6. I don't see a real optimization because you just authenticate with the MAP once Alper: this is an optimization Hesham: this can be better for FMIP because you don't want to use IKEv2 with each AR. With HMIPv6 you can use EAPoIKEv2 and you handle change of MAP with overlapping MAPs. I don't see a problem in re-using keys. To re-use MIPv6 work you should do a pull model instead of push model Alper: you can use this approach also in pull model Hesham: you are assuming that the NAS understands and is aware of the MAP. If the are multiple MAPs, the NAS must be aware of the MAP the MN is going to choose Ahmad: how the SPI is used? how is it communicated? Alper: SPI=1 at initial EAP auth. 3. Mobility Independent Services: Problem Statement Telemaco Melia draft-melia-mipshop-mobility-services-ps-01.txt 15 Mins ps -00 version submitted at the beginning of Sep how to transport signaling messages for MIH appendix for different mobility services support comments to ID-00 - make it shorter - make it 802.21 related but this may be in contrast with what already agreed in IETF #66 version 01 - removed appendix - more .21 specific three possible options - main body only (version 01) - main body plus all appendixes - main body plus one .21 specific appendix Juan Carlos: some technical objections because the text has some non .21 related aspects that are not useful. Supporting James proposal Telemaco: according to the charter we should stick to .21 Subir: we should stick to what .21 requests. One way is to describe the general problem and then describe what is .21 but this may imply we don't have a clear understanding on what we need to specify Behcet: 01 seems to be good Daniel: not sure which is the proble. In the draft you jump to deployment scenarios and solutions Telemaco: you need to transport mobility information from the mobile to the network and vice versa Daniel: it's not clear the gap analysis and why current solutions cannot be used Juan Carlos: the draft needs some improvements for people that do not know .21 Stefano: please send detailed comments on the mailing list on how to improve the document Stefano: we would like to adopt the PS draft as WG item. Is there any objection? (no objection) We'll ask the same question on the mailing list 4. MIH design considerations Robert Hancock draft-hepworth-mipshop-mih-design-considerations-01 15 Mins DC draft to capture IETF expertise DC draft should help the design process draft stucture activity since 00 version - discussion about particular solutions characteristics - reflect the underlying issues in the DC draft - GIST presented for information at 802.21 Problem Boundary Issues Routing and Discovery some major architectural options - full MN control - discovery details delegated to the nw - discovery of adjacent peer or full path Jari: in the DHCP WG we discussed that DHCP has been approved in .21 Robert: not approval status yet in IETF, nor in .21 draft (where just L2 discovery is covered) Vijay: a lot of discovery methos. are all these applicable? Robert: some are inappropriate (e.g. DNS SRV). DHCP and mDNS may have a role Subir: in .21 draft, the discovery can be done also in DHCP. ?: there is another alternative to discover the IP address of .21 peer and it's the .21 L2 Stefano: we can capture that L2 can be used but this is out of the scope Jari: not sure it is out of the scope. We should focus on the problem definition in order to understand what is out of scope Juan Carlos: about routing? is it IP routing? Robert: it's signaling routing from one peer to another, not IP routing Alper: is this doc informative or normative? Requirements? Stefano: informative 5. Mobile and Wireless Neighborhood Discovery using DHCP Alper Yegin draft-jang-mipshop-nhdisc-00.txt 5 Mins DHCP for 802.21 IS (Alper) IS trasnport = DHCP IS client/server = DHCP client/server define new DHCP options where is the DHCP server? - by default in the serving network but it can be also in centralized location or in the home network or in the target nw you can rely also on the DHCP security this is configuration and DHCP is for that it's only for IS, not ES or CS ?: .21 provides three services. Do you think it would not be better to have a common protocol for all three of them? Alper: ES and CS might have a common protocol and there may be link layer protocols ?: this is a problem statement document issue. Do we need to handle IS only or also ES and CS? Yoshi: in .21 no requirement to use a single transport for all three services Subir: requirement from .21 is for a transport protocol of MIH and not for particular services. Are only configuration information or more than that? I think that there are information like cost that are not configuration Alper: it's configuration/information Subir: DHCP is for network parameters and not provider information Stefano: this is once again related to the PS and I hope Yoshi or official LS can clarify that 6. Transport of Media Independent Handover Messages Over IP Akbar Rahman draft-rahman-mipshop-mih-transport-01.txt 10 Mins Yoshi: what is the proxy? Juan Carlos: we are not passing the information at the IP layer all the way down. The Proxy just take out the information and deliver to the MN using L2 .21 but we want to leave this open for now DHCP to discover the Mobility Manager UDP as MIH transport between MN and MM IPsec for security ?: what defines the retransmission protocol? Juan Carlos: .21 will do the retransmissions Yoshi: it's not a proxy, it's a point of service because it's terminating a transaction and creating a new one John: people will put NATs wherever they want. With UDP you will run in NAT problems. Now SIP is required to use TCP and UDP is optional Stefano: you assume that the sessions are initiated by the MN but this may not be true for ES/CS. You are assuming the NATs maintain the state for a long time and this is not true Alex: if the MN must be reachable, then you need to solve the NAT problem ?: it's not a session, it's an individual transaction 7. HMIPv6 Security Next Steps Chairs 15 Mins Proposal: use of EAPoIKEv2 is sufficient to progress HMIPv6 as a proposed standard Vidya: I agree. Do we need a document for SPD entries like rfc3776? Vijay: we should be able to re-use what we have defined for MIP6. Assumption is to point to that but we can Jari: there is a need for some level of details. If this work cannot use the MIP6 document, the doc has some problems Alper: why we don't use rfc4285 in HMIPv6? Jari: is anything that we need to do? Alper: we should at least ack that it can be used Jari: 4285 is not PS and we are doing PS Vijay: This does not mean we drop all work on HMIPv6 security WG needs to decide if we still want to do another separate solution James: I think it's sufficient EAPoIKEv2 Vidya: agree we don't need another option. If we look at futuristic options, not sure mipshop is the right place to do it Vijay: We'll go with that assumption and we need to modify the charter. Any objections? 8. Next Steps Chairs 15 Mins WGLC on rfc4068bis Vidya: not sure it's ready for WGLC James: there are still couple of issues in FMIP adopt draft-soliman-mipshop-4140bis-01 as WG item draft on CGA/CBA to IESG adopt draft-melia-mipshop as WG item DT to work on the solution Jari: are you completing the PS draft before the DT? Stefano: we would like to have a new revision before setting up the DT