Subject: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 01 Jan 2007 17:22:27 +0100

Hi all,

it seems that we came across a security issue that requires more 
thoughts. Interestingly, David Nelson gave a presentation at the IETF#66 
meeting that dealt with a similar problem when RADIUS is used in the 
ISMS context. You can find his presentation here:
http://www3.ietf.org/proceedings/06jul/slides/radext-7/sld1.htm

We need to investigate the potential security threats in more detail 
before we immediately jump to the solution space.
Who has time and would be interested to brainstorm about this subject a 
little bit?
The goal is to have a more detailed description of the security threats.

Ciao
Hannes

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

---

From: "Julien Bournelle" <[email-masked]>
Date: Mon, 8 Jan 2007 11:59:01 +0100

hi hannes, all

 ok, so let's try to investigate this.

 In our current document, we have the following architecture:

 MN <--- IKEv2 -----> HA <------> AAA_EAP
                               ^
                               |
                              +------------> AAA_MIP6

 HA authenticates the MN by using 4072 in AUTHENTICATE_ONLY mode
 (if EAP used within IKEv2) and we have defined 2 new messages for
Authorization purposes at AAA_MIP6.
 HA uses identiy provided by MN in IDii field of the 3rd IKEv2 message to route
 messages to the corresponding realm.Thus, in the picture above, we
consider that AAA_EAP and AAA_MIP6 are in the same realm.
 Howver, as we have a different App-Id, AAA_EAP and AAA_MIP6 may be located in
 different servers. Note that this is not a requirement, that's possible.

 Advantages are modularity and flexibility. This approach may also be
used by other
 applications that use EAP for authentication. However, we do not require
 use of EAP.

 The problem that we have with this approach is to investigate if it
creates a security
 hole to separate Authentication and Authorization.

 As it has been mentionned in the ML, the HA may be compromised.

 So, the first thing I think we should do is to catch and to agree on the goals
 of such an attack. I can see:

 a/ DoS on the Mobile IPv6 service (shutdown) with loss of revenues
for an operator

 b/ Steal the service

     1. The attacker compromises the HA to obtain free mip6 service for himself

     2. The attacker compromises the HA for a group of people to
     obtain free mip6 service

     3. The attacker compromises the HA for all to obtain free mip6 service.

c/ Identity spoofing to charge someone else

 others ?

 Julien

---

From: "La Monaca Michele" <[email-masked]>
Date: Mon, 8 Jan 2007 19:26:57 +0100

Hi Julien, 

as you said the separation between auth and autz takes along modularity
and flexibility but it raises security concerns if the HA is
compromised. Therefore, I think that it would be better to compare what
a compromised HA can/cannot do in the two cases:

"Split" AAA approach 

1) Deny service to regular users (i.e. DoS) YES 
2) Grant service to fake users (i.e. steal the service) YES
3) DoS to the AAA infrastructure YES
4) Identity spoofing to charge someone else YES
5) something else?

"Integrated" AAA approach

1) Deny service to regular users (i.e. DoS) YES
2) Grant service to fake users (i.e. steal the service) YES
3) DoS to the AAA infrastructure YES
4) Identity spoofing to charge someone else YES?
5) something else?

Btw, the separation between auth and autz might improve the overall
security in some circumstances. For example, an attacker may succeed to
tear down the AAA-EAP functionality but not the AAA-MIPv6 one, so
already authenticated users may continue to use the mipv6 service.

My 2 cents,

--Michele

>-----Messaggio originale-----
>Da: Julien Bournelle [mailto:[email-masked]]
>Inviato: Monday, January 08, 2007 11:59 AM
>A: Hannes Tschofenig
>Cc: [email-masked]
>Oggetto: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security
>
>hi hannes, all
>
> HA uses identiy provided by MN in IDii field of the 3rd IKEv2 message
to
>route
> Howver, as we have a different App-Id, AAA_EAP and AAA_MIP6 may be
located
>in
> So, the first thing I think we should do is to catch and to agree on
the
>goals
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

---

From: Preeti Shandilya <[email-masked]>
Date: Tue, 9 Jan 2007 13:56:30 +0530

Hi !

I have a confusion regarding failed AVP description  mentioned in RFC 
3588. It seems that RFC is not clear about the inclusion of AVP in 
Failed-AVP,  if a mandatory AVP is missing from a grouped AVP in a 
received request message. In my opinion, if a mandatory AVP is missing 
from a grouped AVP, AVP code of grouped AVP should be included in the 
failed AVP in the response message rather than the AVP code of the missing 
AVP.

This is something different from the mail chain at 
http://www1.ietf.org/mail-archive/web/dime/current/msg00532.html

Following scenario shall have problem if we include the AVP code of the 
missing AVP in failed AVP rather than grouped AVP code.

There is a request message in which  an AVP is mandatory and is mandatory 
in a gruped AVP also. If in a received request message this AVP is missing 
but present in the gouped AVP and diameter node returns the answer message 
with error code as DIAMETER_MISSING_AVP and include AVP code of missing 
AVP in thr answer message, the node which originated the request shall not 
receive the correct information as to whether message is failed because of 
AVP is missing in the message or is missing in a grouped AVP.

