Mobile IPv4 Challenge/Response Extensions (Revised)
draft-ietf-mip4-rfc3012bis-05

[Ballot comment]
The Gen-ART review from Elwyn Davies cuts very deep so like Sam, I will abstain.

Summary of the review:

...this draft needs considerably more work to be a useful PS.  There has to be some doubt, given the use of CHAP, whether it is *worth* devoting too much effort to it, but that is a decision for others.  The overall impression that comes over from the document is a hurried attempt to patch up a crumbling edifice that maybe ought to be demolished and rebuilt differently.  The convoluted logic described and the fact that it is extensions to, combinations of or realignments of about three other protocols makes it extremely difficult to see whether the whole thing could be correct - the additions since RFC3012 appear to be attempts to fix something that was pretty broken!

Full review (actually of the previous version, but still applicable);

http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-mip4-rfc3012bis-04-davies.txt

[Ballot comment]
I didn't like this for MIP6 and for the same reasons I cannot support
it for MIP4.
I understand it's already on the standards track so I'm not going to block the document.

[Ballot discuss]
The title page header needs to indicate that this document updates
  RFC 3344, and it obsoletes RFC 3012.

  There are not any known problems with HMAC-MD5; however, problems
  could be found in the future.  How can HMAC use a stronger one-way
  hash function in the future?  Please update the Security
  Considerations to state how to make such a transition.

[Note]: '11/22/05:  Open issues remain regarding co-located care of addresses?  Need to clarify how/if this was resolved before this is reviewed by the IESG.' added by Margaret Wasserman

Follow-up IANA Last Call Comments:
Author has clarified where the error codes should go:
Please interpret those as below:
Error code from Home Agent => HA_BAD_AAA_AUTH (128-192 range )
Error codes from Foreign Agent => FA_BAD_AAA_AUTH and HA_WRONG_CHALLENGE
(64-127 range)
Author has also confirmed that the references for RFC 3012 should be replaced with this document.

IANA Last Call Comments:
We understand this document to add 3 new error codes.  Should FA_BAD_AAA_AUTH and HA_BAD_AAA_AUTH go in the 128-192 range (Error Codes from the Home Agent)and HA_WRONG_CHALLENGE should go in the 64-127 range (Error Codes from the Foreign Agent) in the Code Values for Mobile IP Registration Reply Messages registry found at http://www.iana.org/assignments/mobileip-numbers? 

Should the refereces for RFC3012 for the existing parameters be replaced with this new document? 

Clarification regarding the above is needed.
We understand the above to be the only IANA Actions.

Gabriel's review:

From: gabriel montenegro
To: mip4@ietf.org
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.

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.

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

Other comments interspersed below.

>
>
>
> Network Working Group                                Charles E. Perkins
> Internet-Draft ...
...snip...
>                                                          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
...snip...
>    extensions defined for Mobile IP Registration by RFC3344.  This
>    document obsoletes RFC3012.

This should be a separate 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.

>    authentication mechanisms are mostly external to the principal
>    operation of Mobile IP, since the foreign agent can easily route
...snip...
>    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.

...

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

...

>
>    The Challenge extension, illustrated in Figure 1, is inserted in the
>    Agent Advertisements by the foreign agent, in order to communicate a
...snip...
>    information on generating pseudo-random numbers suitable for use as
>    values for the challenge.

Perhaps clarify that the transport of these is 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.

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

...

> 3.2  Foreign Agent Processing for Registration Requests

Perhaps s/for/of/ 
E.g., 3344 uses "processing of" but never "processing for"

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

...

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

s/code only in/code in/

...

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

>    Appendix C provides an example of an action that could be taken by a
>    foreign agent.
>
>    In the event that the Challenge ...
...snip...
>    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.

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

...

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

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.

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

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

s/along with/as part of/

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

s/for/of/

...

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

> 3.4  Home Agent Processing for the Challenge Extensions

...

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

s/MAY/may/

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/

>    MISSING_CHALLENGE: A mobile node that does not include a Challenge
>    when the Mobile-Foreign Authentication extension is present may
...snip...
>    Registration Request contains a Mobile-AAA Authentication extension
>    with an incorrect authenticator that fails verification.  A mobile

s/incorrect//

>    node that receives a HA_BAD_AAA_AUTH MUST use a new Challenge value
>    in any new registration, obtained either from an Agent ...
...snip...
>    with a Challenge extension containing a Challenge value previously
>    used by that mobile node, the mobile node MAY receive a Registration

