RE: HMIPv6 Security Model (Was Re: [Mipshop] Extension of the WG Last Callondraft-ietf-mipshop-4140bis-00.txt)

["Hesham Soliman" <[e-mail]>]

Actually, I think the misunderstanding is deeper than that. HMIPv6 never
assumed a particular authorisatiom model because it never needed that. We
made it very clear when 4140 was published that a form of oppotunistic IPsec
would suffice. However, some people wanted a particular deployment model
which required authorisation certs ....etc. 

So, the point to know here is that the authorisation requirements are
**deployment** security models and *not* HMIPv6 security models. The
protocol security is fine with any of those options. 

Hesham 

 > -----Original Message-----
 > From: Narayanan, Vidya [mailto:[e-mail]] 
 > Sent: Wednesday, August 29, 2007 3:59 AM
 > To: Vijay Devarapalli; Hesham Soliman
 > Cc: Julien Laganier; [e-mail]; 
 > [e-mail]
 > Subject: RE: HMIPv6 Security Model (Was Re: [Mipshop] 
 > Extension of the WG Last Callondraft-ietf-mipshop-4140bis-00.txt)
 > 
 > I think there may be a misunderstanding here.  Based on earlier
 > discussions, we were assuming that the MAP is *always* interested in
 > authenticating the MN identity and ensuring it is authorized 
 > for HMIPv6.
 > That led to our having a MUST on EAPoIKEv2 support.  
 > However, based on
 > current discussions, I'm saying that not all networks may 
 > want that type
 > of authorization in order to provide HMIPv6 service.  In 
 > that case, the
 > support for EAP is in fact, optional on the MAP.  
 > Deployments that are
 > interested in the authorization aspects will ensure that the MAPs
 > deployed in their networks support EAP.  
 > 
 > So, the point here is that RFC4306, as specified is sufficient and we
 > don't need to change any of the normative behavior of IKEv2 
 > responders.
 > We do need to add text to clarify what type of authentication is
 > appropriate for what kind of environments. 
 > 
 > Vidya
 > 
 > > -----Original Message-----
 > > From: Vijay Devarapalli [mailto:[e-mail]] 
 > > Sent: Tuesday, August 28, 2007 8:54 AM
 > > To: Hesham Soliman
 > > Cc: Narayanan, Vidya; 'Julien Laganier'; [e-mail]; 
 > > [e-mail]
 > > Subject: HMIPv6 Security Model (Was Re: [Mipshop] Extension 
 > > of the WG Last Callondraft-ietf-mipshop-4140bis-00.txt)
 > > 
 > > Hello,
 > > 
 > > We seem to be changing the security model assumed for HMIPv6.
 > > 
 > > My earlier understanding of the HMIPv6 security model is that 
 > > the MAP would like to authenticate the user before granting 
 > > "HMIPv6 service". 
 > > Since the MN and the MAP share no security credentials, the 
 > > MAP has to go back to the home network of the MN to 
 > > authenticate the MN. So EAP support on the MAP was mandated.
 > > 
 > > A related issue - HMIPv6 may be deployed in an environment 
 > > where the visited network that hosts the MAP would like to 
 > > charge for the "HMIPv6 service". This means the home network 
 > > must be involved in the authentication and authorization.
 > > 
 > > We now seem to be moving towards a "first come, first serve" 
 > > basis, where the MAP allows the MN HMIPv6 service with a 
 > > self-signed certificate or with BTNS. But once a binding is 
 > > created, the MAP ensures it is the same MN all the time.
 > > 
 > > I would be fine with the second one, as long as we document 
 > > the new security model. But this might prevent some of the 
 > > deployments I described above.
 > > 
 > > Vijay
 > > 
 > > Hesham Soliman wrote:
 > > > Hi Vidya, all,
 > > > 
 > > > Thanks for the comments. First I want to say that I 
 > > completely agree 
 > > > with you and Julien on the fact that we don't need to 
 > > mandate EAP. The 
 > > > reason I went along with it was the chairs call for 
 > mandating one 
 > > > method for authentication. I'm very happy with mandating 
 > > self signed 
 > > > certs instead of EAP as the default mechanism. Let's do 
 > > this as a part of the comments on LC.
 > > > Once we finish receiving comments I'll send this question 
 > > to the list.
 > > > 
 > > > On the question of binding the ids to the RCoA, I think 
 > > again we're in 
 > > > agreement but we're using different words to express that. 
 > > I think the 
 > > > MAP only needs to know that future BUs were secured by 
 > the same MN 
 > > > that it originally allocated the RCoA. Of course one 
 > would do this 
 > > > indirectly by inferring that since the same key was used to 
 > > secure the 
 > > > BU, then the BU came from the same MN. So there would be 
 > no need to 
 > > > physically tie the MN identity (i nthe form of self signed 
 > > cert or EAP id) to the binding.
 > > > 
 > > > Hesham
 > > > 
 > > >  > -----Original Message-----
 > > >  > From: Narayanan, Vidya [mailto:[e-mail]]  > Sent: 
 > > > Tuesday, August 28, 2007 3:38 AM  > To: Hesham Soliman; Julien 
 > > > Laganier; [e-mail]  > Cc: 
 > > > [e-mail]; Vijay Devarapalli  > 
 > > > Subject: RE: [Mipshop] Extension of the WG Last  > 
 > > > Callondraft-ietf-mipshop-4140bis-00.txt
 > > >  >
 > > >  > Hi Hesham, Julien,
 > > >  > Just commenting on one point below.  
 > > >  >
 > > >  > <snip>
 > > >  >
 > > >  > >  >
 > > >  > >  > But w.r.t. to the MN, I do not think the MAP needs 
 > > to  >  > > 
 > > > authenticate it in  > the traditional use of the term, i.e.
 > > >  > > verifying the MN identity, and  > binding the security  > > 
 > > > association established with the MN to that  > identity.
 > > >  > >
 > > >  > > => I think we definitely need to bind the SA to the 
 > > identity  > > 
 > > > of the MN, otherwise another MN would steal it. But I do 
 >  > > agree 
 > > > that the identity of the MN itself is not that important.
 > > >  > > So Verifying the identity during the IKE exchange is  > > 
 > > > typically not important, while binding the identity to the  
 > > > > RCoA 
 > > > is important.
 > > >  > >
 > > >  >
 > > >  > The resultant SA must be bound to the RCoA, but, not  > 
 > > necessarily 
 > > > to the  > identity as known by the EAP method (or the IKEv2 
 > > IDi), for 
 > > > instance.
 > > >  > In essence, if we separated the "identity" concept from 
 > > the  > "IP 
 > > > address"
 > > >  > concept, the SA must be bound to the latter, but, not  > 
 > > > necessarily to the  > former.
 > > >  >
 > > >  > That actually questions the MUST on the EAP in IKEv2 
 > > support, which 
 > > > I  > think is the point Julien was making.  It is an 
 > interesting  > 
 > > > point that  > has merit in my view.  I know we decided on a 
 > > "MUST" on 
 > > > EAP to avoid  > forcing PSKs between MNs and MAPs (which is 
 > > > impractical) and to  > alternatively avoid forcing certs on MNs 
 > > > (which, depending on who you  > ask, would also be qualified as 
 > > > impractical :)).  But,  > unless the MAP is  > interested 
 > > in checking 
 > > > any "authorization" for the MN's use of HMIP  > service, an 
 > > > authentication on its identity should not be needed.  In 
 >  > those 
 > > > environments, it would be sufficient to go with a  > 
 > > self-signed cert  
 > > > > from the MN or perhaps with something that BTNS is 
 > > working  > on (I 
 > > > haven't  > been following the BTNS work - so, can't say that for 
 > > > sure)...
 > > >  >
 > > >  > I recall that we had a discussion earlier and 
 > concluded that  > 
 > > > support for  > EAP on the MAP must be mandated.. But, I 
 > think it is 
 > > > worth  > reconsidering  > whether we need to change any of 
 > > the IKEv2 
 > > > recommendations  > at all based  > on this point.
 > > >  >
 > > >  > Thanks,
 > > >  > Vidya
 > > >  >
 > > > 
 > > > 
 > > 
 > > 
 > 



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