Pl let me know your opinion about this

regards
Preeti

***********************  Aricent- Confidential   ***********************
"DISCLAIMER: This message is proprietary to Aricent  and is intended solely for the use of 
the individual to whom it is addressed. It may contain privileged or confidential information and should not be 
circulated or used for any purpose other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for 
loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: "Julien Bournelle" <[email-masked]>
Date: Wed, 10 Jan 2007 13:28:11 +0100

Hi michele,

> 4) Identity spoofing to charge someone else YES

 The fact is that by separating authentitcation and authorization,
 if HA is compromised, a non-authenticated user can be authorized.

 This threat does not exist if authentication and authorization are binded.

 The question is what are the consequence of this. If Alice compromised
 the HA and asks an authorization for Bob. The problem that has been evoked
 is that Bob could be charged for the Mobile IPv6 service.

 But wouldn't this problem also exist if authentication and
authorization are tied
 and if the HA is compromised ?

 Julien

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 12 Jan 2007 10:33:39 -0800

Hi Julien,

While I appreciate the threat analysis here, the problem is pretty easy to
solve. Unless, we want to leave this vulnerability as something only for the
security consideration, I suggest we add the security measure.

I am working on a draft that shows how you can separate authentication and
authorization while binding the two together. The draft will be submitted
soon (or at least before next IETF deadline). There is one problem remaining
and that is I am wondering about the messaging triggers (see below). If
people like the solution we can use it for the WG draft. It is just hard to
show a solution over ML, sorry.

For now, I say, we can use the EAP method to generate MSK/EMSK and then use
those keys in assurance for previous authentication (Diameter EAP) to the
authorization server for Diameter MIP.
The issue is that based on the threat analysis that you provided, we cannot
trust HA to provide this assurance. It has to come from the peer and/or AAA
server. 
One way would be for the peer to generate the key sign its request with this
key. Without getting into the details right now, the issue would be:
What message would carry this signature from the peer? And this is why I
have been asking the question of what message would trigger the Mobile IP
Authorization (MAR) message and what is the timing of MAR/MAA w.r.t IKEv2.

The problem is that we need to perform all Mobile IP bootstrapping after
MAA, i.e. after the MN is actually authorized for Mobile IP, so if there is
any message (even an IKEv2 message) that carries a Mobile IP parameter, it
has to come  after MAA.

Hope I am making sense,

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:[email-masked]] 
Sent: Monday, January 08, 2007 2:59 AM
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security

hi hannes, all

 HA authenticates the MN by using 4072 in AUTHENTICATE_ONLY mode
 (if EAP used within IKEv2) and we have defined 2 new messages for
Authorization purposes at AAA_MIP6.
 HA uses identiy provided by MN in IDii field of the 3rd IKEv2 message to
route
 messages to the corresponding realm.Thus, in the picture above, we
consider that AAA_EAP and AAA_MIP6 are in the same realm.
 Howver, as we have a different App-Id, AAA_EAP and AAA_MIP6 may be located
in
 different servers. Note that this is not a requirement, that's possible.

 So, the first thing I think we should do is to catch and to agree on the
goals
 of such an attack. I can see:

 b/ Steal the service

     1. The attacker compromises the HA to obtain free mip6 service for
himself

 others ?

 Julien

---

From: Julien Laganier <[email-masked]>
Date: Mon, 15 Jan 2007 09:56:19 +0100

Hi Julien,

Some thoughts below,

On 1/10/07, Julien Bournelle wrote:
> Hi michele,
>
> On 1/8/07, La Monaca Michele wrote:
> > Hi Julien,
> >
> > as you said the separation between auth and autz
> > takes along modularity and flexibility but it
> > raises security concerns if the HA is
> > compromised. Therefore, I think that it would be
> > better to compare what a compromised HA
> > can/cannot do in the two cases:
> >
> > "Split" AAA approach
> >
> > 2) Grant service to fake users (i.e. steal the
> > service) YES 3) DoS to the AAA infrastructure
> > YES
>  The fact is that by separating authentitcation
> and authorization, if HA is compromised, a
> non-authenticated user can be authorized.

I understand what you mean but I think it would be more 
be more precise to say:

When separate authentication and authorization are used 
and the HA is compromised (by Mallory), it is possible 
that the HA submit the identity of another user 
(Alice) to the authorization server, have this other 
user (Alice) be authorized by the authorization 
server, although the user that will be provided with 
the service is different (e.g. Mallory, or whoever 
else.)

That is, the HA cannot render a unauthenticated user 
*authorized*, but rather provide it with the service 
in spite of the user being unauthorized.

This sounds somehow like the contrary of what you 
said :) Let me try to reword your sentence into:

   The fact is that by separating authentication
   and authorization, if HA is compromised, a 
   non-authenticated user can be unauthorized and use
   the service.

Then this would contradict your statement below...

> authorization are binded.

..because even if authentication and authorization are 
bound together, still a compromise HA could provide 
the service to *anyone* in spite of a particular 
instance of this anyone not being authenticated 
or/neither authorized.

