[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Pls check: draft-carroll-dynmobileip-cdma-04.txt
AAA-doctors.
I am holding a DISCUSS on rev 3 of this document, see DISCUSS text below.
This was/is based on (I believe) a review on the OPS Directorate list,
by one of you. It seems now better to move this to AAA doctors.
So pls check if there is still a serious technical issue with the new
revision 4 of the document.
Pls also note, that in the meantime, the IESG review policy for documents
that conme in via RFC-Editor has changed in that:
- we only check for conflict with IETF standards and IETF ongoing activities
- the documents will ALWAYS get a disclaimer (on front page) that explains
that the document has NOT had complete IETF review, and that people
should carefully evaluate if it can be used in their own environment
But the below DISCUSS part of the review at least was valid on rev 3,
namely that it violated an existing IETF std.
I have not checked this yet myself, because I am about to leave for the
weekend (for my daugther's wedding). SO I figured that I'd foward this
to the AAA doctors team.
Thanks,
Bert
------
Bert Wijnen:
Discuss:
[2004-01-08] I do ask OPS Directorate to be easy on the documents that
come back for a second (or 3rd or...) time to iesg agenda,
so we don't bounce back documents many many times.
Yet... this is what I got back on this one
There are several editorial things and such, but for example this one:
Section 4.7
"the RADIUS AAA Server MUST initiate the DMU procedure by
including the MIP_Key_Request attribute in an Access Reject
message sent to the PDSN."
The RADIUS protocol defined in [RFC2865] does not permit
attributes to be sent in Access-Reject messages.
Seems to be in conflict with an existing IETF DS.
So that should become a DISCUSS, even at this late stage I think.
I see no web ballot, so here it is in email
Thanks,
Bert
-----Original Message-----
From: OPS Directorate reviewer
I find this draft to be difficult to understand.
The draft does not include a terminology section, so that I found myself
looking for the definition of various terms.
Also, I found myself looking for a description of the entities
involved in the protocol, and the operational model up front, so that it
is obvious what the protocol is trying to accomplish, who the parties are,
and what their security relationships are.
At various points I found myself scratching my head trying to understand
exactly what was meant by various statements:
For example, in the abstract it is stated that "The Dynamic
Mobile IP Key Update (DMU) procedure occurs at the IP layer directly
between the MIP Mobile Node (MN) and RADIUS AAA Server. " This suggests
that the MN is actually acting as a RADIUS client sending packets to the
RADIUS server, which isn't the case.
In the abstract it is also stated that the protocol is a "secure and
efficient mechanism"; personally, I'd prefer that these terms be excised
in order to let the reader make their own judgements.
Section 1
"DMU, however, may be performed in any MIP network to enable
secure and efficient bootstrapping of the shared secret between the
Mobile Node (MN) and RADIUS AAA Server."
Since RFC 2002 doesn't describe secrets shared between the MN and the AAA
server, only between the MN and HA, I was left wondering about the
operational model being used by this document. Since the document doesn't
divide normative from informative references, and doesn't even reference
RFC 2002, let alone any of the MIP/NAI or MIP/AAA drafts, it isn't evident
to me what the security assumptions are. This *really* needs to be
spelled out up front.
" By utilizing RSA encryption, the MN (or MN manufacturer) is able to
pre-generate MIP keys (and the CHAP key) and pre-encrypt the MIP keys
prior to initiation of the DMU procedure. By employing this pre-
computation capability, the DMU process requires an order of
magnitude less computation during the key exchange than Diffie-
Hellman Key Exchange. "
Which keys are we talking about? The MN-HA, FA-HA or MN-FA shared secrets
discussed in RFC 2002? What is "the CHAP key"? Does this relate to the
MIP/AAA draft? References, please.
Section 2.1
"By utilizing RSA Public Key Cryptography, MNs can be pre-loaded with
a common RSA Public (encryption) key (by the MN manufacturer) while
the associated RSA Private (decryption) key is securely distributed
from the MN manufacturer to each service provider."
Hmm. In public key cryptography it is the public key that can be
freely distributed, but the private key has to remain private. By sharing
the private key widely, aren't we compromising it? (at least for purposes
such as non-repudiation).
Figure 1 does provide some basic description of the packet flows, but it
does not go into sufficient detail.
Russ Housley presented a series of requirements for AAA key handling at
IETF 56, that lay out the requirements for publication of documents
describing the use of AAA keys. Based on this and other figure, I am unable
to determine whether Russ's requirements are being met.
Section 2.2
This section introduces a number of additional parties in the exchange,
other than just the MN, FA, HA and RADIUS server. However, it's not clear
from this and other sections what the trust relationships are between the
entities or how authentication occurs.
For example, the second paragraph talks about pre-provisioning of the
A-Key and SSD betwen the MN and "cdma2000 1X network", and how the RADIUS
server "delegates its authentication function." However, it is not
described how the RADIUS server communicates with the cmda2000 1X network
or what security is required in order to establish the delegation.
Section 4.7
"the RADIUS AAA Server MUST initiate the DMU procedure by including
the MIP_Key_Request attribute in an Access Reject message sent to the
PDSN. "
The RADIUS protocol defined in [RFC2865] does not permit attributes to be
sent in Access-Reject messages.
"The RADIUS AAA Server MUST include the AAA_Authenticator in the
Access Accept as a Vendor-Specific RADIUS Attribute."
What if the RADIUS server doesn't include this attribute? What happens?