[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Draft                                   Dan Harkins
draft-hoffman-sla-00.txt                         Derrell Piper
December 17, 2002                                Paul Hoffman
Expires in six months


               Secure Legacy Authentication (SLA) for IKEv2

Status of this memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.


Abstract

SLA is a new IKEv2 exchange that reuses most of the features of the
IKEv2 Initial (Phase 1) exchange but allows for legacy authentication
that is not susceptible to man-in-the-middle attacks. It has a flexible
number of messages based on the type of authentication being used, and
is extensible for new authentication mechanisms. SLA will work with
remote access configuration in the same way as IKEv2's Initial exchange.

Introduction

This document is *not* meant to become an RFC. Instead, if the IPsec
WG agrees, it should be part of the IKEv2 RFC. The next version of this
draft can be specified as changes to the IKEv2 document.

It is possible that the format of the tag-length-value attributes will
change to match those that are currently in XAUTH. If that happens,
all of the usage examples from XAUTH can bin incorporated. This would
increase code-reuse for folks who already have done XAUTH.

1. Exchange overview

Re-use of IKEv2 code is an important goal for SLA. SLA's messages are
very similar to those in IKEv2's Initial exchange. The resulting key
material is derived in the same fashion as IKEv2, and SLA uses the same
denial-of-service protection as IKEv2's Initial exchange. Because SLA
has a different exchange number than IKEv2's Initial exchange, there is
no ambiguity for either party about whether or not legacy authentication
will be used.

The SLA protocol is based on earlier proposals for secure legacy
authentication such as Hybrid and CRACK. In SLA, the authentication of
each side happens very differently. The responder (who is usually a
security gateway) authenticates itself to the initiator first using
standard IKEv2 authentication methods. After that, the initiator (who is
usually a remote access client) authenticates itself to the responder
using a legacy authentication mechanism such as username-password,
SecurID token, and so on.

In this description, "message N" is the last message in the exchange.
Because the number of messages is variable, there is no specified number
for the message.

A quick summary of the exchange is:

- Message 1 is the same as the IKEv2 message 1.

- Message 2 is the same as the IKEv2 message 2 except that it includes
the responder's authentication payload. This allows the remote access
client to authenticate the responder before engaging in sensitive legacy
authentication.

- Message 3 is the same as the IKEv2 message 3 except that the
identification payload and the authentication payload are replaced by
the first challenge/response payload, which identifies the initiator and
the legacy authentication mechanism being used.

- Messages 4 through N-1 consist of the legacy authentication steps.
Each message consists of a single challenge/response payload.

- The last message, N, always comes from the responder, and it includes
a challenge/response payload that states that the authentication is
complete. It also contains the SAr2, TSi, and TSr payloads from IKEv2
message 4.


2. Exchange details

All information not defined here is assumed to be the same as for the
IKEv2 Initial exchange. Messages 1 and 2 are:

       Initiator                          Responder
      -----------                        -----------
       HDR, SAi1, KEi, Ni        -->

                                 <--    HDR, SAr1, KEr, Nr, AUTH

The responder's AUTH payload is computed over all of message 1
concatenated with all of message 2. Because the contents of the AUTH
payload cannot be known when creating the concatenation, a dummy AUTH
payload is constructed which consists of the payload header that would
have been used (including a correct length field), but with each octet
of the contents set to 0x00.

The client MUST both verify the signature as being valid for the
gateway's public key as well as verify that the signed exchange matches
the actual data sent by the client in the first message.

Message 3 is:

       HDR*, CHRE,
             SAi2, TSi, TSr  -->

Message 4 through message N-1 have the format:

                     HDR*, CHRE

This is the challenge/response message described in section 3. The
contents of the CHRE payloads is specific to the legacy authentication
method chosen.

Message N is the last message, and MUST come from the responder. If the
responder successfully authenticates the initiator, message N is:

                                   <--    HDR*, CHRE,
                                                SAr2, TSi, TSr

If the responder does not successfully authenticate the initiator,
message N is:

                                   <--    HDR*, CHRE

In either case, the CHRE in message N MUST contain the SLA_T_FIN
attribute to tell the initiator whether or not the authentication
succeeded.


2.1 Error codes

Errors are indicated with IKEv2 Notify exchanges. They are:

REFUSE-TO-DO-SLA
        Responder unwilling to do SLA (after message 1)

REFUSE-TO-GO-FORWARD
        Initiator (after message 2) cannot or does not want to continue
        the exchange. This may be due to the initiator not being able to
        validate the signature on the AUTH in message 2, the initiator
        not liking SAr1 or KEr, and so on.



3. The Challenge/Response Payload (CHRE)

The Challenge/Response payload is used to convey a challenge from the
responder to the initiator and is used by the initiator to respond to a
challenge from the responder.  The Challenge/Response payload contains
attributes denoting specific information conveyed from the initiator to
the responder and back.  The actual legacy authentication method will
determine the contents of this payload at the various points in the
exchange.

This payload consists of the IKEv2 generic header and a payload-specific
body whose length is not fixed. The body consists of one or more
attributes, described below.  The "Payload Length" in the generic header
includes the length of the header itself.  All fields labeled "RESERVED"
MUST be filled with zero (0) prior to sending and each party to the
exchange MUST verify that value on all payloads it is sent.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !   RESERVED    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!           LAM Type            !           RESERVED            !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                     one or more attributes                    ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The payload type for this payload is [[ TBA ]].

The LAM Type field denotes the legacy authentication method associated
with the exchange.  The LAM Type must be set in all CHRE payloads in an
exchange.  The LAM Type is selected by the initiator and MUST be set in
every CHRE payload to the same value throughout the exchange.

3.1 LAM Types

Different legacy authentication methods are denoted by unique LAM
type identifiers in the Challenge/Response payloads.

If the responder is not configured to support the requested LAM type
while processing the initiator's first CHRE payload, the responder MUST
terminate the exchange and MUST respond with an IKEv2 Notify
of type NO-PROPOSAL-CHOSEN.

A conformant responder MUST support at least one of the specified LAM
Types.  A responder MAY support more than one LAM Type and it's assumed
that the choice of which LAM Types are supported is
implementation-specific and determined from local policy configuration,
perhaps on a per-user basis based on the content of the first CHRE
payload and its associated attributes.

The legacy authentication methods are:

LAM Type Identifier       Value
-------------------       -----------
RESERVED                  0
SLA_PASSWORD              1
SLA_OTP                   2
SLA_CHALLENGE_RESPONSE    3
SLA_SECURID               4
<unassigned>              5-32767
<private use>             32768-65535

This table will be maintained by IANA. Additional LAM types MAY be
defined. Such definitions MUST be in standards-track RFCs and registered
with IANA.

SLA_PASSWORD
        A simple username/password mechanism.  It is used for any simple
        host-based password or one-way hash mechanism. It also useful for
        proxy-based password authentication schemes.

SLA_OTP
        A one-time password mechanism.  It is useful for the S/KEY [Hal95]
        and OTP [HM96] schemes.

SLA_CHALLENGE_RESPONSE
        A token-based challenge/response mechanism.  It's useful for a wide
        variety of cryptographic tokens, typically based on DES.

SLA_SECURID
        A SecurID-like mechanism.  It's useful for the RSA SecurID system.
        The SLA_SECURID closely resembles SLA_CHALLENGE_RESPONSE.

3.2 LAM Attributes

The Challenge/Response payload contains attributes used to convey
information between the initiator and the responder authenticating the
initiator. Attributes have the structure:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!         Attribute Tag         !        Attribute Length       !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                       Attribute content                       ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The attribute length is specified in octets.

Attribute name     Attribute tag
--------------     -------------
RESERVED           0
SLA_T_USERNAME     1
SLA_T_SECRET       2
SLA_T_DOMAIN       3
SLA_T_PIN          4
SLA_T_CHALLENGE    5
SLA_T_MESSAGE      6
SLA_T_FIN          7

This table will be maintained by IANA. Additional LAM attributes MAY be
defined. Such definitions MUST be in standards-track RFCs and registered
with IANA.

SLA_T_USERNAME
        The initiator user identity that's requesting authentication.  The
        syntax and format of SLA_T_USERNAME is specific to each LAM type.

SLA_T_SECRET
        Secret information the initiator sends in an attempt to
        authenticate, for instance a password or passcode. The syntax and
        format of SLA_T_SECRET is specific to each LAM type.

SLA_T_DOMAIN
        The domain or realm the initiator is requesting authentication
        credentials within.  The syntax and format of SLA_T_DOMAIN is
        specific to each LAM type.

SLA_T_PIN
        The initiator's PIN.  The syntax and format of SLA_PIN is specific
        to each LAM type.

SLA_T_CHALLENGE
        Any challenge the responder may choose to issue to the initiator.
        The syntax and format of SLA_T_CHALLENGE is specific to each LAM
        type.

SLA_T_MESSAGE
        An ASCII string to be displayed to the user upon receipt of the
        corresponding CHRE payload.  SLA_T_MESSAGE is valid for all LAM
        types.  Upon receipt, the contents of SLA_T_MESSAGES SHOULD be
        displayed to the initiator user, typically along with the CHRE
        challenge.

SLA_T_FIN
        The responder's response to the authentication exchange at all
        critical decision points specific to each LAM type. The following
        table defines the values for SLA_T_FIN:

        Finish Types       Value
        ------------       -----
        RESERVED           0
        SLA_FIN_SUCCESS    1
        SLA_FIN_MORE       2

        SLA_FIN_SUCCESS indicates the responder has successfully
        authenticated the initiator.  This value successfully terminates the
        SLA exchange.  This value is legal for all LAM types.

        SLA_FIN_MORE indicates the responder requires an additional round-
        trip to authentication the initiator.  This is only legal for LAM
        types which define its use.  It MUST NOT be used unless defined in
        the corresponding LAM profile.


4. Legacy Authentication Method (LAM) Profiles

Each defined LAM type uses the CHRE payload and LAM attributes in a
different manner.  This section profiles the acceptable use of each
for the defined LAM types and details the list of acceptable
attributes for each profile.

In the profiles, the CHRE payloads are numbered. Thus, CHRE1 is
the CHRE payload in message 3 of the SLA exchange, CHRE2 is the
CHRE payload in message 4, and so on.

4.1 LAM Profiles: Password

The Password profile supports legacy operating system (OS)
authentication along with proxy-based password authentication protocols.

The password exchange consists of exactly two CHRE payloads:

- The CHRE1 payload contains the initiator's username as a
SLA_T_USERNAME attribute and a password as a SLA_T_SECRET attribute. The
format of the initiator password is dictated by the corresponding host
OS or proxy authentication server and may be either plaintext or binary.

- The CHRE2 payload contains a SLA_T_FIN attribute with the value of
SLA_FIN_SUCCESS.

The following attributes are defined for Password:

SLA_T_USERNAME      (initiator -> responder, required)

        SLA_T_USERNAME is sent in the initiator's first CHRE payload and
        MUST contain the initiator's username which is used as an index key
        by the host OS or proxy password authentication server.

SLA_T_SECRET    (initiator -> responder, required)

        SLA_T_SECRET is sent in the initiator's first CHRE payload and MUST
        contain the initiator's password.

SLA_T_DOMAIN        (initiator -> responder, optional)

        SLA_T_DOMAIN is sent in the initiator's second message and MAY be
        used to specify the authentication domain that the initiator is
        requesting authentication within.

SLA_T_FIN           (responder -> initiator, required)

        SLA_T_FIN is used to successfully terminate the exchange.

4.2 LAM Profiles: One-Time Password

The OTP profile supports both the S/KEY and OTP one-time password
schemes.

The OTP exchange consists of exactly four CHRE payloads.

- The CHRE1 payload contains only any associated attributes such as a
username.

- The CHRE2 payload contains the OTP server's challenge text which MUST
be displayed to the initiator user.

- The CHRE3 payload contains the initiator's one-time password response.

- The CHRE4 payload contains a SLA_T_FIN attribute with the value of
SLA_FIN_SUCCESS.

The following attributes are defined for OTP:

SLA_T_USERNAME      (initiator -> responder, required)

        SLA_T_USERNAME is sent in the initiator's first CHRE payload and
        MUST contain the initiator's username which is used as an index key
        by the OTP server.

SLA_T_CHALLENGE (responder -> initiator, required)

        SLA_T_CHALLENGE is sent in the responder's first CHRE payload and
        MUST contain the OTP challenge to be issued to the initiator.

SLA_T_SECRET    (initiator -> responder, required)

        SLA_T_SECRET is sent in the initiator's second CHRE payload and
        contains the initiator's one-time password.

SLA_T_MESSAGE       (responder -> initiator, optional)

        SLA_T_MESSAGE is optionally sent in any responder message and MAY by
        used by the responder to provide optional text to be displayed to
        the user along with any associated challenge text.

SLA_T_FIN           (responder -> initiator, required)

        SLA_T_FIN is used to successfully terminate the exchange.

4.3 LAM Profiles: Challenge/Response

The Challenge/Response profile supports various token cards that follow
a standard challenge/response exchange.  The initiator's token card
information (the response) depends on the responder's request (the
challenge).

