Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Thu, 1 Dec 2005 18:30:00 -0800

Oh, OK then. :)  We're in agreement that MFCE is not needed in CCoA
mode.

Kent

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]] 
> Sent: Thursday, December 01, 2005 6:18 PM
> To: Kent Leung (kleung)
> Cc: Jayshree Bharatia; [email-masked]
> Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
> 
> Kent Leung (kleung) wrote:
> 
> >>What if the draft allows the Generalized Authentication 
> extension for 
> >>mobile nodes with CCoA, but does not allow the challenge 
> extension?  I 
> >>don't see what's wrong with this, since the draft is 
> "about" a foreign 
> >>agent protocol.
> >>
> >>    
> >>
> >
> >But that means the Generalized Authentication is split into 
> 2 separate 
> >drafts (this one for FA CoA mode and a new draft for CCoA 
> mode).  BTW, 
> >I think this was proposed in the thread but not warmly received.
> >  
> >
> No, I think it's fine if the same draft mentions that the 
> extension is legitimate for use by mobile nodes with co-located CoA.
> 
> >I don't think adding a couple of sentences to specify that 
> MFCE is not 
> >needed in CCoA mode is refocussing this draft.
> >  
> >
> This is fine with me.  I guess you inferred that I am against 
> mentioning co-located CoA in this draft.  I am not against 
> that, and I did not mean
> to imply that.    I am only against specifying a way to use 
> the challenge
> extension with co-located CoA.
> 
> Regards,
> Charlie P.
> 

-- 
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: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Fri, 2 Dec 2005 12:12:33 -0500

Yes, I agree. Otherwise not sure how we can do 3957 and 4004?
Given that the fix we proposed (replace the challenge value with 0 in
the authenticator calculation for direct RRQ), I think this RFC will get
a much bigger applicability with a small change.

Madjid 

-----Original Message-----
From: Pete McCann [mailto:[email-masked]] 
Sent: Friday, December 02, 2005 10:02 AM
To: Kent Leung (kleung)
Cc: Jayshree Bharatia; Charles E. Perkins; Nakhjiri Madjid-MNAKHJI1;
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Chair hat off, I think there is clearly value in using MN-AAA
authenticator even in co-located mode, especially if one is trying to
bootstrap an HA for which no security association exists yet.  I support
Kent's and Vijay's suggested changes.

-Pete

Kent Leung \(kleung\) writes:
 > I vote for #2.  The reason is that that RFC 3012 is addressing two  >
functions, as stated in previous emails (initiated by Gabe's review and
> comment to split this draft).
 >
 > 1) FA challenge/authentication and MN-FA replay protection.  
 >
 > 2) Generalized authentication (e.g. MN-AAA), which is independent if
the  > NAS is FA or HA.
 >
 > I would like to keep this in one draft, which means both functions  >
should be covered fully (i.e. including CCoA mode).  I believe that  >
Vijay was OK with this except he wanted to explicitly state that replay
> protection is using nonce/timestamp.  But I don't see a need since
this  > is fundamental function of Mobile IP itself.
 > > From: Jayshree Bharatia [mailto:[email-masked]]  > > Sent:
Thursday, December 01, 2005 2:46 PM  > > To: Charles E. Perkins; Kent
Leung (kleung);  > > [email-masked]; [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked];  > >
[email-masked]  > > Subject: RE: [Mip4] review:
draft-ietf-mip4-rfc3012bis-04.txt  > >  > > Hi all,  > >  > > I am not
sure how to proceed toward supporting co-located CoA  > > mode in
RFC3012bis. RFC3012 doesn't have any details on this  > > and it was a
working assumption that this draft is not  > > applicable for co-located
CoA mode.
 > >
 > > Later in the process of updating RFC3012bis, there was a  > >
discussion that we shouldn't be limiting use of MN-AAA  > > extension
for co-located CoA mode. Anyway, we need to come up  > > with some
agreement now. The following is the summary of the  > > discussion:
 > > - Kent and Madjid think that having clarification that there  > >
is no challenge included in the MN-AAA extension for  > > co-located CoA
mode is good. Although, there is no need of  > > indicating what type of
value is used for replay protection. 
 > > Although, Vijay likes to see this to be clarified.
 > > - Charlie suggest removing support of co-located CoA mode.
 > >
 > > Hence, I have three options:
 > > 1. Remove the paragraph which discusses co-located CoA  > > support
(last paragraph of section 3.1) 2. Make changes to  > > indicate that
there is no challenge included in the MN-CoA  > > extension for
co-located CoA mode.
 > > 3. Include changes proposed by Vijay in earlier email.
 > >
 > > Please send me reply suggesting which option you prefer.
 > >
 > > Regards,
 > > Jayshree
 > >
 > > From: [email-masked] [mailto:[email-masked]] On  > >
Behalf Of Charles E. Perkins  > > Sent: Wednesday, November 30, 2005
7:05 PM  > > To: Kent Leung (kleung)  > > Cc: [email-masked];
[email-masked]  > > Subject: Re: [Mip4] review:
draft-ietf-mip4-rfc3012bis-04.txt  > >  > >  > >  > > Hello folks,  > >
> > I do not believe the document should support co-located CoA  > >
mode.  The point is to enable some mechanism for use by the  > > foreign
agent.  There is no need for a mobile node to use the  > > challenge.
No additional replay protection is afforded.
 > >
 > > I would prefer for the use of the extension to be prohibited  > >
