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

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Fri, 4 Nov 2005 15:00:26 -0500

Hi Pete,

Document does have a dual personality, since it partly talks about
challenge response procedures that are only used for FA-based cases, but
partly also covers MN-AAA AE that is generic for MIP-AAA interaction.
For RADIUS-MIP design, We have been running into some problems with the
specification provided in this document, since the Authenticator field
requires knowledge of the challenge

Authenticator = MD5(
High-order byte from Challenge || Key ||
MD5(Preceding Mobile IP data ||
Type, Subtype (if present), Length, SPI) ||
Least-order 237 bytes from Challenge)

Which is not presence in a direct registration through the HA. We did
talk to the authors and decided to use 0 instead of challenge for now.
However, we feel that the RFC3012 needs to add this fix, not RADIUS-MIP
draft. We were planning to bring this to Vancouver for attention. 

Having said all this I don't think I am advocating for a separation. I
can understand the issue with MD5, but not sure that warrants a
separation either. Given that many people depend on this spec, urgency
is appreciated.

Regards,

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Pete McCann
Sent: Friday, November 04, 2005 11:41 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

We didn't get any followup to Gabriel's review here.  How does the group
feel about splitting 3012bis into two documents?

-Pete

gabriel montenegro writes:
 > 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/

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

-- 
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, 4 Nov 2005 15:02:05 -0500

We know that never happens in IETF :) ( :) means sarcasm) 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Charles E. Perkins
Sent: Friday, November 04, 2005 11:52 AM
To: Pete McCann
Cc: [email-masked]; [email-masked]
Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Hello folks,

This document has been essentially ready to go for over a year.

How much longer will it take if we start from scratch with two
documents?

Maybe next year someone will demand that we merge them again.

Regards,
Charlie P.

Pete McCann wrote:

>We didn't get any followup to Gabriel's review here.  How does the 
>group feel about splitting 3012bis into two documents?
>
>-Pete
>
> > 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 
> > - Generalized Authentication Extension
> > 
> > They really should be two documents, specially cuz this is a 
> > revision, the proper opportunity to make such changes.
> > 
> > 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.
> > 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:
"processing of"?
Perkins
Center
Calhoun
Networks
Bharatia
Networks
> > >                                                            June 
> > > 17, 2005
for AUTH48.
> > >    extension.  This new extension is provided so that a mobile
node can
AAA
MAY

> > explicit here precisely because this extension differs in that it is

> > unilateral. It does not aid the MN in establishing legitimacy of the
> > >    packets to and from a mobile node whether or not the mobile
node is
agent.
> > >    Unfortunately, that extension does not provide the foreign
agent any
and
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.

> > (perhaps section 3 itself.
> > 
> > ...
> > > 
> > >    The Challenge extension, illustrated in Figure 1, is inserted
in the
communicate a
> > >    previously unused challenge value that can be used by the
mobile node
provide
earlier
> > >    information on generating pseudo-random numbers suitable for
use as
> > > 2.1  Handling of Solicited Agent Advertisements
> > ...
of the
> > 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
> > > 
registration
> > >    process [RFC3344] which may occur after the foreign agent
issues a
> > 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"
> > 
> > > 
has
MUST
MUST
Error
> > handling Registration Replies.
> > 
> > s/code only in/code in/
> > 
> > ...
Authentication
agent
Request.
> > 
> > s/Request./Request, before forwarding to the Home Agent./
> > 
by a
through
remove
for
consistent.

> > no AAA, so perhaps clarifying text could be added:
> > 
> > latter because its calculation does not include the Challenge
Extension.
then
the
present
that
value
the
value
node
> > Registration Replies. Mixing section contents like this makes things
very confusing.

> > 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.
> > >    applicable authentication from the Registration Request
message, then

> > > 3.3  Foreign Agent Processing for Registration Replies
> > 
> > s/for/of/
> > 
> > ...

> > 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, 
> > > 3.4  Home Agent Processing for the Challenge Extensions
> > ...
> > 
> > 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
> > ...
node in

> > > that
> > 
> > s/in the case where the mobile node/if it/
> > 
Challenge
node
> > >    SHOULD send a Challenge extension containing an unused
challenge in
the
verification.  A
Foreign
Challenge
extension
mobile
value
Advertisement,
containing
extension
value
Advertisement,
containing
Request
previously
STALE_CHALLENGE.
value in
the
Challenge
> > Jari's comments, I believe.
> >  
> > ...
> > 
> > > 4.  Mobile-Foreign Challenge Extension
> > > 
that is
Challenge
indicate the
found in
2).
> > > 5.  Generalized Mobile IP Authentication Extension
> > 
> > This really should be a separate document.
> > 
various
present its
defined;
> > >    purpose of the generalized authentication extension defined 
> > > here to
> > 
> > s/here to/here is to/
> > 
> > ...
> > > 6.  Mobile-AAA Authentication subtype
> > > 
mobile
the
Mobile-AAA
Mobile-
> > 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.
> > 
> > ...
> > 
thus
extensions
with
the
the
the
fields of
these
preceding
hashed
challenge
this
> > >    algorithm includes the high-order byte in the computation
twice, but
padding
> > >    is never used to increase the length of the challenge; the
input data