The Challenge/Response profile consists of at least two CHRE payloads.
If more challenges are required to authenticate this initiator, the
CHRE2 payload contain a challenge to the initiator. The initiator would
respond with CHRE3, and the responder with CHRE4. This can be repeated
until the responder authenticates the initiator (or authentication
fails, see below).

When the initiator is using a token that can compute the next expected
response without requiring a challenge, the CHRE1 payload contains the
initiator's username and expected response.  When the initiator does not
have an expected response, or has chosen not to use the current one for
whatever reason, the CHRE1 payload contains only the initiator's
username.

The CHRE2 payload contains the responder's challenge text which MUST be
displayed to the initiator user unless the initiator has presented an
expected response (as above) in which case this is identical to CHRE4
below.

The CHRE3 payload, when used, contains the initiator's response to the
responder challenge.

The CHRE4 payload contains a SLA_T_FIN attribute with the value of
SLA_FIN_SUCCESS, or another challenge.

The following attributes are defined for Challenge/Response:

SLA_T_USERNAME      (initiator -> responder, required)

        SLA_T_USERNAME is sent in the initiator's second message and MUST
        contain the initiator's username which is used as an index key for
        authentication by the responder.

SLA_T_SECRET    (initiator -> responder, required)

        SLA_T_SECRET contains the initiator's response and is sent in the
        initiator's second message if an anticipated challenge is used, and
        in the initiator's third message if the initiator is responding to a
        responder challenge.

