Subject: [Pana] RE: Review of draft-ietf-pana-ipsec-07

From: "Alper Yegin" <[email-masked]>
Date: Mon, 29 May 2006 01:17:22 -0700

Hello,

I realized that the PANA-IPsec review touched upon some discussions that
pertain to the base protocol specification (draft-ietf-pana-pana-11.txt). 

Let me separate those issues from the PANA-IPsec ones, the latter to be
handled by the author Mohan.

Signaling IPsec
---------------

> >      2) The PaC learns the IP address of the Enforcement point (EP)
> >         during the PANA exchange.
> >
> >      3) The PaC learns that the network uses IPsec [RFC2401] for
> >         securing the link between the PaC and EP during the PANA
> >         exchange.
> 
> Refer to 4301.  Perhaps it would be worthwhile to indicate how PANA
> protocol signals the use of IPsec.  A quick look at the PANA protocol
> document did not help!

If you search for "IPsec", you'd find the relevant text in the PANA protocol
specification.

8.13.  Protection-Capability AVP

   The Protection-Capability AVP (AVP Code 13) indicates the
   cryptographic data protection capability supported and required by
   the EPs.  The AVP data is of type Unsigned32.  Below is a list of
   valid data values and associated protection capabilities:

      0          L2_PROTECTION
      1          IPSEC_PROTECTION

Global IP address and access authorization
------------------------------------------

> >    The PRPA of the PaC may be a link-local address [IPV4-LINK] or a
> >    private address [RFC1918] or a routable address or an IPv6 link-local
> >    address or global address [RFC2462]. Please refer to [PANA-FRAME] for
> 
> Just curious about PRPA being a global address.  If the PaC already
> has a globally routable address, why would it care to go through
> IKEv2 and access enforcement?  (I don't have a full picture of PANA
> operation, so wondering whether this is ok.  It might be worthwhile
> to elaborate on that in this document, since it is talking about
> access enforcement!)

Having a globally routable IP address does not imply the host is authorized
for unlimited access to the network. Similarly, having a private IP address
does not imply the host is not authorized to access the network either. 

Distributed authenticators
--------------------------

> Note that if the EP and PAA are identified distinctly then they cannot be 
> thought of as a "distributed authenticator".  That in turn implies that 
> EAP keying material is transported outside the boundary of the EAP 
> authenticator.  I believe that this creates an issue with the AAA Key 
> Management guidelines, because now the EP can impersonate the 
> Authenticator.

I don't understand the technical reason behind the very first sentence. 
Can Bernard explain?

> I agree.  In practice, I don't think that the PANA architecture provides 
> the tight consistency required to handle a 3 party re-key.  

Please elaborate what exactly the issue is.

> This could 
> even become a problem in a 2 party scenario where the PANA exchange might 
> itself be secured via IPsec.  In this case, if it is not clear exactly 
> when the new keys are installed, then there might not be an easy way to 
> get back in sync if the PaC and PAA installed incompatible key state.  

> Yep, this would not be inline with the guidance of
> draft-housley-aaa-key-mgmt.

Not clear what the issue is.

EAP re-authentication and rekeying
----------------------------------

In reference to EAP re-authentication:

> The situation is particularly tricky when the PAA and EP exist on separate

> entities.  When the PANA BIND exchange completes between the PaC and PAA, 
> do we really expect the PaC - EP re-key to occur simultaneously?  

No.

> This 
> seems unlikely.  In the period until re-key propagation completes, I am 
> not sure how the PaC or EP know what the key state is.  

You must have noticed the "Key-ID" in the key derivation function
(PANA-IPsec). And you must have also seen the relevant text in the PANA
specification.

> For example, is 
> the PaC/EP supposed to maintain two sets of PSKs?

Yes (like it is done in similar cases elsewhere; e.g.: IEEE 802.16e).

PANA, IPsec, IKEv1, IKEv2
-------------------------

>As far as I can tell, one of the motivations for this document is the 
>need to support EAP authentication with IKEv1.  

PANA does not aim in bringing EAP support to IKEv1. I don't know where
someone can get such an idea from.

> If use of PANA/IPsec 
>were to be restricted to IKEv2, it seems like it would be less useful 
>since IKEv2 already supports EAP authentication.

> One of the principles of RFC 1958 is:
>
>  3.2 If there are several ways of doing the same thing, choose one.

> If there is substantial overlap in the needs addressed by RFC 4306
> (IKEv2/EAP) and PANA/IPsec, then I'm not clear why we would need both of 
> them.

It was clarified in IETF ML e-mails that one cannot substitute for the
other.

Session identification
----------------------

> Probably the PANA session ID!

> I'm not sure why two session identifiers are necessary to identify the 
> same exchange.  The EAP Session-Id uniquely identifies the EAP 
> conversation, and since PANA is an EAP transport, it would seem that it 
> would also uniquely represent the PANA conversation too.  Having two 
> Session-Ids to uniquely identify a conversation seems like it could result

> in confusion, particularly if both Session-Ids were sent to an 
> authenticator.  It seems like this could result in multiple names for the 
> same keys.

Think of the EAP re-authentications that take place within a single PANA
session. Then you'd see the relation between the EAP sessions and PANA
sessions. 

I don't see where the confusion can arise from. Keys derived and used by
PANA only rely on PANA session identifier and Key-id. 

Last hop vs. end-to-end security
--------------------------------

> * Specifically, is the purpose to provide *secrecy* for the communication 
> between the endpoint (PaC) and the access router (AR), or only 
> authenticity?

If we are only talking about "access control", "authenticity" is what we
need. This is what network access authentication protocols are for. One of
the by-products of such protocols is the keying material that can enable
"secrecy". And secrecy is very desirable in a lot of deployments.

> It is not clear to me why one would want to provide secrecy at this level.
> Presumably, if the PaC wants to keep its communication secret it would do
> end-to-end encryption with whomever it is interacting, which is unlikely 
> to be the AR. So I assume it is only authenticity. (In either case, this 
> point should probably be discussed in the security considerations
> section.)

I guess this is a classic end2end vs hop-by-hop security discussion. Without
getting into a full-fledge discussion, let me just note that, the current
trend in access network architectures is to minimally ensure the hop-by-hop
security model.

Regards,

Alper

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