>  The question is what are the consequence of this.

I therefore think there's no consequences.

> If Alice compromised the HA and asks an
> authorization for Bob. The problem that has been
> evoked is that Bob could be charged for the Mobile
> IPv6 service.

The problem with charging/accounting is different, and 
is caused by authentication being decoupled from 
accounting. That was evocated last year by Yoshi in 
one of his message:
 
<http://www1.ietf.org/mail-archive/web/dime/current/msg00964.html>

>  But wouldn't this problem also exist if
> authentication and authorization are tied

That's exactly my point. I think a problem with 
accounting would primarily be caused by decoupling of 
accounting and authentication, and would be orthogonal 
to a decoupling of authentication and authorization.

--julien

>  Julien
his sounds somehow like the contrary of what you 
said :) Let me try to reword your sentence into:

   The fact is that by separating authentication
   and authorization, if HA is compromised, a 
   non-authenticated user can be unauthorized and use
   the service.

Then this would contradict your statement below...

> authorization are binded.

..because even if authentication and authorization are 
bound together, still a compromise HA could provide 
the service to *anyone* in spite of a particular 
instance of this anyone not being authenticated 
or/neither authorized.

>  The question is what are the consequence of this.

I therefore think there's no consequences.

> If Alice compromised the HA and asks an
> authorization for Bob. The problem that has been
> evoked is that Bob could be charged for the Mobile
> IPv6 service.

The problem with charging/accounting is different, and 
is caused by authentication being decoupled from 
accounting. That was evocated last year by Yoshi in 
one of his message:
 
<http://www1.ietf.org/mail-archive/web/dime/current/msg00964.html>

>  But wouldn't this problem also exist if
> authentication and authorization are tied

That's exactly my point. I think a problem with 
accounting would primarily be caused by decoupling of 
accounting and authentication, and would be orthogonal 
to a decoupling of authentication and authorization.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Mon, 15 Jan 2007 11:12:41 +0100

> Hi Julien,

Hi Madjid,

> While I appreciate the threat analysis here, the
> problem is pretty easy to solve. Unless, we want to 
> leave this vulnerability as something only for the

Solving the problem implies that we understand it.

I am still not convinced that separation of 
authentication and authorization does indeed introduce 
a new vulnerability -- see my other note on the 
subject:

http://www1.ietf.org/mail-archive/web/dime/current/msg01178.html

Until we determine what are the threats and attacks, 
and determine whether each of them does represent a 
sufficiently important risk which deserve a 
countermeasure, I really think it is premature to 
devise solutions.

Best,

--julien

> I am working on a draft that shows how you can
> separate authentication and authorization while
> binding the two together. The draft will be
> submitted soon (or at least before next IETF
> deadline). There is one problem remaining and that
> is I am wondering about the messaging triggers (see
> below). If people like the solution we can use it
> for the WG draft. It is just hard to show a solution
> over ML, sorry.
>
> For now, I say, we can use the EAP method to
> generate MSK/EMSK and then use those keys in
> assurance for previous authentication (Diameter EAP)
> to the authorization server for Diameter MIP.
> The issue is that based on the threat analysis that
> you provided, we cannot trust HA to provide this
> assurance. It has to come from the peer and/or AAA
> server.
> One way would be for the peer to generate the key
> sign its request with this key. Without getting into
> the details right now, the issue would be: What
> message would carry this signature from the peer?
> And this is why I have been asking the question of
> what message would trigger the Mobile IP
> The problem is that we need to perform all Mobile IP
> bootstrapping after MAA, i.e. after the MN is
> actually authorized for Mobile IP, so if there is
> any message (even an IKEv2 message) that carries a
> Mobile IP parameter, it has to come  after MAA.
>
> Hope I am making sense,
>
> Madjid

---

From: Julien Laganier <[email-masked]>
Date: Mon, 15 Jan 2007 11:03:21 +0100

Hi Madjid,

Best,

--julien

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 16 Jan 2007 11:30:29 -0800

Hi Julien,

Unless you are looking for a formal threat analysis document, the attacks
have been described several times on the mailing list.

I am not against protocol decoupling, I am against complete
state-decoupling. 

I think the email you are referring to (your own) debates whether the issue
is with accounting or with authorization when a decoupling happens. 
There is a little bit of difference in threats for authorization versus
accounting. Many authorization frameworks, don't separate authorization from
authentication. Immediately following an authentication, the AAA server also
authorizes for services for the same authenticated peer, assuming the
resources are available. 

The solution being presented here is saying lets authorize the peer through
a separate signaling exchange and without proof of prior authentication.
Essentially decoupling the first A of AAA from the other two AAs, causes
spoofing problems, since the network is relying on an intermediary (HA) that
(1) initially has not been part of the authentication and (2) later can be
compromised to request authorization for an unauthenticated peer.

