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 16:16:00 +0100

Hi Ahmad,

Just a couple of requirements:

2.7.3 
   Within a single session or transaction, it MUST be possible to
   interleave authentication, authorization and accounting AAA messages.

   This states, that e.g. a session may have to use initial
   authentication, authorization and accounting AAA message(s), but also
   have to include e.g. re-authentication every 30 minutes, or a
   continuous "drip-drip" of accounting AAA messages.

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.

But you can find several other places in the document where  authentication & authorization are bound.

BR,

Lionel

> -----Message d'origine-----
> De : Ahmad Muhanna [mailto:[email-masked]] 
> Envoyé : jeudi 25 janvier 2007 15:42
> À : MORAND Lionel RD-CORE-ISS; Yoshihiro Ohba
> Cc : Julien Laganier; [email-masked]
> Objet : RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: 
> Issue or notIssue ?
> 
> 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
> > 
> > > > 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 11:36:47 -0600

Hi Lionel,
Thanks for your response. Please see some comments inline.

Regards,
Ahmad

>    continuous "drip-drip" of accounting AAA messages.

[Ahmad]
This one is a little tricky. IMO, In the case of Authentication and Authorization separation, there will be authentication, authorization, and accounting for every session. DO you think otherwise? I do not see here that there is an indication that Authorization and Authentication needs to be combined again.

>    states that sometimes both types of information need to be 

[Ahmad]
I am not sure I can read this requirement as a requirement that when Authentication and Authorization are separated, Authorization messages MUST provide authentication too. Because if that was the intention, then this requirement does not make any sense. The second portion of it negate what the first portion already allowed to happen.
My interpretation is the Authentication and Authorization is fine and allowed, however, AAA protocols should give the option for integrated solution, i.e. Authentication and Authorization in the same message and at the same time.

In general, as long as RFC2609 ALLOWED the separation between Authentication and Authorization, it does not make sense to mandate integration in case separation option is adopted. Am I making some sense here.

> 
> But you can find several other places in the document where  
> authentication & authorization are bound.
> 
> BR,
> 
> Lionel
> 
> > De : Ahmad Muhanna [mailto:[email-masked]] Envoyé : jeudi 25 
> > janvier 2007 15:42 À : MORAND Lionel RD-CORE-ISS; Yoshihiro 
> Ohba Cc : 
> > Julien Laganier; [email-masked] Objet : RE: [Dime] Diameter 
> Mobile IPv6 
> > HA-to-AAAH Support:
> > Issue or notIssue ?
> > 
> > Hi Lionel,
> > Just for my education, could you please give me a pointer to which 
> > requirement you are referring in RFC2906.
> > Thanks.
> > 
> > >