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

From: "Julien Bournelle" <[email-masked]>
Date: Tue, 5 Dec 2006 10:33:51 +0100

Hi madjid,

 sorry for the late response

On 11/30/06, Madjid Nakhjiri <[email-masked]> 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 ?

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

> or if the
> AAA server does not keep any authentication state (ok for Diameter),

 why is it a problem ?

>  or if
> the client uses a different ID for authorization (we agreed that we should
> not do this), or issues related to HA:
>
> 1) HA change is needed (e.g. keeping AAA_EAP ID, and other MN-authentication
> state to send to AAA_MIP). Currently, we are saying that the HA needs to
> keep state on the authentication.
>
> 2) HA must be trusted with its reporting (it does not fake an authentication
> that never happened), so it does not launch DoS attacks on the AAA_MIP by
> sending a lot of fake authorization requests.
>
> 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.

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

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

 Julien

> Please see my other email to Ahmad.
> Yes, we need to find a way to carry the new attributes, and may be that has
> to be through Diameter EAP, not sure, need to investigate.
>
> R,
>
> Madjid
>
>
>
>
> -----Original Message-----
> From: Julien Bournelle [mailto:[email-masked]]
> Sent: Thursday, November 23, 2006 12:42 AM
> To: Ahmad Muhanna
> Cc: [email-masked]
> Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split
>
> HI Ahmad,
>
>  thanks a lot for your review. I respond to your proposal and try to
> sum up a little our current situation with this highligting three
> different ways to move forward.
>
> On 11/22/06, Ahmad Muhanna <[email-masked]> wrote:
> >
> > Hi all,
> >
> > The following is an idea that I would like to throw out as a possible
> > solution:
> >
> > I believe the easiest way is for the HA to include an explicit attribute
> > that the user has been authenticated successfully. This way, the
> > AAAH-MIP6 have an explicit indication and record from the serving HA,
> > regardless if it is in the Home or Visited Network. We may also require
> > that the HA include the identity of the AAAH-EAP server which did the
> > authentication.
> >
> > Comments:
> > ??
>
>  hmm, the threat mentionned by madjid was that the HA is compromised
> and uses a fake AAA-EAP server. In this case, the HA would be able to
> send your proposed attribute. I'm not sure this solve the issue.
>
>  Personnally, before solving this issue, I think we should agree or
> not on the fact that it si effectivily an issue. The fact that we use
> 4072 in AUTHENTICATE_ONLY mode for Authentication and define a new
> application for the Authorization/Accounting part was to avoid to
> update all Diameter Application using EAP for Authentication if 4072
> has to be updated. As we define a new application for
> Authorization/Accounting, we lost the binding between Authentication
> and Authorization/Accounting at the AAA server. However, AAAH-EAP and
> AAAH-MIP6 belong to the MSA and finally the HA is now responsible of
> this binding.
>
>  To move forward with this I see 3 options:
>
>  1/ We continue with the current approach and decide that this is not
> an issue if the Authz/Acctg server has no "proof" that the user has
> been authenticated. The HA is responsible for this.
>
>  We consider that this is an issue. So we consider that the
> Authz/Acctg need to be bound to the Authentication. Then we have 2
> options:
>
>  2/ We include DER/DEA messages in the MIP6 Application but define a
> new command-code. An update of 4072 would certainly lead to an update
> of this application.
>
>  3/ We define a generic mechanism that permits to give a proof to the
> AAAH-MIP6 that AAAH-EAP has correctly authenticated the user.
>
>  Comments ?
>
>
>  Let me know if you see others options.
>
>  Julien
>
>
>
> >
> >
> > Regards,
> > Ahmad
> >
> >
> > > -----Original Message-----
> > > From: Hannes Tschofenig [mailto:[email-masked]]
> > > Sent: Friday, November 10, 2006 6:26 PM
> > > To: [email-masked]
> > > Subject: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split
> > >
> > > Hi all,
> > >
> > > during the DIME meeting Glen raised an important question
> > > that impacts the design of the protocol, namely:
> > > "
> > > Do we need to support the scenario where the Diameter EAP
> > > authentication and the Diameter MIPv6 authorization exchange
> > > terminate at different servers?
> > > "
> > >
> > > Currently, we assume that these two exchanges could be
> > > terminated at different servers. As a  consequence, security
> > > concerns were raised (see slide 5 of
> > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt).
> > >
> > > How do people think about restricting the Diameter MIPv6
> > > HA-to-AAAH document to terminate the authentication and
> > > authorization exchange at the same server?
> > >
> > > Ciao
> > > Hannes
> > >
> > > PS: Glen also suggested to consider using the Diameter MIPv6
> > > App-ID for the Diameter EAP exchange if we decide that both
> > > exchanges terminate at the same server. As a consequence the
> > > open issue described at slide 6 of
> > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt
> > > would also be resolved. The changes to the existing document
> > > would be minimal (about 2 additional sentences).
> > >
> > >
> > > _______________________________________________
> > > DiME mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/dime
> > >
> >
> > _______________________________________________
> > DiME mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/dime
> >
>
> _______________________________________________
> 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: "Julien Bournelle" <[email-masked]>
Date: Tue, 5 Dec 2006 10:34:31 +0100

