Subject: Re: [Mipshop] WG Last Call on draft-ietf-mipshop-4140bis-00.txt

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 08 Aug 2007 09:47:22 -0700

Folks,

We haven't received any comments on this document so far. The last call 
expires on Aug 10th.

Vijay

Vijay Devarapalli wrote:
> Hello,
> 
> This is to announce a working group last call for
> draft-ietf-mipshop-4140bis-00. You can find the document
> at the following URL.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-mipshop-4140bis-00.txt   
> 
> The last call expires on August 10 2007.
> 
> Please post any issues or comments on this document to
> the MIPSHOP WG mailing list. In case you have reviewed
> the document and found no issues, please send an email
> saying you support advancing this document.
> 
> The intended status for this document is Standards Track.
> 
> Vijay
> 
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop

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

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 08 Aug 2007 13:18:57 -0400

Hi Vijay,
   I have read this document and I believe that it is ready to proceed 
on the Standards track. I support advancing this document

Cheers
Suresh

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 13 Aug 2007 12:17:35 -0700

Hello folks,

We are extending the WG last call by another week. The last call now 
expires on the 20th of August.

We had only one response for the last call so far. I would really like 
to see more support for this document before advancing it to the IESG 
for publication.

Vijay

---

From: Frank Xia <[email-masked]>
Date: Mon, 13 Aug 2007 16:37:38 -0500

I think it is ready for IESG

---

From: Jari Arkko <[email-masked]>
Date: Wed, 15 Aug 2007 16:24:28 +0300

Folks,

We cannot progress documents when last calls indicate just one
or two persons who support the document. We need multiple
persons, and they need to perform full reviews (merely supporting
the document is not enough -- please indicate the depth of your
review if you post a response to the WGLC).

Vijay, given vacation period at least in Europe, I wonder if you
should extend the WGLC a bit longer, say to the end of August.

The document seems to have some nits, by the way:

http://tools.ietf.org/wg/mipshop/draft-ietf-mipshop-4140bis/draft-ietf-mipshop-4140bis-00.nits.txt

Jari

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 16 Aug 2007 11:22:13 +1000

In case there is any doubt, obviously the four authors of the draft have
reviewed it and are happy for it to move forward. 

Hesham 

 > -----Original Message-----
 > From: Jari Arkko [mailto:[email-masked]] 
 > Sent: Wednesday, August 15, 2007 11:24 PM
 > To: Vijay Devarapalli
 > Cc: [email-masked]
 > Subject: Re: [Mipshop] Extension of the WG Last Callon 
 > draft-ietf-mipshop-4140bis-00.txt
 > 
 > Folks,
 >

---

From: Thomas C Schmidt <[email-masked]>
Date: Thu, 16 Aug 2007 22:43:32 -0700

Hi Hesham and all,

to prevent the impression Europe is a place of permanent vacation:

I've been following the development of HMIPv6 rather closely and read 
the current document carefully.

