Subject: Re: [Mipshop] WG last call on SeND based handover keys for FMIPv6

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 31 Aug 2007 22:06:27 -0700

Folks,

The last call is expiring on the 3rd. Please review and comment. Note 
that 4068bis (FMIPv6) has a normative reference to this draft and needs 
to advance together with this draft.

Vijay

Vijay Devarapalli wrote:
> Hello,
> 
> This is to announce a working group last call for 
> draft-ietf-mipshop-handover-key-01. You can find the document at the 
> following URL.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-mipshop-handover-key-01.txt
> 
> The last call expires on September 3 2007.
> 
> The intended status for this document is Standards Track.
> 
> FMIPv6 has a normative dependency on this document. So this document 
> will be sent along with draft-ietf-mipshop-fmipv6-rfc4068bis to the IESG.
> 
> 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.
> 
> 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: Julien Laganier <[email-masked]>
Date: Fri, 7 Sep 2007 18:44:38 +0200

>On Saturday 18 August 2007, Vijay Devarapalli wrote: 
> Hello,
>
> draft-ietf-mipshop-handover-key-01.

[...]

> issues, please send an email saying you support advancing this

I have reviewed draft-ietf-mipshop-handover-key-01.txt (Sorry for being 
late), and I think the document is in good shape.

I support the document being sent to IESG after some comments, questions 
and suggested changes I have listed below are addressed.

Thanks,

--julien

-------------------------------------------------------------------------

[...]

>   2.2 Protocol Overview
>
>      The protocol utilizes the SEND secured Proxy Router Solicitation
>      (PrRtSol)/Proxy  Router  Advertisement  (PrRtAdv)  [FMIP] 
> exchange between the MN and the AR to transport an encrypted, shared
> handover  key  from  the  AR  to  the  MN.  The  MN  generates  a
> public/private  key  pair  for  encrypting/decrypting  the  shared
> handover key exchange, using th same public key algorithm as SEND.
                               ^^^
Typo.

[...]

>   3.1 Sending Proxy Router Solicitations
>
>      At some time prior to handover, the MN MUST generate a handover
>      key encryption public/private key pair, using exactly the same
>      public key algorithm with exactly the same parameters (key size,
>      etc.) as for SEND [SEND]. The MN can reuse the key pair on
>      different access routers but MUST NOT use the key pair for any
>      other encryption or authorization operation. 

Shouldn't the document also state that the key pair MUST NOT be used for 
any other signature operation?

>      In order to prevent cryptanalysis, the key pair SHOULD be timed
>      out after a maximum of HKEPK-LIFETIME or HKEPK-HANDOVERS
>      depending on which comes first. 

s/a maximum of HKEPK-LIFETIME or HKEPK-HANDOVERS/either a duration of 
HKEPK-LIFETIME or HKEPK-LIFETIME number of handovers, whichever occurs 
first/

Since HKPEPK-HANDOVERS refers to a number of handovers and not to a time 
I also suggest:

s/timed out/discarded/

I also think that it would be useful to either define HKEPK-LIFETIME and 
HKEPK-HANDOVERS upfront (although the names of the constant are pretty 
explicit), or adding a downstream reference to Section 3.7 where 
protocol constants are defined.

>      The  MN  SHOULD  send  a  Proxy  Router  Solicitation 
> (PrRtRSol) containing a Handover Key Encryption Public Key Option
> with the handover encryption public key. A CGA for the MN MUST be the
> source address on the packet, and the MN MUST include the SEND CGA
> Option and SEND Signature Option with the packet, as specified in
> [SEND]. The SEND signature covers all fields in the PrRtSol,
> including the 128 bit source and destination addresses and ICMP
> checksum as described in RFC 3971, except for the Signature Option
> itself. The MN also sets the handover authentication Algorithm Type
> (AT) extension field in the Handover Key Request Option to the MN's
> preferred FBU authentication algorithm. The SEND Nonce or Timestamp
> option is not necessary because the PrRtSol/PrRtAdv exchange  is  a 
> request/response  protocol  that  uses  a  message identifier to
> control replay attacks.

