Subject: [Mipshop] Review of draft-vidya-mipshop-handover-keys-aaa-02

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 06 Jun 2006 16:55:25 -0700

I am probably overly critical in my review of this document, for a 
number of reasons, including for instance trying to hold this 
document to the standards of RFC 4101.  There are also several nits 
in the review which can be safely ignored, but if clarified will 
improve the document IMO.

Summary: The primary suggestion is to follow 4101 and provide a 
summary of the protocol in an easy to review/analyze format in the 
earlier parts of the document.  Next, I have a question on whether 
two seemingly complementary techniques (referring to the use of a 
message-ID and a sequence number field) are necessary for replay 
protection.  Vidya and I had a subsequent discussion and the 
conclusion was that there may be an advantage to keeping both 
techniques .  I think some of that comes from trying to protect 
against a sub-class of adversaries.  Perhaps inclusion of the threat 
model in the early parts of the document and referring to that model 
in the rest of the document might help clarify the purpose of the two 
fields, should they be kept in the final specification.  Even 
otherwise, inclusion of a protocol model and a threat model is 
strongly encouraged.

Please see inline for detailed comments.

best regards,
Lakshminath

 >Mipshop                                                     V. Narayanan
 >Internet-Draft                                            Qualcomm, Inc.
 >Expires: October 28, 2006                                N. Venkitaraman
 >                                                          Motorola Labs
 >                                                          H. Tschofenig
 >                                                                Siemens
 >                                                            G. Giaretta
 >                                                                  TILab
 >                                                           J. Bournelle
 >                                                                GET/INT
 >                                                         April 26, 2006

 >                       Handover Keys Using AAA
 >             draft-vidya-mipshop-handover-keys-aaa-02.txt
 >
 >Status of this Memo
 >
 >  By submitting this Internet-Draft, each author represents that any
 >  applicable patent or other IPR claims of which he or she is aware
 >  have been or will be disclosed, and any of which he or she becomes
 >  aware will be disclosed, in accordance with Section 6 of BCP 79.

 >  Internet-Drafts are working documents of the Internet Engineering
 >  Task Force (IETF), its areas, and its working groups.  Note that
 >  other groups may also distribute working documents as Internet-
 >  Drafts.

 >  Internet-Drafts are draft documents valid for a maximum of six months
 >  and may be updated, replaced, or obsoleted by other documents at any
 >  time.  It is inappropriate to use Internet-Drafts as reference
 >  material or to cite them other than as "work in progress."

 >  The list of current Internet-Drafts can be accessed at
 >  http://www.ietf.org/ietf/1id-abstracts.txt.

 >  The list of Internet-Draft Shadow Directories can be accessed at
 >  http://www.ietf.org/shadow.html.

 >  This Internet-Draft will expire on October 28, 2006.

 >Copyright Notice

 >  Copyright (C) The Internet Society (2006).

 >Abstract

 >  This document describes a AAA-assisted key management protocol to

 >  generate a handover key between a mobile node (MN) and an access
 >  router (AR) for the purpose of securing FMIPv6 signaling messages.
 >  As such, it specifies a message exchange between the MN and the AR
 >  and assumptions that must hold in order for this protocol to work.
 >  The idea is that the key derived between a mobile node and an access
 >  router through this protocol can be used in fast handovers.
{**
How is the last sentence different from the first? Can the key be
used to protect non-FMIPv6 fast handover signaling messages?  Perhaps
that can be clarified with "fast handovers with protocols other than
FMIPv6?"}

<snip>

 > 1.1.  Applicability

 >  Although this document is focused on FMIPv6, it is applicable to
 >  other protocols as well.  In the context of FMIPv6, the key derived
 >  using this protocol can be used to secure the Fast Binding Update
 >  (FBU) sent from the MN to the PAR as specified in FMIPv6 [1].  Other
 >  protocols may also use this mechanism as noted below.  For instance,
 >  CxTP [9] can also use this protocol to derive keys between the AR and
 >  MN to secure the CTAR message.  Additionally, keys between an MN and
 >  a MAP can be derived using this protocol for HMIPv6 [10] operation.
 >  This draft, however, does not address any details on how the protocol
 >  described in this draft may be used for CxTP or HMIPv6.

A number of acronyms being used for the first time in the document,
please expand them

2.  Terminology

 >  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 >  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 >  document are to be interpreted as described in RFC- 2119 RFC2119 [2].

 >  In addition, this document uses the following terms:

 >  MN-AAA Handover Master Key (HMK):

 >     A key that is shared between the Mobile Node and the AAA server,
 >     hereby referred to simply as the Handover Master Key. The HMK is
 >     never used directly to protect any messages.

 >  MN-AAA Handover Integrity Key (HIK):

 >     A key that is shared between the Mobile Node and the AAA server,
 >     hereby referred to simply as the Handover Integrity Key. The HIK
 >     is derived from the HMK and is used for authenticating the HKReq/
 >     HKResp messages between the MN and the AAA server.

 >  Handover Key (HK):

 >     Session key used to secure messages between the Mobile Node and
 >     Access Router.  A given HK between an MN and ARn is termed as HKn.

Secure any messages?  Or just fast handover signaling messages?

3.  Goals, Assumptions and Requirements

 >  The document generally follows the key management guidelines
 >  documented in [11].  This section describes the goals and assumptions
 >  that the protocol design is based on.

 >  o  A major goal of the protocol is to leverage the existence of AAA
 >     infrastructure to establish session keys for securing FMIPv6
 >     signaling messages.  AAA protocols are widely deployed today due
 >     to the usage of AAA-based network access authentication.  The AAA
 >     server is used to authenticate and authorize the MN for fast
 >     handovers prior to generation of the handover key.  The solution
 >     presented in this document relies on the AAA infrastructure to
 >     derive and distribute keying material for handover support.

Combining the last two sentences: "The handover keying protocol
(HKP) uses the AAA server to authenticate and authorize the MN for
fasthandovers and uses the AAA protocol for derivation and delivery of
the keying material."  Something like that.

 >  o  The protocol must be able to provide separation of the keys used
 >     for integrity protection and the derivation of the handover keys.

Does a protocol provide separation of keys?

 >     For this purpose, two keys are derived from the HMK for a given
 >     node - the Handover Integrity Key (HIK) and the actual Handover
 >     Key (HK).  The former is used to create the MAC (Message
 >     Authentication Code) in the signaling messages for the key
 >     management protocol described in this document and the latter is
 >     used for FMIPv6 signaling protection.

How about this?  To avoid reusing the HMK for two distinct purposes,
namely in a PRF for key derivation and in a MAC for integrity
protection, two keys are derived from the HMK -- an HIK, that protects
HKP messages and an HK that protects the FMIPv6 signaling messages.

 >  o  Unique key naming of the keys must be provided.  Key naming of the
 >     HMK and HIK is provided using the Network Access Identifier (NAI)
 >     of the MN.  In order to provide identity protection, it may be
 >     undesirable to reuse the same NAI as used for network access
 >     authentication.  For sake of identity protection, it may be
 >     desirable to have the AAA server to derive an ephemeral identity
 >     at the time of HMK creation that can be used in subsequent
 >     creation of handover keys.  Such privacy protection mechanisms are
 >     outside the scope of this document.  The HK is also named using
 >     the NAI - however, at some point, a valid MN Care-of-address and
 >     an SPI are associated with the HK.

The above is not very clear.  Could the identity protection text be
moved to security/privacy considerations?  That's out of scope anyway.
With that all keys are initially identified with the NAI and the HK will
be associated with an SPI.

<snip>

 > 4.  Protocol Overview

 >  This section provides a description of the procedure to obtain the
 >  Handover Key (HK).  We assume that the MN shares a key, called
 >  Handover Master Key (HMK), with the AAA server.  For the purpose of
 >  the protocol itself, the HMK may simply be a handover specific master
 >  key pre-shared between the MN and the AAA server.

 >  A Handover Integrity Key (HIK) is derived from the HMK at the MN and
 >  AAA server.  The HIK is used to provide integrity protection to
 >  messages exchanged by the MN and the AAA server.  Also, the actual
 >  Handover Key (HK) shared between the MN and the AR is derived from
 >  the HMK.  The derivation of these keys is described in Section 6.1.

 >  Figure 1 depicts the high-level protocol interaction.

 >          MN           AR                             AAAH Server
 >          |    HKReq.   |                                   |
 >          |  ---------> |                                   |
 >          |             |   AAA Request                     |
 >          |             |  ---------------------->          |
 >          |             |  AAA Response                     |
 >          |             |  <-----------------------         |
 >          |    HKResp.  |      (Keying material)            |
 >          |  <--------- |                                   |

 >  Figure 1: Protocol Operation

Please fix the figures.  The lines should go all the way to the
server, right?  Why is the AAA server shown as AAAH?

 >  The MN, upon attaching to an AR (say AR1) in a given administrative
 >  domain, sends a Handover Key Request (HKReq) message to the AR.  The
 >  MN creates a HKReq message including an NAI-like identifier (that was
 >  derived possibly during the time of HMK derivation), a message ID, a
 >  sequence number and the care-of-address (CoA).  The MN also generates
 >  a nonce and includes it in the HKReq message.  Further, the MN
 >  indicates the PRF algorithm that it chooses to use for key generation
 >  in the HKReq message.  The MN includes a MAC of the message fields in
 >  an MN-AAA MAC Mobility sub-option.  Upon receiving the HKReq from the
 >  MN, AR1 must first ensure that it has a valid neighbor cache entry
 >  for the CoA claimed by the MN.  AR1 further verifies the validity and
 >  uniqueness of the CoA claimed by the MN.  After verifying the
 >  validity of the CoA of the MN, AR1 forwards the HKReq message to the
 >  AAA Server.  The MAC in the HKReq allows the AAA server to
 >  authenticate the MN and to perform authorization for fast handoffs
 >  before deriving a unique and fresh session key, the Handover Key
 >  (HK1).

 >  HK1 will subsequently be used between the MN and the AR1 after a
 >  successful protocol execution.  The key derivation procedure for the
 >  Handover Key is defined as follows:

 >  HK1 = gprf+ (HMK, AAA Nonce | MN Nonce | AR1 ID | MN ID | "Handover
 >  Key"), where | indicates concatenation

 >  The AR1 ID is the IP address of AR1 as seen by the MN.  The MN ID is
 >  the NAI of the MN that is sent by the MN in the HKReq message.  The
 >  AAA and MN Nonces are nonces generated by the AAA server and the MN
 >  respectively for the purpose of HK1 derivation.  The function gprf+
 >  is defined in Section 6.1.

 >  After successful authentication and authorization, the AAA Server
 >  then sends two different parameters to AR1 - one of the parameters
 >  includes the key HK1 and the lifetime associated with it.  The other
 >  parameter, to be sent to the MN, includes the AAA Nonce.  The message
 >  is protected with the AR1-AAA SA when forwarded to AR1.

A few comments on the previous paragraph:

* how about: the AAA server sends two sets of parameters to AR1: HK1
and associated lifetime destined to AR1 and the AAA nonce to be sent to
the MN.

* contains the only reference to AR1-AAA SA. A clarification might be
in order?}

<snip>

 > 5.1.  Mobility Header Types

 > 5.1.1.  Handover Key Request (HKReq)

<snip>

 >     HKReq Fields

 >     Message Type

 >        A one octet field indicating the handover key exchange
 >        mechanism encoded in the mobility options, the value of which
 >        is taken from the IANA Handover Key Exchange Mechanism Type
 >        registry.  A value of '1' (to be assigned by IANA) indicates
 >        AAA-assisted handover key exchange.  Other key exchange
 >        protocols defined in future may define additional values.

 >     v

 >        Verify flag.  This is set by the MN to indicate that it may
 >        already share a key with the AR.

if v is set, is the MAC option a MUST/SHOULD/MAY ?

 >     PRF

 >        A 3 bit field indicating the PRF algorithm that the MN wishes
 >        to use for key generation.  This is the algorithm the MN
 >        proposes to use in the derivation of HIK and HK from the HMK.
 >        Currently, the value of 1 is assigned to indicate HMAC-SHA1.

 >     Reserved

 >        Set to 0; ignored on reception.

 >     Message ID

 >        A two octet random value used to uniquely match requests and
 >        responses and identify retransmissions.

 >     Sequence #

 >        A two octet unsigned integer used by the AR in combination with
 >        the message ID to detect retransmissions and replays.

My guess is only one of the two fields above may be required, but
more on that later

 >     Key Care of Address

 >        Sixteen octet field containing the IPv6 CoA for which the key
 >        is requested.

 >     Mobility Suboptions

 >        Variable length field of such length that the complete Mobility
 >        Header is an integer multiple of 8 octets.  This field contains
 >        one or more TLV-encoded mobility suboptions.  Valid mobility
 >        sub-options for this message include the following:

 >           Handover Nonce Mobility Option (new option defined in
 >           section Section 5.2.1 below)

 >           Mobile Node Identifier Mobility Sub-option, as defined in
 >           [3]

 >           MAC Mobility Option as defined in Section 5.2.2

 >           Timestamp Mobility Option as defined in Section 5.2.3

 > 5.1.2.  Handover Key Response (HKResp)

 >  A handover key response (HKResp) message MUST be sent from the AR to
 >  the MN in response to a HKReq message.  HKResp MUST carry suboptions
 >  appropriate to the key agreement mechanism requested in the HKReq,
 >  which the MN can use to derive a handover key.

The second "MUST" is vague.  Perhaps the requirement can be stated more
precisely.

 >  The HKResp message uses the MH Type value TBA2.  When this value is
 >  indicated in the MH Type field, the format of the Message Data field
 >  in the Mobility Header is as follows:

 >                                         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >                                         | Message Type   |v|PRF|Reserved|
 >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >         |         Message ID            |         Sequence #            |
 >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >         |        Status Code            |     Lifetime                  |
 >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >         |                        SPI                                    |
 >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >         |                                                               |
 >         .                                                               .
 >         .                        Mobility options                       .
 >         .                                                               .
 >         |                                                               |
 >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 >  Figure 3: Handover Key Response

 >     HKResp Fields

 >     Message Type

 >        A one octet field indicating the key exchange mechanism encoded
 >        in the mobility options, the value of which is taken from the
 >        IANA Handover Key Agreement Mechanism Type registry.  A value
 >        of '1' (to be assigned by IANA) indicates AAA-assisted handover
 >        key exchange.  Other key exchange protocols defined in future
 >        may define additional values.

 >      v

 >        Verified flag.  Set by the AR in response to a HKReq with the V
 >        bit set, if it verified the request.

Please use the same case for v throughout

 >     PRF Type

 >        A 3 bit field indicating the PRF algorithm that the AAA server
 >        used for key generation.  This is the algorithm used in the
 >        derivation of HIK and HK from the HMK.  If the AAA server
 >        accepts the algorithm proposed by the MN, it sets the value to
 >        the same as in the HKReq.  If not, the value in this field
 >        indicates the algorithm the MN must use to derive the keys.

s/must/MUST

 >        Currently, the value of 1 is assigned to indicate HMAC-SHA1.

 >     Reserved

 >        Set to 0; ignored on reception.

 >     Message ID

 >        A two octet random value used to uniquely match requests and
 >        responses and identify retransmissions.  This value is copied
 >        from the corresponding HKReq.

 >     Sequence #

 >        A two octet unsigned integer from the matching HKReq that
 >        triggered this message.

 >     Status Code

 >        One octet status code indicating the status of the request.

 >        0 - Success.

 >        129 - HKE_NOT_SUPPORTED.

 >        130 - CoA_AUTH_FAILED

 >        131 - ADMINISTRATIVELY_PROHIBITED.

 >        132 - HK_VERIFY_FAILED

 >        133 - MN_AR_MAC_REQD

 >        134 - INVALID_AUTH_VALUE

 >        135 - TIMESTAMP_REQD

 >        136 - INVALID_PRF_ALG

 >        137 - INVALID_MAC_ALG

 >        138 - INVALID_TIMESTAMP

Some error codes are not listed!

 >     Lifetime

 >        Lifetime of the handover key, in seconds.

 >     SPI

 >        Four octet Security Parameter Index for the handover key at the
 >        AR.  The SPI is used by the MN and the AR to identify the key
 >        when the key is used.

The AR picks this and the MN and AR use it to identify the HK,
right.  My recollection from a discussion earlier is that the SPI alone
is not sufficient to identify the key and instead <AR-ID, SPI> is used
at the MN and the SPI is used at the AR, right?  Where is that
specified?  Perhaps later in the document.

<snip>

 > 6.  Protocol Details

 >  The proposed protocol enables a MN to derive session keys (HKs) with
 >  an access router.  This section describes the key derivation process
 >  and the processing rules for the mobile node, the access router and
 >  the AAA server.

 > 6.1.  Key Derivation

 >  As mentioned earlier, the MN and the AAA server share a key for the
 >  purpose of handover key derivation, called the Handover Master Key

 >  (HMK).  The HMK may be a pre-shared key or may be derived between the
 >  MN and AAA server by means outside the scope of this document.  The
 >  HMK MUST be at least 64 bytes in length and SHOULD NOT be generated
 >  from a password.  The HMK MUST NOT be directly used to protect any
 >  data or derive handover keys.  The HMK is only used to derive the
 >  Handover Integrity Key (HIK) and the Handover Key (HK).

Some of the above is repetition; is it necessary?
Further, there is no need to expand all the key names etc.
Not sure I understand the notion of not directly using HMK to derive
handover keys, it is after all used to derive the HK!

 >  The HMK must be updated periodically to allow the derivation of
 >  cryptographically strong handover keys.

Small must and how frequently?  This belongs in SEC considerations
on the assumptions about the HMK.

 >  The MN and the AAA server MUST derive a Handover Integrity Key (HIK)
 >  and a Handover Key (HK) from the Handover Master Key. The PRF used in
 >  the derivation must be communicated by the MN to the AAA server in
 >  the HKReq message.  The AAA server may choose to mandate a different
 >  PRF type by indicating so in the HKResp message.  The key derivation
 >  follows the procedure explained in this section.

 >  For the purpose of deriving keys of variable length that depend on
 >  the PRF type and MAC algorithm used, this document uses an adaptation
 >  of prf+ defined in RFC4306 [5].  This function is termed "Generalized
 >  prf+ (gprf+)" and is defined as follows (where | indicates
 >  concatenation).

 >  gprf+ (K, S) = T1 | T2 | T3 | T4 ...

 >     where:

 >     T1 = PRF (K, S | Y)

 >     T2 = PRF (K, T1 | S | Y+1)

 >     T3 = PRF (K, T2 | S | Y+2)

 >     T4 = PRF (K, T3 | S | Y+3)

 >  continuing as needed to compute all required keys.  The keys are
 >  taken from the output string without regard to boundaries, depending
 >  on the length of the key required.  These lengths are dependent on
 >  the MAC algorithm and the PRF chosen.  For instance, if the HIK
 >  required is a 256-bit key and the PRF used yields 160-bit keys, the
 >  HIK will come from T1 and the beginning of T2.  Y is a two-byte
 >  hexadecimal value that may differ in different uses of gprf+.  Each
 >  key derivation procedure below explains the appropriate values of K,
 >  S and Y.

