Subject: RE: [Dime] HA-AAAH case: auth. token ?

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 6 Oct 2006 01:08:31 -0400

I concur with Julien. If such a "securer" mechanism needs to be defined
to tie the authentication step with the authorization step, it should be
defined as a generic solution in a separate document. 

-Kuntal

> -----Original Message-----
> From: Julien Bournelle [mailto:[email-masked]]
> Sent: Thursday, October 05, 2006 7:50 AM
> To: Yoshihiro Ohba
> Cc: [email-masked]
> Subject: Re: [Dime] HA-AAAH case: auth. token ?
> 
> Hi yoshi,
> 
> On Thu, Oct 05, 2006 at 07:55:26AM -0400, Yoshihiro Ohba wrote:
> >
> > 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.
> 
>  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
> 
> >
> > Yoshihiro Ohba
> >
> >
> > On Wed, Oct 04, 2006 at 04:30:12PM -0700, Madjid Nakhjiri wrote:
> > > Hi Julien,
> > >
> > > Snip
> > >
> > > > 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.
> > >
> > >  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.
> > >
> > >  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.
> > >
> > > so my question: can't the AAA-MIP6 authz server assume that the MN
has
> > >  been authenticated while receiving an authz request ?
> > >
> > > 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?
> > >
> > > > 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?
> > >
> > >  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.
> > >
> > > 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?
> > >
> > >  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).
> > >
> > > Madjid>>Yes, if the identity used during authz is different from
that
> during
> > > authn, then you have potential for identity fraud.
> > >
> > > > 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.
> > >
> > >  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.
> > >
> > > 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
> > >
> > > > 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
> > > >
> > > >
> > >
> > > --
> > > julien.bournelle at int-evry.fr
> > >
> > >
> > >
> > > _______________________________________________
> > > DiME mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/dime
> > >
> 
> --
> julien.bournelle at int-evry.fr
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime

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