Since the authorization is separated from authentication, this means the
authorization signaling requires a separate trigger. I am saying the trigger
needs to come from the peer itself with a proof of identity and message
integrity. The HA should simply relay this message to the AAA server. Not
that the HA starts an authorization request on its own for an arbitrary
peer. This just sounds like a perfect DoS attack. The prevention does not
require a huge overhead, since the peer is already doing EAP and thus has
shared keys with the AAA servers and can easily sign follow-up authorization
messages. We just have to make sure we have a trigger from the peer in the
bootstrapping process.

The accounting signaling on the other hand is different. Accounting happens
without intervention of the peer and is between AAA client and AAA server.
The accounting needs to use whatever security mechanism available for
accounting framework. That is a AAA problem. The AAA server and AAA client
need to have mechanisms to protect against false accounting and that is
beyond scope of this work.

In summary, by decoupling authorization and authentication we ARE adding
threats to the existing network (by allowing a compromised AAA client to
request authorization for unauthenticated peer). But accounting is typically
decoupled from authentication anyway and we are not adding any new threats
to the existing accounting framework.

Hope this clarifies,

Madjid

-----Original Message-----
From: julien laganier [mailto:[email-masked]] On Behalf Of Julien
Laganier
Sent: Monday, January 15, 2007 2:03 AM
To: [email-masked]; Madjid Nakhjiri
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'
Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security

Hi Madjid,

Best,

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 17 Jan 2007 17:40:03 +0100

Hi Madjid,

Thanks for your reply.

No I am not looking for a formal threat analysis 
document. I am rather looking to understand what are 
the threat, and which attacks derive from them.

As I wrote in a previous note I disagree it is of value 
to block an attack in which a compromised HA presents 
fake identities to a mobility authorization server.

If the HA is compromised it can just furnish the 
mobility service to anyone it wants; it doesn't need 
to lie to the authorization server as I described in a 
previous note, quoted below (sorry to repeat myself):

   When separate authentication and authorization are
   used and the HA is compromised (by Mallory), it is
   possible that the HA submit the identity of another
   user (Alice) to the authorization server, have this
   other user (Alice) be authorized by the 
   authorization server, although the user that will be
   provided with the service is different (e.g.
   Mallory, or whoever else.)

   Binding authentication and authorization together
   doesn't prevent a compromised HA to provide the
   service to *anyone* in spite of a particular
   instance of this anyone not being authenticated 
   or/neither authorized.

In other words, the attack I've seen described doesn't 
IMHO represent a threat since someone who managed to 
compromise the HA can anyway provide mobility service 
to any unauthenticated and/or unauthorized user.

Am I missing something?

--julien

On Tuesday 16 January 2007 20:30, Madjid Nakhjiri 
wrote:
> Hi Julien,
>
> Unless you are looking for a formal threat analysis
> document, the attacks have been described several
> times on the mailing list.
>
> I am not against protocol decoupling, I am against
> complete state-decoupling.
>
> I think the email you are referring to (your own)
> debates whether the issue is with accounting or with
> authorization when a decoupling happens. There is a
> little bit of difference in threats for
> authorization versus accounting. Many authorization
> frameworks, don't separate authorization from
> authentication. Immediately following an
> authentication, the AAA server also authorizes for
> services for the same authenticated peer, assuming
> the resources are available.
>
> The solution being presented here is saying lets
> authorize the peer through a separate signaling
> exchange and without proof of prior authentication.
> Essentially decoupling the first A of AAA from the
> other two AAs, causes spoofing problems, since the
> network is relying on an intermediary (HA) that (1)
> initially has not been part of the authentication
> and (2) later can be compromised to request
> authorization for an unauthenticated peer.
>
> Since the authorization is separated from
> authentication, this means the authorization
> signaling requires a separate trigger. I am saying
> the trigger needs to come from the peer itself with
> a proof of identity and message integrity. The HA
> should simply relay this message to the AAA server.
> Not that the HA starts an authorization request on
> its own for an arbitrary peer. This just sounds like
> a perfect DoS attack. The prevention does not
> require a huge overhead, since the peer is already
> doing EAP and thus has shared keys with the AAA
> servers and can easily sign follow-up authorization
> messages. We just have to make sure we have a
> trigger from the peer in the bootstrapping process.
>
> The accounting signaling on the other hand is
> different. Accounting happens without intervention
> of the peer and is between AAA client and AAA
> server. The accounting needs to use whatever
> security mechanism available for accounting
> framework. That is a AAA problem. The AAA server and
> AAA client need to have mechanisms to protect
> against false accounting and that is beyond scope of
> this work.
>
> In summary, by decoupling authorization and
> authentication we ARE adding threats to the existing
> network (by allowing a compromised AAA client to
> request authorization for unauthenticated peer). But
> accounting is typically decoupled from
> authentication anyway and we are not adding any new
> threats to the existing accounting framework.
>
> Hope this clarifies,
>
> Madjid
>
>
>
>
>
> From: julien laganier
> [mailto:[email-masked]] On Behalf Of
> Julien Laganier
> > problem is pretty easy to solve. Unless, we want
> > to leave this vulnerability as something only for
> > the security consideration, I suggest we add the
> > security measure.
>
> authentication and authorization does indeed
> introduce a new vulnerability -- see my other note
> on the subject:
>
> > is I am wondering about the messaging triggers
> > (see below). If people like the solution we can
> > use it for the WG draft. It is just hard to show a
> > solution over ML, sorry.
> >
> > assurance for previous authentication (Diameter
> > EAP) to the authorization server for Diameter MIP.
> > The issue is that based on the threat analysis
> > that you provided, we cannot trust HA to provide
> > this assurance. It has to come from the peer
> > and/or AAA server.
> > sign its request with this key. Without getting
> > into the details right now, the issue would be:
> > What message would carry this signature from the
> > peer? And this is why I have been asking the
> > question of what message would trigger the Mobile
> > IP
> > The problem is that we need to perform all Mobile
> > IP bootstrapping after MAA, i.e. after the MN is

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 17 Jan 2007 16:50:42 -0800

