Last Modified: 2005-01-25
| Done | Submit usage scenarios and applicability statement to the IESG | |
| Done | Submit security threat analysis to the IESG | |
| Done | Submit protocol requirements to the IESG | |
| Aug 04 | Submit PANA framework to the IESG | |
| Aug 04 | Submit PANA protocol specification to the IESG | |
| Aug 04 | Submit IPsec-based access control to the IESG | |
| Aug 04 | Submit SNMP-based PAA-to-EP protocol specification to the IESG | |
| Dec 04 | Submit MIB for PANA to the IESG |
|
Protocol for carrying Authentication for Network Access (PANA) WG meeting minutes from IETF62 Wednesday, March 8th; 0900-1130 Chair(s): Basavaraj Patil <basavaraj.patil@nokia.com> Alper Yegin <alper.yegin@samsung.com> 1.Agenda: ********* Basavaraj (Raj) Patil presenting: Blue sheets. Document status update. - Yoshi has been diligent in keeping the document updated. - Threats and requirements in the RFC editors queue. - PAA-EP document has been reviewed by the MIB doctor - Jari Arkko will be the technical advisor to the PANA WG. ============================================================= 2. Multihop PANA **************** Alper Yegin presenting: URL: http://panasec.org/docs/IETF62/mhop-PANA.txt - Discussion carried out on the mailing list. - Objective of this discussion is to remove the criteria that limits the PAA and PaC being a single hop away from each other. - Currently the charter says that the PAA and PaC are on the same subnet - Benefits include the fact that the NAS can be beyond the 1st hop and other deployment models - Unless this change makes the protocol extremely complicated, it is worthwhile removing the 1 hop limitation. - Clarified the scope of multi-hop PANA as opposed to multi-hop EAP BoF that was held earlier. Presented the various issues that have been discussed on the mailing list. (See slides) Issue 1: PAA Discovery PAA discovery can be easily handled and no changes are needed to the current protocol spec. Jyunghoon Jee: If PaC can be preconfigured with the PAA's prefix, then you could possibly use anycast to discover the PAA? Does this make sense? If it knows the network prefix in advance, it could use the anycast mechanism. Alper: Agrees that it makes sense to do such a discovery. Issue 2: IP Addressing No changes to the base spec expected to address this problem. Issue 3: EP Location PAA must know the location of the EP. Raj: Do you have a problenm when there are multiple EPs as a result of moving the PAA higher up in the network? Alper: This can be done using the current PAA-EP solution. Hence it is not a limiting factor. Raj: Is it possible that different filters be pushed to different EPs? The PAA will have to know the EPs. Alper: The EPs are preconfigured and yes it is possible that different EPs receive different filters. Subir: The EP and PAA cannot be colocated in the scenario? Alper: The PAA and EP cannot be colocated when you have the multi-hop scenario. Because the EP has to be on the same subnet. Issue 4: NAT traversal Decision on mailing list was to get rid of the integrity checks associated with the IP address. 2 Issues: Port number and IP address integrity check. Two possibilities to address this problem. We can try to make PANA NAT friendly. If there are major challenges to doing this, we can go with Option 2 which simply says that PANA has a limitation of being used in the presence of NATs. Subir: Can the NAT be colocated with the EP/AR? Alper: Yes. Subir: Do all the same arguments that you made apply? Alper: Yes Yoshi: Agrees that it makes sense to remove the integrity check verification. James Kempf: If you move the PAA from the subnet, what is the difference between the PAA and AAA? The PAA is a functional architectural element. Alper: Agrees with James'comment. Alper: So the next step as a result of this discussion is that we will update the charter to remove the 1 hop limitation, fix the protocol spec and move on. Any objections to this? None. ============================================================= 3. PANA PAA-EP Protocol: SNMP usage *********************************** I-D: draft-ietf-pana-snmp-03.txt Yoshihiro Ohba presenting on behalf of Yacine. - Received feedback from MIB doctor. - Security section: Added several things based on review by the MIB doctor - Added PaC presence notification. Identified two ways: Reliable and unreliable. - Next steps 1. Link layer protection - Better that it be described in a separate document since link layers have their own specific solutions. Alper: Is there a generic way to define encapsulation? Understand that there is a need for separate documents based on link layer. Yoshi: If we only have MAC address and generic identifier, then it is possible, but not sure if all link layers will be able to use such. Alper: What else do we need to push from PAA to EP? We would not define the format of the MAC address but a new TLV? Yoshi: We can consider. 2. Current set of MIB objects is defined. If any additional objects are needed, please comment. Maybe one more rev of the ID is needed before WG LC. ============================================================= 4. Context transfer for PANA **************************** I-D: draft-bournelle-pana-ctp-02.txt Julien Bournelle presenting: - Scope of presentation Problem statement: When PaC moves from one network to another and as a result changes PAAs, there is a need to transfer context from the previous PAA. - Example of use of CxTP between PAAs Explained the scenario and operation of CxTP in this scenario - Use of AAA in the context transfer process. Modified some aspects of CxTP as defined in this solution for PANA. Is there interest in making this a PANA WG item? Raj: CTP is an experimental RFC now. Is there really a need to define this protocol since it is a reuse of the existing RFC. Because the only change is the security token. It is basically an application of CTP to PANA. Julien: Agrees. Glen Zorn: AAA server identity. What does it mean? Julien: The new PAA needs to know what AAA server has been used. Glen: What does it mean? Does it mean the local AAA? Home AAA? Proxies? Which one? Julien: It is the AAA that has been used by the previous PAA. Glen: So that could be a proxy. So why do we care. Glen: So how does the PAA know. And why does it matter. Julien: Agrees. Jari Arkko: Slide showing the information transferred. Everything but the authorization rules. Says that it is probably more than the one that you show here. Wearing the EAP co-chair hat: Says that there is a need to Julien: Derivation of the key is described in the PANA-Mobopts document. Jari: Need to show that the mechanism conforms to the EAP WGs specification Alper: Understands that the EAP WG will simplify the keying framework document. Does it imply that other WGs can make modifications? Jari: There is still some need for control. But each WG will still need to specify how it is done for a protocol. James Kempf: Says that security people have this view of cryptographic boundaries. Of course this boundary definition is quite nebulous. However it seems that transferring keys between boundaries may be a cause of concern. If key transfer is what you are interested in, I wonder if context transfer is the right way to do it. Glen: Cryptographic boundary is where we define it. The crypto people like to keep this boundary quite small. Preferably on a chip. Glen Zorn: Session lifetime question. There is more to authorization than filters as Jari mentioned. Raj: So should we make this a WG document. Consensus call to the WG: 1. How many people think that this document should be a PANA WG document? Thomas: Should this work be taken up the context transfer at all? Given that there was only one hand Rephrasing the question. There were about 8 hands in favor of and a couple of hands that were against this. We will take this up on the mailing list. Thomas: Are you chartered to take on such work? You may want to verify this before going forward on this. Raj: Agrees ============================================================= 5. PANA state machine ********************* I-D: draft-ohba-pana-statemachine-01.txt Presented by: Victor Fajardo - Reviewed by a couple of people. - Several changes have been made to the FSM. - Miscellaneous fixes as well that were caught by the reviewers. - Editoroal fixes. Next step: Prefer to get some more reviews from the WG and from people who are implementing this protocol. Additionally make this a WG document. Raj: The state machine used to be a part of the PANA protocol spec. Hence it should be fine to go ahead and make this a WG document and publish it as an Informational RFC. ============================================================= 6. PANA-RADIUS interworking *************************** I-D: draft-lior-pana-radius-00.txt Avi Lior - Document describes how you map PANA messages and AVPs to RADIUS. - Architecture description - The EP is considered to be colocated within the scope of this discussion. - PANAs discovery phase has no equivalent in RADIUS. - Access Phase in PANA maps to Accounting in RADIUS - Reauth in PANA is Auth in Radius. - In the case of multiple authentication, you may use one or more RADIUS servers. There are issues here with this model and it needs to be sorted out. - Should have a similar document like this for Diameter. It could also be in this document itself as well. - Request making this a WG document. Jyungoon Jee: PANA already assumes a backend AAA. Why do we need this specification? Avi: This document is purely informational. There are issues in mapping. Hence such a document will help the community. RFC3580 talks about how to interwork RADIUS with 802.1x Alper: It is the interworking of these protocols that is explained in this document. Jee: If company X makes PANA and anothetr makes RADIUS, then there is a problem if such a thing is standardized. Jari: 1. Supports the idea of defining clearly how PANA and RADIUS and Diameter interwork with each other. If you do not do this vendors end up interpreting things differently and interoperability becomes an issue. 2. Would make sense to have Diameter in the same document. 3. Q: What to put in the NAS-type attribute? Avi: No clear answer at this time. Yoshi: Access-Reject mapping issue. If one EAP fails while another succeeds, what is the problem? Avi: When the Home AAA sends an Access-Reject, the session is gone. But that is not necessarily the same in PANA. Causes confusion to the home network since an Accounting start request is generated even when the Home sents an Access-Reject. Yoshi: The accounting start should be sent only to the Radius server that did not reject. Hence it should not be a problem. Avi: Did not read it that way. However there is a debate in AAA land about a similar issue and hence more discussion is needed. Glen Zorn: Not sure how all this would ever work. Does not believe there is any debate about what an Access-Reject means. The Radius client obeys what it is told. And hence what does it mean if you interpret Access-Reject in other ways? Avi: Explaining. Joe Salowey: It is important to straighten out this issue and several others as well if all this is to work together. Avi: Agrees Raj: Document is intended to be Informational. Should we make this a WG document? Q: How many people think that we need to have this document which specifies how PANA and AAA(Radius/Diameter) interact? Several. How many people think that there is no reason to have such a document and should be left to implementers? 1 hand Glen: Why does this ID need to be just Informational as opposed to being standards track. Because if it is just informational then we can just ignore it. But if it is important Raj: Basically the ID is providing guidelines. Most implementers also understand the interaction. Hence does not think that it makes sense to make it standards track. But can be deferred to the ADs for how to pursue this. Dave Nelson: Thinks that the interop document should be closely specified in order to get interoperable behavior. Hence it should be a standards track document. Glen Zorn: Ditto. Raj: Thomas, do you want to comment on this. Mark Townsley: Believes there is consensus to make it a standards track document. Thomas: The WG at some level should decide this. Raj: We will pursue this on a standards track. ============================================================= 7. Next steps ************** Basavaraj Patil presenting 1. Make the PANA-Radius interactions a WG document 2. Revise the milestones 3. Agreement to remove the limitation of the single hop. Recharter and make the modifications to the WG documents that are affected. The ones that are affected are framework and pana protocol spec. One these changes are done, we will submit the documents to the IESG. The PANA-IPsec ID is not affected by this change. But since the framework, PANA protocol and PANA-IPsec docs go hand in hand, they will be submitted to the IESG in a batch. 4. Another rev of PANA-SNMP document needed before going to WG LC. Glen: What is the rationale for multi-hop PANA? Alper: No reason why the PAA must be on the same subnet. On the ML people have expressed interest in moving the PAA to a different location. Having the PAA Thomas: Do you have concerns with doing this? As long as there is no harm to doing so, there is not a problem? But if you have concerns then we should discuss. Glen: Not sure if there are issues. Security or otherwise. End of meeting. |