Subject: [AAA-WG]: new - draft-ietf-aaa-diameter-mobileip-12alpha1.txt

From: Tony Johansson <[email-masked]>
Date: Fri, 02 Aug 2002 12:00:58 -0700

All,

I have updated the draft to cover all of Luis comments below to
hopefully a satisfying level.  Please, review  this -12alpha1 and let me
know if you have any objection/comments or any additional text
proposals.

http://www.erilab.com/users/temp/draft-ietf-aaa-diameter-mobileip-12alpha1.txt

Thanks,

/Tony

Bernard Aboba wrote:

> ---------- Forwarded message ----------
> Date: Wed, 10 Jul 2002 09:07:58 -0400
> From: Luis A. Sanchez <[email-masked]>
> To: Bernard Aboba <[email-masked]>, Randy Bush <[email-masked]>,
>      "Wijnen, Bert (Bert)" <[email-masked]>
> Subject: Re: FW: request for review from AAA WG
>
> Bernard,
>
> Enclosed you will find a review of the
> <draft-ietf-aaa-diameter-mobileip-11.txt> Diameter Mobile IPv4
> application. There is more to review here including the CMS
> interactions
> . I have to finish a MIPv6 review first and then get back to CMS. This
>
> won't happen until after the IETF meeting. My apologies for the delay.
>
> Regards,
>
> Luis
>
> =================================
>
> General Comments
> ----------------
>
> - The document uses terminology used in other standards documents. For
>
> example, in the IPsec context, security associations are simplex and
> uniquely identified by the triple (IP address, SPI, protocol). It is
> not
> clear if there is a 1 to 1 mapping between IPsec security associations
>
> and the "security associations" between mobile nodes and AAA servers.
>
> - There is no explanation on the KDC functionality with message
> exchanges in the introduction section. This would help understand the
> feature.
>
> - The KDC part of the protocol is not symmetric. It sends keying
> material to the MN and sessions keys to the FA. It is not clear why
> this
> is the case.
>
> - The security considerations sections does not provide any
> considerations about the KDC feature of the protocol.
>
> Specific Comments
> -----------------
>
> Section 1.0
>
> 1) Combined with the Inter-Realm capability of the base protocol, this
>
>     application allows mobile nodes to receive service from foreign
>     service providers.
>
> Problem: Confusing sentence, what protocol?
> Suggestion: "... capability of the Diameter base protocol...
>
> 2) Strong authentication and confidentiality of session keys is
>     required, and it is recommended to be provided using the CMS
> security
>     application [CMS], but may be provided via other security
> mechanisms,
>     e.g. using mutually authenticated TLS or IPsec when deployed in an
>
>     environment without Diameter agents, then hop-by-hop security is
>     sufficient for protecting session keys.
>
> Problem: Missing a comma or period after "IPsec". Otherwise it reads
> as
> a recommendation to use IPsec only when Diameter agents are *NOT*
> present.
> Suggestion: "... but may be provided via other security mechanisms,
>     e.g. using mutually authenticated TLS or IPsec, when deployed in
> an
>     environment without Diameter agents, then hop-by-hop security is
>     sufficient for protecting session keys."
>
> Section 1.2
>
> 1) "This means that
>     without support of the AAA NAI extension, the FA may not be able
> to
>     guarantee, that the AMR well be destined to the same AAAH, which
>     previously authenticated and authorized the mobile node, since the
> FA
>     may not know the identity of the AAAH."
>
> Problem: extra word (well) found in sentence fragment.
> Suggestion: Please delete "well" in front of "be destined"
>
> 2) "Upon receipt of the HAA, the AAAH creates the
> AA-Mobile-Node-Answer
>     (AMA) message, includes the Acct-Multi-Session-Id that was present
> in
>     the HAA, and the MIP-Home-Agent-Address, MIP-Mobile-Node-Address
> AVPs
>     in the AMA message, enabling appropriate firewall controls for the
>
>     penetration of tunneled traffic between the home agent and the
> mobile
>     node."
>
> Problem: The authors mention firewall controls and there is no clear
> understanding on what exactly does it mean in this context. For
> example,
> does it means that one of the AVPs will include packet filtering rules
>
> that MUST be implemented in some firewall? If so, what are the
> selectors
> fields for these rules, what entity will push these rules to the
> firewall and how one validate the authenticity of the rules. One may
> also want to provide confidentiality to such rules. The latter can
> piggyback on the existing secured exchanged but it needs some
> clarification. As you can see this opens a can of worms.
>
> Suggestion: Please clarify what is meant by "firewall controls" and
> establish the exact operation and security model (if needed). If meant
>
> something different please clarify too.
>
> Section 1.4
>
> 1) If no security association
>     exists between the AAAH and the originating AAAF, the AAAH will
> make
>     use of the CMS application [CMS] to establish this association.
>
> Problem: This statement seems to imply that the only mechanism that
> can
> be used to establish a security association is CMS which contradicts
> previously made statements.
>
> Suggestion: Modify statement to include other mechanisms such as
> IPsec.
>
> 2) Figure 6: Mobile IP/Diameter Message Exchange
>
> Problem: Same figure caption as in figure 2.
> Suggestion: Change caption to indicated that it is "Figure 6: Mobile
> IP/Diameter Message Exchange when HA is in Visited Realm" or something
>
> similar.
>
> 3)  If the mobile node is allowed to keep the home agent the AAAH then
>
>     sends a HAR, which contains the Mobile IP Registration Request
>     message data encapsulated in the MIP-Reg-Request AVP and the MIP-
>     Home-Agent-Address AVP with home agent address, as well as any
>     optional KDC session keys, to the AAAF in foreign network 1.
>
> Problem: First time KDC is mentioned and no further explanation is
> given.
>
> Suggestion: Introduce the entire KDC feature first. Architecture view
> should suffice. Need to explain the security for each message
> exchange.
>
> Section 1.6
>
> 1) Diameter Session Termination
>
> Problem: When an STR is sent what happens to the session keys?
> Suggestions: All resources (including session keys) must be
> deallocated
> (destroy) at the AAAH.
>
> Section 5.1
>
> 1) A value of zero indicates infinity (no time-out).
>
> Problem: This setting is of high security risk. However useful for
> debugging purposes.
>
> Suggestion: Please make a note in the document indicating that this
> setting is not recommended since keeping session keys for a long time
> (no refresh) increases the vulnerability of the system.
>
> Section 5.2
>
> 1) The key sent to the mobile node is always in the form of key
>     material, which the AAAH does by generating a random [RANDOM]
> value
>     of at least 64 bits.
>
> Problem: The KDC system is asymmetric. It sends keying material in one
>
> case (to the MN) and session keys in other cases (FA).
>
> Suggestion. Make the system symmetric. THe home AAAH server MUST
> generate all session keys and send them to the MN, FA and HA
> respectively.
>
> 2) The following is an example of a
>     session creation procedure, using MD5 as the hashing algorithm.
>     Additional algorithms are supported, and listed in [MIPKEYS].
>
>        MD5(AAA-Key | key material | node-address | AAA-Key)
>
> Problem: For key derivation, this document recommends using
> MD5/prefix+suffix mode. Back in 1996 Bellare, Canetti and Krawczyk
> published a paper on crypto discussing how a keyed hash function used
> in
> append/pre-append mode is more susceptible to the "divide and conquer"
>
> attack, although impractical, than a keyed-hashed function using a
> keyed-IV instead. They also proved that cryptographic ally HMAC is as
> strong as the hash function used with it. One can no make such a
> statement with a key-hashed function used in prefix+suffix
> mode. As such, IPsec dropped RFC1828 and adopted HMAC-MD5 and
> HMAC-SHA1
> the latter truncated to 90bits. Another potential problem with
> MD5/prefix+suffix could come in if the nonsecret component of the key
> is
> variable length.  In that case, if you were using MD5(secret,
> nonsecret)
> = newkey, then someone might be able to see newkey and later observe
> an
> exchange where nonsecret' = nonsecret|1. Then the key would be
> MD5(newkey, 1) = newkey'.  You have to analyze the protocol very
> carefully to assure that this doesn't happen, but if you use HMAC, you
>
> don't have to worry about it.
>
> **Recommendation: Advise reader to derive keys using: key =
> HMAC-MD5(AAA-key,
>
> {Key Material | node-addres}) or HMAC-SHA1. Do not recommend using
> MD5/prefix+suffix.
>
> 3) "- AAA-Key is the long term secret shared between the mobile
>             node and the AAAH."
>
> Problem: The AAA key need to be chosen at random (or using a
> cryptographically strong pseudo-random generator seeded with a random
> seed), and periodically refreshed.  It is not clear that we can
> recommended a specific frequency for key changes as the attacks refer
> to
> above may seem practically unfeasible.  However, periodic key
> refreshment is a fundamental security practice that helps against
> potential weaknesses of the function and keys, and limits the damage
> of
> an exposed key.
>
> **Recommendation: Add a statement to ensure that both the Mobile Node
> and the AAA server refresh their shared AAA-key. THis could be done
> via
> the AAA protocol or some other out-of-band mechanism. For in-band
> refreshing the new key MUST be encrypted, authenticated and its
> integrity MUST be protected while on transit.
>
> 4) "The Foreign-Home session key is shared between two mobility
> agents:
>     the FA and HA. Since this key is not destined for the mobile node,
>
>     there is no need to follow the session key generation procedures
>     detailed above. Instead, the AAAH generates a random [RANDOM]
> value
>     of at least 64 bits for use as the Foreign-Home session key."
>
> Problem: This text seems to suggest that the security level required
> between the FA and HA is lower hence no need to create/use a
> cryptographically generated session key. What is the argument for
> this?
>
> Suggestion: Please explain. A symmetric protocol is easier to analyze
> and understand its security.
>
> Section 5.5.2
>
> 1) If the session key needs to be encrypted, the AAAF will check if a
>     security association can be established, using the CMS security
>     application [CMS] with the originating host found in the MIP-
>     Originating-Foreign-AAA AVP.
>
> Problem: Sessions keys MUST always be encrypted. This function seems
> to
> be attached to CMS and this should not be the case.
>
> SUggestion: Always encrypt the session key using permanent keys
> (AAA-keys)
>
> Section 6.0
>
> 1) In other words, AAA
>     servers MUST be able to create three session keys: the
> Mobile-Home,
>     Mobile-Foreign, and Foreign-Home keys.
>
> Problem: Inconsistent with previous statements. The message sent to
> the
> MN does not contain a session key but rather the keying material.
>
> Suggestion: Eliminate this problem by having the AAAH calculate all
> keys
> except in the case where the HA is in the foreign realm in which case
> the AAAF will calculate the session key for the HA.
>
> Section 6.8  MIP-Algorithm-Type AVP
>
> 1)   The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated,
> and
>     contains the Algorithm identifier used to generate the associated
>     Mobile IP authentication extension. The following values are
>     currently defined:
>
>        1   Prefix+Suffix MD5 [MOBILEIP]
>        2   HMAC-MD5 [HMAC]
>        3   HMAC-SHA-1 [HMAC]
>
> Problem: as explained before.
> Suggestion: deprecate option 1