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

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 10 Nov 2006 16:25:51 -0800

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 15 Nov 2006 17:08:03 -0500

I'd not much care whether authentication and authorization use
different servers, but I have no technical problem with use of
different servers since we already allow to use different servers for
accounting and authentication/authorization.

I'd rather care whether authentication and authorization are separated
even if the same server is used authentication and authorization.  I
am not convinced with combining MIP6 authorization and EAP
authentication in the same application.  MIP6 authorization with AAA
could happen without EAP, e.g., when EAP is not used for IKEv2
authentication.  It is more modular and flexible to separate MIP6
authorization and EAP authentication.

Also, this discussion might depend on the ongoing discussion in MIP6
WG on RFC4285 support in draft-ietf-mip6-aaa-ha-goals draft.

Regards,
Yoshihiro Ohba

---

From: "La Monaca Michele" <[email-masked]>
Date: Tue, 21 Nov 2006 19:46:32 +0100

Hi Hannes,

I think it doesn't make much sense to separate authentication and
authorization and, at the same time, to mandate that the two AAA servers
are the same server. I think that the main advantage of this kind of
solution is that you can leverage a common infrastructure for
authentication while deploying ad-hoc solutions for authorization.

Worse, in a roaming scenario, NASes and local HAs might not know the
exact Diameter Identity of the home AAA. Therefore AAA routing would be
based only on the Destination-Realm-AVP and the Application ID (i.e.
EAP). Does this imply that the MIPv6 AAAH must be also in charge to
handle AAA EAP requests for the access? What if another service want to
use the same mechanism (EAP for authentication and a dedicated Diameter
app for authorization)? Are you thinking at some sort of AAA source
routing based on the type of node sending the message? 

Last, but not least, I still miss a real understanding of the threats
you considered to motivate the "servers merge".  In
http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt I read
"AAA-MIP6 has no proof that MN has been correctly authenticated (by
AAA-EAP)". Why not? AAA-MIP6 trusts its HAs and HAs guarantee for MNs.
Concerns for roaming scenarios?

Btw, the simple statement that "the same device handles EAP and MIPv6"
doesn't add any security if you don't specify how the Diameter EAP and
MIPv6 servers interact. Actually, putting two different functionalities
on the same device seems to me a weakness rather than a point of
strength: one machine violated -> both functionalities compromised.

My 5 cent.

Regards,
--Michele

> -----Messaggio originale-----
> Da: Hannes Tschofenig [mailto:[email-masked]]
> Inviato: sabato 11 novembre 2006 1.26
> A: [email-masked]
> Oggetto: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split
> 
> Hi all,
> 
--------------------------------------------------------------------

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: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 22 Nov 2006 13:05:07 -0600

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

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

---

From: "Julien Bournelle" <[email-masked]>
Date: Thu, 23 Nov 2006 09:42:05 +0100

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.

> that the HA include the identity of the AAAH-EAP server which did the

 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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 23 Nov 2006 16:08:14 -0600

Hi Julien,
Thanks for your comments. Please see my comments below.

Regards,
Ahmad