> > at least do no harm to the MN.
> > 
> > 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.
following
parameter
section 2.1.
the
this
> > referenced is the section in which it is properly explained (which 
> > could be forward referenced from wherever it's mentioned for the 
> > first time).
> > 
> > > 

> > the above.
agent
recently
nodes
value
> > >    authentication data provided by the mobile node will be
computed over
nodes' IP
computing
authenticator
[RFC2138].
secure
possible.

> > link-layer
> > mechanisms) that can help prevent the dictionary attacks. I guess 
> > the latter applies throughout to the other methods as well.
> > 
or
foreign
challenge
attacks, the
when
> > >    Solicitations.  In addition, the foreign agent MUST NOT
allocate new
also

> > only to the FA and infrastructure.
> > 
> > ...
> > > 14.  Normative References
> > > 
Mobile
progress),
> > > Appendix B.  Verification Infrastructure
> > ...
Mobile-AAA
> > explanation of how to use CHALLENGE_WINDOW. This should be in the 
> > body of the document and must not remain in an appendix.
> >

---

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Mon, 7 Nov 2005 09:55:51 -0800

Hi Pete.  Gabriel's assessment is correct, but I don't think document
splitting will gain much technically to increase comprehension.  Most
people can see clearly the two functions and there is a dependency
between them in FA CoA mode.  Keep draft intact, IMHO.

Kent 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Pete McCann
> Sent: Friday, November 04, 2005 9:41 AM
> We didn't get any followup to Gabriel's review here.  How 
> does the group feel about splitting 3012bis into two documents?
> 
> -Pete
> 
>  > 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:
>  > 	
>  > - 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.
>  >
>  > Nit: saw "processing for" in several places. Shouldn't it 
> be "processing of"?
>  >

---

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Mon, 7 Nov 2005 12:00:48 -0800

I meant "moot", not "mute". 

Kent 

> Behalf Of Kent Leung (kleung)
> Sent: Monday, November 07, 2005 11:36 AM
> To: Vijay Devarapalli
> Cc: Pete McCann; [email-masked]; Vijay Devarapallli; 
> [email-masked]
> Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
> 
> OK.  Since this registration exchange is between MN and HA, I 
> expect that MN would generate some random number in Challenge 
> value.  All implementations that I'm aware of do this.
> 
>    "The mechanism used by the mobile node to
>    obtain the Challenge value in this case is outside the 
> scope of this
>    document."
> 
> But the point is mute since there won't be any Challenge 
> value if the new scheme of zero in place of Challenge for 
> authentication is adopted.
> 
> Kent
> 
> 
> > From: Vijay Devarapalli [mailto:[email-masked]]
> > Sent: Monday, November 07, 2005 11:28 AM
> > To: Kent Leung (kleung)
> > Cc: Vijay Devarapallli; Pete McCann; [email-masked]; 
> > [email-masked]
> > Kent Leung (kleung) wrote:
> > > 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?
> > 
> > for e.g. who generates the challenge in co-located mode?
> > 
> > Vijay
> > 
> > > 
> > > 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.
> > >>
> > > 
> > > 
> > 
> 
> --

