Subject: [Pana] pana-fwk Issues 181 and 182

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 13 Dec 2005 17:37:39 -0500

The following is the current text for section 3 after reflecting
Mark's comments and Alper's responses:

"
3.  General PANA Framework

   PANA is designed to facilitate authentication and authorization of
   clients in access networks.  PANA is an EAP [RFC3748] lower-layer
   that carries EAP authentication methods encapsulated inside EAP
   between a client node and an agent in the access network.  While PANA
   enables the authentication process between the two entities, it is
   only a part of an overall AAA (Authentication Authorization and
   Accounting) and access control framework.  A AAA and access control
   framework using PANA is comprised of four functional entities.

   PANA Client (PaC):

      The PaC is the client implementation of PANA.  This entity resides
      on the node that is requesting network access.  PaCs can be end
      hosts, such as laptops, PDAs, cell phones, desktop PCs, or routers
      that are connected to a network via a wired or wireless interface.
      A PaC is responsible for requesting network access and engaging in
      the authentication process using PANA.

   PANA Authentication Agent (PAA):

      The PAA is the server implementation of PANA.  A PAA is in charge
      of interfacing with the PaCs for authenticating and authorizing
      them for the network access service.

      The PAA consults an authentication server in order to verify the
      credentials and rights of a PaC.  If the authentication server
      resides on the same node as the PAA, an API is sufficient for this
      interaction.  When they are separated (a much more common case in
      public access networks), a protocol needs to run between the two.
      AAA protocols like RADIUS [RFC2865] and Diameter [RFC3588] are
      commonly used for this purpose.

      The PAA is also responsible for updating the access control state
      (i.e., filters) depending on the creation and deletion of the
      authorization state.  The PAA communicates the updated state to
      the Enforcement Points in the network.  If the PAA and EP are
      residing on the same node, an API is sufficient for this
      communication.  Otherwise, a protocol is required to carry the
      authorized client attributes from the PAA to the EP.  While not
      prohibiting other protocols, currently SNMP [I-D.ietf-pana-snmp]
      is suggested for this task.

      The PAA resides on a node that is typically called a NAS (network
      access server) in the access network.  For example on a BRAS
      (Broadband Remote Access Server) in DSL networks, or PDSN (Packet
      Data Serving Node) in 3GPP2 networks.  The PAA may be one or more
      IP hops away from the PaCs.

   Authentication Server (AS):

      The server implementation that is in charge of verifying the
      credentials of a PaC that is requesting the network access
      service.  The AS receives requests from the PAA on behalf of the
      PaCs, and responds with the result of verification together with
      the authorization parameters (e.g., allowed bandwidth, IP
      configuration, etc).  The AS might be hosted on the same node as
      the PAA, on a dedicated node on the access network, or on a
      central server somewhere in the Internet.

   Enforcement Point (EP):

      The access control implementation that is in charge of allowing
      access to authorized clients while preventing access by others.
      An EP learns the attributes of the authorized clients from the
      PAA.

      The EP uses non-cryptographic or cryptographic filters to
      selectively allow and discard data packets.  These filters may be
      applied at the link-layer or the IP-layer [I-D.ietf-pana-ipsec].
      When cryptographic access control is used, a secure association
      protocol needs to run between the PaC and EP.  After completion of
      the secure association protocol, link or network layer per-packet
      ciphering (for example TKIP, IPsec ESP) is enabled for integrity
      protection, data origin authentication, replay protection and
      optionally confidentiality protection.

      An EP must be located strategically in a local area network to
      minimize the access of unauthorized clients to the network.  For
      example, the EP can be hosted on the switch that is directly
      connected to the clients in a wired network.  That way the EP can
      drop unauthorized packets before they reach any other client node
      or beyond the local area network.

                                              RADIUS/
                                              Diameter/
        +-----+       PANA        +-----+     LDAP/ API    +-----+
        | PaC |<----------------->| PAA |<---------------->| AS  |
        +-----+                   +-----+                  +-----+
           ^                         ^
           |                         |
           |         +-----+         |
      IKE/ +-------->| EP  |<--------+ SNMP/ API
   4-way handshake   +-----+

   Figure 1: PANA Functional Model

   Figure 1 illustrates these functional entities and the interfaces
   (protocols, APIs) among them.  Note that PANA will not define API.

   Some of the entities may be co-located depending on the deployment
   scenario.  For example, the PAA and EP would be on the same node
   (BRAS) in DSL networks.  In that case a simple API is sufficient
   between the PAA and EP.  In small enterprise deployments the PAA and
   AS may be hosted on the same node (access router) that eliminates the
   need for a protocol run between the two.  The decision to co-locate
   these entities or otherwise, and their precise location in the
   network topology are deployment decisions that are out of the scope
   of this document.

   Use of IKE or IEEE 802.11i 4-way handshake protocols for secure
   association is only required in the absence of any lower-layer
   security prior to running PANA.  Physically secured networks (e.g.,
   DSL) or the networks that are already cryptographically secured on
   the link-layer prior to PANA run (e.g., cdma2000) do not require
   additional secure association and per-packet ciphering.  These
   networks can bind the PANA authentication and authorization to the
   lower-layer secure channel that is already available.

   Figure 2 illustrates the signaling flow for authorizing a client for
   network access.

               PaC             EP               PAA              AS
                |               |                |                |
   IP address ->|               |                |                |
   config.      |       PANA    |                |      AAA       |
                |<------------------------------>|<-------------->|
                |               |     SNMP       |                |
   (Optional)   |               |<-------------->|                |
   IP address ->|               |                |                |
   reconfig.    |   Sec.Assoc.  |                |                |
                |<------------->|                |                |
                |               |                |                |
                |  Data traffic |                |                |
                |<----------------->             |                |
                |               |                |                |

   Figure 2: PANA Signaling Flow

   The EP on the access network allows general data traffic from any
   authorized PaC, whereas it allows only limited type of traffic (e.g.,
   PANA, DHCP, router discovery, etc.) for the unauthorized PaCs.  This
   ensures that the newly attached clients have the minimum access
   service to engage in PANA and get authorized for the unlimited
   service.

   The PaC MUST configure an IP address prior to running PANA.  After
   the successful PANA authentication, depending on the deployment
   scenario the PaC MAY need to re-configure its IP address or configure
   additional IP address(es).  The additional address configuration MAY
   be executed as part of the secure association protocol run (e.g., via
   IKE).

   An initially unauthorized PaC starts the PANA authentication by
   discovering the PAA, followed by the EAP exchange over PANA.  The PAA
   interacts with the AS during this process.  Upon receiving the
   authentication and authorization result from the AS, the PAA informs
   the PaC about the result of its network access request.

   If the PaC is authorized to gain the access to the network, the PAA
   also sends the PaC-specific attributes (e.g., IP address,
   cryptographic keys, etc.) to the EP by using SNMP.  The EP uses this
   information to alter its filters for allowing data traffic from and
   to the PaC to pass through.

   In case cryptographic access control needs to be enabled after the
   PANA authentication, a secure association protocol runs between the
   PaC and the EP.  The PaC should already have the input parameters to
   this process as a result of the successful PANA exchange.  Similarly,
   the EP should have obtained them from the PAA via SNMP.  The secure

   association protocol exchange produces the required security
   associations between the PaC and the EP to enable cryptographic data
   traffic protection.  Per-packet cryptographic data traffic protection
   introduces additional per-packet overhead but the overhead exists
   only between the PaC and EP and will not affect communications beyond
   the EP.

   Finally, filters are installed at the EP which may allow data to flow
   beyond the EP to a network, and from a network through the EP to the
   PaC.
