Subject: RE: [mobile-ip] Concerns/comments for aaa-keys and gen-key

From: [email-masked]
Date: Tue, 2 Oct 2001 13:05:27 -0400

Erik,

I am the Chair of the TR-45 Adhoc Authentication Group (AHAG) which is
responsible for the development of security protocols and cryptographic
algorithms for North American wireless TDMA and CDMA networks.  I have some
experience in analyzing, integrating, and developing secret/symmetric key
authentication and key distribution protocols.  I also have some experience
in defining a formal cryptographic/security development process.

I'm somewhat troubled by many of the current proposals that represent a
significant shift in the how the IETF may implement authentication/key
distribution for MIPv4 w/ Radius/Diameter AAA.  Unfortunately, I beleive
this is the result of a somewhat informal security design methodoly.  I'm
sure that you're well aware of the generally accepted approach to security
development:

1) Threat/Security Assessment

2) Security Requirements Document

3) Security Architecture/Model/Integration

4) Security Analysis/Review

(Note: Iterative process in which new threats can be added to initial
assessment and so on up to the security model)

Prior to implementing the development process, there should be Security
Development Policy document that at least informs people that when one step
in the process is complete and accepted, no further discussion on the issue
allowed.  For example, during the threat assessment phase, the group might
consider the disclosure of subscriber identity information a high priority
security threat.  In the security requirements step, the security
requirements document will state that subscriber anonimity is essential in
this standard/RFC.  Any later design proposal that does not implement
subscriber anonimity will be rejected.

I'm somewhat concerned that people are proposing Kerberos and other
authentication mechanisms when, from my perspective, the IETF has already
implied that a point-to-point(AAA-to-MN) authentication and key distribution
protocol would be used.  I recommend that the IETF stay focused on the
current issue of MN-HA and MN-FA key distribution within that context.

By this time next year, Verizon Wireless and Sprint PCS will have over 40
million potential MIPv4 w/AAA users. (not including the millions in Korea or
China)  Unfortunately, it is too late for the IETF to start over.  The TIA
TR-45 and 3GPP2 standards groups have already published standards based on
the existing authentication mechanisms within MIPv4 and Radius AAA.  Verizon
Wireless has analyzed the existing security extensively, identified numerous
vulnerabilities (ex. AAA-to-HA or AAA-FA links), and has defined security
solutions for the problems.  Procedures to bootstrap the MN-AAA key are
currently being defined (which is not a cryptographic process per se) and
implemented.  

We critically need a method of distributing the MN-HA key (and MN-FA key)
based on the root MN-AAA key.  The current proposal satisfies that need and
we accept the associated risks/vulnerabilities involved.  I hope you realize
that MIPv4 (or MIPv6) is only one component in a complete information system
with security mechanisms below (air-link) and above (application layer).
The IETF does not have to boil the ocean by addressing every potential
security concern within MIPv4.  

Once again, I suggest that the IETF approve the existing key distribution
proposal.  

However, I completely support the development of a new authentication and
key distribution architecture for MIPv6 and/or MIPv4 which is based on a
robust security design methodoly.

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]]
Sent: Friday, September 28, 2001 10:46 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [mobile-ip] Concerns/comments for aaa-keys and gen-key

Christopher,

> I have the following comments regarding your concerns with the current
> aaa-keys procedure:
> 
> 1) Keying material is used between the MN and FA (or MN and HA) because a
> Key Agreement Protocol is used as opposed to simply encrypting and
> distributing the MN-HA or MN-FA key.  The reason for using a key agreement
> protocol is that the MN-FA link and/or MN-HA link may be over-the-air
which
> is inherently more vulnerable to eavesdropping and cryptanalysis.  Please
> review the attached comments, originally sent to Charlie Perkins and Pat
> Calhoun, regarding the vulnerabilities associated with their original
> proposal to simply encrypt the MN-HA and/or MN-FA key for transmission to
> the MN.

I understand the requirement; I just wonder whether the suggested
protocols actually satisfy the security requirements.

*Based on the proposals within the current thread, I don't beleive that the
IETF understands what the security requirements for MIPv4 w/ AAA are or
where in the security development process you are.  Is there a specific
MIPv4 w/AAA security requirements document that defines the scope and
security goals to be acheived by the MIPv4/AAA architecture.  I do
understand that many security requirements are distributed throughout every
IETF document, however it is extremely difficult for a system developer or
security assessor to synthesize all these requirements - One document (like
the current MIPv6 Security Requirements) is essential.

> Key Agreement Protocols are well understood and have been used for many
> years in GSM and North American cellular/PCS networks to enable secure
> session key generation (in a symmetric/secret key system).

Has the security of those protocols been analysed in the open
literature? Do you have pointers to such analysis papers?

*I'm somewhat amused by your comment considering there are probably over 300
million GSM and ANSI-41 cellular/PCS phones currently using the equivalent
of the proposed key agreement scheme.  GSM has used key agreement to
generate session voice privacy keys for at least ten years while TR-45 CDMA
and TDMA handsets have been using key agreement to generate SSD and privacy
keys for approx. 5 years.

The published literature regarding key agreement is quite extensive.
However, in the more recent literature, authors only briefly describe the
proposed scheme because it is so basic.  Here's a few references as a start:

A. Menezes, P. Van Oorschot and S. Vanstone, "Handbook of Applied
Cryptography," CRC Press, 1996, pp. 497 - Point-to-Point update by key
derivation and non-reversible functions, etc...

M. Bellare and P. Rogaway, "Entity Authentication and key distribution",
Advances in Crypto - Crypto 93 Proceedings, Lecture Notes in Computer
Sceience Vol. 773, D. Stinson ed., Springer-Verlag, 1993.  

M. Bellare, R. Canetti, and H. Krawczyk, "A Modular Approach to the Design
and Analysis of Authentication and Key Exhange Protocols, Proceeding of 30th
Annual Symposium on the Theory of Computing, ACM 1998.

There are many more...

> Note: It is assumed that AAA links to other MIP entities (AAA, HA and FA)
> will be protected.

One of my questions was whether there was an assumption about encryption
being used to prevent evesdropping on these links, or if it is viewed
sufficient from the key agreement protocols if this communication 
is provided with integrity protection? Replay prevention or not?
(The term "protected" is a bit unspecific.)

* We are concerned about privacy on these links.  For example, subscriber
accounting information passed on the FA-to-AAA link must be protected.
There is also a concern about integrity protection - we don't want an
attacker to flip bits and possibly change access times, ids, etc...

> 2)  With regard the AAA-to-AAA, AAA-to-HA and AAA-to-FA links, 3G Wireless
> providers intend to protect these links using one of several techniques:
1)
> IPsec, 2) Linked encryption boxes, or 3) private commication links.
> Distribution of AAA keys is NOT OUR ONLY CONCERN on these links.  We
intend
> to encrypt all data between the AAA and HA/FA for subscriber privacy
reasons
> and other security concerns.  Assuming we intend to protect these links
> using techniques outside the scope of MIP, it is inefficient from our
> perspective to utilize a more elaborate key distribution scheme between
the
> AAA and other network infrastructure components (which are controlled by
the
> service providers).  In other words, we'll already have an SA established
> between these entities and don't need to deal with bootstrapping even
> another SA!
> 
> I do recognize that other implementations of MIPv4 will require more
> inherent security compliance (architecturally built-in SA establishment
> schemes) because most users/system operators will not have the security
> expertise/resources of large service providers.  I recommend that a
separate
> procedure/protocol be developed to satisfy this requirement without
delaying
> the implementation of the existing scheme.

There are subtly but importantly different interpretatiosn of what
you say above. Let me restate and see if you agree with either one of these:
 We know that the IETF protocols and mechanisms for securing the
communication
 between FA, AAA*, and HA will not satisfy the security requirements for
 3G wireless use. But don't worry because we will use other security
protocols
 to make sure we get adequate protection.
 We do need the aaa-key and related IETF documents to move forward in the 
 IETF so that we can get adequate protection for the communication 
 involving the MN.

or

 For other reasons we will be using non-IETF standard mechanisms for
securing
 the communication between FA, AAA*, and HA thus we do not care
 (and perhaps also "have not analysed") the security that the internet
drafts 
 propose to add for the communication between FA, AAA*, and HA.
 We do need the aaa-key and related IETF documents to move forward in the 
 IETF so that we can get adequate protection for the communication 
 involving the MN.

Does either of the above get close to being a restatement of what you said
in the paragraphs above?

* I agree with your characterization that Verizon Wireless (and the 3G
wireless industry) needs the IETF to move forward to establish adequate
protection for MN communications (the air interface is the most vulnerable
link).

However I can't commit solely to either of your two subtle distinctions.  We
do recognize that the existing MIPv4 w/AAA security is apparently based on a
flawed crypto development process (and to that extent I would agree with
your first distinction), but we also recognize that MIP is only one
component within a complete communications system (and that it could be
acceptable for the IETF to consider AAA-to-AAA, AAA-to-HA, and AAA-to-FA
encryption and/or authentication outside the scope of MIPv4 w/ AAA).

Finally, I want to reiterate my support for a new security architecture in
MIPv6 or a later revision of MIPv4 or AAA, however, the current key
distribution proposal will satisfy our security goals.

thanks,

chris

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 4 Oct 2001 16:33:05 +0200 (CEST)

> security concern within MIPv4.  

I hope nobody in the IETF is trying to boil the ocean.
But if the IETF wants to promote quality protocols we must care about
the interaction of Mobile IPv4 and Diameter since that is something
that the IETF is working on. Assuming that somebody else will solve
that problem would be a bit irresponsible.
Of course, we could have the mobileip-aaa-keys draft refer to an
abstract secure AAA service yet have enough detail that MN, FA, and HA
implementors can implement from the spec as a way of avoiding the immediate
issues, but Pat Calhoun doesn't want to do this. I haven't heard any comments
on that issue from anybody else.

I think I asked for a somewhat technical clarification on a statement 
you made in an earlier message and I haven't seen a response.

> You said:
> > expertise/resources of large service providers.  I recommend that a separate
> > procedure/protocol be developed to satisfy this requirement without delaying
>  For other reasons we will be using non-IETF standard mechanisms for securing

   Erik

---

From: Pat Calhoun <[email-masked]>
Date: Sun, 7 Oct 2001 14:55:29 -0700

> on that issue from anybody else.

don't think that's what I said. I was questioning whether this was
required. If it is, then it will be done.

PatC