Internet DRAFT - draft-linn-otp-tls

draft-linn-otp-tls







Network Working Group                                            J. Linn
Internet-Draft                                          RSA Laboratories
Expires: December 7, 2006                                    M. Nystroem
                                                            RSA Security
                                                            June 5, 2006


                          OTP Methods for TLS
                         draft-linn-otp-tls-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on December 7, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes means for applying One-Time Password (OTP)
   methods to authenticate Transport Layer Security sessions, operating
   in conjunction with Pre-Shared Key (PSK) ciphersuites defined for use
   with TLS.






Linn & Nystroem         Expires December 7, 2006                [Page 1]

Internet-Draft             OTP Methods for TLS                 June 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Background . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.3.  Document organization  . . . . . . . . . . . . . . . . . .  3
   2.  Acronyms and notation  . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Acronyms . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Notation . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  OTP TLS elements and protocol  . . . . . . . . . . . . . . . .  5
     3.1.  PSK establishment  . . . . . . . . . . . . . . . . . . . .  5
       3.1.1.  Introduction . . . . . . . . . . . . . . . . . . . . .  5
       3.1.2.  Direct use with entropy-enhancing PSK ciphersuites . .  6
       3.1.3.  Deriving a PSK through OTP hardening . . . . . . . . .  6
     3.2.  Structure of the PSK_Identity element  . . . . . . . . . .  6
     3.3.  TLS extension definitions  . . . . . . . . . . . . . . . .  7
       3.3.1.  Extension types  . . . . . . . . . . . . . . . . . . .  8
       3.3.2.  OTP challenge data . . . . . . . . . . . . . . . . . .  8
       3.3.3.  OTP hardening extension  . . . . . . . . . . . . . . .  9
     3.4.  Error alerts . . . . . . . . . . . . . . . . . . . . . . . 11
   4.  Security considerations  . . . . . . . . . . . . . . . . . . . 13
   5.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 14
   6.  Intellectual property considerations . . . . . . . . . . . . . 15
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 16
   Appendix A.  Example messages  . . . . . . . . . . . . . . . . . . 17
     A.1.  Example syntax . . . . . . . . . . . . . . . . . . . . . . 17
     A.2.  Client Hello . . . . . . . . . . . . . . . . . . . . . . . 17
     A.3.  Server Hello . . . . . . . . . . . . . . . . . . . . . . . 17
   Appendix B.  About OTPS  . . . . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 21



















Linn & Nystroem         Expires December 7, 2006                [Page 2]

Internet-Draft             OTP Methods for TLS                 June 2006


1.  Introduction

1.1.  Scope

   This document describes means for applying One-Time Password (OTP)
   methods to authenticate Transport Layer Security (TLS) [1] sessions,
   operating in conjunction with Pre-Shared Key (PSK) [2] ciphersuites
   defined for use with TLS.

1.2.  Background

   The TLS protocol is widely deployed and used to provide secure
   sessions, not only for web browsing but also for many other purposes.
   It supports a broad range of cryptographic methods, through
   definition and use of different ciphersuites.  Today, the majority of
   TLS deployments authenticate servers using certificate-based public-
   key techniques.  While certificate-based authentication of clients is
   also supported within the protocol, most deployments authenticate
   clients by passing other data (e.g., passwords) to servers across the
   protected channel that TLS establishes.  A recent specification [2]
   defines new ciphersuites, where clients and servers are authenticated
   to each other based on common possession of a shared secret.  The
   current document leverages these ciphersuites by using shared secrets
   that are based on OTPs.  As such, the OTP becomes the basis for
   authentication of a TLS session.

1.3.  Document organization

   The organization of this document is as follows:

   o  Section 1 is an introduction.

   o  Section 2 defines acronyms and notation used in this document.

   o  Section 3 defines methods for use of OTPs within TLS.

   o  Section 4 discusses security considerations.

   o  Section 5 discusses IANA considerations.

   o  Section 6 discusses intellectual property considerations.

   o  Appendix A provides example messages.

   o  Appendix B provides general information about the One-Time
      Password Specifications document series, where the initial drafts
      of this document were produced.




Linn & Nystroem         Expires December 7, 2006                [Page 3]

Internet-Draft             OTP Methods for TLS                 June 2006


2.  Acronyms and notation

2.1.  Acronyms

   PSK       Pre-Shared Key

   TLS       Transport Layer Security

2.2.  Notation

   TLS extension definitions are expressed in the TLS presentation
   language syntax.







































Linn & Nystroem         Expires December 7, 2006                [Page 4]

Internet-Draft             OTP Methods for TLS                 June 2006


3.  OTP TLS elements and protocol

3.1.  PSK establishment

3.1.1.  Introduction

   We define two classes of approaches for establishing a PSK based on
   an OTP value:

   o  The first choice applies the OTP directly as the PSK.  Given that
      the entropy of the value space produced by many OTP methods is
      insufficient to preclude exhaustive search by an attacker, this
      class is recommended only for use with PSK ciphersuites that
      incorporate additional random elements in PSK construction;
      currently-defined ciphersuites with this characteristic employ
      public-key methods.

   o  The second choice applies "hardening" techniques (i.e. techniques
      that do not make it computationally impossible, but economically
      unattractive for an attacker to search for a given key) to the OTP
      in order to derive a resulting PSK that is more resistant to
      search by an attacker.  A PSK of this form is suitable for use
      with arbitrary PSK ciphersuites, even those based purely on
      symmetric-key operations.

   When the OTP method requires a server-issued challenge, we rely on
   the TLS extension feature of [3] to request and provide such
   challenges.  We also rely on the TLS extension feature of [3] to
   negotiate OTP hardening parameters.

   It is important to recognize that some underlying OTP methods employ
   and transfer user-entered PINs in conjunction with OTP values.  For
   purposes of this discussion, we are concerned with PINs that users
   provide for distributed processing purposes, not those consumed
   locally to unlock a token device.  Two basic alternatives exist:

   o  Apply a function to combine the PIN with the OTP value, and use
      the result as input to PSK derivation.  With this approach,
      successful establishment of a TLS-PSK session implies that both
      peers have been independently able to provide matching OTP and PIN
      values.  As such, it offers two-factor mutual authentication.
      This approach increases the input entropy to PSK derivation, but
      may be inconsistent with operational models where users' PINs are
      maintained independently from secrets associated with their token
      devices.

   o  Omit the PIN from PSK derivation, instead retaining it to be
      separately transferred for validation in a subsequent step outside



Linn & Nystroem         Expires December 7, 2006                [Page 5]

Internet-Draft             OTP Methods for TLS                 June 2006


      the scope of TLS, though the newly-established TLS channel may be
      used as a means to transfer it securely.  This approach decouples
      the PIN from TLS processing, which may be appropriate for
      environments where PINs and token device secrets are managed
      separately (e.g., if PINs are to be accepted and processed by
      applications above the TLS layer).

   This specification allows either alternative to be supported, but
   leaves the decision as a matter to be profiled for particular OTP
   methods.  For a method that combines PINs with OTPs, the method
   profile must also define the specific combination function used to
   yield a single element as input to TLS-PSK operation.  If appropriate
   to support different scenarios and requirements, more than one method
   profile may be defined for a given underlying OTP algorithm and
   technology.

3.1.2.  Direct use with entropy-enhancing PSK ciphersuites

   For this case, the OTP value is used directly as a PSK for a TLS-PSK
   ciphersuite.  No extension to the TLS handshake is required except in
   the case of OTP methods that must transfer and process a server-
   provided challenge value before an OTP value can be generated.  For
   this, the OTP Challenge Data extension defined in Section 3.3.2 may
   be used.

   This approach can be applied in conjunction with the DHE_PSK or
   RSA_PSK key exchange algorithms defined in [2], although use of the
   DHE_PSK key exchange algorithm without OTP hardening will expose
   clients to man-in-the-middle (MITM) attacks (see further Section 4).
   For this reason, the alternative of directly using an OTP as a PSK is
   not recommended for the DHE_PSK key exchange algorithm, unless MITM
   attacks are prevented within the operational environment by separate
   server authentication methods or other means.

3.1.3.  Deriving a PSK through OTP hardening

   In this approach, a PSK is derived from a given OTP in such a way
   that an attack based on searching for the OTP becomes economically
   unattractive.  This approach can be applied in conjunction with any
   of the key exchange algorithms defined in [2].  The key derivation
   mechanism recommended in this document builds on the PBKDF2 key
   derivation function defined in PKCS #5 v2.0 [4].

