2.3.11 Protocol for carrying Authentication for Network Access (pana)

Last Modified: 2003-08-26

Basavaraj Patil <basavaraj.patil@nokia.com>
Alper Yegin <alper@docomolabs-usa.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <mrw@windriver.com>
Internet Area Advisor:
Thomas Narten <narten@us.ibm.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:
In some scenarios, an IP-based device is required to authenticate
itself to the network prior to being authorized to use it. This
authentication usually requires a protocol that can support various
authentication methods, dynamic service provider selection, and
roaming clients. In the absence of such an authentication protocol on
most of the link-layers, architectures have resorted to filling the gap
by using a number of inadequate methods. For example, inserting an
additional layer between link-layer and network-layer mostly for client
authentication purpose (e.g., PPPoE), overloading another network-layer
protocol to achieve this goal (e.g., Mobile IPv4 with Registration-
required flag), and even defining application-layer ad-hoc
authentication mechanisms (e.g., http redirects with web-based login).
In these and other cases, a network-layer authentication protocol may
provide a cleaner solution to the authentication problem.

The goal of PANA is to define a protocol that allows clients to
authenticate themselves to the access network using IP protocols. Such
a protocol would allow a client to interact with a site's back-end AAA
infrastructure to gain access without needing to understand the
particular AAA infrastructure protocols that are in use at the
site. It would also allow such interactions to take place without a
link-layer specific mechanism. PANA would be applicable to both
multi-access and point-to-point links. It would provide support for
various authentication methods, dynamic service provider selection,
and roaming clients.

Mobile IPv4 developed its own protocols for performing PANA-like
functions (e.g., MN-FA interaction). Mobile IPv6 does not have the
equivalent of a Foreign Agent (FA) that would allow the access/visited
network to authenticate the MN before allowing access. The PANA
authentication agent (PAA) can perform the authentication function
attributed to the FA in Mobile IPv4, in Mobile IPv6 networks.

The WG will work with the assumption that a PANA client (PaC) is
configured with an IP address before using PANA. This IP address will
provide limited reachability to the PaC until it is authenticated with
the PAA. Upon successful authentication, PaC is granted broader network
access possibly by either a new IP address assignment, or by
points changing filtering rules for the same IP address.

PANA will neither define any new authentication protocol nor define key
distribution, key agreement or key derivation protocols. It is believed
that PANA will be able to meet its goals if it is able to carry EAP
payloads. Note, however, that EAP may need to be extended in order for
PANA to meet the need for all of its intended usages. Such extensions
are outside the scope of the PANA WG.

PANA will develop an IP-based protocol that allows a device to
authenticate itself with the network (and to a PAA in particular) in
order to be granted network access. For simplicity, it is assumed that
the PAA is attached to the same link as the device (i.e., no
intermediary IP routers). The PAA itself may interface with other AAA
backend infrastructures for authenticating and authorizing the service
being requested by the host, but such interactions are transparent to
the PaC.

The PAA does not necessarily act as an enforcement point (EP) to
prevent unauthorized access or usage of the network. When a PaC
succesfully authenticates itself to the PAA, EP(s) (e.g., access
routers) will need to be suitably notified. This WG will identify a
(preferably existing) protocol solution that allows the PAA to deliver
the authorization information to one or more EPs when the PAA is
separated from EPs. A single PAA may serve many access routers. The WG
will also propose a solution of how the PaC discovers the IP address of
PAA for sending the authentication request.

The PANA WG will deliver 

- A mechanism for the PAC to discover the PAA on the link.

- The PANA protocol itself, capable of carrying multiple authentication
    methods (e.g. using EAP)

- Select or define a protocol to carry authorization information
    the PAA and the EPs.
