Subject: RE: [AAA-WG]: use of EAP over IKEv2

From: "David Mariblanca (ML/EEM)" <[email-masked]>
Date: Tue, 6 Apr 2004 12:46:17 +0200

Hi,
at the moment the only need we seem to have is to be able to send the indication of "IKEv2" as service type or something similar. Is it worth to write a paper around that ? Should it be more simple to add one more value to the Service Type AVP ?

David.

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]]
Sent: martes, 06 de abril de 2004 12:37
To: [email-masked]
Cc: David Mariblanca (ML/EEM); [email-masked]
Subject: Re: [AAA-WG]: use of EAP over IKEv2

[email-masked] wrote:

> I think that in most cases the EAP server does not 
> actually have to know anything about IKEv2. EAP methods 
> generate a Master Session Key (MSK) that is sent to 
> the IKEv2 gateway, and then used to generate the AUTH 

Agreed.

> payloads. The situation is a bit different if the EAP 
> method has "channel bindings", but none of the currently
> used methods has them.

(There are beginnings of channel binding support in some
methods, but I'm not aware of those features being used yet.)

In any case, even if you do channel bindings the MSK stays
the same. Its just that the authentication server wants in
addition some verification of the claimed service types.

In EAP WG, we have in the past discussed about the possibility
of including the service type and parameters, such as the
SSID, in the key generation when we go from the MSK to the
AAA key. However, it seems that we have a consensus that
it would not be a good approach, primarily due to getting
different key generation formula everytime someone invents
new parameters that have to be protected. The channel
binding approach avoids this problem.

> However, I agree that an AVP for specifying IKEv2 service
> could be still useful... or even better, a "IKEv2 RADIUS/
> Diameter usage guidelines" document (like RFC3580 is 
> for 802.1X). And no, I'm not volunteering to write that :-) 
> Maybe people involved with VPN products might be interested,
> especially considering that many existing VPN gateways
> already support RADIUS?

Hmm... here's a question: assuming there would be someone
who would be willing to do this, where could the work take
place? A couple of observations: IPsec and AAA WGs are closing
down and RADEXT has a pretty full charter already.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 06 Apr 2004 14:13:20 +0300

> at the moment the only need we seem to have is to be able to send the indication of "IKEv2" as service type or something similar. Is it worth to write a paper around that ? Should it be more simple…

I'm reading the RFCs and drafts some more... by setting the
Tunnel-Type AVP to value 9 (ESP) you could indicate that
the authentication request relates to an IPsec gateway.
So it appears that you can after all indicate what service
is really being offered. That still leaves an open question
on what you should put to the Framed-Protocol AVP. I don't
know!

If the above is not sufficient, a new AVP value may be
needed. RFC 3575 tells the allocation policies,
which differ based on what you intend to do.
Designed Expert procedure is needed for most
attribute value allocations. For Service-Type
RFCs, you need IETF Consensus i.e. the publication
of a standards track RFC. But in your case I
believe the right thing would be to add a new
value to Framed-Protocol.

Hannes wrote:

> would this be a huge effort to define an avp which indicates which protocol
> was used to carry the eap payloads?

Not necessarily. We just have to choose between the
following approaches:

#1 current AVP values are sufficient (maybe, maybe not...)
#2 need one additional value (just get a Designed Expert to agree)
#3 need one additional AVP (small RFC)
#4 a complete explanation of the usage for a particular "link layer"
    (bigger RFC)

If you end up doing #4 this can take some time, the
RFC 3580 example is 30 pages.

--Jari

P.S. Pasi and I could probably handle approach #2 or #3 within
draft-arkko-eap-generic-si-00.txt if people feel that would
be easier.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 6 Apr 2004 09:03:00 -0700 (PDT)

> the authentication request relates to an IPsec gateway.

According to RFC 2868, Tunnel-Type can be included in an Access-Request.
NAS-Port-Type could be set to Virtual (5). Tunnel-Type could be set to
IPsec ESP Tunnel Mode (9).  The only thing that is missing is the
key management - IKEv2 vs. IKEv1 with say, XAUTH.

> on what you should put to the Framed-Protocol AVP. I don't know.

Framed-Protocol is optional in an Access-Request and an Access-Accept, and
really refers to data framing, not the framing of the authentication.  So
I'm not clear that this is the right attribute to use.

Personally, I'd suggest a new attribute for Tunnel-Key-Management
I mention this because this is really orthogonal to Tunnel-Type.  You
could have IPsec ESP tunnel mode keyed manually, via IKEv1, IKEv2, etc.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 15 Apr 2004 09:31:48 +0300

> key management - IKEv2 vs. IKEv1 with say, XAUTH.

Hmm... maybe that's not all. What if you run IKEv2
using EAP authentication but create a transport mode
ESP instead of tunnel mode? Of course we could add
a new value for the Tunnel-Type AVP, but it may be
a stretch to use tunnel AVPs for transport mode
IPsec.

(Also, I'm trying to think if there's some case
where the tunnel attributes would be needed for
multiple purposes at the same time. How do we distinguish
the "I support tunnel type X" hint from "This connection
arrived on tunnel type X" in an Access-Request?)

I'm starting to think that we may need a new attribute
for indicating the encapsulation that was used for
the EAP authentication. Say, EAP-Lower-Layer AVP,
with the following values:

   - PPP
   - 802.1X
   - IKEv2
   - PANA

This could be defined in a small new RFC at the same
time for RADIUS & Diameter. What do folks think about
this?

--Jari