Subject: [mobile-ip] A proposal for resolving a very Possible conflict between RFC3220 & RFC3012 (RFC3012bis)

From: "Ahmad Muhanna"<[email-masked]>
Date: Mon, 18 Mar 2002 14:14:32 -0600

Hello all;

This email is quite long and I appreciate it if as many people as possible
have the patience to read through it and post their input.

I exchanged few emails with Charlie Perkins which led me to post the
following for this mail list.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++
From my reading of RFC3220 and RFC3012 (RFC3102-bis), I would like to share
with all of you the following proposed interpretation to prevent a conflict
between these two RFCs.

1.	RFC3220 introduced a new term "Authorization-enabling extension" and
made it restricted that registration request MUST have only one
authorization-enabling extension after renaming the MN-HA Authentication
extension as authorization-enabling extension, as per section 3.5.2:
	"3.5.2. Mobile-Home Authentication Extension
   	Exactly one authorization-enabling extension MUST be present in all
   	Registration Requests, and also in all Registration Replies
generated
  	by the Home Agent.  The Mobile-Home Authentication Extension is
   	always an authorization-enabling for registration messages specified
   	in this document.  This requirement is intended to eliminate
problems
   	[2] which result from the uncontrolled propagation of remote
   	redirects in the Internet.  The location of the extension marks the
   	end of the authenticated data."

2.	This made it impossible for Mobile Node to include the MN-HA and
MN-AAA Authentication extensions in the same Registration Request.
3.	However, RFC3012 section 6 mandates Mobile Node to include MN-HA
Authentication extension in every Registration Request message as long as
the Mobile Node has a security association with its Home Agent. (MN MUST
always maintain a security association with all of its home agents, as per
RFC3220 (RFC2002)), 
             "6. MN-AAA Authentication subtype
   	"............................................  If the MN-AAA
Authentication
   	extension is present, then the Registration Message sent by the
   	mobile node MUST contain the Mobile-HA Authentication extension [8]
  	if it shares a security association with the Home Agent............"

4.	Also, RFC3012, mandates that the Mobile Node MUST include MN-AAA
Authentication extension whenever it does not have a security association
with the Foreign Agent, as in section 3.1.

Since, at least conceptually although it is not referenced any where in the
standard, MN-AAA authentication extension is viewed as an
authorization-enabling extension, this very wide interpretation causes a
real conflict between RFC3220 & RFC3012 (RFC3012bis). Therefore the
following interpretation proposes a solution for this issue:

1.	Since RFC3220 defines the Authorization-enabling extension as
follows in section 1.6:

	"Authorization-enabling extension
	An authentication which makes a (registration) message
	acceptable to the ultimate recipient of the registration
	message.  An authorization-enabling extension MUST contain
	an SPI.
	In this document, all uses of authorization-enabling
	extension refer to authentication extensions that enable the
	Registration Request message to be acceptable to the home
	agent. Using additional protocol structures specified 
	outside of this document, it may be possible for the mobile 
	node to provide authentication of its registration to the
	home agent, by way of another authenticating entity within
	the network that is acceptable to the home agent (for
	example, see RFC 2794 [6])."

2.	While RFC3012 introduced MN-AAA authentication extension to offer a
mechanism to authenticate the Mobile Node to the visited Foreign Agent, as
it is clearly obvious in the Abstract, Introduction, and section 3.1 ""3.1.
Mobile Node Processing for Registration Requests".

AND since the ultimate recipient of the Registration Request is always the
Home Agent, MN-AAA authentication extension does not comply with the
definition of the Authorization-enabling extension offered in RFC3220.

	1.	This will resolve the conflict and allows the Mobile Node to
always include the MN-HA Authentication extension (Authorization-enabling)
and MN-AAA authentication extension (not an authorization-enabling).
	2.	      When FA process the Registration Request received from
the Mobile Node, it is optional for the FA to forward the MN-AAA
authentication extension or remove it as per RFC3012 section 3.2.
	"The Foreign Agent MUST NOT remove the MN-AAA Authentication
Extension
   	from the Registration Request prior to the completion of the
   	authentication performed by the AAA infrastructure.  The appendix
   	provides an example of an action that could be taken by a foreign
   	agent."
	3.	Then HA always receives a MN-HA Authentication extension and
optionally MN-AAA authentication extension in every Registration Request. HA
may use AAA to get the shared secret key for authenticating the RRQ message
using MN-HA Authentication extension or use the MN-AAA authentication
extension through the AAA infrastructure.

Now As per Charlie's suggestion:

1.	A new cause code for the MN failing authentication at the Home Agent
using the AAA (MN-AAA authentication extension) may be needed.

2.	Also, RFC3012bis should be viewed as obsoleting the word "Exactly"
-- perhaps changing it to a "At least" in section 3.5.2 of RFC3220.
"3.5.2. Mobile-Home Authentication Extension
Exactly At least one authorization-enabling extension MUST be present in all
Registration Requests, and also in all Registration Replies generated 
by the Home Agent."

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++

Thanks for your consideration.

Regards;

Ahmad Muhanna

---

From: Pete McCann <[email-masked]>
Date: Tue, 19 Mar 2002 08:54:34 -0600 (CST)

Hi, Ahmad,

 > extension through the AAA infrastructure.

I think there are cases, such as dynamic HA assignment, where the MN
doesn't have an association with the HA at first.  So, we should allow 
cases where the MN includes ONLY MN-AAA in the RRQ and it is the basis 
for authentication at the HA.

Also, I would like to clarify the rules for when the FA can strip out
the MN-AAA: it can do so after verifying it with a AAA infrastructure, 
and only if a MN-HA authentication extension was present previously in
the RRQ.

-Pete

Ahmad Muhanna writes:
 > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
 > <HTML>
 > <HEAD>
 > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
 > <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
 > <TITLE>A proposal for resolving a very Possible conflict between RFC3220 &amp; RFC3012 (RFC3012bis)</TITLE>
 > </HEAD>
 > <BODY>
 > 
 > <P><FONT FACE="Times New Roman">Hello all;</FONT>
 > </P>
 > 
 > <P><FONT FACE="Times New Roman">This email is quite long and I appreciate it if as many people as possible have the patience to read through it and post their input.</FONT></P>
 > 
 > <P><FONT FACE="Times New Roman">I exchanged few emails with Charlie Perkins which led me to post the following for this mail list.</FONT>
 > </P>
 > 
 > <P><FONT FACE="Times New Roman">++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++</FONT>
 > <BR><FONT FACE="Times New Roman">From my reading of RFC3220 and RFC3012 (RFC3102-bis), I would like to share with all of you the following proposed interpretation to prevent a conflict between these two RFCs.</FONT></P>
 > <BR>
 > 
 > <P><FONT FACE="Times New Roman">1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RFC3220 introduced a new term "<B>Authorization-enabling extension</B>" and made it restricted that registration request MUST have only one authorization-enabling extension after renaming the MN-HA Authentication extension as authorization-enabling extension, as per section 3.5.2:</FONT></P>
 > 
 > <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial Unicode MS Western">"3.5.2. Mobile-Home Authentication Extension</FONT>
 > <BR><FONT SIZE=2 FACE="Arial Unicode MS">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;</FONT><B> <FONT SIZE=2 FACE="Arial Unicode MS">Exactly one authorization-enabling extension MUST be present in all</FONT></B>
 > <BR><B><FONT SIZE=2 FACE="Arial Unicode MS">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; Registration Requests</FONT></B><FONT SIZE=2 FACE="Arial Unicode MS">, and also in all Registration Replies generated</FONT>
 > <BR><FONT SIZE=2 FACE="Arial Unicode MS">&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; by the Home Agent.&nbsp; The</FONT><B> <FONT SIZE=2 FACE="Arial Unicode MS">Mobile-Home Authentication Extension is</FONT></B>
 > <BR><B><FONT SIZE=2 FACE="Arial Unicode MS">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; always an authorization-enabling</FONT></B><FONT SIZE=2 FACE="Arial Unicode MS"> for registration messages specified</FONT>
 > <BR><FONT SIZE=2 FACE="Arial Unicode MS">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; in this document.&nbsp; This requirement is intended to eliminate problems</FONT>
 > <BR><FONT SIZE=2 FACE="Arial Unicode MS">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; [2] which result from the uncontrolled propagation of remote</FONT>
 > <BR><FONT SIZE=2 FACE="Arial Unicode MS">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; redirects in the Internet.&nbsp; The location of the extension marks the</FONT>
 > <BR><FONT SIZE=2 FACE="Arial Unicode MS">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; end of the authenti</FONT><FONT SIZE=2 FACE="Arial Unicode MS Western">cated data."</FONT>
 > </P>
 > 
 > <P><FONT FACE="Times New Roman">2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This made it</FONT><B> <FONT FACE="Times New Roman">impossible for Mobile Node</FONT></B><FONT FACE="Times New Roman"> to include the MN-HA and MN-AAA Authentication extensions in the same Registration Request.</FONT></P>
 > 
 > <P><FONT FACE="Times New Roman">3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; However,</FONT><B> <FONT FACE="Times New Roman">RFC3012 section 6 mandates Mobile Node to include MN-HA Authentication extension in every Registration Request</FONT></B><FONT FACE="Times New Roman"> message as long as the Mobile Node has a security association with its Home Agent. (MN MUST always maintain a security association with all of its home agents, as per RFC3220 (RFC2002)), </FONT></P>
 > 
 > <P><FONT SIZE=2 FACE="Arial Unicode MS Western">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "</FONT><B></B><B><FONT SIZE=2 FACE="Arial Unicode MS">6</FONT></B><FONT SIZE=2 FACE="Arial Unicode MS">. MN-AAA Authentication subtype</FONT>
 > <BR><FONT SIZE=2 FACE="Arial Unicode MS Western">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; "............................................&nbsp;</FONT><B></B><B> <FONT SIZE=2 FACE="Arial Unicode MS">If the MN-AAA Authentication</FONT></B>
 > <BR><B><FONT SIZE=2 FACE="Arial Unicode MS">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; extension is present, then the Registration Message sent by the</FONT></B>
 > <BR><B><FONT SIZE=2 FACE="Arial Unicode MS">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; mobile node MUST contain the Mobile-HA Authentication extension [8]</FONT></B>
 > <BR><B><FONT SIZE=2 FACE="Arial Unicode MS">&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if it shares a security association with the Home Agent</FONT></B><FONT SIZE=2 FACE="Arial Unicode MS Western">............" </FONT>
 > <BR><FONT SIZE=2 FACE="Arial Unicode MS">4</FONT><FONT SIZE=2 FACE="Arial Unicode MS">.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT> <FONT FACE="Times New Roman">Also, RFC3012, mandates that the Mobile Node MUST include MN-AAA Authentication extension whenever it does not have a security association with the Foreign Agent, as in section 3.1.</FONT></P>
 > 
 > <P><FONT FACE="Times New Roman">Since,</FONT><B> <FONT FACE="Times New Roman">at least conceptually although it is not referenced any where in the standard</FONT></B><FONT FACE="Times New Roman">, MN-AAA authentication extension is viewed as an authorization-enabling extension, this very wide interpretation causes a real conflict between RFC3220 &amp; RFC3012 (RFC3012bis). Therefore the following interpretation proposes a solution for this issue:</FONT></P>
 > 
 > <P><FONT FACE="Times New Roman">1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Since RFC3220 defines the Authorization-enabling extension as follows in section 1.6:</FONT>
 > </P>
 > 
 > <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial Unicode MS Western">"Authorization-enabling extension</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial Unicode MS">An authentication</FONT><B> <FONT SIZE=2 FACE="Arial Unicode MS">which makes a (registration) message</FONT></B>
 > <BR><B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial Unicode MS">acceptable to the ultimate recipient of the registration</FONT></B>
 > <BR><B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial Unicode MS">message</FONT></B><FONT SIZE=2 FACE="Arial Unicode MS">.&nbsp; An authorization-enabling extension MUST contain</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial Unicode MS">an SPI.</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial Unicode MS">In this document, all uses of authorization-enabling</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial Unicode MS">extension refer to authentication extensions that enable the</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial Unicode MS">Registration Request message to be acceptable to the home</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial Unicode MS">agent. Using additional protocol structures specified </FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial Unicode MS">outside of this document, it may be possible for the mobile </FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial Unicode MS">node to provide authentication of its registration to the</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial Unicode MS">home agent, by way of another authenticating entity within</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial Unicode MS">the network that is acceptable to the home agent (for</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial Unicode MS Western">example, see RFC 2794 [6])."</FONT>
 > </P>
 > 
 > <P><FONT FACE="Times New Roman">2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; While RFC3012 introduced MN-AAA authentication extension to offer a mechanism to authenticate the Mobile Node to the visited Foreign Agent, as it is clearly obvious in the Abstract, Introduction, and section 3.1 "</FONT><B></B><B><FONT SIZE=2 FACE="Arial">&quot;</FONT></B><FONT FACE="Times New Roman">3.1. Mobile Node Processing for Registration Requests".</FONT></P>
 > 
 > <P><FONT FACE="Times New Roman">AND since the</FONT><B> <FONT FACE="Times New Roman">ultimate recipient</FONT></B><FONT FACE="Times New Roman"> of the Registration Request is always the Home Agent, MN-AAA authentication extension</FONT><B> <FONT FACE="Times New Roman">does not comply with the definition of the Authorization-enabling extension offered in RFC3220</FONT></B><FONT FACE="Times New Roman">.</FONT></P>
 > <UL>
 > <P><FONT FACE="Times New Roman">1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This will resolve the conflict and allows the Mobile Node to always include the MN-HA Authentication extension (Authorization-enabling) and MN-AAA authentication extension (</FONT><B><FONT FACE="Times New Roman">not an authorization-enabling</FONT></B><FONT FACE="Times New Roman">).</FONT></P>
 > 
 > <P><FONT FACE="Times New Roman">2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When FA process the Registration Request received from the Mobile Node, it is optional for the FA to forward the MN-AAA authentication extension or remove it as per RFC3012 section 3.2.</FONT></P>
 > </UL>
 > <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial Unicode MS Western">"The Foreign Agent</FONT><B></B><B> <FONT SIZE=2 FACE="Arial Unicode MS">MUST NOT remove the MN-AAA Authentication Extension</FONT></B>
 > <BR><FONT SIZE=2 FACE="Arial Unicode MS">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; from the Registration Request prior to the completion of the</FONT>
 > <BR><FONT SIZE=2 FACE="Arial Unicode MS">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; authentication performed by the AAA infrastructure.&nbsp; The appendix</FONT>
 > <BR><FONT SIZE=2 FACE="Arial Unicode MS">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; provides an example of an action that could be taken by a foreign</FONT>
 > <BR><FONT SIZE=2 FACE="Arial Unicode MS Western">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; agent."</FONT>
 > <UL>
 > <P><FONT FACE="Times New Roman">3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Then HA always receives a MN-HA Authentication extension and optionally MN-AAA authentication extension in every Registration Request. HA may use AAA to get the shared secret key for authenticating the RRQ message using MN-HA Authentication extension or use the MN-AAA authentication extension through the AAA infrastructure.</FONT></P>
 > </UL>
 > <P><B><FONT FACE="Times New Roman">Now As per Charlie's suggestion:</FONT></B>
 > </P>
 > 
 > <P><B><FONT FACE="Times New Roman">1.</FONT></B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT FACE="Times New Roman">A</FONT><B> <FONT FACE="Times New Roman">new cause code</FONT></B><FONT FACE="Times New Roman"> for the MN failing authentication at the Home Agent using the AAA (MN-AAA authentication extension) may be needed.</FONT></P>
 > 
 > <P><B><FONT SIZE=2 FACE="Arial">2.</FONT></B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">Also, RFC3012bis should be viewed as obsoleting the word &quot;</FONT><B><FONT SIZE=2 FACE="Arial">Exactly</FONT></B><FONT SIZE=2 FACE="Arial">&quot; -- perhaps changing it to a &quot;</FONT><B><FONT SIZE=2 FACE="Arial">At least</FONT></B><FONT SIZE=2 FACE="Arial">&quot; in section 3.5.2 of RFC3220.</FONT></P>
 > 
 > <P><FONT SIZE=2 FACE="Arial">"</FONT><FONT SIZE=2 FACE="Arial Unicode MS">3.5.2. Mobile-Home Authentication Extension</FONT>
 > <BR><B><STRIKE><FONT SIZE=2 FACE="Arial Unicode MS">Exactly</FONT></STRIKE></B><STRIKE></STRIKE><FONT SIZE=2 FACE="Arial Unicode MS"></FONT><B> <FONT SIZE=2 FACE="Arial Unicode MS">At least</FONT></B><FONT SIZE=2 FACE="Arial Unicode MS"> one authorization-enabling extension MUST be present in all</FONT>
 > <BR><FONT SIZE=2 FACE="Arial Unicode MS">Registration Requests, and also in all Registration Replies generated </FONT>
 > <BR><FONT SIZE=2 FACE="Arial Unicode MS Western">by the Home Agent."</FONT>
 > </P>
 > 
 > <P><FONT FACE="Times New Roman">+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++</FONT>
 > </P>
 > 
 > <P><FONT FACE="Times New Roman">Thanks for your consideration.</FONT>
 > </P>
 > <BR>
 > 
 > <P><B><I><FONT COLOR="#0000FF" FACE="Times New Roman">Regards;</FONT></I></B>
 > </P>
 > 
 > <P><B><FONT COLOR="#0000FF" FACE="Times New Roman">Ahmad Muhanna</FONT></B>
 > </P>
 > 
 > </BODY>
 > </HTML>