3.2.  Structure of the PSK_Identity element

   For purposes of this specification, the PSK_Identity field of the
   ClientKeyExchange message defined in [2] may carry either a user's
   name or the identity of the key associated with the user's token



Linn & Nystroem         Expires December 7, 2006                [Page 6]

Internet-Draft             OTP Methods for TLS                 June 2006


   device.  At least one of user and/or key identifier is required.  We
   adopt the method of [5], Section 2.4 to represent these values and
   other data related to OTP-based authentication textually, defining
   the following prefixes:

   o  Prefix "UI=" signifies a user identifier (e.g., username).

   o  Prefix "KI=" signifies a key identifier.

   o  An "OM=" prefix is used to indicate that an OTP method is being
      used in conjunction with TLS-PSK.  This prefix may be followed by
      a textual identifier of the method (which may imply a need for a
      registry of OTP method identifiers, see Section 5), or an "OM="
      element with an empty value can be used to signify that some OTP
      method is being used in conjunction with TLS-PSK but that the
      method must be identified through other means.

   o  To provide the time associated with the OTP used in the PSK
      computations, the client may use the prefix "T=" and, if used,
      shall encode the time value as YYYYMMDDhhmmss, where YYYY denotes
      the year, MM the month, DD the day, and hh, mm, and ss, the hour,
      minutes and seconds, respectively.  The time shall always be
      provided as UTC.

   o  To provide a counter value associated with the OTP used in the PSK
      computations, the client may use the prefix "C=" and, if used,
      shall provide the counter value as a UTF-8 string of decimal
      digits.

   In this notation, assuming a user with the user identifier "J. Random
   User" and a time-based OTP calculated based on the time 11:42:04
   (UTC) December 22, 2005, but without an explicit OTP method
   identifier, the PSK_Identity value would become:

   psk_identity = "UI=J. Random User, T=20051222114204,OM=";

   OTP-based authentication of a user with OTP key identifier 142857 and
   the explicitly-identified "OTP-Counter" method with counter value
   285714 would be represented with the following PSK_Identity value:

   psk_identity = "KI=142857, C=285714, OM=OTP-Counter";

   The order of elements within a PSK_Identity field is not significant.

3.3.  TLS extension definitions






Linn & Nystroem         Expires December 7, 2006                [Page 7]

Internet-Draft             OTP Methods for TLS                 June 2006


3.3.1.  Extension types

   The extensions defined in this document are:

   challenge_data(X) /* To be defined */
   otp_hardening(Y) /* To be defined */

3.3.2.  OTP challenge data

   This extension may be used when a TLS client wants to make use of an
   OTP as a PSK (whether hardened or not), and the OTP algorithm
   requires a challenge as input.  In order to request a challenge from
   the TLS server, the client may include an extension of type
   challenge_data in the (extended) Client Hello message.  The
   extension_data field of this extension shall contain a ChallengeData
   where:

   struct {
       ChallengeDataType challenge_data_type;
       select (ChallengeDataType) {
           case request: ChallengeRequestData;
           case response: ChallengeResponseData;
       } challenge_data;
   } ChallengeData;

   enum {
       request(0), response(1), (255)
   } ChallengeDataType;

   struct {
       opaque otp_algorithm<0..2^16-1>;
       opaque otp_user_id<0..2^16-1>;
       opaque otp_key_id<0..2^16-1>;
   } ChallengeRequestData;

   struct {
       opaque otp_challenge<1..2^16-1>;
   } ChallengeResponseData;

   In a Client Hello message, the request alternative of ChallengeData
   shall be used and shall provide information that the server may need
   in order to generate a challenge:

   o  The otp_algorithm field of the ChallengeRequestData structure
      shall, when non-empty, contain a URL identifying the OTP algorithm
      that needs the challenge.





Linn & Nystroem         Expires December 7, 2006                [Page 8]

