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

From: gabriel montenegro <[email-masked]>
Date: Wed, 21 Sep 2005 00:35:30 -0700 (PDT)

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

...

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

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

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

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

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

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

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

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

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

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

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

...

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

...

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

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

...

> 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

...

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

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

...
> 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: [email-masked]

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.

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