---

From: "Yoshi Tsuda \(yotsuda\)" <[email-masked]>
Date: Tue, 8 Nov 2005 08:00:02 +0800

Hi Jayshree and Vijay, 

 Glad to know Jayshree has a mind to keep upgrading
 the draft. :)  But, to support challenge mentioned by
 Vijay, we would definitely need some more functions
 than existing and having been tested functions in rfc3012,
 which need to be verified in a future interoperability test.
 So would like to know whether it is better to have a new
 rfc or updating rfc3012.  Personally, I think, it's better to
 have a new rfc.

Thanks.
-Yoshi

> From: Jayshree Bharatia [mailto:[email-masked]] 
> Sent: Monday, November 07, 2005 2:45 PM
> To: Vijay Devarapalli; Yoshi Tsuda (yotsuda)
> Cc: Kent Leung (kleung); [email-masked]; Pete McCann; 
> [email-masked]
> Vijay,
> I agree that having co-located CoA support information in 
> this draft is confusing. We added co-located CoA support at 
> the later time as a result of comments (rather long debate!) 
> we had on the mailing list. At that time, it was decided not 
> to limit the use of this mechanism (use of the MN-AAA 
> extension) given that challenges are generated by some other 
> means and make them available at the MN.
> 
> I am open to any suggestions which may clarify the scope better.
> 
> Regards,
> Jayshree
> 
> Behalf Of Vijay Devarapalli
> Sent: Monday, November 07, 2005 4:07 PM
> To: Yoshi Tsuda (yotsuda)
> Cc: Kent Leung (kleung); [email-masked]; Pete McCann; 
> [email-masked]
> Yoshi Tsuda (yotsuda) wrote:
> > Hi Vijay,
> > 
> >  Even in co-located mode, you know, an FA can push  
> challenge to an MN 
> > by setting R-bit and challenge in  agent advertisements.
> 
> in co-located mode, I am assuming there are networks with no FA.
> 
> >  Do you need pushing challenge from an HA to an MN,  instead ?
> 
> nope.
> 
> If so, Kent has already mentioned one option.
> 
> I dont think the MN itself generating the challenge is a solution.
> 
> >  If you want to push challenge from an HA to an MN really,  say MS 
> > CHAPv2, we want you describe such a scenario  in order to review it.
> 
> I wanted the draft actually to say that the 
> challenge/response mechanism is specified only for FA mode. 
> for co-located mode, it could be out of scope for this draft. 
> the draft currently claims that it supports co-located mode 
> too. I am objecting to that.
> 
> >  At the time when we defined and did interoperability tests  about 
> > rfc3012, we assumed visiting subnets need some  guard by challenge.
> > Pushing challenge really from an HA  to an MN is beyond our 
> > assumptions at that time.  I prefer  a new rfc rather than updating 
> > rfc3012, because in such a  case we would probably need more 
> > functions, such as some  guard against losing challenge on an MN.
> 
> ok.
> 
> Vijay
> 
> > 
> > Thanks.
> > -Yoshi
> > 
> > 
> >>From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> >>Of Vijay Devarapalli

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Mon, 7 Nov 2005 19:45:59 -0500

The fix to deal with CCoA is a very small one as I mentioned my previous
email. I really don't think it warrants a huge discussion or a doc
split. The fix that we suggested was agreed by Charlie as well.

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Kent Leung (kleung)
Sent: Monday, November 07, 2005 11:42 AM
To: Vijay Devarapallli; Pete McCann
Cc: [email-masked]; [email-masked]
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

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

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Mon, 7 Nov 2005 19:46:59 -0500

Nobody, that is why we are saying replace it with 0.
You don't need additional replay protection when you are registering
with HA directly.

