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

Versions: 00

Network Working Group                                       Steve Hanna
Internet Draft                                         Juniper Networks
Intended status: Standards Track                              Paul Funk
Expires: March 2008                                    Juniper Networks
                                                     September 24, 2007


                  Key Agility Extensions for EAP-TTLSv0
                   draft-hanna-eap-ttls-agility-00.txt


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 March 24, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document defines new Attribute Value Pairs (AVPs) that add
   cryptographic algorithm agility and other security features
   (protected results and cryptographic binding of inner authentications
   to the outer tunnel) to EAP-TTLSv0.




Hanna                   Expires March 24, 2008                 [Page 1]

Internet-Draft   draft-hanna-eap-ttls-agility-00.txt     September 2007


Table of Contents


   1. Introduction............................................ 2
   2. Terminology ............................................ 3
   3. AVP Format.............................................. 3
   4. Negotiating MSK and EMSK Computation.................... 5
      4.1. MSK-Computation AVP................................ 6
       MSK Computation Method................................. 7
      4.2. Values ............................................ 7
   5. Key Confirmation........................................ 7
      5.1. Key-Confirmation-Option AVP........................ 9
      5.2. Key-Confirmation AVP.............................. 10
   6. Secure Completion ..................................... 11
      6.1. Secure-Completion-Option AVP ..................... 13
      6.2. TTLS-Success AVP.................................. 14
      6.3. TTLS-Failure AVP.................................. 15
   7. Cryptographic Computations............................. 15
      7.1. Use of TLS PRF.................................... 15
      7.2. Composite Key Computation......................... 16
      7.3. MSK/EMSK computation using the "Mixed" mechanism.. 17
      7.4. Key Confirmation computation ..................... 17
   8. Security Considerations................................ 18
      8.1. Cryptographic Algorithm Agility................... 18
      8.2. Protection Against MITM Attacks................... 18
      8.3. Protection Against Truncation Attacks............. 19
      8.4. Protection Against Forged Results................. 19
   9. IANA Considerations.................................... 19
      9.1. Allocation of AVP Codes .......................... 19
      9.2. Creation of New Registries........................ 20
   10. References ........................................... 21
      10.1. Normative References............................. 21
      10.2. Informative References .......................... 21
   Authors' Addresses........................................ 22
   Intellectual Property Statement .......................... 22

1. Introduction

   EAP-TTLSv0 [TTLSv0] is a "tunneled EAP method". This means that it
   defines an authentication protocol for use with the Extensible
   Authentication Protocol [EAP] and that this authentication protocol
   creates a secure tunnel that can carry other authentication protocols
   and other data exchanges. EAP-TTLSv0 has many advantages such as
   extensibility, the ability to more securely carry legacy
   authentication protocols, and widespread usage. But it also has
   several issues: lack of cryptographic algorithm agility,
   vulnerability to possible Man-in-the-Middle attacks when used with


Hanna                   Expires March 24, 2008                 [Page 2]

Internet-Draft   draft-hanna-eap-ttls-agility-00.txt     September 2007


   certain legacy protocols as described in [MITM], and vulnerability to
   truncation attacks.

   This specification defines three extensions to EAP-TTLSv0 that
   address these issues by adding algorithm agility, protected results,
   and cryptographic binding of inner authentications to the outer
   tunnel. The extensions are defined using AVPs with semantics that
   allow for a gradual transition as clients and servers are upgraded to
   support the extensions. At first, clients can request the extensions
   in a backward-compatible manner but proceed with the authentication
   if the server does not support them. Servers can allow clients to use
   the extensions or not. Over time, clients and servers can change
   their policy to require the extensions, thus protecting against
   downgrade attacks. For a description of how the extensions defined in
   this document provide algorithm agility, protected results, and
   cryptobinding, see the Security Considerations section.

2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [KEYWORDS].

3. AVP Format

   This document defines several AVPs to be used with EAP-TTLSv0. All of
   these AVPs begin with the AVP header fields defined in [TTLSv0] and
   use those fields in the same way. This section describes how those
   fields are used and interpreted so that each AVP definition below
   does not need to duplicate this text. Any normative text in this
   section is normative with respect to all AVPs defined in this
   document.

   The format of an EAP-TTLSv0 AVP is shown below. All items are in
   network (i.e. big-endian) order.














Hanna                   Expires March 24, 2008                 [Page 3]

