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

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Tue, 23 Jan 2007 16:11:49 +0100

Hi Folks,

There is a new guy in the game ;)

After reviewing the draft and the mail exchange on the topic, I would say that the conclusion on "issue/no issue" depends on the side you are considering the problem (as often ;).

If you are considering the AAA-MIP6 as a "simple" database providing the HA with specific user/service information after a separate authentication (performed with Diameter authentication), the username conveyed over the HA/AAA-MIP6 is just used as a key entry in the database. There is no need for the AAA-MIP6 to authenticate this username or to be sure that the username was previously authenticated. The client of the database is the HA and not the user. In that case, the AAA-MIP6 has to trust the HA and it is up to the HA to authenticate the username provided by the mn during the SA set-up. This could be compared to interfaces between HSS (Home Subscriber Server) and SIP application servers defined in the 3GPP architecture, over which Diameter applications are used to access database.  

In this context, the HA may use:
1) the Diameter EAP application to authenticate the user.  
2) the Diameter MIP6 application to download user related service information
Authentication and authorization are performed by the AAA-EAP. But there is no way for the AAA-EAP to know what is the service requested by the user. Successful authentication implies implicte authorization. This is the problem with Diameter EAP as it is not possible to route Diameter EAP request to a service-specific EAP server.

In another hand, if the AAA-MIP6 is an authority handling MIP6 service access authorization rights i.e. the AAA-MIP6 must verify that the user is authorized to use the Mobile IPv6 service, this authority has to be able to verify the identity of the user before authorizing this user to access the service. It is not possible to authorize someone to do something without being sure of its identity as the authority must stand surety of the user access rights. Now, it is not possible to rely on the Diameter EAP application to perform the authentication procedure as there is no way to direct the Diameter EAP requests to a specifc EAP server (as the Diameter routing is based on App-Id and Realm). We might think about some specific things to link authentication procedures and authorization/service profile handling. But for me, the simpliest way would be to define the required authentication mechanism within one and only one application i.e. the application that requires this authentication. Therefore, Diameter EAP would not be used and application-specific commands would be specified in the application. One command pair would be added to the Diameter MIP6 application. And to support EAP, AVPs defined in 4072 would be at least (re-)used.

IMHO, the context described in the draft looks like more a service access authorization management than the use of a simple external database. I would be therefore in favor of defining authentication commands within the Diameter MIP6 application instead of trying to reuse the Diameter EAP application, which is not possible without modifications. EAP authentication and MIP6 service access authorization are performed with the same application. Since a application-Id is whatever needed for the HA/AAA-MIP6, what would be the benefit to look for solutions binding Diameter EAP and Diameter MIP6 (with some key derivation, etc.) while a single Diameter MIP6 application with intrinsic authentication commands would be fully appropriate?

I'm pretty sure that the content of this mail may be challenged line by line ;) But at the end, if authentication and authorization are needed to provide MIP6 services, why do not having a single application to do it? Of course, I don't say that it would not be possible to do something more complex...

BR,

Lionel

> -----Message d'origine-----
> De : Julien Laganier [mailto:[email-masked]] 
> Envoyé : mardi 23 janvier 2007 10:42
> À : Ahmad Muhanna
> Cc : [email-masked]
> Objet : Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: 
> Issue or notIssue ?
> 
> 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.)
> 
> _______________________________________________
> 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: "Gerardo Giaretta" <[email-masked]>
Date: Wed, 24 Jan 2007 08:56:56 +0100

Hi all,

I agree with Lionel. The proposal of having a split between
authentication and authorization was made by Yoshi in order to avoid
changes to 4072 and avoid duplicating functionality between Diameter
applications.

However, it seems that there are more drawbacks than benefits as
discussed in this month. And I don't see a strong issue in having the
MIP6 Diameter application supporting both authentication and
authorization. Note that if we want to add support for rfc4285, we'll
have to define an authentication application for MIP6 anyway.