Madjid 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Vijay Devarapalli
Sent: Monday, November 07, 2005 1:28 PM
To: Kent Leung (kleung)
Cc: Pete McCann; [email-masked]; Vijay Devarapallli;
[email-masked]
Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Vijay

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Mon, 7 Nov 2005 19:47:57 -0500

Nope, the RRQ with HA is already protected through 3344 mechanisms.
No need for this. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Kent Leung (kleung)
Sent: Monday, November 07, 2005 1:36 PM
To: Vijay Devarapalli
Cc: Pete McCann; [email-masked]; Vijay Devarapallli;
[email-masked]
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

OK.  Since this registration exchange is between MN and HA, I expect
that MN would generate some random number in Challenge value.  All
implementations that I'm aware of do this.

   "The mechanism used by the mobile node to
   obtain the Challenge value in this case is outside the scope of this
   document."

But the point is mute since there won't be any Challenge value if the
new scheme of zero in place of Challenge for authentication is adopted.

Kent

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Mon, 7 Nov 2005 19:49:19 -0500

Folks lets not get creative here. 3012 challenge was created because
only HA and home network was protected but foreign network was not,..

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yoshi Tsuda (yotsuda)
Sent: Monday, November 07, 2005 2:17 PM
To: Vijay Devarapalli; Kent Leung (kleung)
Cc: Pete McCann; [email-masked]; Vijay Devarapallli;
[email-masked]
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Hi Vijay,

 Even in co-located mode, you know, an FA can push  challenge to an MN
by setting R-bit and challenge in  agent advertisements.

 Do you need pushing challenge from an HA to an MN,  instead ?  If so,
Kent has already mentioned one option.
 If you want to push challenge from an HA to an MN really,  say MS
CHAPv2, we want you describe such a scenario  in order to review it.
 At the time when we defined and did interoperability tests  about
rfc3012, we assumed visiting subnets need some  guard by challenge.
Pushing challenge really from an HA  to an MN is beyond our assumptions
at that time.  I prefer  a new rfc rather than updating rfc3012, because
in such a  case we would probably need more functions, such as some
guard against losing challenge on an MN.

Thanks.
-Yoshi

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Vijay Devarapalli

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Mon, 7 Nov 2005 19:54:47 -0500

I am not sure splitting an RFC merely because it covers two related
topics warrants 2 more years of delay. BTW, I am guessing people who are
suggesting a new RFC are volunteering editorship out of their own time
budget for the next 2 years, is this true??

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yoshi Tsuda (yotsuda)
Sent: Monday, November 07, 2005 6:00 PM
To: Jayshree Bharatia; Vijay Devarapalli
Cc: Kent Leung (kleung); [email-masked]; Pete McCann;
[email-masked]
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Hi Jayshree and Vijay, 

 Glad to know Jayshree has a mind to keep upgrading  the draft. :)  But,
to support challenge mentioned by  Vijay, we would definitely need some
more functions  than existing and having been tested functions in
rfc3012,  which need to be verified in a future interoperability test.
 So would like to know whether it is better to have a new  rfc or
updating rfc3012.  Personally, I think, it's better to  have a new rfc.

Thanks.
-Yoshi

> I agree that having co-located CoA support information in this draft 
> is confusing. We added co-located CoA support at the later time as a 
> result of comments (rather long debate!) we had on the mailing list. 
> At that time, it was decided not to limit the use of this mechanism 
> (use of the MN-AAA
> extension) given that challenges are generated by some other means and

> make them available at the MN.
> 
> I wanted the draft actually to say that the challenge/response 
> mechanism is specified only for FA mode.
> the draft currently claims that it supports co-located mode too. I am 
> objecting to that.
>

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Mon, 7 Nov 2005 20:03:53 -0500

Thanks Vijay for the flattering comments on the RADIUS-MIP draft.
RADIUS-MIP has a long bumpy road ahead and it really intends to explain
the RADIUS sides of things, rather than the Mobile IP side. Calculation
MN-AAA AE for two MIPv4 modes is really the job of MIP WGs not RADEXT.
We solved the problem just because it was offered nowhere else and after
we did it, we thought this is really a small fix to RFC3012bis and
should go into that doc so that MIPv4 would have a clean set of
specifications. I am just suggesting to do this in the interest of
expediency.