whenever the 'D' bit is set.
 > >
 > > Even when a foreign agent is sending 'R' bit advertisements,  > >
there isn't any significant functionality gained.
 > >
 > > Perhaps it's technically feasible to have the challenge in  > >
such situations, but (i) it is wasteful and (ii) I would not  > > like
to see it become considered a mandatory part of any  > > mobile node
implementation where co-located care-of addresses  > > are used, for
whatever reason.
 > >
 > > Regards,
 > > Charlie P.
 > >
 > > PS. Please excuse if I have overlooked some e-mail about this.
 > >
 > >
 > > >On this particular topic, I don't understand what is missing in
the  > > >details to support the CCoA mode?  Since the draft covers
MN-AAA  > > >authentication with NAS in between, I would like to see
both  > > FA (CoA)  > > >and HA (CCoA) modes supported.  Where else
would we be able to cover  > > >just the CCoA for MN-AAA authentication
if not in this draft?
 > > >
 > > >Kent
 > > >
 > > >
 > > >
 > > >
 > > >>not at this late stage. its fine as it is. however, I have  > >
one comment  > > >>on the support for co-located CoA mode. the draft
claims it  > > supports  > > >>it but there really isnt enough detail.
 > > >>IMO, it should be clarified that only FA mode is described in the
> > >>draft.
 > > >>
 > > >>    
 > > >>
 > > >
 > > >
 > > >
 > >
 > >
 > >
 > > --
 > >      Charter page:
http://www.ietf.org/html.charters/mip4-charter.html
 > > Supplemental site: http://www.mip4.org/  > >

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Fri, 2 Dec 2005 12:20:31 -0500

I think the first 2 changes are pretty harmless. Even the third
probably, as long as we clarify that the challenge is only provided to
protect the foreign network, so in direct RRQ, you do not need the
challenge, not that ID field and challenge are two alternative replay
protections. ID protects HA, challenge protects FA..

Also the other change needed is the clarification of use of MN-AAA AE in
case of direct RRQ (challenge is absent).

Madjid

the changes I proposed include 2. the changes I suggested do the
following

- clarify that the MN MUST NOT include the challenge extension
- clarify that in the absence of the FA, there is no challenge generated
by the network.
- clarify that in the absence of a challenge, replay protection is
provided by the identification field.

Vijay

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Fri, 2 Dec 2005 12:24:00 -0500

The point really is that a generalized extension is defined only for one
case, leaving treatment of CCOA underspecified. And yes, whether the
challenge extension is not allowed, or it includes 0s (pretty useless)
or whatever else needs to be specified somewhere.

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Charles E. Perkins
Sent: Thursday, December 01, 2005 7:55 PM
To: Kent Leung (kleung)
Cc: Jayshree Bharatia; [email-masked]
Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Hello Kent,

What if the draft allows the Generalized Authentication extension for
mobile nodes with CCoA, but does not allow the challenge extension?  I
don't see what's wrong with this, since the draft is "about" a foreign
agent protocol.

Then, enabling the Generalized Authentication extension for co-located
CoA just amounts to reasonable practice, not refocussing the document on
colocated CoA.

Regards,
Charlie P.

Kent Leung (kleung) wrote:

>I vote for #2.  The reason is that that RFC 3012 is addressing two 

>the NAS is FA or HA.
>I would like to keep this in one draft, which means both functions 
>should be covered fully (i.e. including CCoA mode).  I believe that 

>protection is using nonce/timestamp.  But I don't see a need since this

>is fundamental function of Mobile IP itself.
>
>Kent
>  
>

---

From: "Jayshree Bharatia" <[email-masked]>
Date: Mon, 5 Dec 2005 12:58:19 -0600

Hi Gabriel,

My apology for not responding you earlier. I thought I took care of your
comments. Anyway, I have updated document with many of your comments.
Although, I have some clarification questions for few which are included
inline.

Thanks,
Jayshree 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
gabriel montenegro
Sent: Wednesday, September 21, 2005 2:36 AM
To: [email-masked]
Subject: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

I reviewed this document. I feel it is not quite RFC quality, being a
bit confusing and verbose/repetitive in sections. A big issue 
I have is that it is really two different things bunched together:
	
- Challenge/Response extention
- Generalized Authentication Extension

They really should be two documents, specially cuz this is a revision,
the proper 
opportunity to make such changes.
[JB] Based on earlier email from Henrik, I would think that WG decision
is not to split this draft at this time. So I haven't addressed this
comment.

I'm also wondering about the use of MD5 throughout. Given recent
developments, some folks (not unanimously, though) are already calling
for the deprecation of SHA-1, and here we are recommending MD5 for a
proposed standard? If this is what's being used today, then this could
be published as a historical or informational RFC, 
If the intent is to fix a few bugs in rfc 3012, perhaps the errata page
is enough. But the use of MD5 should be reviewed by the security ADs.
CHAP should also be avoided, due to its vulnerability to dictionary
attacks. For example, EAP advices against its usage (see rfc3748 section
7.6). Even more explicitly, the EAP requirements for wireless usage call
for mandatory resistance to dictionary attacks:
http://www.faqs.org/rfcs/rfc4017.html, section 2.2.

This comment applies to 3344bis as well.
[JB] I am fine with having a review with security Ads on this topic. 

Nit: saw "processing for" in several places. Shouldn't it be "processing
of"? 
[JB] Done

Other comments interspersed below.