Internet-Draft             OTP Methods for TLS                 June 2006


   o  The otp_user_id field of the ChallengeRequestData structure shall,
      when non-empty, contain a user identifier (e.g., username) that
      enables the server to generate a correct challenge.  Note that use
      of this field may disclose the user identifier to eavesdroppers.

   o  The otp_key_id field of the ChallengeRequestData structure shall,
      when non-empty, contain an identifier of the OTP generation key
      with which a requested challenge is to be used.  As for the
      otp_user_id field, this field may be subject to eavesdropping.

   At least one of the otp_algorithm, otp_user_id, or otp_key_id fields
   must be non-empty in a ChallengeRequestData value; when feasible,
   both otp_algorithm and at least one of otp_user_id and otp_key_id
   should be provided.  The otp_key_id field shall refer to a key for
   the given user when both the otp_key_id and the otp_user_id fields
   are non-empty.  If the otp_user_id or the otp_key_id (or both)
   alternatives of ChallengeRequestData are non-empty, then a
   subsequently sent psk_identity value must match these values.

   Servers that receive a Client Hello containing the challenge_data
   extension may use the information contained in the extension to
   generate an appropriate challenge to return to the client.  In this
   event, the server shall include an extension of type challenge_data
   in the (extended) Server Hello.  The extension_data field of this
   extension shall contain a ChallengeData value and the response
   alternative of the ChallengeData shall be used to provide the
   challenge to the client:

   o  The otp_challenge field of the ChallengeResponseData structure
      shall contain the requested challenge.

   o  Servers that receive a Client Hello containing the challenge_data
      extension but are unable to generate an appropriate challenge
      based on the information provided by the client shall abort the
      handshake with an illegal_parameter alert.

3.3.3.  OTP hardening extension

   This extension may be used when a TLS client wants to make use of an
   OTP as a PSK and the OTP needs to be hardened before being used as a
   PSK.

   OTP hardening is achieved by applying the PBKDF2 from [4] on the OTP,
   using a negotiated iteration count.

   A TLS client may include an extension of type otp_hardening in the
   (extended) Client Hello message in order to establish hardening
   parameters with the TLS server.  The extension_data field of this



Linn & Nystroem         Expires December 7, 2006                [Page 9]

Internet-Draft             OTP Methods for TLS                 June 2006


   extension shall contain an OTPHardeningData where:

   struct {
       uint16 iteration_count;
   } OTPHardeningData;

   The client indicates its highest supported value for the iteration
   count c in PBKDF2 through the iteration_count field of the
   OTPHardeningData.

   Servers that receive a Client Hello containing the otp_hardening
   extension may use the information contained in the extension to
   provide a selected iteration count in return to the client.  In this
   event, the server shall include an extension of type otp_hardening in
   the (extended) Server Hello.  The extension_data field of this
   extension shall contain an OTPHardeningData value with the selected
   iteration count.

   Clients that receive a Server Hello containing the otp_hardening
   extension must do a sanity and policy check on the provided
   iteration_count value.  If the check passes, the client shall compute
   a PSK using PBKDF2 from [4] as follows ("||" denotes string
   concatenation):

   PSK = PBKDF2 (OTP, RS || RC, iterationCount, keyLen)

   Where:

   o  OTP is the current one-time password,

   o  RS and RC are the server_random value from the Server Hello
      message and the client_random value from the Client Hello message,
      respectively,

   o  iterationCount is the iteration_count value from the otp_hardening
      extension in the Server Hello message, and

   o  keyLen shall be set to 16 (128 bits).

   The PBKDF2 PRF algorithm shall be the TLS PRF, using the US-ASCII
   string "OTP hardening" as the label.

   Servers that receive a Client Hello containing the otp_hardening
   extension but are unwilling or unable to engage in an OTP hardening
   operation shall ignore the extension.  In this case, TLS client (and
   TLS server) policy will determine whether the handshake will continue
   or not.




Linn & Nystroem         Expires December 7, 2006               [Page 10]

Internet-Draft             OTP Methods for TLS                 June 2006


