Subject: PANA and IKE

From: Alper Yegin <[email-masked]>
Date: Wed, 30 Jul 2003 11:36:59 -0700

Lately there has been several discussions around PANA and IKE in various
contexts. Here is an attempt to put them in perspective, so that people
don't confuse one with the other...

First, let's recap various environments PANA can be used (from the usage
scenarios draft):
[a] over physically secured links (e.g., DSL)
[b] over cryptographically secured links prior to PANA (e.g., CDMA2000)
[c] over links that uses PANA to enable link-layer ciphering (e.g.,
    bootstraping WEP)
[d] over links that have no lower-layer security, hence IPsec-based access
    control is enabled after PANA

IKE needs to be used in conjunction with [d] as the PANA SA needs to be
turned into an IPsec SA. In that case, PANA SA provides pre-shared keys for
IKE. Please see draft-mohanp-pana-ipsec-00.txt for details. No modifications
to IKE is necessary in here. On the other hand, none of the other scenarios
need IKE in the picture.

These are the PANA-IKE discussions we had in the past:

[1] Can PANA use IKE-like messages? (Pasi Eronen, on the PANA ML)

Getting inspired by other protocols is welcome. We are already doing this
with Diameter-like messages. But note that this is a case-by-case decision
for each part of PANA. Various parts of PANA design can get inspired by
other protocols as we see fit.

[2] Why do we have to do what pana-ipsec draft says, can't we run an
independent IKEv2 with EAP after PANA (James Kempf, IETF57 PANA meeting)?

As explained earlier, PANA does not generate IPsec SA (by design) and relies
on another protocol (IKE) to turn PANA SA into IPsec SA. Once PANA is run,
one can bypass EAP with IKE and use pre-shared secrets with IKE to generate
IPsec SA.

Running EAP both in PANA and IKEv2 does not make sense, because
authenticating the client once is enough. Running EAP inside IKEv2 is not
necessary.

[3] How about using IKEv2 instead of PANA for network access authentication?

People seemed to be inspired about this because IKEv2 carries EAP. But that
does not make IKEv2 a network access authentication protocol. If one wants
to turn IKEv2 into such a protocol, he/she needs to add all relevant bells
and whistles (such as discovery, ability to run without an IP address,
enabling L2 ciphers, EAP sequencing, NAP-ISP auth separation, mobility (fast
re-auth), explicit net access termination, etc.). Only after than it can be
useful for scenario [d]. For others, ([a], [b], [c]) IKEv2 would be too
heavy-weight and now people would want to remove stuff from IKEv2. This is
why it does not make sense to replace PANA with IKEv2.

PANA protocol design is such that it fits all necessary scenarios and works
in conjunction with other existing protocols (IPsec, IKE) when needed.

Comments?

Alper