[Mip4] Re: FWD: AD review of draft-ietf-mobileip-aaa-key-13.txt

[Tom Hiller <[e-mail]>]

(I sent this out yesterday and it bounced, so I am trying again.  Sorry if it is
a duplicate).

Thomas,


This email addresses comments on the aaa-keys-13 draft.  Except for security
comments regarding AAA key distribution to the HA/FA, I respond to comments
inline below.

The major comment appears to be the security of AAA key distribution that
operates in conjunction with the aaa-keys extensions.  Focussing on RADIUS,
RADIUS exposes the keys to the RADIUS proxies between the AAAH and the FA or HA,
and therefore, fails to meet security director guidelines for key mgt in AAA.
Those guideline state that keys should not be exposed to entities that do not
need to know.  RADIUS proxies do not need to know the MN-FA or MN-HA keys.

A way forward suggested by Russ is that the aaa-keys draft state the properties
to be provided by the AAA system for the transport of keys.  The following are
Russ's criterion for AAA key distribution from Atlanta:

Be algorithm independent protocol
Establish strong, fresh session keys
Maintain algorithm independence
Include replay detection mechanism
Authenticate all parties
Maintain confidentiality of authenticator
NO plaintext passwords
Perform client and NAS authorization
Maintain confidentiality of session keys
Confirm selection of “best” ciphersuite
Uniquely name session keys
Compromise of a single NAS cannot compromise any other part of the system,
including session keys and long-term keys
Bind key to appropriate context


(Refer to http://www.drizzle.com/~aboba/IETF56/ietf56-aaa.zip,
"AAA-key-mgt.ppt", slides 4-5).

Also: "only entities that need to know shall see the key; it is not in the ppt
file but I assume is included above confidentiality of session keys.  I think I
saw a file with this explicitly mentioned but cannot locate that file.

Would listing these as requirements for an AAA system to distribute keys be
sufficient (substituting "FA/HA" for "NAS")?   Should the list be further
summarized; if there is a better list, please advise.  If this approach would
work, I can find a logical place to include the requirements in the draft.

Further comments are appreciated.

thanks,
Tom



>
> ------- Forwarded Message
>
> From: Thomas Narten <[e-mail]>
> To: [e-mail]
> Date: Wed, 30 Jul 2003 11:54:59 -0400
> Subject: AD review of draft-ietf-mobileip-aaa-key-13.txt
>
> Here are my review comments. Overall, I think the document is in
> pretty good shape, but some wording clarifications would be
> good. Also, more analysis of the security weaknesses is probably
> warranted.
>
> Thomas
>
> Substantative:
>
>

>>      AAA security association
>>                    A security association between a AAA entity
>>                    and another node needing the services of that
>>                    AAA entity.  In this document all AAA security
>>                    associations are between a mobile node and its home
>>                    AAA server (AAAH). A mobile node's AAA security
>>                    association with its home AAA server (AAAH) may be
>>                    based either on the mobile node's IP address or on
>>                    its NAI [1].

>
>
> Could be more clear.
>
> In particular (based on later reading), the AAA association appears to
> consist of a name for it (i.e, the SPI plus addresses so that peers
> can agree on what AAA SA is being referred to) plus a key. The key of
> some size (used in Section 5).  Is there anything else that is
> contained in this SA? It would be good to just state that the it is
> simply a shared symetric key.


It is not a symmetric key.  The AAA-key length is not stated in section 5.  I am
interested in input on whether the AAA-key's key length belongs in RFC3012bis
and or in the aaa-keys draft.


Proposed edit

AAA security association        A security association between a AAA entity and
another node needing the services of that AAA entity.  In this document all AAA
security associations are between a mobile node and its home AAA server (AAAH).
A mobile node's AAA security association with its home AAA server (AAAH) may be
based either on the mobile node's IP address or on its NAI [1] along with its
SPI.  The key is referred to as "AAA-key" in this specification.


>
>

>>      Mobility security association
>>                    A Mobility Security Association is a simplex
>>                    connection that serves to authenticate MIPv4 control
>>                    traffic such as between a MN and HA and/or a MN and
>>                    FA. A Mobility Security Association is identified
>>                    by the two end points, such as a MN IP address and
>>                    a HA IP address, and a SPI. Two nodes may have one
>>                    or more Mobility Security Associations established
>>                    between each other; however, typically there is
>>                    no reason to have more than one Mobility Security
>>                    Association between two nodes.

>
>
> I.e., suggested rewording (and corrections, if I understand
> correctly):
>
>       Mobility security association
>
>                 A Mobility Security Association is a bi-directional
>                 connection that applies security services to RFC 3344
>                 MIPv4 control traffic between a MN and HA (or MN and
>                 FA) using RFC 3344 Authentication Extensions.  A
>                 Mobility Security Association is uniquely identified
>                 by the peer source and destination IP addresses and an
>                 SPI. Two nodes may have one or more Mobility Security
>                 Associations established between each other; however,
>                 typically there is no reason to have more than one
>                 Mobility Security Association between two nodes.


