Add.

2 files changed, 1078 insertions, 0 deletions

diff --git a/doc/protocol/draft-badra-tls-psk-new-mac-aes-gcm-00.txt b/doc/protocol/draft-badra-tls-psk-new-mac-aes-gcm-00.txt
new file mode 100644
index 0000000000..c0eb4c19c4
--- /dev/null
+++ b/doc/protocol/draft-badra-tls-psk-new-mac-aes-gcm-00.txt
@@ -0,0 +1,539 @@
+TLS Working Group                                         Mohamad Badra 
+Internet Draft                                         LIMOS Laboratory 
+Intended status: Standards Track                         March 29, 2008 
+Expires: September 2008 
+                                    
+ 
+                                      
+         Pre-Shared Key Cipher Suites for Transport Layer Security        
+               with SHA-256/384 and AES Galois Counter Mode  
+                draft-badra-tls-psk-new-mac-aes-gcm-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 September 29, 2008. 
+
+Copyright Notice 
+
+   Copyright (C) The IETF Trust (2008). 
+
+Abstract 
+
+   RFC 4279 and RFC 4785 describe pre-shared key cipher suites for 
+   Transport Layer Security (TLS).  However, all those cipher suites 
+   use SHA-1 as their MAC algorithm.  This document describes a set of 
+   cipher suites for TLS/DTLS which uses stronger digest algorithms 
+
+ 
+ 
+ 
+Badra                 Expires September 29, 2008               [Page 1] 
+
+Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008 
+    
+
+   (i.e. SHA-256 or SHA-384) and another which uses AES in Galois 
+   Counter Mode (GCM). 
+
+Table of Contents 
+
+    
+   1. Introduction...................................................3 
+      1.1. Conventions used in this document.........................3 
+   2. PSK, DHE_PSK and RSA_PSK Key Exchange Algorithms with AES-GCM..3 
+   3. PSK, DHE_PSK and RSA_PSK Key Exchange with SHA-256/384.........4 
+      3.1. PSK Key Exchange Algorithm with SHA-256/384...............4 
+      3.2. DHE_PSK Key Exchange Algorithm with SHA-256/384...........5 
+      3.3. RSA_PSK Key Exchange Algorithm with SHA-256/384...........5 
+   4. TLS Versions...................................................6 
+   5. Security Considerations........................................6 
+      5.1. Counter Reuse with GCM....................................6 
+      5.2. Recommendations for Multiple Encryption Processors........6 
+   6. IANA Considerations............................................7 
+   7. Acknowledgments................................................8 
+   8. References.....................................................8 
+      8.1. Normative References......................................8 
+      8.2. Informative References....................................9 
+   Author's Addresses................................................9 
+   Intellectual Property Statement..................................10 
+   Disclaimer of Validity...........................................10 
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 
+ 
+Badra                 Expires September 29, 2008               [Page 2] 
+
+Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008 
+    
+
+1. Introduction 
+
+   This document describes the use of AES [AES] in Galois Counter Mode 
+   (GCM) [GCM] (AES-GCM) with various pre-shared key (PSK) key exchange 
+   mechanisms ([RFC4279] and [RFC4785]) as a ciphersuite for Transport 
+   Layer Security (TLS).  AES-GCM is not only efficient and secure, but 
+   hardware implementations can achieve high speeds with low cost and 
+   low latency, because the mode can be pipelined. 
+
+   This document also specifies PSK cipher suites for TLS which replace 
+   SHA-256 and SHA-384 rather than SHA-1. RFC 4279 [RFC4279] and RFC 
+   4785 [RFC4785] describe pre-shared key (PSK) cipher suites for TLS.  
+   However, all of the RFC 4279 and the RFC 4785 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. 
+
+   [I-D.ietf-tls-ecc-new-mac] and [I-D.ietf-tls-rsa-aes-gcm] provide 
+   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. PSK, DHE_PSK and RSA_PSK Key Exchange Algorithms with AES-GCM 
+
+   The following eight cipher suites use the new authenticated 
+   encryption modes defined in TLS 1.2 with AES in Galois Counter Mode 
+   (GCM) [GCM]: 
+
+      CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA256      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_AES_258_GCM_SHA256      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA384      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_AES_256_GCM_SHA384      = {0xXX,0xXX}; 
+      CipherSuite TLS_DHE_PSK_WITH_AES_128_GCM_SHA256  = {0xXX,0xXX}; 
+      CipherSuite TLS_DHE_PSK_WITH_AES_256_GCM_SHA384  = {0xXX,0xXX}; 
+      CipherSuite TLS_RSA_PSK_WITH_AES_128_GCM_SHA256  = {0xXX,0xXX}; 
+      CipherSuite TLS_RSA_PSK_WITH_AES_256_GCM_SHA384  = {0xXX,0xXX}; 
+
+   These cipher suites use authenticated encryption with additional 
+   data algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM described in 
+   RFC 5116.  The "nonce" input to the AEAD algorithm SHALL be 12 bytes 
+   long, and is "partially implicit" (see Section 3.2.1 of RFC 5116).  
+   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. 
+ 
+ 
+Badra                 Expires September 29, 2008               [Page 3] 
+
+Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008 
+    
+
+                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.  Therefore, for all the algorithms defined in 
+   this section, SecurityParameters.fixed_iv_length=4. 
+
+   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.record_iv_length=8. 
+
+   In the case of TLS the counter MAY be the 64-bit sequence number.  
+   In the case of Datagram TLS [RFC4347] the counter MAY be formed from 
+   the concatenation of the 16-bit epoch with the 48-bit sequence 
+   number. 
+
+   The PRF algorithms SHALL be as follows: 
+
+   For ciphersuites ending in _SHA256 the hash function is SHA256. 
+
+   For ciphersuites ending in _SHA384 the hash function is SHA384. 
+
+3. PSK, DHE_PSK and RSA_PSK Key Exchange with SHA-256/384 
+
+   The cipher suites described in this section use AES [AES] in CBC 
+   [CBC] mode with an HMAC-based MAC. 
+
+3.1. PSK Key Exchange Algorithm with SHA-256/384 
+
+      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA256      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA256      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA384      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA384      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_NULL_SHA256             = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_NULL_SHA384             = {0xXX,0xXX}; 
+
+   The above six cipher suites are the same as the corresponding cipher 
+   suites in RFC 4279 and RFC 4785 (TLS_PSK_WITH_AES_128_CBC_SHA, 
+   TLS_PSK_WITH_AES_256_CBC_SHA, and TLS_PSK_WITH_NULL_SHA) except for 
+
+ 
+ 
+Badra                 Expires September 29, 2008               [Page 4] 
+
+Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008 
+    
+
+   the hash and PRF algorithms, which are SHA-256 and SHA-384 [SHS] as 
+   follows. 
+
+   Cipher Suite                             MAC             PRF 
+   ------------                             ---             --- 
+   TLS_PSK_WITH_AES_128_CBC_SHA256          HMAC-SHA-256    P_SHA-256 
+   TLS_PSK_WITH_AES_128_CBC_SHA384          HMAC-SHA-384    P_SHA-384 
+   TLS_PSK_WITH_AES_256_CBC_SHA256          HMAC-SHA-256    P_SHA-256 
+   TLS_PSK_WITH_AES_256_CBC_SHA384          HMAC-SHA-384    P_SHA-384 
+   TLS_PSK_WITH_NULL_SHA256                 HMAC-SHA-256    P_SHA-256 
+   TLS_PSK_WITH_NULL_SHA384                 HMAC-SHA-384    P_SHA-384 
+
+3.2. DHE_PSK Key Exchange Algorithm with SHA-256/384 
+
+      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA256  = {0xXX,0xXX};   
+      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA384  = {0xXX,0xXX}; 
+      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA256  = {0xXX,0xXX};     
+      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA384  = {0xXX,0xXX}; 
+      CipherSuite TLS_DHE_PSK_WITH_NULL_SHA256         = {0xXX,0xXX};     
+      CipherSuite TLS_DHE_PSK_WITH_NULL_SHA384         = {0xXX,0xXX}; 
+
+   The above six cipher suites are the same as the corresponding cipher 
+   suites in RFC 4279 and RFC 4785 (TLS_DHE_PSK_WITH_AES_128_CBC_SHA, 
+   TLS_DHE_PSK_WITH_AES_256_CBC_SHA, and TLS_DHE_PSK_WITH_NULL_SHA) 
+   except for the hash and PRF algorithms, which are SHA-256 and SHA-
+   384 [SHS] as follows. 
+
+   Cipher Suite                             MAC             PRF 
+   ------------                             ---             --- 
+   TLS_DHE_PSK_WITH_AES_128_CBC_SHA256      HMAC-SHA-256    P_SHA-256 
+   TLS_DHE_PSK_WITH_AES_128_CBC_SHA384      HMAC-SHA-384    P_SHA-384 
+   TLS_DHE_PSK_WITH_AES_256_CBC_SHA256      HMAC-SHA-256    P_SHA-256 
+   TLS_DHE_PSK_WITH_AES_256_CBC_SHA384      HMAC-SHA-384    P_SHA-384 
+
+3.3. RSA_PSK Key Exchange Algorithm with SHA-256/384 
+
+      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA256    = {0xXX,0xXX}; 
+      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA384    = {0xXX,0xXX}; 
+      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA256    = {0xXX,0xXX}; 
+      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA384    = {0xXX,0xXX}; 
+
+   The above four cipher suites are the same as the corresponding 
+   cipher suites in RFC 4279 and RFC 4785 
+   (TLS_RSA_PSK_WITH_AES_128_CBC_SHA, TLS_RSA_PSK_WITH_AES_256_CBC_SHA, 
+   and TLS_RSA_PSK_WITH_NULL_SHA) except for the hash and PRF 
+   algorithms, which are SHA-256 and SHA-384 [SHS] as follows. 
+
+ 
+ 
+Badra                 Expires September 29, 2008               [Page 5] 
+
+Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008 
+    
+
+   Cipher Suite                             MAC             PRF 
+   ------------                             ---             --- 
+   TLS_RSA_PSK_WITH_AES_128_CBC_SHA256      HMAC-SHA-256    P_SHA-256 
+   TLS_RSA_PSK_WITH_AES_128_CBC_SHA384      HMAC-SHA-384    P_SHA-384 
+   TLS_RSA_PSK_WITH_AES_256_CBC_SHA256      HMAC-SHA-256    P_SHA-256 
+   TLS_RSA_PSK_WITH_AES_256_CBC_SHA384      HMAC-SHA-384    P_SHA-384 
+
+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. 
+
+5. Security Considerations 
+
+   The security considerations in [I-D.ietf-tls-rfc4346-bis], RFC 4279 
+   and RFC 4785 apply to this document as well.  The remainder of this 
+   section describes security considerations specific to the cipher 
+   suites described in this document. 
+
+5.1. 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. 
+
+5.2. Recommendations for Multiple Encryption Processors 
+
+   If multiple cryptographic processors are in use by the sender, then 
+   the sender MUST ensure that, for a particular key, each value of the 
+   explicit_nonce_part used with that key is distinct.  In this case 
+   each encryption processor SHOULD include in the explicit_nonce_part 
+   a fixed value that is distinct for each processor.  The recommended 
+   format is 
+
+        explicit_nonce_part = FixedDistinct || Variable 
+
+   where the FixedDistinct field is distinct for each encryption 
+   processor, but is fixed for a given processor, and the Variable 
+ 
+ 
+Badra                 Expires September 29, 2008               [Page 6] 
+
+Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008 
+    
+
+   field is distinct for each distinct nonce used by a particular 
+   encryption processor.  When this method is used, the FixedDistinct 
+   fields used by the different processors MUST have the same length. 
+
+   In the terms of Figure 2 in [RFC5116], the Salt is the Fixed-Common 
+   part of the nonce (it is fixed, and it is common across all 
+   encryption processors), the FixedDistinct field exactly corresponds 
+   to the Fixed-Distinct field, and the Variable field corresponds to 
+   the Counter field, and the explicit part exactly corresponds to the 
+
+   explicit_nonce_part. 
+
+   For clarity, we provide an example for TLS in which there are two 
+   distinct encryption processors, each of which uses a one-byte 
+   FixedDistinct field: 
+
+          Salt          = eedc68dc 
+          FixedDistinct = 01      (for the first encryption processor) 
+          FixedDistinct = 02      (for the second encryption processor) 
+
+   The GCMnonces generated by the first encryption processor, and their 
+   corresponding explicit_nonce_parts, are: 
+
+          GCMNonce                    explicit_nonce_part 
+          ------------------------    -------------------- 
+          eedc68dc0100000000000000    0100000000000000 
+          eedc68dc0100000000000001    0100000000000001 
+          eedc68dc0100000000000002    0100000000000002 
+          ... 
+
+   The GCMnonces generated by the second encryption processor, and 
+   their corresponding explicit_nonce_parts, are 
+
+          GCMNonce                    explicit_nonce_part 
+          ------------------------    -------------------- 
+          eedc68dc0200000000000000    0200000000000000 
+          eedc68dc0200000000000001    0200000000000001 
+          eedc68dc0200000000000002    0200000000000002 
+          ... 
+
+6. IANA Considerations 
+
+   IANA has assigned the following values for the cipher suites defined 
+   in this document: 
+
+      CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA256      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_AES_258_GCM_SHA256      = {0xXX,0xXX}; 
+ 
+ 
+Badra                 Expires September 29, 2008               [Page 7] 
+
+Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008 
+    
+
+      CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA384      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_AES_256_GCM_SHA384      = {0xXX,0xXX}; 
+      CipherSuite TLS_DHE_PSK_WITH_AES_128_GCM_SHA256  = {0xXX,0xXX}; 
+      CipherSuite TLS_DHE_PSK_WITH_AES_256_GCM_SHA384  = {0xXX,0xXX}; 
+      CipherSuite TLS_RSA_PSK_WITH_AES_128_GCM_SHA256  = {0xXX,0xXX}; 
+      CipherSuite TLS_RSA_PSK_WITH_AES_256_GCM_SHA384  = {0xXX,0xXX};    
+      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA256      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA256      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA384      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA384      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_NULL_SHA256             = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_NULL_SHA384             = {0xXX,0xXX}; 
+      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA256  = {0xXX,0xXX};   
+      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA384  = {0xXX,0xXX}; 
+      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA256  = {0xXX,0xXX};     
+      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA384  = {0xXX,0xXX}; 
+      CipherSuite TLS_DHE_PSK_WITH_NULL_SHA256         = {0xXX,0xXX};     
+      CipherSuite TLS_DHE_PSK_WITH_NULL_SHA384         = {0xXX,0xXX}; 
+      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA256  = {0xXX,0xXX}; 
+      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA384  = {0xXX,0xXX}; 
+      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA256  = {0xXX,0xXX}; 
+      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA384  = {0xXX,0xXX}; 
+
+7. Acknowledgments 
+
+   This draft borrows heavily from [I-D.ietf-tls-ecc-new-mac] and [I-
+   D.ietf-tls-rsa-aes-gcm]. 
+
+8. References 
+
+8.1. Normative References 
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
+             Requirement Levels", BCP 14, RFC 2119, March 1997. 
+
+   [I-D.ietf-tls-rfc4346-bis] 
+             Dierks, T. and E. Rescorla, "The Transport Layer Security 
+             (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-
+             10, work in progress, March 2008. 
+
+   [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 
+             Encryption", RFC 5116, January 2008.  
+
+   [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 
+             for Transport Layer Security (TLS)", RFC 4279, December 
+             2005.  
+
+ 
+ 
+Badra                 Expires September 29, 2008               [Page 8] 
+
+Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008 
+    
+
+   [RFC4785] Blumenthal, U., Goel, P., "Pre-Shared Key (PSK) 
+             Ciphersuites with NULL Encryption for Transport Layer 
+             Security (TLS)", RFC 4785, January 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, November 2007. 
+
+8.2. Informative References 
+
+   [Wang05]  Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 
+             Full SHA-1", CRYPTO 2005, August 2005. 
+
+   [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 
+             Security", RFC 4347, April 2006. 
+
+   [I-D.ietf-tls-ecc-new-mac] 
+             Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
+             256/384 and AES Galois Counter  Mode", draft-ietf-tls-ecc-
+             new-mac-04 (work in progress), February 2008. 
+
+   [I-D.ietf-tls-rsa-aes-gcm] 
+             Salowey, J., A. Choudhury, and C. McGrew, "RSA based AES-
+             GCM Cipher Suites for TLS", draft-ietf-tls-rsa-aes-gcm-02 
+             (work in progress), February 2008. 
+
+Author's Addresses 
+
+   Mohamad Badra 
+   LIMOS Laboratory - UMR6158, CNRS 
+   France 
+    
+   Email: badra@isima.fr 
+    
+
+ 
+ 
+Badra                 Expires September 29, 2008               [Page 9] 
+
+Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008 
+    
+
+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, 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. 
+
+Copyright Statement 
+
+   Copyright (C) The IETF Trust (2008). 
+
+   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. 
+ 
+ 
+Badra                 Expires September 29, 2008              [Page 10] 
+
diff --git a/doc/protocol/draft-badra-tls-psk-new-mac-aes-gcm-01.txt b/doc/protocol/draft-badra-tls-psk-new-mac-aes-gcm-01.txt
new file mode 100644
index 0000000000..d97fe10b77
--- /dev/null
+++ b/doc/protocol/draft-badra-tls-psk-new-mac-aes-gcm-01.txt
@@ -0,0 +1,539 @@
+TLS Working Group                                         Mohamad Badra 
+Internet Draft                                         LIMOS Laboratory 
+Intended status: Standards Track                         March 29, 2008 
+Expires: September 2008 
+                                    
+ 
+                                      
+         Pre-Shared Key Cipher Suites for Transport Layer Security        
+               with SHA-256/384 and AES Galois Counter Mode  
+                draft-badra-tls-psk-new-mac-aes-gcm-01.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 September 29, 2008. 
+
+Copyright Notice 
+
+   Copyright (C) The IETF Trust (2008). 
+
+Abstract 
+
+   RFC 4279 and RFC 4785 describe pre-shared key cipher suites for 
+   Transport Layer Security (TLS).  However, all those cipher suites 
+   use SHA-1 as their MAC algorithm.  This document describes a set of 
+   cipher suites for TLS/DTLS which uses stronger digest algorithms 
+
+ 
+ 
+ 
+Badra                 Expires September 29, 2008               [Page 1] 
+
+Internet-Draft       TLS PSK New MAC and AES-GCM             March 2008 
+    
+
+   (i.e. SHA-256 or SHA-384) and another which uses AES in Galois 
+   Counter Mode (GCM). 
+
+Table of Contents 
+
+    
+   1. Introduction...................................................3 
+      1.1. Conventions used in this document.........................3 
+   2. PSK, DHE_PSK and RSA_PSK Key Exchange Algorithms with AES-GCM..3 
+   3. PSK, DHE_PSK and RSA_PSK Key Exchange with SHA-256/384.........4 
+      3.1. PSK Key Exchange Algorithm with SHA-256/384...............4 
+      3.2. DHE_PSK Key Exchange Algorithm with SHA-256/384...........5 
+      3.3. RSA_PSK Key Exchange Algorithm with SHA-256/384...........5 
+   4. TLS Versions...................................................6 
+   5. Security Considerations........................................6 
+      5.1. Counter Reuse with GCM....................................6 
+      5.2. Recommendations for Multiple Encryption Processors........6 
+   6. IANA Considerations............................................7 
+   7. Acknowledgments................................................8 
+   8. References.....................................................8 
+      8.1. Normative References......................................8 
+      8.2. Informative References....................................9 
+   Author's Addresses................................................9 
+   Intellectual Property Statement..................................10 
+   Disclaimer of Validity...........................................10 
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 
+ 
+Badra                 Expires September 29, 2008               [Page 2] 
+
+Internet-Draft       TLS PSK New MAC and AES-GCM             March 2008 
+    
+
+1. Introduction 
+
+   This document describes the use of AES [AES] in Galois Counter Mode 
+   (GCM) [GCM] (AES-GCM) with various pre-shared key (PSK) key exchange 
+   mechanisms ([RFC4279] and [RFC4785]) as a ciphersuite for Transport 
+   Layer Security (TLS).  AES-GCM is not only efficient and secure, but 
+   hardware implementations can achieve high speeds with low cost and 
+   low latency, because the mode can be pipelined. 
+
+   This document also specifies PSK cipher suites for TLS which replace 
+   SHA-256 and SHA-384 rather than SHA-1. RFC 4279 [RFC4279] and RFC 
+   4785 [RFC4785] describe pre-shared key (PSK) cipher suites for TLS.  
+   However, all of the RFC 4279 and the RFC 4785 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. 
+
+   [I-D.ietf-tls-ecc-new-mac] and [I-D.ietf-tls-rsa-aes-gcm] provide 
+   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. PSK, DHE_PSK and RSA_PSK Key Exchange Algorithms with AES-GCM 
+
+   The following eight cipher suites use the new authenticated 
+   encryption modes defined in TLS 1.2 with AES in Galois Counter Mode 
+   (GCM) [GCM]: 
+
+      CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA256      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_AES_258_GCM_SHA256      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA384      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_AES_256_GCM_SHA384      = {0xXX,0xXX}; 
+      CipherSuite TLS_DHE_PSK_WITH_AES_128_GCM_SHA256  = {0xXX,0xXX}; 
+      CipherSuite TLS_DHE_PSK_WITH_AES_256_GCM_SHA384  = {0xXX,0xXX}; 
+      CipherSuite TLS_RSA_PSK_WITH_AES_128_GCM_SHA256  = {0xXX,0xXX}; 
+      CipherSuite TLS_RSA_PSK_WITH_AES_256_GCM_SHA384  = {0xXX,0xXX}; 
+
+   These cipher suites use authenticated encryption with additional 
+   data algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM described in 
+   RFC 5116.  The "nonce" input to the AEAD algorithm SHALL be 12 bytes 
+   long, and is "partially implicit" (see Section 3.2.1 of RFC 5116).  
+   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. 
+ 
+ 
+Badra                 Expires September 29, 2008               [Page 3] 
+
+Internet-Draft       TLS PSK New MAC and AES-GCM             March 2008 
+    
+
+                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.  Therefore, for all the algorithms defined in 
+   this section, SecurityParameters.fixed_iv_length=4. 
+
+   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.record_iv_length=8. 
+
+   In the case of TLS the counter MAY be the 64-bit sequence number.  
+   In the case of Datagram TLS [RFC4347] the counter MAY be formed from 
+   the concatenation of the 16-bit epoch with the 48-bit sequence 
+   number. 
+
+   The PRF algorithms SHALL be as follows: 
+
+   For ciphersuites ending in _SHA256 the hash function is SHA256. 
+
+   For ciphersuites ending in _SHA384 the hash function is SHA384. 
+
+3. PSK, DHE_PSK and RSA_PSK Key Exchange with SHA-256/384 
+
+   The cipher suites described in this section use AES [AES] in CBC 
+   [CBC] mode with an HMAC-based MAC. 
+
+3.1. PSK Key Exchange Algorithm with SHA-256/384 
+
+      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA256      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA256      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA384      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA384      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_NULL_SHA256             = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_NULL_SHA384             = {0xXX,0xXX}; 
+
+   The above six cipher suites are the same as the corresponding cipher 
+   suites in RFC 4279 and RFC 4785 (TLS_PSK_WITH_AES_128_CBC_SHA, 
+   TLS_PSK_WITH_AES_256_CBC_SHA, and TLS_PSK_WITH_NULL_SHA) except for 
+
+ 
+ 
+Badra                 Expires September 29, 2008               [Page 4] 
+
+Internet-Draft       TLS PSK New MAC and AES-GCM             March 2008 
+    
+
+   the hash and PRF algorithms, which are SHA-256 and SHA-384 [SHS] as 
+   follows. 
+
+   Cipher Suite                             MAC             PRF 
+   ------------                             ---             --- 
+   TLS_PSK_WITH_AES_128_CBC_SHA256          HMAC-SHA-256    P_SHA-256 
+   TLS_PSK_WITH_AES_128_CBC_SHA384          HMAC-SHA-384    P_SHA-384 
+   TLS_PSK_WITH_AES_256_CBC_SHA256          HMAC-SHA-256    P_SHA-256 
+   TLS_PSK_WITH_AES_256_CBC_SHA384          HMAC-SHA-384    P_SHA-384 
+   TLS_PSK_WITH_NULL_SHA256                 HMAC-SHA-256    P_SHA-256 
+   TLS_PSK_WITH_NULL_SHA384                 HMAC-SHA-384    P_SHA-384 
+
+3.2. DHE_PSK Key Exchange Algorithm with SHA-256/384 
+
+      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA256  = {0xXX,0xXX};   
+      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA384  = {0xXX,0xXX}; 
+      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA256  = {0xXX,0xXX};     
+      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA384  = {0xXX,0xXX}; 
+      CipherSuite TLS_DHE_PSK_WITH_NULL_SHA256         = {0xXX,0xXX};     
+      CipherSuite TLS_DHE_PSK_WITH_NULL_SHA384         = {0xXX,0xXX}; 
+
+   The above six cipher suites are the same as the corresponding cipher 
+   suites in RFC 4279 and RFC 4785 (TLS_DHE_PSK_WITH_AES_128_CBC_SHA, 
+   TLS_DHE_PSK_WITH_AES_256_CBC_SHA, and TLS_DHE_PSK_WITH_NULL_SHA) 
+   except for the hash and PRF algorithms, which are SHA-256 and SHA-
+   384 [SHS] as follows. 
+
+   Cipher Suite                             MAC             PRF 
+   ------------                             ---             --- 
+   TLS_DHE_PSK_WITH_AES_128_CBC_SHA256      HMAC-SHA-256    P_SHA-256 
+   TLS_DHE_PSK_WITH_AES_128_CBC_SHA384      HMAC-SHA-384    P_SHA-384 
+   TLS_DHE_PSK_WITH_AES_256_CBC_SHA256      HMAC-SHA-256    P_SHA-256 
+   TLS_DHE_PSK_WITH_AES_256_CBC_SHA384      HMAC-SHA-384    P_SHA-384 
+
+3.3. RSA_PSK Key Exchange Algorithm with SHA-256/384 
+
+      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA256    = {0xXX,0xXX}; 
+      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA384    = {0xXX,0xXX}; 
+      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA256    = {0xXX,0xXX}; 
+      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA384    = {0xXX,0xXX}; 
+
+   The above four cipher suites are the same as the corresponding 
+   cipher suites in RFC 4279 and RFC 4785 
+   (TLS_RSA_PSK_WITH_AES_128_CBC_SHA, TLS_RSA_PSK_WITH_AES_256_CBC_SHA, 
+   and TLS_RSA_PSK_WITH_NULL_SHA) except for the hash and PRF 
+   algorithms, which are SHA-256 and SHA-384 [SHS] as follows. 
+
+ 
+ 
+Badra                 Expires September 29, 2008               [Page 5] 
+
+Internet-Draft       TLS PSK New MAC and AES-GCM             March 2008 
+    
+
+   Cipher Suite                             MAC             PRF 
+   ------------                             ---             --- 
+   TLS_RSA_PSK_WITH_AES_128_CBC_SHA256      HMAC-SHA-256    P_SHA-256 
+   TLS_RSA_PSK_WITH_AES_128_CBC_SHA384      HMAC-SHA-384    P_SHA-384 
+   TLS_RSA_PSK_WITH_AES_256_CBC_SHA256      HMAC-SHA-256    P_SHA-256 
+   TLS_RSA_PSK_WITH_AES_256_CBC_SHA384      HMAC-SHA-384    P_SHA-384 
+
+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. 
+
+5. Security Considerations 
+
+   The security considerations in [I-D.ietf-tls-rfc4346-bis], RFC 4279 
+   and RFC 4785 apply to this document as well.  The remainder of this 
+   section describes security considerations specific to the cipher 
+   suites described in this document. 
+
+5.1. 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. 
+
+5.2. Recommendations for Multiple Encryption Processors 
+
+   If multiple cryptographic processors are in use by the sender, then 
+   the sender MUST ensure that, for a particular key, each value of the 
+   explicit_nonce_part used with that key is distinct.  In this case 
+   each encryption processor SHOULD include in the explicit_nonce_part 
+   a fixed value that is distinct for each processor.  The recommended 
+   format is 
+
+        explicit_nonce_part = FixedDistinct || Variable 
+
+   where the FixedDistinct field is distinct for each encryption 
+   processor, but is fixed for a given processor, and the Variable 
+ 
+ 
+Badra                 Expires September 29, 2008               [Page 6] 
+
+Internet-Draft       TLS PSK New MAC and AES-GCM             March 2008 
+    
+
+   field is distinct for each distinct nonce used by a particular 
+   encryption processor.  When this method is used, the FixedDistinct 
+   fields used by the different processors MUST have the same length. 
+
+   In the terms of Figure 2 in [RFC5116], the Salt is the Fixed-Common 
+   part of the nonce (it is fixed, and it is common across all 
+   encryption processors), the FixedDistinct field exactly corresponds 
+   to the Fixed-Distinct field, and the Variable field corresponds to 
+   the Counter field, and the explicit part exactly corresponds to the 
+
+   explicit_nonce_part. 
+
+   For clarity, we provide an example for TLS in which there are two 
+   distinct encryption processors, each of which uses a one-byte 
+   FixedDistinct field: 
+
+          Salt          = eedc68dc 
+          FixedDistinct = 01      (for the first encryption processor) 
+          FixedDistinct = 02      (for the second encryption processor) 
+
+   The GCMnonces generated by the first encryption processor, and their 
+   corresponding explicit_nonce_parts, are: 
+
+          GCMNonce                    explicit_nonce_part 
+          ------------------------    -------------------- 
+          eedc68dc0100000000000000    0100000000000000 
+          eedc68dc0100000000000001    0100000000000001 
+          eedc68dc0100000000000002    0100000000000002 
+          ... 
+
+   The GCMnonces generated by the second encryption processor, and 
+   their corresponding explicit_nonce_parts, are 
+
+          GCMNonce                    explicit_nonce_part 
+          ------------------------    -------------------- 
+          eedc68dc0200000000000000    0200000000000000 
+          eedc68dc0200000000000001    0200000000000001 
+          eedc68dc0200000000000002    0200000000000002 
+          ... 
+
+6. IANA Considerations 
+
+   IANA has assigned the following values for the cipher suites defined 
+   in this document: 
+
+      CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA256      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_AES_258_GCM_SHA256      = {0xXX,0xXX}; 
+ 
+ 
+Badra                 Expires September 29, 2008               [Page 7] 
+
+Internet-Draft       TLS PSK New MAC and AES-GCM             March 2008 
+    
+
+      CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA384      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_AES_256_GCM_SHA384      = {0xXX,0xXX}; 
+      CipherSuite TLS_DHE_PSK_WITH_AES_128_GCM_SHA256  = {0xXX,0xXX}; 
+      CipherSuite TLS_DHE_PSK_WITH_AES_256_GCM_SHA384  = {0xXX,0xXX}; 
+      CipherSuite TLS_RSA_PSK_WITH_AES_128_GCM_SHA256  = {0xXX,0xXX}; 
+      CipherSuite TLS_RSA_PSK_WITH_AES_256_GCM_SHA384  = {0xXX,0xXX};    
+      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA256      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA256      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA384      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA384      = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_NULL_SHA256             = {0xXX,0xXX}; 
+      CipherSuite TLS_PSK_WITH_NULL_SHA384             = {0xXX,0xXX}; 
+      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA256  = {0xXX,0xXX};   
+      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA384  = {0xXX,0xXX}; 
+      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA256  = {0xXX,0xXX};     
+      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA384  = {0xXX,0xXX}; 
+      CipherSuite TLS_DHE_PSK_WITH_NULL_SHA256         = {0xXX,0xXX};     
+      CipherSuite TLS_DHE_PSK_WITH_NULL_SHA384         = {0xXX,0xXX}; 
+      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA256  = {0xXX,0xXX}; 
+      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA384  = {0xXX,0xXX}; 
+      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA256  = {0xXX,0xXX}; 
+      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA384  = {0xXX,0xXX}; 
+
+7. Acknowledgments 
+
+   This draft borrows heavily from [I-D.ietf-tls-ecc-new-mac] and [I-
+   D.ietf-tls-rsa-aes-gcm]. 
+
+8. References 
+
+8.1. Normative References 
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
+             Requirement Levels", BCP 14, RFC 2119, March 1997. 
+
+   [I-D.ietf-tls-rfc4346-bis] 
+             Dierks, T. and E. Rescorla, "The Transport Layer Security 
+             (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-
+             10, work in progress, March 2008. 
+
+   [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 
+             Encryption", RFC 5116, January 2008.  
+
+   [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 
+             for Transport Layer Security (TLS)", RFC 4279, December 
+             2005.  
+
+ 
+ 
+Badra                 Expires September 29, 2008               [Page 8] 
+
+Internet-Draft       TLS PSK New MAC and AES-GCM             March 2008 
+    
+
+   [RFC4785] Blumenthal, U., Goel, P., "Pre-Shared Key (PSK) 
+             Ciphersuites with NULL Encryption for Transport Layer 
+             Security (TLS)", RFC 4785, January 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, November 2007. 
+
+8.2. Informative References 
+
+   [Wang05]  Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 
+             Full SHA-1", CRYPTO 2005, August 2005. 
+
+   [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 
+             Security", RFC 4347, April 2006. 
+
+   [I-D.ietf-tls-ecc-new-mac] 
+             Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
+             256/384 and AES Galois Counter  Mode", draft-ietf-tls-ecc-
+             new-mac-04 (work in progress), February 2008. 
+
+   [I-D.ietf-tls-rsa-aes-gcm] 
+             Salowey, J., A. Choudhury, and C. McGrew, "RSA based AES-
+             GCM Cipher Suites for TLS", draft-ietf-tls-rsa-aes-gcm-02 
+             (work in progress), February 2008. 
+
+Author's Addresses 
+
+   Mohamad Badra 
+   LIMOS Laboratory - UMR6158, CNRS 
+   France 
+    
+   Email: badra@isima.fr 
+    
+
+ 
+ 
+Badra                 Expires September 29, 2008               [Page 9] 
+
+Internet-Draft       TLS PSK New MAC and AES-GCM             March 2008 
+    
+
+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, 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. 
+
+Copyright Statement 
+
+   Copyright (C) The IETF Trust (2008). 
+
+   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. 
+ 
+ 
+Badra                 Expires September 29, 2008              [Page 10] 
+