Subject: [AAA-WG]: diameter-eap some minor comments

From: Julien Bournelle <[email-masked]>
Date: Fri, 12 Dec 2003 15:59:30 +0100

Hi,
 
 I've just read the diameter-eap draft and I have some minor comments:

-1- in §2.2 s/respons/respond

-2- In the second scenario described in §2.2, the NAS sends the DER
message directly to the home server. Why do not send it to its local
Diameter Server ?

-3- In the same paragraph, it is said that the DEA may include an
EAP-MSK-Key AVP that contains keying material for protecting the
communication between the user and the NAS. In the roaming scenario, it
would be the home server which will provide this key. So what happen if
the NAS do not want to use this key ?

-4- In §2.8.1, I just wanted to note that we are going to face problem
if we use an EAP method with identity protection in roaming
scenario.(NAS won't be able to route Request)

that's all,

thanks, 

-- 
[email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Sat, 13 Dec 2003 11:00:14 +0200

>  I've just read the diameter-eap draft and I have some minor comments:

Thanks!

> message directly to the home server. Why do not send it to its local

Section 2.2 does not discuss the possibility of local proxies yet.
This is handled in Section 2.3, which has a number of different
scenarios, including scenario 2 where redirects are used to
run the EAP AAA end-to-end between the NAS and the home server, and
scenario 4 which is the typical RADIUS-like proxy model.

> the NAS do not want to use this key ?

This is ultimately a link-layer dependent issue. Home servers would typically
provide the keying material, but depending on the link layer in question,
the NAS would use the keying material in different ways. Presumably
there can be cases where the keying material is not used at all. I would
say in this case the NAS simply throws the AVP away.

Do you see an issue here?

> scenario.(NAS won't be able to route Request)

Yes. Note that if only the user name part, not the domain, is hidden,
then there is no issue. Some EAP methods use this kind of identity
protection. This is discussed in RFC 2284bis.

If one wants even domain identity protection over the wireless,
then there has to be (a) some sort of a tunnel EAP method -- with
implied consequences -- that is terminated at the NAS or (b) some
new link layers that could protect even the initial stages of
EAP negotiation. But you can't have domain identity protection from
the NAS, otherwise roaming doesn't work. You could perhaps use
<encrypted_NAI>@anonymizer.com, but even then you would reveal your
domain to someone else than your home network. Also, link-layer
and tunnel-based identity protection mechanisms would likely be just
authenticate the NAS/AP end with a certificate but not the client end.
Such schemes would then still be vulnerable to identity protection
attacks from insiders, e.g., everyone who has a cert from the trusted
CA could trick you to reveal your identity.

Some of these issues should probably go into 2.8.1. I looked at
RFC 3579 too, but it did not say much about the issue. Perhaps
a reference to RFC2284bis Section 7.3 would be sufficient.

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 13 Dec 2003 06:25:25 -0800 (PST)

> Do you see an issue here?

I would say there are two orthogonal issues:  how the key is delivered,
and whether the AAA server is requesting that security services be
provided.  The keying AVPs only address the first issue;  if security is
required, this needs to be encoded separately (as it is in the RFC 2548
attrbutes).

For example, the key could be provided, and the AAA server could be
indifferent to whether it is used or not.  Or it could *require* that it
be used.  The difference between these two cases is particularly important
in fast handoff or context transfer, where you don't necessarily want a
host to move from an access point that supports security to one that does
not.

> implied consequences

Not necessarily.  Identity protection can be provided within a method
without allowing any arbitrary EAP method to be executed inside of it.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 16 Dec 2003 00:04:50 +0200

> host to move from an access point that supports security to one that does

Agreed.

> without allowing any arbitrary EAP method to be executed inside of it.

I think you mean that the username part can be hidden by methods.

I'm not sure the domain name part can be hidden by methods, unless
the method does tunneling of some sort. We have the following
constraints:

   o  To get to the right home server, we need the domain
   o  The domain can not be exposed on the wireless interface

So lets assume its an EAP method that provides the domain identity
protection. Since the domain is hidden over wireless, and needs to
be known for AAA routing, there has to be a node that does the
translation. Assuming that the selection of the EAP method is
transparent to everyone else except the client and the home
server, it does not seem possible to terminate a domain-hiding
EAP method at some intermediate node -- unless that method did
some sort of general tunneling where the terminated part did
not know what was going on inside.

But I could be missing something.

--Jari

---

From: Julien Bournelle <[email-masked]>
Date: Tue, 16 Dec 2003 12:31:28 +0100

Hi,

> scenario 4 which is the typical RADIUS-like proxy model.

that's right but in Diameter-Mobile-IPv4, the FA (<=> NAS) sends
requests to its local Diameter Server (AAAF). Here, the NAS can send
requests to:
- redirect agent
- proxy agent
- to the home server 

so it appears that there is a different approach between the two drafts.

> Do you see an issue here?

The home server may "think" that it exists a "protection" between its
client and the local NAS but I'm not sure that is an issue. 

> protection. This is discussed in RFC 2284bis.

ok I didn't know (thanks)
-- 
[email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Tue, 16 Dec 2003 13:36:15 +0200

> so it appears that there is a different approach between the two drafts.

Perhaps -- though from the point of view of protocols, the NAS will
be sending a message to the local diameter entity. Its then up to
that entity whether it responds with a redirect, proxies the request,
or handles it by itself. Do you see an issue here?

> client and the local NAS but I'm not sure that is an issue. 

Based on what Bernard said, this may be an issue if there is an expectation
that security is provided where it is really not. It is not certain, however,
that this is a specific issue for Diameter EAP -- it seems that the same
problem appears for most of the authorization AVPs. Maybe 'M' bit would
help.

--Jari

---

From: Julien Bournelle <[email-masked]>
Date: Wed, 17 Dec 2003 10:38:17 +0100

Hi,

> or handles it by itself. Do you see an issue here?

I guess there's no issue but I try to understand why there are two
approach to a problem quite similar.