Protocol for Carrying Authentication for Network Access (PANA) WG Monday, November 18 at 1300-1500 ================================= Chairs: Basavaraj Patil, Alper Yegin Note Takers: Ernie Tacsik, Subir Das 1. Agenda Bashing, 5 Mins ------------------------- No comments made 2. Charter Update and WG document status, 10 Mins, Chairs --------------------------------------------------------- Report by chair (Basavaraj Patil): Only change to charter after Yokohama - added PAA and enforcement point separation, and updated the milestones. Charter is available at ietf web page. Three WG documents are available at this moment, and they will be informational. Security threat analysis is a new wg document. 3. Requirements draft update, 10 Mins, Reinaldo Penno. ------------------------------------------------------ draft-ietf-pana-requirements-03.txt short presentation covering updates to the requirements draft. PAA-EP protocol requirements - Security - Protocol used between PAA and EP should be able to detect inactive peer within an appropiate time period and delete the related states. - Architecture needs to allow PaC and PAA initiated authentication. - Have a mechanism for a newly introduced EP to learn the policies currently in effect on that access network. - PAA should be able to notify an EP for allowing/disallowing access for a particular client. This should happen without EP sending a request to the PAA. changes in requirements draft - pana models - discovery discussion: Michael Thomas: are we dealing with policy discovery here? Chair (Basavaraj Patil): no - PANA only addresses discovery of PAA. 4. Security issues and Threat analysis, 40 Mins, Mohan Parthasarathy -------------------------------------------------------------------- draft-ietf-pana-threats-eval-00.txt The draft does not talk about solution, specific protocols. List may not be complete. Only general threats are discussed, for example: PAA discovery, authentication, leaving the network, attack the network etc. Discussion on requirement PANA MUST protect the identity of the PaC against eavesdropping Michael Thomas: risk reward benefit expose identity consider that you may NOT want to expose identity of PAA in discovery client may need to know (or guess) the PAA. Hannes Tschofenig: questions requirement of must protect identity - this requirement seems to favour certain solutions. Comment: if you have layer 2 protection then this is not a problem. Michael Thomas: to protect identity you must do something like diffie-hellman. Michael Thomas: identity protection is costly. Hannes Tschofenig: agreed. Chair (Basavaraj Patil): questions if diffie-hellman is appropriate does access network need to know id of client? or only need to authenticate. Michael Thomas: suggested real requirement is to provide ability to protect client privacy, not a "MUST protect" requirement. Jarno Rajahalme: suggested real requirement is to protect user privacy. Unknown1: Whom do you want to protect the identity or what type of threats are analyzed? Unknown2: may be location privacy.. Hesham Soliman: base requirements should be on the general case, we should have one set of requirements, not multiple depending on the various deployment environments. Michael Thomas: DoS is an issue of we want id confidentiality. Discussion on leaving the network Unknown: Is it realistic to think about disconnection.. things may crash.. wire may be disconnected... Chair (Alper Yegin): It is not mandatory but if one sends it should be protected. Attack on normal communication - requirement: PANA in combination with the underlying authentication protocol (e.g. EAP) MUST be able to derive keys in order to enable confidentiality. Michael Thomas: how do you use keys? will it be solved in PANA? Discussion on the extent of protection Unknown: how are packets protected smacks of reinventing ipsec? Answer: No implication that data is secure. Erik Nordmark: PANA protocol must be secure itself, questions if this is just last-hop local protection? Mohan Parthasarathy: yes, for the local protection. Unknown: I think PANA should take care by itself but here we see a different things. Not clear to me whether the last hop protection is necessary. Hannes Tschofenig: I think it is necessary to know whether it is about exchanging EAP messages securely, or something else. Whether the focus of PANA is to put the filters at the first hop router . Chair (Basavaraj Patil): Charter does not talk about securing data at the first hop networks it talks about securing PANA itself. Unknown: We should put a requirement that EP and PAA are secured.. Hesham Soliman: suggested must be able to derive keys in order to enable confidentiality and per-packet authentication." Gopal Dommety: is draft suggesting doing encryption EAP to PaC should this be mandated? other issues with keys. Michael Thomas: is PANA a layer 3 PPP or is it a AAA key distribution system need explicit use sceanarios. Chair (Basavaraj Patil): the intended threat to address is to protect against someone injecting packets into network using a previously authenticated users IP address. Erik Nordmark: confidentiality on the identity is not needed. George Tsirtsis: (on PANA requirement of having an IP address) we can use unspecified IP addresses. Hesham Soliman: is this an issue for IPv6? Erik Nordmark: there is a tradeoff, between having and not having having IP address there already - there are pros and cons. George Tsirtsis: what if one meets all requirements without using an IP address configured on the PaC? Gopal Dommety: a solution that works Without an IP address would be good. 5. Secure Network Access Authentication (SeNAA), 20 Mins, Dan Forsberg ---------------------------------------------------------------------- draft-forsberg-pana-secure-network-access-auth-00.txt Discussion on running TLS over UDP: Hannes Tschofenig: How are you deriving the SA for IPsec? If it is authetication only, then why you care about confidentiality. Also if you use only EAP then EAP should provide you the confidentiality. Michael Thomas: running TLS over UDP loses many TCP benefits (such as fragmentation, support for long certificates) Hannes Tschofenig: TLS needs PKI, or else MitM attacks is an issue. Chair (Basavaraj Patil): do we need to protect DI of PAA? 6. PANA over TLS, 20 Mins, Yoshihiro Ohba ----------------------------------------- draft-ohba-pana-potls-00.txt Design policy Start from providing maximum level of security Basic features Authentication parameters including EAP PDUs are carried over TLS TLS runs over reliable transport Discussion: Unknown: You mentioned that you would like to support some EAP methods but if I move and want to support the legacy authentication methods. may be we should consider some other mechanisms to protect those legacy mechanims. What about protecting the other hops. Yoshihiro Ohba: The current draft addresses the EAP protections over TLS but a security discussion is necessary to address these issues. Hannes Tschofenig: on secure channel terminate tunnel in home AAA not at last hop protection mechanism need to be all the way to the end cannot assume the access network is trustworthy. Michael Thomas: huge overlap with IPSRA and IKE per packet integrity on data flows. Why all this effort to use TLS? Chair (Alper Yegin): we are open to discussing other solutions. Erik Nordmark: WG should not consider lot of other proposals. I advocate to discuss the high level methods on the mailing list before producing several drafts... Chair (Basavaraj Patil): Let's explore the other methods and discuss in the mailing list. Derek Atkins: notes there is work in progress on a draft to use Kerberos over EAP. Clarification by chair (Alper Yegin): there are no assumptions in PANA to use TLS. 6. Next steps: chair (Alper Yegin) ---------------------------------- - Wg last call on problem space and usage cenarios after ietf 55 - Complete threat analysis draft and go to wg last call jan03 - Complete requirements draft and go to wg last call end of jan03 - Focus on options for protocol solutions on the mailing list