Internet-Draft   draft-hanna-eap-ttls-agility-00.txt     September 2007


    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         AVP Code                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V M r r r r r r|             AVP Length                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Vendor-ID (when V bit is 1)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Data ...
   +-+-+-+-+-+-+-+-+


   The IANA will assign AVP Codes for the AVPs defined in this document
   when this document moves to RFC status (as defined in [TTLSv0] and
   [RFC3588]). In the mean time, this document defines vendor-specific
   AVP Codes that may be used by setting the 'V' bit. Once this document
   moves to RFC status, implementations MUST accept the new standard AVP
   Codes, MAY accept the vendor-specific AVP Codes, and SHOULD only send
   the standard AVP Codes.

   The 'V' (Vendor-Specific) bit MUST be set to 1 when a vendor-specific
   AVP Code is used. Otherwise, it MUST be set to 0. When this bit is
   set to 1, the Vendor-ID field MUST be present. Otherwise, it MUST be
   absent.

   The 'M' (Mandatory) bit may be set to 0 or 1, depending on the
   preferences and policies of the party sending this AVP. If the M bit
   is set to 1, the party receiving this AVP MUST either support this
   AVP Code or fail the authentication. If the M bit is set to 0, the
   receiving party may safely ignore this AVP.

   The 'r' (reserved) bits MUST be set to 0 by the sending party and
   MUST be ignored by the receiving party, at least for this version of
   this specification. Future versions of this specification may use
   these bits for extensibility.

   The AVP Length field MUST be set to the length in octets of this AVP
   including the AVP Code, AVP Length, AVP Flags (V, M, and r), Vendor-
   ID (if present) and Data.

   The Vendor-ID field is omitted when the V flag is 0. The vendor-
   specific AVP Codes defined in this specification all have a Vendor-ID
   of 2636.

   The contents and meaning of the Data field are different for each AVP
   defined below.


Hanna                   Expires March 24, 2008                 [Page 4]

Internet-Draft   draft-hanna-eap-ttls-agility-00.txt     September 2007


4. Negotiating MSK and EMSK Computation

   Secure computation of a Master Session Key (MSK) and Extended Master
   Session Key (EMSK) is a critical part of any strong EAP method. The
   mechanism defined in [TTLSv0] for computing the MSK and EMSK always
   uses the TLS 1.1 PRF based on MD5 and SHA1. This is not algorithm
   agile. Also, the MSK and EMSK computation method defined in [TTLSv0]
   does not mix in keying material from inner authentications so
   cryptographic binding of the inner and outer authentications is not
   achieved.

   The new MSK-Computation AVP allows the TTLS client and TTLS server to
   negotiate the MSK and EMSK computation method to be used. A new MSK
   and EMSK computation method defined in section 7.3 of this
   specification achieves algorithm agility and adds cryptographic
   binding. To ensure maximum flexibility for the future, other MSK and
   EMSK computation methods can be defined and negotiated using the same
   MSK-Computation AVP.

   Options for MSK and EMSK computation defined in this specification
   include:

   -  Default computation, as defined in [TTLSv0]

   -  Mixed computation method as defined in section 7.3

   In order to negotiate a computation method other than the TTLSv0
   default, the client sends an MSK-Computation AVP in the first phase 2
   TTLS message sent to the TTLS server. This AVP indicates which MSK
   computation methods the client is willing to use. If the client does
   not include an MSK-Computation AVP in the first phase 2 TTLS message
   sent to the TTLS server, the default computation methods (as
   specified in [TTLSv0]) are used.

   If the default MSK computation method (as specified in [TTLSv0]) is
   not acceptable to the client, the client SHOULD set the M (Mandatory)
   bit in the MSK-Computation AVP to indicate that the server must
   support this AVP or terminate the authentication.

   A TTLS server that supports the MSK-Computation AVP MUST respond to
   an MSK-Computation AVP received from the client by selecting one of
   those computations or by failing the authentication if it will not
   accept any of the computations listed by the client. The server MAY
   make its selection by sending an MSK-Computation AVP in any TTLS
   message prior to the completion of the authentication; that is, the
   server is allowed to defer its selection if necessary.



Hanna                   Expires March 24, 2008                 [Page 5]

Internet-Draft   draft-hanna-eap-ttls-agility-00.txt     September 2007


   Note that when the TTLS server relays an inner authentication to
   another server, its ability to mix inner method MSKs with the TLS
   master secret depends on the MSK of the relayed authentication being
   conveyed by the other server to the TTLS server. For example, a
   RADIUS TTLS server may proxy an inner authentication to a home RADIUS
   server, which would normally return the MSK to the TTLS server via
   MPPE-Recv-Key and MPPE-Send-Key attributes. Some RADIUS servers may
   not return the MSK in this manner. In that case, the RADIUS TTLS
   server will not be able to use an MSK computation method that
   requires mixing in the inner MSK. That's why the TTLS server is
   allowed to delay committing to a particular MSK computation method
   until the end of the handshake. It may not know whether the home
   RADIUS server will return the MSK (or even whether a home RADIUS
   server will be used). The TTLS server SHOULD commit to an MSK
   computation method as soon as possible. The TTLS client MAY refuse to
   continue with an authentication if the TTLS server has not committed
   to an MSK computation method by a particular point (e.g. when
   particularly sensitive credentials are requested).

4.1. MSK-Computation AVP

   The basic format of the MSK-Computation AVP is defined in section 3
   above. This section only describes aspects that are specific to the
   MSK-Computation AVP.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         AVP Code                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V M r r r r r r|                  AVP Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Vendor-ID (when V bit is 1)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   MSK Computation Method 1                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The AVP Code for the MSK-Computation AVP will be assigned by IANA
   when this document moves to RFC status. In the mean time, a vendor-
   specific AVP Code of 256 with a Vendor-ID field of 2636 should be
   used for experimental purposes.

   The body of the MSK-Computation AVP contains one or more 32-bit MSK
   computation method values (defined in section 4.3 below), each of
   which specifies a mechanism for computing the MSK and EMSK.


