Subject: [Mip6] AW: a few comments on <draft-giaretta-mip6-aaa-ha-goals-00.txt>

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 21 Apr 2005 23:34:48 +0200

hi gerardo, 

thanks for your comments. 
please see my reponse below: 

> -----Ursprüngliche Nachricht-----
> Von: Gerardo Giaretta [mailto:[email-masked]] 
> Gesendet: Freitag, 8. April 2005 11:05
> An: Tschofenig Hannes
> Cc: [email-masked]
> Betreff: RE: a few comments on 
> <draft-giaretta-mip6-aaa-ha-goals-00.txt>
> 
> 
> Hi Hannes,
> 
> thanks for your comments and sorry for the delay of my response.
> Please see my comments below...(ccing also mip6 ML)
> 
> > 
> > hi gerardo, 
> > 
> > i have finally read your draft 
> > <draft-giaretta-mip6-aaa-ha-goals-00.txt>. 
> > 
> > here are a few comments: 
> > 
> > - avoid the usage of trust. this is just a very difficult 
> > term with many
> > different meanings. use security association instead. 
> > 
> >    The basic security model behind this draft assumes that 
> the mobile 
> >    node shares credentials with the AAA server 
> >    of the MSP (AAAH), as stated in [2]. Furthermore the HA is 
> > expected 
> >    to have a security association with the AAAH server (see 
> > Figure 1). 
> >     
> >  
> >                      MN               AAAH              HA 
> >                      ^                ^  ^               ^ 
> >                      |                |  |               | 
> >                      +----------------+  +---------------+ 
> >                     Security Association  Security Association 
> >                        [or Credential]
> > 
> >                           Figure 1 - Basic Model 
> >     
> > i know that the mip6 bootstrapping problem statement document 
> > also uses the
> > term extensively. i also dislike it there. 
> 
> I tried to use the same terminology adopted in the problem statement
> draft in order to keep them coherent. This is the definition of trust
> relationship in the last version of PS draft:
> 
>    Trust relationship
>       In the context of this draft, trust relationship means that two
>       parties in question, typically the user of the mobile 
> host and the
>       mobility or access service provider, have some sort of prior
>       contact in which the mobile host was provisioned with 
> credentials.
>       These credentials allow the mobile host to authenticate 
> itself to
>       the mobility or access service authorizer and to prove its
>       authorization to obtain service.
> 
> Which are your concerns with the usage of this terminology in these
> drafts with regards to this particular definition? 

my impression is that use misuse the term trust relationship to define
something else. 
in fact it is not really a definition but rather an example. btw, i disliked
this definition already in the problem statement draft. 

i use the following definition for trust relationship: 

a trust relationship denotes a mutual a priori relationship
   between the involved organizations or parties where the parties
   believe that the other parties will behave correctly even in the
   future.

> 
> > i am not sure whether people are willing to revise the 
> > bootstrapping ps
> > document. i re-read it and came across a few things i would 
> > like to see
> > modified. 
> > 
> 
> I guess there is still space to change the mip6 bootstrapping problem
> statement document. Alpesh is still working on it.
> It seems that this issue is mainly related to mip6 bootstrapping PS
> draft. My idea for draft-giaretta-mip6-aaa-ha-goals is to keep the
> terminology of the PS draft. So, no problem for me to change the
> terminology here but only if it is changed also in the PS draft.
ok. then i will just submit my comments for the bootstrapping document as
well. 

> 
> > - Scenario 4 is not quite clear to me. it does not seem to 
> > help with most of
> > the bootstrapping actions. 
> > authorization based on the location (whatever location means 
> > here) seems to
> > be difficult. actually i do not know whether you use the term 
> > location as
> > discussed in <draft-ietf-geopriv-radius-lo-02.txt> or as i 
> > moved to a new
> > location and got a new ip address. just two different things. 
> > 
> 
> Scenario 4 is not related to dynamic bootstrapping. The point is:
> suppose the MN is statically provisioned with the HA address 
> and the HoA
> and has a manually configured SA with its HA. In this scenario, how do
> you perform the authorization procedure? The location of the 
> MN (in the
> sense that it has moved to a new location and got a new IP 
> address) was
> just an example; another could be the time of the day or whatever else
> can be in the user profile.
> 
> Do you think that this scenario is not to be considered? 

