Re: [Mipshop] Extension of the WG Last Call ondraft-ietf-mipshop-4140bis-00.txt

[Vijay Devarapalli <[e-mail]>]

I am trying to see what the MAP must he mandated to implement. To me it 
appears like EAP over IKEv2 must be supported on the MAP. It is of 
course optional to use. For those deployments which require the MAP to 
contact the home network to authenticate the MN, EAP would be used.

Vijay

Julien Laganier wrote:
> On Tuesday 28 August 2007, Vijay Devarapalli wrote:
>> If we don't mandate support for EAP on the MAP (the actual use is
>> optional), then this is not practical. It would rule out all those
>> scenarios where the MAP would need to authenticate the MN with the
>> home network's help and authorize the MN for the "HMIPv6 Service".
>>
>> One question for the working group is whether we are ok with adding a
>> Normative reference to draft-ietf-btns-core-04.txt.
> 
> That wouldn't be prevented by writing down that at *minimum* MN should 
> be BTNS "authenticated" to the MAP. If the deployment requires true 
> authentication for HMIPv6, then certainly it is possible not to have 
> any BTNS PAD entry on the MAP, and the MN would then be required to be 
> truly authenticated by the MAP (as specified per the MAP's PAD).
> 
> --julien
> 
>> Julien Laganier wrote:
>>> On Tuesday 21 August 2007, Hesham Soliman wrote:
>>>> Hi Julien,
>>> Hi Hesham,
>>>
>>>> Thanks for the comments. As you said, I think we're in agreement.
>>>> A couple of responses below.
>>> So are another couple of responses and questions.
>>>
>>>> [...]
>>>>
>>>>  > > 12. Security Considerations
>>>>  > >
>>>>  > >    This specification introduces a new concept to Mobile
>>>>  > > IPv6, namely, a Mobility Anchor Point that acts as a local
>>>>  > > Home Agent.  It is crucial that the security relationship
>>>>  > > between the mobile node and the MAP is strong; it MUST
>>>>  > > involve mutual authentication, integrity protection, and
>>>>  > > protection against replay attacks.
>>>>  >
>>>>  > It seems to me that mutual authentication is not necessary in
>>>>  > the traditional sense of the terms:
>>>>  >
>>>>  > What is required is authentication of the MAP by the MN,
>>>>  > otherwise a node can impersonate the MAP and
>>>>  > discard/rewrite/insert local binding
>>>>  > updates, that would be bad.
>>>>  >
>>>>  > 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.
>>> All right, we agree. Cutting through your reply since we agree...
>>>
>>>> [...]
>>>>
>>>>  > If you keep in mind that the minimal requirements for a MAP
>>>>  > does not seem to authenticate the MN, but rather to authorize
>>>>  > sending local binding updates for a given RCoA, making EAP over
>>>>  > IKEv2 a MUST seems like too much sibce that doesn't seems to be
>>>>  > needed.
>>>>  >
>>>>  > Rather, it seems that use of BTNS by the MN achieve the
>>>>  > necessary level
>>>>  > of security, while not requiring presence of a centralized
>>>>  > authentication infrastructure containing the MN's
>>>>  > credentials. I'd thus
>>>>  > rather make BTNS support for MN 'authentication' a MUST, and
>>>>  > remove the
>>>>  > MUST regarding support for use of EAP over IKEv2.
>>>>
>>>> => We've had an issue raised about this and the WG decided to make
>>>> EAP/IKEv2 the default mechanism.
>>> My understanding was that making EAP/IKEv2 a requirement was due to
>>> concerns about MNs in a visited domain being provisioned with
>>> certificates issued by a trust anchor recognized by that visited
>>> domain.
>>>
>>> However, if self-signed certs/raw public keys used together with
>>> BTNS for MN "authentication" to the MAP are made the mandatory
>>> security mechanism, there are no such provisioning concerns.
>>> Further, this would not presume anything on HMIPv6 deployments,
>>> such as the required presence of an authentication infrastructure
>>> (AAA), thus widening the scope of applicability of the technology.
>>> That would be pretty useful for deployments in open access systems
>>> such as WiFi hotspots and so.
>>>
>>> At the same time, making BTNS the mandatory security mechanism
>>> would not prevent stronger methods of MN authentication (via e.g.
>>> PSK, PKI or EAP/IKEv2) to be used in deployments where it makes
>>> sense.
>>>
>>> So, maybe we should have the following statement:
>>>
>>> "the MAP must authenticate to the MAP via any of the metyat
>>> minimum, BTNS authentication of the MN to the MAP MUST be used.
>>>
>>>    To protect the operations of the HMIPv6 protocol, the protocol
>>>    messages MUST be protected by an IPsec security association
>>> between the MN and the MAP. The security association has to satisfy
>>> the following constraints:
>>>
>>>       o The MAP peer MUST be authenticated by the MN.
>>>       o At the minimum, the MN peer MUST be "unauthenticated" by
>>> the MAP as specified by BTNS extensions to IPsec
>>> [I-D.ietf-btns-core]. Stronger methods of authentication are
>>> supported by IKEv2 peers [RFC4306] and MAY be used to authenticate
>>> the MN to the MAP. o The SA MUST be bound to the the RCoA picked by
>>> the MN. o The SA MUST provides integrity and data origin
>>> authentication. o The SA MUST provides anti-replay protection.
>>>
>>>> At the end of the day, it's a deployment issue, so I'm not
>>>> terribly concerned about it because people will decide what's best
>>>> for their deployments. AAA seems to be trendy now and people want
>>>> it :)
>>> Whether or not using it is certainly a deployment issue. But here
>>> we have a MUST implement which means there's no choice for
>>> implementers.
>>>
>>> And, it is IMHO bad to turn trends and fashions into requirements
>>> in protocols specifications.
>>>
>>>>  > And FWIW, regarding specifically the use of EAP over IKEv2 to
>>>>  > avoid configuration and management of certificates on mobile
>>>>  > nodes, I do not
>>>>  > necessarily see the value of this since in essence it is
>>>>  > trading one centralized authentication infrastructure
>>>>  > containing the MN's credentials (PKI) with another (AAA). But
>>>>  > that is another discussion :)
>>>>
>>>> => Sure, but it gives more options for your favourite centralised
>>>> system.
>>> To give more options it would be sufficient to write since
>>> EAP/IKEv2 is a MAY already in IKEv2 spec.
>>>
>>> Cutting through the rest of your replies since we agree:
>>>> [...]
>>>>
>>>>  > >  If a binding cache entry exists for a given RCoA, the MAP's
>>>>  > >  IKE policy check MUST point to the SA used to install the
>>>>  > > entry. If the mobile node's credentials stored in the
>>>>  > > existing SA do not match the ones provided in the current
>>>>  > > negotiation, the MAP MUST reject the new SA establishment
>>>>  > > request for such RCoA with an INVALID-ID-INFORMATION
>>>>  > > notification [2].
>>>>  >
>>>>  > The above seems informational rather than normative, i.e.
>>>>  > does not seems to be specific to HMIP, that's what you would
>>>>  > expect from any  IPsec implementation, right? Would suggest
>>>>  > deleting MUST keywords.
>>>>
>>>> => A few years ago when 4140 was getting published, a lot of
>>>> people were confused about the IKE policy checks. The MUST is
>>>> there because if this is not done for this particular mobility
>>>> application then the protocol won't work. I didn't think IKE
>>>> defined general policy checks for all applications.
>>> Ah now I understand! I overlooked IKE in 'IKE policy check'... It
>>> looks like that could be covered as part of specifying what should
>>> go in the Peer Authentication Database. I need to think more about
>>> that and will come back to you.
>>>
>>> --julien
> 
> 


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