Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or not Issue ?

From: "Julien Bournelle" <[email-masked]>
Date: Sat, 20 Jan 2007 13:10:21 +0100

Hi Ahmad,

 let me answer to your comments

On 1/19/07, Ahmad Muhanna <[email-masked]> wrote:
>
> > First of all, I think that such an attack isn't caused
> > by decoupling of AAAn and AAAz. It is caused by the
> > rogue HA flooding a AAA server.
> >
> > Second, I do not think how the AAAz would be protected
> > from a flooding attack launched by a rogue HA if it
> > had a "proof of authentication at AAAn [...] provided
> > by either MN or AAAn". AFAIK authentication does not
> > protect from flooding.
>
> [Ahmad]
> If the proposed solution requires the HA to provide authentication
> material to AAAz to ensure that MN has been authenticated, the AAAz will
> have the chance to drop these Authorization Requests if authentication
> material is not authentic, which I assume it is not in this scenario.

 i'm not sure to well understand your comment. Which "proposed solution" ?
 Moreover, I would say that this not the role of the AAAz to perform a kind of
 authentication. The HA needs to know if the user is the person she
claimed to be:
 it uses the AAAn for this. Then, it needs to know if the user is
authorized: it uses
the AAAz for this. If we want the AAAz to know if the user is authenticated, we
 shouldn't decoupled the 2 process.

> Also, if AAAz receives too many of these Requests from the same HA, AAAz
> can close the connection to the HA or just ignore all of its traffic.

 right
>
> Theoretically, I agree with Madjid that there is an issue that needs to
> be addressed.

 I'm still not convinced.

> On the other hand, we need to assess the possibility for
> this security vulnerability to happen in the field and make an educated
> decision to address it or not. One more thing, we can recognize the
> issue
> and provide an optional solution that any deployment which does
> not guarantee that HA wont be comprised Shall implement the proposed
> solution. Just an idea.

that's indeed the question: do we introduce a threat here ? or in other terms do
 we have an issue here ?

 I think no. Madjid and you think "yes".

 We clearly need a way to move forward but I don't think we (as a WG)
 can say: if you think there is an issue then use this optional mechanism,
 if you don't think it is an issue then you don't need this optional mechanism.

 We must know if it is an issue or not.

 regards,

 --Julien (B.)

>
>
> >
> > > As far as you other statements:
> > > "At the HA, there is assurance that the peer is
> > > authenticated since it just checked if it was. "
> > >
> > > I don't think assurance at HA is relevant for AAAz,
> > > since HA was not involved in EAP.
> >
> > But HA is involved in the EAP exchange! It acts as a
> > passtrough, and gets authentication assurance from
> > AAAn.
> >
> > > "If the two were coupled, still the
> > > HA would be able to launch a DoS on the AAA server
> > > and bombard it with authentication and authorization
> > > requests."
> > >
> > > If the authentication failed, then there would be no
> > > authorization.
> >
> > AFAICS the mechanism you want to provide protect from a
> > rogue HA. If the HA is rogue it can ask for
> > authorization request when it wants. It doesn't need
> > authentication to succeed for that.
> >
> > > "The AAA server isn't really in control of who gets
> > > the mobility server and who doesn't since at the end
> > > this is up to the HA to provide the service or not."
> > >
> > > AAA server is the authority that authorizes the
> > > resource, it does not police the resource usage,
> > > since it is not on the path, but we are talking
> > > about authorization not policing.
> > >
> > > You can feel free to stop the conversation if you
> > > want. The solution to the problem is pretty simple,
> > > the MN simply signs the trigger for the service
> > > request. So instead of getting you frustrated, I
> > > will just work to see if I can get the draft out.
> >
> > The solution to this discussion is pretty simple too:
> > What is the problem? :)
> >
> > --julien
> >
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime
>

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 22 Jan 2007 11:10:39 -0600

Hi Julien,
Please see my comments inline.

Regards,
Ahmad

> -----Original Message-----
> From: Julien Bournelle [mailto:[email-masked]] 
> Sent: Saturday, January 20, 2007 6:10 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Julien Laganier; [email-masked]
> Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: 
> Issue or not Issue ?
> 
> Hi Ahmad,
> 
> > > First of all, I think that such an attack isn't caused by 
> decoupling 
> > > of AAAn and AAAz. It is caused by the rogue HA flooding a AAA 
> > > server.
> > >
> > > Second, I do not think how the AAAz would be protected from a 
> > > flooding attack launched by a rogue HA if it had a "proof of 
> > > authentication at AAAn [...] provided by either MN or 
> AAAn". AFAIK 
> > > authentication does not protect from flooding.
> >
> > [Ahmad]
> > material to AAAz to ensure that MN has been authenticated, the AAAz 
> > will have the chance to drop these Authorization Requests if 
> > authentication material is not authentic, which I assume it 
> is not in this scenario.
> 

[Ahmad]
So far there is no proposed solution, but I think at one point long time
back and probably on this thread there was a discussion which briefly
mentioned from High Level that the HA needs to provide AAAz a
token/something to prove that this user has been
authenticated/Authentic.

