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

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Thu, 25 Jan 2007 12:11:23 +0100

Hi Yoshi,

1) If authentication procedures may be performed apart from authorization procedures (I totally agree), authorization procedures must be able to rely on its own authentication procedures if needed (cf. AAA requirements in RFC 2906). Are you OK with that?

2) As it is now, providing authentication with Diameter EAP application and authorization with Diameter MIP6 does not allow the AAA-MIP6 to be sure that the username carried in the authorization request was previously authenticated by the AAA-EAP. Are you OK with that?

3) If the AAA-MIP6 provides the HA with service related information without being sure that the key entry (username) was previously authenticated, what is the difference between the AAA-MIP6 and a "simple" external database providing information data to any authorized entity (HA in the present case)? What/where is the authorization process in that case?

4) If combining Diameter EAP and Diameter MIP6 is more complex than including authentication procedures with Diameter MIP6 that is coherent with AAA requirements, why are we still discussing as much? ;)

5) If the discussion is beyond the scope of the draft and related to the future of global AAA framework, why do not "decouple" the discussions and create a separate thread? But for now, I can see that a Diameter MIP6 application with authentication procedure would be consistent with the current AAA framework while a combinaison of Diameter EAP and Diameter MIP6 will not meet all the AAA requirements without introducing specific functionalites/enhancements.

I would have no problem with a solution proposing EAP authentication procedures and MIP6 authorization procedures supported by to different diameter applications IF it could be possible to bind both procedures in the same equipment in the MSA. That is not the case with the current solution.

BR,

Lionel

> > 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.
> 
> 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 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.
> 
> 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 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 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 application to do it? Of course, I don't 
> say that it would not be possible to do something more complex...
> 
> 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
> 
> > 
> > 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
> > 
> > 
> 

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 25 Jan 2007 08:41:35 -0600

Hi Lionel,
Please see some one comment inline.

Regards,
Ahmad

> -----Original Message-----
> From: MORAND Lionel RD-CORE-ISS 
> [mailto:[email-masked]] 
> Sent: Thursday, January 25, 2007 5:11 AM
> To: Yoshihiro Ohba
> Cc: Julien Laganier; Muhanna, Ahmad (RICH1:2H10); [email-masked]
> Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: 
> Issue or notIssue ?
> 
> Hi Yoshi,
> 
> 1) If authentication procedures may be performed apart from 
> authorization procedures (I totally agree), authorization 
> procedures must be able to rely on its own authentication 
> procedures if needed (cf. AAA requirements in RFC 2906). Are 
> you OK with that?

[Ahmad]
Just for my education, could you please give me a pointer to which requirement you are referring in RFC2906.
Thanks.

> 
> 2) As it is now, providing authentication with Diameter EAP 
> application and authorization with Diameter MIP6 does not 
> allow the AAA-MIP6 to be sure that the username carried in 
> the authorization request was previously authenticated by the 
> AAA-EAP. Are you OK with that?
> 
> 3) If the AAA-MIP6 provides the HA with service related 
> information without being sure that the key entry (username) 
> was previously authenticated, what is the difference between 
> the AAA-MIP6 and a "simple" external database providing 
> information data to any authorized entity (HA in the present 
> case)? What/where is the authorization process in that case?
> 
> 4) If combining Diameter EAP and Diameter MIP6 is more 
> complex than including authentication procedures with 
> Diameter MIP6 that is coherent with AAA requirements, why are 
> we still discussing as much? ;)
> 
> 5) If the discussion is beyond the scope of the draft and 
> related to the future of global AAA framework, why do not 
> "decouple" the discussions and create a separate thread? But 
> for now, I can see that a Diameter MIP6 application with 
> authentication procedure would be consistent with the current 
> AAA framework while a combinaison of Diameter EAP and 
> Diameter MIP6 will not meet all the AAA requirements without 
> introducing specific functionalites/enhancements.
> 
> I would have no problem with a solution proposing EAP 
> authentication procedures and MIP6 authorization procedures 
> supported by to different diameter applications IF it could 
> be possible to bind both procedures in the same equipment in 
> the MSA. That is not the case with the current solution.
> 
> BR,
> 
> Lionel
> 
> > 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.
> > > 
> > 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.
> > 
> > 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?
> > 
> > > 
> must verify 
> > that the user is authorized to use the Mobile
> 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 
> 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
> 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.
> > 
> > > 
> > 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 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 
> > 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...
> > 
> > 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
> > 
> > > 
> > > BR,
> > > 
> > > Lionel
> > > 
> > >

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 25 Jan 2007 11:23:11 -0500

Hi Lionel,