A lot of SDOs depend on these specs (3GPP2 and WiMAX are two examples),
delaying 3012bis would do a big disservice to these SDOs.

Madjid 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Vijay Devarapalli
Sent: Monday, November 07, 2005 6:12 PM
To: Jayshree Bharatia
Cc: Kent Leung (kleung); [email-masked]; Yoshi Tsuda (yotsuda); Pete
McCann; [email-masked]
Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Jayshree Bharatia wrote:
> (use of the MN-AAA extension) given that challenges are generated by 
> some other means and make them available at the MN.
> 

IMHO, this what we should do

- clarify that 3012bis only addresses using the FA
   challenge/response extension in FA CoA mode.
   co-located CoA mode is not supported.

- mention that the MN-AAA extension can be used in
   co-located CoA mode, but the actual details are
   out of scope for 3012bis.

RFC 3957 also does a poor job of describing the co-located CoA mode.

the RADIUS MIPv4 extensions draft,
draft-nakhjiri-radius-mip4-02.txt, does a better job of describing how
the MN-AAA extension can be used between the MN and the HA along with
RFC 3957. IMO, thats the best reference today.

I think draft-nakhjiri is also the wrong place for this. it should be in
a separate draft.

my 2 cents.

Vijay

> challenge/response mechanism is specified only for
> FA mode. for co-located mode, it could be out of
> scope for this draft. the draft currently claims
> that it supports co-located mode too. I am objecting
> to that.
> 
>

---

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Mon, 7 Nov 2005 18:40:00 -0800

I agree with this sentiment.  Unless there's an issue with using zero
for Challenge value in the calculation for CCoA mode, this problem will
be addressed in the draft.  The challenge is not needed for CCoA mode
since there's already Timestamp/Nonce replay protection.

Kent 

> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]] 
> Sent: Monday, November 07, 2005 4:46 PM
> To: Kent Leung (kleung); Vijay Devarapallli; Pete McCann
> The fix to deal with CCoA is a very small one as I mentioned 
> my previous email. I really don't think it warrants a huge 
> discussion or a doc split. The fix that we suggested was 
> agreed by Charlie as well.
> 
> Madjid
>  
> 
> 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
> 
> 
> >

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 8 Nov 2005 04:40:19 -0600

All,

I was under the impression that using MN-AAA (in CCoA)is for
authenticating RRQ which is needed when HA needs to authenticate MN
through AAA infrastructure, same way as the FA. Although, RRQ could be
protected using MN-HA Auth extension but I remember the discussion was
that there could be an RRQ with one authorization enabling extension or
HA does not locally maintain a security association with the MN and it
uses AAA for authenticating the MN. Also, HA could get an RRQ with a
MN-AAA extension only, as I remember.
 
In this case, HA needs to use the same mechanism introduced by this
draft to authenticate the MN via AAA.
This is has nothing to do with the replay protection which is done via
the RRQ ID (time stamp/nonce).

I think, there was a long debate why to leave the MN to generate its own
challenge. Well, since the HA is not using this challenge for replay
protection but for authenticating the MN, then there is no harm by
allowing the MN to generate its own challenge.

I disagree with the suggestion of allowing the MN to use a value of zero
for the challenge in this case. This will generate a very weak
authenticator.

My 2 cents.

Regards,
Ahmad

> Sent: Monday, November 07, 2005 8:40 PM
> To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapallli; Pete McCann
> I agree with this sentiment.  Unless there's an issue with 
> using zero for Challenge value in the calculation for CCoA 
> mode, this problem will be addressed in the draft.  The 
> challenge is not needed for CCoA mode since there's already 
> Timestamp/Nonce replay protection.
> 
> Kent 
> 
> http://www.ietf.org/html.charters/mip4-> charter.html
> >

---

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Tue, 8 Nov 2005 03:40:58 -0800

Hi Ahmad.