3.4.  Error alerts

   This section defines new error alerts for use with the OTP TLS method
   defined in this document.  For compatibility reasons, these alerts
   must not be sent unless the sending party has received, from the
   party they are communicating with, an extended hello message or a key
   exchange message indicating use of OTPs in TLS-PSK as defined by this
   document.

   o  "unsupported_otp_algorithm" - this alert is sent by servers that
      receive a key exchange message (or a "challenge_data" extension)
      which indicates use of an OTP algorithm that is not supported by
      the server.  This message is always fatal.

   o  "otp_key_lost" - this alert is sent by servers that receive a key
      exchange message (or a "challenge_data" extension) which indicates
      use of an OTP key that has been reported as lost.  This message
      may or may not be fatal depending on server policy.

   o  "otp_key_expired" - this alert is sent by servers that receive a
      key exchange message (or a "challenge_data" extension) which
      indicates use of an OTP key that has expired.  This message may or
      may not be fatal depending on server policy.

   o  "otp_key_blocked" - this alert is sent by servers that receive a
      key exchange message (or a "challenge_data" extension) which
      indicates use of an OTP key that has been blocked.  This message
      is always fatal.

   o  "otp_key_unknown" - this alert is sent by servers that receive a
      key exchange message (or a "challenge_data" extension) which
      indicates use of an OTP key unknown to the server.  This message
      is always fatal.

   o  "pin_change_required" - this alert is sent by servers that also
      maintain user PINs associated with OTP keys when they receive a
      key exchange message (or a "challenge_data" extension) based on a
      key for which the user PIN needs to be replaced.  This message may
      or may not be fatal depending on server policy.

   These new error alerts are conveyed using the following syntax:










Linn & Nystroem         Expires December 7, 2006               [Page 11]

Internet-Draft             OTP Methods for TLS                 June 2006


   enum {
       /* Only listing error alerts defined in this document here */
       unsupported_otp_algorithm(TBD),
       otp_key_lost(TBD),
       otp_key_expired(TBD),
       otp_key_blocked(TBD),
       otp_key_unknown(TBD),
       pin_change_required(TBD)
   } AlertDescription;










































Linn & Nystroem         Expires December 7, 2006               [Page 12]

Internet-Draft             OTP Methods for TLS                 June 2006


4.  Security considerations

   This document is a profile of [2] and all security considerations
   discussed in [2] apply.  In particular, since OTPs usually are
   relatively short, the risk of PSK compromise due to brute-force
   searching applies when an OTP is used directly as the PSK and the PSK
   key exchange algorithm or (in the case of an MITM attack) the DHE_PSK
   key exchange algorithm is used.  This document therefore recommends
   OTP hardening whenever the PSK key exchange algorithm is suggested by
   the client, or when there is a risk for a MITM attack and the DHE_PSK
   key exchange algorithm is suggested by the client.

   When, per Section 3.1.3 of this document and Section 2 of [2], a
   symmetric PSK is established through hardening of an OTP value, an
   attacker obtaining that PSK would become able to decrypt data from
   its protected TLS session.  If the encrypted session was recorded,
   its underlying plaintext could be revealed once the PSK was obtained.
   It is important, therefore, that the level of hardening applied to
   protect the PSK against searching attacks on the OTP space be
   consistent with the data's value, its useful lifetime, and the
   anticipated level of computational resources to be applied against
   the PSK.  If a suitable hardening level cannot be achieved, use of
   the entropy-enhancing ciphersuites as discussed in Section 3.1.3 of
   this document and Sections 3 and 4 of [2] is recommended.  It should
   be noted, however, that the use of OTPs provides perfect forward
   secrecy: Even if a particular OTP is compromised, an attacker will
   not be able to apply its value to decrypt any other conversation than
   the one where the OTP was used as a basis for a PSK.























Linn & Nystroem         Expires December 7, 2006               [Page 13]

Internet-Draft             OTP Methods for TLS                 June 2006


5.  IANA considerations

   This document does not contain any considerations for IANA.  A
   registry may be required for OTP method identifiers as introduced in
   Section 3.2, however.  No other IANA actions are anticipated.














































Linn & Nystroem         Expires December 7, 2006               [Page 14]

Internet-Draft             OTP Methods for TLS                 June 2006


6.  Intellectual property considerations

   RSA Security makes no patent claims on the general constructions
   defined by this document, although specific underlying techniques may
   be covered.  RSA Security has US patents (and foreign counterparts)
   on certain underlying techniques, in particular US Patent Nos.
   4,885,778; 4,856,062; 5,097,505; 5,168,520; 5,367,572 and 5,657,388.
   Additional patents are pending.  As this specification can be
   implemented without the use of these underlying techniques, it is RSA
   Security's position that the technology covered by these patents and
   applications is not required to implement this specification.








































Linn & Nystroem         Expires December 7, 2006               [Page 15]

Internet-Draft             OTP Methods for TLS                 June 2006


7.  Acknowledgements

   Thanks to all the participants at the OTPS workshops where this
   proposal has been discussed and on the OTPS mailing list for their
   review and comments related to this document.

