PANA Meeting Minutes IETF 54 July 15, 15:30-17:30 Note taker: T.J. Kniveton/Nokia WG Chairs: Basavaraj Patil and Alper Yegin Basavaraj: Presented the agenda. Goal of today's meeting is to go over enhancements to the charter and to talk about revised requirements, Scenarios where PANA can or may be applied, and then what kind of issues will a PANA solution have to deal with. Most questions about the nature of PANA are answered in the FAQ written after the last IETF. The URL is in the presentation. --- Charter issues dealt with since IETF53: At last IETF, many questions about objectives, which were dealt with on the mailing list. - Should PANA access agent and enforcement point be colocated? If not, a subsequent protocol would be needed. - discussion concluded that PAA and EP should be colocated. - Location of PAA? can it be located beyond the first hop router or point of attachement? - PAA must be located on the same IP subnet/link as the PaC (i.e. first hop router or even AP) - PAA is not enforcement entity for access control - Just an interface to backed AAA infrastructure - Can communicate with EP which may be AR/AP - IP address assignment- what is role? There was a lot of discussion about this on mailing list - Conclusion: Node must have an IP address before PANA messaging occurs. - Is PANA required when you have 802.1x or PPP available - PANA does not necessarily compete with these, depending on scenario. - PANA is L2 independent for access authentication - Many security issues are still remaining - Session hijacking, protection of packets, other open issues. Outcome of discussion - Revised charter, with narrower focus and clear goal. ADs reviewed; awaiting IESG approval. Questions? Is this URL right? (http://www.toshiba.com/tari/pana-charter.txt) Try it again. -- Requirements and Terminology - Alper Yegin - Reynaldo Penno is editor of this document now, but couldn't attend this IETF. - Authentication Protocol - Goal is not to invent a new protocol. Current thinking is that EAP should be sufficient. - If extensions to EAP needed PANA WG will define requirements, not solutions. Will take these to EAP group or elsewhere to satisfy needs on PANA - Device Identifier needs to be integrity protected in PANA request sent by PaC - EAP doesn't do that, but do we really need this? - If per-packet auth encryption not used, spoofing can happen anytime. - Otherwise, checking DI is redundant Maybe you can make this dependent on upgrading the encryption - PAA and EP: PAA needs to communicate filters etc. to EP - PAA and EP are colocated. Anything else is outside scope - PAA generally on first-hop router. Requires discovery mechanism for client. Question on previous slide. Popping up a couple levels, I think there might be different threats, in which case different solutions might make sense. I think this needs to be written down somewhere in a document -- threat analysis. A possibility is that you authenticate security, but allow people to steal somebody else's authenticated service. So a cleartext DI that anyone else can spoof is sufficient. As long as you're there, somebody can spoof your DI; that might be acceptible tradeoff. We should have a threat analysis document. - IP address configuration - Must have IP address first. DHCP, autoconfig, etc. Could be temporary address, or keep using it after PANA. - Heartbeat: required for links that do not provide disconnect indication. Optional usage. - Comments? What is timescale of heartbeat? I'm thinking there are already effectively mechanisms: lease for DHCP, IPv6 addresses can be advertised with lifetimes, does mobile IP already have requirement for frequent-enough messages? Is this high frequency - every 1-10 seconds? Intention is for disconnect indication. Depending on type of link, every 2 seconds. If nothing else will provide, then it's there. Purpose is to detect when client leaves network to prevent hijacking Time-based charging might be another reason So you're wise not to send this thing About heartbeat, is it between client and PAA? Yes. It's between the PANA end points, that is PaC and PAA. It's not between PaC and EP. Right, but assumption is they're (EP and PAA) colocated. Could lead to denial of service Security implications of doing authentication at L3 is something we need to consider Hope you're sending it as a link-local multicast, to survive failure of PANA client You're suggesting solution of how to implement this. Heartbeats/Keepalives turn into make-deads. If there is congestion, keepalives may get dropped and your network connection disappears. If you bill per time, you just reauthenticate every per-time period. I recommend getting rid of heartbeats completely. My question was more generic requirements. Do you need to support multiple PAAs Network supports multiple access routers. And there can be several authentication agents on the network. You're making assumption that PAA and enforcement pt are colocated. But if there are 2 routers, and you want to switch routers, you need communication between routers to support this. Can we safely say that PAA and EP are colocated? Doesn't sidestep original problem. Also, is heartbeat wrong terminology? This is really a re-authentication Well we also have re-authentication. So let's reconsider the current setup, might be too much. If heartbeat is there to determine when to stop billing, you need to protect against someone pretending to be the guy who just left, which sounds like you need reauthentication. Are you trying to handle case where you have an ad-hoc network accessing managed network? Authentication agent multiple hops away is out of scope. Wouldn't it just get a managed addresss? Alternative scenario, router part of MANET who is next to AR is the one who asks, rather than expecting node multiple hops back This is supposed to be a generic protocol supporting someone plugging into a wire, right? So if we find a generic situation which I can implement in all situations, then there is no reason to implement this. Even if the problem is solved by this protocol, there is nothing to prevent neighbors from just stringing ethernet wires. We've talked about this as being generic, but it's unclear this provides the mechanism we're talking about because it won't work in all situations. If this locks me down to one address, this means that I can't use privacy extensions in v6 Cable modem systems let anybody come on This is a topical question with Time Warner sending out letters to people using 802.11. We need to move to a model where if you use an excessive amount of bandwidth, you pay for it. If I am sharing my connection with 100 people, I am doing a service by reselling the bandwidth we can have a good discussion if we have something written down. If it's trivial to bypass authentication (i.e. friend is on same layer 2 access network), this protocol doesn't do anything to improve that process. If we have a hole in the process, we need to understand what we're actually getting from this protocol. Question on different topic. If you have public shared hotspot, PAA will be managed separately by operators, but EP might have to be on a separate device. PAA addressible by separate addresses. But IP's can be colocated on same box PAA on EP, and only on backend, requests are forwarded to different AAA servers. EP could just forward directly then. Proxy functionality. What is the definition of PAA then? Functionality is PANA endpoint. PANA is front end to authentication protocol. Getting IP address first -- is it possible to run pana coincident with DHCP so that you don't get an address if auth fails? in terms of simplification, we have concluded that it has to have an IP address. Suggestion of additional simplification. If we can have access to multiple PEs, why not require unique relationship with EPs? If I have access to more than one EP, I have to establish unique relationship with PAA. So client interacts with each PAA and run PANA with both of them? Yes. Then you can require PAAs to talk to each other. PaC's may be able to communicate with each other, and authentication between them may be important in ad-hoc networks Please write up this scenario and post to the list. Do we really need IP addresses? Check the list for this discussion. After PANA happens, there may be a new IP address, or characteristics of IP address then change. We tried to restrict this to have colocation, and IP address. But we could expand this stuff if there is a good reason to. 6 months ago this was nebulous and it wasn't clear how to find a solution. So this is part of a focusing effort but scope is not closed forever. But whomever wants a larger scope Was IP issue decided before or after colocation issue? Many problems with unspecified addresses if colocation is not there, but otherwise. Discussion was done after colocation of PAA and EP. --- Usage scenarios Yashiro Ohba - Mobile IPv6, CDMA 2000, DSL/Cable modem, Limited scope access network - MIPv6 Why is mobile IP relevant here? The PaC is asking for access to the internet. Once it gets it, it will use it to do a binding update. But i don't understand why this is specifically motivated by mobile ip. Earlier in MIPv4, you have a FA where we show PAA. To a certain degree, it does authentication. So FA was essentially performing role of PAA. But even if you're not doing MIPv6, your point is still valid. This is important, because you don't want to confuse sending AAA messages with sending mobility signaling. You could replace sending MIPv6 with sending HTTP. - Multi-layer authentication. In CDMA2000, server system authentication and then higher layer authentication (PPP/Mobile IP) - PANA can be used for authentication in the case of Simple IP service in lieu of PPP. - DSL - PANA works in any topology in DSL modem or customer premise equip, there may be a router. Can we use this scenario? In that case, the router functionality is combined in DSL modem. So home router can be PaC on behalf of client behind home router. How about guest? You're basically creating an access network at home, and could use a PAA there. Does PANA allow for authentication of services? For example, 802.1x does not have that capability. We did discuss this to a certain extent on the mailing list. - Last scenario: limited scope access networks (original scenario). - Limited scope access is unrestricted. Then access to internet requires PANA authentication Who initiates the authentication We'll discuss this during the solution issues presentation later. - Example: local web server can be accessed without authentication Local free services are on other side of PAA (not on same subnet as host). That's where it gets interesting. I.e. you might have a router between the PaC's and services. DSL uses PPPoE and PPPoA, which assign addresses after authentication. Actually this is a requirement. issues of migrating away from PPP are pretty big. Whether to use PANA are at most 10% of the problems there so let's not use it as a justification. This scenario is not realistic, but wishful thinking in some sense. Could I authenticate a machine, then authenticate a user? Like what exactly am I authorizing? Is there a way to do layered authentication? A client is authenticated, and credentials are supplied by the client. Network access is authorized to the device being used by the client. You could authenticate at layer 2, and then authenticate the user at a higher layer (PANA). But not in the scope to use PANA to control the scope. The service being authorized is being able to send and receive packets to an IP address. And if the packets don't carry user info, talking about user authentication doesn't make sense. The service is the ability of the wire to emit and receive packets. --- Issues w.r.t protocol solution - UDP/ICMP/IP? - What would be PANA based on to encapsulate EAP? What about a connection-oriented protocol? SCTP allows you to do partial reliability Are you suggesting SCTP ought to be a candidate? What about using ICMP embedded data option? It may be difficult to get ICMP #, and requires IP stack changes OK, IP stack is going to need to be changed to implement this anyway. PANA + IPsec differ remarkably from PPPoE. There is physical protection (unshared medium). Can just use PANA. CDMA2000 has L2 protection. If no other protection, PANA might be used in conjunction with IPsec. What is identity? We don't have an IP address, and MAC address can be spoofed you may have to rely on IPsec and use IP address as identity. IPsec would solve the problem but the overhead is high. Might want to use ESP and AH to remote place; generating separate signature and sending in packets seems to be a non-starter NAI is right id to use. IMSI is going to go away eventually. Distribute keys down to layer 2. Authenticating machine and getting access vs. auth user. So we are talking about multi-layer auth. Device identifier - MAC address. IMSI or ESN is tied to subscriber record somewhere. Credentials presented are who is it that's going to be billed? Doesn't say anything about multiple users and which ones are authorized to send packets. IMSI is only pointer to HLR/VLR or AC used today. When you talk about NAI, that's more meaningful for AAA server, which gets involved later on. It is really an architecture issue to bring these two together. Steve's comment - you could use IPsec. Well PaC could just be router at your house; might not know how to map to users You can get arbitrarily fancy with the granularity. The packets might be signed with the right thing to make your PAA happy. But tagging mechanism might not extend beyond the enforcement. So cases where it works are more limited. - How does PaC discover PAA? - What would heartbeat method be? - According to earlier discussion, additional mechanism might not be necessary I hope there will still be networks that allow you to get to the net without presenting your credit card. If you are doing a solicitaiton mode on every network they attach to, well I prefer the model where in v6 the RA would include a flag saying to get beyond me, you need to include some PANA info. - How will PANA be triggered when PaC goes beyond "free zone"? - PAA sends ICMP error message, sends PANA Start message, ..can PaC know on its own to send PANA start? Why are we saying two services? We should talk about service authentication in a full blown way or not talk about it at all. The question is what should trigger PANA to occur? - New IP address assignment after PANA. Reasons: - Another IP address with greater scope (link local vs. global) - Might want to obtain provider-specific IP address - How is it done? - PaC decision (policy) - PANA success message can have a bit to get a new address - Router colocated with PAA can take an action PANA message with this bit contradicts with the FAQ (PANA does not do address allocation) It doesn't really do address allocation, it just indicates PaC should do it. Is this a decision that's been made, to get a new IP address, or just a possibility? Changing IP address on the fly might be asking a lot from the client stack - How do we secure protection against eavesdropping and spoofing? - PANA can recommend using specific EAP methods when underlying medium is not secure. PANA should pick another scheme rather than developing its own. - If there are multiple first-hop routers, how does PANA work? - Each router has a PAA and responds to discoveryPaC does pana with all - Each router has a PAA, each PAA responds, PaC does pana with one - Only one router has PAA -Questions? Last slide seemed to say that in some cases, you need a protocol to carry things between PAA and enforcement point. Maybe WG needs to put that in the charter to pick one protocol to use to do that. It might be too constraining to say that you can always colocate these, even when you have multiple ARs. Then the scope expands to pick a protocol to carry this stuff. Just choose step 1, and PaC does pana with all of them. --- Next step: get feedback from IESG on charter and update charter.