> From: Julien Bournelle [mailto:[email-masked]] 
> Sent: Thursday, November 23, 2006 2:42 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Hannes Tschofenig; [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.
> 
> > I believe the easiest way is for the HA to include an explicit 
> > attribute that the user has been authenticated 
> successfully. This way, 
> > the
> > 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.

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

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. Please see some thoughts below.

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

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

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 ?

> AAAH-MIP6 that AAAH-EAP has correctly authenticated the user.

[Ahmad]
If we agree on one of the options above, then this is already addressed.

> > > 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, 30 Nov 2006 10:45:18 -0800

Hi Ahmad,

Yes, this is what is needed, that is why I called this "authorization token"
when raised the issue.
The authentication assurance (token) comes from AAAH-EAP in form of an
attribute to the AAA client (presumably the same as the HA, although that is
debatable too, if MSP and ASP are different), gets to HA, and then forwarded
to the AAAH-MIP through an attribute.
However, it is a bit more complicated than that, the assurance must be
certified, i.e. a AAAH-EAP signature would be needed, otherwise any HA or
proxy can create that token and insert it in the attribute.
The AAAH-MIP must also be able to verify the AAAH-EAP signature, which means
some trust relationship between AAAH-EAP and AAAH-MIP is required as well.
Still a manageable problem IMO.

R,

Madjid

-----Original Message-----
From: Ahmad Muhanna [mailto:[email-masked]] 
Sent: Wednesday, November 22, 2006 11:05 AM
To: Hannes Tschofenig; [email-masked]
Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split

Hi all,

Comments: 
??

Regards,
Ahmad

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 30 Nov 2006 11:01:11 -0800

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. Things
that cause problem are when the AAA-MIP is different from AAA_EAP, or if the
AAA server does not keep any authentication state (ok for Diameter), 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.

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

 Comments ?

 Julien

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 30 Nov 2006 11:02:03 -0800

PS. I missed your 3rd option. I agree this can be a generic mechanism, but
not sure about the details, can you elaborate?

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,

 Comments ?

 Julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 30 Nov 2006 13:21:40 -0600

Hi Madjid,

I assume that you mean the AAA-EAP signature is identical per user per
session. Right?
On the other hand, could you please comment on the other options I sent
in response to Julien's options. Thanks.

Regards,
Ahmad

> From: Madjid Nakhjiri [mailto:[email-masked]] 
> Sent: Thursday, November 30, 2006 12:45 PM
> To: Muhanna, Ahmad (RICH1:2H10); 'Hannes Tschofenig'; [email-masked]
> Cc: 'Madjid Nakhjiri'
> The authentication assurance (token) comes from AAAH-EAP in 
> form of an attribute to the AAA client (presumably the same 
> as the HA, although that is debatable too, if MSP and ASP are 
> different), gets to HA, and then forwarded to the AAAH-MIP 
> through an attribute.
> However, it is a bit more complicated than that, the 
> assurance must be certified, i.e. a AAAH-EAP signature would 
> be needed, otherwise any HA or proxy can create that token 
> and insert it in the attribute.
> The AAAH-MIP must also be able to verify the AAAH-EAP 
> signature, which means some trust relationship between 
> AAAH-EAP and AAAH-MIP is required as well.

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 30 Nov 2006 14:37:01 -0800

Hi Ahmad,

Not sure what you mean by "identical", if you mean unique? Yes.
As far as the other option, do you mean the HA including the id of AAA_EAP
for AAA_MIP? I think that would be needed too. It could be included in the
signature as well. If you mean something else, please let me know, what it
was? Thanks.

R,

Madjid

-----Original Message-----
From: Ahmad Muhanna [mailto:[email-masked]] 
Sent: Thursday, November 30, 2006 11:22 AM
To: Madjid Nakhjiri; Hannes Tschofenig; [email-masked]
Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split

Hi Madjid,

Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 30 Nov 2006 19:13:54 -0600

Thanks Madjid. 
Please see comments inline.

Regards,
Ahmad

> Sent: Thursday, November 30, 2006 4:37 PM

[Ahmad] Yep. that's exactly what I meant.

> As far as the other option, do you mean the HA including the 
> id of AAA_EAP for AAA_MIP? I think that would be needed too. 
> It could be included in the signature as well. If you mean 
> something else, please let me know, what it was? Thanks.

[Ahmad]
The other option basically is to facilitate to the HA to communicate
Authorization request with the same server which performed the
EAP-Authentication (which also support AAA-MIP6), I understand that
requires maintaining a state at the AAA-EAP server and minor changes on
the HA side; What do you think, is that an option?

Thanks again.
Ahmad
> I assume that you mean the AAA-EAP signature is identical per 
> user per session. Right?
> On the other hand, could you please comment on the other 
> options I sent in response to Julien's options. Thanks.
> 
> Regards,
> Ahmad
>  
> 
> > Yes, this is what is needed, that is why I called this 
> "authorization 
> > token"
> > when raised the issue.
> form of an 
> > attribute to the AAA client (presumably the same as the HA, 
> although 
> > that is debatable too, if MSP and ASP are different), gets 
> to HA, and 
> > then forwarded to the AAAH-MIP through an attribute.
> assurance must be 
> > certified, i.e. a AAAH-EAP signature would be needed, 
> otherwise any HA 
> > or proxy can create that token and insert it in the attribute.
> signature, which 
> > means some trust relationship between AAAH-EAP and AAAH-MIP is 
> > required as well.