It is not a bidirectional connection.

Proposed edit

Mobility security association      A Mobility Security Association is a simplex
connection that applies security services to RFC 3344 MIPv4 control traffic
between a MN and HA (or MN and FA) using RFC 3344 Authentication Extensions.  A
Mobility Security Association is uniquely identified by the peer source and
destination IP addresses and an SPI. Two nodes may have one or more Mobility
Security typically there is no reason to have more than one Mobility Security
Association between two nodes.



>
>
>

>>      Registration Key
>>                    A key used as the basis of a Mobility Security
>>                    Association between a mobile node and a foreign
>>                    agent.  A registration key is typically only used
>>                    once or a very few times, and only for the purposes
>>                    of verifying a small volume of Authentication data.

>
>
> don't understand first sentence.
>
> Is Registration Key actually the key in the AAA Security Association?
> If so, better to just say so.
>
>


Agreed - proposed:

Registration Key
A key used in the Mobility Security Association between a mobile node and a
foreign agent.  A registration key is typically only used once or a very few
times, and only for the purposes of verifying a small volume of Authentication data.



>
>

>>    2. If the mobile node does not have a Mobility Security Association
>>       with the home agent, it MUST add an MN-HA Key Request extension
>>       (see Section 7.3) as part of its Registration Request that it
>>       sends to the Foreign Agent.

>
>
> Is there no other way for the MN to set up the MN-HA key other than
> via AAA? (Seems like the MUST is a bit strong.)


The context of that statement is you have to do this if you're using the methods
of this draft. If you're using some other method then that would be out of the
scope of this draft.



>
>

>>    1. Using the Key Material from the extension, the mobile node
>>       calculates
>>
>>          key = HMAC-MD5 (AAA-key, {Key Material || home address})

>
>
> what is AAA-key? Is this the key that is part of the AAA SA? Would be
> good to define this better (e.g, define a term, and use the term
> consistently). Also, does this key have any particular length or other
> properties?



See my comment on AAA Security Association above. I added the clarification on
AAA-key, and request input whether the AAA-key length should be defined in here
aaa-keys or in RFC3012bis.


>
>

>>      MN-FA Key Request Subtype Data
>>                       Data needed to carry out the creation of the
>>                       registration key on behalf of the mobile node.
>>                       This field is zero in length and carries no data.

>
>
> Would be better to have this field have the same name as is used in
> (say) section 5, where "Key Material" is used. Can we define a proper
> name for this field?
>
> Actually, why do you have this field at all, when it is defined to
> have zero lengh and carry no data?


The aaa-keys extensions have been designed into implementations. I don't recall
the history of the extension.  I suggest we not make changes unless the changes
are necessary to make aaa-keys work or be more secure.  It might be good to get
further input on this from other members of the group, however.


>
>
> Security considerations seems pretty weak. Where is the analysis of
> the weaknesses/vulnerabilities in the system? I.e, nothing is said
> about how keys are distributed within the AAA and how if that is weak,
> how it might result in compromise of the AAA key...


Please see my note at beginning of email

>
>

>>   One further detail deserves mention.  The Mobility Security
>>   Association to be established between the mobile node and the foreign
>>   agent have to be communicated to the foreign agent as well as to the
>>   mobile node.  The way that the key is distributed to the foreign
>>   agent is not relevant to any material in this document, and is
>>   expected to be handled as part of the AAA protocol processing between
>>   the AAAH and AAAL, and the further AAA protocol processing between
>>   the AAAL and the foreign agent.  Any method by which the key can be
>>   securely transmitted to the AAAL and then relayed (possibly with
>>   re-encryption) to the foreign agent, is outside the jurisdiction
>>   of any Mobile IP specification, and thus compatible (by reason of
>>   non-interference) with the protocol extensions specified in this
>>   document.

>
>
> Note: the above is not quite true. To understand the weaknesses of the
> proposed extensions, one has to make assumptions about the above. I.e,
> is the AAA SA key actually communicated to the FA via AAA? If so,
> there are huge potential vulnerabilities here (one can't just assume
> the AAA protocols are secure enough to not worry about this). I.e, is
> there an assumption that the AAA Key itself will be communicated  from
> the AAAH to AAAL (and the FA?).



Ditto, please refer to the top of this email.


>
>
> Nits:
>
> Could use a TOC (see ID nits, http://www.ietf.org/ID-nits.html)
>
>

>>                 AAA Registration Keys for Mobile IP

>


Agreed


>
> title doesn't satisfy ID nits? (Not sure AAA will be acceptable to rfc
> editor).


I have no problem with a different title, but there are RFCs with AAA in the
title (RFC2989).  Should we spell out AAA in the title, or find a completely new
title?


>
>