Hi, 

If we are going based on a premise that the HA can authorize anybody
regardless of AAA server's authorization, then why are we bothering with
authorization messaging to begin with. The HA should just go ahead and
authorize MIP6 service. No AAA server and no amount of AAA messaging
security can prevent a AAA client from being a misbehaving Network access
server. So based on your reasoning we do not need any authorization
messaging or AAA protocol security either, since it does not prevent a
misbehaving AAA client. BTW, we don't need AAA authentication either.

An analogy here is that we don't need Mobile IP signaling security, since a
the HA can simply dump all the packets it receives or send them to timbaktu
if it wants.

We are not trying to boil the ocean by solving all security problems within
AAA infrastructures, we are simply trying to see we are not adding new
issues.

Most of authorization models today, authenticate and authorize the peer at
the same time and authorization ALWAYS follows successful authentication.
Here we are separating the two and saying that heck the servers can be
different too, without providing any assurance that the peer is previously
authenticated and this is a new threat. One threat is that the HA can launch
a DoS on the AAA server and bombard it with Authorization requests.

If the AAA server is to authorize somebody, it must make sure that somebody
is authenticated, the proof must either come from that somebody or from
within the AAA server (states). The HA cannot do this, because it has no
part of the EAP authentication.

Furthermore, people are suggesting that the Authenticating AAA server is
different from Authorizing AAA server, so that rules out the inner AAA state
thing. 

And yes, even AAA authorization does not guarantee that the HA lies when
sending accounting data, but I guess one problem at the time:)

My main issue here is actually something else and that is why Mobile IPv6
bootstrapping parameters are provided to the peer before the actual
authorization.

R,

Madjid

-----Original Message-----
From: julien laganier [mailto:[email-masked]] On Behalf Of Julien
Laganier
Sent: Wednesday, January 17, 2007 8:40 AM
To: [email-masked]
Cc: Madjid Nakhjiri
Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security

Hi Madjid,

Thanks for your reply.

Am I missing something?

--julien

---

From: Julien Laganier <[email-masked]>
Date: Thu, 18 Jan 2007 14:48:40 +0100

Hi Madjid,

I get the feeling that we are talking past to each 
others, so let me reply to you inline.

On Thursday 18 January 2007 01:50, Madjid Nakhjiri 
wrote:
> Hi,
>
> If we are going based on a premise that the HA can
> authorize anybody regardless of AAA server's
> authorization, then why are we bothering with
> authorization messaging to begin with. 

I thought the attack supposedly introduced by 
decoupling of authorization and authentication becomes 
possible when the HA is compromised. Isn't it the 
case? If not, could you please describe (or give a 
pointer to a description of it) what the attack really 
is?

If the attack is possible when HA is compromised, then 
certainly the HA doesn't need to lie to AAA server for 
authorizing the MIP6 service since it can provide it 
to whomever it wants.

> The HA should 
> just go ahead and authorize MIP6 service. No AAA
> server and no amount of AAA messaging security can
> prevent a AAA client from being a misbehaving
> Network access server. So based on your reasoning we
> do not need any authorization messaging or AAA
> protocol security either, since it does not prevent
> a misbehaving AAA client. BTW, we don't need AAA
> authentication either.

Madjid, this is not based on my reasoning at all, I 
never said that. You are putting words in my mouth. 
Please abstain from doing that, this really isn't 
helping the discussion.

> An analogy here is that we don't need Mobile IP
> signaling security, since a the HA can simply dump
> all the packets it receives or send them to timbaktu
> if it wants.

This is simply irrelevant.

> We are not trying to boil the ocean by solving all
> security problems within AAA infrastructures, we are
> simply trying to see we are not adding new issues.

This is exactly what I am trying to do: understand if 
new issues are introduced by decoupling.

> Most of authorization models today, authenticate and
> authorize the peer at the same time and
> authorization ALWAYS follows successful
> authentication. Here we are separating the two and
> saying that heck the servers can be different too,
> without providing any assurance that the peer is
> previously authenticated and this is a new threat.

The HA checks with the authentication server if the 
peer is authenticated, then it checks with the  
authorization server if it authorized.

At the HA, there is assurance that the peer is 
authenticated since it just checked if it was. 

So I do not see what the threat is.