Hanna                   Expires March 24, 2008                 [Page 6]

Internet-Draft   draft-hanna-eap-ttls-agility-00.txt     September 2007


   The client MAY list multiple values, in order from most to least
   preferred. The TTLS server MUST list only one value.

4.2. MSK Computation Method Values

   A standard set of MSK computation method values for use in the MSK-
   Computation AVP is defined in this section. To enable extensibility,
   each value contains a vendor-id in the first (high order) 24 bits and
   a selector in the last (low order) 8 bits. Values defined in this
   specification use a vendor-id of 0. Vendors MUST use the vendor's
   IANA-assigned Private Enterprise Number [PEN].

   The following set of standard MSK computation method values are
   defined at this time:

   -  0  Default computation as defined in [TTLSv0]

   -  1  Mixed computation mechanism as defined in section 7.3

   Additional standard MSK computation method values may be defined at a
   later time by publishing an RFC that defines these values.

5. Key Confirmation

   Key Confirmation permits the client and TTLS server each to prove to
   the other that it is in possession of all keys resulting from inner
   authentications, in addition to the TLS master secret. This is done
   to preclude a type of man-in-the-middle attack in which the attacker,
   acting as a server, induces a legitimate client to perform an
   authentication which the attacker then acts as a client to feed into
   the EAP-TTLS negotiation as an inner method (as described in [MITM]).

   Note that use of the Mixed mechanism for MSK computation may provide
   a comparable safeguard, by ensuring that the MSK resulting from the
   EAP-TTLS negotiation cannot be known by such a man-in-the-middle
   attacker, and therefore cannot be used in a subsequent data
   connection, thus allowing authentication to succeed but denying the
   attacker the fruits of that successful authentication.

   Key Confirmation is negotiated using the Key-Confirmation-Option AVP
   and implemented using the Key-Confirmation AVP. The client MAY issue
   a Key-Confirmation-Option AVP in its first phase 2 TTLS message to
   the TTLS server, indicating one or both of the following Key
   Confirmation Option values:

   -  Disabled



Hanna                   Expires March 24, 2008                 [Page 7]

Internet-Draft   draft-hanna-eap-ttls-agility-00.txt     September 2007


   -  Enabled

   By listing both Disabled and Enabled options, the client can indicate
   that it is willing to proceed with or without Key Confirmation. If
   this is the case, the client should set the M bit for the Key-
   Confirmation-Option AVP to 0 so that servers that do not support this
   AVP can be supported. If, on the other hand, the client requires Key
   Confirmation to be used, it may set the M bit for the Key-
   Confirmation-Option AVP to 1 so that servers that do not support this
   AVP will fail the authentication.

   The Key-Confirmation-Option AVP MUST appear in the client's first
   phase 2 TTLS message to the TTLS server if it appears at all. Absence
   of the Key-Confirmation-Option AVP is equivalent to selecting the
   "Disabled" option.

   If the client transmits a Key-Confirmation-Option AVP that includes
   an option acceptable to the TTLS server, the TTLS server MUST respond
   with a Key-Confirmation-Option AVP in its first phase 2 TTLS message
   to the client indicating its selection (Enabled or Disabled). If the
   TTLS server is unwilling to accommodate the client's Key Confirmation
   preference, it MUST fail the authentication.

   Once negotiated, Key Confirmation MAY be initiated by the TTLS server
   in any TTLS message, by issuing a Key-Confirmation AVP to the client.
   A Key Confirmation that occurs after all MSK-generating inner
   authentication methods have completed is called the "final Key
   Confirmation", and any Key Confirmation that occurs early (with fewer
   than all inner MSKs) is called an "intermediate Key Confirmation".

   If the TTLS server indicated "Enabled" in its Key-Confirmation-Option
   AVP, the TTLS server MAY initiate one or more intermediate Key
   Confirmations and MUST initiate a final Key Confirmation. If the TTLS
   server indicated "Disabled" in its Key-Confirmation-Option AP, the
   TTLS server MUST NOT initiate any intermediate Key Confirmations or
   final Key Confirmations.

   When the client receives a valid Key-Confirmation AVP from the TTLS
   server, it MUST include its own Key-Confirmation AVP in its next TTLS
   message to the TTLS server. If the client receives an invalid Key-
   Confirmation AVP from the TTLS server, it MUST abandon the
   authentication or otherwise cause it to fail.

   If the client wants to require the server to send a final Key
   Confirmation, it should set the M (Mandatory) bit on the Key-
   Confirmation-Option AVP to ensure that servers that do not support
   this AVP will terminate the authentication. If the client sets the M


Hanna                   Expires March 24, 2008                 [Page 8]