> 
> 
> 
> Network Working Group                                 Charles E.
Perkins
> Internet-Draft                                     Nokia Research
Center
> Expires: December 19, 2005                                Pat R.
Calhoun
>                                                     Black Storm
Networks
>                                                       Jayshree.
Bharatia
>                                                          Nortel
Networks
>                                                            June 17,
> 2005

Please update the author contact information now, instead of waiting for
AUTH48.

...
> Abstract
...

>    Furthermore, this document updates RFC3344 by including new
>    authentication extension called the Mobile-AAA Authentication
>    extension.  This new extension is provided so that a mobile node
can
>    supply credentials for authorization using commonly available AAA
>    infrastructure elements.  This Authorization-enabling extension MAY
>    co-exist in the same Registration Request with Authentication
>    extensions defined for Mobile IP Registration by RFC3344.  This
>    document obsoletes RFC3012.

This should be a separate document.        

[JB] Should be covered by my earlier comment on WG decision of not
splitting the document. 
...

> 1.  Introduction
> 
>    Mobile IP defines the Mobile-Foreign Authentication extension to
>    allow a mobile node to authenticate itself to a foreign agent.
> Such

It can provide *mutual* authentication, right? Suggest making it
explicit here precisely because this extension differs in that it is
unilateral. It does not aid the MN in establishing legitimacy of the FA;
only the opposite is true. 

[JB] MN-FA Authentication extension is defined by RFC3344 so I am not
sure adding clarification on that extension is necessary here. I would
think that purpose of having MN-AAA is clearly defined. If you have any
specific text change, please let me know and I will update the document.

>    authentication mechanisms are mostly external to the principal
>    operation of Mobile IP, since the foreign agent can easily route
>    packets to and from a mobile node whether or not the mobile node is
>    reporting a legitimately owned home address to the foreign agent.
>    Unfortunately, that extension does not provide the foreign agent
any
>    direct guarantee that the protocol is protected from replays, and
>    does not allow for the use of CHAP [RFC1994] for authenticating

See above comments on CHAP. Shouldn't be a motivation for a new PS
document. 

[JB] As indicated in my earlier comment, I am ok with further review by
security ADs. ...
> 2.  Mobile IP Agent Advertisement Challenge Extension

