Current Meeting Report
Slides


2.2.12 Protocol for carrying Authentication for Network Access (pana)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 03-Dec-01
Chair(s):
Basavaraj Patil <basavaraj.patil@nokia.com>
Subir Das <subir@research.telcordia.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Erik Nordmark <nordmark@eng.sun.com>
Internet Area Advisor:
Erik Nordmark <nordmark@eng.sun.com>
Mailing Lists:
General Discussion:pana@research.telcordia.com
To Subscribe: pana-request@research.telcordia.com
In Body: (un)subscribe
Archive: ftp://ftp.research.telcordia.com/pub/Group.archive/pana/archive
Description of Working Group:
The AAA working group is specifying the Diameter protocol for communication between servers i.e. where Radius is currently being used. There is currently no general protocol to be used by a user's device when wanting network access, and this WG will attempt to fill that hole. That is, a protocol between a user's device and a device at the network access point where the network access device might be a client of the AAA infrastructure.

Currently the authentication mechanisms in PPP are being used for many wired access scenarios as well as some wireless access, which requires using PPP framing for the data packets. This is not viewed as the optimal solution in the cases where framing protocols already exist. Also, IEEE 802 is working on 802.1X which provides EAP authentication limited to IEEE 802 link layers.

Network access technologies for wired and wireless media are evolving rapidly. With the rapid growth in the number and type of devices and terminals that support IP stacks and can access the Internet, users can potentially use a single device having the capability of attaching via different multiple access media and technologies to interface to the network. The model for providing the users' information to the network for authentication, authorization or accounting needs to be the same and NOT be tied in to the underlying access type.

The intent of this WG is to develop a protocol but the working group can't start doing that until the requirements document is done.

The working group's primary task is to define a protocol between a user's device and a node in the network that allows:

- A device (on behalf of a user) to authenticate to an agent in the local network. The agent might be non-local, but at the boundary of some AAA-equivalent function. The agent is called PANA Authentication Agent (PAA) in this charter.

- The device to discover the IP address of the PAA.

- The PAA to use either local mechanisms/knowledge, or the AAA infrastructure i.e. being a client of the AAA, to authenticate the device.

- Outside of the scope of the protocol, allows for the PAA to install access control mechanisms in the network, based on the results of the AAA protocol exchanges. This follows the model of current Radius being able to provide filtering rules to NASes.

The working group will also provide documentation on

- Requirements placed on the protocol (in requirements draft)

- Chosen approach for handling the security issues and which existing security mechanisms that are chosen for the protocol. (in framework draft)

- What assumptions the protocol is making on the AAA infrastructure e.g. in terms of security. (in framework draft)

- The relative location of the PAA and any access control functions in the network and how their location affects the performance and scalability of the PAA solution, as well as the tradeoffs in the level of access control enforcement. (in framework draft)

- The relationship between the PANA protocol and e.g. PPP and 802.1X in deployment where both might be viewed as useful. (in "interactions" draft)

A naive view of a PANA protocol would just be to define how to carry EAP (RFC 2284) messages in an IP based protocol. However, EAP makes certain assumptions about PPP like link-layers such as:

- The link-layer is point-to-point i.e. a single NAS or Access Router is involved in the EAP exchange. For PANA there is a desire to be

able to support redundant ARs on multi-access link layers where inbound and/or outbound packets might use more than one AR.

- The link-layer providing a disconnect indication. PANA should not make this assumption. The assumption affects both the ability to tell when the session has ended from an accounting perspective, and it affects the frequency at which the device needs to be reauthenticated.

A possible way to address the need for more frequent re-authentication is to have the first authentication, using the AAA infrastructure and the assumed shared secret between the device and its AAA home domain, create a security association between the device and the PAA. Then re-authentication can be done using this security association without involving the AAA infrastructure. Note that this local security association is between a pair of entities: the device and the PAA. It is not intended to be viewed as some general security association between the device and the operator of the access network. In fact, such general security associations are outside the scope of PANA.

The WG will not directly work on solutions relating to mobility of the device. However, it is noted that the ability to re-authenticate locally with the PAA, can be an important element in allowing efficient handling of mobile devices.