Therefore my suggestion is: close the issue stating that the AAA
servers for authentication and authorization are co-located and that
the same application is used for both.

Does it sound good to everybody?

If not, I would like to hear strong motivations and benefits to have
the servers/application split since during these months I have not
heard any (a part from the documentation issue mentioned above).

--Gerardo

---

From: "Julien Bournelle" <[email-masked]>
Date: Wed, 24 Jan 2007 15:12:46 +0100

Hi all,

> Does it sound good to everybody?

 In order to move forward, I agree to go in this direction.

 Julien

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 24 Jan 2007 17:06:39 -0500

Hi Lionel,

> Authentication and authorization are performed by the AAA-EAP. But there is no way for the AAA-EAP to know what is the service requested by the user. Successful authentication implies implicte auth…

If AAA-MIP6 provides authorizatin, AAA-EAP provides authentication,
but does not provide authorization.  For this purpose, the HA needs to
set Auth-Request-Type set to AUTHENTICATE_ONLY in AAA-EAP.  In this
case, AAA-EAP server does not need to know what kind of authorization
will be made.  The authorization decision will be made by AAA-MIP6.
Am I missing something?

> In another hand, if the AAA-MIP6 is an authority handling MIP6 service access authorization rights i.e. the AAA-MIP6 must verify that the user is authorized to use the Mobile IPv6 service, this aut…

I don't understand the difference between the two cases you mentioned
above.  I believe that more or less the AAA servers need to trust the
HA in both cases.  Depending on threat model which we don't seem to
exactly know right now, the AAA-MIP6 server may or may not need an
evidence that the user has been authenticated by a AAA-EAP server.

> IMHO, the context described in the draft looks like more a service access authorization management than the use of a simple external database. I would be therefore in favor of defining authenticati…

I don't understand what is the point of discussing "service access
authorization management" and "simple external database".  If MIP6
application needs to support multiple authentication methods such as
EAP and RFC 4285, I believe it is more appropriate to consider
separation of authentication and authorization if security is
reasonably handled.  Also, there is some authentication method (e.g.,
authentication based on IKEv2-cert without using EAP) does not require
any AAA interacation for authentication.  I was pointing this out
several times but no one seems to pay attention to it.

> I'm pretty sure that the content of this mail may be challenged line by line ;) But at the end, if authentication and authorization are needed to provide MIP6 services, why do not having a single a…

To me, discussion on coupling vs. decoupling authentication and
authorization is not just a MIP6 issue.  This is a fundamental
discussion that will decide the future direction of AAA.

Yoshihiro Ohba

---

From: Julien Laganier <[email-masked]>
Date: Thu, 25 Jan 2007 16:25:46 +0100

Hi Yoshi, Lionel, Folks,

Cutting quite a lot thru the message:

On Wednesday 24 January 2007 23:06, Yoshihiro Ohba 
wrote:
> If AAA-MIP6 provides authorizatin, AAA-EAP provides
> authentication, but does not provide authorization. 
> For this purpose, the HA needs to set
> Auth-Request-Type set to AUTHENTICATE_ONLY in
> AAA-EAP.  In this case, AAA-EAP server does not need
> to know what kind of authorization will be made. 
> The authorization decision will be made by AAA-MIP6.
> Am I missing something?

Agree.

[...]

> I don't understand what is the point of discussing
> "service access authorization management" and
> "simple external database".  If MIP6 application
> needs to support multiple authentication methods
> such as EAP and RFC 4285, I believe it is more
> appropriate to consider separation of authentication
> and authorization if security is reasonably handled.
>  Also, there is some authentication method (e.g.,
> authentication based on IKEv2-cert without using
> EAP) does not require any AAA interacation for
> authentication.  I was pointing this out several
> times but no one seems to pay attention to it.

I think at the minimum standardized MIPv6 MN-HA 
authentication schemes MUST be supported.

This includes the simplest scheme where MN and HA use a 
static shared key for ESP (in addition to IKE-based 
schemes you are mentioning).