> authenticating RRQ which is needed when HA needs to 
> authenticate MN through AAA infrastructure, same way as the 
> FA. Although, RRQ could be protected using MN-HA Auth 
> extension but I remember the discussion was that there could 
> be an RRQ with one authorization enabling extension or HA 
> does not locally maintain a security association with the MN 
> and it uses AAA for authenticating the MN. Also, HA could get 
> an RRQ with a MN-AAA extension only, as I remember.
>  

Right, MN-AAA Authentication Extension is used by AAA server to
authenticate MN (and in effect, authenticate the RRQ).  FA and HA is the
NAS (i.e. AAA client).

> In this case, HA needs to use the same mechanism introduced 
> by this draft to authenticate the MN via AAA.

HA needs to map fields in the RRQ to RADIUS attributes.

> This is has nothing to do with the replay protection which is 
> done via the RRQ ID (time stamp/nonce).
> 

The challenge value is used for replay protect between MN and FA because
there wasn't any before RFC 3012.  The ID field is for replay protection
between MN and HA.

> I think, there was a long debate why to leave the MN to 
> generate its own challenge. Well, since the HA is not using 
> this challenge for replay protection but for authenticating 
> the MN, then there is no harm by allowing the MN to generate 
> its own challenge.
> 

There's no harm, but also no technical value.  By having adding the
MN-FA Challenge Ext, it was easy for HA to map the RRQ fields/exts to
RADIUS attributes and follow the authentication algorithm in RFC 3012.
But I don't see this is necessary if we specify that MN does not add the
MFCE in RRQ sent directly to HA, and HA sets challenge to zero when MFCE
is not in RRQ.

> I disagree with the suggestion of allowing the MN to use a 
> value of zero for the challenge in this case. This will 
> generate a very weak authenticator.
> 

How does this make a very weak authenticator?

Kent

---

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Tue, 8 Nov 2005 04:02:51 -0800

Hi Yoshi.  You raised a good point about the R-bit.

I would categorize the two types of registrations:

1) Direct registration.

This is when MN sends a RRQ directly to the HA.  It is only for CCoA
mode.  I don't think MFCE is needed to be appended in the message and
authentication algorithm can have challenge value set to zero.

2) Relayed registration.

FA relays RRQ from MN to the HA.  This is for both FA CoA mode and CCoA
mode (R-bit advertised).  Since the challenge is replay protection for
the leg between MN and FA of the registration, MFCE must always be
included in the RRQ and authentication algorithm follows RFC 3012.

Kent 

> From: Yoshi Tsuda (yotsuda) 
> Sent: Monday, November 07, 2005 12:17 PM
>  Even in co-located mode, you know, an FA can push  challenge 
> to an MN by setting R-bit and challenge in  agent advertisements.
> 
>  Do you need pushing challenge from an HA to an MN,  instead 
> ?  If so, Kent has already mentioned one option.
>  If you want to push challenge from an HA to an MN really,  
> say MS CHAPv2, we want you describe such a scenario  in order 
> to review it.
>  At the time when we defined and did interoperability tests  
> about rfc3012, we assumed visiting subnets need some  guard 
> by challenge.  Pushing challenge really from an HA  to an MN 
> is beyond our assumptions at that time.  I prefer  a new rfc 
> rather than updating rfc3012, because in such a  case we 
> would probably need more functions, such as some  guard 
> against losing challenge on an MN.
> 
> Thanks.
> -Yoshi
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 8 Nov 2005 07:29:53 -0600

Hi Kent,

Comments inline.

Regards,
Ahmad

> MFCE in RRQ sent directly to HA, and HA sets challenge to 

[Ahmad]
Makes sense. I agree to make it optional and in case not present, the
assumption is 0.
> How does this make a very weak authenticator?

[Ahmad]
You are right. 
I take it back, my mind went blank for a second and thought that the
challenge is not available for an attacker.

---

From: "Yoshi Tsuda \(yotsuda\)" <[email-masked]>
Date: Wed, 9 Nov 2005 01:00:37 +0800