The organization of this section (describing a format), followed by the
next section on operation, followed by other sections (4 and 5) on
packet formats is very confusing. Suggest having all the packet formats
bunched together, following each other. 
Also suggest preceding them by some section on overview of operation
(perhaps section 3 itself.

...
[JB] I would rather not do restructuring at this stage, unless others
are having same issue and see value in doing so.
> 
>    The Challenge extension, illustrated in Figure 1, is inserted in
the
>    Agent Advertisements by the foreign agent, in order to communicate
a
>    previously unused challenge value that can be used by the mobile
node
>    to compute an authentication for its next registration request
>    message.  The challenge is selected by the foreign agent to provide
>    local assurance that the mobile node is not replaying any earlier
>    registration request.  Eastlake, et al.  [RFC1750] provides more
>    information on generating pseudo-random numbers suitable for use as
>    values for the challenge.

Perhaps clarify that the transport of these is unicast.
[JB]Can you clarify your comment further? As mentioned in the draft,
Agent Advertisement can be multicast or unicast. 

> 2.1  Handling of Solicited Agent Advertisements
...
>    advertised Challenges.  It must instead re-use the most recent of
the
>    CHALLENGE_WINDOW Advertisement Challenge values.

This is the first time this is mentioned, and it is not explained. It is

mentioned several times afterwards, but is never really explained until
the appendices. Explanation or at least a reference to the proper
section should accompany the first reference. 

[JB] Done (provided reference of section 9)

> 3.  Operation
> 
>    This section describes modifications to the Mobile IP registration
>    process [RFC3344] which may occur after the foreign agent issues a
>    Mobile IP Agent Advertisement containing the Challenge on its local

Given that Agent Advertisements can be multicast, I'd clarify here that
these are unicast.

...
[JB] This is true that Agent Advertisements can be multicast or unicast.
In section 2, we have explicit description on handling challenges in
case of multicast and unicast. So I am not sure why we need to mention
here that Agent Advertisement is going to be unicast only.

> 3.2  Foreign Agent Processing for Registration Requests

Perhaps s/for/of/  
E.g., 3344 uses "processing of" but never "processing for"
[JB] Done
> 
>    Upon receipt of the Registration Request, if the foreign agent has
>    issued a Challenge as part of its Agent Advertisements, and it does

s/and it/and if it/
[JB] Done
...

>    unless the Registration Reply has already been
>    received from the home agent.  In this case the foreign agent MUST
>    preserve the value of the Code field set by the home agent and MUST
>    put its own rejection code only in the Status field of the FA Error
>    extension (defined in [FAERR]).

The above does not belong here, but in the next section (3.3) on
handling Registration Replies. [JB] Done s/code only in/code in/ [JB]
Done ...
>    with Code value FA_BAD_AAA_AUTH.  If the Mobile-AAA Authentication
>    Extension is present in the Registration Request, the foreign agent
>    MUST NOT remove the Mobile-AAA Authentication Extension and the
>    Mobile-Foreign Challenge Extension from the Registration Request.

s/Request./Request, before forwarding to the Home Agent./
[JB] Done

>    Appendix C provides an example of an action that could be taken by
a
>    foreign agent.
> 
>    In the event that the Challenge extension is authenticated through
>    the Mobile-Foreign Authentication extension and the Mobile-AAA
>    Authentication extension is not present, the foreign agent MAY
remove
>    the Challenge Extension from the Registration Request without
>    disturbing the authentication value computed by the mobile node for
>    use by the AAA or the home agent.

Sometimes "Challenge extension" and sometimes "Challenge Extension"
Please double-check throughout to make sure capitalization is
consistent. 

[JB] Done (changed to "Challenge extension"]

"use by the AAA" is confusing as it was just said that this case has no 
AAA, so perhaps clarifying text could be added:

s/home agent./home agent, the former because it is not present, the
latter because its calculation does not include the Challenge Extension.

Or one could reword, of course...
[JB] I have reworded the above paragraph as:
"In the event that the Challenge extension is authenticated through the
Mobile-Foreign Authentication extension and the Mobile-AAA
Authentication extension is not present, the foreign agent MAY remove
the Challenge extension from the Registration Request without disturbing
the authentication value used for the computation."

...

>    If the foreign agent does not remove the Challenge extension, then
>    the foreign agent SHOULD store the Challenge value as part of the

notice the should here. But what if it's not stored? See below.

>    pending registration request list [RFC3344].  Also, if the
>    Registration Reply coming from the home agent does not include the
>    Challenge Extension, the foreign agent SHOULD NOT reject the
>    Registration Request message.  If the Challenge Extension is
present
>    in the Registration Reply, it MUST be the same Challenge value that
>    was included in the Registration Request.  If the Challenge value
>    differs in the Registration Reply received from the home agent, the
>    foreign agent MUST insert an FA Error extension with Status value
>    HA_WRONG_CHALLENGE in the Registration Reply sent to the mobile
node
>    (see Section 10).

The above section does not belong here but in the next section on
Registration Replies. Mixing section contents like this makes things
very confusing. 

[JB] Done

Above, notice the MUST be the same Challenge value. But if the value was
not stored (as allowed by the SHOULD above), then what happens? The
error recovery and error status value above does not take that into
account.

[JB] I am ok with your suggestion but I haven't made this change yet. I
need input from others with respect to backward compatibility if
"should" changes to "must".
 
>    If the foreign agent does remove the Challenge extension and
>    applicable authentication from the Registration Request message,
then
>    it SHOULD insert the Identification field from the Registration

s/insert/store/
[JB] Done

>    Request message along with its record-keeping information about the

s/along with/as part of/
[JB] Done

>    particular mobile node in order to protect against replays.
> 
> 3.3  Foreign Agent Processing for Registration Replies

s/for/of/
[JB] Done
...
>    If the foreign agent receives a Registration Reply with the Code
>    value HA_BAD_AAA_AUTH, it MUST be relayed to the mobile node.

Presumably, regardless of code value, the Reg Reply must be relayed,
yes? If so, why is this here? Suggest deleting the above as it is 
redundant. In general, there seems to be a lot of repetition. One reads
them carefully expecting there to be an exception to a rule, but there
is none, so it's just tiring.

[JB] I have reworded as below to reflect that the error received in the
Registration Reply from the HA is relayed to the MN in the Registration
Reply. "If the foreign agent receives a Registration Reply with the Code
value HA_BAD_AAA_AUTH, the Registration Reply with this Code value MUST
be relayed to the mobile node."

> 3.4  Home Agent Processing for the Challenge Extensions
...

>    The home agent MAY receive a Registration Request with the
> Mobile-AAA

s/MAY/may/
JB] Done

Does not seem prescriptive but merely describing an eventuality, so I
don't think we need rfc 2026 language here.

> 3.5  Mobile Node Processing for Registration Replies
...
>    UNKNOWN_CHALLENGE: This error code is received by the mobile node
in
>    the case where the mobile node has moved to a new foreign agent
> that

s/in the case where the mobile node/if it/
[JB] As a part of Jari's comments, this text is removed.

>    MISSING_CHALLENGE: A mobile node that does not include a Challenge
>    when the Mobile-Foreign Authentication extension is present may
>    receive a MISSING_CHALLENGE error.  In this case, the mobile node
>    SHOULD send a Challenge extension containing an unused challenge in
>    the next Registration Request.
> 
>    BAD_AUTHENTICATION: This error is sent by the foreign agent if the
>    Registration Request contains a Mobile-Foreign Authentication
>    extension with an incorrect authenticator that fails verification.
A
>    mobile node that receives a BAD_AUTHENTICATION Code value SHOULD
>    include the Mobile-AAA Authentication Extension in the next
>    Registration Request.  This will make it possible for the Foreign
>    Agent to use its AAA infrastructure in order to authenticate the
>    mobile node.  In this case, the mobile node MUST use a new
Challenge
>    value in any new registration, obtained either from an Agent
>    Advertisement, or from a Challenge extension to the Registration
>    Reply containing the error.
> 
>    FA_BAD_AAA_AUTH: This error is sent by the foreign agent if the
>    Registration Request contains a Mobile-AAA Authentication extension
>    with an incorrect authenticator that fails verification.  A mobile
>    node that receives a FA_BAD_AAA_AUTH MUST use a new Challenge value
>    in any new registration, obtained either from an Agent
Advertisement,
>    or from a Challenge extension to the Registration Reply containing
>    the error.
> 
>    HA_BAD_AAA_AUTH: This error is sent by the home agent if the
>    Registration Request contains a Mobile-AAA Authentication extension
>    with an incorrect authenticator that fails verification.  A mobile

