[Pana] Minutes of PANA WG meeting at IETF63

[[e-mail]]

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 ([e-mail])
2. Subir Das  ([e-mail])

Chairs: Alper Yegin <[e-mail]> 
	Basavaraj Patil <[e-mail]>


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

- PANA messages & AVPs to AAA messages & AVPs
- simplifications
	- no AAA Proxy chains
	- EAP server is co-located with AAA server
	- NAS consists of PAA and AAA client
	- several AAA interactions: e.g. RADIUS client talking to
	Diameter server but also one authentication using Diameter and
	another using RADIUS  
- WG document standard and not informational
- issues raised
	- multiple authentications, what if one fails?
		- issue with RADIUS: what happens if an Access-Reject
		 is received?  
		- rejection or rejection of what was authenticated
		- draft-aboba-radext-fixes-00 seems the right
		 direction: Access Reject is a Reject of what you
		 asked for and not tear down of the whole session 
	- integration of Diameter
		- Diameter EAP was used
		- separate description, one for RADIUS and one for
Diameter
- what is next?
	- align with latest PANA
	- need a review (technical review first)

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

- some kind of mobility support for PANA
- FMIPv6-based and CTP-based are not applicable to cover the
- inter-administrative domain handovers or heterogeneous handover in
which authorization characteristics may differ 
- overview
	- proactively execute EAP authentication and PANA SA between
	 PaC and the PAA in the new network 
	- similar to 802.11i pre-suthentication
	- pre-authentication can be performed independently from the
	 initial authentication, i.e. with different credential or with
a
	 different AAA server 
	- terminology: pre-authentication, post-authorization
- pre-authnetication operation (before handover)
	- pre-authentication can be initiated by preparing PAA or PaC
	- P-flag in PANA header to distinguish pre-authentication with
	  normal one 
[Raj]: which is the trigger? the handover?
[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 

- after handover
	- PaC performs a PANA-Update exchange (PUR/PUA)
- authorization considerations
	- pre-authorization and post-authorization may have different
policies
	- AAA protocol may need to carry additional attribute

[Alper]: is part of standard document that specified how in .11i
distinguish pre-authentication from authentication 
[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  

- accounting: two options
	- PAA may start accounting immediatly after pre-authentication
	(like in MPA) 
	- it may not start accounting before PaC starts
	
[Avi]: are these optional or seeking for recomendation
[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 





	



_______________________________________________
Pana mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pana