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

From: Alpesh Patel <[email-masked]>
Date: Thu, 02 Aug 2001 09:52:45 -0700

Pat,

We can probably define the specifics/details of the operation of this
in another draft. What we are asking is that you include a statement in
this regard so that we have a basis for a new draft. We don't want to
close the avenues through which we can define unsolicited key
distribution.

I personally think it is better to amend your draft now instead of going
back to revise your rfc to support unsolicited key distribution.

Alpesh

Pat Calhoun wrote:
> 
> 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
> On Tue, Jul 31, 2001 at 02:38:10PM -0400, Madhavi W. Chandra wrote:
> > Hi Charlie and Pat,
> >
> > On Fri, Jul 27, 2001 at 01:47:59PM -0700, Charles E. Perkins wrote:
> > >
> > >
> > > 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.
> > >
> > >
> > > "Madhavi W. Chandra" wrote:
> > > >
> > > > 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?
> > >
> > > As Pat noted, there should be restrictions.  I have added text
> > > 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.
> >
> > > > 2.  Section 7, 'FA-FA Key Reply Subtype Data' sounds like a
> > > > description for MN-HA Reply.
> > >
> > > Fixed.
> >
> > <snip>
> >
> > > >
> > > > 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.
> >
> > <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.
> >
> > > > 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?
> >
> > <Pat's response>
> > > 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.
> >
> > 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.
> >
> > > > 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?
> > >
> > > 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.
> >
> > 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
> >
> > >
> > > Regards,
> > > Charlie P.
> >
> >
> >
> >
> >
> >

-- 
-a

---

From: Alpesh Patel <[email-masked]>
Date: Thu, 02 Aug 2001 13:44:41 -0700

Alpesh Patel wrote:

Pat,

In addition to the request for adding the unsolicited key push feature, 
we are still requesting support for HA-HA authentication as requested
by Madhavi Chandra. 

Also, we are still wondering if authentication of a reply carrying a 
key is in line with RFC2002 - MN parses the reply, obtains the key 
from an extension in the reply and uses this key to authenticate the
message.

Thanks
Alpesh

-- 
-a

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 2 Aug 2001 13:44:48 -0700

> we are still requesting support for HA-HA authentication as requested

Somehow I missed that request.

> from an extension in the reply and uses this key to authenticate the

That is correct.

PatC

---

From: Alpesh Patel <[email-masked]>
Date: Tue, 14 Aug 2001 10:51:02 -0700

Hi,

This is about mandating HMAC-MD5 for MobileIP as per the current
discussions in 2002bis.
My colleagues' and my concern is that this is not backwards compatible
with RFC2002.
I think indicating MD5 as SHOULD is not sufficient. 

What if three years from now,
new authentication algorithms come up. Shouldn't we have a mechanism to
indicate to
the Mobile Entity what algorithm to use to authenticate the peer entity?
Probably by
means of an extension (too costly) or just by adding a field in the
authentication
extension itself? I think this is a good time to do that. 

HMAC-MD5/MD5 as MUST/SHOULD in that order, as per me is not sufficient.
I would prefer
SHOULD/MUST order for HMAC-MD5/MD5 to be backwards compatible.

I heard/read one argument that RFC2002 was never a draft standard and
2002bis is on 
that track. My argument is that RFC2002 is out for about 4/5 years now
and it is
obvious that there would be implementation/deployment out there. IETF is
not ITU
where in everyone waits till a whole reference architecture document is
published
on a consensus. I have no intention to trash ITU here, but am trying to
make
it obvious for a need to be backwards compatible to what had been
agreed/recommended
in 2002.

Thanks
-a