Internet-Draft   draft-hanna-eap-ttls-agility-00.txt     September 2007


   bit and then the server responds with a first EAP-TTLS message that
   does not include a Key-Confirmation-Option AVP or includes an invalid
   or unacceptable Key-Confirmation-Option AVP , or the TTLS server
   sends an invalid Key-Confirmation AVP at any point, the TTLS client
   should consider the authentication failed. If the TTLS server sends a
   Key-Confirmation-Option AVP indicating that key confirmation is
   Enabled and then the TTLS client receives an EAP-Success message
   without receiving a final Key Confirmation, the client SHOULD NOT
   consider the session properly established.

   If the TTLS server receives an invalid Key-Confirmation AVP from the
   TTLS client or fails to receive any Key-Confirmation AVP in response
   to one sent, the TTLS server SHOULD fail the authentication and send
   an EAP-Failure message. If secure completion has been negotiated and
   no TTLS-Success or TTLS-Failure message has been sent, a TTLS-Failure
   message should be sent before the EAP-Failure message. If secure
   completion has been negotiated and a TTLS-Success or TTLS-Failure
   message has already been sent, only an EAP-Failure message should be
   sent.

   Intermediate Key Confirmation might be used when multiple inner
   authentications are performed and it is desirable to validate the
   results of a first authentication prior to performing a subsequent
   authentication, possibly for security or performance reasons. Use of
   intermediate Key Confirmation is anticipated to be atypical.

   Because intermediate Key Confirmations expose information about the
   results of previous EAP methods, clients SHOULD NOT engage in an
   intermediate Key Confirmation unless they have already authenticated
   the server and determined that it is sufficiently trusted to expose
   this information.

5.1. Key-Confirmation-Option AVP

   The basic format of the Key-Confirmation-Option AVP is defined in
   section 3 above. This section only describes aspects that are
   specific to the Key-Confirmation-Option AVP.












Hanna                   Expires March 24, 2008                 [Page 9]

Internet-Draft   draft-hanna-eap-ttls-agility-00.txt     September 2007


    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         AVP Code                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V M r r r r r r|                  AVP Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Vendor-ID (when V bit is 1)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Key Confirmation Option Value 1                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The AVP Code for the Key-Confirmation-Option AVP will be assigned by
   IANA when this document moves to RFC status. In the mean time, a
   vendor-specific AVP Code of 257 with a Vendor-ID field of 2636 should
   be used for experimental purposes.

   The body of the Key-Confirmation-Option AVP contains one or more 32-
   bit Key Confirmation Option Values. To enable extensibility, each
   value contains a vendor-id in the first (high order) 24 bits and a
   selector in the last (low order) 8 bits. Standard values (defined in
   this or future IETF specifications) use a vendor-id of 0. Vendors
   MUST use the vendor's IANA-assigned Private Enterprise Number [PEN].

   The following standard Key Confirmation Option values are defined at
   this time:

      0  Disabled

      1  Enabled

   Additional standard Key Confirmation Option values may be defined at
   a later time by publishing an RFC that defines these values.

   The client MAY list multiple Key Confirmation Option values, in order
   from most to least preferred. The server MUST list only one value.

5.2. Key-Confirmation AVP

   The basic format of the Key-Confirmation AVP is defined in section 3
   above. This section only describes aspects that are specific to the
   Key-Confirmation AVP.





Hanna                   Expires March 24, 2008                [Page 10]

Internet-Draft   draft-hanna-eap-ttls-agility-00.txt     September 2007


    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         AVP Code                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V M r r r r r r|                  AVP Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Vendor-ID (when V bit is 1)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Key Confirmation Data ...                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Key Confirmation Data (continued)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Key Confirmation Data (continued)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Key Confirmation Data (continued)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Key Confirmation Data (continued)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Key Confirmation Data (continued)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Key Confirmation Data (continued)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Key Confirmation Data (continued)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The AVP Code for the Key-Confirmation AVP will be assigned by IANA
   when this document moves to RFC status. In the mean time, a vendor-
   specific AVP Code of 258 with a Vendor-ID field of 2636 should be
   used for experimental purposes.

   The body of the Key-Confirmation AVP contains 32 octets of binary Key
   Confirmation Data, computed as described in section 7.4.

6. Secure Completion

   As defined in [EAP], the EAP-Success and EAP-Failure messages, which
   indicate the result of an EAP authentication, are unprotected
   messages sent by the EAP authenticator to the client and not
   acknowledged by the client. Thus these messages can be changed in
   transit.

   In addition, while the TLS protocol provides a means to securely
   terminate a conversation, [TTLSv0] does not utilize that mechanism,
   leaving it vulnerable to possible truncation attack. For example, an
   attacker might insert a counterfeit EAP-Success to the client prior
   to completion of the TTLS exchange, or the attacker might contrive to


Hanna                   Expires March 24, 2008                [Page 11]