The PANA protocol needs reliability and congestion ontrol, taking into account that the PANA protocol needs to be able to operate over multiple router hops. The congestion control principles are documented in RFC 2914.

The WG will not invent new security protocols and mechanism but instead will use existing mechanisms. For example, already specified EAP methods. In particular, the WG will not define authentication protocols, key distribution or key agreement protocols, or key derivation.

The protocol must support both IPv4 and IPv6, but given that the MOBILEIP WG is building Mobile IPv4 specific solutions to this problem, the urgency for solutions are likely to be higher for IPv6. The protocol must not assume a particular method of IP address configuration. In particular, it must not interfere with standard techniques and protocols like IPv6 stateless address autoconfiguration (including the temporary addresses specified RFC 3041) and DHCP. This implies that it is desirable that the PANA protocol be independent of IP address configuration.

Goals and Milestones:
Dec 01   First draft of Usage Scenarios I-D (Informational)
Feb 02   Submit first draft of Requirements and terminology I-D (Informational)
Mar 02   Usage Scenarios I-D sent to the IESG for consideration as an Informational RFC.
Apr 02   Submit first draft of Framework specification based on scenarios I-D (PS)
May 02   First draft on PANA interactions with PPP and 802.1X (INFO)
Jun 02   Requirements and terminology I-D sent to the IESG for consideration as an Informational RFC.
Jun 02   First draft of Protocol specification I-D (PS)
Aug 02   Framework document sent to the IESG for consideration as Proposed.
Oct 02   PANA interactions with PPP and 802.1X to IESG
Nov 02   Protocol specification to IESG
Dec 02   First draft of MIB definition (PS)
Mar 03   Submit MIB Definition I-D to IESG for consideration as Proposed.
Mar 03   Close down or recharter
No Current Internet-Drafts

No Request For Comments

Current Meeting Report


PANA WG Meeting Minutes, SLC, Thursday, Dec 13th at 1530-1730
=============================================================

Thanks to Jarno Rajahalme, Eva Gustafsson and Gopal Dommety for taking the notes.

AGENDA:

1. Agenda bashing & WG Milestones Discussion 20 Mins
B. Patil/S. Das

