Subject: [Mip4] Contradiction between RFC 3957 and RFC 4721

From: "McCann Peter-A001034" <[email-masked]>
Date: Wed, 23 May 2007 17:03:30 -0400

It has been brought to my attention that there is
a contradiction between RFC 3957 and RFC 4721 in 
the specification of how the MN-AAA Authentication
Extension can be used in Registration Replies.

RFC 3957 contains the following text in Section 1,
2nd-to-last paragraph:

>   When the Mobile IP Registration Reply packet is authenticated
>   by the MN-AAA Authentication Extension [3], the mobile node can
>   verify that the key material contained in the extensions were
>   produced by the AAA server, and thus may be reliably used to create
>   Mobility Security Associations with the home agent and/or the
foreign
>   agent.

Meanwhile, RFC 4721 contains the following text in Section 6:

>   If the Mobile-AAA Authentication extension is present, the Mobile-
>   Home Authentication extension MUST appear prior to the Mobile-AAA
>   Authentication extension.  The corresponding response MUST include
>   the Mobile-Home Authentication extension and MUST NOT include the
>   Mobile-AAA Authentication extension.

It seems to me that inclusion of an MN-AAA extension in a
Registration Reply is not strictly necessary to validate 
the integrity of the new keys; that can be accomplished by
computing the MN-HA (and MN-FA) keys from the supplied 
nonces and verifying the corresponding MN-HA (or MN-FA)
authentication extension.

However, I also think that a blanket prohibition against
including the MN-AAA extension in Registration Replies
was not intended.  Also, it seems that the text in RFC 4721
also requires the MN-HA authentication extension to be
present in the registration request even when an MN-HA 
key has not yet been distributed.

Is there any information out there as to how implementations
deal with MN-AAA authentication extensions in Registration
Replies?  Should we generate an erratum to RFC 4721, permitting
their inclusion?

-Pete

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Thu, 24 May 2007 10:59:32 +0200

> key has not yet been distributed.
Yes i have pointed out the last point on the mailing list a while ago 
without success.

The questions were:
"What value should be set by the MN in the mandatory MN-HA 
authentication extension when MN-HA key is not yet available because 
being bootstrapped using the MN-AAA extension also contained in the 
registration request?"
"In such a case, how should the MN-HA extension from the registration 
request be handled by the HA"? Be ignored?

I don't have yet the answer.

> Replies?  Should we generate an erratum to RFC 4721, permitting
Erratum would certainly help.
Should state clearly how RFC 3344bis should be interpreted/relaxed when 
AAA is used as an alternate authorization method.

Bruno.