HI madjid,

On 11/30/06, Madjid Nakhjiri <[email-masked]> wrote:
> PS. I missed your 3rd option. I agree this can be a generic mechanism, but
> not sure about the details, can you elaborate?

 I don't have the details. This should be investigated.

 Julien

---

From: "Julien Bournelle" <[email-masked]>
Date: Tue, 5 Dec 2006 10:47:27 +0100

Hi Ahmad,

  inline.

On 11/23/06, Ahmad Muhanna <[email-masked]> wrote:

 <snip>

> >  hmm, the threat mentionned by madjid was that the HA is
> > compromised and uses a fake AAA-EAP server. In this case, the
> > HA would be able to send your proposed attribute. I'm not
> > sure this solve the issue.
>
> [Ahmad]
> I am not sure what the exact meaning and the extent of the HA being
> compromised? (IMO) If the HA is compromised, why the HA needs
> authorization from AAAH-MIP6 to start with. HA will be able to offer the
> service without the need to contact the AAAH-MIP6 server.

 yes you're right. That's one of the reason i'm wondering if we really
need to inform the authorization server that the authentication is ok.

>
> On the other hand, we probably should come up with a mechanism which
> allows the HA to communicate both Authentication and authorization to
> the same server.

 basically this can be done by configuration.

> >  Personnally, before solving this issue, I think we should
> > agree or not on the fact that it si effectivily an issue. The
> > fact that we use
> > 4072 in AUTHENTICATE_ONLY mode for Authentication and define
> > a new application for the Authorization/Accounting part was
> > to avoid to update all Diameter Application using EAP for
> > Authentication if 4072 has to be updated. As we define a new
> > application for Authorization/Accounting, we lost the binding
> > between Authentication and Authorization/Accounting at the
> > AAA server. However, AAAH-EAP and
> > AAAH-MIP6 belong to the MSA and finally the HA is now
> > responsible of this binding.
> >
> >  1/ We continue with the current approach and decide that
> > this is not an issue if the Authz/Acctg server has no "proof"
> > that the user has been authenticated. The HA is responsible for this.
> >
>
> [Ahmad]
> It is ok as long as the HA include something to indicate that the user
> has been authenticated.
> Possibly: HA include an attribute to indicate
> that user have been authenticated and/or the identity of the AAAH-EAP
> server which done the authentication. At least there will be some record
> that HA has communicated that. Especially when HA is in the visited
> network.

 what is the goal of this indication ?

> >  2/ We include DER/DEA messages in the MIP6 Application but
> > define a new command-code. An update of 4072 would certainly
> > lead to an update of this application.
>
> [Ahmad]
> Basically this option assumes that the same AAAH server support
> authentication and authorization. Right?

 yes. It would be the same application and we won't need anymore
specific authorization messages.

> What about if we think of a mechanism that allows the HA to send the MAR
> to the same AAAH which done EAP authentication and at the same time it
> supports AAAH-MIP6. This way we avoid the update for the existing RFC
> and at the same time guarantee that the same server does both
> operations.

 the problem is the AAA routing. Let me know if I'm wrong but if we
use different application-id code, we are not sure that AAA messages
will hit the same AAA server.

>
> Here I am throwing a couple of thoughts:
>
> Option 1:
> 1. Mandating that AAAH server which support EAP to support MIP6
> Authorization.
> 2. Then HA always sends the MAR to the same server which done the EAP
> authentication via the AAAH-EAP identity.
>
> Option 2 (this gives more flexibility):
> 1. HA and/or proxy Diameter server should track Diameter servers which
> support both EAP and MIP6 Authorization during capabilities exchange.
> 2. HA and/or Proxy Diameter Server should forward the EAP authentication
> to a server that support both EAP authentication + MIP6 authorization.
> 3. HA sends the MIP6 Authorization request (MAR) to the same AAAH-EAP
> server which performed the EAP authentication.
>
> Comments ?

 I fear it would add complexity in proxy agents.
 What do others think ?

 Julien

