Authentication Protocol for Mobile IPv6
RFC 4285

Note: This ballot was opened for revision 07 and is now closed.

(Thomas Narten) (was Yes) Discuss

Discuss (2005-02-24 for -** No value found for 'p.get_dochistory.rev' **)
Substantive:

>    This document introduces new mobility options to aid in
>    authentication of the Mobile Node to the Home Agent or AAAH server.
>    The confidentiality protection of Return Routability messages and
>    authentication/integrity protection of Mobile Prefix Discovery (MPD)
>    is outside the scope of this document.

what is required to get RR to work in this scenario?

Even if out of scope, this document should make it clear whether there
are  fundamental issues or whether the details simply aren't included
because 3GPP2 has no plans for using RO.

>    New values for this namespace can be allocated using Standards Action
>    [RFC2434].

seems overly restrictive. Especially since _this_ document is
informational and creates one for 3GPP2. Isn't IETF RFC good enough?

> 7.  Security Considerations
> 
>    This document proposes new authentication options to authenticate the
>    control message between Mobile Node, Home Agent and/or home AAA (as
>    an alternative to IPsec).  The new options provide for authentication
>    of Binding Update and Binding Acknowledgement messages.  The MN-AAA
>    authentication options provides for authentication with AAA
>    infrastructure.  It can be used to generate a per session key between
>    Mobile Node and Home Agent for subsequent authentication of BU/BA
>    between Mobile Node and Home Agent via the MN-HA authentication
>    option.