The chairs presented a short history of this working group: BURP BoF, URP BoF, PANA WG( (BURP->URP->PANA, Internet Area) and then charter Highlights:

To define a protocol between a user's device and a node in the network that allows:
-- the device to authenticate to an agent in the local network (PANA authentication agent, PAA)
- the device to discover the IP address of the PAA
- the PAA to use either local mechanisms or the AAA infrastructure to authenticate the device.
- PAA provides hook to access control protocol but does not specify any access control mechanisms (this is out of scope for PANA)

Issues: requirements on the protocol, approach for handling security issues, relation to AAA infrastructure.


- WG will produce
- - Usage Scenarios (Info)
- - Requirements and Terminology (Info)
- - Framework (PS)
- - - Chosen approach for handling the security issues with existing security protocols
- - - Assumptions the protocol is making on AAA infrastructure
- - - Relative locations of the PAA and any access control functions
- - Interactions (Info)
- - - relationship to PPP, 802.1x
- - Protocol Spec. (PS)
- MIB Definition (PS)

The chairs also presented milestones.

- challenging schedule, but strive for high quality documents must not miss the window of opportunity

Question: Relation to address assignment

Answer: Will be addressed later on

Question: What exactly is the problem we are trying to solve here? Why not Use IPSec instead.

Answer: Parameters/credentials needs to be sent from the user device to the network, then we can utilize the AAA infrastructure in the backend to authenticate for access.

AAA is not running to the laptop, need to carry the credentials from the device to the AAA client. Extending AAA mechanisms to the user's device. Today we have PPPOE, 802.1x is doing similar, but 802 specific, don't apply to e.g. CDMA-2000.


Question: EAP is already supported by Diameter. Are we looking for EAP or something else? Do we really need something else?

Answer: We are looking for a generic solution; we don't want a mechanism that is specific for each link layer. But of EAP works everywhere...
The intent of PANA is Transport and not to re-invent EAP.


Question: 802.1x is an EAP wrapper. If everyone is else is using EAP why we need something else? All link layers already have it?

Answer: Is this a BOF or the WG? Anyway, here we are using multi-access links although it can be used also on point-to-point links.

Comment: These questions and answers need to be made clear and go into the framework introduction, or people will ask the same questions over and over again.


2. Usage Scenario Draft 30 Mins
http://people.nokia.net/~patil/Internet_Drafts/draft-ohba-pana-usage-scenarios-00.txt
http://www.ietf.org/internet-drafts/draft-ohba-pana-usage-scenarios-00.txt
Yoshihiro Ohba

Changes:
- removed key distr. to other apps
- mobility auth token removed
- added terminology
- added "LSA Details" section
- Terminology

Scenarios:
- limited charge-free network access
- Multi-ARs in a single subnet
- 3 possible locations for the PAA
- access router, other (core) router, independent PAA
- Device with multiple interfaces
- Interface switching/multi-homing/interface sharing
- IPsec tunnel to protect ND if an Ethernet switch is between a GD and AR
- A GPRS scenario
- Intra-domain, inter-technology handoff

Question: There are two parts of authentication; initial (full) authentication that goes back to AAA, and local exchange. Does re-authentication mean doing the same thing as initial authentication?

Answer: Re-authentication is performed when lifetime expires...
Comment: There are two reasons for authentication; for the AAA to say that you are still there, and for the local access to say that you are still there.

Answer: This will be defined in the terminology. Chairs also agreed that we need terminology clarifications..

Note: There was a discussion on charge-free local network access, on authorization and policies; if there is a charge PANA is used, if there is no charge there is no PANA...

Question: Local vs. Global re-auth. Do we need terminology to make the distinction?

Question: (ref. limited charge-free) Walled-Garden? Authorization over PANA?

Answer: PANA not used to pass any policies for access, policies at the access network.

Comments: No need to go through the solutions at this point, just present the scenarios
: PANA should not be concerned about neighbor caches or address resolution
: Now we should discuss only about what the WG should be doing

Question: Do you assume IPv6?

Answer: The slide is for IPv4.

Comment: It would be useful to get your view on why usage scenarios are useful in the first place. Usage scenarios should explain: this is something people want to do with our network that they cannot do today that would be enabled with PANA. (That type of scenarios would be better that the level we are working on.)

Question: Why it is that the scenarios are useful in first place? Going through interactions with routing etc. is not addressing that fundamental question

Question: Do you differentiate between user and device authentication in these scenarios?

Answer: Basically, the user is authenticated.

Comments: One way to see it is to do like PPP does; you authenticate a identifier.
: We cannot mix the identifiers; it is crucial to understand what is user and what is device.
: PANA SHOULD use AAA (not MAY).

Comments: Large rat hole on identification: Identify the device with what ever identifier PPP uses.
: PANA should be mandated to use IETF AAA Standard
: backend can be anything
: Using something else than Diameter should be out of scope. Legacy reasons to use something else.
: Diameter/Radius/LDAP/Whatever
: It leaves scope for various protocols, but not IETF protocols are outside the acope.

Comment: What PAA uses in the backend does not matter; we define the protocol between the device and the PAA. This will come up in the requirements; what PAA uses in the backend could be anything (Diameter, RADIUS, local configuration...)
Answer: It is not irrelevant what protocol is used by the PAA in the backend, since the user needs to provide credentials.

Question: Difference between GPRS case and the multi-access case?

There was a comment about using Kerberos in the PAA backend, and a short discussion about its vulnerability to attacks.

Answer: Kerberos for wireless access? We should not go to the Kerberos.. as it is proved that Kerberos is vulnerable to Dictinoary attack. Thomas Wo's paper on how to crack Kerberos, very effective crack.

Comment: All these scnearios are being deployed today and work. so what are we doing with this new protocol?


3. A Smart-Card based scenario for PANA Framework 10 Mins
Jari Malinen

http://www.ietf.org/internet-drafts/draft-kniveton-sim6-00.txt

- Experimental, mobility friendly scenario
- Simple carrier of an authentication method (ICMP)
- Requirements
- - Domain model flexibility (2 or 3 domains involved)
- - Modularity and extensibility
- - No assumptions on where the authorizer or KDC resides
- - - Smart Card generates keys locally
- - - Another instance of then key moved elsewhere

Question: IPR issues on your proposal (reduced roundtrips)?

Comment: This issue was never really clarified...

Comment: IPR question is a valid question?
Answer : Specific EAP method IPR is pointless for the WG consideration

Question: AKA or GSM EAP method. Is the smart card relevant here?

Comment: Should focus on how to carry EAP over IP

4. Discussion on Requirements and Framework for PANA 30 Mins
S. Das/B. Patil

The chairs initiated a discussion on requirements and framework for PANA (to create a requirements and framework I-D) Objective/Goals

Comment: Should have once sentence "How to use EAP over IP"

Answer: Yes, but that is a solution and we should not go into solution space yet.

Comments: PPP not necessarily our solution
: Keeping EAP in mind will help focus the
: If EAP fulfills the requirements, then use it

: Done already?

Comments: EAP over IKE may also fit here... EAP is part of the answer.
: Everyone is using EAP; we cannot ignore it.
: Done already
: PIC ? (IPSRA)
: MIPv4 done, MIPv6 not done, do not want Mobile IPv6 specific solution.
: Not doing EAP is not an option anymore.

Comment:EAP over IP may not be the only answer. what abot EAP in IKE? looks like there is an EAP component

Answer: this seems more of an architectural issue.


- Scenario 1

Issue 1,
Issue 2,
Issue 3: How often to authenticate?
Issue 4:
Issue 5: Location of the PAA?
Issue 6: PAA Discovery?
Issue 7: Implications to access control
Issue 8:
Issue 9: How to carry auth. info?
Issue 10: LSA?
Issue 11: Relationships between PAA & AAA protocols
Issue 12: Assumptions for the AAA infra?
Issue 13: What happens if no AAA infra?
Issue 14: Transport protocol to use for reliability?

More issues?

5. Input for PANA requirements (Alper Yegin)
<draft-yegin-unap-snard-00.txt> 10 Mins

- a carrier to AAA
- a front-end to AAA
- Already done for MIPv4
- PANA should be generic
- - can be used to provide some FA-functionality in the visited network (operator requirement)
- "A" is for authentication
- - implicit Authorization
- - Should be extensible to the latter "AA"'s

- Should be fast!
- Piggybacking on existing signaling
- PAA discovery (simple, fast)
- Intra-domain movement
- - key distribution
- - LSA
- - Context transfer
- - hierarchies
- AAA trust relationships
- Security
- - capability for periodic and on-demand auth. (session lifetime)
- - Replay protection
- - Use NAI
- Not all clients have an IP address at the time of PANA execution

Question: Are you assuming that the PAA always runs on the access router?

Answer: Not all PAA functionality needs to be in the access router, but yes, there is a correlation; if the PAA is not in the access router, you need an IP address to get to it.

Comments: If not in AR, need at least a relay in the first hop router?

Comment: Confused by the statement that this should work without IP address.

Answer: Best end to anchor is NAI.

Comment: NAI-issue: NAI is used with AAA for message routing. IP address is totally useless as an identifier. Compare to the DHCP with relays, i.e. the PAA location is irrelevant.

Comment: Try to design for a generic problem (not specific problem).

Comments: PANA is a carrier; nothing more. PANA can be used to carry EAP over.
: The location of PAA is irrelevant.


Question: SAs? Imply IPsec?
Answer: Not necessarily

Question: Let's not just focus on the one specific example scenario (roaming w/ NAI)

Answer: Do not confuse examples with the protocol architecture. EAP over PANA will be very flexible.

Comments: There seems to be some confusion that this is targeted towards mobile or implicit roaming involved.

Commensts: Roaming is implied here.
: Efficiency in MIPv4 combination of Address config, Access Auth, and mobility management. Also has important security properties.



6. Summarize/Next Steps 20 Mins
Chairs

Patil: Next Steps
- Terminology / Requirements draft volunteers?

The chairs stated that we need to come up with requirements and terminology, and asked for volunteers to work on it.

Slides

Agenda
PANA Usage Scenarios
Discussion on Requirements and Framework
Input for PANA Requirements and Framework
A Smart-Card-based scenario over PANA framework