It would also be consistent with the last sentence of 
provision 2.2.6 of AAA Authorization Requirements 
(RFC2906)

   AAA protocols MUST be capable of leveraging any
   underlying peer entity authentication mechanisms
   that may have been applied - this MAY provide
   additional assurance that the owner of the 
   authorization information is the same as the
   authenticated entity.  For example, if IPSec
   provides sufficient authentication, then it must be
   possible to omit AAA protocol authentication.

> > I'm pretty sure that the content of this mail may
> > be challenged line by line ;)

Can we? :)

> > But at the end, if authentication and authorization
> > are needed to provide MIP6 services, why do not
> > having a single application to do it? 

Modularity. Allow for the different authentication 
mechanisms (EAP/AAA, IKE, ESP w/ static key) to be 
leveraged on.
 
> > Of course, I don't say that it would not be
> > possible to do something more complex...

Modular solutions usually makes things more simple by 
decoupling aspects of a problem which are 
independents.

> To me, discussion on coupling vs. decoupling
> authentication and authorization is not just a MIP6
> issue.  This is a fundamental discussion that will
> decide the future direction of AAA.

Agree completely.

Best,

--julien

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 29 Jan 2007 16:20:51 -0800

Hi Lionel,

Thanks for the nice break down of the problem that arises from separation of
Authentication and authorization. You may be new in the game, but you
certainly started a juicy thread.

The problem is that AAA-MIP6 is seen as a database operation on the user
profile to do authorization. I actually go further than you and say heck if
the AAA-MIP6 authorization process is separate from the authentication, then
why even bother to use the same identity? We are not checking the
authentication state, so we might as well use two different identities for
AAA-EAP and AAA-MIP6 (I hope people realize the sarcasm here).

And yes, when AAA-MIP6 and AAA-EAP are separate, as you mentioned the
AAA-EAP just does EAP authentication and has no idea about future service
requests including those for MIP6 service and this creates another issue.
Once Hokey WG defines the method for using EAP MSK/EMSK to generate keys for
MIP6 and so on, the AAA-EAP actually needs to create the keying material for
MIP6, while it has no idea about MIP6 service, since that service is being
authorized by AAA-MIP6.

I personally am on the fence on one versus two applications. The easiest way
out is to define one application that re-uses EAP. The more grand way is to
allow for separation of Authentication and authorization, but then we have
to take care of the arising issues, which are:

1) AAA-MIP6 making sure MN is authenticated.
2) AAA-EAP getting access to service data to create MIP6 keys.

Having debating this for so long, we have written a draft that tries to
tackle the issues. The main idea is to use the initial Authentication
(either MN or AAA-EAP, but not HA) to create an verifiable assurance of the
authentication to the AAA-MIP and define an interaction between AAA-MIP and
AAA-EAP to get MIP6 key material. There are some other bells and whistles
such as the Authentication ID that could help the future AAA work (as Yoshi
mentioned), where you can have separate authentication and authorization
servers 

http://www.ietf.org/internet-drafts/draft-nakhjiri-dime-mip6-nsi-00.txt

Regards,

Madjid

-----Original Message-----
From: MORAND Lionel RD-CORE-ISS [mailto:[email-masked]] 
Sent: Tuesday, January 23, 2007 7:12 AM
To: Julien Laganier; Ahmad Muhanna
Cc: [email-masked]
Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or
notIssue ?

Hi Folks,

After reviewing the draft and the mail exchange on the topic, I would say
that the conclusion on "issue/no issue" depends on the side you are
considering the problem (as often ;).

If you are considering the AAA-MIP6 as a "simple" database providing the HA
with specific user/service information after a separate authentication
(performed with Diameter authentication), the username conveyed over the
HA/AAA-MIP6 is just used as a key entry in the database. There is no need
for the AAA-MIP6 to authenticate this username or to be sure that the
username was previously authenticated. The client of the database is the HA
and not the user. In that case, the AAA-MIP6 has to trust the HA and it is
up to the HA to authenticate the username provided by the mn during the SA
set-up. This could be compared to interfaces between HSS (Home Subscriber
Server) and SIP application servers defined in the 3GPP architecture, over
which Diameter applications are used to access database.  

