Subject: RE: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2)

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 03 Oct 2006 16:41:37 -0700

Hi Julien,

Sorry for responding late. I was making a point to go through all email up
to this point.

I definitely do not support option 1, since it does not make sense to make
MIP6 application depend on EAP application, first due to the spaghetti
application design process it creates, and second due to the fact that we
don't want to bind people to use EAP for MIP6 authentication.

Now to option 2, it is great that you are considering authorization and
authorization credentials as a separate matter than authentication. The
industry for years has failed to make that distinction. However, the current
option 2 is not strong from security and AAA design.

Yes, a Mobility service provider and its AAA server should look at the MN
and its service profile to see if it is authorized to use MIP6 service and
how it is supposed to pay for it. But we need to figure out what
"authorization credentials" to be used for this authorization. Now this
includes 
1) something that securely identifies the MN (this includes proof of
authentication)
2) something that proves MN's right to MIP6 service, i.e. an authorization
token or indication to a profile that the AAA server of MSP has of MN that
shows MN should have MIP6 service.

If you are separating authorization spec from authentication spec, then both
of these need to be included in the authorization spec.

The MN identity used MIP6 may or may not be the same as that used in a
previous EAP, especially in split scenario, so it seems that in split
scenario you run two EAPs, one with MN ASP ID and one with MN MSP ID. When
you produce a separate authorization spec ("Diameter MIP6 spec" separate
from "Diameter EAP spec"), you need make sure that 

1) MN uses the same ID during EAP and during MIP6?
2) even if it does, the MN's ID the MN is using is authenticated? There must
be a proof of a previous authentication. Just saying MN has run EAP before
it is not enough. When you are separating Diameter MIP spec and Diameter EAP
spec and taking authentication out, then the MIP spec needs to specify how
the MN provides proof that it has run a previous EAP (or another
authentication method) by probably signing its MIP6 authorization request
with a key that was generated during a previous EAP or authentication.
Otherwise, there is no way to know that the MN has actually been
authenticated, meaning it is very difficult to separate authorization from
authorization.

Having said that I am hesitant to state that support option 2 as well.
And yes, Update of 4072 should not affect update of MIP6 application.

Diameter MIP6 application needs to stand on its own and if it is going to
only define authorization and accounting and rely on a previous
authentication, then it must be independent of whether the authentication is
EAP or something else. We are not here to just solve a specific optimization
problem...

My two rusty (late) pennies,

Regards,

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:[email-masked]] 
Sent: Friday, September 15, 2006 3:21 AM
To: [email-masked]
Subject: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2)

Hi all,

 this is a new polling concerning the ha-aaah interface for the Mobile
 IPv6 Boostrapping. To date, at the previous one, there was a
 consensus on moving forward with a new App-ID. But, yoshi has
 proposed an interesting idea that should be considered by the WG.

 As you may recall, in the ha-aaah case, the MN is authenticated by
 EAP (IKEv2 is used between MN and the HA) and thus the HA-AAAH
 interface must, at least, be able to carry EAP packets. It appears that
 we now have 2 options:

 (1) We define a new Diameter application for Mobile IPv6 with a new
     App-ID that carry EAP packets as it is done in RFC 4072 (Diameter
     EAP) but Authorization and Accouting is specific to Mobile IPv6
     (thus the need for a new App-ID). The risk, as noted by yoshi, is
     that an update of the RFC4072 may result in an update of this
     application. 

 (2) We define a new Diameter Application for Mobile IPv6 but which is
     used for Authorization and Accounting. We continue to use
     Diameter EAP for the Authentication. Thus the HA will use
     Diameter EAP with the AVP Auth-Request-Type set to
     AUTHENTICATE_ONLY and then the HA will use this MIP6 Application
     for Authorization/Accounting of the Mobile IPv6 service. This new
     application will have its own App-ID.

     This would avoid to update the application if 4072 is updated and
     this could be a way to proceed if other applications need EAP for
     Authentication but have different needs for the Authorization and
     Accounting part.

 Please indicate wether you prefer (1) or (2).  

 As in the previous polling:
 - it might be useful to state a reason for your decision. 
 - indicate wether some aspects are still unclear to you.

 Regards,

 Julien