Internet-Draft   draft-hanna-eap-ttls-agility-00.txt     September 2007


   substitute empty TTLS payloads for real ones to either client or TTLS
   server in the final TTLS payloads. This substitution would go
   undetected.

   Whether such vulnerabilities could lead to real damage beyond denial
   of service depends on the underlying inner protocols used within
   TTLS. However, for maximum security it is advisable to use the Secure
   Completion mechanism to thwart possible attacks.

   In Secure Completion, the TTLS server issues a TTLS-Success or TTLS-
   Failure AVP as the final AVP of its final TTLS message to the client.
   The client responds with either a TTLS-Success or TTLS-Failure AVP as
   the final AVP of its final TTLS message to the TTLS server. Once the
   TTLS server receives the client's final TTLS message, the unprotected
   EAP-Success or EAP-Failure (as appropriate) is sent to the client to
   complete the EAP exchange.

   Note that other AVPs may appear in the same TTLS message as TTLS-
   Success or TTLS-Failure, provided they appear earlier in the message.
   The TTLS server, for example, could piggyback a TTLS-Success at the
   end of a final inner EAP-Request message.

   The client MUST respond to a TTLS-Success from the TTLS server with
   either a TTLS-Success or TTLS-Failure. The client MUST respond to a
   TTLS-Failure from the TTLS server with a TTLS-Failure. If the client
   fails to include such a value as the final AVP in its final EAP-
   Response or if the client sends a TTLS-Failure AVP in its final EAP-
   Response, the server SHOULD send an EAP-Failure. The server SHOULD
   NOT send an EAP-Failure if both the server and client have just sent
   TTLS-Success messages since an untrusted intermediary could easily
   change this EAP-Failure to an EAP-Success without the client
   detecting that change. In any case, the server SHOULD send only one
   TTLS-Success or TTLS-Failure message during a particular EAP-TTLSv0
   handshake.

   When session resumption is employed with EAP-TTLS and secure
   completion had been negotiated in the prior session, the TTLS server
   and client MUST still send TTLS-Success or TTLS-Failure AVPs to each
   other as their last AVPs. This will often result in an additional
   round trip but the client and server have previously negotiated
   secure completion and this is the price to be paid for that extra
   measure of security.

   The client MAY issue a Secure-Completion-Option AVP in its first
   phase 2 TTLS message to the TTLS server, listing one or both of the
   following Secure Completion Option values (defined in section 6.1
   below):


Hanna                   Expires March 24, 2008                [Page 12]

Internet-Draft   draft-hanna-eap-ttls-agility-00.txt     September 2007


   -  Disabled

   -  Enabled

   By listing both Disabled and Enabled options, the client can indicate
   that it is willing to proceed with or without Secure Completion. If
   this is the case, the client should set the M bit for the Secure-
   Completion-Option AVP to 0 so that servers that do not support this
   AVP can be supported. If, on the other hand, the client requires
   Secure Completion to be used, it may set the M bit for the Secure-
   Completion-Option AVP to 1 so that servers that do not support this
   AVP will fail the authentication.

   The Secure-Completion-Option AVP MUST appear in the client's first
   phase 2 TTLS message to the TTLS server if it appears at all. Absence
   of the Secure-Completion-Option AVP is equivalent to selecting the
   "Disabled" option.

   If the client transmits a Secure-Completion-Option AVP that includes
   an option acceptable to the TTLS server, the TTLS server MUST respond
   with a Secure-Completion-Option AVP in its first phase 2 TTLS message
   to the client indicating its selection (Enabled or Disabled). If the
   TTLS server is unwilling to accommodate the client's Secure
   Completion preferences, it MUST fail the authentication.

6.1. Secure-Completion-Option AVP

   The basic format of the Secure-Completion-Option AVP is defined in
   section 3 above. This section only describes aspects that are
   specific to the Secure-Completion-Option AVP.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         AVP Code                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V M r r r r r r|                  AVP Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Vendor-ID (when V bit is 1)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Secure Completion Option Value 1                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The AVP Code for the Secure-Completion-Option AVP will be assigned by
   IANA when this document moves to RFC status. In the mean time, a


Hanna                   Expires March 24, 2008                [Page 13]

Internet-Draft   draft-hanna-eap-ttls-agility-00.txt     September 2007


   vendor-specific AVP Code of 259 with a Vendor-ID field of 2636 should
   be used for experimental purposes.

   The body of the Secure-Completion-Option AVP contains one or more 32-
   bit Secure Completion Option Values. To enable extensibility, each
   value contains a vendor-id in the first (high order) 24 bits and a
   selector in the last (low order) 8 bits. Standard values (defined in
   this or future IETF specifications) use a vendor-id of 0. Vendors
   MUST use the vendor's IANA-assigned Private Enterprise Number [PEN].

   The following standard Secure Completion Option values are defined:

   -  0  Disabled (default behavior of [TTLSv0])

   -  1  Enabled

   The client MAY list multiple Secure Completion Option values, in
   order from most to least preferred. The server MUST list only one
   value.

6.2. TTLS-Success AVP

   The basic format of the TTLS-Success AVP is defined in section 3
   above. This section only describes aspects that are specific to the
   TTLS-Success AVP.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         AVP Code                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V M r r r r r r|                  AVP Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Vendor-ID (when V bit is 1)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The AVP Code for the TTLS-Success AVP will be assigned by IANA when
   this document moves to RFC status. In the mean time, a vendor-
   specific AVP Code of 260 with a Vendor-ID field of 2636 should be
   used for experimental purposes.

   The body of the TTLS-Success AVP is empty (zero length).