Two minor things appear to me.

  1. The formal nits (uncited references :( ).

  2. An issue with the consistency of the distance field:
     Distance field in the MAP Option is not bound to a specific
     metrik. It is advised only to be used consistently  within a MAP
     domain. On the other hand, overlapping MAP domains are allowed.
     As the MN cannot identify domains from the MAP Option,
     this may lead to an inconsistent view at the mobile node.

     So my suggestion would be to explicitly state a consistency
     requirement from the MN's point of view - in single or overlapping
     MAP domains.

Beyond these minor details I think the document is fine and should be 
moved forward.

Back to the beach now,

thomas

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 17 Aug 2007 16:12:19 +1000

Thanks Thomas, I'll address both comments as part of the LC. I agree with
your suggestions.

Hesham 

 > From: Thomas C Schmidt [mailto:[email-masked]] 
 > Sent: Friday, August 17, 2007 3:44 PM
 > To: [email-masked]
 > Subject: Re: [Mipshop] Extension of the WG LastCall on

---

From: Julien Laganier <[email-masked]>
Date: Tue, 21 Aug 2007 08:55:24 +0200

> expires on the 20th of August.

It's still the 20th somewhere on the planet :) 

$ date
Mon Aug 20 20:52:32 HST 2007. 

I have reviewed this document and overall think it looks good. I however 
have comments on the security considerations section:

> 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. 

Rather, the minimal requirements for the MAP seems to be able to verify 
authorization of a MN to issue local binding updates for a given RCoA.

The simplest way for the MAP to grant RCoA authorization is on a 
first-come first-serve basis. 

Following, the authorization verification can be achieved via a 
verification of a 'sameness' property, i.e. that the entity wanting to 
send a local BU for a given RCoA is the same entity that initially 
registered that RCoA. This can be done via use of an IKEv2 exchange in 
the BTNS mode for the Initiator/MN (See draft-ietf-btns-core).

That is, a MN does not traditionally authenticate itself (via a PKI, or 
EAP) but just send a self generated public key in the CERT payload of 
the IKEv2 exchange, and generates signature in the AUTH payload using 
the corresponding private key. Once the BTNS IKEv2 exhange completes, a 
BTNS security association is established, with traffic selector 
protecting traffic exchanged between the RCoA and the MAP. That seems 
appropriate for protection of local binding updates since this SA binds 
the RCoA to possession of the BTNS public/private key pair, thus 
guarantying 'sameness', and consequently validating authorization to 
issue local binding updates..

MitM attacks would be defeated since an attacker cannot impersonate the 
MAP which is still authenticated.

> Confidentiality may be needed for payload traffic, but is not required
> for binding updates to the MAP.  The absence of any of these
> protections may lead to malicious mobile nodes impersonating other
> legitimate ones or impersonating a MAP.  Any of these attacks will
> undoubtedly cause undesirable impacts to the mobile node's
> communication with all correspondent nodes having knowledge of the
> mobile node's RCoA. 
>
>    Three different relationships (related to securing binding
> updates) need to be considered:
>
>       1) The mobile node - MAP
>       2) The mobile node - Home Agent
>       3) The mobile node - correspondent node
>
> 12.1. Mobile Node-MAP Security
>
>    In order to allow a mobile node to use the MAP's forwarding
> service, initial authorisation (specifically for the service, not for
> the RCoA) MAY be needed.  

Agree with the MAY w.r.t. to requirements of authorization of HMIP 
service above.

> Authorising a mobile node to use the MAP 
> service can be done based on the identity of the mobile node
> exchanged during the SA negotiation process.  The authorisation may
> be granted based on the mobile node's identity, or based on the
> identity of a Certificate Authority (CA) that the MAP trusts.  For
> instance, if the mobile node presents a certificate signed by a
> trusted entity (e.g., a CA that belongs to the same administrative
> domain, or another trusted roaming partner), it would be sufficient
> for the MAP to authorise the use of its service.  Note that this
> level of authorisation is independent of authorising the use of a
> particular RCoA. 

Also agree about independence of that authorization with authorization 
to use a given RCoA.

> Similarly, the mobile node would trust the MAP if 
> it presents a certificate signed by the same CA or by another CA that
> the mobile node is configured to trust (e.g., a roaming partner).

I think that 'Similarly' and 'would' above should be removed since it 
seems to imply that MAP authorization/authentication is also a MAY. I'm 
assuming that the MAP MUST be authenticated and authorized, right?

>    IKEv2 allows the use of EAP as a mechanism to bootstrap the
> security association between the communicating peers. Hence, EAP can
> be used with IKEv2 to leverage the AAA infrastructure to bootstrap
> the SA between the mobile node and the MAP. Such mechanism is useful
> in scenarios where an administrator wishes to avoid the configuration
> and management of certificates on mobile nodes. A MAP MUST support
> the use of EAP over IKEv2.

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.

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 :)

>    If EAP is used with IKEv2, the EAP method runs between the mobile
>    node and a AAA server. Following a successful authentication, the
>    resulting keying material can be used to bootstrap IKEv2 between
> the MAP and the mobile node. The specification of which EAP methods
> should be used, or how keys are transported between the MAP and the
> AAA server is outside the scope of this document.
>
>    HMIPv6 uses an additional registration between the mobile node and
>    its current MAP.  As explained in this document, when a mobile
> node moves into a new domain (i.e., served by a new MAP), it obtains
> an RCoA, an LCoA and registers the binding between these two
> addresses with the new MAP.  The MAP then verifies whether the RCoA
> has not been registered yet and, if so, it creates a binding cache
> entry with the RCoA and LCoA.  Whenever the mobile node gets a new
> LCoA, it needs to send a new BU that specifies the binding between
> RCoA and its new LCoA.  This BU needs to be authenticated, otherwise
> any host could send a BU for the mobile node's RCoA and hijack the
> mobile node's packets.  However, because the RCoA is temporary and is
> not bound to a particular node, a mobile node does not have to
> initially (before the first binding update) prove that it owns its
> RCoA (unlike the requirement on home addresses in Mobile IPv6) when
> it establishes a Security Association with its MAP.  A MAP only needs
> to ensure that a BU for a particular RCoA was issued by the same
> mobile node that established the Security Association for that RCoA.

