RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split

[Madjid Nakhjiri <mnakhjiri at huawei.com>]

Hi Julien,

-----Original Message-----
From: Julien Bournelle [mailto:julien.bournelle at gmail.com] 
Sent: Tuesday, December 05, 2006 1:34 AM
To: Madjid Nakhjiri
Cc: Ahmad Muhanna; dime at ietf.org
Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split

Hi madjid,

 sorry for the late response

On 11/30/06, Madjid Nakhjiri <mnakhjiri at huawei.com> wrote:
> Actually Julien, let me explain, The issue is that since you are
decoupling
> the authentication from authorization, during the authorization you have
no
> assurance that the client identity has actually been authenticated.

 One question is: is this really an issue ?

Madjid>>yes, see below.

> Things
> that cause problem are when the AAA-MIP is different from AAA_EAP,

 Is this really a problem if the authorization server trust the HA ?

Madjid>>well, define trust? Just because HA as a AAA client shares a key
with the AAA_MIP, it does not mean it cannot lie to the AAA_MIP.
The AAA_EAP may authenticate somebody, while HA tries to get authorization
for somebody else! So basically the HA can help the MN steal service. 

> 3) HA is under attack itself, where its databases are manipulated.
>
> Now back to your options, I don't think you can sweep this under the rug.
> This is probably the first place in the IETF where you are separating
> authentication from authorization, so you will get a lot of scrutiny down
> the road and you cannot ignore the security issues for the scenario you
are
> presenting (especially the separation of the AAA servers and service
> providers). So option 1 is out. I think we should take the issue
seriously.

 that's true that we are introducing a new scheme: we're decoupling
the authorization from the authentication process. However, the HA is
responsible of the binding.

Madjid>> the decoupling if not done right can cause security issues.

 And yes I'm wondering if this is really a security issue.

Madjid>>I gave you an example above.

>
> However, I don't think the solution you present in option 2 is needed. You
> don't need new command modes, you simply need attributes that carry
> information related to a previous authentication of the MN by the AAA-EAP
> and this can be done by attributes.

 I'm not sure that "simply" is adequate here...if we need to add
attributes to 4072 and define a token-based mechanism that would give
a proof to the AAA-MIP6, i'm not sure that so simple.


Madjid>>Ok, sorry for the exaggeration on simplicity, but it does solve the
security problem.


 Julien





_______________________________________________
DiME mailing list
DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime