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

From: "Ahmad Muhanna"<[email-masked]>
Date: Tue, 19 Mar 2002 12:00:24 -0600

Hi Pete;
I thought that I sent this message but it seems that it did not go through.

Well, I would like to agree with you, However, the following points make it
very difficult:

I.	RFC3220 (RFC2002):
	It is mandatory for the Mobile Node to have a security association
with all of its Home Agents as per 
	section 3.6.

	"3.6. Mobile Node Considerations

  	 A mobile node MUST be configured with a netmask and a mobility
   	security association for each of its home agents.
	.....
	"	
2.	RFC3012:
	It is mandatory that MN must include the MN-HA authentication
extension in every RRQ message as long as the mobile 	Node shares a
security association with its home agent, as per section 6. below.

Now, in my opinion, anything else needs to change the existing standard
including RFC3220, which mandates the MN to maintain a security association
with its Home Agents.

However, in the case of dynamically allocated Home Agent: 
As per RFC3220, the MN must have a security association with its home
agents. 
This means that the MN MUST have this security association before sending
any RRQ messages.

I think the best approach without introducing any serious conflicts and
changes in the standard may be the following:
1.	MN MUST maintain at all times a security association with all of its
home agents or HOME DOMAIN.
2.	I assume that Dynamically allocated HA is one which belongs to the
MN Home Domain.
3.	If the Dynamically allocated HA does not have the security
parameters available for this MN, it MUST inquire it 
	(ex. AAA infrastructure) to get the needed security parameters to be
able to authenticate the MN.
4.	IF the HA or Home Domain needs to update (for example) the shared
secret key with the MN, it always can be done after 	the initial RRQ with
the last (configured or updated) security parameters the MN shares with its
Home Agents 
	(Home Domain).

Thanks for consideration.
Regards;

Ahmad Muhanna

-----Original Message-----
From: Pete McCann [mailto:[email-masked]]
Sent: Tuesday, March 19, 2002 8:55 AM
To: [email-masked]
Cc: 'Charles E. Perkins'
Subject: [mobile-ip] A proposal for resolving a very Possible conflict
between RFC3220 & RFC3012 (RFC3012bis)

Hi, Ahmad,

I agree with this approach, except for your point 3 below:

 > 	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.

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:
 > 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: "Ahmad Muhanna"<[email-masked]>
Date: Wed, 20 Mar 2002 08:15:38 -0600

Hello Charlie;

I am not sure how can we introduce new issues and text to the already
published standard (RFC3220) other than the mysteriously vanished text from
that RFC.
I believe we need to look into this very closely before rushing for any
changes.

Now, I believe any addition to the standard MUST consider 100% backward
compatibility with existing standard.
Existing HA rejects any RRQ message which does not contain MN-HA
Authentication extension. as per the standard RFC2002 (RFC3220).

Regards;

Ahmad Muhanna
Nortel Networks
Shasta PDSN-MIP Development
Phone. + 1 972 685 1416 ESN. 445-1416
[email-masked]

-----Original Message-----
From: Charlie Perkins [mailto:[email-masked]]
Sent: Tuesday, March 19, 2002 6:48 PM
To: Pete McCann
Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; [email-masked]'
Subject: Re: [mobile-ip] A proposal for resolving a very Possible
conflictbetween RFC3220 & RFC3012 (RFC3012bis)

Hello Pete,

Pete McCann wrote:

> I believe we will need to update the MN-HA key in the first RRQ/RRP,
> sometimes.
>
> Maybe the right approach is to update the text in 3220 to explicitly
> allow zero security associations with home agents, if some other
> "authorization enabling extension" is present in the message.

If so, the time to do so would be this week, so that we can get it in at
the same time we supply the mysteriously vanished text, and update the
"exactly one", and relieve the possibility for misinterpretation that was
noticed during Connectathon.

Regards,
Charlie P.

---

From: "Ahmad Muhanna"<[email-masked]>
Date: Wed, 20 Mar 2002 09:03:30 -0600

Hi, Pete,
I believe the following points needs to be made clear:

1. It is good to preserve a sort of forward compatibility, however, we need
to keep in mind the more important issue which is backward compatibility.
2. When we need to support any argument, we can not use work in progress
documentation. In other words, we can not defeat existing standard by
referencing I-D which is not a standard yet.
3. As per (RFC2002) RFC3220 & RFC3012, existing HA does the following:
	i. 	Expects a SA with all of its home domain Mobile Nodes.
	ii.	Expecting a MN-HA authentication extension in every RRQ.
	iii.	MN-AAA authentication extension does not comply with the
definition of the authorization-enabling extension and 
		the only extension which is defined as
authorization-enabling extension is the MN-HA authentication extension.

4. Now, with all of the above in mind, It is very dangerous to patch the
standard here and there to satisfy future forward compatibility.
5. Interpretation of MIP standard should be done with the original and
current spirit and understanding rather than the future evolution and
understanding of MIP standard. This will only create more problems without
introducing a comprehensive solution.

I believe, a committee needs to take charge of this task with one objective
in mind "How to evolve MIP standard to be forward combatable with all of the
new understandings while maintaining a 100% backward combatability". 

Thanks for consideration;

Regards;