So when I read the above ("A MAP only needs to ensure that a BU for a 
particular RCoA was issued by the same mobile node that established the 
Security Association for that RCoA.") it seems that we're indeed in 
violent agreement on the security requirements placed on the MN-MAP SA.

Thus I'd expect that you agree that BTNS is the natural (and simplest!) 
solution to that problem.

>    The MAP does not need to have prior knowledge of the identity of
> the mobile node nor its Home Address.
> As a result the SA between the 
> mobile node and the MAP can be established using any key
>    establishment protocols such as IKE. 
  
Exactly!  And that is what exactly what BTNS does.

>    A return routability test is not necessary.
>
>    The MAP needs to set the SA for the RCoA (not the LCoA).  This can
> be performed with IKE [2].  The mobile node uses its LCoA as the
> source address, but specifies that the RCoA should be used in the SA.
>  This is achieved by using the RCoA as the identity in IKE Phase 2
> negotiation.  This step is identical to the use of the home address
> in IKE phase 2.

Here I'm wondering whether or not we want to modify the text and refers 
to IKEv2 instead, since in effects IKEv2 is deprecating IKEv1.

>    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.

> This is to prevent two 
> different mobile nodes from registering (intentionally or not) the
> same RCoA. Upon receiving this notification, the mobile node SHOULD
> generate a new RCoA and restart the IKE negotiation. Alternatively, a
> MAP may decide that, if a binding cache entry already exists for a
> particular RCoA, no new security association should be established
> for such RCoA; this is independent of the mobile node's credentials.

Shall we have some text explainling how 'garbage collections' of RCoA 
SAs occurs, e.g. via IKE dead-peer detection, or SA lifetime 
exhaustion?

> This prevents the mobile node from being able to re-establish a
> security association for the same RCoA (i.e., to change session
> keys). However, this is not a major problem because the SA will
> typically only be used to protect signalling traffic when a MN moves,
> and not for the actual data traffic sent to arbitrary nodes. Binding
> updates between the MAP and the mobile node MUST be protected with
> either AH or ESP in transport mode. When ESP is used, a non- null
> authentication algorithm MUST be used.

I think the two last sentences should be rewritten in:

Binding updates between the MAP and the mobile node MUST be integrity 
protected with AH or ESP in transport mode. When ESP is used without AH 
integrity protection, a non- null authentication algorithm MUST be used 
in ESP.

That's it for now. I hope the review helps. Best,

--julien

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 21 Aug 2007 23:41:25 +1000

Hi Julien, 

Thanks for the comments. As you said, I think we're in agreement. A couple
of responses below.

 > Mon Aug 20 20:52:32 HST 2007. 

=> I wouldn't worry about that :) there are people still reviewing the doc
so I think we may have to handle more comments anyway. 

 > binding the security association established with the MN to that 

=> 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.

 > authorization of a MN to issue local binding updates for a 

=> That too.

 > the BTNS mode for the Initiator/MN (See draft-ietf-btns-core).

=> Agreed.

 > issue local binding updates..

=> Agreed.

 > MAP which is still authenticated.

=> Sure and by the "sameness" MiTM attacks would not work for the MN too.

 > assuming that the MAP MUST be authenticated and authorized, right?

=> Yes.

 > 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. 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 :)

 > credentials (PKI) with another (AAA). But that is another 

=> Sure, but it gives more options for your favourite centralised system.

 > solution to that problem.

=> No objection from me!

 > to IKEv2 instead, since in effects IKEv2 is deprecating IKEv1.

=> Ok.

 > 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.

 > SAs occurs, e.g. via IKE dead-peer detection, or SA lifetime 

=> Sure, suggestions welcome, otherwise I'll send something to the list.

 > integrity protection, a non- null authentication algorithm 

=> Ok. Thanks for the review!

Hesham

---

From: Greg Daley <[email-masked]>
Date: Mon, 27 Aug 2007 10:58:21 +1000

Hi,

Sorry about the delay, i hope these comments are still useful.

With regard to the mutual authentication issue, the MAP
still has to be interested in continutity of binding,
so that the same identity currently bound in the SA
is entitled to the same RCoA. 

This is an ephemeral identity, but one which needs to
be managed so long as the RCoA is still bound.

This impacts on the garbage collection to the point
where it is important not to reallocate an RCoA to a
different identity, even if the peer is dead. Otherwise,
address stealing attacks would be possibe where the IKE
peer is temporarily unreachable (or forced to be).