The explanation about the length of the key required is repetitious
and I think that the example is not needed.

s/byte/octet

If Y is different in different uses of the gprf+, shouldn't it be a
parameter of gprf+?

 > 6.1.1.  Handover Integrity Key Derivation

 >  The gprf+ is used as follows to derive the HIK.

 >  HIK = gprf+ (HMK, "Handover Integrity Key")

 >  where, the string Handover Integrity Key is a 22-character ascii
 >  string with no null termination.  The value of Y is the Message ID
 >  (in hex) from the HKReq sent by the MN.  The Message ID is used in
 >  the derivation to allow the values of HIK to change upon every
 >  instantiation of the gprf+ for this purpose.  Since the HIK
 >  derivation does not involve nonces or other changing parameters, the
 >  Message ID is included to avoid the use of the same HIK for a long
 >  time.  This really is provided to allow implementations that don't
 >  refresh the HMK appropriately to still be able to have changing HIKs.
 >  If the HMK is refreshed periodically, there is not a need to derive a
 >  new HIK at every HKReq/HKResp exchange.  However, at the time of this
 >  writing, it is felt that it will not be uncommon to configure a HMK
 >  and not change it for a long period of time.

 >  The actual length of the HIK required is determined by the PRF used
 >  in the derivation.  Note that the length of the HIK must be
 >  sufficient for the MAC algorithm used.  Hence, the choice of PRF must
 >  be done such that it results in a sufficiently long key that can be
 >  used by the MAC algorithm.