SLA_T_PIN           (initiator -> responder, optional)

        SLA_PIN is optionally sent in any initiator message and MAY by used
        if the authentication protocol also requires the initiator to
        provide a PIN.

SLA_T_MESSAGE       (responder -> initiator, optional)

        SLA_MESSAGE is optionally sent in any responder message and MAY by
        used by the responder to provide optional text to be displayed to
        the user along with any associated challenge text.

SLA_T_FIN           (responder -> initiator, required)

        SLA_T_FIN is used to successfully terminate the exchange.

4.4 LAM Profiles: SecurID

The SecurID profile supports the RSA SecurID protocol.  With SecurID the
initiator will be passing the output of the SecurID card as the body of
the CHRE1 payload and its identity as an associated SLA_T_USERNAME
attribute.  Assuming the initiator and responder are in sync (that is,
they are not in "Next Code" mode), the authentication completes with the
CHRE2 payload.

For simple SecurID, the CHRE payloads are used as follows:

- The CHRE1 payload contains the initiator's username and the current
Passcode displayed by the initiator's SecurID token.

- The CHRE2 payload contains a SLA_T_FIN attribute with the value of
SLA_FIN_SUCCESS.

When the initiator and responder clocks are slightly out of sync, the
responder will respond with an additional challenge payload to which the
initiator MUST respond with another response payload.  This is known as
"Next Code" mode.

