Subject: [AAA-WG]: Review of draft-ietf-aaa-diameter-mobileip-11.txt (fwd)

From: Bernard Aboba <[email-masked]>
Date: Fri, 12 Jul 2002 00:06:52 -0700 (PDT)

---------- 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

---

From: "Fredrik Johansson" <[email-masked]>
Date: Fri, 12 Jul 2002 14:08:25 +0200

Please see comments below.

/Fredrik

> won't happen until after the IETF meeting. My apologies for the delay.

This is done because otherwise we would need strong encryption of the keys
sent to the MN.

> considerations about the KDC feature of the protocol.

Perhaps the security consideration sections should say something on how to
chose the MN-AAA key since that key is used when creating the session keys.

> Specific Comments

The KDC generates all keys, but the only way to send the key to the MN
without having to have strong encryption is to do it via key material.

> {Key Material | node-addres}) or HMAC-SHA1. Do not recommend using

Sounds reasonable,

> integrity MUST be protected while on transit.

I suggest a section is added where we recomend the key to be refreshed but
the means is outside the scope of this document. This key is typically
somehting that you would get with the subscription or from your sysadmin and
I believe that better to leave it to the different deployment scenarios to
decide how and when to refresh this key.

> cryptographically generated session key. What is the argument for this?

Correct me if I'm wrong, but what difference does it make to the FA and HA
if they get a random number to use as key between them or if they get a
random number that has been hashed with some algorithm before sent to them,
as long as the number is sent in a secure way.

> be attached to CMS and this should not be the case.

I believe that the intention is that if the connection between say the AAAH
and the HA is protected via IPSec, then there is no need to further encrypt
the key since the whole communication is secured anyway, provided it's only
one hop between them. I.e. it should not be mandatory to use CMS or some
other end-to-end encryption mechanism in this case.

> Suggestion: deprecate option 1

Agree, make an example that suggest using 2 or 3.

---

From: Johan Johansson <[email-masked]>
Date: Fri, 12 Jul 2002 14:22:32 +0200

>other end-to-end encryption mechanism in this case.

Obviously if the session keys are to be encrypted the AAAF and the 
Originating-Foreign-AAA must negotiate a key and a cryptoalgorithm 
somehow. Since these nodes will typically be located in different 
realms, or the OFAAA avp would probably not be needed, it seems 
infeasible to use preconfigured keys. How then will the negotiation take 
place once CMS is ruled out? It can't be implementation or even 
deployment specific since we are talking about several administrative 
domains. Wouldn't it by necessity have to be specified in the standard 
to make the standard work, since interoperability is what standards is 
all about and so on?

>>SUggestion: Always encrypt the session key using permanent keys (AAA-keys)

I can't see a way to do this in a scalable way. Hopefully someone else can.

j

---

From: Tony Johansson <[email-masked]>
Date: Sun, 28 Jul 2002 15:38:14 -0700

All,

> {Key Material | node-addres}) or HMAC-SHA1. Do not recommend using

Agreed.

In section 5.2  Key Material vs. Session Key:

Remove:

"...
The following is an example of a session creation procedure, using
MD5 as the hashing algorithm. Additional algorithms are supported, and listed
in [MIPKEYS].

Where:

- AAA-Key is the long term secret shared between the mobile node and the AAAH.

- Key material is a random [RANDOM] value of at least 64 bits.

- node-address is the mobile node's identity. This is the contents of the
MIP-Mobile-Node-Address AVP, unless the value of the AVP is all zero or
ones, in which case of value of the User-Name AVP is used instead.

..."

Add:

"...
The following is an example of a session creation procedure, which the Mobile
Node has to comply with, using HMAC-MD5 as the hashing algorithm. Additional
algorithms are supported, and listed in [MIPKEYS] and from that list the
HMAC-MD5 or the HMAC-SHA1 are the recommended algorithms to be used.

key = HMAC-MD5(AAA-key,{Key Material | node-address})

Where:

- AAA-Key is the long term secret shared between the mobile node and the AAAH.

- Key material is a random [RANDOM] value of at least 64 bits.

- node-address is the mobile node's identity. This is the contents of the
MIP-Mobile-Node-Address AVP, unless the value of the AVP is all zero or ones,
in which case of value of the User-Name AVP is used instead."

Any comments...

BR,

/Tony

---

From: Tony Johansson <[email-masked]>
Date: Sun, 28 Jul 2002 15:35:42 -0700

All,

Final coming back to this one.

Since there are quite a few comments I've split my comments / text proposals
into a number of mails, so that we don't drown in one gigantic mail respond.

> material to the MN and sessions keys to the FA. It is not clear why this

Okay how about adding the following new section?:

".in 0
1.6  Key Distribution Center (KDC)

.in 3
In order to allow the scaling of wireless data access across administrative
domains, it is necessary to minimize the specific security associations
required. This means that each Foreign Agent should not be required have a
pre-configured shared security association with each Home Agent on the
Internet, nor should the mobile node be required to have a pre-configured
shared security association with any specific home agent or any specific
foreign agent.

Diameter Mobile IPv4 application solves this by including a key distribution
center (KDC), which means that after a Mobile Node is authenticated, the
authorization phase includes the generation of sessions keys.  Specifically,
three keys are generated and are required by [MOBILEIP]:

.in 11
.ti 2
- K1 Key, which will work as security association between the Mobile Node and
the Home Agent.
.ti 2
- K2 Key, which will work as the security association between the Mobile Node
and the Foreign Agent
.ti 2
- K3 Key, which will work as the shared between the Foreign Agent and the Home
Agent

Figure 9 depicts the new security associations used for Mobile-IP message
integrity using the keys derived by the DIAMETER server.

.in 9
.KS
          +--------+                      +--------+
          |Foreign |          K3          | Home   |
          |Agent   |<-------------------->| Agent  |
          |        |                      |        |
          +--------+                      +--------+
                  ^                        ^
                  | K2                  K1 |
                  |       +--------+       |
                  |       | Mobile |       |
                  +------>| Node   |<------+
                          |        |
                          +--------+
.in 3
.ce 1
Figure 9 - Security association after key distribution
.KE

If the home agent is assigned in the home network, each key is generated and
encrypted by the home Diameter server. If instead the home agent is assigned
in the foreign network the K3 key is generated and encrypted by the foreign
networks local Diameter server, while the K1 and K2 is still generated and
encrypted by the home Diameter server.

The keys destined for the foreign and home agent are propagated to the
mobility nodes via the Diameter protocol, and the keys must be encrypted
either by IPSec or TLS, when deployed in an environment without Diameter
agents, or encrypted by means described in [CMS] when deployed in an
environment with Diameter agents.

The keys destined for the mobile node must also be propagated via the Mobile
IP protocol and must therefore instead follow the encryption mechanisms
described in [AAAKEY]. This means that the keys distributed to the mobile node
are instead sent as key material, and the mobile node and the home Diameter
will use the material and the long term shared secrete to create the keys (see
section 5.2).

Once the session keys have been established and propagated, the mobility
devices can exchange registration information directly as defined in
[MOBILEIP] without the need of the Diameter infrastructure.  However the
session keys have a lifetime, after which the Diameter infrastructure must be
invoked again to acquire new session keys."

Comments are very appreciated and if some one have any additional text
proposals regarding this would be even more appreciated.

BR,

/Tony

---

From: Tony Johansson <[email-masked]>
Date: Sun, 28 Jul 2002 15:37:06 -0700

All,

> something different please clarify too.

Hmmm,  I'm not sure what to do with this one? I guess the question is -
should support for packet filtering rules be mandatory to support  or not in
the mobility agents?

1. If yes, then I guess we only need to clarify that all mobility agents MUST
implement support for filtering rules as defined in Base, so that the FA
and/or HA will always be able to receive and handle that MIP-Filter-Rule AVPs
that may be received in HAR/AMA.

2. If no is the case, thus not requiring that the FAs or the HAs must have
firewall support. In this case I think we need some more, like a small new
section with something like the following:

"1.9  Packet filtering support

This application has support for pushing packet filtering roles to either of
the mobility agents to enabling appropriate firewall controls for the
penetration of tunneled traffic between the home agent and the mobile node.
The packet filtering roles are set by the AAAH by adding one or more
MIP-Filter-Rule AVPs in the HAR if destine to the home agent and/or in the AMA
if destine for the foreign agent.

If MIP-Filter-Rule AVPs are included in the HAR and the home agent does not
have firewall support, the home agent MUST return a HAA with Result-Code AVP
equal to DIAMETER_ERROR_MIP_FILTER_NOT_SUPPORTED.

If the MIP-Filter-Rule AVPs are included in the AMA and the foreign agent does
not have firewall support, the foreign agent SHOULD log the event and MUST
issue a Session-Termination-Request (STR) back to its local Diameter server.

...

3.0  Result-Code AVP Values

...

DIAMETER_ERROR_MIP_FILTER_NOT_SUPPORTED 4008

This error code is used by the mobility agent to indicate to the home Diameter
server that the requested packet filter roles cannot be supported."

BR,

/Tony

---

From: Tony Johansson <[email-masked]>
Date: Sun, 28 Jul 2002 16:24:01 -0700

All,

> S3) "- AAA-Key is the long term secret shared between the mobile
>             node and the AAAH."
>

To solve the above, would something like this be apropriate to add in the
consideration section:

"10.0  Security Considerations
...
This specification also defines a method by which the home Diameter server can
create and distribute session keys to be used to authenticate Mobile IP
registration messages [MOBILEIP]. The key distribution is asymmetric due to
the fact the keys to the mobile node have to be propagated via the mobile IP
protocol [AAAKEY, MOBILEIP], while the mobility agent keys are propagated via
the Diameter protocol. This means that the keys destine to the mobility agents
are always protected by IPSec or TLS as defined in [BASE], when deployed
without any Diameter agents, or protected using the methods defined in [CMS],
when deployed in an environment that includes Diameter agents. The keys
destine for the mobile node are always sent as key material, which is used to
derive the actual keys, which means that it does not expose any data that
could be used in an attack aimed at recovering the long term key shared
between the mobile node and the home Diameter server.

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. Therefore, must also the long-term shared secrete between the
mobile node and the home Diameter server  be periodically refreshed, by
utilizing some out-of-band mechanism, since this shared secrete can not be
refreshed by any in-band mechanism."

Comments are very appreciated and if some one have any additional text
proposals regarding this would be even more
appreciated.

BR,

/Tony