>  Moreover, I would say that this not the role of the AAAz to 
> perform a kind of  authentication. 

[Ahmad]
To some extent I agree. However, AAAz does not need to authenticate the
user rather it needs to be offered an assurance that this user has been
authentication. I think this is a side effect of decoupling the
Authentication and Authorization processes.

> The HA needs to know if 
> the user is the person she claimed to be: it uses the AAAn for this.
Then, it needs to know if the user is
> authorized: it uses
> the AAAz for this. If we want the AAAz to know if the user is 
> authenticated, we  shouldn't decoupled the 2 process.

[Ahmad]
We are probably splitting hair here, apparently there are two arguments
here:

1. AAAz is an authorization server and since it has a security
relationship with the HA, AAAz relies on the HA to do two things: 
1.1. HA makes sure that the user has been authenticated by AAAn. 
1.2. HA will not send any Authorization requests for any user(s) who has
not been authenticated.

(In normal conditions, the above two conditions are ALWAYS TRUE except
in one condition, HA has been compromised) 

2. AAAz is an authorization server and has a security association with
the HA, however, due to the fact that the HA could be compromised, a
process needs to be in place for the HA to ALWAYS provide the AAAz,
Authorization server, with a proof (token, etc.) that the user has been
authenticated by AAAn.

I assume here that the difference in opinion is about the possibility of
the HA to be compromised or NOT. Because due to the decoupling of
Authentication and Authorization processes and using different
application IDs, I clearly see an issue when HA is compromised which
does not exist if Authorization and Authentication are not decoupled.

I agree with you, we have two options here:

1. If Authorization and Authentication processes are NOT decoupled, then
this issue goes away.

2. In the case of decoupling Authorization and Authentication, we
clearly need to highlight the new security risk/vulnerability introduced
by decoupling and provide a solution. In the case that vulnerability is
not applicable to any deployment, then that solution becomes an
optional/not-needed one. (I am not sure what is the problem with this
approach.)

> 
> > Also, if AAAz receives too many of these Requests from the same HA, 
> > AAAz can close the connection to the HA or just ignore all of its
traffic.
>  right

[Ahmad]
Thanks Julien. It seems you agree that AAAz can do this to avoid this
attack by a compromised HA; then I assume that you agree decoupling the
Authentication and Authorization processes introduces a security
vulnerability/risk in the case when HA is compromised which does not
exist if both Authentication and Authorization processes are not
decoupled. Right?

> >
> > Theoretically, I agree with Madjid that there is an issue 
> that needs 
> > to be addressed.
> 
>  I'm still not convinced.

[Ahmad]
Please see my comments above. I hope it helps in clarifying the issue.

> this security 
> > vulnerability to happen in the field and make an educated 
> decision to 
> > address it or not. One more thing, we can recognize the issue and 
> > provide an optional solution that any deployment which does not 
> > guarantee that HA wont be comprised Shall implement the proposed 
> > solution. Just an idea.
> 
> that's indeed the question: do we introduce a threat here ? 
> or in other terms do  we have an issue here ?
> 
>  We clearly need a way to move forward but I don't think we 
> (as a WG)  can say: if you think there is an issue then use 
> this optional mechanism,  if you don't think it is an issue 
> then you don't need this optional mechanism.
> 
> > > > "At the HA, there is assurance that the peer is authenticated 
> > > > since it just checked if it was. "
> > > >
> passtrough, and 
> > > gets authentication assurance from AAAn.
> > >
> > > > "If the two were coupled, still the HA would be able to 
> launch a 
> > > > DoS on the AAA server and bombard it with authentication and 
> > > > authorization requests."
> > > >
> rogue HA. If 
> > > the HA is rogue it can ask for authorization request when 
> it wants. 
> > > It doesn't need authentication to succeed for that.
> > >
> > > > "The AAA server isn't really in control of who gets the 
> mobility 
> > > > server and who doesn't since at the end this is up to the HA to 
> > > > provide the service or not."
> > > >
> resource, it does 
> > > > not police the resource usage, since it is not on the 
> path, but we 
> > > > are talking about authorization not policing.
> > > >
> > > > You can feel free to stop the conversation if you want. The 
> > > > solution to the problem is pretty simple, the MN simply 
> signs the 
> > > > trigger for the service request. So instead of getting you 
> > > > frustrated, I will just work to see if I can get the draft out.
> > >

---

From: Julien Laganier <[email-masked]>
Date: Tue, 23 Jan 2007 10:41:58 +0100

Hi Ahmad,

Cutting a bit thru your message, I have some comments 
below:

On Monday 22 January 2007 18:10, Ahmad Muhanna wrote:
>
>
>[...]
>
> [Ahmad]
> We are probably splitting hair here, apparently
> there are two arguments here:

I don't think this is hair splitting. Understand the 
issue should be a prerequisite to solving it.

