Subject: [Mipshop] Review of draft-vidya-handover-keys-aaa-02.txt

From: "James Kempf" <[email-masked]>
Date: Mon, 29 May 2006 04:39:55 -0700

This is my second review of this document. I reviewed an earlier draft of
the document. This draft seems to have addressed most of the issues I found
in the earlier draft.

High Level Comment:

This protocol strikes me as being somewhat complex. I did not make a
concerted effort to dig out possible security holes, but I think it could
use some deeper study, and, in particular, I really think someone should
implement it before it is standardized. I know that is not required for
non-routing protocols, but I think it would be a good idea.

Detailed Comments:

pg 7, paragraph 1: The term "PRF algorithm" is used without definition. It
should be included in the terminology section.

pg 7, paragraph 4: The IP address of the AR is being used to identify the
AR, but the text does not say what IP address. If the address is not global,
there is a possibility of confusion if an AR on another link uses the same
link local address.

pg. 9, Message Type: There is no IANA Handover Key Exchange Mechanism Type
registry. If the message type is a mobility header type indicator, then it
comes from the mobility header type registry. Since the HReq is send in a
Mobility Header, this must be a mobility header type.

pg 9, again PRF is used without definition.

pg. 11: Same as the last two. Also, it might be best to make the values
TBD-IANA1, TBD-IANA2, etc. and let IANA do the allocation, unless you really
want to set the number at '1'.

pg. 12: These are a lot of status codes and it is not clear to me that the
protocol gets much use out of having so many. More about this below.

pg. 17: The key derivation algorithm described here seems to be somewhat
complex. What security benefit is derived from this complexity? If any, then
it should be described in the document.

pg. 20, paragraph 1: This must make it clearer how authentication is
validated. From my reading of the text, it currently only requires that the
MAC mobility option be there, not that it be checked. Unless the check is
specified somewhere else in the text and I missed it.

pg. 20, last paragraph: I think it would be easier to read these status
codes if they were organized as a bulleted list. I also question whether
there is need for so many. For example, what value does HKE_NOT_SUPPORTED
provide over a simple failure? The MN doesn't know what other algorithm to
use. I don't understand why a retransmittal of the request would work for
COA_AUTH_FAILED. Why would the MN get INVALID_MAC_ALG or INVALID_PRF_ALG?
Wouldn't the AR just send what it prefers and if the MN can't match it then
too bad? There is no provision for negotiating these algorithms, so what is
the point of returning an error code?

pg. 23, 6th paragraph: I'm not sure about this. If the NC entry for the CoA
expires and the AR removes the key, then the MN is left thinking that the
key is valid when it isn't. Why not send an NS to the MN to see if it is
still around and refresh the NC entry?

I didn't check the Radius and Diameter attribute definitions in the
appendix. I'd suggest they be moved to a separate document, since the
authors don't intend the definitions in the appendix to be normative.

                    jak

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop