Subject: [Pana] WG Review: Recharter of Protocol for carrying Authentication for Network Access (pana)

From: The IESG <[email-masked]>
Date: Thu, 02 Jun 2005 11:12:40 -0400

A modified charter has been submitted for the Protocol for carrying Authentication
for Network Access (pana) working group in the Internet Area of the IETF.  
The IESG has not made any determination as yet. The modified charter is provided 
below for informational purposes only. Please send your comments to the IESG 
mailing list ([email-masked]) by June 8th.

+++

Protocol for carrying Authentication for Network Access (pana)
--------------------------------------------------------------

Current Status: Active Working Group

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

Internet Area Director(s):
Mark Townsley <[email-masked]>
Margaret Wasserman <[email-masked]>

Internet Area Advisor:
Mark Townsley <[email-masked]>

Technical Advisor(s):
Jari Arkko <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: https://www1.ietf.org/mailman/listinfo/pana
In Body: (un)subscribe
Archive: http://www.ietf.org/mail-archive/web/pana/index.html

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
already 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 enforcement 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. 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.

Network access authentication enables the client to be authorized for
packet data service. However it is possible that the underlying link
itself is insecure, i.e the packets being sent to and received on the
link between the client (PaC) and the 1st hop access router (EP) in the
network are not protected by any physical or cryptographic
means. In such cases, PANA will enable the establishment of an IPsec
SA between the client and the 1st hop access router to secure the
packets on the link. In networks that have physical security or
ciphering as a link-layer feature, no such SA is required. Hence the
establishment of the IPsec SA is optional. The WG will deliver a
document that explains how such an IPsec SA is established by using
IKE after successful PANA authentication. No enhancements to either
IKE or IPsec are expected.

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. SNMP will be used
by the PAA to deliver the authorization information to one or
more EPs when the PAA is separated from EPs. The WG will document
the solution based on SNMP for carrying the authorization information
between the PAA and the EP.

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)

- A document that describes how SNMP is used to deliver authorization
information from the PAA to the EP in the scenarios where the PAA
and EP are separated.

- A document that explains the establishment of an IPsec SA between
the client and the 1st hop access router subsequent to
authentication for securing the data packets on the link.

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  
Aug 04    Submit PANA framework to the IESG  
Aug 04    Submit PANA protocol specification to the IESG  
Aug 04    Submit IPsec-based access control to the IESG  
Aug 04    Submit SNMP-based PAA-to-EP protocol specification to the IESG  
Dec 04    Submit MIB for PANA to the IESG 

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

---

From: John Schnizlein <[email-masked]>
Date: Wed, 8 Jun 2005 11:13:50 -0400

Comments embedding in (trimmed) context below:

On Jun 2, 2005, at 11:12 AM, The IESG wrote:

> ... Description of Working Group:
> most of the link-layers,

The question of what widely deployed link layers lack authentication 
has not been answered.

The justification of PANA, rather than expecting new link-layer 
protocols to provide authentication comparable to IEEE 802.1X or PPP, 
has still not been provided.

> architectures have resorted to filling the gap
> by using a number of inadequate methods.....
>

The presumption of changing the IP address of the host, or the 
enforcement configuration of the host's edge of the network is 
unnecessarily complicated compared to authentication prior to address 
assignment.  Stable addressing, which DHCP was designed to facilitate, 
would be sacrificed for unspecified reasons. Dynamic modification of 
the configuration of the edge router introduces complexity in network 
management that are not resolved by reference to (pixie dust) SNMP 
(below).

> order to be granted network access.

Is mutual authentication, so that a host can avoid authentication to a 
bogus PAA not required?

> The PAA itself may interface with
> ...

Dynamic reconfiguration of the edge of the network based on user 
authentication is well beyond the design expectations for network 
management via SNMP.  In fact, SNMP was found [RFC 3535] less than 
effective as a practical solution for managing configuration, even 
without the extra dynamic demands from per-authentication changes.

> ...

Is the security area comfortable with a new general mechanism for IPsec 
over just a single hop?

If the security association is to protect PANA, it should be between 
the client and server.

> Dec 04    Submit MIB for PANA to the IESG

If the last 5 items are not done now, dates in the future would be 
appropriate.

John

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 09 Jun 2005 14:19:39 -0400

John,

Perhaps the external review announcement should have been a bit more clear, but 
this rechartering is actually limited to the specific change of allowing PANA to 
traverse multiple IP hops, where before it was confined to a single link. Sorry 
if there was confusion on that matter.

One comment of yours that seems to be directly related to this change is the 
following:

> If the security association is to protect PANA, it should be between the 
> client and server.
> 

Chairs, shouldn't there be a security option beyond the 1st hop now?

Thanks,

- Mark

---

From: Alper Yegin <[email-masked]>
Date: Thu, 09 Jun 2005 11:55:32 -0700

Mark,

> John,
> 
> Perhaps the external review announcement should have been a bit more
clear,
> but
> this rechartering is actually limited to the specific change of
allowing
> PANA to
> traverse multiple IP hops, where before it was confined to a single
link.
> Sorry

I'll respond to John's other comments/questions on a separate thread on
the PANA ML. 

> One comment of yours that seems to be directly related to this change
is
> the
the
> Chairs, shouldn't there be a security option beyond the 1st hop now?

The WG didn't feel a need to make a change on that. (Though I guess with
little or no change on the PANA-IPsec document that could be
accomplished).