Hanna                   Expires March 24, 2008                [Page 14]

Internet-Draft   draft-hanna-eap-ttls-agility-00.txt     September 2007


6.3. TTLS-Failure AVP

   The basic format of the TTLS-Failure AVP is defined in section 3
   above. This section only describes aspects that are specific to the
   TTLS-Failure AVP.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         AVP Code                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V M r r r r r r|                  AVP Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Vendor-ID (when V bit is 1)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The AVP Code for the TTLS-Failure AVP will be assigned by IANA when
   this document moves to RFC status. In the mean time, a vendor-
   specific AVP Code of 261 with a Vendor-ID field of 2636 should be
   used for experimental purposes.

   The body of the TTLS-Failure AVP is empty (zero length).

7. Cryptographic Computations

7.1. Use of TLS PRF

   All of the cryptographic mechanisms described in this section use the
   PRF function used in the TLS handshake negotiation that initiates the
   TTLS exchange. In many cases, this will be the standard PRF function
   defined in TLS 1.1 [TLS]; however, it is expected that future
   versions of or extensions to the TLS protocol will permit alternative
   PRF functions to be negotiated. If an alternative PRF function has
   been negotiated during the TLS handshake negotiation, then these
   mechanisms use that alternative PRF function instead of the TLS 1.1
   PRF. This provides algorithm agility since these mechanisms are not
   tied to the MD5 and SHA-1 hashes used in the TLS 1.1 PRF.

   The TLS PRF function used for cryptography described in this
   specification is denoted as follows:

      TLS-PRF-nn(secret, label, seed)

   where:

      nn is the number of generated octets



Hanna                   Expires March 24, 2008                [Page 15]

Internet-Draft   draft-hanna-eap-ttls-agility-00.txt     September 2007


      secret is a secret key

      label is a string (without null-terminator)

      seed is a binary sequence.

   The same PRF function that is used in the TLS handshake MUST be used
   for all cryptographic operations described in this manner.

   The TLS 1.1 PRF has invariant output regardless of how many octets
   are generated. However, it is possible that alternative PRF functions
   will include the size of the output sequence as input to the PRF
   function; this means generating 32 octets and generating 64 octets
   from the same input parameters will no longer result in the first 32
   octets being identical. For this reason, the PRF is always specified
   with an "nn", indicating the number of generated octets.

7.2. Composite Key Computation

   The Composite Key is a 40-octet secret derived by cryptographically
   mixing the TLS master secret and all inner MSKs. It is used as a
   basis for computing the MSK and/or EMSK when the "Mixed" computation
   mechanism has been negotiated, as well as for computing Key
   Confirmation values.

   Note that when an intermediate Key Confirmation is performed, an
   intermediate Composite Key must be computed using only those inner
   MSKs whose values are available at the time that the TTLS server
   issues the intermediate Key Confirmation. A subsequent Key
   Confirmation exchange or MSK/EMSK computation using the "Mixed"
   mechanism will require a new Composite Key computation, as one or
   more additional inner MSKs will have become available.

   Composite Key = TLS-PRF-40(master_secret,
                "ttls composite key",
                client_random +
                server_random +
                inner_session_keys)

   master_secret, client_random and server_random are security
   parameters from the TLS handshake.

   inner_session_keys is the concatenation of all session keys produced
   by inner authentication methods. This value is calculated as follows.
   Treating each session key as an unsigned big-endian binary numeric
   value (perhaps a rather long number), sort this set of session keys
   from lowest numeric value to highest. Prefix each session key with a


Hanna                   Expires March 24, 2008                [Page 16]

Internet-Draft   draft-hanna-eap-ttls-agility-00.txt     September 2007


   2-octet big-endian value indicating the length of that session key in
   octets. Then concatenate the length-prefixed session keys in the
   determined (sorted) order. Finally, append two octets of zero to
   terminate the sequence.

   If there are no inner authentication methods that produce a session
   key, inner_session_keys will consist only of two octets of zero.

   The session keys are ordered by value rather than by the sequence in
   which they are produced in order to avoid imposing any restrictions
   against multiple concurrent inner authentications, which might result
   in ambiguous orderings.

7.3. MSK/EMSK computation using the "Mixed" mechanism

   The "Mixed" mechanism for computing the MSK and EMSK uses the
   following formula:

      Keying Material = TLS-PRF-128(composite_key,
                "ttls mixed keying material",
                <null>)

      MSK = Keying Material [0..63]

      EMSK = Keying Material [64..127]

   where <null> indicates that the seed value is of zero-length.

7.4. Key Confirmation computation

   The Key Confirmation value transmitted by the client is computed
   according to the following formula:

      client_key_confirmation = TLS-PRF-32(composite_key,
                "ttls client key confirmation",
                <null>)

   The Key Confirmation value transmitted by the TTLS server is computed
   according to the following formula:

      server_key_confirmation = TLS-PRF-32(composite_key,
                "ttls server key confirmation",
                <null>)