> One threat is that the HA can launch a DoS on the
> AAA server and bombard it with Authorization
> requests.

But this is unrelated to decoupling of authorization 
and authentication. 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.

So this threat is not introduced by decoupling.  

> If the AAA server is to authorize somebody, it must
> make sure that somebody is authenticated, the proof
> must either come from that somebody or from within
> the AAA server (states).
> The HA cannot do this, 
> because it has no part of the EAP authentication.

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. So 
certainly the AAA server can trust the HA to provide 
reliable authenticated identities for authorization.

What would be a reason for the HA not do so (it doesn't 
need to ask the AAA server to provide the service to 
anyone it wants) and what attacks would that realize 
(it doesn't need to ask the AAA server to provide the 
service to anyone it wants).

But I guess I am just repeating myself so better to 
stop here.

Best,

--julien

> Furthermore, people are suggesting that the
> Authenticating AAA server is different from
> Authorizing AAA server, so that rules out the inner
> AAA state thing.
>
> And yes, even AAA authorization does not guarantee
> that the HA lies when sending accounting data, but I
> guess one problem at the time:)
>
> My main issue here is actually something else and
> that is why Mobile IPv6 bootstrapping parameters are
> provided to the peer before the actual
> authorization.
>
>
> R,
>
> Madjid
>
>
>
>
> As I wrote in a previous note I disagree it is of
> value to block an attack in which a compromised HA
> presents fake identities to a mobility authorization
> server.
>
> to lie to the authorization server as I described in
> a previous note, quoted below (sorry to repeat
> myself):
>
>    When separate authentication and authorization
> are used and the HA is compromised (by Mallory), it
> is possible that the HA submit the identity of
> another user (Alice) to the authorization server,
> have this other user (Alice) be authorized by the
>    authorization server, although the user that will
> be provided with the service is different (e.g.
>    That is, the HA cannot render a unauthenticated
> user *authorized*, but rather provide it with the
> service in spite of the user being unauthorized.
>
> In other words, the attack I've seen described
> doesn't IMHO represent a threat since someone who
> managed to compromise the HA can anyway provide
> mobility service to any unauthenticated and/or
> unauthorized user.
>
> Am I missing something?
>
> --julien
>
> > Unless you are looking for a formal threat
> > analysis document, the attacks have been described
> > several times on the mailing list.
> >
> > debates whether the issue is with accounting or
> > with authorization when a decoupling happens.
> > There is a little bit of difference in threats for
> > authorization versus accounting. Many
> > authorization frameworks, don't separate
> > authorization from authentication. Immediately
> > following an
> > exchange and without proof of prior
> > authentication. Essentially decoupling the first A
> > of AAA from the other two AAs, causes spoofing
> > problems, since the network is relying on an
> > intermediary (HA) that (1) initially has not been
> > part of the authentication and (2) later can be
> > the trigger needs to come from the peer itself
> > with a proof of identity and message integrity.
> > The HA should simply relay this message to the AAA
> > server. Not that the HA starts an authorization
> > request on its own for an arbitrary peer. This
> > just sounds like a perfect DoS attack. The
> > prevention does not require a huge overhead, since
> > the peer is already doing EAP and thus has shared
> > keys with the AAA servers and can easily sign
> > follow-up authorization messages. We just have to
> > make sure we have a trigger from the peer in the
> > bootstrapping process.
> >
> > framework. That is a AAA problem. The AAA server
> > and AAA client need to have mechanisms to protect
> > against false accounting and that is beyond scope
> > of this work.
> >
> > authentication we ARE adding threats to the
> > existing network (by allowing a compromised AAA
> > client to request authorization for
> > unauthenticated peer). But accounting is typically
> > decoupled from
> > authentication anyway and we are not adding any
> > new threats to the existing accounting framework.
> >
> > Hope this clarifies,
> >
> > Madjid
> >
> >
> >
> >
> >
> > On Friday 12 January 2007 19:33, Madjid Nakhjiri
>
> wrote:
> > > Hi Julien,
> >
> > Hi Madjid,
> >
> > > to leave this vulnerability as something only
> > > for the security consideration, I suggest we add
> > > the security measure.
> >
> > http://www1.ietf.org/mail-archive/web/dime/current
> >/m sg01178.html
> >
> > Until we determine what are the threats and
> > attacks, and determine whether each of them does
> > represent a sufficiently important risk which
> > deserve a countermeasure, I really think it is
> > premature to devise solutions.
> >
> > Best,
> >
> > --julien
> >
> > > deadline). There is one problem remaining and
> > > that is I am wondering about the messaging
> > > triggers (see below). If people like the
> > > solution we can use it for the WG draft. It is
> > > just hard to show a solution over ML, sorry.
> > >
> > > EAP) to the authorization server for Diameter
> > > MIP. The issue is that based on the threat
> > > analysis that you provided, we cannot trust HA
> > > to provide this assurance. It has to come from
> > > the peer and/or AAA server.
> > > One way would be for the peer to generate the
> > > key sign its request with this key. Without
> > > getting into the details right now, the issue
> > > would be: What message would carry this
> > > signature from the peer? And this is why I have
> > > been asking the question of what message would
> > > trigger the Mobile IP
> > > The problem is that we need to perform all
> > > Mobile IP bootstrapping after MAA, i.e. after
> > > the MN is actually authorized for Mobile IP, so
> > > if there is any message (even an IKEv2 message)
> > > that carries a Mobile IP parameter, it has to
> > > come  after MAA.
> > >
> > > Hope I am making sense,
> > >
> > > Madjid
> >

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 18 Jan 2007 11:06:27 -0800

