Subject: [mobile-ip] WG last call: draft-ietf-mobileip-gen-key-00.txt

From: Phil Roberts <[email-masked]>
Date: Fri, 6 Jul 2001 13:55:02 -0400

This is a Mobile IP WG last call for the I-D
draft-ietf-mobileip-gen-key-00.txt
Generalized Key Extensions for Mobile IP. This draft will be sent to the
IESG
requesting a proposed standard status to be associated with it at the end of
the last call period. Please send your comments to the WG discussion list.

WG Last call issued on : Jul 5, 2001
Expires on : Jun 20, 2001

Basavaraj Patil
Phil Roberts

---

From: Jouni Malinen <[email-masked]>
Date: Thu, 12 Jul 2001 16:09:49 +0300

> the last call period. Please send your comments to the WG discussion list.

I noticed couple of minor typos/copy-paste errors (below) that could be
fixed:

3. Generalized MN-FA Key Reply Extension

      Length          The 16-bit Length field indicates the length of
                      the extension.  It is equal to 4 plus the number
                      of bytes in the Encoded MN-FA Key Data.

==> It is equal to the number of bytes ..
	(i.e., no SPI or lifetime field of 4 bytes in MN-FA key reply ext.)

7. Generalized FA-FA Key Reply Extension

      Length          The 16-bit Length field indicates the length of
                      the extension.  It is equal to 4 plus the number
                      of bytes in the Encoded FA-HA Key Data.

==> Encoded FA-FA Key Data

   For each subtype, the format of the FA-HA Key Reply Subtype Data has

==> format of the FA-FA Key Reply ..

-- 
Jouni Malinen                                            PGP id EFC895FA

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 12 Jul 2001 06:02:24 -0700

Thanks for the commens. I will address these in the next revision.

PatC

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Wed, 18 Jul 2001 11:57:52 -0400

Hi Charlie and Pat,

We've just started following this draft and are trying to grasp its
intent.  We have a few questions/comments:

1.  Since it is not specified, can the 'Reply' Key extensions be
appended to both RPYs and RRQs?

2.  Section 7, 'FA-FA Key Reply Subtype Data' sounds like a
description for MN-HA Reply.

3.  Are the 'Reply' Key extensions in Sections 6 and 7 sent
unsolicited by a mobility agent (MA)?  Actually, who is sending these
extensions and how do they even know to send these extension?  Also,
in what MIP messages are these being sent?  Please explain this a bit.

4.  Can the 'Reply' Key extensions in Sections 3 and 5 be sent
unsolicited to the MN...meaning, not in response to a 'Request' Key
extension.

5.  Curious...why separate Types for each message?  Why not
Type = Key Distribution message,
Subtype = MN-HA, MN-FA, FA-HA, etc
First byte of Subtype = serve purpose of current Subtype?

6. When MN sends 'MN-HA Key Request' extension in RRQ, does it append
MN-AAA AE since no MHAE?  So, AAA is doing proxy authentication of MN
for the HA?  Then, HA sends RPY with 'MN-HA Key Reply'
extension...what AE is used to secure the RPY?

7. We would like a mobility agent, say MA-1, to pass key to MA-2 for
MA-2 to use with MN.  If MAs are FAs, then probably the FA-FA Key
Reply Extension would be used...appended to what MIP message?  What if
the MAs are HAs?

8. Section on user scenarios would be helpful...mention that the AAA
Registration Keys draft is an instantiation of this draft. A simple
user scenario would illustrate the intent of the draft.

Thanks,
Madhavi

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 20 Jul 2001 13:53:56 -0700

> appended to both RPYs and RRQs?

No. Request goes in Registration Request, while Reply goes in the Registration
Reply.

> description for MN-HA Reply.

I think you mean FA-HA, and the text is incorrect.

> in what MIP messages are these being sent?  Please explain this a bit.

AS far as section 6, its use depends upon the context. As far as AAA
is concerned, it isn't used because AAA transfers the keying information
instead of within MIP. However, I presume that there are cases where
the FA and/or HA wish to exchange keying information. We decided that it
made sense to include this case, since it will most likely be needed 
sometime in the future.

As far as section 7, it could be useful in hierarchical scenarios.

> unsolicited to the MN...meaning, not in response to a 'Request' Key

if it is requested, then it is returned. However, it *could* be unsolicited.

> First byte of Subtype = serve purpose of current Subtype?

We thought that a separate type for each peer set made sense. We don't
use that many, and even if a subtype wasn't recognized, you'd still have
an idea whether you need the key or not (and return the appropriate error).

Example. Let's assume an FA receives a packet with one of these mumbo
extensions you mention above. If the subtype isn't recognized, it doesn't
know whether the key is destined for it or not. Perhaps the key is really 
for the mobile node instead.

Make sense?

> extension...what AE is used to secure the RPY?

They are independent. If the MN includes the MN-HA Key Request with the
AAA subtype (see AAA keys draft), then it really should include the
MN-AAA extension. However, these are separate drafts, and it makes sense
to leave it that way.

You are correct, though, that the HA would include the MN-HA Key Reply
extenion in the reply message, with the MN-HA auth ext generated using the
newly distributed key.

> Reply Extension would be used...appended to what MIP message?  What if

Since this behavior hasn't been defined, I cannot claim to know. This
draft only defines the generalized extensions, but separate extension
documents would describe how they are used. aaa keys is one such example.

> user scenario would illustrate the intent of the draft.

We had decided NOT to create a double link list. The AAA keys draft already
points to this draft, and the other way around doesn't make a whole lot
of sense.

The AAA draft, which describes subtypes, provides the needed illustration.
I would hate to have to copy that text into this simple draft, because it is
so AAA specific.

Thanks,

PatC

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 27 Jul 2001 13:47:59 -0700

Hello folks,

I submitted a version of the genkey draft, but I turned off my laptop
before the mail had gone out and so I missed last week's deadline.
It turns out that I had forgotten to cite RFC 2119 anyway, and so
it might have been rejected by the IESG.  I have re-revised the draft,
and I will resubmit it at the next opportunity.

The new draft is available at:
	http://people.nokia.net/charliep/txt/genkey/genkey.txt

Here are some additional comments.

> appended to both RPYs and RRQs?

As Pat noted, there should be restrictions.  I have added text
to that effect near the end of the Introduction.

> description for MN-HA Reply.

Fixed.

> Reply Extension would be used...appended to what MIP message?  What if

I agree with Pat's comments about hierarchical FAs being the
motivation for this extension, which seems to belong here.
For the case of home agents, no one ever made such a request,
and I haven't seen any protocol that would use such a thing as
part of any Mobile IPv4 registration message.  Even though it's
a bit late, it's not completely impossible to add such a feature.
However, I reckon the burden of proof would be on you to make
the case.

Regards,
Charlie P.

---

From: "Fredrik Johansson" <[email-masked]>
Date: Mon, 30 Jul 2001 10:51:33 +0200

Hi Charlie,

Thanks for getting this draft ready for last call. I've just a few comments
that I unfortunately missed before.

in section 2.0 and 4.0
It's stated that the mobile node SPI is the SPI that will be assigned for
the security association. Shouldn't it rather be a hint to what SPI the
mobile node would like to assign for the security association?
i.e.

Mobile Node SPI         The Security Parameter Index provided
                        by the mobile node as a hint to which
                        SPI it would like to assign for the security
                        association created for use with the
                        registration key.

Section 3.0 and 5.0
The MN-FA/MN-HA Key Reply Subtype Data shouldn't be an encrypted copy of the
key to be used as some subtypes doesn't send the actual key but a key
material instead.

"Subtype data, e.g. key material, to be used
between the mobile node and its home/foreign agent, along
with any other information needed by the mobile
node to create the designated Mobility Security
Association with the home/foreign agent.

Section 7.0
Is there a reason to why the FA-FA key reply extension contains a SPI when
it's left out from the other reply extensions? Or can it be left to the
subtype as in the other reply extensions?

thanks
/Fredrik

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]On Behalf Of Charles E.
>Perkins
>Sent: den 27 juli 2001 22:48
>To: Madhavi W. Chandra
>Cc: Mobile IP Working Group; Pat Calhoun
>Subject: Re: [mobile-ip] Re: mobile-ip] WG last call:

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Tue, 31 Jul 2001 14:38:10 -0400

Hi Charlie and Pat,

> to that effect near the end of the Introduction.

I'm not clear on the need for the restrictions.  Being able to 
append a 'Request' Key or 'Reply' Key extension to either a
RRQ or RPY provides more flexibility.  Say, for example, that
hierarchical FAs want to share a key...they can append the FA-FA 
Key Reply Extension to a RRQ as it propagates.  Of course, the
extensions must be properly secured.

> > description for MN-HA Reply.

<snip>

> > unsolicited to the MN...meaning, not in response to a 'Request' Key

<Pat's response> 
> if it is requested, then it is returned. However, it *could* be unsolicited.

It will be helpful to explicity state this in the draft.  We want to be
able to push keys to different entities, and hence would like support
for unsolicted key exchange.

> > extension...what AE is used to secure the RPY?

<Pat's response>

> extenion in the reply message, with the MN-HA auth ext generated using the

But, how does the MN know this newly generated key to authenticate the
MHAE in the RPY?  Doesn't the MN first have to parse the RPY to extract the 
'MN-HA Key Reply extension' for the key, and then authenticate the RPY.
Is this in line with RFC2002?  Or am I completely misunderstanding 
something.
 
> However, I reckon the burden of proof would be on you to make

The need for HA-HA communication will become important in the case
of HA redundancy or load-balancing.  The HAs will need to share a 
security association, which can be dynamically assigned via a AAA 
server. It's analogous to the hierarchical FA case for future use.  
We'd like to request this feature to be included.  We realize the 
late nature of this request, and are more than willing to help with 
text, motivation, etc.

Thanks,
Madhavi

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 31 Jul 2001 12:03:12 -0700

Ah, I think that I just understood what you want.

You want the ability to include a key in a request, and not necessary request
one. Isn't there anyway that this could simply be defined in another Internet
Draft? I'd hate to start adding new features in the draft this late in the
game (plus, there are some parties that really need an RFC number to start
deploying their services).

Perhaps once we've identified a need for the feature you mention (in an
Internet-Draft form), you can simply define the new AVPs there.

PatC