>>  the Authentication Data need by authentication extensions used in

>
>
> s/need/needed/ ?


Agreed


>
>

>>   It is also assumed that the AAA entities involved (i.e., the AAAH,
>>   AAAL, and the AAA interface features of the foreign agents and home

>
>
> AAAH and AAAL not defined/expanded in first use.


Agreed to expand.

>
>
>

>>   The key material may be requested by the mobile node in new
>>   extensions to Mobile IP Registration Request messages, and supplied
>>   to the mobile node in extensions to the Mobile IP Registration Reply
>>   messages.  Alternatively, the AAA server MAY provide unsolicited key

>
>
> s/new extensions/new extensions (defined below)/


Agreed.

>
>

>>   messages.  Alternatively, the AAA server MAY provide unsolicited key
>>   material to mobile nodes; the mobile node MUST then calculate new

>
>
> s/material/material via mobility agents/


Agreed


>
>

>>    8. If a MN-HA Key Material from AAA Key Material extension is
>>       present in the Registration Reply message, then the mobile node
>>       MUST create or update its Mobility Security Association with the
>>       Home Agent indicated in the Registration Reply, using the key
>>       computed from the Key Material in the AAA extension.  In this
>>       case, if no Key Material extension is present, the mobile node
>>       MUST discard the Registration Reply.  If the mobile node does
>>       not already have a Mobility Security Association with the Home
>>       Agent indicated in the Registration Reply message, and if no Key
>>       Material extension is present, the mobile node MUST discard the
>>       Registration Reply.
>>

>
>
> Is this last sentence needed? There is an AND in the if. But one o
> the ANDs is already covered bythe previous sentence (I think), in
> which case the RR is already supposed to be discarded.


Agreed

>
>

>>  The following steps are performed on the AAA server:

>
>
> AAAL or AAAH? (I assume the former).
>


It is the AAAH, not the AAAL.  Will fix by making it "AAAH".


>
>

>>    2. The mobile node creates the Mobility Security Association, using
>>       the key and the other relevant information in the Key Extension.
>>

>
>
> which MSA? the one to the HA or the one to the FA?


It could be either, how about s/"Association/Association(s)/"?


>
>

>>   The Generalized MN-FA Key Reply extension supplies a registration key
>>   requested by using one of the subtypes of the Generalized MN-FA Key

>
>
> not a "registration key", but "keying material"


Agreed


>
>

>>      MN-FA Key Reply Subtype Data
>>                 An encoded copy of the registration key, along with any
>>                 other information needed by the recipient to create the
>>                 designated Mobility Security Association.

>
>
> needs better text; this is not a key, its keying material. (do the
> same throughout document)


Agreed


>
>

>>   If the foreign agent receives a Registration Reply that has no MN-FA
>>   Key Reply extension, and if it has no existing Mobility Security
>>   Association with the mobile node, the foreign agent MAY change
>>   the Code value of the Registration Reply to MISSING_MN_FA (see
>>   section 8), effectively causing the registration to fail.

>
>
> Is this a typo? I thought the MN would get the RR, not the FA. How is
> the FA getting this?


In FA CoA mode of MIP, the FA receives the Reply first.


>
>

>>6.1. Generalized MN-FA Key Request Extension

>
>
> Note: It would seem to be better to rename this extension to be "Key
> Material" request or something, as this is NOT requesting a Key per
> se.


Agreed



>
> IANA Considerations:
>
>

>>   The Code value specified for error MISSING_MN_FA, listed in
>>   section 8, MUST NOT conflict with any other code values listed in
>>   RFC 3344, RFC 3024 [10], or RFC 2356 [11].  This value is to be
>>   taken from the space of error values conventionally associated with
>>   rejection by the foreign agent (i.e., 64-127).

>
>
> Above doesn't  quite make sense in IANA considerations. IANA doens't
> assign values that have already been assigned for other purposes. Or
> rather, they only do so if folks have just used a number for some
> purpose without bothering to allocate it properly from IANA. So, the
> above paragraph should be reworded to just say IANA assigns a TBD, and
> if there is a recommended value, suggest what it is). I.e, does the WG
> know more than IANA about the code values that are already in use?


Agreed


>
>

>>   Section 4 introduces the Replay Method Identifier namespace that
>>   requires IANA management.  This specification makes use of 1-3;
>>   all other values other than zero (0) or one (1) are available for
>>   assignment, pending review and approval by a Designated Expert [12].

>
>
> Better to use words like: IANA will create and maintain namespace for
> Replay Method Identifier as defined in Section 4. This
> specification...


Agreed


>
> In appendix C, I think you want to use a term other than "IP Security
> Association". First, its a term that is not defined. Second, it can be
> read to mean IPsec SAs, which I suspect is not actually the case.


Those security associations are in fact IPSec associations.  I will clarify that.


>
>
> ------- End of Forwarded Message
>





_______________________________________________
Mip4 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mip4