i got confused by the fact that you have everything pre-configured and then
you have a problem with authorization since you do not perform the
authorization based on the pre-established credentials and the configuration
parameters but on something else that demands interaction with the aaa
infrastructure. 

> 
> > - regarding:
> > "
> >   G2.1 The AAA-HA interface should allow the use of Network Access 
> >         Identifier (NAI) to identify the mobile node. 
> > "
> > 
> > typically the nai is used to identify the entity that can be 
> > associated with
> > a legal person. 
> > in fact it would be good to describe this aspect in more 
> > detail. i haven't
> > found a good discussion of this topic somewhere in the 
> > literature. maybe
> > someone else can point me to some literature. 
> > 
> 
> The assumption in the draft is that there is a one-to-one matching
> between the user and the MN. Do you see a possible issue in 
> identifying
> the user/MN with the NAI in the communication between the AAAH and the
> HA?

wouldn't it be better to just say that the nai is used to associate a user. 

(which is even not fully correct if you consider pre-paid cards but that's
problably a difficult issue to get the text truely right.)

> 
> 
> > - regarding:
> > 
> > "
> >    G2.3 The AAAH server should be able to enforce explicit 
> > operational 
> >         limitations and authorization restrictions on the HA (e.g. 
> >         packet filters, QoS parameters). 
> > "
> > 
> > could you elaborate a little bit more what you would like to 
> > accomplish with
> > this requirement?
> > 
> 
> The HA is an anchor point, at least for bidirectional tunneling. For
> this reason an operator might want to install policies on MN's traffic
> exploiting that all bidirectional data is tunneled through the HA.

hmm. this is not what i read from the requirement. you explanation seems to
say that the aaah should dictate the usage of bi-directional tunneling. 
i got the impression that you would like to install packet filters and to
perform a qos reservation. this would be interesting for our work with the
diameter qos application. 

> 
> > - regarding:
> > 
> > "
> >    G2.2 The HA should be able to query the AAAH server to verify 
> >         Mobile IPv6 service authorization for the mobile node. 
> > "
> > 
> > what is the idea? query without triggering any actions? 
> > 
> 
> This is mainly related to scenarios 3 and 4. The HA, after receiving a
> BU or during the IKE exchange, could get in touch with the 
> AAAH in order
> to authorize the user. Based on the response from the AAAH, the HA can
> grant Mobile IPv6 service to the MN.
> 
> This might also be relevant for scenario 1. However, in this case the
> AAA-HA communication is used also to authenticate the user.

the aaa server is asked to perform authorization by relying on the
authentication provided to the home agent. 

> 
> 
> > - regarding:
> > 
> > "
> >    G2.2 The HA should be able to query the AAAH server to verify 
> >         Mobile IPv6 service authorization for the mobile node. 
> > "
> > what state would you like to retrieve? what should the aaah 
> > do with the
> > state? 
> > 
> 
> I think you are referring to goal G2.7.
> 
true - copy-and-paste problem 

> "
> G2.7	The AAAH server should be able to retreive the Mobile IPv6 state
> associated to a specific MN from the correspondent HA. This may be
> useful to periodically verify the Mobile IPv6 service status.
> "
> 
> Suppose that the AAA architecture of the MSA/MSP is stateless and the
> AAA server that handles MN re-authentications changes over time. If
> bootstrapping is performed during network access, how the AAA server
> knows that the MN is already registered with that HA? A possible
> approach could be: the MN tells the AAA infrastructure that 
> it is using
> a particular HA and the AAA server verifies the MN's state on that HA.
> See draft-giaretta-mip6-authorization-eap-02, section 5.2 for details.

i will re-visit draft-giaretta-mip6-authorization-eap-02 with regard to this
issue but i have the impression that this is a somewhat fancy feature and i
am not sure whether it is really needed. 

let me come back to this issue. 