s/MAY/may/

>    Reply to the mobile node containing the Code value STALE_CHALLENGE.
>    In such instances, the mobile node MUST use a new Challenge value in
...snip...
>    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.

...

> 4.  Mobile-Foreign Challenge Extension
>
>    This section specifies a new Mobile IP Registration extension that is
...snip...
>          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.

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

>    purpose of the generalized authentication extension defined here to

s/here to/here is to/

...

> 6.  Mobile-AAA Authentication subtype
>
>    The Generalized Authentication extension with subtype 1 will be
...snip...
>    Registration Request with Authentication extensions defined for
>    Mobile IP Registration by [RFC3344].  If the mobile node does not

s/by//

>    include a Mobile-Foreign Authentication [RFC3344] extension, then it

s/[RFC3344]//

>    MUST include the Mobile-AAA Authentication extension whenever the
>    Challenge extension is present.  If both are present, the Mobile-AAA
...snip...
>    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.

...

> 8.  SPIs for RADIUS AAA Servers
>
>    Some AAA servers only admit a single security association, and thus
...snip...
>    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?

...

> 9.  Configurable Parameters
>
>    Every Mobile IP agent supporting the extensions defined in this
...snip...
>        +------------------+---------------+---------------------+
>        | CHALLENGE_WINDOW | 2            | 3.2                |

This has never been explained! And the first time it's mentioned is section 2.1.

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

First time it's mentioned is section 3.1.

...

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

>
>        +--------------------+-------+--------------------------+
>        | Error Name        | Value | Section of Document      |
...snip...
>        +--------------------+-------+--------------------------+
>
>                            Table 2: Error Values
>

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

...

> 12.  Security Considerations
>
>    In the event that a malicious mobile node attempts to replay the
...snip...
>    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


...

>    Section 8 (SPI For RADIUS AAA Servers) defines a method of computing
>    the Generalized Mobile IP Authentication Extension ...
...snip...
>... 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.

>    Note that an active attacker may try to prevent successful
>    registrations by sending a large number of Agent Solicitations or
...snip...
>    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.

...

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

...

> Authors' Addresses

...

>    Pat R. Calhoun
>    Black Storm Networks
>    110 Nortech Parkway
>    San Jose, CA  95134
>
>    Fax:  +1 720-293-7501
>    Email: pcalhoun@diameter.org

Update this info.

> Appendix A.  Change History

I like Jari's suggestion to detail the changes with respect to 3012.

...

> Appendix B.  Verification Infrastructure

...

>    In order to verify the credentials of the mobile node, we imagine

s/imagine/assume/

...

> 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/
s/an Agent/a unicast Agent/

...

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

Jari's review:

From: Jari Arkko
To: Charlie P , mip4@ietf.org
Cc:
Subject: [Mip4] draft-ietf-mip4-rfc3012bis-04.txt review

I understand that this draft is mainly a bug fix revision.
It seems reasonable, overall. Some small technical issues/
questions, clarifications, and nits below, however:

Technical:

> 3.5  Mobile Node Processing for Registration Replies
>
>    ...
>
>    UNKNOWN_CHALLENGE: ... MUST use a new Challenge value in
...snip...
>    Reply containing the error.
>
>    HA_WRONG_CHALLENGE: ... (no mention of the challenges)...

The challenge rules are almost the same for all error cases,
except the last one. I realize that the last one is a serious
error, and there's little that the mobile node can do about
it. However, the rules appear to imply that a new challenge
value is required in all cases, except if you retry after
HA_WRONG_CHALLENGE. Is there a reason for this? Presumably
if you want to retry the registration just in case the system
now works correctly, you would want to use a new, fresh
Challenge.

If there is no reason for this difference, I would suggest
deleting some of the case-specific rules above and replacing
them with generic text at the bottom of the section, saying
something like:

"In any case, if the mobile node attempts to register again
  after such an error, it MUST use a new Challenge value
  in such a registration, obtained either from an Agent Advertisement,
  or from a Challenge extension to the Registration Reply containing
  the error."

(And even this may be unnecessary, given that there is also a requirement
close to this in Section 4.)