Note that the issue here is more about third parties who
have received binding updates from the MN, and how they
treat packets from the RCoA (in their binding cache).

Therefore, the garbage collection text needs to be
informed to ensure that reallocation doesn't occur within
binding lifetime.

Here is some example text:

Security Association Garbage Collection

The Security Associations bound to the Regional Care of Address,
may be garbage collected for any of a variety of reasons, such
as IKE Dead Peer Detection, negotiated SA lifetime
expiry, Session-Timeout associated with the EAP derived
session keys or Least Recently Used caching of SAs with no
current binding.

Care must be taken in the case where the session is to be expired
using Dead-Peer-Detection or other reachability information.
Particularly, it is important that the RCoA cannot be
re-allocated to a device with another identity within the
residual lifetime of the last received local binding update.
Otherwise, attackers could override the RCoA binding by
negotiating a new session while packets are still travelling
toward the prior address holder.

One such way to implement this is to hold-down Dead-Peer-Detection
SA deletion, until the binding lifetime expires.

I hope this helps.

Sorry about the tardiness again.

Greg

----- Original Message -----
From: Hesham Soliman <[email-masked]>
Date: Tuesday, August 21, 2007 11:41 pm
Subject: RE: [Mipshop] Extension of the WG Last Call
ondraft-ietf-mipshop-4140bis-00.txt
To: 'Julien Laganier' <[email-masked]>, [email-masked]
Cc: [email-masked], 'Vijay Devarapalli'
<[email-masked]>

> Hi Julien, 
> 
> Thanks for the comments. As you said, I think we're in agreement. A 
> coupleof responses below.
> 
> > $ date
> > > the MAP is strong; it MUST involve mutual authentication, 
> integrity > > protection, and protection against replay attacks.  
> > 
> => 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
> => We've had an issue raised about this and the WG decided to make 
> EAP/IKEv2the default mechanism. At the end of the day, it's a 
> deployment issue, so
> > > negotiation.  This step is identical to the use of the home 
> address > > in IKE phase 2.
> > 
> > >    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
> => A few years ago when 4140 was getting published, a lot of people 
> wereconfused about the IKE policy checks. The MUST is there because 
> if this is
> not done for this particular mobility application then the protocol 
> won'twork. I didn't think IKE defined general policy checks for all 
> applications.
> 
> > 
> > > This is to prevent two 
> > > different mobile nodes from registering (intentionally or not) 
> the > > same RCoA. Upon receiving this notification, the mobile 
> node SHOULD
> > > particular RCoA, no new security association should be 
> established > > for such RCoA; this is independent of the mobile 
> node's 
> > credentials.
> > 
> > > updates between the MAP and the mobile node MUST be protected 
> with > > either AH or ESP in transport mode. When ESP is used, a 
> non- null

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 27 Aug 2007 10:38:13 -0700

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

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 28 Aug 2007 12:46:19 +1000

Greg, 

Thanks a lot for the text. Good point about the residual times between
allocations of RCoAs. Folks, I'd like to include Greg's text in the draft,
let me know if there are any objections. 

Hesham 

 > From: Greg Daley [mailto:[email-masked]] 
 > Sent: Monday, August 27, 2007 10:58 AM
 > To: Hesham Soliman
 > Cc: 'Julien Laganier'; [email-masked]; 
 > [email-masked]; 'Vijay Devarapalli'
 > Subject: Re: RE: [Mipshop] Extension of the WG Last Call 
 > The Security Associations bound toFrom [email-masked] Mon Aug 27 22:48:20 2007
From: "Hesham Soliman" <[email-masked]>
To: "'Greg Daley'" <[email-masked]>
Subject: RE: RE: [Mipshop] Extension of the WG Last Call
	ondraft-ietf-mipshop-4140bis-00.txt
Date: Tue, 28 Aug 2007 12:46:19 +1000
Cc: [email-masked], [email-masked],
	'Vijay Devarapalli' <[email-masked]>

Greg, 

Thanks a lot for the text. Good point about the residual times between
allocations of RCoAs. Folks, I'd like to include Greg's text in the draft,
let me know if there are any objections. 