Hanna                   Expires March 24, 2008                [Page 17]

Internet-Draft   draft-hanna-eap-ttls-agility-00.txt     September 2007


8. Security Considerations

   The EAP-TTLSv0 extensions defined in this document supplement the
   security protection provided by EAP-TTLSv0 by adding algorithm
   agility, cryptographic binding of inner authentications to the outer
   tunnel, and protected results. These additional security features
   provide protection against failures in cryptographic algorithms,
   protection against particular kinds of MITM attacks, protection
   against truncation attacks, and protection against forged results.
   The following sections show how this protection is provided.

8.1. Cryptographic Algorithm Agility

   EAP-TTLS uses cryptographic algorithms in several places. First, it
   is based on EAP-TLS [EAPTLS] which is based on TLS which uses
   asymmetric and symmetric encryption algorithms and hash algorithms.
   Some algorithm agility is provided by the ciphersuite negotiation
   included in TLS 1.1 but the TLS PRF always uses MD5 and SHA1.
   Fortunately, TLS 1.2 [TLS12] can be used with EAP-TTLS to provide
   algorithm agility for the TLS PRF. This can be negotiated with the
   standard TLS version negotiation mechanism.

   However, the original design of EAP-TTLSv0 always uses the TLS 1.1
   PRF to calculate the Master Session Key (MSK) and Extended Master
   Session Key (EMSK). This leaves the system open to attacks based on
   weaknesses in MD5 and SHA1. The MSK-Computation AVP allows the PRF
   negotiated during the TLS handshake to be used for calculating MSK
   and EMSK values, thus allowing a smooth transition to other
   cryptographic algorithms if MD5 and SHA1 are judged to be inadequate.

8.2. Protection Against MITM Attacks

   As described in [MITM], if a malicious EAP server can convince a
   client to authenticate using a particular EAP authentication method
   and then pass this method through a standard tunneled EAP method, the
   malicious party can typically gain access as if it had performed the
   authentication itself. Several countermeasures are possible, such as
   ensuring that clients only authenticate with trusted servers. But one
   good way to solve the problem is to modify tunneled EAP methods to
   verify that the same client is terminating both the inner and the
   outer authentication method.

   The MSK-Computation AVP allows the client and/or server to require
   that the MSK and EMSK is computed using a mixture of the TLS master
   secret and the MSKs exported from inner methods. If the MSK and EMSK
   are used to derive keys necessary for later access (as with 802.1X
   [8021X]), this will ensure that the attack described above will fail


Hanna                   Expires March 24, 2008                [Page 18]

Internet-Draft   draft-hanna-eap-ttls-agility-00.txt     September 2007


   since the attacker will not know the MSKs exported from the inner
   methods. The KeyConfirmation AVPs provide even stronger protection
   against this attack, allowing the TTLS server and TTLS client each to
   verify that the other party knows the MSKs from all inner methods and
   the TLS master secret before the authentication terminates. When
   intermediate key confirmation is used, the TTLS server can verify
   this at any point in the authentication process. If a MITM attack is
   detected, the TTLS server can terminate authentication promptly to
   prevent the later authentication steps from taking place. This can
   avoid revealing sensitive information to the attacker, such as one-
   time passwords or biometric data.

8.3. Protection Against Truncation Attacks

   By truncating an EAP-TTLSv0 session, an attacker could cause the
   client to believe that the session completed successfully when in
   fact it was unsuccessful or incomplete. The implications of such an
   attack depend on the particular inner methods in use and the
   circumstances of the deployment but they could perhaps result in the
   client using the wrong keying material for later communications, for
   example. The Secure-Completion-Option, TTLS-Success, and TTLS-Failure
   AVPs allow the client to require or request that the server and
   client securely confirm the results of the authentication to each
   other before the authentication is considered complete. Thus, any
   truncation can easily be detected.

8.4. Protection Against Forged Results

   EAP results (EAP-Success and EAP-Failure) are not generally protected
   in transit from the server to the client. This means that the client
   can be led to believe that an authentication failed when it actually
   succeeded or vice versa. The Secure-Completion, TTLS-Success, and
   TTLS-Failure AVPs allow the client to securely determine the results
   of the authentication, thus foiling any attempt to forge or modify
   the results of the authentication.

9. IANA Considerations

   This section provides guidance to the Internet Assigned Numbers
   Authority (IANA) regarding registration of values related to this
   specification, in accordance with [IANA]. The term "IETF Consensus"
   is used in this section with the meaning defined in [IANA].

9.1. Allocation of AVP Codes

   This specification requires the allocation and assignment of six AVP
   Codes to identify new AVPs identified in this specification. As


Hanna                   Expires March 24, 2008                [Page 19]