I think at minimum a SEND Nonce MUST be included in PrRtSol and copied 
back in PrRtAdv since the message identifier is not mandated by 4068bis 
to be random, and thus does nothing against replay attacks (4068bis 
says only the identifier is used so that "replies can be matched                    
to this message."

>      If the AR does not respond to the PrRtSol, as would be the case
> if the proxy router functionality is not deployed, the MN MAY include
> the Handover Key Request option in a standard IPv6SEND-protected
> Router Solicitation (RS) instead [RFC2461]. 

I'm not that familiar with FMIPv6 and don't understand in which 
situation the proxy router functionality would not be deployed but 
FMIPv6 support present. Thus I'm assuming that it means no FMIPv6 
support present, and I don't understand what would be the purpose of 
requesting a handover key when no FMIPv6 support is present.

Could you explain what I'm missing. That might also be clarified in the 
text.

[...]

>   3.2 Receiving Proxy Router Solicitations and Sending Proxy Router
>       Advertisements

[...]

>      If the proxy router functionality is not deployed and the
> Handover Key Request Option was instead received in an RS, the AR MAY
> reply as  described  above  in  a  standard  IPv6  SEND-protected 
> Router Advertisement (RA) unicast to the MN's care-of CGA. 

Here again, I don't understand the purpose. 

> The Key Hash field MUST be used to allow the MN to match public key

s/public key/the public key/

> used to encrypt the handover key with the corresponding key needed to

s/key/private key/

> decrypt it, since the RS/RA exchange does not include a message
> identifier. 

It seems the SEND Nonce contained in the RS/RA exchange could be used to 
match the public key used to encrypt the handover key with the 
corresponding private key needed to decrypt it. That would render the 
Key Hash field of HKReply useless.

>   3.3 Receiving Proxy Router Advertisements
>
>      Upon receipt of one or more PrRtAdvs secured with SEND and
> having the Handover Key Reply Option, the MN MUST first validate the
> PrRtAdvs  as  described  in  RFC  3971.  From  the  messages  that
> validate, the MN SHOULD choose one with an AT flag in the Handover
> Key Reply Option indicating an authentication algorithm that the MN
> supports. From that message, the MN MUST determine which handover key
> encryption public key to use in the event the MN has more than one.
> It does so by either matching the key hash field in the Handover Key
> Reply Option against the store of handover key encryption public keys
> or by using the same key as in the matching PrRtSol. 

Why are there two methods to determine the appropriate HO key encryption 
key?

[...]

>   3.4 Sending FBUs
>
>      When the MN needs to signal the previous AR using an FMIPv6 FBU,
>      the  MN  MUST  utilize  the  handover  key  and  the 
> corresponding authentication algorithm to generate an authenticator
> for the message. The MN MUST select the appropriate key for the AR
> using the AR's CGA and its previous care-of CGA on the AR's link. The
> MN MUST generate the authentication MAC using the handover key and
> the appropriate algorithm, then include the MAC in the FBU message as
> defined by the FMIPv6 document. As specified by FMIPv6 [FMIP], the MN
                 ^^^^^^^^^^^^^^^                  ^^^^^^^^^^^^^
Seems to me the FMIPv6 reference would fit better after 'FMIPv6 
document'.

[...]

>   3.6 Key Generation and Lifetime
>
>      The AR MUST randomly generate a key having sufficient strength
> to match the authentication algorithm. Some authentication algorithms
> specify a required key size. The AR MUST generate a unique key for
> each CGA public key, and SHOULD take care that the key generation is
> uncorrelated between handover keys, and between handover keys and CGA
> keys. The actual algorithm used to generate the key is not important
> for interoperability since only the AR generates the key; the MN
> simply uses it.

I find the last argument weird. The algorithm is important for 
interoperability since the MN has to support it. I don't understand 
what point is conveyed.

[...]

>   3.7 Protocol Constants
>
>      The following are protocol constants:
>
>      HKEPK-LIFETIME:  The  maximum  lifetime  for  the  handover  key
>                       encryption public key. Default is 12 hours.
>
>      HKEPK-HANDOVERS:  The maximum number of handovers for which the
>                         handover key encryption public key should be
>                         reused. Default is 10.

Regarding these limitation to usage of encryption public key, why don't 
we have two fields in handover key request and handover key reply so 
that a MN can propose to the AR HKEPK-LIFETIME and HKEPK-HANDOVERS 
values according to local policy in the request, and the AR can cut 
these values according to its own policy and send them back to the MN 
in the reply?

>   4.0 Message Formats
>
>   4.1 Handover Key Request Option
>
>      The Handover Key Request Option is a standard IPv6 Neighbor
>      Discovery [RFC2461] option in TLV format.

[...]

>      Fields:

[...]

See previous comment on adding two fields to carry HKEPK-LIFETIME and 
HKEPK-HANDOVERS values proposed by MN.

>   4.2 Handover Key Reply Option
>
>      The  Handover  Key  Reply  Option  is  a  standard  IPv6 
> Neighbor Discovery [RFC2461] option in TLV format.
>

[...]

>      Fields:

See previous comment on adding two fields to carry HKEPK-LIFETIME and 
HKEPK-HANDOVERS values chosen by AR.

[...]

>        Key Hash:  A 128-bit field containing the most significant
>                     (leftmost) 128 bits of a SHA-1 [SHA1] hash of the
>                     public key used for encrypting the handover key.
>                     The SHA-1 hash is taken over the presentation
> used in the Handover Key Encryption Public Key field of Handover Key
> Request Option from the solicitation message to which this message is
> a response. Its purpose is to associate the encrypted handover key to
> a particular decryption private key known by the receiver.

See previous comment on Key Hash not being needed when SEND Nonce is 
present.

Hope the review helps.

Best,

--julien

---

From: "James Kempf" <[email-masked]>
Date: Fri, 7 Sep 2007 14:52:35 -0700

Most of these suggestions look reasonable.  I have a couple followup 

>says only the identifier is used so that "replies can be matched

How about if this document requires that the message identifier MUST be 
random if the PrRtSol is used for key exchange? This would have the same 
effect but not introduce any additional options.

>Could you explain what I'm missing. That might also be clarified in the

The PrRtSol functionality requires that an access router have information 
about neighboring (in the geographical sense) subnets and access points. 
This information may, in certain deployments, be difficult to obtain. 
Therefore, deployment of the functionality is optional.

But I agree that this is does introduce a certain amount of additional 
complexity into the protocol. We could require that PrRtSol functionality be 
deployed for SEND handover key exchange. The effect of that, though, would 
be to require it for FMIP too since key exchange is required for FMIP. 
Unless another key exchange method (like the now apparently dormant AAA 
method) is standardized that doesn't require PrRtSol.

>Why are there two methods to determine the appropriate HO key encryption

Right, this is a typo. The PrRtSol/PrRtAdv is a request/response protocol, 
so the response can always be matched with the request that generated it, 
and the right key thereby determined.

>interoperability since the MN has to support it. I don't understand

The AR generates the key using an algorithm, then sends the key to the MN. 
This isn't like AAA keys, where the AAA server and the MN generate the 
independently using a shared secret. It's more like provisioning the shared 
secret in the first place, from which the AAA keys are generated. So the MN 
doesn't need to know the algorithm, just like it doesn't need to know how 
the provisioned shared key is generated for AAA keys.

>these values according to its own policy and send them back to the MN

Why does the AR need to be concerned about these constants? The public key 
is owned by the MN. The AR is not expected to cache it. Once the AR uses the 
key for encrypting a handover key, the MN's handdover key encryption public 
key is dropped.

            jak

---

From: Julien Laganier <[email-masked]>
Date: Tue, 11 Sep 2007 17:50:49 +0200

> On Friday 07 September 2007, James Kempf wrote:
>
> Most of these suggestions look reasonable.  

Good.

> I have a couple followup responses below:

My followups below too:

> >> with the handover encryption public key. A CGA for the MN MUST be
> >> the source address on the packet, and the MN MUST include the SEND
> >> CGA Option and SEND Signature Option with the packet, as specified
> >> in [SEND]. The SEND signature covers all fields in the PrRtSol,
> >> itself. The MN also sets the handover authentication Algorithm
> >> Type (AT) extension field in the Handover Key Request Option to the
> >> MN's preferred FBU authentication algorithm. The SEND Nonce or
> >> Timestamp option is not necessary because the PrRtSol/PrRtAdv
> >> exchange  is  a request/response  protocol  that  uses  a  message
> >> identifier to control replay attacks.
> >
> > I think at minimum a SEND Nonce MUST be included in PrRtSol and
> > copied back in PrRtAdv since the message identifier is not mandated
> > by 4068bis to be random, and thus does nothing against replay
> > attacks (4068bis says only the identifier is used so that "replies
> > can be matched to this message."
>
> How about if this document requires that the message identifier MUST
> be random if the PrRtSol is used for key exchange? This would have
> the same effect but not introduce any additional options.

Since the PrRtSol already contains additional options (SEND CGA and SEND 
Signature) I'd prefer adding another additional (SEND) option (i.e. 
SEND Nonce) rather than adding constraints on an otherwise independent 
FMIPv6 message field (i.e. "message identifier MUST be random if the 
PrRtSol is used for key exchange").

> >> If the AR does not respond to the PrRtSol, as would be the
> >> case if the proxy router functionality is not deployed, the MN MAY
> >> include the Handover Key Request option in a standard
> >> IPv6SEND-protected Router Solicitation (RS) instead [RFC2461].
> >
> > Could you explain what I'm missing. That might also be clarified in
> > the text.
>
> The PrRtSol functionality requires that an access router have
> information about neighboring (in the geographical sense) subnets and
> access points. This information may, in certain deployments, be
> difficult to obtain. Therefore, deployment of the functionality is
> optional.

Ok, now I understand, I missed that from 4068bis itself.

> But I agree that this is does introduce a certain amount of
> additional complexity into the protocol. We could require that
> PrRtSol functionality be deployed for SEND handover key exchange. The
> effect of that, though, would be to require it for FMIP too since key
> exchange is required for FMIP. Unless another key exchange method
> (like the now apparently dormant AAA method) is standardized that
> doesn't require PrRtSol.

I understand, and have no strong opinion on the matter.

> >> having the Handover Key Reply Option, the MN MUST first validate
> >> the PrRtAdvs  as  described  in  RFC  3971.  From  the  messages 
> >> that validate, the MN SHOULD choose one with an AT flag in the
> >> Handover Key Reply Option indicating an authentication algorithm
> >> that the MN supports. From that message, the MN MUST determine
> >> which handover key encryption public key to use in the event the
> >> MN has more than one. It does so by either matching the key hash
> >> field in the Handover Key Reply Option against the store of
> >> handover key encryption public keys or by using the same key as in
> >> the matching PrRtSol. 
> >
> > Why are there two methods to determine the appropriate HO key
> > encryption key?
>
> Right, this is a typo. The PrRtSol/PrRtAdv is a request/response
> protocol, so the response can always be matched with the request that
> generated it, and the right key thereby determined.

Ok.

> >>      The AR MUST randomly generate a key having sufficient
> >> strength to match the authentication algorithm. Some
> >> authentication algorithms specify a required key size. The AR MUST
> >> generate a unique key for each CGA public key, and SHOULD take
> >> care that the key generation is uncorrelated between handover
> >> keys, and between handover keys and CGA keys. The actual algorithm
> >> used to generate the key is not important for interoperability
> >> since only the AR generates the key; the MN simply uses it.
> >
> The AR generates the key using an algorithm, then sends the key to
> the MN. This isn't like AAA keys, where the AAA server and the MN
> generate the independently using a shared secret. It's more like
> provisioning the shared secret in the first place, from which the AAA
> keys are generated. So the MN doesn't need to know the algorithm,
> just like it doesn't need to know how the provisioned shared key is
> generated for AAA keys.

Ah, you're right -- I somehow managed to overlook the "generate" word, 
sorry.

> >>      HKEPK-LIFETIME:  The  maximum  lifetime  for  the  handover 
> >> key encryption public key. Default is 12 hours.
> >>
> >>      HKEPK-HANDOVERS:  The maximum number of handovers for which
> >> the handover key encryption public key should be reused. Default
> >> is 10.
> >
> > Regarding these limitation to usage of encryption public key, why
> > don't we have two fields in handover key request and handover key
> > reply so that a MN can propose to the AR HKEPK-LIFETIME and
> > HKEPK-HANDOVERS values according to local policy in the request,
> > and the AR can cut these values according to its own policy and
> > send them back to the MN in the reply?
>
> Why does the AR need to be concerned about these constants? The
> public key is owned by the MN. The AR is not expected to cache it.
> Once the AR uses the key for encrypting a handover key, the MN's
> handdover key encryption public key is dropped.

The handover key secures the handover operation for the AR. One might 
thus expects the AR to have its word to say about the desired security 
level of the handover key.

Since the security level of that handover key is bounded by the security 
level of the public/private encryption key pair, it might be desirable 
that the AR can say something about the desired security level of the 
public/private encryption key pair, i.e. HKEPK-LIFETIME and 
HKEPK-HANDOVERS.

What do you think?

--julien

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Sep 2007 09:24:23 -0700

Julien,

Only one remaining item, the rest I think we are in agreement on. I'll add a 
SEND nonce.

>public/private encryption key pair, i.e. HKEPK-LIFETIME and

But these constants don't apply to the handover key, they apply to the 
handover key encryption public key, i.e. the public key generated by the 
mobile node that is used by the router to encrypt the handover key. That key 
is completely controlled by the mobile node, is used once by the router in 
response to the PrRtSol then discarded by the router. Ultimately, it is the 
mobile node that controls the lifetime of this key pair, even if the router 
says that it should be something, the mobile node can simply ignore it. 
Since the router doesn't keep track of the key, it won't know whether the 
mobile node has timed the key out or not.

This does bring up a point, however. Currently, there is no lifetime on the 
handover key itself. We could add a field in the PrRtAdv for the handover 
key lifetime, and include an additional constant for the suggested default. 
Since the key is generated by the router, it seems to make sense that the 
router specify a lifetime. If the mobile node doesn't abide by that 
lifetime, it will be disappointed if it tries to use the key after the 
lifetime expires.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 11 Sep 2007 10:09:19 -0700

Hi,

> PrRtSol is used for key exchange").

Agree it makes sense to include a nonce option.

> Ok, now I understand, I missed that from 4068bis itself.

Put another way, we would like to make sure that the MN can still get its
packets from PAR even when it had no opportunity to exchange neighborhood
information.

-Rajeev
-- 
http://people.nokia.net/~rajeev

---

From: Julien Laganier <[email-masked]>
Date: Wed, 12 Sep 2007 17:27:19 +0200

James,

On Tuesday 11 September 2007, James Kempf wrote:
> Julien,
>
> Only one remaining item, the rest I think we are in agreement on.
> I'll add a SEND nonce.

Good.

Some replies inline below.

> >> > Regarding these limitation to usage of encryption public key,
> >> > why don't we have two fields in handover key request and
> >> > handover key reply so that a MN can propose to the AR
> >> > HKEPK-LIFETIME and HKEPK-HANDOVERS values according to local
> >> > policy in the request, and the AR can cut these values according
> >> > to its own policy and send them back to the MN in the reply?
> >>
> > The handover key secures the handover operation for the AR. One
> > might thus expects the AR to have its word to say about the desired
> > security level of the handover key.
> >
> > Since the security level of that handover key is bounded by the
> > security level of the public/private encryption key pair, it might
> > be desirable that the AR can say something about the desired
> > security level of the public/private encryption key pair, i.e.
> > HKEPK-LIFETIME and HKEPK-HANDOVERS.
> >
> >What do you think?
>
> But these constants don't apply to the handover key, they apply to
> the handover key encryption public key, i.e. the public key generated
> by the mobile node that is used by the router to encrypt the handover
> key. That key is completely controlled by the mobile node, is used
> once by the router in response to the PrRtSol then discarded by the
> router. Ultimately, it is the mobile node that controls the lifetime
> of this key pair, even if the router says that it should be
> something, the mobile node can simply ignore it. Since the router
> doesn't keep track of the key, it won't know whether the mobile node
> has timed the key out or not.

Agree that the mobile can simply ignore the router's word on PK 
lifetime, and that the router has no way to know if the mobile followed 
the advice.

However, security protocols typically assumes that legitimate parties 
behave accordingly to the protocol specification. Otherwise no security 
holds. For example IKE negotiates session key lifetimes yet one of the 
peer can simply publish the key thus defeating any trust the remote 
peer could have in the key remaining secure for the duration of the 
negotiated lifetime.

I'd thus expect both parties here (MN and router) to behave well, 
accordingly to the specification.

But maybe I'm wrong...

> This does bring up a point, however. Currently, there is no lifetime
> on the handover key itself. We could add a field in the PrRtAdv for
> the handover key lifetime, and include an additional constant for the
> suggested default. Since the key is generated by the router, it seems
> to make sense that the router specify a lifetime. If the mobile node
> doesn't abide by that lifetime, it will be disappointed if it tries
> to use the key after the lifetime expires.

Yes, I agree.

--julien

---

From: "James Kempf" <[email-masked]>
Date: Wed, 12 Sep 2007 08:37:35 -0700

Hi Julien,

> accordingly to the specification.

While it was true that IKEv1 negotiated SA lifetime, IKEv2 no longer does. 
As RFC 4306 says, it is not necessary for interoperability. That's what I am 
saying about this.

But I do think a key lifetime is necessary for the handover key, since that 
is being provisioned by the router rather than negotiated between the two 
sides as in IKE and therefore the router in a sense "owns" the key.

           jak

---

From: Julien Laganier <[email-masked]>
Date: Thu, 13 Sep 2007 09:36:45 +0200

Hi James,

On Wednesday 12 September 2007, James Kempf wrote:
> > lifetime, and that the router has no way to know if the mobile
> > followed the advice.
> >
> > However, security protocols typically assumes that legitimate
> > parties behave accordingly to the protocol specification. Otherwise
> > no security holds. For example IKE negotiates session key lifetimes
> > yet one of the peer can simply publish the key thus defeating any
> > trust the remote peer could have in the key remaining secure for
> > the duration of the negotiated lifetime.
> >
> While it was true that IKEv1 negotiated SA lifetime, IKEv2 no longer
> does. As RFC 4306 says, it is not necessary for interoperability.
> That's what I am saying about this.

I agree. 

> But I do think a key lifetime is necessary for the handover key,
> since that is being provisioned by the router rather than negotiated
> between the two sides as in IKE and therefore the router in a sense
> "owns" the key.

Right.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Thu, 13 Sep 2007 09:40:34 +0200

On Friday 07 September 2007, Julien Laganier wrote:
> > 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.
>
> I have reviewed draft-ietf-mipshop-handover-key-01.txt (Sorry for
> being late), and I think the document is in good shape.
>
> I support the document being sent to IESG after some comments,
> questions and suggested changes I have listed below are addressed.

All suggested changes, comments and questions I had w.r.t. 
draft-ietf-mipshop-handover-key-01.txt have been addressed on this 
mailing list. 

I fully support the updated document incorporating changes we agreed on 
to be be forwarded to IESG.

Best,

--julien

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Sep 2007 11:14:42 -0700

Hello,

The WG last call on draft-ietf-mipshop-handover-key-01.txt has concluded.

Vijay