s/incorrect//
[JB] As a part of Jari's comments, this text is removed.

>    node that receives a HA_BAD_AAA_AUTH MUST use a new Challenge value
>    in any new registration, obtained either from an Agent
Advertisement,
>    or from a Challenge extension to the Registration Reply containing
>    the error.
> 
>    STALE_CHALLENGE: If the foreign agent receives a Registration
Request
>    with a Challenge extension containing a Challenge value previously
>    used by that mobile node, the mobile node MAY receive a
> Registration

s/MAY/may/
[JB] As a part of Jari's comments, this text is removed.

>    Reply to the mobile node containing the Code value STALE_CHALLENGE.
>    In such instances, the mobile node MUST use a new Challenge value
in
>    next Registration Request, obtained either from an Agent
>    Advertisement, or from a Challenge extension to the Registration
>    Reply containing the error.
> 
>    HA_WRONG_CHALLENGE: This error is sent by the foreign agent if the
>    Registration Reply from the home agent contains a different
Challenge
>    value from the one included in the Registration Request.

s/the one/that/

Repetitiveness in the challenge rules was already taken care of by
Jari's comments, I believe. 
 [JB] Yes. As a part of Jari's comments, this text is removed. ...

> 4.  Mobile-Foreign Challenge Extension
> 
>    This section specifies a new Mobile IP Registration extension that
is
>    used to satisfy a Challenge in an Agent Advertisement.  The
Challenge
>    extension to the Registration Request message is used to indicate
the
>    challenge that the mobile node is attempting to satisfy.
> 
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Type      |    Length     |          Challenge ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>              Figure 2: The Mobile-Foreign Challenge Extension
> 
>       Type:
> 
>          132 (skippable) (see [RFC3344])
> 
>       Length:
> 
>          Length of the Challenge value
> 
>       Challenge:
> 
>          The Challenge field is copied from the Challenge field found
in
>          the Agent Advertisement Challenge extension (see section 2).

s/Agent Advertisement/received/
Cuz Agent Advertisements are not the only way to learn a Challenge. 
[JB] Done

> 5.  Generalized Mobile IP Authentication Extension

This really should be a separate document.

>    Several new authentication extensions have been designed for
various
>    control messages proposed for extensions to Mobile IP.  A new
>    authentication extension is required for a mobile node to present
its
>    credentials to any other entity other than the ones already
defined;
>    the only entities defined in the base Mobile IP specification
>    [RFC3344] are the home agent and the foreign agent.  It is the

s/It is/The/
[JB] Done

>    purpose of the generalized authentication extension defined here to

s/here to/here is to/
[JB] Done

...
> 6.  Mobile-AAA Authentication subtype
> 
>    The Generalized Authentication extension with subtype 1 will be
>    referred to as a Mobile-AAA Authentication extension.  The mobile
>    node MAY include a Mobile-AAA Authentication extension in any
>    Registration Request.  This extension MAY co-exist in the same
>    Registration Request with Authentication extensions defined for
>    Mobile IP Registration by [RFC3344].  If the mobile node does not

s/by//
[JB] Done
>    include a Mobile-Foreign Authentication [RFC3344] extension, then
> it

s/[RFC3344]//
[JB] Done

>    MUST include the Mobile-AAA Authentication extension whenever the
>    Challenge extension is present.  If both are present, the
Mobile-AAA
>    Authentication extension MUST precede the Mobile-Foreign
>    Authentication extension.
> 
>    If the Mobile-AAA Authentication extension is present, then the
>    Registration Message sent by the mobile node MUST contain the
Mobile-
>    Home Authentication extension [RFC3344] if it shares a security

notice this "if"

>    association with the home agent.  If both are present, the Mobile-

and this "if" as well.
This means that MN-HA Authentication is no longer a MUST, and that it
may be absent. I believe this is a departure from rfc 3344, and if so,
it should be flagged by explicitly saying so. 
[JB] Agree. I have reworded the paragraph as below:

From:
If the Mobile-AAA Authentication extension is present, then the
Registration Message sent by the mobile node MUST contain the
Mobile-Home Authentication extension [RFC3344] if it shares a security
association with the home agent.  If both are 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.

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

...

> 8.  SPIs for RADIUS AAA Servers
> 
>    Some AAA servers only admit a single security association, and thus
>    do not use the SPI numbers for Mobile IP authentication extensions
>    for use when determining the security association that would be
>    necessary for verifying the authentication information included
with
>    the Authentication extension.
> 
>    SPI number CHAP_SPI (see Section 9) is reserved for indicating the
>    following procedure for computing authentication data (called the
>    "authenticator"), which is used by many RADIUS servers [RFC2138]
>    today.
> 
>    To compute the authenticator, apply MD5 [RFC1321] computed on the
>    following data, in the order shown:
> 
>       High-order byte from Challenge || Key ||
> 
>       MD5(Preceding Mobile IP data ||
> 
>       Type, Subtype (if present), Length, SPI) ||
> 
>       Least-order 237 bytes from Challenge
> 
>    where the Type, Length, SPI, and possibly Subtype, are the fields
of
>    the authentication extension in use.  For instance, all four of
these
>    fields would be in use when SPI == CHAP_SPI is used with the
>    Generalized Authentication extension.  Since the RADIUS protocol
>    cannot carry attributes of length greater than 253, the preceding
>    Mobile IP data, type, subtype (if present), length and SPI are
hashed
>    using MD5.  Finally, the least significant 237 bytes of the
challenge
>    are concatenated.  If the challenge has fewer than 238 bytes, this
>    algorithm includes the high-order byte in the computation twice,
but
>    ensures that the challenge is used exactly as is.  Additional
padding
>    is never used to increase the length of the challenge; the input
data
>    is allowed to be shorter than 237 bytes long.