Hi Julien,

Hi Julien,

Let me start again: First I think only authenticated users should be
authorized for service. Do you agree?

If yes, then when decoupling authentication and authorization, you can
potentially go to one server for authentication (AAAn) and a different one
for authorization (AAAz). The AAAz has no idea that the MN has previously
been authenticated by AAAn. The proof of authentication at AAAn cannot be
provided by HA to the AAAz. It should be provided by either MN or AAAn. 
I realize that the HA can authorize service to whomever it wants regardless
of what AAAz says. But that threat exists even when authentication and
authorization are done at the same time. It does not cause any disruption
for the AAA CPU or memory or AAA channel, etc. But, when you decouple the
two, and allow the HA to create many fake service requests, you are
introducing a new threat to the AAAz: It is processing many requests, it is
depleting the resources off the resource database, it may be allocating HA
to people and bring the other HA s down as well.

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.

"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.

"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.

Madjid
-----Original Message-----
From: julien laganier [mailto:[email-masked]] On Behalf Of Julien
Laganier
Sent: Thursday, January 18, 2007 5:49 AM
To: Madjid Nakhjiri
Cc: [email-masked]
Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security

Hi Madjid,

Best,

--julien

---

From: Julien Laganier <[email-masked]>
Date: Fri, 19 Jan 2007 15:08:49 +0100

On Thursday 18 January 2007 20:06, Madjid Nakhjiri 

Hi Madjid,

> Hi Julien,

Hi again,

> Let me start again: First I think only authenticated
> users should be authorized for service. Do you
> agree?

In this case, since authorization is delivered or not 
based on the user identity, certainly the user shall 
be authenticated.

> If yes, then when decoupling authentication and
> authorization, you can potentially go to one server
> for authentication (AAAn) and a different one for
> authorization (AAAz).

Right: this is the split between authentication and 
authorization we've been discussing.

> The AAAz has no idea that the MN has previously been
> authenticated by AAAn.

Why should it know about authentication -- we're 
talking about separating the two here.

AAAz is giving an authorization status for a MN 
identity to an HA requesting this information. 
Authentication of the MN is orthogonal to that.

> The proof of authentication at AAAn cannot be
> provided by HA to the AAAz. 

The question isn't if it can or if it cannot. The AAAz 
isn't in charge of veryfing authentication proof, it 
is in charge of delivering authorization status to a 
AAA client requesting it.

> It should be provided by either MN or AAAn.

No it shouldn't, that's the whole point of split. If 
you want the AAAz to know about authentication, then 
don't split entities and use a single AAAn/z.