_______________________________________________
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: Wed, 4 Oct 2006 11:41:28 +0200

Hi madjid,

> of these need to be included in the authorization spec.

 that's indeed a good question. At this point of time, I thought that
 in the mip6-authz messages, we didn't need sort of "authz token". 
 I thought that the authentication process was implicit for the AAA-MIP6
 Authz server and that finally it was the HA which basically need to be
 sure that the MN is authenticated. 

 so my question: can't the AAA-MIP6 authz server assume that the MN has
 been authenticated while receiving an authz request ?

> 1) MN uses the same ID during EAP and during MIP6?

 Concerning Identity used in the MIP6 Authz process, we have two
 options:

 1/ The HA uses the Identity provided in the IDi field during the
 IKE_AUTH phase. In this case, the identity will be the same than the
 one provided with the Diameter EAP Application.

 2/ The HA uses something provided in the BU. In this case, it implies
 that the mip6-authz application is used after the whole EAP
 authentication process. This may not be possible if we want to do
 authorization of HoA allocation (cf. my thread on this subject).

> authenticated, meaning it is very difficult to separate authorization from

 well, as noted below, I tend to think that the Authz server doesn't
 need a proof that the MN has been authenticated. The Authz server
 could trust the HA for this.

 Julien

-- 
julien.bournelle at int-evry.fr

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 04 Oct 2006 16:30:12 -0700

Hi Julien,

Snip

 Madjid>>Traditionally, the authorization token is not an absolute
necessity, as long as there is a proof of a previous authentication and as
long as there is profile info in the MSP AAA server on the MN. However,
"authorization token" would provide a clean separation of authorization and
authentication. I say this because I have seen talk about having different
MIP6 and EAP servers on this list.

Madjid>>When it comes to security, you cannot assume anything:) If the
process depends on a previous authentication, then a proof of a previous
authentication needs to be provided. This could either be a key resulted
from a previous authentication signing the authorization request, or an
authorization token, IMO.
The other question I have after reading the split scenario doc is that you
guys are saying bootstrapping of some of MIP6 info (such as HoA) is done as
part of IKEv2 signaling. How can you then separate a Diameter MIP6
authorization from the IKEv2 authentication?

Madjid>>This could work, as long as the MSP AAA server recognizes the MN
with the same ID that the EAP server. Again, we need to very careful in
writing the spec, so that we avoid dependency of MIP6 spec on EAP spec, or
feasibility of MIP solution on a prior EAP run. That is why providing proof
for authentication or an authorization token is important, this way you know
what ID has been used before.
I still have the question as before: how do you do MIP6 HoA bootstrapping if
authn and authz are separated?

Madjid>>Yes, if the identity used during authz is different from that during
authn, then you have potential for identity fraud.

Madjid>> You seem to be making assumptions about HA here, i.e. HA knows
about the previous EAP and knows MN with that same identity. If this is
true, then the HA may have been provided with some info (a key or a token)
from the EAP/AAA server and then the HA can use that knowledge with the
MSP/AAA to show that MN has been authenticated. 

R,

Madjid

 Julien

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 5 Oct 2006 12:52:19 +0200

Hi madjid,

> MIP6 and EAP servers on this list.

 yes. as we are defining a new App for the Authz, the AAA-EAP and
 AAA-MIP6 may be different servers. But, from my point of view, as we
 are decoupling Authentication from the Authorization/Accounting
 process, the AAA-MIP6 does not need to authenticate again the MN. The
 HA is reponsible of this and it does so with 4072. 

> authentication needs to be provided. 

 well. I'm not sure about that. Basically, it is the HA which needs to
 ensure that the MN is correctly authenticated. The AAA-MIP6 is here
 just to check the profile.

 what do other think ?

> This could either be a key resulted

 the HA uses both 4072 and the Authz Application during the IKEv2
 exchange. 

> authn and authz are separated?

 do I answer to your question above ?

> about the previous EAP and knows MN with that same identity. 

 that's not a big assumption :).

