Last Modified: 2005-07-29
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 | |
Done | Submit IPsec-based access control to the IESG | |
Done | Submit PANA framework to the IESG | |
Done | Submit PANA protocol specification to the IESG | |
Oct 05 | Submit PANA state machine specification to the IESG | |
Dec 05 | Submit SNMP-based PAA-to-EP protocol specification to the IESG | |
Dec 05 | Submit PANA-AAA interactions document to the IESG | |
Feb 06 | Submit PANA mobility optimizations to the IESG | |
Mar 06 | Submit MIB for PANA to the IESG |
RFC | Status | Title |
---|---|---|
RFC4016 | I | Protocol for Carrying Authentication and Network Access Threat Analysis and Security Requirements |
RFC4058 | I | Protocol for Carrying Authentication for Network Access (PANA)Requirements |
Meeting minutes of Protocol for carrying Authentication for Network Access (pana) WG from IETF63 ==================================================================== When: August 1st, 2005 Credits for these minutes: 1. Gerardo Giaretta (Gerardo.Giaretta@TILAB.COM) 2. Subir Das (subir@research.telcordia.com) Chairs: Alper Yegin <alper.yegin@samsung.com> Basavaraj Patil <basavaraj.patil@nokia.com> 0. Preliminaries, Agenda and Document Status (Chairs) ..................................................... - Agenda bashing - drop one agenda item (pana-ipsec) because no author. Status to be sent on the mailing list - Status of various WG documents presented (See slides) 1. PANA Framework ................. Presenter: Yoshihiro Ohba I-D: -ietf-pana-framework-05.txt Yoshi presented the issue (such as Dual Stack) and there were no questions/comments on the floor 2. PANA Protocol ................ Presenter: Yoshihiro Ohba I-D: draft-ietf-pana-pana-10.txt Yoshi presented the technical issues and corresponding resolutions. e.g., Issues like Master key derivation algorithm, Dual Stack etc.. There were no questions on the floor. Raj: The PANA protocol specification is ready for AD review. 3. SNMP usage for PAA-EP interface .................................. Presenter: Yacine El Mghazli I-D: draft-ietf-pana-snmp-04.txt Yacine presented the updated draft. Changes form ver 03: - Link layer access control, Accounting, Conformance section, IPSP MIB updates - Dependency w.r.t IPSP drafts: - PANA-SNMP re-uses from IPSP MIBs - PANA-specific objects extending the IPSP SPD-MIB Author Updates: IPSP authors updated the draft status: IESG will talk about Mark (AD): Alper has mentioned to me. Did you mention to the IESG? Authors: Yes, we have gave the info to IESG and no response from them Mark(AD): IESG is always flooded with info and may be but I will look into it. Avi Lior: I am a little bit confused: Q: Using SNMP for accounting? Don't know how scalable it is? Also SNMP's ability Q: Moving authorization info from PAA to EP. The question is there are Lot of info need to be moved from PAA to EP. Every time we transfer Yacine: The scope is only binary authorization. Other type such as pre-paid Alper: Is the SNMP extensible to cover other things? Yacine: Yes it can be done. Raj: Do you think SNMP can take care of other info such as pre-paid, per session info? Raj: Giving some background info: we did some studies on which protocol we should use. Yacine: We did some study such COPS, RADIUS Avi: Are you transferring accounting info back to PAA Yacine: Yes. Avi: Accounting should be outside of PANA Alper: You can use any protocol and it does not change the PANA framework. Avi: How is PANA involved with accounting? Yacine: If the WG thinks this is good we can delete that part. And people can use their own protocol for accounting. 4. State machine for PANA ......................... Presenter: Victor Fajardo I-D: draft-ietf-pana-statemachine-01.txt Victor presented the issues and corresponding resolutions: Issue 1: EAP-Restart() Issue 2: Nonce, PPAC, PCAP Issue 3: Obvious bug in the state machine Issue 4: PANA_PROTECTION_CAPABILITY Issue 5, Issue 6, Issue 7 etc… 5. Interworking of PANA and Radius .................................. Presenter: Avi Lior I-D: draft-ietf-pana-aaa-interworking-00.txt Raj mentioned that this is a new WG item. Avi presented the draft. Next steps were also mentioned. Reviews of the document were sought for. There were no questions on the floor
6. DHCPv4 option for PANA Authentication Agents ............................................... Presenter: Suraj Kumar I-D: draft-suraj-dhcpv4-paa-option-00.txt Raj mentioned that this a new document for WG consideration. Suraj presented the draft. A new DHCPv4 option was proposed. Author asked for WG consensus: Raj clarified that this is not a PANA WG item. This needs to be discussed in Dhc WG. 7. Pre-authentication Support for PANA ...................................... Presenter: Yoshihiro Ohba I-D: draft-ohba-pana-preauth-00.txt
[Yoshi]: pre-authentication can be started before the handover. Out of scope of this document how the host decides. E.g. additional thresold ofr signaling [Jari]: where to communicate with PANA? [Yoshi]: out of the scope also this. Triggers will depend on the technologies since it is a make before break approach
[Yoshi]: not sure if it is in the standard [Alper]: is part of RADIUS standard? [Avi]: we need to figure out what AAA server needs to know [Alper]: should it know that it is a pre-authentication? The AAA server needs to know it is a pre-authentication or not? [Avi]: I think so for example to manage resources or for billing [Raj]: whay would you care to have home AAA know that? [Jari]: start and stop accounting messages can be used to distinguish. If possible in the same way it is donw in 11i [Avi]: I may want to know if it is a pre-authentication for resources management [Vidya]: I guess what's different for .11i? [Avi]: I don't know [Vidya]: my understanding is now that the AAA server does not know anything about pre-authentication [Avi]: accounting can be used to understand if it was a pre-authentication or not [Subir]: is it a requirement for AAA to know that it is a pre-authentication? [Avi]: IMO it is a good idea for the AAA server. No technical but for business [Farouq]: one issue in 3GPP is how to distinguish sessions for the same ID [Jari}: it may be not wise to terminate the other session [Avi]: business reasons becuase of double authentication [Alper]: I think it is a AAA issue and it is orthogonal to PANA. Is there a block to distinguish them? Otherwise we should bring this problem to AAA
[Yoshi]: yes not mandated behaviuor but only recommendation [Jari]: wouldn't be good to mandate something? [Avi]: my recommendation is not start accoutnting until PaC active (second bullet) [Jari]: Agree - WG item? [Raj]: the objective is to enable mobility but there is CTP. Why do you need pre-auth is needed? [Yoshi]: CTP needs SA between PAAs and this is not possible [Raj]: in the same domain? [Yoshi]: authorization may differ in heterogeneous handovers with e.g. different link-layers [Raj]: isn't CTP [Gerardo]: when CTP is used a problem with authorization may arise. If links are different, you transfer some authorization state from PAA to another and the state may not be correct in the new PAA. [Raj]: PAA of the new can understand if auhorization is [Gerardo]: this is possible if PAA knows the user profile [Avi]: AAA server needs also to know where is the PaC and which is the PAA [Alper]: pre-authentication in this scenario can be a good fallback [Gerardo]: this solution solves the same problem of mobopt and ctp so we should understand which is needed Consensus to make it a WG item. Later we should discuss if this and mobility opts are needed. [Alper]: at the next step we will discuss if we need two solutions 8. Use of Context Transfer Protocol (CxTP) for PANA ................................................... Presenter: Julien Bournelle I-D: draft-bournelle-pana-ctp-03 Alper: In PANA Mobopts draft there are similar things and using the CTP protocol as context transfer. I think this should be an experimental draft Avi: Are you sending the termination message to old PAA? Julien: It is not described but it is possible. Avi: If you are doing this why are not using PANA Pre-Auth Julien: We are not using EAP. Yoshi: Jari: How many additional documents do we need to make this happen? AVi: May be how many more iteration do we need? Alper: What extra things do we need in AAA protocols to make this work? Julien: This is true for PANA-Mobopts not this one. Alper: I understand. We need to understand the big picture also. Raj: Do we need to go another round of iteration and address the AAA issues. Alper: Do we have a complete picture or Lionel: We should accept the WG item and address the issues. NOTE: Again I missed some interesting discussions here and I could not capture it.. Alper: We can work proactively work on both options Lionel: How do we update the AAA authorization parameter. Raj: It is safe to assume that this document should be considered as WG Item and understand the AAA issues 9. FPANA: combining PANA and FMIPv6 for fast authentication at handover .............................................................. Presenter: Humio Teraoka I-D: draft-hiko-pana-fpana-00.txt Humi presented the draft and described the problem space via a video. Raj: This is an important work and Mipshop can adopt this work and both PANA and Mipshop can jointly do this. Victor has mentioned the interop testing between Toshiba and Smsung implementations. 10. Next Steps Chairs Raj: We have three documents under AD/IESG review. Mark has promised that he will give the review by September. As soon as we will receive the comments we will pass this to the mailing list. Mark: Who are the authors of IPSP draft? There are some miscommunications and pl. contact me after the meeting. Raj: We have now three WG documents and we will discuss the PANA-PreAuth and CTP drafts on the mailing list |