> [Ahmad]
> If we agree on one of the options above, then this is already addressed.
>
> >
> >  Comments ?
> >
> >
> > > > during the DIME meeting Glen raised an important question that
> > > > impacts the design of the protocol, namely:
> > > > "
> > terminated at
> > > > different servers. As a  consequence, security concerns
> > were raised
> > > > (see slide 5 of
> > HA-to-AAAH
> > > > document to terminate the authentication and
> > authorization exchange
> > > > at the same server?
> > > >
> > > > Ciao
> > > > Hannes
> > > >
> > > > PS: Glen also suggested to consider using the Diameter
> > MIPv6 App-ID
> > > > for the Diameter EAP exchange if we decide that both exchanges
> > > > terminate at the same server. As a consequence the open issue
> > > > described at slide 6 of
> > > > would also be resolved. The changes to the existing
> > document would
> > > > be minimal (about 2 additional sentences).
> > > >
> > > >

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 07 Dec 2006 14:59:22 -0800

Hi Julien,

-----Original Message-----
From: Julien Bournelle [mailto:[email-masked]] 
Sent: Tuesday, December 05, 2006 1:34 AM
To: Madjid Nakhjiri
Cc: Ahmad Muhanna; [email-masked]
Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split

Hi madjid,

Madjid>>yes, see below.

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. 

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

Madjid>>I gave you an example above.

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

 Julien

---

From: "Julien Bournelle" <[email-masked]>
Date: Mon, 11 Dec 2006 14:11:08 +0100

Hi madjid, all,

>  One question is: is this really an issue ?

 maybe others have a different opinion.

> Madjid>>well, define trust?
>  Just because HA as a AAA client shares a key

 sure.

> for somebody else! So basically the HA can help the MN steal service.

  The assumption that the HA could be compromised is the reason why we
are talking about this. One question is if this assumption doesn't
bring concerns more important.

As an example, if the HA is compromised, why should it contact the AAA_MIP6 ?

 Julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 11 Dec 2006 11:32:34 -0600

Hi Julien,
Sorry for the late response, please see one comment below.

Regards,
Ahmad

> > >  1/ We continue with the current approach and decide that this is 
> > > not an issue if the Authz/Acctg server has no "proof"
> > Possibly: HA include an attribute to indicate that user have been 
> > authenticated and/or the identity of the AAAH-EAP server which done 
> > the authentication. At least there will be some record that HA has 
> > communicated that. Especially when HA is in the visited network.
> 

[Ahmad]
IMHO, I believe the HA is responsible for this, but the HA still needs
to communicate to the Authorizing server that the user has been
authenticated vi a certain server (AAAH-EAP), especially when the HA is
in the visited network. If we guarantee the delivery of authorization
request to the same server which done the authentication, then this
becomes no issue.

> > > new command-code. An update of 4072 would certainly lead to an 
> > > update of this application.
> >
> > [Ahmad]
>  yes. It would be the same application and we won't need 
> anymore specific authorization messages.
> 
> > What about if we think of a mechanism that allows the HA to 
> send the 
> > MAR to the same AAAH which done EAP authentication and at the same 
> > time it supports AAAH-MIP6. This way we avoid the update for the 
> > existing RFC and at the same time guarantee that the same 
> server does 
> > both operations.
> 
>  the problem is the AAA routing. Let me know if I'm wrong but 
> if we use different application-id code, we are not sure that 
> AAA messages will hit the same AAA server.
> 
> >
> > 2. HA and/or Proxy Diameter Server should forward the EAP 
> > authentication to a server that support both EAP 
> authentication + MIP6 authorization.
> > > > > Subject: [Dime] Diameter Mobile IPv6 HA-to-AAAH 
> Support: Server 
> > > > > Split
> > > > >
> > > > > Hi all,
> > > > >

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 20 Dec 2006 14:42:47 -0800

Hi Julien,

A compromised HA will of course contact AAA-MIP6 to steal service or Denial
of service attacks. I am not sure what kind of proof you are providing?
Otherwise why would we care about HA compromise?:)

Madjid

 sure.

As an example, if the HA is compromised, why should it contact the AAA_MIP6

---

From: "Julien Bournelle" <[email-masked]>
Date: Thu, 21 Dec 2006 09:37:54 +0100

Hi madjid,

> of service attacks. I am not sure what kind of proof you are providing?

 If you can compromise the HA to steal the service, why would you
contact the AAA-MIP6 to get an authorization ?

 Julien

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 28 Dec 2006 23:57:44 -0800

I think you are missing the point here. If you separate authentication and
authorization without making sure identities are proven, You can get the HA
to give a rouge node Mobile IP service, while another node gets charged for
it. That is just one example for the problems ahead.

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:[email-masked]] 
Sent: Thursday, December 21, 2006 12:38 AM
To: Madjid Nakhjiri
Cc: Ahmad Muhanna; [email-masked]
Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split

Hi madjid,

 Julien

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 29 Dec 2006 10:57:29 -0500

Madjid,

How this problem is different from the problem that would arise from
separating accounting and authentication/authorization? 

Yoshihiro Ohba

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 29 Dec 2006 15:11:50 -0800

Not sure what the problem you are referring to, is, but there can be several
problems if you just separate authentication from authz/accounting without
taking proper precautions. I just brought one up directly related to
Julien's question.

Madjid

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Friday, December 29, 2006 7:57 AM
To: Madjid Nakhjiri
Cc: 'Julien Bournelle'; [email-masked]
Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split

Madjid,

Yoshihiro Ohba