RE: [Mip6] Bootstrapping DT solution draft

[Gerardo Giaretta <[e-mail]>]

Hi Rafa, 

> 
> >
> >>Another related question is about authorization. Under my 
> >>point of view
> >>, MSP's AAA server is the entity that finally takes 
> decision about if
> >>the mobility service is authorized or not. MSA's AAA server 
> could send
> >>to MSP's AAA some kind of evidences or attributes related with
> >>authenticated user.Following these attributes and internal policies
> >>MSP's AAA server takes a final decision.
> >>
> >>    
> >>
> >
> >I tend to agree. This is the reason why AAA server of the 
> MSP should be
> >involved. I think that these issues should be covered by
> >draft-mip6-aaa-ha-goals.
> >
> <$rafa> Well... in the MIP6 bootstrapping draft , you mention 
> that MSA 
> is giving authorization.
> However if you agree that MSP can be involved in the 
> authorization , I 
> don't see why it should explained
> in draft-mip6-aaa-ha-goals.
> 

MSA gives the authorization based on the user profile. This is the role
of the MSA. The AAA-MSP acts as a AAA proxy and, as for network access,
it can have an active role in this process. However, usually this is
based on roaming agreements between the providers.

> >
> >>In particular , I was thinking a similar model than it is shown in
> >>Diameter EAP application I-D (Scenario 3: Direct EAP, 
> >>authorization via
> >>agents).
> >>
> >>Note this dicussion could be also valid for other services 
> >>(i.e. network
> >>access service).
> >>
> >>    
> >>
> >
> >I tend to agree also here. The MSP might need to add some 
> authorization
> >AVPs. 
> >
> <$Rafa> I agree that AVPs or specific information could be placed on 
> draf-ietf-aaa-ha-goals but to say if MSP is involved in 
> authorization or not
> could be said in bootstrapping solution I-D.
>

We may add some text in the draft to clarify the role of the AAA-MSP.
But I would keep the distinction between MSA and MSP with the MSA that
authorized MIPv6 service based on the user profile. 

> >>>      

~snip~

> >>>
> >><$Rafa> Here appears "MSA to grant the service" and in page 
> >>10 section 
> >>5.1.1
> >>"MSP granting the mobility service". Would it not be in the 
> first case
> >>"MSP to grant the service" too?
> >>
> >>    
> >>
> >
> >Yes. What about the following text?
> >
> >"
> >Authentication and Authorization with MSA. The user must be
> >authenticated in order for the MSP to grant the service. 
> Since the user
> >credentials can be verified only by the MSA, this 
> authorization step is
> >performed by the MSA. Moreover, the mobility service must be 
> explicitly
> >authorized by the MSA based on the user's profile. These 
> operations are
> >performed in different ways depending on the credentials used by the
> >Mobile Node during the IKEv2 peer authentication and on the backend
> >infrastructure (PKI or AAA). 
> >  
> >
> >"
> >  
> >
> <$Rafa> As you can see, this text still state MSA is explicitly doing 
> the authorization and MSP is not involved.

MSA MUST explicitly do the authorization. MSP MAY be involved depending
on the scenario and the roaming agreements between the operators. Do you
agree on that?

> So I understand from this that MSP's AAA server is only doing routing.
> 

In my view usually it performs only AAA routing since based on roaming
agreements the authorization is implicit.

> >
> >  
> >>    
> >>
> >>>the Mobile Node including the DNS Update mobility option with the 
> >>>correct value in the Status field (see section 8.1).
> >>>This procedure can be performed directly by the Home Agent 
> >>>      
> >>>
> >>if the Home 
> >>    
> >>
> >>>Agent has a security association with the domain specified in the 
> >>>Mobile Node's FQDN.
> >>>
> >>>
> >>>      
> >>>
> >><$Rafa> Why don't MSP's AAA server could do DNS update 
> >>instead of MSA's
> >>AAA server??
> >>
> >>    
> >>
> >
> >It could. But I don't see a reason for that. Do you see any 
> issue with
> >the current solution? 
> >  
> >
> <%Rafa> if MSP provides the Home Agent , and Home Agent gives a Home 
> Address... would not be more coherent that MSP's AAA server 
> did this task?
> 

It depends on the FQDN used by the MN. If the FQDN belongs to the MSA<
the MSA MUST do that since the MSP AAA server may not share a SA with
the DNS server of the MSA.


Regards,
--Gerardo