> If this is

 I don't see how.. the AAA-MIP6 is not aware of this key.

 Julien

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 05 Oct 2006 07:55:26 -0400

Hi Madjid,

You are making a very good point.  I agree with you that
"authorization token" will make the architecture of separating
authentication and authorization securer.  I can imagine that this can
be easily achived based on: the AAA client requests the authentication
server to sign information that indicates that a particular MN was
authenticated by the server via a particular NAS at a certain data and
time using the server's public key and the authentication server
returns the signed information back to the AAA client.  The AAA client
can then present the signed information to the authorization server as
a proof of successful authentication of the MN by the authentication
server.

On the other hand, we can discuss whether this securer mechanism
should be mandatory or optional.  I prefer making such a mechanism
optional because AAA clients, authentication server and authorization
server are fairly trusted entities with each other in a particular
deployment.

Yoshihiro Ohba

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 5 Oct 2006 14:50:08 +0200

Hi yoshi,

> server are fairly trusted entities with each other in a particular

 I think that if
 we want such a mechanism, it should be better to define it in another
 document because it is would be a general mechanism that could be used
 by other authorization application.

 what do you think ?

 Julien

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 05 Oct 2006 10:04:27 -0400

Hi Julien, all

I agree with all of you that having a "authentication token" may be a 
way to "bind" that authentication with the authorization.

However, Julien made a good point: I don't think this mechanism is 
exclusive to MIP6 authz because it can be generally used when 
authorization and authentication are separately done  (typically with 
two AAA servers).

My 2 cents.

Julien Bournelle wrote:

>>>>If you are separating authorization spec from authentication spec, then
>>>>        
>>>>
>>>both
>>>      
>>>
>>>>2) even if it does, the MN's ID the MN is using is authenticated? There
>>>>        
>>>>
>>>must
>>>      
>>>
>>>>it is not enough. When you are separating Diameter MIP spec and Diameter
>>>>        
>>>>
>>>EAP
>>>      
>>>
>>>>authentication, then it must be independent of whether the authentication
>>>>        
>>>>
>>>is
>>>      
>>>
>>>>EAP or something else. We are not here to just solve a specific
>>>>        
>>>>
>>>optimization
>>>      
>>>
>>>>problem...
>>>>

-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: [email-masked]
------------------------------------------------------

---

From: "La Monaca Michele" <[email-masked]>
Date: Thu, 5 Oct 2006 18:50:27 +0200

Hi Madjid, all,

I'm quite new to this topic so forgive if my comments (in line) are misapplied.

> -----Messaggio originale-----
> Da: Madjid Nakhjiri [mailto:[email-masked]]
> Inviato: mercoledì 4 ottobre 2006 1.42
> A: 'Julien Bournelle'; [email-masked]
> Oggetto: RE: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2)
> 
> Hi Julien,
> 
> scenario you run two EAPs, one with MN ASP ID and one with MN MSP ID. 

> When you produce a separate authorization spec ("Diameter MIP6 spec" separate

My understanding is that four (possibly) different MN's identities are involved:

1) EAP access ID --> known only by AAAH (integrated scenario)
2) IKEv2 IDi --> known by AAAH and HA
3) EAP mip6 (outer) ID --> known by AAAH and HA
4) EAP mip6 (inner) ID --> known only by AAAH

Requisites:

- in an integrated scenario AAAH should be able to correlate 1) and 3) if different (but this is up to the AAAH, not our problem)

- the IDi provided by the MN must contain a valid @DOMAIN info since it is used to contact the right AAAH for the authentication, but we cannot count on this ID to uniquely identify a specific user between HA and AAAH, since the user part may be neither meaningful nor unique (e.g. FAKE_ID_BY_MN@DOMAIN)

- 4) is the only option I foresee to uniquely identify a specific user between HA and AAAH since HA could build a NAI like this UNIQUE_ID_BY_HA!FAKE_ID_BY_MN@DOMAIN for the EAP Response ID

- Then AAAH can easily bind UNIQUE_ID_BY_HA!FAKE_ID_BY_MN@DOMAIN ID provided by the HA with the EAP mip6 (inner) ID provided by the MN