8.  Normative References

   [1]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
        Protocol Version 1.1", RFC 4346, April 2006,
        <http://www.ietf.org/rfc4346.txt>.

   [2]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for
        Transport Layer Security (TLS)", RFC 4279, December 2005,
        <http://www.ietf.org/rfc4279.txt>.

   [3]  Blake-Wilson, S., Nystroem, M., Hopwood, D., Mikkelsen, J., and
        T. Wright, "Transport Layer Security (TLS) Extensions",
        RFC 3546, June 2003, <http://www.ietf.org/rfc3546.txt>.

   [4]  RSA Laboratories, "Password-Based Cryptography Standard",
        PKCS #5 Version 2.0, March 1999,
        <http://www.rsasecurity.com/rsalabs/pkcs/>.

   [5]  Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access
        Protocol (v3): UTF-8 String Representation of  Distinguished
        Names", RFC 4279, December 1997,
        <http://www.ietf.org/rfc2253.txt>.























Linn & Nystroem         Expires December 7, 2006               [Page 16]

Internet-Draft             OTP Methods for TLS                 June 2006


Appendix A.  Example messages

A.1.  Example syntax

   The syntax of the examples in this appendix loosely follows the
   presentation language syntax defined in [1].

A.2.  Client Hello

   In this example, the client suggests use of either the
   TLS_DHE_PSK_WITH_AES_128_CBC_SHA or the
   TLS_RSA_PSK_WITH_AES_128_CBC_SHA ciphersuite, both defined in [2].
   The client also asks the server for a suitable iteration count for
   the OTP hardening, and indicates it cannot support an iteration count
   above 20,000.

       message_type = client_hello;
       length = ...;
       body = {
       client_version = 3.1;
           random = {
               gmt_unix_time = 1135069786;
               random_bytes = 0xa243edfeed12adef...;
               };
           session_id = ; /* Empty */
           cipher_suites = {{0x00, 0x8F},{0x00,0x94}};
           compression_methods = {null};
           client_hello_extension_list = {
               {
                   extension_type = otp_hardening;
                   extension_data = {
                       iteration_count = 20000;
                       }
                   }
               }
           };

A.3.  Server Hello

   Continuing with the previous example, the server responds positively
   to the client hello message, selects the Diffie-Hellman PSK cipher
   suite, and sets the iteration count to 20,000:









Linn & Nystroem         Expires December 7, 2006               [Page 17]

Internet-Draft             OTP Methods for TLS                 June 2006


       message_type = server_hello;
       length = ...;
       body = {
           server_version = 3.1;
           random = {
               gmt_unix_time = 1135069787;
               random_bytes = 0x2143287432987321dbc321...;
               };
           session_id = 0x4321defeadcbbdbe213...;
           cipher_suite = {0x00, 0x8F};
           compression_method = null;
           server_hello_extension_list = {
               {
                   extension_type = otp_hardening;
                   extension_data = {
                       iteration_count = 20000;
                       }
                   }
               }
           };































Linn & Nystroem         Expires December 7, 2006               [Page 18]

Internet-Draft             OTP Methods for TLS                 June 2006


Appendix B.  About OTPS

   The One-Time Password Specifications are documents produced by RSA
   Laboratories in cooperation with secure systems developers for the
   purpose of simplifying integration and management of strong
   authentication technology into secure applications, and to enhance
   the user experience of this technology.

   RSA Laboratories plans further development of the OTPS series through
   mailing list discussions and occasional workshops, and suggestions
   for improvement are welcome.  As for our PKCS documents, results may
   also be submitted to standards forums.  For more information,
   contact:

   OTPS Editor
   RSA Laboratories
   174 Middlesex Turnpike
   Bedford, MA  01730 USA
   otps-editor@rsasecurity.com
   http://www.rsasecurity.com/rsalabs/































Linn & Nystroem         Expires December 7, 2006               [Page 19]

Internet-Draft             OTP Methods for TLS                 June 2006


Authors' Addresses

   John Linn
   RSA Laboratories

   Email: jlinn@rsasecurity.com


   Magnus Nystroem
   RSA Security

   Email: magnus@rsasecurity.com







































Linn & Nystroem         Expires December 7, 2006               [Page 20]

Internet-Draft             OTP Methods for TLS                 June 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Linn & Nystroem         Expires December 7, 2006               [Page 21]