Subject: EAPoIP: The final piece of the puzzle

From: Paal Engelstad <[email-masked]>
Date: Sun, 6 Jan 2002 12:43:10 +0100

Hi, anyone that might take a look at the EAPoIP draft.

http://search.ietf.org/internet-drafts/draft-engelstad-pana-eap-over-ip-00.txt) 

Here is some information that might save you some time:

1) The design: 

My goal was to analyze how EAP can be merged with IPSec, using IKE as the glue, and to avoid creating new protocols or making changes to existing ones. Of course, EAP must naturally run over some IP transport protocol (UDP, TCP, SCTP, whatever) instead of PPP. Moreover, I accepted that the discovery mechanisms might lead to some extensions/options. So, in terms of the framework in the draft, the goal is to make the Pre-IKE part of EAPoIP as minimal as possible, hopefully making it unnecessary.

2) The final piece of the puzzle?

I believe I have found the final piece of the puzzle to get EAPoIP interact with back-end protocols (e.g. DIAMETER, RADIUS, etc.), making it a completed scheme that almost only rests on existing IKE, IPSec and traditional EAP. I have not yet had time to analyze the nitty-gritty details of IKE to verify the correctness of my proposal. But since it might ease your understanding of the draft, and thereby save you time, I will try to give you an idea. My current version goes something like this:

<<"Requirement 1) The back-end protocol MUST convey the phase 1 IKE-messages 1-6 verbatim from PAA to CAA (i.e. the AAAh). Note that these are the IKE-messages from the session between the PAA and the Client! Some IKE D-H-dependent keys might also be included (?) This communication MUST be protected by strong security mechanism (-preferably IPSec).

Requirement 2) The CAA, in the other end of the back-end protocol, MUST be able to operate as follows:

a) Upon reception of IKE Message 5, PAA generates IKE Message 6, and IKE-authenticates it based on the public key of (or shared secret with) the CAA. Messages 1-6 are sent over to CAA. CAA MUST be able to verifiy the correctness of PAAs authentication, using the private key or the secret shared with PAA.

b) If this was correct, CAA MUST verify the correctness of the roaming host's IKE-authentication in message 5, based on the private key of (or shared secret with) the Client (which naturally used CAAs public key or their shared secret to IKE-authenticate message 5.)

c) If this also was correct, CAA generates IKE-message 6, based on IKE-message 1-5, however using the clients public key (or the secret shared between CAA and the client).

d) CAA returns to PAA (over the security-protected back-end protocol) the new message 6. PAA therefore knows that the client authenticated the IKE-session correctly, and forwards the new IKE-message 6 back to the client. The client receives a correctly IKE-authenicated message 6 >>...

...Everyone is happy, and the scheme is complete.... 

Using IKE with secret keys are not the best solution for roaming hosts, because the current version of IKE unfortunately requires a binding between the IP-address and the pre-shared secret prior to the IKE session. Some Pre-IKE EAPoIP could be used to convey such a binding. However, I think that using public keys or signature keys makes more sense. Note that as long as the CAA is hard-coded with the public keys of both PAA and the Client (as part of the roaming agreement/SLA and the subscription, respectively), or is able to verify signature keys of both, no PKI is required.

3) I also think the EAPoIP scheme easily can be extended to handle:

a) authentication of nodes without an IP address

b) let hosts that roams within an access domain be allowed to change IP-addresses not having to modify the security association with the PAA (by means of tunneling). Alternatively, SA might be modified by IPSec/IKE re-negotiation) 

c) Allow PAA and CAA to alternatively convey the IKE-verification message over a separate instance of EAPoIP (if Radius or Diameter is not in place) and by just defining a new Post-IKE Intitial Request/Response Type.

I plan to start working on a second version of the draft after I return from vacation (and to the list) in a weeks time. The second version will address some of the issues above. Meanwhile, critical remarks and notifications of flaws are always welcome;-)

Thanks for your time and attention,
Paal

