Subject: AW: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.tx t

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 17 Feb 2005 14:34:01 +0100

hi all, 

let me try another attempt: 

the authentication and key exchange protocol will be run between two nodes
(eap peer and eap server, if we assume eap usage -- i think most people do).

now, since the eap peer and the eap server do not communicate directly with
each other (in most cases at least) we have in many cases another party in
the game. 

finally, there is yet another node that is target of the whole bootstrapping
procedure (if i assume that the end host is always the second target since
the established keying material is supposed to be known to two or more
parties).

please some note that some of these entities may not be physically
separated. 

now, how does your classification consider these three aspects? 

btw, i disagree that the protocol between the aaa server and the home agent,
.. etc. node does not need to be standardized. 

ciao
hannes

> Hi James, Ohba-san and all,
> 
> Let me add new point of view for classification of framework.
> (It does not mean that I disagree Alper's classification.)
> 
> I think that framework can be divided into 2 main branches as follows.
>  Type1: bootstrapping procedure is executed between MN and AAA server.
>  Type2: bootstrapping procedure is executed between MN and network
>         elements such as HA, NAS and DHCP server.
>         Those network elements can use back end AAA server.
> 
> In type 1, we assumed that MNs and AAA server communicate directly by
> using authentication protocol such as EAP and network elements are not
> required to understand MIP6 specific information. So, I don't 
> think that
> we are required to specify detailed interface between AAA and 
> MN because
> AAA in home network can assign configuration parameters in vendor
> specific attribute.
> 
>  Local domain  |    Home domain
>        NE      |      AAA
>                |       |
>         +--------------+
>         |      |
>         MN     |
> 
> In type2, we are required to specify interface. Because bootstrapping
> messages may be treated by network elements in local domain and AAA
> server in home network.
> I don't understand why problems are caused only in DHCP case.
> 
>     Local domain   |   Home domain
>        NE-------------------->AAA
>   (DHCP, HA, NAS)  |           |
>         |          |           NE
>         |          |           |
>        MN- - - - - - - - - - - +
>                    |
> 
> Could you give me comments?
> 
> Best Redards
> --Mayumi
> 
> > On Wed, Feb 16, 2005 at 01:19:42PM -0800, James Kempf wrote:
> > 
> >>Yoshi,
> >>
> >>
> >>>This seems to be a general problem that is common to any roaming
> >>>scenario, not specific to MIP6 bootstrapping scenario.  The IETF
> >>>already defines a similar framework for Mobile IPv4 
> bootstrapping with
> >>>having a MN-FA-AAA interface and I don't see a problem in 
> general (in
> >>>terms of complexity for roaming support) with replacing FA with
> >>>NAS/DHCP in the case of Mobile IPv6 bootstrapping.
> >>>
> >>
> >>Yes, but configuration is a different problem from network 
> access/mobility
> >>auth/authz.. The information distributed by any network 
> access/mobility
> >>roaming consists of a yes/no indication about whether 
> someone can enter the
> >>network, together with possibly a master key associated with that
> >>permission.
> >>
> >>What your draft is talking about is distributing detailed 
> configuration
> >>about the topology and services in the home administrative 
> domain. There is
> >>much more that can go wrong in that case.
> > 
> > 
> > So do you think that the existing solution for Mobile IPv4
> > bootstrapping is not a good solution to follow when 
> defining a Mobile
> > IPv6 bootstrapping solution?
> > 
> > 
> >>
> >>>>The other alternative is that the AAA-H itself 
> communicates with the
> >>
> >>AAA-F
> >>
> >>>>to obtain the local HA address, then sends it back in the 
> EAP reply. In
> >>
> >>that
> >>
> >>>>case, there is an additional round trip on the back end, 
> but, again
> >>
> >>there
> >>
> >>>>would be no need for the IKEv2 transaction if the EAP is used to
> >>
> >>configure
> >>
> >>>>the IPsec SA.
> >>>
> >>>But both of these would need to push IKE credentials of the MN from
> >>>the AAA server in the home domain to the local HA in the visited
> >>>domain, to avoid the second EAP run.  On the other hand, 
> if we allow
> >>>the delivery of IKE credentials to the local HA across 
> administrative
> >>>domains, I think we can certainly allow the framework of 
> carrying a HA
> >>>address to the local NAS/DHCP across administrative domains.
> >>>
> >>
> >>The difference is that the delivery is end to end, between 
> the MN and the
> >>AAA-H with EAP. So the security can be end to end, between 
> the home network
> >>operator and the client. If the NAS is in the middle, as in 
> your proposal,
> >>there is a weak point where compromise of security, or 
> network management
> >>problems are more likely to occur.
> > 
> > 
> > I don't understand the security threat because the HA address is
> > somehow exposed to the operator of the visited domain when the MN
> > sends a BU to the HA (I mentioned this several months ago).  Also I
> > don't understand the network management problems, because 
> even in the
> > end-to-end delivery model you mentioned above, some information such
> > as IKEv2 credentials would need to be passed to the local HA in the
> > visited domain from the home domain (it's not a pure end-to-end
> > delivery in that sense) in order for the MN to perform 
> IKEv2 with the
> > local HA without running EAP over IKEv2.  I really don't see a major
> > difference between managing IKEv2 credentials and managing 
> HA address
> > across administrative domains.
> > 
> > Regards,
> > 
> > Yoshihiro Ohba
> > 
> > 
> > 
> > 
> >>            jak
> >>
> >>
> > 
> > 
> > _______________________________________________
> > Mip6 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mip6
> > 
> 
> -- 
> 
> *++++++++++++++++++++++++++++++++++++++++++
> NTT Network Service Systems Laboratories
> Mayumi Yanagiya
> tel: +81 422 59 6783   fax: +81 422 59 5631
> E-mail: [email-masked]
> +++++++++++++++++++++++++++++++++++++++++++*
> 
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
> 

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