> 1. AAAz is an authorization server and since it has
> a security relationship with the HA, AAAz relies on
> the HA to do two things: 1.1. HA makes sure that the
> user has been authenticated by AAAn. 1.2. HA will
> not send any Authorization requests for any user(s)
> who has not been authenticated.
>
> (In normal conditions, the above two conditions are
> ALWAYS TRUE except in one condition, HA has been
> compromised)

Right. So we both agree there's no problem unless the 
HA is compromised

I think what the first step is to agree on a threat 
model. I do not agree that we should defend against a 
compromised HA. The HA should be deemed secure against 
attackers.

We have to place a limit on what is entity X when 
asking the question "what if entity X is compromised". 
Since nothing is really impossible in the real world, 
we cannot defend against compromission of any entity 
implicated in a protocol. Security is a tradeoff. 

More below...

> 2. AAAz is an authorization server and has a
> security association with the HA, however, due to
> the fact that the HA could be compromised, a process
> needs to be in place for the HA to ALWAYS provide
> the AAAz, Authorization server, with a proof (token,
> etc.) that the user has been authenticated by AAAn.

OK, if HA can be compromised. But why are we stopping 
here? Why not considering the case where the AAAn is 
compromised? Is is it more likely for an HA to be 
compromised than for a AAAn?

We really have to agree on a threat model first.

> I assume here that the difference in opinion is
> about the possibility of the HA to be compromised or
> NOT. 

Exactly.

Best,

--julien (L.)

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 24 Jan 2007 13:13:01 -0600

Hi Julien,
Please see response inline.

Regards,
Ahmad

> From: julien laganier [mailto:[email-masked]] On 
> Behalf Of Julien Laganier
> Sent: Tuesday, January 23, 2007 3:42 AM
> Cc: Julien Bournelle; [email-masked]
> > We are probably splitting hair here, apparently there are two 
> > arguments here:
> 
> I don't think this is hair splitting. Understand the issue 
> should be a prerequisite to solving it.

[Ahmad]
OK.

> > relationship with the HA, AAAz relies on the HA to do two 
> things: 1.1. 
> > HA makes sure that the user has been authenticated by AAAn. 1.2. HA 
> > will not send any Authorization requests for any user(s) 
> who has not 
> > been authenticated.
> >
> Right. So we both agree there's no problem unless the HA is 
> compromised

[Ahmad]
Agree.
> 
> I think what the first step is to agree on a threat model. I 
> do not agree that we should defend against a compromised HA. 
> The HA should be deemed secure against attackers.
> 
> We have to place a limit on what is entity X when asking the 
> question "what if entity X is compromised". 
> Since nothing is really impossible in the real world, we 
> cannot defend against compromission of any entity implicated 
> in a protocol. Security is a tradeoff. 

[Ahmad]
I agree. 
However, we need to capture this somewhere in the draft and if people
are ok to live with the limitation without offering a solution to
address it, hay. I am fine too.

> > Authorization server, with a proof (token,
> OK, if HA can be compromised. But why are we stopping here? 
> Why not considering the case where the AAAn is compromised? 
> Is is it more likely for an HA to be compromised than for a AAAn?

[Ahmad]
I am not sure this will help resolving the issue. However, in my
opinion, AAAn only respond to requests by nature and yes; I believe it
is more secure than the HA for the simple fact that ONLY very specific
traffic is allowed to the AAA server anyway. Right?

> > I assume here that the difference in opinion is about the 
> possibility 
> > of the HA to be compromised or NOT.
> 
> Exactly.
> 
> Best,
> 
> --julien (L.)
>

---

From: "Julien Bournelle" <[email-masked]>
Date: Fri, 26 Jan 2007 18:38:07 +0100

Hi Ahmad,

 sorry for the delay. some answers below

On 1/22/07, Ahmad Muhanna <[email-masked]> wrote:
<cut>

> token/something to prove that this user has been

 ok.

> Authorization server, with a proof (token, etc.) that the user has been

 I have one question here: if the HA is compromised, why do it
 will contact the AAAz ?

> the HA to be compromised or NOT.

 the HA may be compromised.

> Because due to the decoupling of
> by decoupling

 yes.

> and provide a solution.

 if we all agree, I guess the simpler solution may be to re-couple AAAn and
 AAAz.

> In the case that vulnerability is
> attack by a compromised HA;

 I was saying "right" because the AAAz may have an internal mechanism
 to protect himself against DoS from a HA.

>then I assume that you agree decoupling the

 I'm still not convinced, a compromised HA may also perform a DoS
 on a AAA coupling authn and authz.

 To be honest, I don't have strong opinion on this subject. I think
 that both sides seem to have valid arguments.

 However, if we
 think that the AAAz should have a way to get an assurance that
 the user has been authenticated, I would prefer to have a unique
 application to do so. In this case, I'm wondering if we could design
 an application that would support different kind of authentication
 (EAP, RFC4285, others ?). But, I saw that in the past, NASREQ and
 EAP application were coupled and have been split. It could be interesting
 to know the reason.

 My 2 cents,

 Julien