Hi Kent,

 Thank you for your qualification.  Based on the policy of
 foreign subnets,  some subnets can request MNs to include
 MFCE even in case of CCoA mode.  For those subnets,
 they can filter away (1).  They can only relay (2) to an HA in
 case there is MFCE.  From my memory, this scinario was
 confirmed in the interoperability test at Sun couple years ago.

 Thanks.
-Yoshi

> From: Kent Leung (kleung) 
> Sent: Tuesday, November 08, 2005 4:03 AM
> To: Yoshi Tsuda (yotsuda); 'Vijay Devarapalli'
> Cc: 'Pete McCann'; [email-masked]'; 'Vijay Devarapallli'; 
> [email-masked]'
> This is when MN sends a RRQ directly to the HA.  It is only 
> for CCoA mode.  I don't think MFCE is needed to be appended 
> in the message and authentication algorithm can have 
> challenge value set to zero.
> 
> 2) Relayed registration.
> 
> FA relays RRQ from MN to the HA.  This is for both FA CoA 
> mode and CCoA mode (R-bit advertised).  Since the challenge 
> is replay protection for the leg between MN and FA of the 
> registration, MFCE must always be included in the RRQ and 
> authentication algorithm follows RFC 3012.
> 
> Kent 
>

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Tue, 8 Nov 2005 13:28:49 -0500

Lets ponder what challenge mean? And what does it mean if MN generates a
challenge that was meant to challenge the MN itself? 

Even if we allow that, what is the checking mechanism for the challenge,
the MN may generate a challenge once and use it for 3 years to come. 

We don't want to burden the AAA with checking the freshness of the
challenge, because that just create too much work for AAA. 
The current MIP specs don't have a method for checking the freshness of
a challenge created by the mobile. So in the absence of a robust
freshness check infrastructure, a challenge that is used 10 times adds
no more value than a zero, so either fix the freshness check across the
entire MIP infrastructure, or make the hash stronger, until I see a well
thought and complete solutions, I am not convinced we have a better
option..

-----Original Message-----
From: Ahmad Muhanna [mailto:[email-masked]] 
Sent: Tuesday, November 08, 2005 4:40 AM
To: Kent Leung (kleung); Nakhjiri Madjid-MNAKHJI1; Vijay Devarapallli;
Pete McCann

All,

My 2 cents.

Regards,
Ahmad

> Of Kent Leung (kleung)
> for Challenge value in the calculation for CCoA mode, this problem 
> will be addressed in the draft.  The challenge is not needed for CCoA 
> mode since there's already Timestamp/Nonce replay protection.
> 
> Kent
> 
> > The fix to deal with CCoA is a very small one as I mentioned my 
> > previous email. I really don't think it warrants a huge discussion 
> > or a doc split. The fix that we suggested was agreed by Charlie as 
> > well.
> > 
> > Madjid
> >  
> > 

> > Of Kent Leung (kleung)
> > authentication with NAS in between, I would like to see both FA 
> > (CoA) and HA (CCoA) modes supported.

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Tue, 8 Nov 2005 14:38:15 -0500

I completely agree with Kent, there is no need for additional replay
protection with HA, so I agree with Jayshree on moving on.

Thanks,

Madjid

-----Original Message-----
From: Jayshree Bharatia [mailto:[email-masked]] 
Sent: Tuesday, November 08, 2005 10:56 AM
To: Kent Leung (kleung); Nakhjiri Madjid-MNAKHJI1; Vijay Devarapallli;
Pete McCann

I am also ok with this suggestion. If it is agreed by all, I can change
section 3.1 to reflect this change.

Regards,
Jayshree

-----Original Message-----

Kent 

> previous email. I really don't think it warrants a huge discussion or 
> a doc split. The fix that we suggested was agreed by Charlie as well.
> 
> Madjid
>  
> 
> and HA (CCoA) modes supported.

---

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Fri, 25 Nov 2005 11:16:38 -0800

I don't think it's necessary to say replay protection of messages
between MN and HA is provided by timestamp or nonce as specified in RFC
3344.  This function is already explicitly stated in the base protocol.