Goals and Milestones:
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
Dec 03  Submit IPsec-based access control to the IESG
Dec 03  Submit protocol specification to the IESG
Jan 04  Submit interaction of PANA with 802.1x and PPP document to the IESG
Apr 04  Submit MIB for PANA to the IESG
  • - draft-ietf-pana-usage-scenarios-06.txt
  • - draft-ietf-pana-requirements-07.txt
  • - draft-ietf-pana-threats-eval-04.txt
  • - draft-ietf-pana-pana-01.txt
  • No Request For Comments

    Current Meeting Report

    quicker.Protocol for Carrying Authentication for Network Access (PANA) WG 
    Meeting MinutesSession: Monday, July 14 at 1300-1500Chairs:  Basavaraj Patil 
    <Basavaraj.Patil@nokia.com>         Alper Yegin <alper@docomolabs-usa.com>Note Takers: Jayshree Bharatia, Paulo PagliusiTopic 1. Draft Status
    ---------------------------------Short discussion on the current document status was given by the AlperYegin.-  draft-ietf-pana-usage-scenarios-06.txt   WG last call completed on March 11, 2003. Draft is sent to ADs for IESG 
    consideration.-  draft-ietf-pana-requirements-07.txt   WG last call completed on June 12, 2003. Draft is sent to ADs for IESG 
    consideration.-  draft-ietf-pana-threats-eval-04.txt   WG last call completed on May 1, 2003. Draft is sent to ADs for IESG 
    consideration.-  draft-ietf-pana-pana-01.txt   Work in progress. The draft will be discussed at IETF 57.Topic 2- Securing the first hop in PANA using IPsec by Hannes 
    ---------------------------------The intent of the draft was discussed in brief. This draft provides a 
    mechanism for enabling IPsec-based per-packet authentication between the PaC 
    and EP, once the client is authenticated by using PANA. IKE 
    pre-shared key is derived from the PANA SA, which is established when PaC 
    and PAA authenticate to each other.  Pre-shared key is derived from the 
    PANA SA. It was mentioned that manual key distribution is not used. Main 
    mode and aggressive  mode are easily supported. There may not be any 
    issues for IPv4. For IPv6, the router and neighbor discovery related 
    extensions are different. Also, the initial problem may be that IPSec 
    selector can't be used as a traffic selector. All packets are tunneled to 
    the link local address of the EP. The packets are protected twice, for 
    local and the remote networks. IKE pre-shared key derivation is done from 
    the PANA security association. The recommendation was to use the IPSec 
    tunnel mode instead of the IP-IP Transport mode.Hesham Soliman - The problem of the selector seems like the 
    implementation problem which may be solvable. This comments was revised 
    later in the discussion based on the different understanding.? - It is necessary for PANA WG to contact IPSec WG for solution of the 
    selector problem. Keys are for the bootstrapping IKE. If this is the case 
    than it will be more complicated.James Kempf -  If PANA is already solving the PAA and host(MN) security 
    problem, why it is necessary to have IKE exchanges?Alper Yegin - The current mechanism allows binding of the client ID to the 
    data traffic. The PANA association is not exactly the IPSec 
    association. There needs to be some kind of binding between them.James Kempf - Can't we just carry EAP inside IKEv2?Alper Yegin - Are you suggesting replacing PANA with IKEv2?James Kempf - No, run IKEv2 independent of and after PANA.Alper Yegin - Let's take this offline and discuss on the PANA mailing 
    list.Brijesh Kumar - I am not convinced that the mechanism described in this 
    particular I-D is useful, since link layer security mechanism already 
    provides enough security. There is no need to run IPsec twice on a single 
    client.? - The end points are different and they provide different level of 
    security. The safe assumption here is that there may not be security 
    support at the layer 2.Chairs did a consensus call on whether or not to adapt this 
    individual submission as an official WG item, given that the WG had 
    already agreed to tackle this problem space. 15 people said agreed, 5 
    disagreed to the adoption of this draft.Conclusion: There is consensus on the adoption of this draft as an 
    official WG item.Topic 3. PAA-EP Protocol Considerations: By Yacine El Mghazli
    ---------------------------------- Terminology like PAA, PaC, EP were discussed in brief along with the 
    scenario description of PAA/EP separation (when PAA separated from AR and 
    also when PAA co-located with AR.- The following PAA-EP Protocol Requirements were mentioned. The details of 
    these requirements are noted at 
    tf/draft-yacine-pana-paa-ep-reqs.txt.  a. Discussion objectives    - No new PANA protocol design    - Use of existing protocol  b. Core Requirements    - pana-req-07 document is used as a base    - Secure    - one-many PAA-EP relationship    - Provisioned data  c. Nice to have functionality    - Pull model    - Inactive peer detection    - recovery- The Protocol Comparison discussion included comparison of SNMP, 
    COPS-PR, DIAMTER and ForCES protocols.  1. SNMP Applicability: Description on how SNMP satisfies the current 
    requirements and also few pros and cons are discussed.  2. COPS-PR: Same as SNMP, it satisfies most of the requirements but 
    seems like having more advantages.  3. DIAMETER: It satisfies all requirements but not meant to be used for 
    provisioning.  4. ForCES: This protocol is still being discussed. Otherwise seems like 
    satisfying most of the requirements.Gabriel Montenegro - What is the relationship between this subject and 
    CAPWAP (BOF)?Alper Yegin - This is about provisioning, and it is not PANA protocol. 
    CAPWAP has also some aspects of this. This is a good question, let's ask it 
    at CAPWAP meeting as well.Ralph Droms - What about NETCONF as another PAA-EP protocol 
    candidate?Alper Yegin - Sure, we should look at that too.Reinaldo Penno - Let's do not waste too much time in the Protocol 
    evaluation process. Let's make it quick and simple.Conclusion:The topic is still open to the discussion. There may be a need of 
    coordination with other IETF work groups like netconf.Topic 4. PANA Discussion and Open Issues:
    ---------------------------------The list of PANA issues can be found at
    http://danforsberg.info:8080/pana-issues/.Issue 9:Issue: Message format not defined in the 00 draftProposed solution: Diameter-like message format is suggested to be used 
    (header+AVP)Issues 4,5,16:  1. Device ID needs to be updated     Proposal is to use Re-auth command which contains new device ID.  2. MAC and IP address are used at the same time     Couple of proposals are discussed: Support either MAC or IP address as 
    DI and not both addresses at the same time or use both addresses 
    (assuming that SEND will solve the issue).     Alper Yegin - Is it really useful to bootstrap 2 layers of 
    ciphering?     Pasi Eronen - Both L2 and L3 may be useful, 3GPP does that.     Alper Yegin - What is the purpose of two layers of ciphering in 3GPP?     Pasi Eronen - One for the local access, one for the remote access to 
    home domain.     John Vollbrecht - Is this same as EAP with MASTER KEY and Multiple 
    Session Keys?     Alper Yegin - Yes, it is.  3. In single Device ID, use multiple IP addresses.     PaC can have multiple IP addresses on the same interface. This may not 
    be issue since it is not required to have different interfaces 
    specified for all IP address, Is this sufficient or is there any need of 
    mentioning all IP addresses as DI and bind to session.     Melinda Shore - Why do we use DI in PANA (regarding the use of 
    addresses as identifiers)?     Alper Yegin - We need it to bind the authenticated client to its 
    associated data traffic.     ? - Change of address in the middle of session should be looked at as 
    well.     Ralph Droms - What is the impact of IPv6 privacy addresses on DI?     Alper Yegin - Generally link-local IPv6 address is used as Device ID. 
    Hence, if the inner IP address change, there shouldn't be any problem.Issue 6:How can a PANA session identified? The proposal was to use new 
    session-Id.Issue 3:New section is added to the document describing PANA security 
    association establishment (section 5.0).Issue 8:The discussion took place on what parameter should PAA communicate to 
    perform re-authentication. Session lifetime and Refresh interval were 
    mentioned.Issue 11:For the PANA client notification, the author added new section 4.10. Also, 
    PAA-EP protocol is evolved to solve this problem.Issue 7:Moving context from one PAA to another PAA may be required for the 
    performance reason. The new section 4.9 (Mobility Handling) is added 
    describing this.Issue 15:It was mentioned that the cookie mechanism defined for the discovery and 
    handshake phase might not be effective for controlling the on-link 
    attackers. In Puzzle mechanism, PAA sends a challenge that does not need a 
    shared secret for a PaC to respond but need some calculation on PaC. The 
    current proposal is to make cookie as a default and study more on the 
    security aspects of puzzle and include it in some separate document.Issues 18,19:Some of the result codes ported from the DIAMETER are intended to be used 
    for the PANA-Result-Request message.Issue 1,3:The discussion took place whether PANA needs to support capability 
    negotiation. The capability negotiation outside of the EAP can be placed for 
    downgrading the  attack. The proposed solution is to support 
    capability indication.Topic 5. Next steps
    ---------------------------------Basavaraj Patil talked about the next steps for the WG. PANA-IPsec draft 
    will be updated based on the feedback. The goal is to finish the PANA 
    protocol specification by next IETF. Provisioning protocol 
    discussions will continue on the PANA mailing list. We will arrange an 
    interoperability testing among the implementors of PANA.


    Protocol for Carrying Authentication for Network Access
    PANA enabling IPsec based Access control
    PAA-EP protocol considerations
    PANA Discussion and Open Issues
    Next Steps