I find it odd that this document doesn't anywhere say how one
generates a session key, if that is indeed what this document is used
for...
Comment (2005-02-24 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
>    responsible for performing Registration of a Mobile Node at a home

s/Registration/registration/? (Why capitalized?)

>    and Accounting (AAA) server in Home network (AAAH) based on a shared
>    key based security association between the Mobile Node and the
>    respective authenticating entity.  This shared key based security
>    association (shared-key based SA) may be statically provisioned or

hyphens in "shared-key-based security"?


>    Mobile Node MAY use Mobile Node Identifier Option as defined in

s/Mobile/A Mobile/ (or The...) 

>    [MN_Ident] or Home Address to identify itself while authenticating

s/Home/the Home/

>    When a Binding Update or Binding Acknowledgement is received without
>    an authentication option and the entity receiving it is configured to
>    use authentication option or has the shared-key based security
>    association for authentication option, the entity should silently
>    discard the received message.

the above is worded weakly. I would assume that the HA needs to be
configured to reqiure authentication, either IPsec or this
method. Above can almost be read to imply that a HA might not use
either.

>       SPI:
> 
>          Security Parameter Index
>

This document doesn't  seem to define SPI precisely. It would be good
to provide a reference to the proper MIP document that describes them
(i.e, what there properties are, who assigns them, etc.)

>       Alignment requirements :
> 
>          The alignment requirement for this option is 4n + 1.

provide a reference to the RFC that defines the alignment rquirements?

>    Home Agent used within this specification consists of a SPI, a key,

s/a SPI/an SPI/

>    16 octets in length.  The authentication algorithm is HMAC_SHA1.  The

Reference for HMAC_SHA1?

>    the mobility header upto and including the SPI value of this option.

s/upto/up to/ (multiple occurances)

>    The Mobility message replay protection option MAY be used in Binding

why not a should?

>    If the timestamp is valid, the Home Agent copies the entire Timestamp
>    field into the Timestamp field in the BA it returns to the Mobile
>    Node.  If the timestamp is not valid, the Home Agent copies only the
>    low-order 32 bits into the BA, and supplies the high-order 32 bits
>    from its own time of day.

This last part seems odd.

>    code MIPV6-ID-MISMATCH.  The Home Agent does not create a binding

seems like you could find a better, more intuitive name. e.g.,
something like MIPV6-TS-INVALID (for timestamp).

>    infrastructure.  It can be used to generate a per session key between

s/per session/per-session/

(Margaret Cullen) No Objection

(David Kessens) No Objection

(Sam Hartman) (was Discuss, No Objection) Abstain

Comment (2005-10-13)
No email
send info
I have significant process and technical concerns with the document.
From a process standpoint, two security reviews were solicited and
provided to the working group when the working group was considering
adopting the draft as a work item.  The security reviews were provided
by Radia Perlman and myself.  The working group never responded to
these comments.  The reviews questioned whether this architecture made
sense and suggested alternatives to consider and questions to answer
before going down the path of adopting this approach.  I believe that
these comments suggest that there may be a conflict in the consensus
of the security area when considering this document with the consensus
of the MIP6 working group.  We should determine what the IETF
consensus is on this document; tools available to help us accomplish
this include an IETF-wide last call or  polling portions of the
security community.  


On a technical level, I'm concerned about this document both because
it is hard to review from a security standpoint and because it will
make future mip6 work significantly harder to review from a security
standpoint.  This document attempts to establish a way of
authenticating MIP6 traffic without the use of IPsec.  The IPsec
solution is fairly well complete: IKE provides for the use of a
variety of credential types to set up security associations; IPsec
provides for confidentiality and authentication of messages.
Assumptions about IPsec and the available services are included
throughout MIP6, particularly in route optimization.  However these
assumptions have not been written down in any formal mip6 security
service model.  So if the mip6 security architecture is going to be
replaced by something other than ipsec it will be challenging to
determine what properties that replacement model needs to provide.  In
addition, future work will need to either duplicate security analysis
both for the non-ipsec model and the ipsec model or to ignore one of
the security models. This protocol only provides part of the services
that IPsec provides., this protocol only provides part of the
non-IPsec solution .  IT authenticates binding updates from the MN to
the HA.  In effect, the document authors are saying that they don't
like IPsec and so they are going to get rid of it and only build the
part that corresponds to AH.  That might be OK for 3GPP; they may have
proprietary parts of the rest of the infrastructure and not need to
invent replacements for the rest of the IPsec dependencies.  However
outside of such an environment this document presents a much weaker
security picture than the existing MIPV6 specifications.  As such it
is my preference that this document not be published as an IETF
specification.  I would rather see the IESG approve the code point and
3GPP2 publish the document as one of their specifications.  (I
recognize this would require an IETF consensus against publication; it
is reasonable for the IESG to see if such a consensus exists but not
to block this document absent such a consensus.)

I would also be happy if we actually do the rest of the work necessary
to replacing IPsec.  At a minimum that would include documenting the
MIP6 security service model so that we can see what MIP6 and future
extensions require out of security.  We would then document how the
IPsec and non-IPsec solution fit this service model.  We'd also need
to finish defining the non-IPsec solution.  This would involve some
sort of confidentiality solution for RO and prefix discovery.  It
would also require some mechanism for getting keys to use for this
mechanism and the confidentiality mechanism.  That mechanism would
need to eventually be able to support a full EAP exchange, although it
might not be required to actually specify EAP support initially.  I
realize this solution requires more time and effort than the MIP6
working group probably wants to spend, but I list it in the interest
of enumerating possible solutions.

If we are going to publish this specification and we are not actually
going to complete the security solution, we need a very strong
applicability statement/IESG note warning.

(Russ Housley) (was Discuss) Abstain

Comment (2005-08-23)
No email
send info
The security review that was conducted early in the devleopment of this
document was largely ignored.  Since this document will be published as an
Informational RFC and the 3GPP2 community is waiting for the document, I
am choosing to ABSTAIN rather than perform the detailed review necessary
to determine which of the concerns raised by in the security review ought
to be addressed.  However, I would really like to see an applicabilty
statement added to this document so that this approach is not used outside
of the 3GPP2 environment without careful consideration.  In other words,
please tell the reader what in the 3GPP2 environment makes this a more
attractive (and secure) alternative to IPsec.

(Allison Mankin) Abstain