"

The following is the comments that are not resolved yet as far as I
know.

[1] In Issue 182, it seems that the following comments are not
discussed yet:

>   Enforcement Point (EP):
>
>      The access control implementation that is in charge of allowing
>      access to authorized clients while preventing access by others.
>      An EP learns the attributes of the author
>
Do you mean access to authroized clients, or access of authorized
payloads associated with clients? I gathered that this is a *traffic*
EP, not necessarily a client EP per se.

>ized clients from the
>      PAA.
>
>      The EP uses non-cryptographic or cryptographic filters to
>      selectively allow and discard data packets.  These filters may be
>      applied at the link-layer or the IP-layer.
>
Are the details of how one identifies a packet for a given client is
detailed somewhere? This is very link-specific for the link-layer, but
for IP you should be able to suggest something - is it source IP address?

> When cryptographic
>      access control is used, between the PaC and EP.
>

[2] In Issue 181, I am waiting for text:

>After

>  the successful PANA authentication, depending on the deployment

>  scenario the PaC MAY need to re-configure its IP address or configure

>  additional IP address(es).  The additional address configuration MAY

>  be executed as part of the secure association protocol run (e.g., via

>  IKE).

I think you need to warn the reader what this really means. Changing an 

IP address is not something that is always seamless for a host or set of 

applications. 

Alper: Yes, we'll add some text for that.

Regards,
Yoshihiro Ohba

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 19 Dec 2005 02:37:35 -0500

> EP, not necessarily a client EP per se.

Here is revised text:

"
Enforcement Point (EP):

The access control implementation that is in charge of allowing access
of payloads associated with authorized clients while preventing access
of other payloads.  An EP learns the attributes of the authorized
clients from the PAA.
"

> Alper: Yes, we'll add some text for that.

Here is revised text:

"
After the successful PANA authentication, depending on the deployment
scenario the PaC MAY need to re-configure its IP address or configure
additional IP address(es).  The additional address configuration MAY
be executed as part of the secure association protocol run (e.g., via
IKE).  If this additional IP address configuration happens in the
middle of an application protocol run, an appropriate procedure for
changing an IP address will need to be taken so that the IP address
change is transparent to the application protocol.
"

Regards,
Yoshihiro Ohba