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://ww
w.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
Mipshop ietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop
|