This draft starts by trying to help the FA, not the MN. so it should at
least do no harm to the MN. 

But this is something that can end up screwing the MN. Any device within
RF coverage of both can see everything above (including the challenge),
except the password used in CHAP. Given the weakness to dictionary
attacks, an exchange like the above effectively blasts the user's
password to anybody who cares to listen. This shouldn't be recommended.
Or am I missing something?

...
[JB] We can reflect what security AD may be proposing for this issue.

> 9.  Configurable Parameters
> 
>    Every Mobile IP agent supporting the extensions defined in this
>    document SHOULD be able to configure each parameter in the
following
>    table.  Each table entry contains the name of the parameter, the
>    default value, and the section of the document in which the
parameter
>    first appears.
> 
>        +------------------+---------------+---------------------+
>        | Parameter Name   | Default Value | Section of Document |
>        +------------------+---------------+---------------------+
>        | CHALLENGE_WINDOW | 2             | 3.2                 |

This has never been explained! And the first time it's mentioned is
section 2.1. [JB] I have given reference to this section (section 9) in
section 2.1

>        |                  |               |                     |
>        | CHAP_SPI         | 2             | 8                   |

First time it's mentioned is section 3.1.
[JB] We already have reference to section 9 for CHAP_SPI.
...

> 10.  Error Values
> 
>    Each entry in the following table contains the name of the Code
>    [RFC3344] to be returned in a Registration Reply, the value for the
>    Code, and the section in which the error is first mentioned in this
>    specification.

Why is the first time it's mentioned that important? What should be
referenced is the section in which it is properly explained (which 
could be forward referenced from wherever it's mentioned for the 
first time).
[JB] Done (removed "first" from the statement)
> 
>        +--------------------+-------+--------------------------+
>        | Error Name         | Value | Section of Document      |
>        +--------------------+-------+--------------------------+
>        | UNKNOWN_CHALLENGE  | 104   | 3.2                      |
>        |                    |       |                          |
>        | BAD_AUTHENTICATION | 67    | 3.2 - also see [RFC3344] |
>        |                    |       |                          |
>        | MISSING_CHALLENGE  | 105   | 3.1, 3.2                 |
>        |                    |       |                          |
>        | STALE_CHALLENGE    | 106   | 3.2                      |
>        |                    |       |                          |
>        | FA_BAD_AAA_AUTH    | TBD   | 3.2                      |
>        |                    |       |                          |
>        | HA_BAD_AAA_AUTH    | TBD   | 3.4                      |
>        |                    |       |                          |
>        | HA_WRONG_CHALLENGE | TBD   | 3.2                      |
>        +--------------------+-------+--------------------------+
> 
>                            Table 2: Error Values
> 

Given the errors seen in the previous table, please double-check all the
above.

...
[JB] Done

> 12.  Security Considerations
> 
>    In the event that a malicious mobile node attempts to replay the
>    authenticator for an old Mobile-Foreign Challenge, the foreign
agent
>    would detect it since the agent always checks whether it has
recently
>    advertised the Challenge (see Section 3.2).  Allowing mobile nodes
>    with different IP addresses or NAIs to use the same Challenge value
>    does not represent a security vulnerability, because the
>    authentication data provided by the mobile node will be computed
over
>    data that is different (at least by the bytes of the mobile nodes'
IP
>    addresses).

OLD:
     at least by the bytes of the mobile nodes' IP addresses

NEW:
     at least the mobile node's IP address will vary

[JB] Done
...

>    Section 8 (SPI For RADIUS AAA Servers) defines a method of
computing
>    the Generalized Mobile IP Authentication Extension's authenticator
>    field using MD5 in a manner that is consistent with RADIUS
[RFC2138].
>    The use of MD5 in the method described in Section 8 is less secure
>    than HMAC-MD5 [RFC2104], and should be avoided whenever possible.

s/should/MUST/
But really, this MUST be avoided always, unless there's other (e.g.,
link-layer
mechanisms) that can help prevent the dictionary attacks. I guess the
latter applies throughout to the other methods as well. 

[JB] Done. I would think that "whenever possible" term will take care of
backward compatibility issue.

>    Note that an active attacker may try to prevent successful
>    registrations by sending a large number of Agent Solicitations or
>    bogus Registration Requests, each of which could cause the foreign
>    agent to respond with a fresh challenge, invalidating the challenge
>    that the MN is currently trying to use.  To prevent such attacks,
the
>    foreign agent MUST NOT invalidate previously unused challenges when
>    responding to unauthenticated Registration Requests or Agent
>    Solicitations.  In addition, the foreign agent MUST NOT allocate
new
>    storage when responding to such messages, because this would also
>    create the possibility of denial of service.

Should say that it does not seek to provide any assurance to the MN,
only to the FA and infrastructure.

[JB] I though it is implicit. Not sure we really need specific text
saying that. I am ok clarifying further if others have issue following
the intent.

...
> 14.  Normative References
> 
>    [FAERR]    Perkins, C., "Foreign Agent Error Extension for Mobile
>               IPv4", draft-perkins-mip4-faerr-00.txt (work in
progress),
>               January 2004.