Hesham 

 > From: Greg Daley [mailto:[email-masked]] 
 > Sent: Monday, August 27, 2007 10:58 AM
 > To: Hesham Soliman
 > Cc: 'Julien Laganier'; [email-masked]; 
 > [email-masked]; 'Vijay Devarapalli'
 > Subject: Re: RE: [Mipshop] Extension of the WG Last Call 
 > > > the Regional Care of Address,
 > > > > the ones provided in the current  the IKEv2 exchange, and generates signature in the AUTH 
 > > > payload using

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 28 Aug 2007 12:45:03 +1000

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

 > From: Narayanan, Vidya [mailto:[email-masked]] 
 > Sent: Tuesday, August 28, 2007 3:38 AM
 > To: Hesham Soliman; Julien Laganier; [email-masked]
 > Cc: [email-masked]; Vijay Devarapalli
 > Subject: RE: [Mipshop] Extension of the WG Last 
 > Callondraft-ietf-mipshop-4140bis-00.txt
 > 
 > Hi Hesham, Julien,
 > has merit in my view.  I know pond.com
	with ESMTP
	id <20070828024508.CFEC21704.oaamta01ps.mx.bigpond.com@PC20005>;
	Tue, 28 Aug 2007 02:45:08 +0000
From: "Hesham Soliman" <[email-masked]>
To: "'Narayanan, Vidya'" <[email-masked]>,
	"'Julien Laganier'" <[email-masked]>, <[email-masked]>
Subject: RE: [Mipshop] Extension of the WG Last
	Callondraft-ietf-mipshop-4140bis-00.txt
Date: Tue, 28 Aug 2007 12:45:03 +1000
Cc: [email-masked],
	'Vijay Devarapalli' <[email-masked]>

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

 > From: Narayanan, Vidya [mailto:[email-masked]] 
 > Sent: Tuesday, August 28, 2007 3:38 AM
 > To: Hesham Soliman; Julien Laganier; [email-masked]
 > Cc: [email-masked]; Vijay Devarapalli
 > Subject: RE: [Mipshop] Extension of the WG Last 
 > Callondraft-ietf-mipshop-4140bis-00.txt
 > 
 > Hi Hesham, Julien,

we decided on a "MUST" on EAP to avoid

---

From: Julien Laganier <[email-masked]>
Date: Tue, 28 Aug 2007 17:46:24 +0200

> Hi Julien,

Hi Hesham,

> couple of responses below.

So are another couple of responses and questions.

> [...]
>  > > 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. 
>  >
>  > What is required is authentication of the MAP by the MN, otherwise
>  > a node can impersonate the MAP and discard/rewrite/insert
>  > local binding
>  > the traditional use of the term, i.e. verifying the MN identity,
>  > and binding the security association established with the MN to
>  > that identity.
>
> MN, otherwise another MN would steal it. But I do agree that the
> identity of the MN itself is not that 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.
>  >
> 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

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:

> [...]
>  > >  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. 
>
> 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

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 28 Aug 2007 08:53:30 -0700

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

---

From: Julien Laganier <[email-masked]>
Date: Tue, 28 Aug 2007 17:57:49 +0200

Hi Greg,

> Sorry about the delay, i hope these comments are still useful.

At least you're not alone being delayed, I am too...

I agree with everything you said below. I'd like to propose some 
additions to your text below...

> session keys or Least Recently Used caching of SAs with no

Add after last sentence above this sentence: "Both the MN and the MAP 
should make their possible to extend the validity of the negotiated SA 
to that of the established HMIPv6 binding for the corresponding RCoA. 
This includes use of appropriate SA lifetimes and re-negotiation of SA 
when needed."

> SA deletion, until the binding lifetime expires.

Me too.

--julien

> > > Agent.  It
> > > > is crucial that the security relationship between the
> > >
> > > mobile node and
> > >
> > > It seems to me that mutual authentication is not necessary in
> >
> > the
> >
> > > What is required is authentication of the MAP by the MN,
> >
> > otherwise a
> >
> > and
> > > send a local BU for a given RCoA is the same entity that
> >
> > initially
> >
> > > guarantying 'sameness', and consequently validating
> >
> > authorization to
> >
> > > > it presents a certificate signed by the same CA or by
> > >
> > > another CA that
> > >
> > 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
> >
> > avoid
> > one
> > > >    The MAP needs to set the SA for the RCoA (not the
> > >
> > > LCoA).  This can
> > >
> > > > be performed with IKE [2].  The mobile node uses its LCoA as
> > > > the source address, but specifies that the RCoA should be used
> > >
> > > in the SA.
> > >
> > > >  This is achieved by using the RCoA as the identity in IKE
> >
> > Phase 2
> >
> > > > 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
> > >
> > > does not seems
> > > to be specific to HMIP, that's what you would expect from any
> >
> > IPsec
> >
> > > > generate a new RCoA and restart the IKE negotiation.
> > >
> > > Alternatively, a
> > >
> > > > MAP may decide that, if a binding cache entry already exists
> >
> > for a
> >
> > > > typically only be used to protect signalling traffic when
> > >
> > > a MN moves,
> > >
> > > > and not for the actual data traffic sent to arbitrary
> > >
> > > nodes. Binding
> > >

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 28 Aug 2007 08:58:05 -0700

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.