In this context, the HA may use:
1) the Diameter EAP application to authenticate the user.  
2) the Diameter MIP6 application to download user related service
information
Authentication and authorization are performed by the AAA-EAP. But there is
no way for the AAA-EAP to know what is the service requested by the user.
Successful authentication implies implicte authorization. This is the
problem with Diameter EAP as it is not possible to route Diameter EAP
request to a service-specific EAP server.

In another hand, if the AAA-MIP6 is an authority handling MIP6 service
access authorization rights i.e. the AAA-MIP6 must verify that the user is
authorized to use the Mobile IPv6 service, this authority has to be able to
verify the identity of the user before authorizing this user to access the
service. It is not possible to authorize someone to do something without
being sure of its identity as the authority must stand surety of the user
access rights. Now, it is not possible to rely on the Diameter EAP
application to perform the authentication procedure as there is no way to
direct the Diameter EAP requests to a specifc EAP server (as the Diameter
routing is based on App-Id and Realm). We might think about some specific
things to link authentication procedures and authorization/service profile
handling. But for me, the simpliest way would be to define the required
authentication mechanism within one and only one application i.e. the
application that requires this authentication. Therefore, Diameter EAP would
not be used and application-specific commands would be specified in the
application. One command pair would be added to the Diameter MIP6
application. And to support EAP, AVPs defined in 4072 would be at least
(re-)used.

IMHO, the context described in the draft looks like more a service access
authorization management than the use of a simple external database. I would
be therefore in favor of defining authentication commands within the
Diameter MIP6 application instead of trying to reuse the Diameter EAP
application, which is not possible without modifications. EAP authentication
and MIP6 service access authorization are performed with the same
application. Since a application-Id is whatever needed for the HA/AAA-MIP6,
what would be the benefit to look for solutions binding Diameter EAP and
Diameter MIP6 (with some key derivation, etc.) while a single Diameter MIP6
application with intrinsic authentication commands would be fully
appropriate?

I'm pretty sure that the content of this mail may be challenged line by line
;) But at the end, if authentication and authorization are needed to provide
MIP6 services, why do not having a single application to do it? Of course, I
don't say that it would not be possible to do something more complex...

BR,

Lionel

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 29 Jan 2007 16:26:44 -0800

Hi Gerardo,

This is a good short term solution for solving parts of the current MIPv6
split scenario problems. I don't see why we need to change 4072, when we are
using its AVPs? If you define a new Diameter MIP6 application, all the 4285
needs is probably to add AVPs to the same application, possibly through a
separate RFC (if the AVPs don't come in time:)).

However, in the long term, I think it is good to investigate how
authentication and authorization can be dealt with separate, this will
probably as Yoshi mentioned be the way to go in the future. We can deal with
that in a separate context. I am hoping that our draft

can shed some light on the issues.

Regards,

Madjid

-----Original Message-----
From: Gerardo Giaretta [mailto:[email-masked]] 
Sent: Tuesday, January 23, 2007 11:57 PM
To: MORAND Lionel RD-CORE-ISS
Cc: [email-masked]; Julien Laganier
Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or
notIssue ?

Hi all,

--Gerardo

>
> If you are considering the AAA-MIP6 as a "simple" database providing the
HA with specific user/service information after a separate authentication
information
> Authentication and authorization are performed by the AAA-EAP. But there
is no way for the AAA-EAP to know what is the service requested by the user.
Successful authentication implies implicte authorization. This is the
problem with Diameter EAP as it is not possible to route Diameter EAP
request to a service-specific EAP server.
>
> I'm pretty sure that the content of this mail may be challenged line by
line ;) But at the end, if authentication and authorization are needed to
provide MIP6 services, why do not having a single application to do it? Of
course, I don't say that it would not be possible to do something more
complex...