> it is not enough. 
> When you are separating Diameter MIP spec and Diameter EAP

After the EAPoIKEv2 authentication, MN is implicitly authenticated since it holds an IPSec SA with the HA. 

My 2 cents,

--Michele

>  - indicate wether some aspects are still unclear to you.
--------------------------------------------------------------------

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: Yoshihiro Ohba <[email-masked]>
Date: Thu, 5 Oct 2006 19:00:04 -0400

Hi Julien,

I agree with you that such a token mechanism (if needed) is better
defined in a separate document.  On the other hand, actual AVPs that
are used for realizing the mechanism would need to be carried in each
application and thus each application specification would need to have
the AVPs in its ABNF.

Regards,
Yoshihiro Ohba

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 05 Oct 2006 17:27:43 -0700

-----Original Message-----
From: Julien Bournelle [mailto:[email-masked]] 
Sent: Thursday, October 05, 2006 3:52 AM
To: Madjid Nakhjiri
Cc: 'Julien Bournelle'; [email-masked]
Subject: Re: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2)

Hi madjid,

Madjid>>Ok, so the ongoing assumption is that AAA-MIP6 can be different from
AAA-EAP, and AAA-MIP6 is an authorization server that can authorize MN with
the ID the MN has presented to the HA and to the AAA_EAP. And the AAA-MIP6
trusts that the MN has authenticated through the HA. So the trust of MN is
transitive. This is a security consideration, see below.

 what do other think ?

Madjid>>So you are saying HA is fully trusted by AAA-MIP6? So AAA-MIP6 takes
HA's word for MN having been authenticated and if MN ends up not paying its
bill because HA lied or was compromised, then this should be covered in the
security consideration, then...

Madjid>>Ok, I guess the devil is in the details at this point:)
Are you saying some of the MIP6 bootstrapping (IKEv2 PSK for an MN-HA IPsec
SA? And HoA) is done during 4072? I will have to read some more..

.

Madjid>>Ok, I guess I was mixing split and integrated scenarios.

Julien

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 05 Oct 2006 17:41:52 -0700

I think we should be aware of the security implications and once the design
is done, if there are security considerations, assess whether they are
tolerable or not,

If they are, cover those in the related sections.
If they are not, solve the issue, which would be mandatory (otherwise the
issue would have been tolerable:) )

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:[email-masked]] 
Sent: Thursday, October 05, 2006 5:50 AM
To: Yoshihiro Ohba
Cc: Madjid Nakhjiri; 'Julien Bournelle'; [email-masked]
Subject: Re: [Dime] HA-AAAH case: auth. token ?

Hi yoshi,

 I think that if

 what do you think ?

 Julien

> > > scenario you run two EAPs, one with MN ASP ID and one with MN MSP ID.
When

---

From: Julien Bournelle <[email-masked]>
Date: Fri, 6 Oct 2006 12:19:32 +0200

Hi yoshi,

> application and thus each application specification would need to have

 yes, you're fully right. Moreover, we can imagine that mulitple
 mechanism are possible for this. So, before going into details we
 should analyse if we need that or not.

 Julien

---

From: Julien Bournelle <[email-masked]>
Date: Fri, 6 Oct 2006 12:29:06 +0200

Hi madjid,

On Thu, Oct 05, 2006 at 05:27:43PM -0700, Madjid Nakhjiri wrote:
> transitive. 

 right

> This is a security consideration, see below.
> 
> >  
> Madjid>>So you are saying HA is fully trusted by AAA-MIP6? 

 yes, we have a trust relationship since the HA is a Diameter client.

> So AAA-MIP6 takes
 As noted by Monica in her mail, if the HA does not authenticate the MN
 with 4072, we won't have IPsec SAs for mip6 service since the AUTH
 payload in IKEv2 is computed with the key delivered by the EAP server.

 Am I missing something ?

> SA? And HoA) is done during 4072? I will have to read some more..

 the key used for the AUTH payload comes from 4072.
 HoA should be delivered by the AAA-MIP6.

 Julien