Authentication Protocol for Mobile IPv6
draft-ietf-mip6-auth-protocol-07

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
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.


I also have some comments about the document.

1) The document still feels a lot more like a standards-track document
than an informational document.  Thomas noticed some problems in
this regard with the IANA considerations.  I noticed the following:

>It does not imply that the availability of
>  such a solution deprecates the use of IPsec for securing Mobile IPv6
>  signaling between Mobile Nodes and Home Agents.  Home agents still
>  have to implement and support registrations from Mobile Nodes that
>  are secured via IPsec as well as with the authentication option.

I propose the following instead:
This document does not change the security requirements for Mobile
IPV6: mobile  nodes and home agents must still implement 
IPsec for security.  Instead this document provides an additional
option for some deployment situations.

2) The document claims that no confidentiality protection for return
    routability/prefix discovery is provided.  It should forbid use of
    options such as route optimization whose secure operation depends
    on these features.


3) The terms "security association" and "SPI" are used inconsistently
  with their IPsec meanings.  They have very specific meanings in
  that context and the re-use of these terms creates unacceptable
  confusion in the mind of security reviewers.  Find terms specific
  to this approach and use them.

4) The description of the AAA authentication option is broken.  The
  security considerations text implies that there is a session key
  that some how falls out of the option to be used by the other
  authentication option.  The actual description of the option does
  not ever produce a session key.  Also, the interaction between the
  AAA option and the normal authentication option is not well
  specified.  It seems you can use both at once; why would you do
  this?


5)  Overloading the SPI to choose the hash function to use in the AAA
    option is not acceptable.  Just add an algorithm identifier to
    that option.

6) Decide what identification behavior is mandatory to implement?  IS
  it identification by IP address or by the identification option?
  If it is the identification option, which sub option is mandatory
  to implement?

[Ballot discuss]
I am confused about this document.  The MIP architecture uses IPsec
to protect traffic between the MN and HA.  It does not require complex
key management.  In fact, a pre-shared secret seems completely fine.  It
seems that using EAP is more complex than the IPsec with a pre-shared
secret.  I am completely missing the motivation for this document.

IANA Comments:
Upon approval of this document the IANA will register AUTH-OPTION-TYPE and
MESG-ID-OPTION-TYPE in the Mobility Options located at the following:

In this draft, the suggested values are 8 and 9.  However, at the time of approval the next available value will be assigned.

IANA will also register values for status codes MIPV6-ID-MISMATCH,
MIPv6-AUTH-FAIL and MIPV6-MESG-ID-REQD.  In this draft, the suggested values are 144 for MIPV6-ID-MISMATCH 145 for MIPV6-MESG-ID-REQD and 146 for
MIPV6-AUTH-FAIL.  Upon approval the IANA will assign the next available numbers, which should be the ones suggested.

The IANA will add a new sub-registry for enumerating algorithms identified by specific SPIs to http://www.iana.org/assignments/mobility-parameters.
(The URL listed in this draft is incorrect.)  The defined values in this document will be used (0, 3, and 5). 

The IANA will create a new namespace for the subtype field of the MN-HA
and MN-AAA authentication mobility options.  This namespace will be located at http://www.iana.org/assignments/mobility-parameters (the URL in this draft is incorrect).  The defined values in this document will be used (1 and 2)

[Ballot discuss]
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.  In contrast, 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.

If this document is going to be published, we need to actually do the
rest of the work necessary to replacing IPsec.  At a minimum that
would include 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. 

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.


I also have some comments about the document.

1) The document still feels a lot more like a standards-track document
than an informational document.  Thomas noticed some problems in
this regard with the IANA considerations.  I noticed the following:

>It does not imply that the availability of
>  such a solution deprecates the use of IPsec for securing Mobile IPv6
>  signaling between Mobile Nodes and Home Agents.  Home agents still
>  have to implement and support registrations from Mobile Nodes that
>  are secured via IPsec as well as with the authentication option.

I propose the following instead:
This document does not change the security requirements for Mobile
IPV6: mobile  nodes and home agents must still implement 
IPsec for security.  Instead this document provides an additional
option for some deployment situations.

2) The document claims that no confidentiality protection for return
    routability/prefix discovery is provided.  It should forbid use of
    options such as route optimization whose secure operation depends
    on these features.


3) The terms "security association" and "SPI" are used inconsistently
  with their IPsec meanings.  They have very specific meanings in
  that context and the re-use of these terms creates unacceptable
  confusion in the mind of security reviewers.  Find terms specific
  to this approach and use them.

4) The description of the AAA authentication option is broken.  The
  security considerations text implies that there is a session key
  that some how falls out of the option to be used by the other
  authentication option.  The actual description of the option does
  not ever produce a session key.  Also, the interaction between the
  AAA option and the normal authentication option is not well
  specified.  It seems you can use both at once; why would you do
  this?


5)  Overloading the SPI to choose the hash function to use in the AAA
    option is not acceptable.  Just add an algorithm identifier to
    that option.

6) Decide what identification behavior is mandatory to implement?  IS
  it identification by IP address or by the identification option?
  If it is the identification option, which sub option is mandatory
  to implement?

[Ballot discuss]
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...

[Ballot comment]
>    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/

[Ballot discuss]
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.

From: Thomas Narten
To: alpesh@cisco.com, kleung@cisco.com, mkhalil@nortelnetworks.com,
    haseebak@nortelnetworks.com, kchowdury@starentnetworks.com
cc: Gopal Dommety , Basavaraj.Patil@nokia.com,
    Sam Hartman ,
    Russ Housley
Date: Tue, 15 Feb 2005 12:16:14 -0500
Subject: AD review of draft-ietf-mip6-auth-protocol-04.txt

Here is my AD review of this document.

2005-02-15: review of 04 (WG says advance)

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

Editorial

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

Thomas