> 11.  IANA Considerations
>
>    All protocol values in this specification are to be the same as
>    defined in RFC 3012 [RFC ...
...snip...
>    by this document.  Among these, HA_WRONG_CHALLENGE may appear in the
>    Status code of the FA Error extension defined in [FAERR].

Are IANA considerations & rules needed for the Subtype field
and SPI 0-255 range defined in Section 5?

> The protocol messages for handling the authentication within the
>  verification infrastructure, and identity of the agent performing the
>  verification of the foreign agent challenge, are not specified in
>  this document, because those operations do not have to be performed
>  by any Mobile IP entity.

I'm not sure I understand the part that begins "identity of the agent".
Also, mobile IP entities appear to have to be involved, at least the FA
is involved. Of course there can be other intermediate nodes such
as AAA proxies or authentication servers that are not Mobile IP
entities.

The fact that you are not specifying the verification infrastructure
becomes clear already earlier in Appendix B, so one way to deal with
this paragraph is to remove it.

>      Preceding Mobile IP data || Type, Subtype, Length, SPI

"Preceding Mobile IP data" is not explained. All bytes preceding
the start of the option in question, presumably? But starting
from the IP, UDP, or Mobile IP header or something else?

Editorial:

>    defined in RFC 3012 [RFC3012].  Additionaly, new error codes

s/additionaly/additionally/

>    node has attempted to use.  The following stylized programmatic
>    algorithm accomplishes this objective.  The maximum amount of total

Maybe s/stylized programmatic algorithm/pseudo-code algorithm/

> Appendix A.  Change History

Might be an idea to clean this up to a "What's New vs. RFC3012"
section. Right now its hard to see if all the changes are true
technical changes from 3012, editorial modifications, or just
back-and-forth modifications between draft revisions.

Other editorial issues:

I spent quite a bit of time trying to understand all the "MUST
precede" rules relating to the order of the options (Sect 3, Sect
6, etc). Its still hard to get an overview, and its also hard to
convince yourself that the specification of these rules is
complete and unambiguous. But I don't have a good suggestion
for a better way to describe the rules.

>      Least-order 237 bytes from Challenge
>      ...
>    using MD5.  Finally, the least significant 237 bytes of the challenge

Would "last 237 bytes" be easier to understand?

--Jari

MDIR review from Jari:

From: Jari Arkko
To: Margaret Wasserman
CC:  mdir@machshav.com
Subject: draft-ietf-mip4-rfc3012bis-04.txt review

I understand that this draft is mainly a bug fix revision.
It seems reasonable, overall.

Technical:

> 3.5  Mobile Node Processing for Registration Replies
>
>    ...
>
>    UNKNOWN_CHALLENGE: ... MUST use a new Challenge value in

...snip...

>    Reply containing the error.
>
>    HA_WRONG_CHALLENGE: ... (no mention of the challenges)...

The challenge rules are almost the same for all error cases,
except the last one. I realize that the last one is a serious
error, and there's little that the mobile node can do about
it. However, the rules appear to imply that a new challenge
value is required in all cases, except if you retry after
HA_WRONG_CHALLENGE. Is there a reason for this? Presumably
if you want to retry the registration just in case the system
now works correctly, you would want to use a new, fresh
Challenge.

If there is no reason for this difference, I would suggest
deleting some of the case-specific rules above and replacing
them with generic text at the bottom of the section, saying
something like:

"In any case, if the mobile node attempts to register again
  after such an error, it MUST use a new Challenge value
  in such a registration, obtained either from an Agent Advertisement,
  or from a Challenge extension to the Registration Reply containing
  the error."

(And even this may be unnecessary, given that there is also a requirement
close to this in Section 4.)

> 11.  IANA Considerations
>
>    All protocol values in this specification are to be the same as
>    defined in RFC 3012 [RFC ...

...snip...

>    by this document.  Among these, HA_WRONG_CHALLENGE may appear in the
>    Status code of the FA Error extension defined in [FAERR].

Are IANA considerations & rules needed for the Subtype field
and SPI 0-255 range defined in Section 5?

> The protocol messages for handling the authentication within the
>  verification infrastructure, and identity of the agent performing the
>  verification of the foreign agent challenge, are not specified in
>  this document, because those operations do not have to be performed
>  by any Mobile IP entity.

I'm not sure I understand the part that begins "identity of the agent".
Also, mobile IP entities appear to have to be involved, at least the FA
is involved. Of course there can be other intermediate nodes such
as AAA proxies or authentication servers that are not Mobile IP
entities.

The fact that you are not specifying the verification infrastructure
becomes clear already earlier in Appendix B, so one way to deal with
this paragraph is to remove it.

>      Preceding Mobile IP data || Type, Subtype, Length, SPI

"Preceding Mobile IP data" is not explained. All bytes preceding
the start of the option in question, presumably? But starting
from the IP, UDP, or Mobile IP header or something else?

Editorial:

>    defined in RFC 3012 [RFC3012].  Additionaly, new error codes

s/additionaly/additionally/

>    node has attempted to use.  The following stylized programmatic
>    algorithm accomplishes this objective.  The maximum amount of total

Maybe s/stylized programmatic algorithm/pseudo-code algorithm/

> Appendix A.  Change History

Might be an idea to clean this up to a "What's New vs. RFC3012"
section. Right now its hard to see if all the changes are true
technical changes from 3012, editorial modifications, or just
back-and-forth modifications between draft revisions.

Other editorial issues:

I spent quite a bit of time trying to understand all the "MUST
precede" rules relating to the order of the options (Sect 3, Sect
6, etc). Its still hard to get an overview, and its also hard to
convince yourself that the specification of these rules is
complete and unambiguous. But I don't have a good suggestion
for a better way to describe the rules.