Thanks.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 09 Jun 2005 12:20:13 -0700

Hi John,

As Mark said, only one part of the charter is going through the IESG
review. It's the removal of the following statement:

"For simplicity, it is assumed that the PAA is attached to the same link
as the device (i.e., no intermediary IP routers)."

Nevertheless, let me answer your following questions/comments.

> has still not been provided.

This is already described in RFC 4058 Appendix A.

> assignment.  

I'm not sure how complicated that would be, but it is necessary.

> Stable addressing, which DHCP was designed to facilitate,

Sure, mutual authentication support is needed. This is achieved by using
mutually authenticating EAP methods. 

> without the extra dynamic demands from per-authentication changes.

I don't know if you followed it but we had some lengthy discussion for
coming to this decision in the WG. Unless there is some recent
development that'd suggest revisiting this decision, I think we should
stick with it.

> Is the security area comfortable with a new general mechanism for
IPsec

This issue hasn't come up during the reviews so far. Do you see a
specific problem?

> If the security association is to protect PANA, it should be between

As the text above says, it is for protecting the data packets.

> If the last 5 items are not done now, dates in the future would be

Yes, we shall update those.

Alper

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 09 Jun 2005 17:15:46 -0400

Alper Yegin wrote:

>>>Is the security area comfortable with a new general mechanism for
> 
> IPsec
> 
>>>over just a single hop?
>>>

Why not? Can we have a little more detail?

- Mark

---

From: Alper Yegin <[email-masked]>
Date: Tue, 14 Jun 2005 11:45:13 -0700

Hi Mark,

Sorry for the late response, I was away from my e-mail.

> Why not? Can we have a little more detail?

The location of the PAA and the location of the EP(s) are independent
from each other. People could have asked for off-link EPs even when the
PAA was mandated to be on-link.

There is a tendency that the EP should be on the network element closest
to the PaCs. I think that's why WG members are content with the current
design. Of course we should let anyone who has a different point of view
to speak up.

Alper

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 14 Jun 2005 18:05:50 -0700

> design. Of course we should let anyone who has a different point of view
I am not convinced that the use case of EP being multiple hops away has been
discussed before in this mailing list. Till someone can describe the use case,
we should not talk about it in the recharter.

-mohan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 17 Jun 2005 09:36:05 -0400

I have a feeling that this is a good opportunity to make a change on
that and I have one usage:

An access network consists of a set of IP links and routers where the
IP links are using different link-layer types.  Instead of using
different L2 ciphering mechanisms per link-layer type, one may want to
use IPsec for all links.  Then it might make sense to place EP(s) on
the router(s) at the boundary between the access network and the rest
of the Internet, instead of having an EP on each router that is one
hop away from PaC.  This is also good for mobility, because once an
IPsec SA is bootstrapped between a PaC and the EP that is multiple
hops away from the PaC, the PaC does not need to perform
Diffie-Hellman key exchange every time it switches from one IP link to
another in the same access network.  Instead, the PaC will just need
to perform MOBIKE for updating IP address of the IPsec SA.

Note that as a side effect of allowing PAA to be multiple hops away
from PaC, the PANA protocol itself has already been designed enough to
allow IPsec EP to be multiple hops aways from PaC.  So it seems to me
that this is basically a deployment issue.

Best regards,
Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Sat, 18 Jun 2005 09:21:41 +0300

I agree. To me part of the appeal of L3 network access solution is that
you _can_ deploy an IP-based access network and only place the access
control solution at the border. And I don't see a need to change anything
in your protocols to achieve this.

(But I'm not sure you have worked out all the mobility details. How
does a client know, after a movement, that its still in an area where
it can use the same gateway and does not need to rerun all of PANA?
In any case, this shouldn't be something that you need to solve now;
movement optimizations should come as a later addition.)

--Jari

Yoshihiro Ohba wrote:

>>>>>The WG didn't feel a need to make a change on that. (Though I guess
>>>>>          
>>>>>
>>>with
>>>      
>>>

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 20 Jun 2005 14:08:27 -0700

> to perform MOBIKE for updating IP address of the IPsec SA.
This looks like HMIP :-) When you change access routers within the same
access network, you still configure a new PRPA. Doesn't that trigger mobility
at L3 ? Or you have assumed that all of them are advertising the same prefix
or something else to suppress L3 movement detection i.e how does it interact
with "mobility" ?

> that this is basically a deployment issue.
To some extent i agree that it is a deployment issue. But it makes some assumptions
which i don't know whether it is valid or not (today or tomorrow).

1) The access network supports links of different access types (WLAN, Wimax etc.) 
     and controlled by the same operator. If it is not the same operator, you can't have
     a single EP at the boundary of internet and access network.

2) Most of the access network has some form of "filtering" or "enforcement" at the edge.
    Why would that change in the future ? There is one exception to this that in some of the
    WLAN hotspot deployments that i know of, which uses web authentication (not 802.1x)
    the access control is not done at the APs or the router it connects to but the access controller
    that sits in a centralized place. I don't know whether this is an indicator of change :-) With 802.1x,
   it will  still be in the access points (at least the per-packet encryption/authentication).

To some extent,  i do agree that we don't have to explicitly restrict the charter to say
that "EP should be just one hop away". But implicitly assuming that it would work
may not be good.  We have at least provide some guidance (in the PANA framework
document) on how this can be deployed. I am not sure what you wanted and don't know
how fits well within the current scope of the working group.

-mohan

-mohan