> >  
> >
> >>>On the other hand, if the Mobile Node wants to be reachable 
> >>>      
> >>>
> >>through a 
> >>    
> >>
> >>>FQDN that belongs to the MSA, the Home Agent and the DNS 
> >>>      
> >>>
> >>server that 
> >>    
> >>
> >>>must be updated belong to different administrative domain. 
> >>>      
> >>>
> >>In this G. 
> >>    
> >>
> >>>Giaretta, Ed. Expires December 22, 2005 [Page 16]
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>Internet-Draft MIPv6 bootstrapping in split scenario June 2005
> >>>case the Home Agent may not share a security association 
> >>>      
> >>>
> >>with the DNS 
> >>    
> >>
> >>>server and the DNS entry update can be performed by the AAA 
> >>>      
> >>>
> >>server of 
> >>    
> >>
> >>>the MSA. In order to accomplish this, the Home Agent sends 
> >>>      
> >>>
> >>to the AAA 
> >>    
> >>
> >>>server the FQDN-HoA pair through the AAA protocol. This message is 
> >>>proxied by the AAA infrastructure of the MSP and is 
> received by the 
> >>>AAA server of the MSA. The AAA server of the MSA perform the DNS 
> >>>update based on [14]. The detailed description of the 
> communication 
> >>>between Home Agent and AAA is out of the scope of this draft. More 
> >>>details are provided in [12].
> >>>
> >>>
> >>>      
> >>>
> >><snip>
> >>
> >>    
> >>
> >>>9. Security Considerations
> >>>9.1. HA Address Discovery
> >>>Use of DNS for address discovery carries certain security 
> >>>      
> >>>
> >>risks. DNS 
> >>    
> >>
> >>>transactions in the Internet are typically done without any 
> >>>authentication of the DNS server by the client or of the 
> >>>      
> >>>
> >>client by the 
> >>    
> >>
> >>>server. There are two risks involved:
> >>>1) A legitimate client obtains a bogus Home Agent address 
> >>>      
> >>>
> >>from a bogus 
> >>    
> >>
> >>>DNS server. This is sometimes called a "pharming" attack,
> >>>2) An attacking client obtains a legitimate Home Agent 
> >>>      
> >>>
> >>address from a 
> >>    
> >>
> >>>legitimate server.
> >>>
> >>>      
> >>>
> >><$Rafa>I have a comment regarding this case 1): I think any 
> >>user already
> >>authenticated and authorized to use mobility service could launch
> >>this attack becuase user already owns a valid certificate and 
> >>therefore
> >>a legitimate client could verify this certificate. The issue is this
> >>user is NOT AUTHORIZED to be a Home Agent. what do you think??
> >>
> >>    
> >>
> >
> >I don't get your point. Which scenario are you referring to? Are you
> >assuming only certificates is used or also AAA?
> >  
> >
> <$Rafa> I am assuming only certificates.
> 
> 
> >  
> >
> >>>The risk in Case 1 is mitigated because the Mobile Node is 
> >>>      
> >>>
> >>required to 
> >>    
> >>
> >>>conduct an IKE transaction with the Home Agent prior to 
> >>>      
> >>>
> >>performing a 
> >>    
> >>
> >>>Binding Update to establish Mobile IPv6 service. According to the 
> >>>IKEv2 specification [7], the responder must present the 
> >>>      
> >>>
> >>initiator with 
> >>    
> >>
> >>>a valid certificate containing the responder's public key, and the 
> >>>responder to initiator IKE_AUTH message must be protected with an 
> >>>authenticator calculated using the public key in the certificate. 
> >>>Thus, an attacker would have to set up both a bogus DNS 
> >>>      
> >>>
> >>server and a 
> >>    
> >>
> >>>bogus Home Agent, and provision the Home Agent with a 
> >>>      
> >>>
> >>certificate that 
> >>    
> >>
> >>>a victim Mobile Node could verify. If the Mobile Node can 
> >>>      
> >>>
> >>detect that 
> >>    
> >>
> >>>the certificate is not trustworthy, the attack will be 
> >>>      
> >>>
> >>foiled when the 
> >>    
> >>
> >>>Mobile Node attempts to set up the IKE SA.
> >>>
> >>>
> >>>      
> >>>
> >><snip>
> >>
> >>    
> >>
> >>>9.5. Dynamic DNS Update
> >>>Mobile IPv6 bootstrapping recommends the Home Agent to update the 
> >>>Mobile Node's FQDN with a dynamically assigned home address rather 
> >>>than have the Mobile Node itself do it (see Section 6 above). This 
> >>>choice was motivated by a concern for preventing redirection-based 
> >>>flooding attacks (see draft-ietf-mip6-ro-sec [19] for more 
> >>>      
> >>>
> >>information 
> >>    
> >>
> >>>about redirection-based flooding attacks and the role 
> >>>      
> >>>
> >>preventing them 
> >>    
> >>
> >>>played in the design of Mobile IPv6 route optimization security). 
> >>>Exactly as for route optimization, it is possible for a 
> >>>      
> >>>
> >>node that is 
> >>    
> >>
> >>>the legitimate owner of a DNS FQDN - in the sense that it has a 
> >>>security association with the DNS server allowing it to perform 
> >>>dynamic DNS update of its FQDN - to bind its FQDN to the 
> >>>      
> >>>
> >>address of a 
> >>    
> >>
> >>>victim, then redirect large volumes of traffic at the victim. The 
> >>>attack may be propagated without the owner's knowledge, for 
> >>>      
> >>>
> >>example, 
> >>    
> >>
> >>>if the node is compromised by malware, or it may be 
> >>>      
> >>>
> >>intentional if the 
> >>    
> >>
> >>>node itself is the attacker.
> >>>While it is possible to prevent redirection attacks 
> through ingress 
> >>>filtering on access routers, ISPs have little or no incentive to 
> >>>deploy ingress filtering. In some cases, if an attack could 
> >>>      
> >>>
> >>result in 
> >>    
> >>
> >>>substantial financial gain, it is even possible that a 
> >>>      
> >>>
> >>corrupt ISP may 
> >>    
> >>
> >>>have an incentive not to deploy ingress filters such as has 
> >>>      
> >>>
> >>been the 
> >>    
> >>
> >>>case for spam. Consequently, the security for dynamic 
> >>>      
> >>>
> >>Mobile Node FQDN 
> >>    
> >>
> >>>update has been assigned to the Home Agent, where active network 
> >>>administration and vigilant defense measures are more 
> >>>      
> >>>
> >>likely to (but 
> >>    
> >>
> >>>G. Giaretta, Ed. Expires December 22, 2005 [Page 25]
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>Internet-Draft MIPv6 bootstrapping in split scenario June 2005
> >>>are not assured of) mitigating problems, and the owner of 
> >>>      
> >>>
> >>the Mobile 
> >>    
> >>
> >>>Node is more likely to detect a problem if it occurs.
> >>>If a Home Agent performs dynamic DNS update on behalf of 
> the Mobile 
> >>>Node directly with the DNS server, the Home Agent MUST have 
> >>>      
> >>>
> >>a security 
> >>    
> >>
> >>>association of some type with the DNS server. The security 
> >>>      
> >>>
> >>association 
> >>    
> >>
> >>>MAY be established either using DNSSEC [16] or TSIG/TKEY 
> >>>      
> >>>
> >>[17][18]. A 
> >>    
> >>
> >>>security association is required even if the DNS server is 
> >>>      
> >>>
> >>in the same 
> >>    
> >>
> >>>administrative domain as the Home Agent. The security association 
> >>>SHOULD be separate from the security associations used for other 
> >>>purposes, such as AAA.
> >>>In the case where the Mobility Service Provider is 
> >>>      
> >>>
> >>different from the 
> >>    
> >>
> >>>Mobility Service Authorizer, the network administrators 
> may want to 
> >>>limit the number of cross-administrative domain security 
> >>>      
> >>>
> >>associations. 
> >>    
> >>
> >>>If the Mobile Node's FQDN is in the Mobility Service Authorizer's 
> >>>domain, since a security association for AAA signaling involved in 
> >>>mobility service authorization is required in any case, the 
> >>>      
> >>>
> >>Home Agent 
> >>    
> >>
> >>>can send the Mobile Node's FQDN to the AAA server under the HA-AAA 
> >>>server security association,
> >>>      
> >>>
> >>$Rafa> MSA's AAA Server?? or MSP's AAA server??
> >>
> >>    
> >>
> >
> >To the MSA's AAA server through the MSP's AAA server. The MSA's AAA
> >server updates the MSA's DNS server. 
> >
> >  
> >
> >>So far, these are my comments.
> >>
> >>    
> >>
> >
> >Thanks again,
> >
> >--Gerardo
> >
> >  
> >
> >>Regards.
> >>
> >>-- 
> >>------------------------------------------------------
> >>Rafael Marin Lopez
> >>Faculty of Computer Science-University of Murcia
> >>30071 Murcia - Spain
> >>Telf: [phone] e-mail: [e-mail]
> >>------------------------------------------------------
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>Gerardo Giaretta wrote:
> >>
> >>    
> >>
> >>>Dear WG,
> >>>
> >>>the bootstrapping DT has submitted a solution draft. The document
> >>>defines how a Mobile Node can bootstrap MIPv6 operations from
> >>>non-topological information and pre-configured security 
> >>>      
> >>>
> >>credentials. The
> >>    
> >>
> >>>solution solves the boostrapping problem when the Mobile 
> >>>      
> >>>
> >>Node's mobility
> >>    
> >>
> >>>service is authorized by a different service provider than 
> >>>      
> >>>
> >>basic network
> >>    
> >>
> >>>access (i.e. split scenario).
> >>>
> >>>The draft can be found at
> >>>
> >>>      
> >>>
> >>http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp
> >>ing-split-
> >>    
> >>
> >>>00.txt.
> >>>
> >>>The DT is currently working on optimized solutions for integrated
> >>>scenario (i.e. mobility service and basic network access 
> >>>      
> >>>
> >>are authorized
> >>    
> >>
> >>>by the same entity).
> >>>
> >>>Please read the document and provide comments.
> >>>
> >>>Thanks and regards,
> >>>
> >>>--Gerardo (DT editor)
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>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
> >>>[e-mail]. Thank you
> >>>===========================================================
> =========
> >>>
> >>>_______________________________________________
> >>>Mip6 mailing list
> >>>[e-mail]
> >>>https://www1.ietf.org/mailman/listinfo/mip6
> >>>
> >>>
> >>>
> >>>
> >>>      
> >>>
> >>
> >>
> >>Gerardo Giaretta wrote:
> >>
> >>    
> >>
> >>>Dear WG,
> >>>
> >>>the bootstrapping DT has submitted a solution draft. The document
> >>>defines how a Mobile Node can bootstrap MIPv6 operations from
> >>>non-topological information and pre-configured security 
> >>>      
> >>>
> >>credentials. The
> >>    
> >>
> >>>solution solves the boostrapping problem when the Mobile 
> >>>      
> >>>
> >>Node's mobility
> >>    
> >>
> >>>service is authorized by a different service provider than 
> >>>      
> >>>
> >>basic network
> >>    
> >>
> >>>access (i.e. split scenario).
> >>>
> >>>The draft can be found at
> >>>http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap
> >>>      
> >>>
> >>ping-split-
> >>    
> >>
> >>>00.txt.
> >>>
> >>>The DT is currently working on optimized solutions for integrated
> >>>scenario (i.e. mobility service and basic network access are 
> >>>      
> >>>
> >>authorized
> >>    
> >>
> >>>by the same entity).
> >>>
> >>>Please read the document and provide comments.
> >>>
> >>>Thanks and regards,
> >>>
> >>>--Gerardo (DT editor)
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>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
> >>>[e-mail]. Thank you
> >>>===========================================================
> =========
> >>>
> >>>_______________________________________________
> >>>Mip6 mailing list
> >>>[e-mail]
> >>>https://www1.ietf.org/mailman/listinfo/mip6
> >>>
> >>>
> >>>
> >>>      
> >>>
> >>-- 
> >>------------------------------------------------------
> >>Rafael Marin Lopez
> >>Faculty of Computer Science-University of Murcia
> >>30071 Murcia - Spain
> >>Telf: [phone]    e-mail: [e-mail]
> >>------------------------------------------------------
> >>
> >>
> >>    
> >>
> >
> >
> >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
> >[e-mail]. Thank you
> >====================================================================
> >
> >_______________________________________________
> >Mip6 mailing list
> >[e-mail]
> >https://www1.ietf.org/mailman/listinfo/mip6
> >
> >
> >  
> >
> 
> 
> -- 
> ------------------------------------------------------
> Rafael Marin Lopez
> Faculty of Computer Science-University of Murcia
> 30071 Murcia - Spain
> Telf: [phone]    e-mail: [e-mail]
> ------------------------------------------------------
> 
> 


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 
[e-mail]. Thank you
====================================================================

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