Update this reference to the latest version.
[JB] Done
...
> Authors' Addresses
...
>    Pat R. Calhoun
>    Black Storm Networks
>    110 Nortech Parkway
>    San Jose, CA  95134
> 
>    Fax:   +1 720-293-7501
>    Email: [email-masked]

Update this info.
[JB] Done

> Appendix A.  Change History

I like Jari's suggestion to detail the changes with respect to 3012.
[JB] Done
...

> Appendix B.  Verification Infrastructure
...
>    In order to verify the credentials of the mobile node, we imagine

s/imagine/assume/
[JB] Done
...

> Appendix C.  Message Flow for FA Challenge Messaging with Mobile-AAA
>              Extension
...
>    1.  The foreign agent disseminates a Challenge Value in an Agent

s/disseminates/includes/ 
[JB] Done

s/an Agent/a unicast Agent/
[JB] Done
...

> Appendix E.  Foreign Agent Algorithm for Tracking Used Challenges

This section is normative, and is where we finally see the explanation
of how to use CHALLENGE_WINDOW. This should be in the body of the
document and must not remain in an appendix.

The appendix should only have the pseudo-code example.
[JB] I am waiting for further feedback from the WG on this comment and
hence haven't included it in the document.

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Mon, 5 Dec 2005 18:16:41 -0500

Hi Vijay,

Agreed, however remember that SPI=CHAP-SPI and the authenticator using
the challenge value is defined under section "8: SPIs for RADIUS AAA
Servers"
So your addition should go there.

Not sure what the document recommends for Diameter, probably nothing.
For Diameter, 4004 uses MIP-MN-AAA-SPI AVP which is different from CHAP
SPI, not sure how they handle it.

Madjid

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]] 
Sent: Monday, December 05, 2005 3:27 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: Kent Leung (kleung); Jayshree Bharatia; [email-masked]; Charles E.
Perkins

Nakhjiri Madjid-MNAKHJI1 wrote:
> Vijay,
> 
> However we want to do it, needs to be specified. Motorola development 
> folks share Nokia's confusion:) I think only a handful of people in 
> the industry know exactly how 3344, 3012, 3957, 4004 all work together

> and that is why the key bootstrapping is not getting any traction in 
> the implementations. We have endless internal "educative" sessions on 
> this too :) I believe 4004  for Diameter missed the problem with 
> MN-AAA AE for direct RRQs.
> We tried to cover it in RADIUS-MIP draft, but I don't think that is 
> the right place for it. We suggested zero based on Charlie's initial 
> suggestion to make implementation of CoA and CCoA less complex, you 
> have the same field, you just enter zero when no value is available.

then we need one more clarification. if the SPI is set to CHAP_SPI and
the mobile node is using co-located CoA mode, it sets the challenge to
0. if the SPI is something else, the mobile node leaves out the
challenge while calculating the authenticator field.

agreed? please excuse me if this sounds obvious to you. :)

Vijay

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Mon, 5 Dec 2005 18:41:47 -0500

Jayshree, 

Appreciate for the effort on gaining consensus.
I don't have a strong position either way, the text is now complete.
I sort of agree with Vijay that you might want to add that "In CCoA,
replay protection is provided through methods specified in 3344
(Identification field in RRQ)", this is just to keep people from
wondering...
I am fine with either way consensus goes on this one.

Madjid

-----Original Message-----
From: Jayshree Bharatia [mailto:[email-masked]] 
Sent: Monday, December 05, 2005 2:30 PM
To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung)
Cc: [email-masked]; Charles E. Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Hi all,

Thanks for all your comments. In summary, I see that we have now general
agreement that co-located CoA support for MN-AAA extension will be part
of this draft. In that respect, I am considering text proposed by Vijay
for section 3.1 and 3.5. 

Currently we have text saying that the mechanism used by the mobile node
to obtain the Challenge value in this case is outside the scope of this
document. Based on the input from Kent and Madjid, the following is the
proposal (modified Vijay's proposal for section 3.5):

From:
In the co-located CoA mode, the mobile node will receive a Registration
Reply without the Challenge Extension and processes the Registration
Reply as specified in [RFC3344].

To:
In the co-located CoA mode, the mobile node will receive a Registration
Reply without the Challenge Extension and processes the Registration
Reply as specified in [RFC3344]. In this case, the Challenge value 0 is
recommended for the authenticator calculation mentioned in section 8.

Please note that I haven't included Vijay's proposed text for a new
section (5) and also for Security Considerations since they are already
part of RFC3344.

Regards,
Jayshree

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Friday, December 02, 2005 11:31 AM
To: Vijay Devarapalli; Kent Leung (kleung)
Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; [email-masked]; Charles E.
Perkins

Vijay,

However we want to do it, needs to be specified. Motorola development
folks share Nokia's confusion:) I think only a handful of people in the
industry know exactly how 3344, 3012, 3957, 4004 all work together and
that is why the key bootstrapping is not getting any traction in the
implementations. We have endless internal "educative" sessions on this
too :) I believe 4004  for Diameter missed the problem with MN-AAA AE
for direct RRQs. We tried to cover it in RADIUS-MIP draft, but I don't
think that is the right place for it. We suggested zero based on
Charlie's initial suggestion to make implementation of CoA and CCoA less
complex, you have the same field, you just enter zero when no value is
available.

Madjid