Internet-Draft   draft-hanna-eap-ttls-agility-00.txt     September 2007


   described in RFC 3588, release of blocks of AVPs requires IETF
   Consensus.

   Once this document is approved as an RFC, the IANA is requested to
   allocate and assign unique AVP Codes for the following six AVPs
   defined in this specification: MSK-Computation, Key-Confirmation-
   Option, Key-Confirmation, Secure-Completion-Option, TTLS-Success, and
   TTLS-Failure.

   Once these allocations and assignments have been made, they should be
   added to this specification. For each AVP Code, there is a paragraph
   like this one:

   The AVP Code for the MSK-Computation AVP will be assigned by IANA
   when this document moves to RFC status. In the mean time, a vendor-
   specific AVP Code of 256 with a Vendor-ID field of 2636 should be
   used for experimental purposes.

   Once the AVP Code for the MSK-Computation AVP has been assigned, this
   paragraph should be changed to read:

   The AVP Code for the MSK-Computation AVP is [Assigned-AVP-Code]. In
   order to allow implementation of this specification before assignment
   of that code, a vendor-specific AVP Code of 256 with a Vendor-ID
   field of 2636 has been used for experimental purposes.
   Implementations of this RFC MUST accept the new standard AVP Code for
   the MSK-Computation AVP, MAY accept the vendor-specific AVP Code, and
   SHOULD only send the standard AVP Code.

   This subsection (subsection 9.1) of the IANA Considerations section
   may be removed once the AVP Codes have been assigned and the document
   is ready to move to RFC status.

9.2. Creation of New Registries

   This specification requires the creation of three new registries to
   be managed by IANA: MSK Computation Methods, Key Confirmation
   Options, and Secure Completion Options.

   Each of these registries should be composed of numeric values in the
   range 0 to 255. Each value should also have a name. Because of the
   limited number of values available in each of these registries,
   values should only be added to these registries if they achieve IETF
   Consensus as defined in [IANA].

   A vendor extension mechanism has been defined to allow vendors to
   define their own values similar in function to the IANA-reserved


Hanna                   Expires March 24, 2008                [Page 20]

Internet-Draft   draft-hanna-eap-ttls-agility-00.txt     September 2007


   values in these registries. This vendor extension mechanism is
   described earlier in this specification. Such vendor-specific values
   are not to be tracked or managed by IANA.

   Certain values defined in this specification should be prepopulated
   into these registries. The next three paragraphs enumerate those
   values.

   For the MSK Computation Methods registry, the values to be
   prepopulated are 0 (with a name of "Default computation as defined in
   RFC XXXX") and 1 (with a name of "Mixed computation mechanism as
   defined in RFC YYYY"), where XXXX is replaced by the RFC number
   assigned to [TTLSv0] and YYYY is replaced by the RFC number assigned
   to this specification.

   For the Key Confirmation Options registry, the values to be
   prepopulated are 0 (with a name of "Disabled") and 1 (with a name of
   "Enabled").

   For the Secure Completion Options registry, the values to be
   prepopulated are 0 (with a name of "Disabled") and 1 (with a name of
   "Enabled").

   When this document is ready to become an RFC, this paragraph and the
   preceding four paragraphs can be deleted.

10. References

10.1. Normative References

   [KEYWORDS]S. Bradner, "Key words for use in RFCs to Indicate
             Requirement Levels", RFC 2119, March 1997.

   [TLS]     Dierks, T. and E. Rescorla, "The Transport Layer Security
             (TLS) Protocol Version 1.1", RFC 4346, April 2006.

   [TTLSv0]  Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS
             Authentication Protocol Version 0", Internet Draft (work in
             progress), draft-funk-eap-ttls-v0-01.txt, April 2007.

10.2. Informative References

   [EAP]     Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
             Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
             3748, June 2004.




Hanna                   Expires March 24, 2008                [Page 21]

Internet-Draft   draft-hanna-eap-ttls-agility-00.txt     September 2007


   [EAPTLS]  Simon, D. and B. Aboba, "PPP EAP TLS Authentication
             Protocol", RFC 2716, October 1999.

   [IANA]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
             October 1998.

   [MITM]    Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in
             Tunnelled Authentication Protocols", Cryptology ePrint
             Archive, Report 2002/163, http://eprint.iacr.org, 2002.

   [PEN]     IANA Private Enterprise Numbers,
             http://www.iana.org/assignments/enterprise-numbers.

   [TLS12]   Dierks, T. and E. Rescorla, "The Transport Layer Security
             (TLS) Protocol Version 1.2", Internet Draft (work in
             progress), draft-ietf-tls-rfc4346bis-04.txt, July 2007.

   [8021X]   IEEE Standards for Local and Metropolitan Area Networks:
             Port based Network Access Control, IEEE Std 802.1X-2001,
             June 2001.

Authors' Addresses

   Steve Hanna
   Juniper Networks, Inc.
   1194 North Mathilda Avenue
   Sunnyvale, CA 94089 USA

   Email: shanna@juniper.net


   Paul Funk
   Juniper Networks, Inc.
   1194 North Mathilda Avenue
   Sunnyvale, CA 94089 USA

   Email: pfunk@juniper.net


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


Hanna                   Expires March 24, 2008                [Page 22]

Internet-Draft   draft-hanna-eap-ttls-agility-00.txt     September 2007


   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.

Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

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, THE IETF TRUST 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.

Acknowledgment

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










Hanna                   Expires March 24, 2008                [Page 23]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/