>      Least-order 237 bytes from Challenge
>      ...
>    using MD5.  Finally, the least significant 237 bytes of the challenge

Would "last 237 bytes" be easier to understand?

MDIR review from Jari:

From: Jari Arkko
To: Margaret Wasserman
CC:  mdir@machshav.com
Subject: draft-ietf-mip4-rfc3012bis-04.txt review

I understand that this draft is mainly a bug fix revision.
It seems reasonable, overall.

Technical:

> 3.5  Mobile Node Processing for Registration Replies
>
>    ...
>
>    UNKNOWN_CHALLENGE: ... MUST use a new Challenge value in

...snip...

>    Reply containing the error.
>
>    HA_WRONG_CHALLENGE: ... (no mention of the challenges)...

The challenge rules are almost the same for all error cases,
except the last one. I realize that the last one is a serious
error, and there's little that the mobile node can do about
it. However, the rules appear to imply that a new challenge
value is required in all cases, except if you retry after
HA_WRONG_CHALLENGE. Is there a reason for this? Presumably
if you want to retry the registration just in case the system
now works correctly, you would want to use a new, fresh
Challenge.

If there is no reason for this difference, I would suggest
deleting some of the case-specific rules above and replacing
them with generic text at the bottom of the section, saying
something like:

"In any case, if the mobile node attempts to register again
  after such an error, it MUST use a new Challenge value
  in such a registration, obtained either from an Agent Advertisement,
  or from a Challenge extension to the Registration Reply containing
  the error."

(And even this may be unnecessary, given that there is also a requirement
close to this in Section 4.)

> 11.  IANA Considerations
>
>    All protocol values in this specification are to be the same as
>    defined in RFC 3012 [RFC ...

...snip...

>    by this document.  Among these, HA_WRONG_CHALLENGE may appear in the
>    Status code of the FA Error extension defined in [FAERR].

Are IANA considerations & rules needed for the Subtype field
and SPI 0-255 range defined in Section 5?

> The protocol messages for handling the authentication within the
>  verification infrastructure, and identity of the agent performing the
>  verification of the foreign agent challenge, are not specified in
>  this document, because those operations do not have to be performed
>  by any Mobile IP entity.

I'm not sure I understand the part that begins "identity of the agent".
Also, mobile IP entities appear to have to be involved, at least the FA
is involved. Of course there can be other intermediate nodes such
as AAA proxies or authentication servers that are not Mobile IP
entities.

The fact that you are not specifying the verification infrastructure
becomes clear already earlier in Appendix B, so one way to deal with
this paragraph is to remove it.

>      Preceding Mobile IP data || Type, Subtype, Length, SPI

"Preceding Mobile IP data" is not explained. All bytes preceding
the start of the option in question, presumably? But starting
from the IP, UDP, or Mobile IP header or something else?

Editorial:

>    defined in RFC 3012 [RFC3012].  Additionaly, new error codes

s/additionaly/additionally/

>    node has attempted to use.  The following stylized programmatic
>    algorithm accomplishes this objective.  The maximum amount of total

Maybe s/stylized programmatic algorithm/pseudo-code algorithm/

> Appendix A.  Change History

Might be an idea to clean this up to a "What's New vs. RFC3012"
section. Right now its hard to see if all the changes are true
technical changes from 3012, editorial modifications, or just
back-and-forth modifications between draft revisions.

Other editorial issues:

I spent quite a bit of time trying to understand all the "MUST
precede" rules relating to the order of the options (Sect 3, Sect
6, etc). Its still hard to get an overview, and its also hard to
convince yourself that the specification of these rules is
complete and unambiguous. But I don't have a good suggestion
for a better way to describe the rules.