Vijay

---

From: Julien Laganier <[email-masked]>
Date: Tue, 28 Aug 2007 18:01:50 +0200

Hi Vidya,

On Monday 27 August 2007, Narayanan, Vidya wrote:
>
> > > 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.
> >
> 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.

Agree.

> think is the point Julien was making.  It is an interesting point
> that has merit in my view.  

Good to hear.

> I know we decided on a "MUST" on EAP to 
> avoid forcing PSKs between MNs and MAPs (which is impractical) and to
> 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)...

BTNS specifies extensions to IPsec Peer Authentication Database (PAD) 
allowing to use unauthenticated public key material (e.g. self signed 
cert of raw public key) to "authenticate" the MN, which is exactly what 
we're talking about.

> 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.

Good.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Tue, 28 Aug 2007 18:20:18 +0200

Hi Hesham,

On Tuesday 28 August 2007, 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.

Great.

> 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.

I think we agree. What's needed w.r.t. the MN is "sameness", or as you 
put it, that "the MAP only needs to know that future BUs were secured 
by the same MN that it originally allocated the RCoA." 

I think this sameness 'property' can be satisfied in two ways, either: 

1- a single IKE SA with the RCoA as a traffic selector is kept from all 
the lifetime of the HMIPV6 binding for the RCoA, or

2- the MAP matches that IKEv2's IDi remains the same across IKE SA 
established to protect the HMIPv6 binding.

--julien

>  > 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"
>  > 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: Julien Laganier <[email-masked]>
Date: Tue, 28 Aug 2007 18:33:26 +0200

On Tuesday 28 August 2007, Vijay Devarapalli wrote:
> 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.

I think it depends on the specific deployment policy, MAP might want to 
authenticate, or might not want to (like in hotspots). 

It think the protocol should not force a specific deployment policy.

> visited network that hosts the MAP would like to charge for the
> "HMIPv6 service". This means the home network must be involved in the

I understand that, but as I said I don't think it is the job of a 
protocol spec to restrain deployment models beyond minimal requirements 
for the thing to be secure.

With what I'm proposing the minimum level of security is no 
authentication for MN (BTNS), and that is mandatory for 
interoperability purpose. Now a BTNS peer is also an IKEv2/IPsec peer, 
and as such support stronger methods of authentication. These can be 
used in specific deployment as they fit.

> certificate or with BTNS. But once a binding is created, the MAP
> ensures it is the same MN all the time.

Yes.

> security model. But this might prevent some of the deployments I

Good. The new security model can be summarized in "at minimum no RCoA 
binding theft. Stronger security measures can be implemented".

As such is does not prevent any deployment of stronger security since it 
is entirely possible than a BTNS peer does have a CA-signed certificate 
or uses EAP/IKEv2.

--julien

> 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.
> >
> > 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
> >
> >  > > agree that the identity of the MN itself is not that
> >  > > important. So Verifying the identity during the IKE exchange
> >  > > is
> >  > instance. In essence, if we separated the "identity" concept
> >  > from the "IP address"
> >  > 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
> >  > needed.  In those environments, it would be sufficient to go
> >  > with a self-signed cert

---

From: Julien Laganier <[email-masked]>
Date: Tue, 28 Aug 2007 18:34:08 +0200

On Tuesday 28 August 2007, Vijay Devarapalli wrote:
> scenarios where the MAP would need to authenticate the MN with the
> home network's help and authorize the MN for the "HMIPv6 Service".
>

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