> 
> 
> > - regarding:
> > 
> > "
> >    G5.1 The AAAH server should be able to poll the 
> designated HA for 
> >         the allocation of a Home Address to the MN. Optionally, the 
> >         AAAH server can provide a set of hints for the 
> > construction of 
> >         the Home Address (e.g. a preferred Home Address or a 
> > preferred 
> >         Interface Identifier). 
> > "
> > 
> > how would the message flow for this interaction look like?
> > i only see two options here: 
> >  * the ha selects one (and then it might not be necessary to 
> > communicate it
> > to the aaa server)
> >  * the aaah selects one. 
> > why do you see the need for polling?  
> >  
> 
> this goal is related to scenario 2. The MIPv6 bootstrapping 
> is performed
> during network access authentication communicating with the AAAH. In
> this case the MN does not communicate directly with the HA. For this
> reason, it is the AAAH that has to send the HoA to the MN. As you
> mention one possibility is that the AAAH selects one HoA by its own.
> However, my idea is that it is better that the HA allocates the HoA
> since it has the most updated vision on the addresses allocated in its
> link (e.g. it could have a list of HoAs already taken).

i see. 

> 
> > this question also relates to the next requirement, regarding:
> > "   
> >    G5.2 The HA should be able to communicate to the AAAH server the 
> >         Home Address allocated to the MN. 
> > "
> > 
> > what would the aaah do with the home address? 
> > 
> 
> As mentioned above, the AAAH sends the HoA to the MN in 
> scenario 2, but
> the HoA is selected by the HA.

same as above. 

> 
> > - regarding 
> > 
> > "
> >    G5.3 The AAAH server should be able to send to the HA 
> the security 
> >         data needed to setup the IPsec SA between the MN 
> and the HA. 
> >         Possible security data are the authentication 
> method and the 
> >         cryptographic material to be used for IKE bootstrapping. 
> > "
> > 
> > i think this section should talk only about the ikev2 
> > pre-shared secret
> > (maybe ikev1). maybe you want to provide a solution for the 
> mip6-auth
> > protocol (but i am not sure). 
> > 
> 
> This refers to:
> - PSK for IKEv2
> - PSK and peer authentication method for IKEv1 Phase 1
> 
> Moreover, we'd like to keep the requirements a bit general in order to
> address also mip6-auth if it will be necessary.

it might be sufficient to have this information implicit in the exchange. i
do not think that the home agent will implement all three protocols and is
suddenly configured to use one protocol for user a and another one for user
b. 

> 
> > for ikev2 there are not further parameters that need to be 
> > provided since
> > there are no further options that can be specified. 
> > 
> 
> agree. Different for IKEv1, though.
true, if it is important at all.

i remember the discussions about considering ikev1 as well but i wasn't sure
whether there is large interest. 
 
> 
> > one thing to discuss would be the issue of the identity used for
> > authentication. you might for user identity confidentiality 
> > reasons want to
> > use one identity during the bootstrapping procedure and 
> > another one for mip6
> > usage. 
> > 
> 
> could you please elaborate this point? don't you think this is more
> related to the bootstrapping solution discussion?
for some of the scenarios i had the impression that it is not necessary to
use the same identity for bootstrapping and for subsequent mip6 usage. 
in the bootstrapping you might want to use a nai (particularly in the
context of an eap protocol run). as a result of the bootstrapping you
create, for example, a shared secret for ikev2. subsequently, you use ikev2
to create the ipsec sa to protect mipv6 signaling. what identity do you use
to identify the pre-shared secret? do you use the nai again or something
else? 

ciao
hannes

> 
> 
> Ciao,
> --Gerardo
> 
> > ciao
> > hannes
> > 
> 
> 
> Gruppo Telecom Italia - Direzione e coordinamento di Telecom 
> Italia S.p.A.
> 
> ====================================================================
> 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 send an e_mail to
> [email-masked]. Thank you
> ====================================================================
> 

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

---

From: JinHyeock Choi <[email-masked]>
Date: Fri, 22 Apr 2005 16:01:18 +0900

Test. Please, ignore.