Subject: [Pana] AD-review: pana-fwk (Section 3)

From: "Alper Yegin" <[email-masked]>
Date: Mon, 24 Oct 2005 14:04:59 +0300

Hi Mark,
 
We partitioned the pana-fwk document among the authors in order to
handle your review feedback. Let us tackle it section-by-section.
 
In this message I'll only include responses to your questions and issues
that may require discussion. All the other straight-forward editing is
omitted.
 
Please see below and let us know if you have further comments.

==========================
 
>  Authentication Server (AS):
>
>     The server implementation that is in charge of verifying the
> 
>
Is this another PANA Server?
 
Alper: No, this corresponds to the RADIUS server. This term is coming
from RFC 3748 (EAP). We can clarify this.
 
==========================
 
>     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?
 
Alper: We can give a reference to pana-ipsec document here.
 
===========================
 
>  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.
> 
>
Which begs that question as to, if you already have a cryptographically 
secure connection below, why you need another layer of authentication 
above. Perhaps the answer to this is that the keys for the lower-layer 
crypto may not be owned by the users running PANA. Thus, there is not a 
1:1 association, however, the suggestion that you may bind between 
layers diminishes this claim.
 
Alper: The other layer of authentication is needed for "accessing the IP
service." The lower-layer may be already authenticated, authorized, and
crypto-secured for another service (e.g., voice in 3GPP2). Or, think of
the physical security present in DSL networks. I know there is physical
security, but I don't know who is at the other end of the wire. As soon
as I know the identity of that party, I can relate this wire to that
user. That'd be the binding.
 
===========================
 
>              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.
> 
>
 
What level of review has this received from the SNMP community?
 
Alper: pana-snmp has been reviewed by David Perkins and Robert Story.
 
Also, is it possible to need a NAT between the EP and PAA?
 
Alper: Yes. We analyzed this and found no issues. There was a
presentation on that during IETF 62.
 
===========================

>  The PaC MUST configure an IP address prior to running PANA.
>
The PaC cannot use DHCP to get an IP address? When I see "configure" I 
immediately think "statically configure."
 
Alper: Unless stated otherwise, "configured" stands for "either
dynamically or statically configured." So, DHCP is a valid option. That
issue is expanded in Section 5.
 
===========================

>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.
 
This is really verging onto the territory of multi-homing 
in general, particularly when you suggest multiple IP addresses. This 
paragraph is really leaving open a lot of possibilities, is it possible 
to constrain this?
 
Alper: When IPsec tunnels are used, there'd be at least two IP
addresses. One used inside the tunnel, the other outside. IPsec
tunnel-mode implementations already deal with this.
 
===========================

>  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
> 
>
So, SNMP is now a peer to peer key negotiation protocol ;-)
 
Alper: No, it is still used for managing and configuring devices. One of
the configuration parameters is a key.
 
===========================
 
>  In case cryptographic access control needs to be enabled after the  
> PANA authentication, a secure association protocol runs between the  
> PaC and the EP.
>
If you have already exchanged keys, I wonder why you need to exchange 
them again.
 
Alper: PaC and EP sharing a master key is not sufficient to enable, say,
IPsec. They need to use this key with a secure association protocol,
such as IKE, and produce IPsec SAs (which include more keys and other
attributes). Please see figure 4 in
http://ietf.org/internet-drafts/draft-ietf-eap-keying-07.txt. 
 
===========================

Regards,
 
Alper

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