> >> Thanks for the comments. As you said, I think we're in agreement.
> >> A couple of responses below.
> >
> >>  > >    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.
> >>  >
> >>  > the traditional sense of the terms:
> >>  >
> >>  > otherwise a node can impersonate the MAP and
> >>  > discard/rewrite/insert local binding
> >>  > 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.
> >>  > 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.
> >>  >
> > 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.
> >
> > "the MAP must authenticate to the MAP via any of the metyat
> > minimum, BTNS authentication of the MN to the MAP MUST be used.
> >
> >    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 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
> > 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.
> >
> >>  > 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 :)
> >>
> > To give more options it would be sufficient to write since
> > EAP/IKEv2 is a MAY already in IKEv2 spec.
> >
> >>  > >  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].
> >>  >
> >>  > 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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 28 Aug 2007 10:58:42 -0700

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

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Tuesday, August 28, 2007 8:54 AM
> To: Hesham Soliman
> Cc: Narayanan, Vidya; 'Julien Laganier'; [email-masked]; 
> [email-masked]
> Subject: HMIPv6 Security Model (Was Re: [Mipshop] Extension 
> of the WG Last Callondraft-ietf-mipshop-4140bis-00.txt)
> 
> Hello,
> 
> 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,
> > 
> > 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 
> > certs instead of EAP as the default mechanism. Let's do 
> this as a part of the comments on LC.
> > 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
> > 
> >  > From: Narayanan, Vidya [mailto:[email-masked]]  > Sent: 
> > Tuesday, August 28, 2007 3:38 AM  > To: Hesham Soliman; Julien 
> > Laganier; [email-masked]  > Cc: 
> > [email-masked]; Vijay Devarapalli  > 
> > Subject: RE: [Mipshop] Extension of the WG Last  > 
> >  > >  > But w.r.t. to the MN, I do not think the MAP needs 
> to  >  > > 
> >  > > verifying the MN identity, and  > binding the security  > > 
> >  > > => 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  > > 
> > > 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
> >  >
> > 
> > 
> 
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 28 Aug 2007 11:09:54 -0700

Hi Hesham,
One quick note below.  

> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: Monday, August 27, 2007 7:45 PM
> To: Narayanan, Vidya; 'Julien Laganier'; [email-masked]
> Cc: [email-masked]; 'Vijay Devarapalli'
> 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. 

I think we can point to RFC4306 and write some notes on what type of
client authentication is meaningful for what type of environments.  I
don't think we need to change any of the normative behavior already
specified for IKEv2.  I think we may be on the same page here, but, just
wanted to clarify. 

Thanks,
Vidya

>Let's do this 
> as a part of the comments on LC.
> 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 
>  > From: Narayanan, Vidya [mailto:[email-masked]]  > 
> Sent: Tuesday, August 28, 2007 3:38 AM  > To: Hesham Soliman; 
> Julien Laganier; [email-masked]  > Cc: 
> [email-masked]; Vijay Devarapalli  
> 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  > 
> necessarily to the  > identity as known by the EAP method (or 
> the IKEv2 IDi), for instance.
> the  > "IP address"
> 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
>  > 
> 
> 
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 28 Aug 2007 14:14:24 -0700

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

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 29 Aug 2007 10:22:33 +1000

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 

 > Sent: Wednesday, August 29, 2007 3:59 AM
 > To: Vijay Devarapalli; Hesham Soliman
 > Cc: Julien Laganier; [email-masked]; 
 > Subject: RE: HMIPv6 Security Model (Was Re: [Mipshop] 
 > Extension of the WG Last Callondraft-ietf-mipshop-4140bis-00.txt)
 > 
 > > completely agree 
 >  > > agree 
 > > > authentication on its identity should not be needed.  In 
 >  > those

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 29 Aug 2007 10:23:27 +1000

Hi Julien, 

Yes we completely and utterly agree :)

Hesham 

 > From: julien laganier [mailto:[email-masked]] On 
 > Behalf Of Julien Laganier
 > Sent: Wednesday, August 29, 2007 2:20 AM
 > To: Hesham Soliman
 > Cc: 'Narayanan, Vidya'; [email-masked]; 
 > Subject: Re: [Mipshop] Extension of the WG Last 
 > important.

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 29 Aug 2007 10:26:16 +1000

> specified for IKEv2.  I think we may be on the same page 

=> Agreed, we don't want to change anyhing in IKE, simply explain what can
be used for HMIPv6 (all of the IKE modes can be used actually).

Hesham

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 29 Aug 2007 12:25:52 +1000

The same question can be asked about the HA today, what MUST it implement?
Neither 3775 nor 3776 talk about EAP (IKEv2 wasn't around but that's beside
the point). Of course the drafts that specifically use AAA for bootstrapping
would mandate EAP. So I don't understand why the MAP case is a special case
that requires mandating one way or another.