---

From: "James Kempf" <[email-masked]>
Date: Mon, 7 Jan 2002 14:30:20 -0800

Paal,

I had heard there was an EAP over IP draft somewhere else in IETF. Is
your draft that one?

            jak

----- Original Message -----
From: "Paal Engelstad" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, January 06, 2002 3:43 AM
Subject: EAPoIP: The final piece of the puzzle

> Hi, anyone that might take a look at the EAPoIP draft.
http://search.ietf.org/internet-drafts/draft-engelstad-pana-eap-over-ip-
00.txt)
> My goal was to analyze how EAP can be merged with IPSec, using IKE as
the glue, and to avoid creating new protocols or making changes to
existing ones. Of course, EAP must naturally run over some IP transport
protocol (UDP, TCP, SCTP, whatever) instead of PPP. Moreover, I accepted
that the discovery mechanisms might lead to some extensions/options. So,
in terms of the framework in the draft, the goal is to make the Pre-IKE
part of EAPoIP as minimal as possible, hopefully making it unnecessary.
> I believe I have found the final piece of the puzzle to get EAPoIP
interact with back-end protocols (e.g. DIAMETER, RADIUS, etc.), making
it a completed scheme that almost only rests on existing IKE, IPSec and
traditional EAP. I have not yet had time to analyze the nitty-gritty
details of IKE to verify the correctness of my proposal. But since it
might ease your understanding of the draft, and thereby save you time, I
will try to give you an idea. My current version goes something like
this:
>
> <<"Requirement 1) The back-end protocol MUST convey the phase 1
IKE-messages 1-6 verbatim from PAA to CAA (i.e. the AAAh). Note that
these are the IKE-messages from the session between the PAA and the
Client! Some IKE D-H-dependent keys might also be included (?) This
communication MUST be protected by strong security mechanism
(-preferably IPSec).
> a) Upon reception of IKE Message 5, PAA generates IKE Message 6, and
IKE-authenticates it based on the public key of (or shared secret with)
the CAA. Messages 1-6 are sent over to CAA. CAA MUST be able to verifiy
the correctness of PAAs authentication, using the private key or the
secret shared with PAA.
>
> b) If this was correct, CAA MUST verify the correctness of the roaming
host's IKE-authentication in message 5, based on the private key of (or
shared secret with) the Client (which naturally used CAAs public key or
their shared secret to IKE-authenticate message 5.)
>
> c) If this also was correct, CAA generates IKE-message 6, based on
IKE-message 1-5, however using the clients public key (or the secret
shared between CAA and the client).
>
> d) CAA returns to PAA (over the security-protected back-end protocol)
the new message 6. PAA therefore knows that the client authenticated the
IKE-session correctly, and forwards the new IKE-message 6 back to the
client. The client receives a correctly IKE-authenicated message 6 >>...
> Using IKE with secret keys are not the best solution for roaming
hosts, because the current version of IKE unfortunately requires a
binding between the IP-address and the pre-shared secret prior to the
IKE session. Some Pre-IKE EAPoIP could be used to convey such a binding.
However, I think that using public keys or signature keys makes more
sense. Note that as long as the CAA is hard-coded with the public keys
of both PAA and the Client (as part of the roaming agreement/SLA and the
subscription, respectively), or is able to verify signature keys of
both, no PKI is required.
> b) let hosts that roams within an access domain be allowed to change
IP-addresses not having to modify the security association with the PAA
(by means of tunneling). Alternatively, SA might be modified by
IPSec/IKE re-negotiation)
>
> c) Allow PAA and CAA to alternatively convey the IKE-verification
message over a separate instance of EAPoIP (if Radius or Diameter is not
in place) and by just defining a new Post-IKE Intitial Request/Response
Type.
>
> I plan to start working on a second version of the draft after I
return from vacation (and to the list) in a weeks time. The second
version will address some of the issues above. Meanwhile, critical
remarks and notifications of flaws are always welcome;-)