Kent

> From: Vijay Devarapallli [mailto:[email-masked]] 
> Sent: Wednesday, November 23, 2005 2:30 PM
> To: Jayshree Bharatia
> Cc: Henrik Levkowetz; Kent Leung (kleung); Nakhjiri 
> Madjid-MNAKHJI1; Pete McCann; [email-masked]; [email-masked]
> On 11/23/05, Jayshree Bharatia <[email-masked]> wrote:
> > Vijay,
> >
> > My understanding of the proposal is that challenge value 0 will be 
> > used for the calculation for co-located CoA mode. Hence, 
> there won't 
> > be challenge extension included in the registration request.
> 
> agree.
> 
> > I haven't
> > included your suggestion on using timestamp for replay protection.
> 
> it wasnt mine. Kent?
> 
> Vijay
> 
> > Please propose new text for this change and I will include 
> it in the 
> > document.
> 
> 
> 
> >
> > Regards,
> > Jayshree
> > From: Vijay Devarapallli [mailto:[email-masked]]
> > Sent: Tuesday, November 22, 2005 8:42 PM
> > To: Henrik Levkowetz
> > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; Kent Leung (kleung); 
> > Nakhjiri Madjid-MNAKHJI1; Pete McCann; [email-masked]; 
> > [email-masked]
> > On 11/22/05, Henrik Levkowetz <[email-masked]> wrote:
> > > Hi Jayshree,
> > >
> > > I believe we've reached consensus on this.  The AD is 
> waiting for an 
> > > updated document, so please make the change and submit a 
> new version.
> >
> > just to make sure I understand what the consensus is.
> >
> > when Kent and I discussed this, we agreed that the MN 
> leaves out the 
> > challenge extension in the registration request when using 
> co-located 
> > CoA mode rather than include a null challenge.
> >
> > is this the consensus?
> >
> > I think we also need some text which explains that replay 
> protection 
> > is provided by the use of timestamp in the registration request 
> > instead of a challenge when the mobile node is using 
> co-located CoA mode.
> >
> > Vijay
> >
> > >
> > > Regards,
> > >
> > >         Henrik
> > >
> > > on 2005-11-08 17:55 Jayshree Bharatia said the following:
> > > > I am also ok with this suggestion. If it is agreed by 
> all, I can 
> > > > change section 3.1 to reflect this change.
> > > >
> > > > Regards,
> > > > Jayshree
> > > >
> > > > Behalf
> > > > I agree with this sentiment.  Unless there's an issue 
> with using 
> > > > zero for Challenge value in the calculation for CCoA mode, this 
> > > > problem will be addressed in the draft.  The challenge is not 
> > > > needed
> >
> > > > for CCoA mode since there's already Timestamp/Nonce replay 
> > > > protection.
> > > >
> > > > Kent
> > > >
> > > >> previous email. I really don't think it warrants a huge 
> > > >> discussion or a doc split. The fix that we suggested 
> was agreed 
> > > >> by Charlie as well.
> > > >>
> > > >> Madjid
> > > >>
> > > >>
> missing in 
> > > >> (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
> > > >>
> > > >>
> > > >> >
> > > >> > IMO, it should be clarified that only FA mode is 
> described in 
> > > >> > the
> >
> > > >> > draft.
> > > >> >
> > > >>
> > > >> --

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Mon, 28 Nov 2005 11:15:16 -0500

I agree. I don't remember anybody discussing the need for this type of
addition. 

-----Original Message-----
From: Kent Leung (kleung) [mailto:[email-masked]] 
Sent: Friday, November 25, 2005 1:17 PM
To: Vijay Devarapallli; Jayshree Bharatia
Cc: Henrik Levkowetz; Nakhjiri Madjid-MNAKHJI1; Pete McCann;
[email-masked]; [email-masked]
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Kent

> Cc: Henrik Levkowetz; Kent Leung (kleung); Nakhjiri Madjid-MNAKHJI1; 
> Pete McCann; [email-masked]; [email-masked]