Hesham 

 > From: Vijay Devarapalli [mailto:[email-masked]] 
 > Sent: Wednesday, August 29, 2007 7:14 AM
 > To: Julien Laganier
 > Cc: Hesham Soliman; [email-masked]; 
 > Subject: Re: [Mipshop] Extension of the WG Last Call 
 > typically not
 > >>>> for their deployments. AAA seems to be trendy now and 
 > people want
 > >>>> it :)
 > >>>> => Sure, but it gives more options for your favourite 
 > centralised
 > >>>> system.

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 28 Aug 2007 21:57:13 -0700

> that requires mandating one way or another.

The difference between a HA and a MAP is that the HA and the MN belong 
to a certain home network, and many authentication models become 
possible, like pre-shared keys, certs, *and* EAP.

3775 was even more easy. We assumed a static PAD (PAD wasn't around at 
that time, but the equivalent) on the HA. The HA has enough state 
already about the MN.

Vijay

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 29 Aug 2007 18:03:25 +1000

> possible, like pre-shared keys, certs, *and* EAP.

=> All these models are applicable to both the MAP and the HA. The question
being raised is why we need to mandate one way if the choice depends on the
deployment. Just like the HA didn't mandate one way (preconfig or
Certs...etc). 

Hesham

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 29 Aug 2007 10:39:42 -0700

I don't think there is any reason to mandate a particular authentication
method on the MAP, given that HMIP doesn't rely on a particular method.
The point is that identity authentication is optional for HMIP and it
depends on deployment needs.  It is not unlike how EAPoIKEv2 support is
mandated for untrusted accesses in cellular networks, while still
referring to RFC4306 (which itself doesn't mandate EAP, as we've been
talking about).  

Vidya

> Sent: Wednesday, August 29, 2007 1:03 AM
> To: 'Vijay Devarapalli'
> Cc: [email-masked]; [email-masked]
>  > > Neither 3775 nor 3776 talk about EAP (IKEv2 wasn't 
> around  > but that's beside  > > the point). Of course the 
> drafts that specifically use AAA  > for bootstrapping  > > 
> would mandate EAP. So I don't understand why the MAP case  > 
> is a special case  > > that requires mandating one way or another.
>  >
>  > The difference between a HA and a MAP is that the HA and 
> the  > MN belong  > to a certain home network, and many 
> authentication models become  > possible, like pre-shared 
> keys, certs, *and* EAP.
> 
> => All these models are applicable to both the MAP and the 
> HA. The question being raised is why we need to mandate one 
> way if the choice depends on the deployment. Just like the HA 
> didn't mandate one way (preconfig or Certs...etc). 
> 
> Hesham
> 
> 
> 
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 29 Aug 2007 11:02:16 -0700

> 
> One question for the working group is whether we are ok with 
> adding a Normative reference to draft-ietf-btns-core-04.txt.
> 
> Vijay

On this particular question, I don't currently see a need for a
normative reference to the BTNS work.  IKEv2 allows the use of PGP
certificates, which are much like self-signed certs.  What we have in
IKEv2 is more than sufficient for a normative reference.  An informative
reference to the BTNS work may be okay. 

Vidya

---

From: Julien Laganier <[email-masked]>
Date: Thu, 30 Aug 2007 17:31:06 +0200

Hi Vidya,

Some comments below,

On Wednesday 29 August 2007, Narayanan, Vidya wrote:
> IKEv2 is more than sufficient for a normative reference.  An
> informative reference to the BTNS work may be okay.

I think PGP certificates are more than self-signed certificates. Beside 
some additional information (validity dates, revocation check URL), 
self-signed certificates are more-or-less equivalent to a raw public 
key, they are not certified by any trust anchor. OTOH PGP certificates 
are certified by a web-of-trust and can be verified locally using the 
configured trust anchors. To me PGP certs are much more like X509 
certs, it is just the topology of trust delegation that differs (tree 
vs. web), but I digress :)

I think RFC4301 processing model itself does not specify how to handle 
self-signed certificates used for "authentication". The Peer 
Authorization Database of RFC4301 requires support for two types of  
authentication data, X.509 certificates and pre-shared secrets. It goes 
on with "For authentication based on an X.509 certificate, the PAD 
entry contains a trust anchor via which the end entity (EE) certificate 
for the peer must be verifiable, either directly or via a certificate
path". 

Other types of authentication data are not disallowed ("This document 
does not mandate support for any other authentication methods, although 
such methods MAY be employed."), but requires additional 
specifications.

How to authenticate uncertified public keys within the context of 
RFC4301 is to be specified by BTNS [I-D.ietf-btns-core].

So I think we need a normative reference to that document if we want to 
allow "authentication" with uncertified public keys.

--julien