Current Meeting Report
Slides


2.3.10 Protocol for carrying Authentication for Network Access (pana)

NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 05/20/2002

Chair(s):
Basavaraj Patil <basavaraj.patil@nokia.com>
Alper Yegin <alper@docomolabs-usa.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Erik Nordmark <erik.nordmark@sun.com>
Internet Area Advisor:
Erik Nordmark <erik.nordmark@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
Internet-Drafts:
  • - draft-ietf-pana-usage-scenarios-02.txt
  • - draft-ietf-pana-requirements-02.txt
    • No Request For Comments

    Current Meeting Report

     PANA Meeting Minutes
    IETF 54
    July 15, 15:30-17:30
    Note taker: T.J. Kniveton/Nokia
    WG Chairs: Basavaraj Patil and Alper Yegin

    Basavaraj:
    Presented the agenda.
    Goal of today's meeting is to go over enhancements to the charter and to talk about revised requirements, Scenarios where PANA can or may be applied, and then what kind of issues will a PANA solution have to deal with.

    Most questions about the nature of PANA are answered in the FAQ written after the last IETF. The URL is in the presentation.

    ---

    Charter issues dealt with since IETF53:
    At last IETF, many questions about objectives, which were dealt with on the mailing list.

    - Should PANA access agent and enforcement point be colocated? If not, a subsequent protocol would be needed.
    - discussion concluded that PAA and EP should be colocated.
    - Location of PAA? can it be located beyond the first hop router or point of attachement?
    - PAA must be located on the same IP subnet/link as the PaC (i.e. first hop router or even AP)
    - PAA is not enforcement entity for access control
    - Just an interface to backed AAA infrastructure
    - Can communicate with EP which may be AR/AP
    - IP address assignment- what is role? There was a lot of discussion about this on mailing list
    - Conclusion: Node must have an IP address before PANA messaging occurs.
    - Is PANA required when you have 802.1x or PPP available
    - PANA does not necessarily compete with these, depending on scenario.
    - PANA is L2 independent for access authentication
    - Many security issues are still remaining
    - Session hijacking, protection of packets, other open issues.

    Outcome of discussion
    - Revised charter, with narrower focus and clear goal. ADs reviewed; awaiting IESG approval.

    Questions?
    <Charlie> Is this URL right? (http://www.toshiba.com/tari/pana-charter.txt)
    <Basavaraj> Try it again.

    --
    Requirements and Terminology - Alper Yegin

    - Reynaldo Penno is editor of this document now, but couldn't attend this IETF.
    - Authentication Protocol
    - Goal is not to invent a new protocol. Current thinking is that EAP should be sufficient.
    - If extensions to EAP needed PANA WG will define requirements, not solutions. Will take these to EAP group or elsewhere to satisfy needs on PANA
    - Device Identifier needs to be integrity protected in PANA request sent by PaC
    - EAP doesn't do that, but do we really need this?
    - If per-packet auth encryption not used, spoofing can happen anytime.
    - Otherwise, checking DI is redundant
    <Hesham> Maybe you can make this dependent on upgrading the encryption

    - PAA and EP: PAA needs to communicate filters etc. to EP
    - PAA and EP are colocated. Anything else is outside scope
    - PAA generally on first-hop router. Requires discovery mechanism for client.

    <Erik N.> Question on previous slide. Popping up a couple levels, I think there might be different threats, in which case different solutions might make sense. I think this needs to be written down somewhere in a document
    -- threat analysis. A possibility is that you authenticate security, but allow people to steal somebody else's authenticated service. So a cleartext DI that anyone else can spoof is sufficient. As long as you're there, somebody can spoof your DI; that might be acceptible tradeoff.
    <Alper> We should have a threat analysis document.

    - IP address configuration
    - Must have IP address first. DHCP, autoconfig, etc. Could be temporary address, or keep using it after PANA.

    - Heartbeat: required for links that do not provide disconnect indication.
    Optional usage.
    - Comments?

    <Steve Deering> What is timescale of heartbeat? I'm thinking there are already effectively mechanisms: lease for DHCP, IPv6 addresses can be advertised with lifetimes, does mobile IP already have requirement for frequent-enough messages? Is this high frequency - every 1-10 seconds?
    <Basavaraj> Intention is for disconnect indication. Depending on type of link, every 2 seconds. If nothing else will provide, then it's there.
    <Alper> Purpose is to detect when client leaves network to prevent hijacking
    <Hesham> Time-based charging might be another reason
    <Steve> So you're wise not to send this thing

    <unknown> About heartbeat, is it between client and PAA?
    <Alper> Yes. It's between the PANA end points, that is PaC and PAA. It's not between PaC and EP.
    <unknown>Right, but assumption is they're (EP and PAA) colocated.

    <unknown> Could lead to denial of service
    <Basavaraj> Security implications of doing authentication at L3 is something we need to consider

    <Deering> Hope you're sending it as a link-local multicast, to survive failure of PANA client
    <Basavaraj> You're suggesting solution of how to implement this.

    <Derek Atkins - Security area> Heartbeats/Keepalives turn into make-deads.
    If there is congestion, keepalives may get dropped and your network connection disappears. If you bill per time, you just reauthenticate every per-time period. I recommend getting rid of heartbeats completely.

    <steve deering> My question was more generic requirements. Do you need to support multiple PAAs
    <Alper> Network supports multiple access routers. And there can be several authentication agents on the network.

    <Thomas Narten> You're making assumption that PAA and enforcement pt are colocated. But if there are 2 routers, and you want to switch routers, you need communication between routers to support this. Can we safely say that PAA and EP are colocated? Doesn't sidestep original problem.
    Also, is heartbeat wrong terminology? This is really a re-authentication
    <Alper> Well we also have re-authentication. So let's reconsider the current setup, might be too much.

    <Erik> If heartbeat is there to determine when to stop billing, you need to protect against someone pretending to be the guy who just left, which sounds like you need reauthentication.

    <Unknown> Are you trying to handle case where you have an ad-hoc network accessing managed network?
    <Alper> Authentication agent multiple hops away is out of scope.
    <Narten> Wouldn't it just get a managed addresss?
    <Deering> Alternative scenario, router part of MANET who is next to AR is the one who asks, rather than expecting node multiple hops back

    <Mike St.Johns> This is supposed to be a generic protocol supporting someone plugging into a wire, right? So if we find a generic situation which I can implement in all situations, then there is no reason to implement this.
    <Erik> Even if the problem is solved by this protocol, there is nothing to prevent neighbors from just stringing ethernet wires.
    We've talked about this as being generic, but it's unclear this provides the mechanism we're talking about because it won't work in all situations.
    <unknown2> If this locks me down to one address, this means that I can't use privacy extensions in v6
    <unknown1> Cable modem systems let anybody come on
    <unknown3> This is a topical question with Time Warner sending out letters to people using 802.11. We need to move to a model where if you use an excessive amount of bandwidth, you pay for it. If I am sharing my connection with 100 people, I am doing a service by reselling the bandwidth
    <Erik> we can have a good discussion if we have something written down.
    <Mike St. Johns> If it's trivial to bypass authentication (i.e. friend is on same layer 2 access network), this protocol doesn't do anything to improve that process. If we have a hole in the process, we need to understand what we're actually getting from this protocol.

    <Unknown> Question on different topic. If you have public shared hotspot, PAA will be managed separately by operators, but EP might have to be on a separate device.
    <Basavaraj> PAA addressible by separate addresses. But IP's can be colocated on same box
    <Alper> PAA on EP, and only on backend, requests are forwarded to different AAA servers.
    <Unknown> EP could just forward directly then. Proxy functionality. What is the definition of PAA then?
    <Alper> Functionality is PANA endpoint. PANA is front end to authentication protocol.

    <Unknown> Getting IP address first -- is it possible to run pana coincident with DHCP so that you don't get an address if auth fails?
    <Basavaraj> in terms of simplification, we have concluded that it has to have an IP address.

    <Unknown> Suggestion of additional simplification. If we can have access to multiple PEs, why not require unique relationship with EPs? If I have access to more than one EP, I have to establish unique relationship with PAA.
    <Narten> So client interacts with each PAA and run PANA with both of them?
    Yes. Then you can require PAAs to talk to each other.

    <Unknown> PaC's may be able to communicate with each other, and authentication between them may be important in ad-hoc networks
    <Basavaraj> Please write up this scenario and post to the list.

    <Gopal Dommety> Do we really need IP addresses?
    <Basavaraj> Check the list for this discussion. After PANA happens, there may be a new IP address, or characteristics of IP address then change.
    <Erik> We tried to restrict this to have colocation, and IP address. But we could expand this stuff if there is a good reason to. 6 months ago this was nebulous and it wasn't clear how to find a solution. So this is part of a focusing effort but scope is not closed forever. But whomever wants a larger scope

    <Jarno R.> Was IP issue decided before or after colocation issue? Many problems with unspecified addresses if colocation is not there, but otherwise.
    <Basavaraj> Discussion was done after colocation of PAA and EP.

    ---

    Usage scenarios
    Yashiro Ohba

    - Mobile IPv6, CDMA 2000, DSL/Cable modem, Limited scope access network
    - MIPv6
    <Steve Deering> Why is mobile IP relevant here? The PaC is asking for access to the internet. Once it gets it, it will use it to do a binding update. But i don't understand why this is specifically motivated by mobile ip.
    <Basavaraj> Earlier in MIPv4, you have a FA where we show PAA. To a certain degree, it does authentication. So FA was essentially performing role of PAA. But even if you're not doing MIPv6, your point is still valid.
    <Hesham> This is important, because you don't want to confuse sending AAA messages with sending mobility signaling. You could replace sending MIPv6 with sending HTTP.

    - Multi-layer authentication. In CDMA2000, server system authentication and then higher layer authentication (PPP/Mobile IP)
    - PANA can be used for authentication in the case of Simple IP service in lieu of PPP.

    - DSL - PANA works in any topology
    <Unknown> in DSL modem or customer premise equip, there may be a router. Can we use this scenario?
    <Ohba> In that case, the router functionality is combined in DSL modem. So home router can be PaC on behalf of client behind home router.
    <unknown> How about guest?
    <Basavaraj> You're basically creating an access network at home, and could use a PAA there.

    <Gopal> Does PANA allow for authentication of services? For example, 802.1x does not have that capability.
    <Basavaraj> We did discuss this to a certain extent on the mailing list.

    - Last scenario: limited scope access networks (original scenario).
    - Limited scope access is unrestricted. Then access to internet requires PANA authentication

    <Unknown> Who initiates the authentication
    <Ohba> We'll discuss this during the solution issues presentation later.

    - Example: local web server can be accessed without authentication

    <Deering> Local free services are on other side of PAA (not on same subnet as host). That's where it gets interesting. I.e. you might have a router between the PaC's and services.

    <Mark Townsley> DSL uses PPPoE and PPPoA, which assign addresses after authentication. Actually this is a requirement.
    <Narten> issues of migrating away from PPP are pretty big. Whether to use PANA are at most 10% of the problems there so let's not use it as a justification. This scenario is not realistic, but wishful thinking in some sense.

    <Unknown> Could I authenticate a machine, then authenticate a user? Like what exactly am I authorizing? Is there a way to do layered authentication?
    <Alper> A client is authenticated, and credentials are supplied by the client. Network access is authorized to the device being used by the client.
    <Basavaraj> You could authenticate at layer 2, and then authenticate the user at a higher layer (PANA). But not in the scope to use PANA to control the scope.
    <Deering> The service being authorized is being able to send and receive packets to an IP address. And if the packets don't carry user info, talking about user authentication doesn't make sense. The service is the ability of the wire to emit and receive packets.

    ---

    Issues w.r.t protocol solution

    - UDP/ICMP/IP?
    - What would be PANA based on to encapsulate EAP?

    <Hesham> What about a connection-oriented protocol?
    <Pascal> SCTP allows you to do partial reliability
    <Narten> Are you suggesting SCTP ought to be a candidate?

    <TJ> What about using ICMP embedded data option?
    <Alper> It may be difficult to get ICMP #, and requires IP stack changes <TJ> OK, IP stack is going to need to be changed to implement this anyway.

    <Unknown> PANA + IPsec differ remarkably from PPPoE.
    <Alper> There is physical protection (unshared medium). Can just use PANA.
    CDMA2000 has L2 protection. If no other protection, PANA might be used in conjunction with IPsec.

    <Gopal> What is identity? We don't have an IP address, and MAC address can be spoofed
    <Alper> you may have to rely on IPsec and use IP address as identity.
    <Deering> IPsec would solve the problem but the overhead is high. Might want to use ESP and AH to remote place; generating separate signature and sending in packets seems to be a non-starter
    <Pete McCann> NAI is right id to use. IMSI is going to go away eventually. Distribute keys down to layer 2.

    <Unknown> Authenticating machine and getting access vs. auth user. So we are talking about multi-layer auth.
    <Basavaraj> Device identifier - MAC address.
    <Unknown2> IMSI or ESN is tied to subscriber record somewhere.
    <Deering> Credentials presented are who is it that's going to be billed? Doesn't say anything about multiple users and which ones are authorized to send packets.

    <Unknown> IMSI is only pointer to HLR/VLR or AC used today. When you talk about NAI, that's more meaningful for AAA server, which gets involved later on. It is really an architecture issue to bring these two together.

    <Erik> Steve's comment - you could use IPsec. Well PaC could just be router at your house; might not know how to map to users
    <Deering> You can get arbitrarily fancy with the granularity. The packets might be signed with the right thing to make your PAA happy.
    <Erik> But tagging mechanism might not extend beyond the enforcement. So cases where it works are more limited.

    - How does PaC discover PAA?
    - What would heartbeat method be?
    - According to earlier discussion, additional mechanism might not be
    necessary

    <Deering> I hope there will still be networks that allow you to get to the net without presenting your credit card. If you are doing a solicitaiton mode on every network they attach to, well I prefer the model where in v6 the RA would include a flag saying to get beyond me, you need to include some PANA info.

    - How will PANA be triggered when PaC goes beyond "free zone"?
    - PAA sends ICMP error message, sends PANA Start message, ..can PaC know on its own to send PANA start?

    <Gopal> Why are we saying two services? We should talk about service authentication in a full blown way or not talk about it at all.
    <Basavaraj> The question is what should trigger PANA to occur?

    - New IP address assignment after PANA. Reasons:
    - Another IP address with greater scope (link local vs. global)
    - Might want to obtain provider-specific IP address
    - How is it done?
    - PaC decision (policy)
    - PANA success message can have a bit to get a new address
    - Router colocated with PAA can take an action

    <Mark Townsley> PANA message with this bit contradicts with the FAQ (PANA does not do address allocation)
    <Alper> It doesn't really do address allocation, it just indicates PaC should do it.

    <Narten> Is this a decision that's been made, to get a new IP address, or just a possibility?
    <Unknown> Changing IP address on the fly might be asking a lot from the client stack

    - How do we secure protection against eavesdropping and spoofing?
    - PANA can recommend using specific EAP methods when underlying medium is not secure.

    <Narten> PANA should pick another scheme rather than developing its own.

    - If there are multiple first-hop routers, how does PANA work?
    - Each router has a PAA and responds to discoveryPaC does pana with all
    - Each router has a PAA, each PAA responds, PaC does pana with one
    - Only one router has PAA

    -Questions?
    <Erik> Last slide seemed to say that in some cases, you need a protocol to carry things between PAA and enforcement point. Maybe WG needs to put that in the charter to pick one protocol to use to do that. It might be too constraining to say that you can always colocate these, even when you have multiple ARs. Then the scope expands to pick a protocol to carry this stuff.
    <Deering> Just choose step 1, and PaC does pana with all of them.

    ---

    Next step: get feedback from IESG on charter and update charter.






    Slides

    Agenda
    Charter Issues Dealt with since IETF53
    PANA Usage Scenarios Updates
    PANA Requirements and Terminology
    Issues to Consider w.r.t Protocol Solution