Further, I am reading your statement as somehow saying 
that the MN is more trustworthy than the HA (you said 
"The proof of authentication at AAAn cannot be 
provided by HA to the AAAz. It should be provided by 
either MN or AAAn."), and I find it surprising. Maybe 
I read you wrong...

> I realize that the HA can authorize service to
> whomever it wants regardless of what AAAz 
> says. 

Good.

> But that threat exists even when authentication and
> authorization are done at the same time. 

Nobody argued about that.

> It does not cause any disruption for the AAA CPU or
> memory or AAA channel, etc. 

Right.

> But, when you decouple the two, and allow the HA to
> create many fake service requests, you are
> introducing a new threat to the AAAz: It is
> processing many requests, it is depleting the
> resources off the resource database, it may be
> allocating HA to people and bring the other HA s down
> as well. 

So if I read you correctly, in the threat you're 
describing there is a rogue HA launching a denial of 
service attack against the AAAz, right? And this DoS 
takes the form of a flooding attack?

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.

> 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.

> HA would be able to launch a DoS on the AAA server
> and bombard it with authentication and authorization
> requests."
>

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

> decoupling of authorization and authentication
> becomes possible when the HA is compromised. Isn't
> it the case? If not, could you please describe (or
> give a pointer to a description of it) what the
> attack really is?
>
> If the attack is possible when HA is compromised,
> then certainly the HA doesn't need to lie to AAA
> server for authorizing the MIP6 service since it can
> provide it to whomever it wants.
>
> > The HA should
> > Network access server. So based on your reasoning
> > we do not need any authorization messaging or AAA
> > protocol security either, since it does not
> > prevent a misbehaving AAA client. BTW, we don't
> > need AAA authentication either.
>
> > all the packets it receives or send them to
> > timbaktu if it wants.
>
> > security problems within AAA infrastructures, we
> > are simply trying to see we are not adding new
> > issues.
>
> This is exactly what I am trying to do: understand
> if new issues are introduced by decoupling.
>
> > Most of authorization models today, authenticate
> > and authorize the peer at the same time and
> and authentication. 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 AAA server is to authorize somebody, it
> > must make sure that somebody is authenticated, the
> > proof must either come from that somebody or from
> > within the AAA server (states).
> > The HA cannot do this,
> 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.
> So certainly the AAA server can trust the HA to
> provide reliable authenticated identities for
> authorization.
>
> What would be a reason for the HA not do so (it
> doesn't need to ask the AAA server to provide the
> service to anyone it wants) and what attacks would
> that realize (it doesn't need to ask the AAA server
> to provide the service to anyone it wants).
>
> > Authorizing AAA server, so that rules out the
> > inner AAA state thing.
> >
> > that the HA lies when sending accounting data, but
> > I guess one problem at the time:)
> >
> > that is why Mobile IPv6 bootstrapping parameters
> > are provided to the peer before the actual
> > authorization.
> >
> >
> > R,
> >
> > Madjid
> >
> >
> >
> >
> > document. I am rather looking to understand what
> > are the threat, and which attacks derive from
> > them.
> >
> > presents fake identities to a mobility
> > authorization server.
> >
> > mobility service to anyone it wants; it doesn't
> > need to lie to the authorization server as I
> > described in a previous note, quoted below (sorry
> > to repeat myself):
> >
> > are used and the HA is compromised (by Mallory),
> > it is possible that the HA submit the identity of
> >    Binding authentication and authorization
> > together doesn't prevent a compromised HA to
> > provide the service to *anyone* in spite of a
> > particular instance of this anyone not being
> > authenticated or/neither authorized.
> >
> > > analysis document, the attacks have been
> > > described several times on the mailing list.
> > >
> > > I am not against protocol decoupling, I am
> > > against complete state-decoupling.
> > >
> > > I think the email you are referring to (your
> > > own) debates whether the issue is with
> > > accounting or with authorization when a
> > > decoupling happens. There is a little bit of
> > > difference in threats for authorization versus
> > > accounting. Many
> > > authentication, the AAA server also authorizes
> > > for services for the same authenticated peer,
> > > assuming the resources are available.
> > >
> > > authentication. Essentially decoupling the first
> > > A of AAA from the other two AAs, causes spoofing
> > > intermediary (HA) that (1) initially has not
> > > been part of the authentication and (2) later
> > > can be compromised to request authorization for
> > > an unauthenticated peer.
> > >
> > > signaling requires a separate trigger. I am
> > > saying the trigger needs to come from the peer
> > > itself with a proof of identity and message
> > > integrity. The HA should simply relay this
> > > message to the AAA server. Not that the HA
> > > starts an authorization request on its own for
> > > an arbitrary peer. This just sounds like a
> > > perfect DoS attack. The prevention does not
> > > require a huge overhead, since the peer is
> > > already doing EAP and thus has shared keys with
> > > the AAA servers and can easily sign follow-up
> > > authorization messages. We just have to make
> > > sure we have a trigger from the peer in the
> > > bootstrapping process.
> > >
> > > different. Accounting happens without
> > > intervention of the peer and is between AAA
> > > client and AAA server. The accounting needs to
> > > use whatever security mechanism available for
> > > accounting framework. That is a AAA problem. The
> > > AAA server and AAA client need to have
> > > mechanisms to protect against false accounting
> > > and that is beyond scope of this work.
> > >
> > > unauthenticated peer). But accounting is
> > > typically decoupled from
> > > > While I appreciate the threat analysis here,
> > > > the problem is pretty easy to solve. Unless,
> > > > we want to leave this vulnerability as
> > > > something only for the security consideration,
> > > > I suggest we add the security measure.
> > >
> > > introduce a new vulnerability -- see my other
> > > note on the subject:
> > >
> > > http://www1.ietf.org/mail-archive/web/dime/curre
> > >nt /m sg01178.html
> > >
> > > > separate authentication and authorization
> > > > while binding the two together. The draft will
> > > > be submitted soon (or at least before next
> > > > IETF deadline). There is one problem remaining
> > > > and that is I am wondering about the messaging
> > > > assurance for previous authentication
> > > > (Diameter EAP) to the authorization server for
> > > > Diameter MIP. The issue is that based on the
> > > > threat analysis that you provided, we cannot
> > > > trust HA to provide this assurance. It has to
> > > > come from the peer and/or AAA server.
> > > > signature from the peer? And this is why I
> > > > the MN is actually authorized for Mobile IP,
> > > > so if there is any message (even an IKEv2
> > > > message) that carries a Mobile IP parameter,
> > > > it has to come  after MAA.
> > > >
> > > > Hope I am making sense,
> > > >
> > > > Madjid
> > >

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 19 Jan 2007 12:02:37 -0600

Hi Julien,
Please see one comment below.

Regards,
Ahmad

> From: Julien Laganier [mailto:[email-masked]] 
> Sent: Friday, January 19, 2007 8:09 AM
> To: [email-masked]

[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.
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.

Theoretically, I agree with Madjid that there is an issue that needs to
be addressed. 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.