Subject: [Pana] PANA WG meeting minutes from IETF62

From: [email-masked]
Date: Fri, 8 Apr 2005 11:45:38 -0500

Protocol for carrying Authentication for Network Access (PANA)
WG meeting minutes from IETF62
Wednesday, March 8th; 0900-1130

Chair(s):
Basavaraj Patil <[email-masked]>
Alper Yegin <[email-masked]>

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.

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

---

From: "Junghoon Jee" <[email-masked]>
Date: Sat, 9 Apr 2005 23:01:15 +0900

Hello Basavaraj,
Here is several shorts comments about the minutes.
 
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.

=> Please change the name of Jyunghoon Jee to Junghoon Jee.

Avi Lior

Jyungoon Jee: PANA already assumes a backend AAA. Why do we need this
specification? 
=> Junghoon Jee : PANA already assumes a backend AAA. Why do we need this
specification? 
      If the interoperation problem occurs, it is a problem of PANA. 

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.

=> Junghoon Jee : If company X makes PANA and another makes RADIUS, then
there is no problem in the interoperation. Why does it need to be
standardized ?

Regards,
--Junghoon