Subject: [AAA-WG]: Re: advancing Diameter MIPv4

From: Bernard Aboba <[email-masked]>
Date: Wed, 13 Aug 2003 16:31:56 -0700 (PDT)

Comments below:

> I have a security question regarding changes I proposed for this draft: The
> security guidance for distributing keys is that "only those entities that need
> the key should see the key".

[BA] This was one of the elements of the guidance.  The entire
presentation is available here:

http://www.drizzle.com/~aboba/IETF56/AAA/AAA-Key-Mgmt.ppt

> Now then for the FA(s) to receive a key from the
> HAAA via TLS, 3GPP2 carriers have to open pinholes in the firewalls so TLS can
> run.  This exposes the 3GPP2 carrier to possible attacks due to all the
> pinholes being open, i.e., one per FA.

I presume that this concern exists on the HAAA, rather than the FA, no?
Today HAAAs typically only need to accept traffic from known AAA agents;
under this proposal they would need to accept AAA traffic directly from NASes.

> If instead the HAAA could send the keys under the
> protection of TLS in usual MIPv4-Diameter messages (e.g., the AMA message) to
> the AAAF, then AAAF could just proxy the message with key to the FA, which is
> all intra-domain.  Then there would not have to be as many holes in the firewalls.

I think this issue arises because the NAS initiates the key-related
traffic, and therefore a pinehole needs to be opened for the HAAA to receive that
traffic.  However, if the HAAA were to initiate the key-related traffic a "stateful inspection"
filter on the firewall would open the holes automatically.  Of course,
this would require the NAS to be able to receive keys from HAAAs, but
presumably the NAS knows which HAAAs it is attempting to get keys from so
it can screen out unsolicited traffic from other HAAAs.

> Also, there is some concern about the need for the Diameter clients to have the
> certificates to establish TLS to HAAA servers.  Having the TLS connection to the
> AAAF would solve this problem, albeit the keys are exposed to the AAAF.

Diameter clients either require TLS w/certs or IPsec (either certs or
pre-shared keys).  If only pre-shared keys are available, then IPsec is
the only option.  Are you saying that the preference is to use IPsec
w/pre-shared keys instead of TLS?

> Should we revisit the requriement for the AAAF to not see the keys, i.e., to
> allow it to see the keys and thereby reduce the functionality required at the
> Diameter client in the FA as well as the number of pinholes?

I'd suggest that we discuss the problem and figure out what the options
are for solving it.

> Note: It turns out that my slides from the IETF presentation show the "AAAF" and
> the "FA" as being merged in figures 8, 9, and 10.  This was not intentional,
> however, it's just inherited from the original draft.
>
> To find the MIPv4-Diameter presentation from the AAA WG:
> http://www.drizzle.com/~aboba/IETF57/AAA/
> and click "MIPv4-Diameter Edit.ppt".
>
> thanks,
> Tom