For SecurID with "Next Code", the CHRE payloads are used as follows:

- The CHRE1 payload contains the initiator's username and the current
Passcode displayed by the initiator's SecurID token.

- The CHRE2 payload contains a SLA_T_FIN attribute with the value
of SLA_FIN_MORE.

- The CHRE3 payload contains the initiator's next Passcode
displayed by the initiator's SecurID token.

- The CHRE4 payload contains a SLA_T_FIN attribute with the value
of SLA_FIN_SUCCESS.

The following attributes are defined for SecurID:

SLA_T_USERNAME      (initiator -> responder, required)

        SLA_T_USERNAME is sent in the initiator's second message and MUST
        contain the initiator's username which is used as an index key by
        the ACE server.

SLA_T_PIN           (initiator -> responder, optional)

        SLA_T_PIN is sent in the initiator's second message and MAY be used
        when the SecurID card is not a PINPAD card.

SLA_T_MESSAGE       (responder -> initiator, optional)

        SLA_T_MESSAGE is optionally sent in any responder message and MAY by
        used by the responder to provide optional text to be displayed to
        the user along with any associated challenge text.

SLA_T_FIN           (responder -> initiator, required)

        SLA_T_FIN is used to successfully terminate the exchange and to
        request the initiator continue under "Next Code" mode.

4.5 LAM Profile Matrix

Each of the LAM's supported by IKE Challenge/Response fall into one
of the defined LAM profiles.  This section details the classification
for those methods.

Password
        DIAMETER
        LDAP
        NDS (Netware Directory Services)
        NT Domain
        RADIUS
        TACACS
        TACACS+
        UNIX Login

OTP
        OTP
        S/KEY

Challenge/Response
        AXENT Defender
        CheckPoint ActivCard
        CRYPTOCard CRYPTOCard
        Digital Pathways SNK
        LeeMah InfoCard
        Secure Computing SafeWord (Enigma Logic DES Gold)

SecurID
        RSA SecurID


5. Additional security considerations

Each legacy authentication mechanism has its own security
considerations. Using any particular legacy authentication mechanism
exposes the IKEv2 system to the same attacks as the legacy
authentication mechanism.

The encrypted channel that results after the the first two messages is
secured because the responder signs its Diffie-Hellman public value. The
channel is secured from the initiator's perspective because the
initiator knows that the responder was the actual source of the
Diffie-Hellman public value and is an active party to the exchange. The
channel is secured from the responder's perspective because the
initiator has proved proof-of-possession of a long-term shared secret
and would not have sent its sensitive information if a man-in-the-middle
was detected by the initiator.


6. Additional IANA considerations

Create a LAM Type registry from section 3.1.

Create a LAM Attribute registry from section 3.1.


7. Authors' Addresses

Dan Harkins
dharkins@trpz.com

Derrell Piper
ddp@electric-loft.org

Paul Hoffman
paul.hoffman@vpnc.org


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/