Add.

2 files changed, 786 insertions, 0 deletions

diff --git a/doc/protocol/draft-ietf-tls-ecc-new-mac-02.txt b/doc/protocol/draft-ietf-tls-ecc-new-mac-02.txt
new file mode 100644
index 0000000000..b6c9433712
--- /dev/null
+++ b/doc/protocol/draft-ietf-tls-ecc-new-mac-02.txt
@@ -0,0 +1,449 @@
+
+
+
+Network Working Group                                        E. Rescorla
+Internet-Draft                                         Network Resonance
+Intended status:  Informational                        December 19, 2007
+Expires:  June 21, 2008
+
+
+TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter
+                                  Mode
+                   draft-ietf-tls-ecc-new-mac-02.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 June 21, 2008.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   RFC 4492 describes elliptic curve cipher suites for Transport Layer
+   Security (TLS).  However, all those cipher suites use SHA-1 as their
+   MAC algorithm.  This document describes eight new CipherSuites for
+   TLS/DTLS which specify stronger digest algorithms.  Four use HMAC
+   with SHA-256 or SHA-384 and four use AES in Galois Counter Mode
+   (GCM).
+
+
+
+
+Rescorla                  Expires June 21, 2008                 [Page 1]
+
+Internet-Draft               TLS ECC New MAC               December 2007
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+     1.1.  Conventions Used In This Document . . . . . . . . . . . . . 3
+   2.  Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . . 3
+     2.1.  HMAC-based Cipher Suites  . . . . . . . . . . . . . . . . . 3
+     2.2.  Galois Counter Mode-based Cipher Suites . . . . . . . . . . 4
+     2.3.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . 5
+     2.4.  TLS Versions  . . . . . . . . . . . . . . . . . . . . . . . 5
+     2.5.  Security Considerations . . . . . . . . . . . . . . . . . . 5
+       2.5.1.  Downgrade Attack  . . . . . . . . . . . . . . . . . . . 5
+       2.5.2.  Perfect Forward Secrecy . . . . . . . . . . . . . . . . 6
+       2.5.3.  Counter Reuse with GCM  . . . . . . . . . . . . . . . . 6
+     2.6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . 6
+   3.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+     3.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
+     3.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
+   Intellectual Property and Copyright Statements  . . . . . . . . . . 8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rescorla                  Expires June 21, 2008                 [Page 2]
+
+Internet-Draft               TLS ECC New MAC               December 2007
+
+
+1.  Introduction
+
+   RFC 4492 [RFC4492] describes Elliptic Curve Cryptography (ECC) cipher
+   suites for Transport Layer Security (TLS).  However, all of the RFC
+   4492 suites use HMAC-SHA1 as their MAC algorithm.  Due to recent
+   analytic work on SHA-1 [Wang05], the IETF is gradually moving away
+   from SHA-1 and towards stronger hash algorithms.  This document
+   specifies TLS ECC cipher suites which replace SHA-256 and SHA-384
+   rather than SHA-1.
+
+   TLS 1.2 [I-D.ietf-tls-rfc4346-bis], adds support for authenticated
+   encryption with additional data (AEAD) cipher modes
+   [I-D.mcgrew-auth-enc].  This document also specifies a set of ECC
+   cipher suites using one such mode, Galois Counter Mode (GCM) [GCM].
+   Another document [I-D.salowey-tls-rsa-aes-gcm], provides support for
+   GCM with other key establishment methods.
+
+1.1.  Conventions Used In This Document
+
+   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 [RFC2119].
+
+
+2.  Cipher Suites
+
+   This document defines 8 new cipher suites to be added to TLS.  All
+   use Elliptic Curve Cryptography for key exchange and digital
+   signature, as defined in RFC 4492.
+
+2.1.  HMAC-based Cipher Suites
+
+   The first four cipher suites use AES [AES] in CBC [CBC] mode with an
+   HMAC-based MAC:
+
+       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256  = {0xXX,XX};
+       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384  = {0xXX,XX};
+       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
+       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
+
+   These four cipher suites are the same as the corresponding cipher
+   suites in RFC 4492 (TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
+   TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
+   TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, and
+   TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA) except for the hash and PRF
+   algorithms, which are SHA-256 and SHA-384 [SHS] as follows.
+
+
+
+
+
+Rescorla                  Expires June 21, 2008                 [Page 3]
+
+Internet-Draft               TLS ECC New MAC               December 2007
+
+
+      Cipher Suite                                MAC          PRF
+      ------------                                ---          ---
+      TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256     HMAC-SHA-256 P_SHA-256
+      TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384     HMAC-SHA-384 P_SHA-384
+      TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256      HMAC-SHA-256 P_SHA-256
+      TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384      HMAC-SHA-384 P_SHA-384
+
+2.2.  Galois Counter Mode-based Cipher Suites
+
+   The second four cipher suites use the new authenticated encryption
+   modes defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]:
+
+       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  = {0xXX,XX};
+       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384  = {0xXX,XX};
+       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
+       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
+
+   These cipher suites use authenticated encryption with additional data
+   algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM described in
+   [I-D.mcgrew-auth-enc].  The "nonce" input to the AEAD algorithm SHALL
+   be 12 bytes long, and is "partially implicit" (see Section 3.2.1 of
+   [I-D.mcgrew-auth-enc]).  Part of the nonce is generated as part of
+   the handshake process and is static for the entire session and part
+   is carried in each packet.
+
+             struct {
+                opaque salt[4];
+                opaque explicit_nonce_part[8];
+             } GCMNonce.
+
+   The salt value is either the client_write_IV if the client is sending
+   or the server_write_IV if the server is sending.  These IVs SHALL be
+   4 bytes long.
+
+   The explicit_nonce_part is chosen by the sender and included in the
+   packet.  Each value of the explicit_nonce_part MUST be distinct from
+   all other values, for any fixed key.  Failure to meet this uniqueness
+   requirement can significantly degrade security.  The
+   explicit_nonce_part is carried in the IV field of the
+   GenericAEADCipher structure.  Therefore, for all the algorithms
+   defined in this section, SecurityParameters.iv_length=8.
+
+   In the case of TLS the counter MAY be the 64-bit sequence number.  In
+   the case of Datagram TLS [RFC4347] [NOTE:  there needs to be a new
+   DTLS draft for AEAD, this is a placeholder] the counter MAY be formed
+   from the concatenation of the 16-bit epoch with the 48-bit sequence
+   number.
+
+
+
+
+Rescorla                  Expires June 21, 2008                 [Page 4]
+
+Internet-Draft               TLS ECC New MAC               December 2007
+
+
+   The PRF algorithms SHALL be as follows:
+
+   For TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
+   TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 it SHALL be P_SHA-256.
+
+   For TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
+   TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 it SHALL be P_SHA-384.
+
+2.3.  Acknowledgements
+
+   This work was supported by the US Department of Defense.
+
+   David McGrew contributed substantual sections of the GCM nonce text
+   as well as providing a review of this document.
+
+2.4.  TLS Versions
+
+   Because these cipher suites depend on features available only in TLS
+   1.2 (PRF flexibility and combined authenticated encryption cipher
+   modes), they MUST NOT be negotiated by older versions of TLS.
+   Clients MUST NOT offer these cipher suites if they do not offer TLS
+   1.2 or later.  Servers which select an earlier version of TLS MUST
+   NOT select one of these cipher suites.  Because TLS has no way for
+   the client to indicate that it supports TLS 1.2 but not earlier, a
+   non-compliant server might potentially negotiate TLS 1.1 or earlier
+   and select one of the cipher suites in this document.  Clients MUST
+   check the TLS version and generate a fatal "illegal_parameter" alert
+   if they detect an incorrect version.
+
+2.5.  Security Considerations
+
+   The security considerations in RFC 4346 and RFC 4492 apply to this
+   document as well.  The remainder of this section describes security
+   considerations specific to the cipher suites described in this
+   document.
+
+2.5.1.  Downgrade Attack
+
+   TLS negotiation is only as secure as the weakest cipher suite that is
+   supported.  For instance, an implementation which supports both 160-
+   bit and 256-bit elliptic curves can be subject to an active downgrade
+   attack to the 160-bit security level.  An attacker who can attack
+   that can then forge the Finished handshake check and successfully
+   mount a man-in-the-middle attack.
+
+
+
+
+
+
+
+Rescorla                  Expires June 21, 2008                 [Page 5]
+
+Internet-Draft               TLS ECC New MAC               December 2007
+
+
+2.5.2.  Perfect Forward Secrecy
+
+   The static ECDH cipher suites specified in this document do not
+   provide perfect forward secrecy (PFS).  Thus, compromise of a single
+   static key leads to potential decryption of all traffic protected
+   using that key.  Implementors of this specification SHOULD provide at
+   least one ECDHE mode of operation.
+
+2.5.3.  Counter Reuse with GCM
+
+   AES-GCM is only secure if the counter is never reused.  The IV
+   construction algorithm above is designed to ensure that this cannot
+   happen.
+
+2.6.  IANA Considerations
+
+   IANA has assigned the following values for these cipher suites:
+
+      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
+      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
+      CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256    = {0xXX,XX};
+      CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384    = {0xXX,XX};
+      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
+      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
+      CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256    = {0xXX,XX};
+      CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384    = {0xXX,XX};
+
+
+3.  References
+
+3.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
+              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
+              for Transport Layer Security (TLS)", RFC 4492, May 2006.
+
+   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+              Security", RFC 4347, April 2006.
+
+   [I-D.mcgrew-auth-enc]
+              McGrew, D., "An Interface and Algorithms for Authenticated
+              Encryption", draft-mcgrew-auth-enc-05 (work in progress),
+              November 2007.
+
+   [I-D.ietf-tls-rfc4346-bis]
+
+
+
+Rescorla                  Expires June 21, 2008                 [Page 6]
+
+Internet-Draft               TLS ECC New MAC               December 2007
+
+
+              Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-07
+              (work in progress), November 2007.
+
+   [AES]      National Institute of Standards and Technology,
+              "Specification for the Advanced Encryption Standard
+              (AES)", FIPS 197, November 2001.
+
+   [SHS]      National Institute of Standards and Technology, "Secure
+              Hash Standard", FIPS 180-2, August 2002.
+
+   [CBC]      National Institute of Standards and Technology,
+              "Recommendation for Block Cipher Modes of Operation -
+              Methods and Techniques", SP 800-38A, December 2001.
+
+   [GCM]      National Institute of Standards and Technology,
+              "Recommendation for Block Cipher Modes of Operation:
+              Galois;/Counter Mode (GCM) for Confidentiality and
+              Authentication", SP 800-38D (DRAFT), April 2006.
+
+   [Wang05]   Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
+              Full SHA-1", CRYPTO 2005, August 2005.
+
+3.2.  Informative References
+
+   [I-D.salowey-tls-rsa-aes-gcm]
+              Salowey, J., "RSA based AES-GCM Cipher Suites for TLS",
+              draft-salowey-tls-rsa-aes-gcm-00 (work in progress),
+              February 2007.
+
+
+Author's Address
+
+   Eric Rescorla
+   Network Resonance
+   2483 E. Bayshore #212
+   Palo Alto  94303
+   USA
+
+   Email:  ekr@networkresonance.com
+
+
+
+
+
+
+
+
+
+
+
+Rescorla                  Expires June 21, 2008                 [Page 7]
+
+Internet-Draft               TLS ECC New MAC               December 2007
+
+
+Full 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.
+
+   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.
+
+
+Intellectual Property
+
+   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.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Rescorla                  Expires June 21, 2008                 [Page 8]
+
+
diff --git a/doc/protocol/draft-ietf-tls-extractor-00.txt b/doc/protocol/draft-ietf-tls-extractor-00.txt
new file mode 100644
index 0000000000..9c7dd50261
--- /dev/null
+++ b/doc/protocol/draft-ietf-tls-extractor-00.txt
@@ -0,0 +1,337 @@
+
+
+
+Network Working Group                                        E. Rescorla
+Internet-Draft                                         Network Resonance
+Intended status:  Standards Track                      December 19, 2007
+Expires:  June 21, 2008
+
+
+     Keying Material Extractors for Transport Layer Security (TLS)
+                    draft-ietf-tls-extractor-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 June 21, 2008.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   A number of protocols wish to leverage Transport Layer Security (TLS)
+   to perform key establishment but then use some of the keying material
+   for their own purposes.  This document describes a general mechanism
+   for allowing that.
+
+
+
+
+
+
+
+Rescorla                  Expires June 21, 2008                 [Page 1]
+
+Internet-Draft               TLS Extractors                December 2007
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3
+   3.  Signalling Extractors . . . . . . . . . . . . . . . . . . . . . 3
+   4.  Extractor Definition  . . . . . . . . . . . . . . . . . . . . . 3
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
+   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
+   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
+     8.2.  Informational References  . . . . . . . . . . . . . . . . . 5
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5
+   Intellectual Property and Copyright Statements  . . . . . . . . . . 6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rescorla                  Expires June 21, 2008                 [Page 2]
+
+Internet-Draft               TLS Extractors                December 2007
+
+
+1.  Introduction
+
+   A number of protocols wish to leverage Transport Layer Security (TLS)
+   [4] or Datagram TLS (DTLS) [5] to perform key establishment but then
+   use some of the keying material for their own purposes.  A typical
+   example is DTLS-SRTP [6], which uses DTLS to perform a key exchange
+   and negotiate the SRTP [3] protection suite and then uses the DTLS
+   master_secret to generate the SRTP keys.
+
+   These applications imply a need to be able to extract Exported Keying
+   Material (EKM) from TLS/DTLS.  This mechanism has the following
+   requirements:
+
+   o  Both client and server need to be able to extract the same EKM
+      value.
+   o  EKM values should be indistinguishable from random by attackers
+      who don't know the master_secret.
+   o  It should be possible to extract multiple EKM values from the same
+      TLS/DTLS association.
+   o  Knowing one EKM value should not reveal any information about the
+      master_secret or about other EKM values.
+
+   The mechanism described in this document is intended to fill these
+   requirements.
+
+
+2.  Conventions Used In This Document
+
+   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 [1].
+
+
+3.  Signalling Extractors
+
+   Other protocols which wish to use extractors SHOULD have some way for
+   the peers to signal that an extractor will be used.  An example is a
+   TLS extension, as used in DTLS-SRTP.
+
+
+4.  Extractor Definition
+
+   An extractor takes as input two values:
+
+   o  A disambiguating label string
+   o  A length value
+
+   It then computes:
+
+
+
+Rescorla                  Expires June 21, 2008                 [Page 3]
+
+Internet-Draft               TLS Extractors                December 2007
+
+
+          PRF(master_secret, label,
+              SecurityParameters.client_random +
+              SecurityParameters.server_random)[length]
+
+   The output is a pseudorandom bit string of length bytes generated
+   from the master_secret.
+
+   Label values MUST be registered via Specification Required as
+   described by RFC 2434 [2].  Note that extractor labels have the
+   potential to collide with existing PRF labels.  In order to prevent
+   this, labels SHOULD begin with "EXTRACTOR".  This is not a MUST
+   because there are existing uses which have labels which do not begin
+   with this prefix.
+
+
+5.  Security Considerations
+
+   Because an extractor produces the same value if applied twice with
+   the same label to the same master_secret, it is critical that two EKM
+   values generated with the same label be used for two different
+   purposes--hence the requirement for IANA registration.  However,
+   because extractors depend on the TLS PRF, it is not a threat to the
+   use of an EKM value generated from one label to reveal an EKM value
+   generated from another label.
+
+
+6.  IANA Considerations
+
+   IANA is requested to create (has created) a TLS Extractor Label
+   registry for this purpose.  The initial contents of the registry are
+   given below:
+
+      Value                          Reference
+      -----                          ------------
+      client finished                [RFC4346]
+      server finished                [RFC4346]
+      master secret                  [RFC4346]
+      key expansion                  [RFC4346]
+      client EAP encryption          [RFC2716]
+      ttls keying material           [draft-funk-eap-ttls-v0-01]
+
+   Future values are allocated via RFC2434 Specification Required
+   policy.  The label is a string consisting of printable ASCII
+   characters.  IANA MUST also verify that one label is not a prefix of
+   any other label.  For example, labels "key" or "master secretary" are
+   forbidden.
+
+
+
+
+
+Rescorla                  Expires June 21, 2008                 [Page 4]
+
+Internet-Draft               TLS Extractors                December 2007
+
+
+7.  Acknowledgments
+
+   Thanks to Pasi Eronen for valuable comments and the contents of the
+   IANA section.
+
+
+8.  References
+
+8.1.  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+   [3]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+        Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+        RFC 3711, March 2004.
+
+   [4]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
+        Protocol Version 1.1", RFC 4346, April 2006.
+
+   [5]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+        Security", RFC 4347, April 2006.
+
+8.2.  Informational References
+
+   [6]  McGrew, D. and E. Rescorla, "Datagram Transport Layer Security
+        (DTLS) Extension to Establish Keys for  Secure Real-time
+        Transport Protocol (SRTP)", draft-ietf-avt-dtls-srtp-01 (work in
+        progress), November 2007.
+
+
+Author's Address
+
+   Eric Rescorla
+   Network Resonance
+   2064 Edgewood Drive
+   Palo Alto, CA  94303
+   USA
+
+   Email:  ekr@networkresonance.com
+
+
+
+
+
+
+
+
+Rescorla                  Expires June 21, 2008                 [Page 5]
+
+Internet-Draft               TLS Extractors                December 2007
+
+
+Full 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.
+
+   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.
+
+
+Intellectual Property
+
+   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.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Rescorla                  Expires June 21, 2008                 [Page 6]
+
+