> 1) If authentication procedures may be performed apart from authorization procedures (I totally agree), authorization procedures must be able to rely on its own authentication procedures if needed…

I am not sure which requirement in RFC 2906 you are reffering to, but
let me quote some text in RFC 2906 relating to relationship between
authentication and authorization:

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

2.2.8   AAA protocols MUST be usable even in environments where no peer
   entity authentication is required (e.g. a network address on a secure
   LAN may be enough to decide).

2.9.1   Authorization separate from authentication SHOULD be allowed
   when necessary, but the AAA protocols MUST also allow for a single
   message to request both authentication and authorization.

   AAA protocols have to allow a split between authentication and
   authorization so that different mechanisms are used for each. This
   states that sometimes both types of information need to be carried in
   the same message.

3. Security Considerations

   This document includes specific security requirements.

   This document does not state any detailed requirements for the
   interplay with authentication, accounting or accountability (audit).
   A AAA protocol, which meets all of the above requirements, may still
   leave vulnerabilities due to such interactions. Such issues must be
   considered as part of AAA protocol design.
"

> 2) As it is now, providing authentication with Diameter EAP application and authorization with Diameter MIP6 does not allow the AAA-MIP6 to be sure that the username carried in the authorization re…

It depends on threat model as Julien Laganier mentioned.  In my
personal opinion, if AAA clients and servers trust each other, and the
assurance of binding between authorization and authentication is made
by the AAA clients, I don't think we need a special mechanism.

> 3) If the AAA-MIP6 provides the HA with service related information without being sure that the key entry (username) was previously authenticated, what is the difference between the AAA-MIP6 and a…

I don't see a difference between the two.  In both cases, authorization 
decision is made by AAA-MIP6.

> 4) If combining Diameter EAP and Diameter MIP6 is more complex than including authentication procedures with Diameter MIP6 that is coherent with AAA requirements, why are we still discussing as muc…

Including authentication procedures with Diameter MIP6 will be more
complex if we need to support multiple authentication methods (EAP and
non-EAP) within a single application.  Also, Diameter EAP application
may be revised due to new work such as HOKEY.  If we include EAP
within Diameter MIP6, Diameter MIP6 would need to duplicate the same
revision in its specification.  Isn't it a mess?

Also, what happens if we need to suppport QoS for MIP6?  Do you want
to include QoS support in MIP6 application, or do you want to include
MIP6 support in Diameter QoS application, or do you want to decouple
QoS and MIP6?

> 5) If the discussion is beyond the scope of the draft and related to the future of global AAA framework, why do not "decouple" the discussions and create a separate thread? But for now, I can see t…

Can you elaborate on which AAA requirements will not be met?

> I would have no problem with a solution proposing EAP authentication procedures and MIP6 authorization procedures supported by to different diameter applications IF it could be possible to bind bot…

It is possible by just routing the two different applications to
the same server.

Yoshihiro Ohba

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 25 Jan 2007 13:04:22 -0600

All,
cutting some text for clarity. One comment below from an old posting which is attached. 

Regards,
Ahmad
 
> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Thursday, January 25, 2007 10:23 AM
> To: MORAND Lionel RD-CORE-ISS
> Cc: Yoshihiro Ohba; Julien Laganier; Muhanna, Ahmad 
> (RICH1:2H10); [email-masked]
> Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: 
> Issue or notIssue ?
> 
> > 
> It is possible by just routing the two different applications 
> to the same server.
>

[Ahmad]
This was one of the suggestions that I proposed after reviewing the draft, cutting and pasting from the original email which is attached:

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

> > > 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
> authenticate 
> EAP as it 
> > > is not possible to route Diameter EAP request to a 
> service-specific 
> > > EAP server.
> > > 
> 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?
> > > 
> > > > 
> > > MIP6 service access authorization rights i.e. the AAA-MIP6 must 
> > > verify that the user is authorized to use the Mobile
> 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 
> 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.
> 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.
> > > 
> > > 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.
> > > 
> > > > 
> > > 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 application with intrinsic authentication commands 
> > > would be fully appropriate?
> > > 
> > > 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.
> > > 
> > > > 
> 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...
> > > 

Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split
From: "Muhanna, Ahmad \(RICH1:2H10\)" <[email-masked]>
To: "Julien Bournelle" <[email-masked]>
Cc: <[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.
> 
> 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.

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

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

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

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

> 
>  3/ We define a generic mechanism that permits to give a proof to the
> 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.

> 
>  Comments ?
> 
> 
>  Let me know if you see others options.
> 
>  Julien
> 
> 
> 
> >
> >
> > Regards,
> > Ahmad
> >
> >
> > > 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).
> > >
> > >