>      Least-order 237 bytes from Challenge
>      ...
>    using MD5.  Finally, the least significant 237 bytes of the challenge

Would "last 237 bytes" be easier to understand?

Submission Questionnaire:

This is a request to advance the draft:

  draft-ietf-mip4-3012bis-04.txt

To Proposed Standard RFC status.

Answers to Questions:

> 1) Have the chairs personally reviewed this version of the ID and do
>    they believe this ID is sufficiently baked to forward to the IESG
>    for publication?

Yes, the draft was reviewed by Pete McCann.

> 2) Has the document had adequate review from both key WG members and
>    key non-WG members? Do you have any concerns about the depth or
>    breadth of the reviews that have been performed?

The key WG members have reviewed the document.  The 3GPP2 PDS working
group was also given an opportunity to review. 

> 3) Do you have concerns that the document needs more review from a
>    particular (broader) perspective (e.g., security, operational
>    complexity, someone familiar with AAA, etc.)?

Additional review by security/AAA experts on the text changes would
also be welcome.

> 4) Do you have any specific concerns/issues with this document that
>    you believe the ADs and/or IESG should be aware of? For example,
>    perhaps you are uncomfortable with certain parts of the document,
>    or whether there really is a need for it, etc., but at the same
>    time these issues have been discussed in the WG and the WG has
>    indicated it wishes to advance the document anyway.

No.

> 5) How solid is the WG consensus behind this document?  Does it
>    represent the strong concurrence of a few individuals, with others
>    being silent, or does the WG as a whole understand and agree with
>    it?

There is unanimous consensus to advance the document.

> 6) Has anyone threatened an appeal or otherwise indicated extreme
>    discontent?  If so, please summarize what are they upset about.

No.

> 7) Have the chairs verified that the document adheres to _all_ of the
>    ID nits?  (see http://www.ietf.org/ID-nits.html).

Yes.


> 8) For Standards Track and BCP documents, the IESG approval
>    announcement includes a writeup section with the following
>    sections:
>
>    - Technical Summary
>    - Working Group Summary
>    - Protocol Quality
>
>    Please provide such a writeup. (We will hopefully use it as is, but
>    may make some changes.) For recent examples, have a look at the
>    "protocol action" announcements for approved documents.
>
>    Note:
>
>    - When doing the technical summary, one would expect that the
>      relevant information is in the abstract and/or introduction of
>      the document. It turns out that the step of producing the writeup
>      sometimes points out deficiencies in the introduction/abstract
>      that are also worthy of rectifying.
>
>    - For the Working Group Summary, was there anything in WG process
>      that is worth noting? (E.g., controversy about particular points,
>      decisions where concensus was particularly rough, etc.)
>
>    - For the protocol quality, useful information could include:
>
>      - is the protocol already being implemented?
>
>      - have a significant number of vendors indicated they plan to
>        implement the spec?
> 
>      - are there any reviewers (during the end stages) that merit
>        explicit mention as having done a thorough review that resulted
>        in important changes or a conclusion that the document was fine
>        (except for maybe some nits?)

Technical Summary

This is a revision to RFC 3012 that clarifies the operation of the
Mobile IPv4 Challenge/Response mechanism in the interest of greater
interoperability.  The specification given in RFC 3012 left some
aspects of challenge handling in the FA unspecified which in some
cases led to unnecessary authentication failure.  In particular, the
requirements for retaining valid, outstanding challenges at the FA
(especially in a mixed environment of multicast/unicast FA
Advertisements) were clarified and mobile requirements tightened
to improve the chances that a given challenge used by a mobile
node in its request would be accepted as valid by the FA. 

The new revision also introduces the use of the FA Error extension to
communicate error conditions from the FA to the MN even when the Code
field of the Registration Reply is used by the HA.

The new revision clarifies the computation of the authenticator when
CHAP_SPI is used and the challenge is shorter than 238 bytes.

The new revision adds new error codes FA_BAD_AAA_AUTH and
HA_BAD_AAA_AUTH to distinguish whether failure occurred at the FA or
the HA.  The new revision adds the error code HA_WRONG_CHALLENGE to
cover the case when the Home Agent includes a different challenge
in the Reply than the one it was sent in the Request.


Working Group Summary

  The document is a product of the mip4 working group.

Protocol Quality

  The document was reviewed for protocol quality by Pete McCann
  (maybe change this after IESG does its own review -pm).