Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R) Networks
draft-carroll-dynmobileip-cdma-05
Discuss
No Objection
(David Kessens)
(Margaret Cullen)
(Sam Hartman)
No Record
(Bill Fenner)
Note: This ballot was opened for revision 05 and is now closed.
Steven Bellovin Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2004-01-08)
Unknown
This is a complex document, and I don't guarantee that I found everything. However, I'm not thrilled with what I saw. The two biggest issues are replays and key handling. The problem of message replay may be fundamental, since they stress the ability to precompute the essential message from the MN to the Home RADIUS AAA server. (Btw -- is it RADIUS or AAA/Diameter?) If that message is precomputed -- possibly even at the factory -- it can't have a fresh timestamp, a nonce, etc. The procedures for passing around private keys are not adequate. It's a bad idea to pass them around in the first place, but if it has to be done, it should be done properly. "Properly" does *not* include sending them by ordinary mail in unencrypted form. A better scheme would be to encrypt them with a public key, the private key for which resides inside tamper-resistant boxes. The option of handset manufacturers sending many per-handset private keys to all the world's service providers is especially scary; I suggest that that option be dropped. A handset's private key should be generated by the handset and not exported. (Btw -- generating good 1750-quality random numbers may require special hardware, or at least special interfaces to things like the microphone input. Simple software fixes may not solve fundamental problems with such algorithms.) Preloading the public keys of all relevant service providers can be tricky, too, since new providers can appear, or existing providers may wish to roll over their keys. While the tendency of providers to want "locked" equipment does alleviate the first part of this concern, the second part remains. I understand why they don't want a PKI (though I think the concerns, as stated, are overblown and result from a misunderstanding of the concept); nevertheless, in addition to provider keys that may be preloaded, handsets should have a CA's key as well, to permit downloading of new keys for service providers. In that vein, the handsets need an authenticated way to know the current time, in order to process key expiration. In 4.11, there doesn't seem to be any mention of what keys are used to encrypt and authenticate messages to the MN. The problem described in 7.2 makes me nervous. I'm not at all convinced that an improbable level of expertise is necessary. A glossary of acronyms would be a useful addition.
Thomas Narten Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2005-02-09)
Unknown
Placeholder. This document violates a MUST NOT of radius, one that has security implications. Need guidance from AAA on how to proceed.
Bert Wijnen Former IESG member
(was Discuss)
No Objection
No Objection
(2005-02-08)
Unknown
Passing my DISCUSS to Thomas, since I will be off-line for (quite) a while
Brian Carpenter Former IESG member
(was Discuss)
No Objection
No Objection
(2005-06-06)
Unknown
I strongly suggest a Note to the RFC Editor to insert an IANA Considerations section stating that the IANA is not responsible for the PKOID registry.
David Kessens Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Harald Alvestrand Former IESG member
No Objection
No Objection
(2005-02-17)
Unknown
Reviewed by Suzanne Woolf, Gen-ART She points out what seems like significant weaknesses in the protocol - so much so that this would have no future as an IETF standard, if they are correctly identified. Should there be an IESG note that says "pestilence here", or some such? Like, for instance: This document describes an existing deployed technology that was developed outside the IETF. It uses RADIUS in a way incompatible with the RADIUS protocol, and practices the sharing of secret keys in public-key cryptosystems, which is not a practice the IETF recommends. Do not take this document as an example of good protocol design.
Margaret Cullen Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(2005-02-16)
Unknown
Section 4.6 states the need for integrity of the RSA public key when
it is distributed to MN manufacturers. The reason given is weak.
The document says that an invalid public key is programmed into a
terminal, then the terminal may be denied service. This is true,
but a bigger concern would the substitution of one public key
with another one, where the corresponding private key is controlled
by an attacker.
PKCS #1 Version 1.5 (as identified by [9]) is used in this protocol.
PKCS #1 Version 1.5 key transport is vulnerable to adaptive chosen
ciphertext attacks, especially when it is used to for key management
in interactive applications like this one. This attack is often
referred to as the "Million Message Attack," and it explained in
[CRYPTO98] and [RSALABS]. Exploitation of this vulnerability,
which reveals the result of a particular RSA decryption, requires
access to an oracle which will respond to hundreds of thousands of
ciphertexts, which are constructed adaptively in response to
previously received replies that provide information on the
successes or failures of attempted decryption operations. The AAA
server is such an oracle. The security considerations need to
explain how to avoid this attack. TLS includes protection against
this attack by exhibiting the same behavior in the face of decrypt
errors.
[CRYPTO98] Bleichenbacher, D. "Chosen Ciphertext Attacks Against
Protocols Based on the RSA Encryption Standard PKCS #1,"
in H. Krawczyk (editor), Advances in Cryptology -
CRYPTO '98 Proceedings, Lecture Notes in Computer
Science 1462 (1998), Springer-Verlag, pp. 1-12.
[RSALABS] Bleichenbacher, D., B. Kaliski, and J. Staddon.
Recent Results on PKCS #1: RSA Encryption Standard.
RSA Laboratories' Bulletin No. 7, June 26, 1998.
[http://www.rsasecurity.com/rsalabs/bulletins]
Sam Hartman Former IESG member
No Objection
No Objection
()
Unknown
Bill Fenner Former IESG member
No Record
No Record
()
Unknown