> Also, MN sets the challenge value to zero in the MN-AAA authenticator
> computation.

hmm.. how about the MN does not use any challenge value (whether 0 or
anything else)? it calculates the MN-AAA authenticator without any
challenge field. one the basic clarifications that is needed is that
there is no challenge to use when there is no FA.

> I don't think this is necessary, but doesn't matter too much to me
> either.

well, folks inside Nokia who implement mobile nodes were very confused
by RFC 3012. it would be good to make this explicit.

Vijay

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Mon, 5 Dec 2005 19:03:29 -0500

Hi Jayshree,

Please note that this also impacts section 8 on use of CHAP SPI for
RADIUS server, as I mentioned in a previous email.

Regards,

Madjid 

-----Original Message-----
From: Jayshree Bharatia [mailto:[email-masked]] 
Sent: Monday, December 05, 2005 5:57 PM
To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung)
Cc: [email-masked]; Charles E. Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Hi Madjid,

OK. In this case, I will include his text in section 3.1 (Mobile Node
processing of Registration Requests) rather than having a new section as
he suggested. I will also include his proposed text for "Security
Considerations" section.

Thanks,
Jayshree

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Monday, December 05, 2005 5:42 PM
To: Bharatia, Jayshree [RICH1:2H13:EXCH]; Vijay Devarapalli; Kent Leung
(kleung)

Jayshree, 

Appreciate for the effort on gaining consensus.
I don't have a strong position either way, the text is now complete. I
sort of agree with Vijay that you might want to add that "In CCoA,
replay protection is provided through methods specified in 3344
(Identification field in RRQ)", this is just to keep people from
wondering... I am fine with either way consensus goes on this one.

Madjid

-----Original Message-----
From: Jayshree Bharatia [mailto:[email-masked]] 
Sent: Monday, December 05, 2005 2:30 PM
To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung)
Cc: [email-masked]; Charles E. Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Hi all,

From:

To:

Regards,
Jayshree

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Friday, December 02, 2005 11:31 AM
To: Vijay Devarapalli; Kent Leung (kleung)
Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; [email-masked]; Charles E.
Perkins

Vijay,

Madjid

Vijay

---

From: "Jayshree Bharatia" <[email-masked]>
Date: Mon, 5 Dec 2005 18:10:20 -0600

Hi Madjid,

I have covered this part in the modified text for section 3.4 I sent
earlier today. Please check that and see if you like to add or modify. 

In short, most of Vijay's proposal is going in. But I have slightly
modified text for section 3.5 to include value of challenge for
authenticator computation in section 8. Also, instead of new section, I
will include his proposed text to section 3.1. 

Regards,
Jayshree

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]] 
Sent: Monday, December 05, 2005 6:03 PM
To: Bharatia, Jayshree [RICH1:2H13:EXCH]; Vijay Devarapalli; Kent Leung
(kleung)

Hi Jayshree,

Regards,

Madjid 

-----Original Message-----
From: Jayshree Bharatia [mailto:[email-masked]] 
Sent: Monday, December 05, 2005 5:57 PM
To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung)
Cc: [email-masked]; Charles E. Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Hi Madjid,

Thanks,
Jayshree

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Monday, December 05, 2005 5:42 PM
To: Bharatia, Jayshree [RICH1:2H13:EXCH]; Vijay Devarapalli; Kent Leung
(kleung)

Jayshree, 

Madjid

-----Original Message-----
From: Jayshree Bharatia [mailto:[email-masked]] 
Sent: Monday, December 05, 2005 2:30 PM
To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung)
Cc: [email-masked]; Charles E. Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Hi all,

From:

To:

Regards,
Jayshree

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Friday, December 02, 2005 11:31 AM
To: Vijay Devarapalli; Kent Leung (kleung)
Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; [email-masked]; Charles E.
Perkins

Vijay,

Madjid

Vijay

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Thu, 8 Dec 2005 15:57:00 -0500

Sorry, I should have responded to this email then. If you could add more
guidance in section 8 that would be great.

Madjid 

-----Original Message-----
From: Jayshree Bharatia [mailto:[email-masked]] 
Sent: Monday, December 05, 2005 6:10 PM
To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung)
Cc: [email-masked]; Charles E. Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Hi Madjid,

Regards,
Jayshree

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Monday, December 05, 2005 6:03 PM
To: Bharatia, Jayshree [RICH1:2H13:EXCH]; Vijay Devarapalli; Kent Leung
(kleung)

Hi Jayshree,

Regards,

Madjid 

-----Original Message-----
From: Jayshree Bharatia [mailto:[email-masked]] 
Sent: Monday, December 05, 2005 5:57 PM
To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung)
Cc: [email-masked]; Charles E. Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Hi Madjid,

Thanks,
Jayshree

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Monday, December 05, 2005 5:42 PM
To: Bharatia, Jayshree [RICH1:2H13:EXCH]; Vijay Devarapalli; Kent Leung
(kleung)

Jayshree, 

Madjid

-----Original Message-----
From: Jayshree Bharatia [mailto:[email-masked]] 
Sent: Monday, December 05, 2005 2:30 PM
To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung)
Cc: [email-masked]; Charles E. Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Hi all,

From:

To:

Regards,
Jayshree

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Friday, December 02, 2005 11:31 AM
To: Vijay Devarapalli; Kent Leung (kleung)
Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; [email-masked]; Charles E.
Perkins

Vijay,

Madjid

Vijay