Context Transfer Protocol (CXTP)
draft-ietf-seamoby-ctp-11

[Ballot discuss]
Comments from the ops directorate:

This draft does not attempt to answer all the security considerations
relating to context transfer, but nevertheless there appear to be some
pretty big holes.

For example, Section 6.2 talks about using of IKE to dynamically negotiate
keys for protection of Inter-Router traffic.  However, it doesn't say what
IKE modes need to be implemented, or what IPsec ciphersuites are required.

Since context transfer security is an n by n problem, establishing the SAs
to protect inter-router transfers is not an easy thing.  For this reason one
might conclude that pre-shared keys are difficult, since n(n-1) of them
would be necessary.  On the other hand, is it being suggested that each
router needs to be provisioned with a certificate? On reading the draft it
isn't clear what's being recommended (or even considered).

In addition to the security issues described in the draft, there is also a
"correctness" problem that isn't discussed.  The problem is that in a
context transfer it is possible that the context being transferred is not
valid on the new router.  In order to address this, it is necessary for a
context transfer protocol to carefully specify how context is processed on
the next router, and under what conditions the transfer will fail.

some of the issues are laid out in Section 2.5 of draft-ietf-eap-keying:

2.5.2.  Correctness in Fast Handoff

  Bypassing all or portions of the AAA conversation creates challenges
  in ensuring that authorization is properly handled. These include:

[a]  Consistent application of session time limits.  A fast handoff
    should not automatically increase the available session time,
    allowing a user to endlessly extend their network access by
    changing the point of attachment.

[b]  Avoidance of privilege elevation.  A fast handoff should not result
    in a user being granted access to services which they are not
    entitled to.

[c]  Consideration of dynamic state.  In situations in which dynamic
    state is involved in the access decision (day/time, simultaneous
    session limit) it should be possible to take this state into
    account either before or after access is granted. Note that
    consideration of network-wide state such as simultaneous session
    limits can typically only be taken into account by the backend
    authentication server.

[d]  Encoding of restrictions.  Since a authenticator may not be aware
    of the criteria considered by a backend authentication server when
    allowing access, in order to ensure consistent authorization during
    a fast handoff it may be necessary to explicitly encode the
    restrictions within the authorizations provided in the AAA-Token.

[e]  State validity.  The introduction of fast handoff should not render
    the authentication server incapable of keeping track of network-
    wide state.

    A fast handoff mechanism capable of addressing these concerns is
    said to be "correct".  One condition for correctness is as follows:
    For a fast handoff to be "correct" it MUST establish on the new
    device the same context as would have been created had the new
    device completed a AAA conversation with the authentication server.

    A properly designed fast handoff scheme will only succeed if it is
    "correct" in this way.  If a successful fast handoff would
    establish "incorrect" state, it is preferable for it to fail, in
    order to avoid creation of incorrect context.

    Some backend authentication server and authenticator configurations
    are incapable of meeting this definition of "correctness".  For
    example, if the old and new device differ in their capabilities, it
    may be difficult to meet this definition of correctness in a fast
    handoff mechanism that bypasses AAA.  Backend authentication
    servers often perform conditional evaluation, in which the
    authorizations returned in an Access-Accept message are contingent
    on the authenticator or on dynamic state such as the time of day or
    number of simultaneous sessions.  For example, in a heterogeneous
    deployment, the backend authentication server might return
    different authorizations depending on the authenticator making the
    request, in order to make sure that the requested service is
    consistent with the authenticator capabilities.

    If differences between the new and old device would result in the
    backend authentication server sending a different set of messages
    to the new device than were sent to the old device, then if the
    fast handoff mechanism bypasses AAA, then the fast handoff cannot
    be carried out correctly.

    For example, if some authenticator devices within a deployment
    support dynamic VLANs while others do not, then attributes present
    in the Access-Request (such as the authenticator-IP-Address,
    authenticator-Identifier, Vendor-Identifier, etc.) could be
    examined to determine when VLAN attributes will be returned, as
    described in [RFC3580].  VLAN support is defined in [IEEE8021Q].
    If a fast handoff bypassing the backend authentication server were
    to occur between a authenticator supporting dynamic VLANs and
    another authenticator which does not, then a guest user with access
    restricted to a guest VLAN could be given unrestricted access to
    the network.

    Similarly, in a network where access is restricted based on the day
    and time, Service Set Identifier (SSID), Calling-Station-Id or
    other factors, unless the restrictions are encoded within the
    authorizations, or a partial AAA conversation is included, then a
    fast handoff could result in the user bypassing the restrictions.

    In practice, these considerations limit the situations in which
    fast handoff mechanisms bypassing AAA can be expected to be
    successful.  Where the deployed devices implement the same set of
    services, it may be possible to do successful fast handoffs within
    such mechanisms.  However, where the supported services differ
    between devices, the fast handoff may not succeed.  For example,
    [RFC2865], section 1.1 states:

        "A authenticator that does not implement a given service MUST
        NOT implement the RADIUS attributes for that service.  For
        example, a authenticator that is unable to offer ARAP service
        MUST NOT implement the RADIUS attributes for ARAP.  A
        authenticator MUST treat a RADIUS access-accept authorizing an
        unavailable service as an access-reject instead."

    Note that this behavior only applies to attributes that are known,
    but not implemented.  For attributes that are unknown, section of 5
    of [RFC2865] states:

        "A RADIUS server MAY ignore Attributes with an unknown Type.  A
        RADIUS client MAY ignore Attributes with an unknown Type."

    In order to perform a correct fast handoff, if a new device is
    provided with RADIUS context for a known but unavailable service,
    then it MUST process this context the same way it would handle a
    RADIUS Access-Accept requesting an unavailable service.  This MUST
    cause the fast handoff to fail.  However, if a new device is
    provided with RADIUS context that indicates an unknown attribute,
    then this attribute MAY be ignored.

    Although it may seem somewhat counter-intuitive, failure is indeed
    the "correct" result where a known but unsupported service is
    requested. Presumably a correctly configured backend authentication
    server would not request that a device carry out a service that it
    does not implement.  This implies that if the new device were to
    complete a AAA conversation that it would be likely to receive
    different service instructions.  In such a case, failure of the
    fast handoff is the desired result.  This will cause the new device
    to go back to the AAA server in order to receive the appropriate
    service definition.

    In practice, this implies that fast handoff mechanisms which bypass
    AAA are most likely to be successful within a homogeneous device
    deployment within a single administrative domain. For example, it
    would not be advisable to carry out a fast handoff bypassing AAA
    between a authenticator providing confidentiality and another
    authenticator that does not support this service.  The correct
    result of such a fast handoff would be a failure, since if the
    handoff were blindly carried out, then the user would be moved from
    a secure to an insecure channel without permission from the backend
    authentication server.  Thus the definition of a "known but
    unsupported service" MUST encompass requests for unavailable
    security services.  This includes vendor-specific attributes
    related to security, such as those described in [RFC2548].