Ahmad Muhanna

-----Original Message-----
From: Pete McCann [mailto:[email-masked]]
Sent: Tuesday, March 19, 2002 3:27 PM
To: Muhanna, Ahmad [RICH1:2Q20:EXCH]
Cc: [email-masked]'; 'Charles E. Perkins'
Subject: RE: [mobile-ip] A proposal for resolving a very Possible
conflict between RFC3220 & RFC3012 (RFC3012bis)

Hi, Ahmad,

I understand your point of view, but some comments below...

 >    	security association for each of its home agents.

Technically, "for each of its home agents" does not imply that there
is a home agent - the quantification "for each" could be the empty set.

 > security association with its home agent, as per section 6. below.

Again, this is qualified with "as long as the mobile node shares a
security association."  No security association => no need for the 
extension.

 > This means that the MN MUST have this security association before sending

I am trying to preserve a sort of "forward compatibility" with dynamic 
home agent assignment ala the Diameter Mobile IP application.  I think 
this was the intention of the language in 3220, which should have been,
"at least one authorization enabling extension."  The intention was to 
allow the MN to leave out MN-HA, especially for the case of dynamic HA
assignment.

 > home agents or HOME DOMAIN.

Where "all of" may be the empty set.

 > 2.	I assume that Dynamically allocated HA is one which belongs to the

Maybe not - see
http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-09.txt

 > able to authenticate the MN.

And if the HA is in the foreign domain, the keys must be generated for 
use by that session only and distributed to the MN in a new extension.

 > security key with the MN, it always can be done after the 
 > 	initial RRQ with the last (configured or updated) security
 > parameters the MN shares with its Home Agents (Home Domain)

-Pete

---

From: "Ahmad Muhanna"<[email-masked]>
Date: Wed, 20 Mar 2002 18:07:51 -0600

Hello Charlie;

We are in full agreement that any HA will never receive a RRQ message with
ONLY MN-AAA authentication except in the case that this HA does not have a
security association with the Mobile Node. (RFC3012bis & RFC3220 & this
discussion)

In reference to the backward compatibility issue:

If an existing HA (RFC2002) receives a RRQ message with ONLY the MN-AAA
authentication extension, it means that this HA does not have a security
association with the Mobile Node (against RFC 2002 but it is considered an
error scenario). It is not spilled out in RFC2002 what HA SHOULD do but it
can not send a RRP message since there is no SA with the MN. 
I assume that this HA discards this RRQ without sending a RRP message to the
MN.

This makes the existing HA(RFC2002) compatible with RFC3220 after replacing
the EXACTLY word with (At least) in section 3.5.2.
"At least one authorization-enabling extension MUST be present in all ..."

Regards;
Ahmad Muhanna

-----Original Message-----
From: Charlie Perkins [mailto:[email-masked]]
Sent: Wednesday, March 20, 2002 10:36 AM
To: Muhanna, Ahmad [RICH1:2Q20:EXCH]
Cc: 'Pete McCann'; [email-masked]'
Subject: Re: [mobile-ip] A proposal for resolving a very Possible

Hello folks,

Ahmad Muhanna wrote:

> 1. It is good to preserve a sort of forward compatibility, however, we
> need to keep in mind the more important issue which is backward
> compatibility.

I agree that we need backward compatibility, but I don't think that is
at issue
here.  A home agent will require a MN-HA authentication extension if and

only if it has a security association with the mobile node.  Thus, if a
home agent
is built to work with dynamically created assocations, delivered by AAA,

then by definition that home agent will be O.K. with the new
specification.

> 2. When we need to support any argument, we can not use work in
> progress documentation. In other words, we can not defeat existing
> standard by referencing I-D which is not a standard yet.

We can fix anything in RFC 3220bis independently of RFC 3012bis, which
is a
better approach than having RFC 3012bis obsolete language in the
yet-to-be-written
RFC3220bis.  On the other hand, the entire process has to be driven by
working
group consensus.  And, I sincerely hope that there is no such thing as
RFC3220bisbis
in any near future timeframe.

>         iii.    MN-AAA authentication extension does not comply with
> the definition of the authorization-enabling extension and

The intention for the "authorization-enabling" language in RFC 3220 was
exactly to enable authorization by means other than the MN-HA
authentication
extension.  It was a mistake not to change this, but nobody caught this
instance
of the inconsistency.  I did change seemingly innumerable other
instances of it.

> 4. Now, with all of the above in mind, It is very dangerous to patch
> the standard here and there to satisfy future forward compatibility.

I don't think this is really true, as I explained above.  Furthermore, I
do think it
is appropriate to eliminate straggling language that would have been
eliminated
before except that we just missed it.

> understanding of MIP standard. This will only create more problems
> without introducing a comprehensive solution.

I agree with you, and yet I see that we should still take the corrective
actions that have
been discussed.

> I believe, a committee needs to take charge of this task with one
> objective in mind "How to evolve MIP standard to be forward combatable
> with all of the new understandings while maintaining a 100% backward
> combat ability".

Hmm... another committee...  I'm not so sure about this, but then again
if
there is a need I'll happily go along with the program, as long as the
committee supplies the text to go along with any future recommendations.

Regards,
Charlie P.