The above paragraph is not required.  First, the length semantics
are clear already.  The PRF algorithm's output length is not relevant
since prf+ is being used.

6.1.2.  Handover Key Derivation

 >  The gprf+ is used as follows to derive the HK (where | indicates
 >  concatenation).

 >  HK = gprf+ (HMK, "MN Nonce | AAA Nonce | MN ID | AR ID | "Handover
 >  Key")

there is an extra " above

 >  where, the string Handover Key is a 12-character ascii string with no
 >  null termination.  The MN Nonce is generated by the MN and
 >  communicated to the AAA server in the HKReq message.  The AAA nonce
 >  is generated by the AAA server and communicated to the MN in the
 >  HKResp message.  The MN ID is the NAI of the MN and the AR ID is the
 >  IP address of the AR as seen by the MN.  The value of Y for the HK
 >  derivation is set to 0x0000.

 >  The actual length of the HK required is determined by the PRF used in
 >  the derivation.  Note that the length of the HK must be sufficient
 >  for the MAC algorithm used in the protection of FMIPv6 signaling.
 >  Hence, the choice of PRF must be done such that it results in a
 >  sufficiently long key that can be used by the MAC algorithm.

Same as before: length of HK is dependent on the MAC algorithm used
for FMIPv6 and that's all. It does not depend on the PRF choice

 >  More details on the process leading to HK derivation and its usage
 >  can be found in sections below.

 > 6.2.  Mobile Node Considerations

 >  After attaching to an AR, an FMIPv6 capable mobile node SHOULD
 >  immediately proceed to obtain a session key between itself and its
 >  current AR.

 > 6.2.1.  Sending Handover Key Request Messages

 >  In order to derive a shared key with the AR, the MN MUST create a
 >  HKReq with a unique, random Message ID and a sequence number also
 >  starting at a random value.  The MN MUST also derive a fresh MN nonce
 >  that will be used in HK derivation and include it in the HKReq.  For
 >  subsequent retransmissions, the sequence number MUST be incremented
 >  by 1 and the Message ID MUST remain the same.

It is not clear why the Message ID and the Sequence number are
needed, but perhaps that is described later?  A one-liner here might be
useful.
Fresh nonce?  Do you mean random nonce?

 >  In order to obtain absolute replay protection, the MN SHOULD use the
 >  Timestamp mobility option defined in Section 5.2.3.

"Absolute" replay protection?  Please explain what, if any, replay
protection is offered with other mechanisms and explain why TSs are
required to claim replay protection.  Or, perhaps this can be moved to
later.

 >  The MN MUST indicate the PRF algorithm it used for HIK derivation and
 >  intends to use for HK derivation in the PRF field of the HKReq
 >  header.  A value of 1 indicates HMAC-SHA1.  That is the only value
 >  presently defined in this document.

Why refer to HMAC-SHA1 here?  If that is replaced in the future,
it would need to be done in multiple places.

 >  The HKReq sent by the MN MUST include the MN-AAA MAC Mobility Sub-
 >  Option.  The AUTH Value in the MN-AAA MAC option shall be calculated
 >  as follows:

 >  AUTH = prf(HIK, MH Data)

You mean MAC and not PRF?

 >  The prf used is indicated in the Algorithm Type included in the MAC
 >  Mobility Option.  At the time of writing of this document, the only
 >  value defined is 1 for HMAC-SHA1.

No need for the second sentence.  In the first sentence, replace the
prf with MAC.

 >  MH Data is the content of the Mobility Header up to and including the
 >  Algorithm Type field of this option.

 >  The MN should send a new HKReq before the expiry of the lifetime of
 >  the key obtained via the pervious HKReq.  Once a MN obtains a new
 >  key, it MUST discard the old key and use the new key for
 >  authenticating the FBU.

 >  If the MN does not receive a response after a configured timeout
 >  (HKEY_REQ_TOUT), it SHOULD retransmit the request for a maximum of N
 >  HO_KEYTRIES.  In each of the retry attempts, the MN MUST use the same
 >  message ID.  The default value of N_HO_KEYTRIES is 3.

Doesn't say anything about incrementing SEQ# in the retries; perhaps
that comes later?

6.2.2.  Receiving and Processing Handover Key Response Messages

 >  Upon receiving a successful HKResp message from the AR, the MN MUST
 >  ensure that the message contains the MN-AR MAC mobility option.  If
 >  not, it MUST silently discard the message.  The MN MUST ensure that
 >  the Message ID matches with that of the corresponding HKReq.  If
 >  there is a mismatch, it MUST drop the packet.  The MN MUST compute
 >  the handover key using the keying material contained in the HKResp
 >  message.  The key is computed as described in Section 6.1.  It is
 >  repeated here for completion.

Not required at all, I'd delete the derivation thing.  Why repeat
after only a few pages of the spec?  Furthermore, if something changes,
the updates may make this inconsistent in the document.

 >  HK = gprf+ (HMK, AAA Nonce| MN Nonce | AR ID | MN ID | "Handover
 >  Key"), where | indicates concatenation

 >  The AR ID is the IP address of the AR.  The MN ID is the NAI of the
 >  MN that is sent by the MN in the HKReq message.  The AAA Nonce is a
 >  nonce generated by the AAA server and included in the HKResp received
 >  by the MN.  The MN Nonce is the nonce generated by the MN and
 >  included in the HKReq message.  The PRF used is indicated by the PRF
 >  field of the HKResp message.

 >  The MN MUST verify the AUTH Value in the MN-AR MAC mobility option
 >  using the HK derived.  The MAC algorithm used is the one specified in
 >  the Algorithm Type field of the MN-AR MAC mobility sub-option.  If
 >  the MAC algorithm is not supported by the MN, it MUST discard the
 >  message.  If the AUTH Value verification fails, the MN MUST silently
 >  discard the message.

 >  Upon successful processing of the HKResp and derivation of the valid
 >  HK, the MN MUST store the SPI and lifetime associated with the key,
 >  as sent in the HKResp.

At this point the reader does not know what's in the HKResp
messages, so the above description seems to be in vacuum.  We know only
that there is a MAC and the associated verification rules, and the above
line says something about SPI and lifetime etc., without any explanation
of the use of those fields.

6.2.2.1.  Error Processing

 >  If the MN receives a HKResp with the Code set to
 >  ADMINISTRATIVELY_PROHIBITED, the MN MUST NOT send any more HKReq
 >  messages via that AR.  If the MN receives a HKResp with the Code set
 >  to HKE_NOT_SUPPORTED, it SHOULD use a different key exchange protocol
 >  to derive the handover key.  If the code is set to COA_AUTH_FAILED,
 >  it MAY retransmit the HKReq after a random time greater than
 >  HK_RETRY_INTERVAL.  However, the MN MUST NOT retransmit the HKReq
 >  more than N HO_KEYTRIES.  If the code is set to MN_AAA_AUTH_REQD, the
 >  MN MUST send a new HKReq with the MN AAA Authentication Option
 >  included.  If the code is set to INVALID_AUTH_VALUE, the MN MUST NOT
 >  send any more HKReq messages via that AR.  If the code is set to
 >  TIMESTAMP_REQD, the MN SHOULD send another HKReq using the Timestamp
 >  mobility option.  If the code is set to INVALID_TIMESTAMP, the MN
 >  SHOULD send another HKReq with the adjusted timestamp value.  If the

AUTH and MAC are interchangeable and I don't like that confusion.
It appears that you are saying an MN_AAA_AUTH_REQD might be sent, but it
is not clear when the AAA server might send that error code since the
rule might be that it MUST discard messages without MACs silently!
Actually that is not clear either!  I'd definitely say that the AAA
server MUST NOT send INVALID_AUTH_VALUE, as that introduces a
vulnerability: the AAA server becomes an Oracle for an attacker.

 >  code is set to INVALID_PRF_ALG, the MN MAY send another HKReq with
 >  the PRF Algorithm specified in the HKResp message.  If the code is
 >  set to INVALID_MAC_ALG in the MN-AAA MAC sub-option, the MN MAY send
 >  another HKReq with the Algorithm Type value set to that found in the
 >  corresponding field of the HKResp message.

6.2.3.  Returning to an Access Router

 >  When a MN attaches to an AR with which the MN believes it has a
 >  shared Key (for example the MN has an unexpired key it obtained when
 >  it was Previously associated with the access router), the MN MAY

s/Previously/previously

 >  request that the AR utilize the Key as long as the key has not

s/Key/key

 >  expired.  If the MN wishes to re-use the key, it MUST do so only
 >  after verifying that by sending a HKReq with the verify flag set.
 >  The message ID field in the HKReq is a freshly generated random
 >  number.  However the sequence number value in this HKReq MUST be
 >  greater than the sequence number in previous HKReq sent to the AR
 >  corresponding to the key.  The MN MUST include an MN-AR MAC mobility
 >  option in HKReq with verify flag set.  The MN-AR MAC Option MUST be
 >  the last option included in the HKReq.  The verify procedure serves
 >  two purposes: (1) It is used to verify that the AR still has the key
 >  and allows use of the key until the lifetime of the key and (2)It
 >  enables the MN CoA to be bound to the key.  If the verify request is
 >  not successful the MN SHOULD create a new MN-AR handover key by
 >  sending a HKReq with the MN-AAA Auth option .

Several problems with the text above:
1. The text about message IDs and sequence numbers is not clear,
especially the part about message IDs.  For the SEQ part, I am still
looking for a justification of the need for it, but perhaps it is
elsewhere in the document.
2. I guess the MAC is for PoP of the key; perhaps that might be stated.
3. It is not clear how the MN CoA is bound to the key, perhaps it is to
non FMIPv6 challenged folks.  A sentence on it might help!

 >  If the MN receives a HKResp with the code set to HK_VERIFY_FAILED, it
 >  SHOULD send another HKReq with the MN-AAA MAC Mobility sub-option to
 >  obtain a new handover key via the AAA server.

I see references to MN-AAA Auth option and MN-AAA MAC Mobility
sub-option; I guess they are different.  Please clarify.

 > 6.3.  Access Router Considerations

 >  If the HKReq message does not contain the MN ID Mobility Option, the
 >  AR MUST silently discard the message.  If the HKReq does not have the
 >  verify bit set, the AR does the following.

 >  If the HKReq message does not contain the MN-AAA MAC Mobility sub-
 >  option, it MUST silently discard the message.

 >  The AR MUST first determine if it has a pending request from the MN
 >  with the same message id.  If so and if the AR has already received a
 >  AAA response corresponding to the HKReq, the AR SHOULD retransmit the
 >  HKResp to the MN.  If the received message has the same message ID
 >  and the sequence number as before, the AR MUST drop the packet.  For
 >  further protection from replays, the rate of retransmissions of
 >  responses to MN MUST not be more than a preconfigured RETRANS_RATE.
 >  If the AR already forwarded this message to the home AAA Server but
 >  has not yet received a response from AAA server, the AR MUST silently

 >  discard the retransmitted request from the MN.  Note that the AAA
 >  protocol should independently perform its own retransmission.  If
 >  this is a new HKReq, the AR MUST check to determine if the MN-AAA MAC
 >  Mobility sub-option has been included in this message by the MN.  If
 >  it has been included, then the AR MUST forward the request to the
 >  home AAA Server.

Usually retransmission means (atleast in certain protocols that I am aware of)
that the sender doesn't change anything in the message.  In this case, the MN
is really preparing the message again and sending it.

I believe that only one of message-id and seq fields is needed.

With your current semantics, the processing rule about the same msg ID
and seq number comes before the same message ID, and "response
available" case

 >  If the AR expects timestamp-based replay protection, it MUST return a
 >  HKResp with the error code set to "TIMESTAMP_REQD".

 >  If it is a new HKReq, the AR SHOULD send a request to the AAA server
 >  only after successful validation of the CoA.  Section 7.4 provides
 >  additional discussion on the issues associated with address
 >  validation and some possible options for address validation.  If the
 >  AR fails to verify the CoA, it MUST send a HKResp with the code set
 >  to CoA_AUTH_FAILED.

Perhaps a sentence on what validation of the CoA would mean might be
useful here.  I am not sure it's a good idea to report AUTH failures.

 >  The AAA message is constructed using the appropriately defined
 >  attributes (illustrated in Appendix A for RADIUS and Appendix B for
 >  Diameter).  While creating the AAA request message, the AR MUST
 >  include the NAS-IP-Address AVP in the AAA message (e.g.  RADIUS
 >  Access Request) sent to the AAA server.  The AR MUST use its IP
 >  address as seen by the MN in this AVP.  This will be used as the AR
 >  ID in deriving the handover key.

 >  The domain name in the NAI is used to determine the AAA server to be
 >  contacted.

 >  If the AR receives a successful AAA response (e.g., RADIUS Access
 >  Accept) message from the AAA server, it MUST store the handover key
 >  received from the AAA server along with the CoA and MN ID and index
 >  it additionally with an SPI.  The AR MUST send the SPI, AAA Nonce and
 >  lifetime in the RADIUS message in the HKResp message to the MN.  The
 >  AR MUST include a MAC of the message created using the HK in the
 >  MN-AR MAC Mobility Sub-Option carried in the HKResp message.

 >  The AUTH Value in the MN-AR MAC option is created as follows.

 >  AUTH = prf (HK, MH Data)

 >  The prf used is indicated in the Algorithm Type included in the MAC
 >  Mobility Option.  At the time of writing of this document, the only
 >  value defined is 1 for HMAC-SHA1.

 >  MH Data is the content of the Mobility Header up to and including the
 >  Algorithm Type field of this option.

Starting at the "The AUTH value, this seems like repetition from
earlier and I recall stating several issues with it.  First, I'd suggest
deleting this.  If not, please see below:

1. Please replace AUTH with MAC.  That'd result in changes in a few
other places.
2. Replace prf with MAC.
3. No need to specify HMAC-SHA1 here again.

 >  If the AR received an MN-AAA MAC sub-option from the AAA server, it

"If": is this really an option? Is the MN-AAA MAC an option?

 >  MUST include that in the HKResp to the MN.

 >  If the AR receives an unsuccessful AAA response (e.g., RADIUS Access
 >  Reject) message from the AAA server, the AR MUST send an appropriate
 >  error code to the MN in the HKResp message.

 >  The AR SHOULD buffer the information to be sent to the MN for a
 >  maximum value of HKEY_REQ_TOUT, so that it can be retransmitted upon
 >  receiving a HKReq with the same Message ID and incremented sequence
 >  number.

 >  If an AR receives a AAA response message corresponding to a MN that
 >  is no longer connected to it, the AR SHOULD silently discard it.

 >  After retransmission timeout, if the AR does not receive a response
 >  from the AAA server, it MUST remove all state associated with the MN
 >  and MUST NOT send a response to the MN.

 >  When the neighbor cache entry for the CoA expires, the AR MUST
 >  disassociate the key and the corresponding CoA.  When the lifetime of
 >  the key expires, the AR should remove the SPI.

 > 6.3.1.  Returning Mobile Node

 >  If a mobile node believes that it shares a handover key with a valid
 >  lifetime with the AR, it may send a HKReq with the 'V' bit set.  If
 >  so, the AR MUST use the MN ID to lookup the MN and obtain the key.

s/MN ID/SPI

 >  If a key is present the AR MUST verify the AUTH value in the MAC
 >  option.  If it is valid, it MUST verify that the sequence number in
 >  the HKReq is greater than the value in the sequence number field in
 >  the previously received HKReq from the MN for the same key.  This
 >  ensures that the message is not a replay of a previous message with a
 >  verify bit set.  If the sequence number check fails the AR MUST
 >  silently discard the message.

Is the assumption on replay protection using the "same msg-id, diff
seq number" that the AR stores the entire message that it has forwarded
to the AAA server and compares it or does it just verify the msg-id and
respond back?

 >  If the sequence number check is successful and computed MAC matches
 >  the AUTH value included in the HKReq message, the AR SHOULD verify
 >  that the IP address is valid and is not claimed by any other node.
 >  If that procedure succeeds, the AR MUST send a response with the
 >  verified bit set including a MAC of the response.  Also, the AR MUST
 >  record the CoA of the MN as the IP address associated with the
 >  handover key for that MN, in addition to the MN ID (NAI).  If the
 >  MN-AR MAC Mobility Sub-Option is not present in the HKReq in this
 >  case, the AR MUST drop the message and return a HKResp with the error
 >  code set to "MN_AR_MAC_REQD".  Also, if the option was included but
 >  the AR was unable to verify the MAC, it MUST drop the message and
 >  return a HKResp with the error code set to "INVALID_AUTH_Value".  The

MAC_REQD is ok, but INVALID_AUTH MUST NOT be sent.  BTW, why is it
invalid AUTH and not MAC?  I may have asked that Q already.

 >  rate of transmissions of responses to MN MUST not be more than a
 >  preconfigured TRANS_RATE.  If the AR does not have the key and if the
 >  HKReq does not have the MN-AAA MAC Option, it MUST drop the message
 >  and return a HKResp with the error code set to "HK_VERIFY_FAILED".

The HK_VERIFY as useful as it might be, should be generic and should
not indicate whether the MAC failed, but instead should say something
like the AR wants to force the MN do full authentication

 >  If the AR does not have the key and the HKReq included the MN-AAA MAC
 >  Mobility Sub-Option, the AR MAY process the HKReq as though the 'V'
 >  bit was not set.

 > 6.4.  AAA Server Considerations

 >  A description of the actual AAA attributes is included in Appendix A
 >  and Appendix B.  The text in the Appendices are provided for

s/text/attributes  perhaps

 >  illustration only and these are expected to be specified in separate
 >  documents.  This section provides a brief description of the
 >  operation of the AAA server for this protocol.  The discussion is
 >  explained with RADIUS as the example AAA protocol, but applies
 >  equally to Diameter as well.

 >  If the MN cannot be authenticated by the AAA server, it MUST silently
 >  discard the HKReq message.  If authorization failed for the MN to use
 >  FMIPv6 at the AR it is visiting, the AAA server MUST return a
 >  response with the code set to ADMINISTRATIVELY_PROHIBITED.

 >  If the AAA server expects to use a PRF other than the one indicated
 >  in the HKReq message, it MUST return an error set to INVALID_PRF_ALG
 >  and set the PRF field in the HKResp to indicate the algorithm that
 >  must be used.  The AAA server, in this case, MUST include an MN-AAA
 >  MAC option with the AUTH Value computed using the HIK.

So I guess the MN-AAA MAC doesn't need to be present all the time?
That's not very clear

 >  The AAA server MUST derive a Handover Integrity Key (HIK) from the
 >  Handover Master Key (HMK) for the MN as specified in Section 6.1.

 >  If the AAA server is expecting timestamp-based replay protection in
 >  the HKReq, it MUST send an error set to TIMESTAMP_REQD in response to
 >  an HKReq that does not contain the Timestamp mobility option.  If the
 >  HKReq contains the Timestamp mobility option, it MUST be processed in
 >  accordance with Section 5.2.3.  If the timestamp sent by the MN does
 >  not match its own timestamp, the AAA server MUST send an error with
 >  the code INVALID_TIMESTAMP and include its timestamp in accordance
 >  with Section 5.2.3.  The AAA server, in this case, MUST include an
 >  MN-AAA MAC option with the AUTH Value computed using the HIK.

 >  Upon receiving a handover key request, the AAA server MUST verify
 >  that the MN-AAA MAC Mobility Sub-Option is present in the message.
 >  If it is absent, the AAA server MUST silently discard the message.
 >  Otherwise, the AAA server MUST verify the AUTH Value in the option.
 >  If it is invalid, the AAA server MUST silently discard the message.

 >  If it is valid, the AAA server must proceed with the handover key
 >  generation described in Section 6.1.  If the MAC Algorithm used by
 >  the MN is unacceptable, the AAA server SHOULD return an error of type
 >  INVALID_MAC_ALG, including an MN-AAA MAC option with the algorithm
 >  set to the desired value and the AUTH Value computed using the HIK.

 >  If the NAS-IP-Address AVP was not included in the request, the AAA
 >  server MUST return an error to the AR, indicating that the NAS-IP-
 >  Address is required.

 >  The AAA server MUST send a response back to the AR, including the AAA
 >  Nonce as well as the derived HK.  Note that the AAA protocol is
 >  expected to provide its own security between the AR and the AAA
 >  server for purposes of encrypting the HK.  The AAA server SHOULD
 >  include a lifetime for the HK in the RADIUS Access Accept message.
 >  The AAA server is, however, not required to store the key or the
 >  lifetime.

 > 6.5.  Indirect MN-AR Handover Key Exchange

 >  The MN may wish to derive a handover key with an AR when it is not
 >  directly attached to that AR.  This may happen in case the MN is
 >  using FMIPv6 service with pAR as its anchor (while moving rapidly
 >  across ARs, for instance) and its handover key with the pAR is about
 >  to expire.  In this case, the MN may need to refresh the key via the
 >  nAR it is attached to.

 >  To establish a new handover key with an AR, the MN simply sends HKReq
 >  message destined to that AR.  The CoA for such indirect refreshes
 >  SHOULD be set to NULL.  If the CoA is non-NULL, the pAR MUST check if
 >  the CoA provided in the HKReq is the same address that is tied to the
 >  NAI provided by the MN.  If that is not the case the pAR MUST reject
 >  the HKReq.  If the checks are valid, the pAR contacts the AAA server
 >  to establish a handover key as described before.

 > 7.  Security Considerations

 >  This section describes the security considerations for the protocol
 >  for establishing handover keys specified in this document.  The
 >  messages described in this document are intended to allow the
 >  establishment of a security association between the mobile node and
 >  access router for fast handoff purposes.  The protocol is loosely
 >  based on the Mobile IP-AAA model [12] where the MN-HA security
 >  association is derived using a AAA server.

 >  The handover key protocol described in this document transports the
 >  nonce from the AAA server to the MN and the MN derives its own

 >  handover key using the nonce and other parameters.

 >  The proposed protocol uses an NAI-like identity of the MN as the
 >  identity to derive the handover keys between the MN and AR.  This
 >  protocol does not provide active or passive user identity
 >  confidentiality.  If such confidentiality is desired, a service
 >  specific identity must be derived as part of the HMK bootstrapping
 >  procedure.

7.1.  Strength of the HMK

 >  The protocol relies on the HMK shared between the mobile node and the
 >  AAA server for handover key derivation.  It also relies on the
 >  security of the AAA protocol (RADIUS or Diameter) used between the AR
 >  and the AAA server for HK distribution to the AR.
{**What AAA channel properties do you require?  Confidentiality,
integrity and replay protection?}

 >  The Security Associations resulting from use of this protocol do not
 >  offer any higher level of security than what is already implicit in
 >  use of the AAA Security Association between the mobile node and the
 >  AAA server.  In order to deny any adversary the luxury of unbounded
 >  time to analyze and break the HMK, it must be refreshed periodically.
 >  The provisioning and refreshing of the HMK in the MN and AAA server
 >  is outside the scope of this document.

7.2.  Strength of the HIK and HK

 >  The protocol allows the derivation of the Handover Integrity Key
 >  (HIK) and the Handover Key (HK) from the HMK.  The HIK is shared
 >  between the MN and the AAA server and used in integrity protection of
 >  the HKReq message and in implicit authentication of the MN.  The AUTH
 >  value in the MAC option of the message is calculated using the HIK,
 >  allowing integrity protection.  By verifying proof of possession of
 >  the valid HIK, the MN is authenticated by the AAA server.

 >  The Handover Key (HK) is shared between the MN and the AR and is used
 >  in integrity protection of messages between the MN and the AR.  The
 >  AR uses the HK to compute the AUTH value in the HKResp message to the
 >  MN.  Also, when the MN sends a HKReq to the AR with the MN-AR MAC
 >  Mobility Sub-Option, it uses the HK to derive the AUTH value in it.
 >  Subsequently, when the MN and AR exchange FMIPv6 signaling messages
 >  (FBU/FBAck), the HK is used to protect the signaling.

The HK is known to the AAA server and the AAA server can spoof any
of these messages.  In other words, there is no MSK-TSK like derivation
procedure here.  Do you guys want to talk about that?

 >  This protocol allows the PRF used for key derivation to be indicated
 >  by the MN in the HKReq message.  Also, the AAA server may choose to
 >  deny the usage of the chosen PRF by specifying a different PRF in the
 >  HKResp messages.  Currently, HMAC-SHA1 is the only PRF for which a
 >  value has been defined in this document.  Future documents may define
 >  more PRF types and values.  The choice of the PRF must be done in

 >  keeping with the security properties of the desired key and the
 >  desired level of security.  Also, the MAC algorithm used in the
 >  creation of the AUTH value must be taken into consideration to
 >  determine the length of the HK and the HIK required.

7.3.  Replay Protection

 >  The proposed protocol uses a sequence number in combination with a
 >  message ID to detect retransmissions and replays at the AR.  It also
 >  allows the use of timestamp based absolute replay protection between
 >  the MN and the AAA server.  Using the sequence number alone provides
 >  limited replay protection.  Replay protection is provided as long as
 >  there is state corresponding to an MN at the AR.  An attacker may,
 >  however, cache a HKReq message sent on the link between an MN and AR
 >  and replay it at a sufficiently later time when the AR has no state
 >  for that MN.  In this case, the AR will end up sending a AAA request
 >  to the AAA server.  The HKReq will be successfully processed by the
 >  AAA server in this case, since the authentication data will be valid
 >  (as the attacker has not modified anything in the message).  The AAA
 >  server will create a HK corresponding to this message and will
 >  provide it to the AR.  However, it must be noted that the MN cannot

The MN or the attacker?

 >  obtain the HK, because, without the HMK, it cannot derive the key
 >  from the nonce.  Hence, this scenario does not lead to an adversary
 >  using FMIP services on the AR.  But, it does result in some minimal
 >  resource consumption at the AAA server (for computing the handover
 >  key).  The assumption from an accounting perspective here is that
 >  accounting at the AAA server will not be triggered until the MN
 >  actually starts using the FMIP service (in other words, until the MN
 >  sends an FBU to the AR).  If accounting for FMIPv6 is started based
 >  on when the handover key is derived, this issue could result in an MN
 >  getting charged for FMIP service due to an adversary.  To provide
 >  absolute replay protection, the use of a timestamp-based approach
 >  using the Timestamp mobility option is recommended.

I would have thought the need for message-ID *and* the seq #
would've been explained here.  I just strongly to remove the seq#. It
has very limited use for an interestingly limited adversary.

 > 7.4.  IP Address Authorization

 >  For FMIPv6 operation, the access router must ensure that a mobile
 >  node cannot redirect traffic belonging to any other node.  For this
 >  purpose, the access router must bind the handover key of a mobile
 >  node to its care-of-address.  The AR must ensure that the CoA claimed
 >  by the MN does not belong to any other node.

 >  IP address authorization may be done in different ways in different
 >  networks.  For example, where stateful address assignment is used, it
 >  is possible for a DHCP server to securely notify the AR (DHCP Relay
 >  Agent potentially) of the IP address assigned to the MN.  The AR may
 >  note the IP address to MN ID mapping at that time.  Also, when IPv6CP
What's IPv6CP, first use, please expand
 >  is used, it is possible for the AR to know the same mapping.

 >  When stateless autoconfiguration is used by the MN to obtain a CoA,
 >  SeND may be used to protect against the threats of ND in general.  It

Need a reference for SeND; expand ND
 >  must be noted that this protocol is not attempting to solve the
 >  general threats of ND itself.  Some other mechanisms may also be
 >  available for IP address authorization.  For instance, in cellular
 >  networks that do not have a broadcast link between the MN and a base
 >  station, the packets coming on the link between the MN and BS can be
 >  considered valid, since it is an authenticated point-to-point link to
 >  the MN.  In such a case, SeND is not required to achieve IP address
 >  authorization, even for of stateless IP address autoconfiguration. .

Not sure whether SEC considerations are complete given that the 
threat model is not available.

8.  IANA Considerations

<snip>

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 6 Jun 2006 21:17:32 -0700

Hi Lakshminath,
Thanks for taking the time to provide comments. I will start a separate
thread to discuss the replay protection (Seq #/Msg ID) issue you have
raised. 

We will try to incorporate the rest of your comments and update the
summary to provide a clearer picture of the messages exchanged. 

Thanks,
Vidya 

> -----Original Message-----
> From: Lakshminath Dondeti [mailto:[email-masked]] 
> Sent: Tuesday, June 06, 2006 4:55 PM
> To: [email-masked]
> Cc: Narayanan, Vidya
> Subject: Review of draft-vidya-mipshop-handover-keys-aaa-02
> 
>  >Mipshop                                                     
> V. Narayanan
>  >         |                        SPI                       
>              |
>  >         |                                                  
>              |
>  >         .                                                  
>              .
>  >         .                        Mobility options          
>              .
>  >         .                                                  
>              .
>  >         |                                                  
>              |