summaryrefslogtreecommitdiff
path: root/doc/protocol/draft-ietf-tls-psk-05.txt
blob: a9e5403564409fc1a8a079e94b76ab13524dcdce (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900


TLS Working Group                                         P. Eronen, Ed.
Internet-Draft                                                     Nokia
Expires: June 17, 2005                                H. Tschofenig, Ed.
                                                                 Siemens
                                                       December 17, 2004


     Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
                       draft-ietf-tls-psk-05.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

   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 17, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document specifies three sets of new ciphersuites for the
   Transport Layer Security (TLS) protocol to support authentication
   based on pre-shared keys.  These pre-shared keys are symmetric keys,
   shared in advance among the communicating parties.  The first set of
   ciphersuites uses only symmetric key operations for authentication.
   The second set uses a Diffie-Hellman exchange authenticated with a
   pre-shared key; and the third set combines public key authentication
   of the server with pre-shared key authentication of the client.




Eronen & Tschofenig       Expires June 17, 2005                 [Page 1]

Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004


1.  Introduction

   Usually TLS uses public key certificates [3] or Kerberos [12] for
   authentication.  This document describes how to use symmetric keys
   (later called pre-shared keys or PSKs), shared in advance among the
   communicating parties, to establish a TLS connection.

   There are basically two reasons why one might want to do this:

   o  First, TLS may be used in performance-constrained environments
      where the CPU power needed for public key operations is not
      available.

   o  Second, pre-shared keys may be more convenient from a key
      management point of view.  For instance, in closed environments
      where the connections are mostly configured manually in advance,
      it may be easier to configure a PSK than to use certificates.
      Another case is when the parties already have a mechanism for
      setting up a shared secret key, and that mechanism could be used
      to "bootstrap" a key for authenticating a TLS connection.

   This document specifies three sets of new ciphersuites for TLS.
   These ciphersuites use new key exchange algorithms, and re-use
   existing cipher and MAC algorithms from [3] and [2].  A summary of
   these ciphersuites is shown below.

      CipherSuite                        Key Exchange  Cipher       Hash

      TLS_PSK_WITH_RC4_128_SHA           PSK           RC4_128       SHA
      TLS_PSK_WITH_3DES_EDE_CBC_SHA      PSK           3DES_EDE_CBC  SHA
      TLS_PSK_WITH_AES_128_CBC_SHA       PSK           AES_128_CBC   SHA
      TLS_PSK_WITH_AES_256_CBC_SHA       PSK           AES_256_CBC   SHA
      TLS_DHE_PSK_WITH_RC4_128_SHA       DHE_PSK       RC4_128       SHA
      TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA  DHE_PSK       3DES_EDE_CBC  SHA
      TLS_DHE_PSK_WITH_AES_128_CBC_SHA   DHE_PSK       AES_128_CBC   SHA
      TLS_DHE_PSK_WITH_AES_256_CBC_SHA   DHE_PSK       AES_256_CBC   SHA
      TLS_RSA_PSK_WITH_RC4_128_SHA       RSA_PSK       RC4_128       SHA
      TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA  RSA_PSK       3DES_EDE_CBC  SHA
      TLS_RSA_PSK_WITH_AES_128_CBC_SHA   RSA_PSK       AES_128_CBC   SHA
      TLS_RSA_PSK_WITH_AES_256_CBC_SHA   RSA_PSK       AES_256_CBC   SHA

   The first set of ciphersuites (with PSK key exchange algorithm),
   defined in Section 2 use only symmetric key algorithms, and are thus
   especially suitable for performance-constrained environments.

   The ciphersuites in Section 3 (with DHE_PSK key exchange algorithm)
   use a PSK to authenticate a Diffie-Hellman exchange.  These
   ciphersuites protect against dictionary attacks by passive



Eronen & Tschofenig       Expires June 17, 2005                 [Page 2]

Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004


   eavesdroppers (but not active attackers), and also provide Perfect
   Forward Secrecy (PFS).

   The third set of ciphersuites (with RSA_PSK key exchange algorithm),
   defined in Section 4, combine public key based authentication of the
   server (using RSA and certificates) with mutual authentication using
   a PSK.

1.1  Applicability statement

   The ciphersuites defined in this document are intended for a rather
   limited set of applications, usually involving only a very small
   number of clients and servers.  Even in such environments, other
   alternatives may be more appropriate.

   If the main goal is to avoid PKIs, another possibility worth
   considering is to use self-signed certificates with public key
   fingerprints.  Instead of manually configuring a shared secret in,
   for instance, some configuration file, a fingerprint (hash) of the
   other party's public key (or certificate) could be placed there
   instead.

   It is also possible to use the SRP (Secure Remote Password)
   ciphersuites for shared secret authentication [14].  SRP was designed
   to be used with passwords, and incorporates protection against
   dictionary attacks.  However, it is computationally more expensive
   than the PSK ciphersuites in Section 2.

1.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].


















Eronen & Tschofenig       Expires June 17, 2005                 [Page 3]

Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004


2.  PSK key exchange algorithm

   This section defines the PSK key exchange algorithm and associated
   ciphersuites.  These ciphersuites use only symmetric key algorithms.

   It is assumed that the reader is familiar with ordinary TLS
   handshake, shown below.  The elements in parenthesis are not included
   when PSK key exchange algorithm is used, and "*" indicates a
   situation-dependent message that is not always sent.

      Client                                               Server
      ------                                               ------

      ClientHello                  -------->
                                                      ServerHello
                                                    (Certificate)
                                               ServerKeyExchange*
                                             (CertificateRequest)
                                   <--------      ServerHelloDone
      (Certificate)
      ClientKeyExchange
      (CertificateVerify)
      ChangeCipherSpec
      Finished                     -------->
                                                 ChangeCipherSpec
                                   <--------             Finished
      Application Data             <------->     Application Data


   The client indicates its willingness to use pre-shared key
   authentication by including one or more PSK ciphersuites in the
   ClientHello message.  If the TLS server also wants to use pre-shared
   keys, it selects one of the PSK ciphersuites, places the selected
   ciphersuite in the ServerHello message, and includes an appropriate
   ServerKeyExchange message (see below).  The Certificate and
   CertificateRequest payloads are omitted from the response.

   Both clients and servers may have pre-shared keys with several
   different parties.  The client indicates which key to use by
   including a "PSK identity" in the ClientKeyExchange message (note
   that unlike in [7], the session_id field in ClientHello message keeps
   its usual meaning).  To help the client in selecting which identity
   to use, the server can provide a "PSK identity hint" in the
   ServerKeyExchange message.  If no hint is provided, the
   ServerKeyExchange message is omitted.

   It is expected that different types of identities are useful for
   different applications running over TLS.  This document does not



Eronen & Tschofenig       Expires June 17, 2005                 [Page 4]

Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004


   therefore mandate the use of any particular type of identity (such as
   IPv4 address or FQDN) or identity hint; neither is specified how
   exactly the client uses the hint (if it uses it at all).

   To increase the chances for successful interoperation between
   applications that do agree on what type of identity is used, the
   identity MUST be first converted to a character string, and then
   encoded to octets using UTF-8 [5].  For instance,

   o  IPv4 addresses are sent as dotted-decimal strings (e.g.,
      "192.0.1.2"), not as 32-bit integers in network byte order.

   o  Domain names are sent in their usual text form (e.g.,
      "www.example.com" or "embedded\.dot.example.net"), not in DNS
      protocol wire format.

   o  X.500 Distinguished Names are sent in their string representation
      [9], not as BER-encoded ASN.1.

   In situations where the identity is entered by a person, processing
   the character string with an appropriate stringprep [10] profile is
   RECOMMENDED.

   The format of the ServerKeyExchange and ClientKeyExchange messages is
   shown below.

      struct {
          select (KeyExchangeAlgorithm) {
              /* other cases for rsa, diffie_hellman, etc. */
              case psk:  /* NEW */
                  opaque psk_identity_hint<0..2^16-1>;
          };
      } ServerKeyExchange;

      struct {
          select (KeyExchangeAlgorithm) {
              /* other cases for rsa, diffie_hellman, etc. */
              case psk:   /* NEW */
                  opaque psk_identity<0..2^16-1>;
          } exchange_keys;
      } ClientKeyExchange;










Eronen & Tschofenig       Expires June 17, 2005                 [Page 5]

Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004


   The premaster secret is formed as follows: if the PSK is N octets
   long, concatenate an uint16 with the value N, N zero octets, a second
   uint16 with the value N, and the PSK itself.

      Note 1: All the ciphersuites in this document share the same
      general structure for the premaster secret, namely

         struct {
             opaque other_secret<0..2^16-1>;
             opaque psk<0..2^16-1>;
         };

      Here "other_secret" is either zeroes (plain PSK case), or comes
      from the Diffie-Hellman or RSA exchange (DHE_PSK and RSA_PSK,
      respectively).  See Sections 3 and 4 for a more detailed
      description.

      Note 2: Using zeroes for "other_secret" effectively means that
      only the HMAC-SHA1 part (but not the HMAC-MD5 part) of the TLS PRF
      is used when constructing the master secret.  See [8] for a more
      detailed rationale.

   The TLS handshake is authenticated using the Finished messages as
   usual.

   If the server does not recognize the PSK identity, it MAY respond
   with an "unknown_psk_identity" alert message.  Alternatively, if the
   server wishes to hide the fact that the PSK identity was not known,
   it MAY continue the protocol as if the PSK identity existed but the
   key was incorrect: that is, respond with a "decrypt_error" alert.





















Eronen & Tschofenig       Expires June 17, 2005                 [Page 6]

Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004


3.  DHE_PSK key exchange algorithm

   This section defines additional ciphersuites that use a PSK to
   authenticate a Diffie-Hellman exchange.  These ciphersuites give some
   additional protection against dictionary attacks, and also provide
   Perfect Forward Secrecy (PFS).  See Section 6 for discussion of
   related security considerations.

   When these ciphersuites are used, the ServerKeyExchange and
   ClientKeyExchange messages also include the Diffie-Hellman
   parameters.  The PSK identity and identity hint fields have the same
   meaning as in the previous section (note that the ServerKeyExchange
   message is always sent even if no PSK identity hint is provided).

   The format of the ServerKeyExchange and ClientKeyExchange messages is
   shown below.

      struct {
          select (KeyExchangeAlgorithm) {
              /* other cases for rsa, diffie_hellman, etc. */
              case diffie_hellman_psk:  /* NEW */
                  opaque psk_identity_hint<0..2^16-1>;
                  ServerDHParams params;
          };
      } ServerKeyExchange;

      struct {
          select (KeyExchangeAlgorithm) {
              /* other cases for rsa, diffie_hellman, etc. */
              case diffie_hellman_psk:   /* NEW */
                  opaque psk_identity<0..2^16-1>;
                  ClientDiffieHellmanPublic public;
          } exchange_keys;
      } ClientKeyExchange;

   The premaster secret is formed as follows.  Let Z be the value
   produced by the Diffie-Hellman exchange (with leading zero bytes
   stripped as in other Diffie-Hellman based ciphersuites).  Concatenate
   an uint16 containing the length of Z (in octets), Z itself, an uint16
   containing the length of the PSK (in octets), and the PSK itself.

   This corresponds to the general structure for the premaster secrets
   (see Note 1 in Section 2) in this document, with "other_secret"
   containing Z.







Eronen & Tschofenig       Expires June 17, 2005                 [Page 7]

Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004


4.  RSA_PSK key exchange algorithm

   The ciphersuites in this section use RSA and certificates to
   authenticate the server, in addition to using a PSK.

   As in normal RSA ciphersuites, the server must send a Certificate
   message.  The format of the ServerKeyExchange and ClientKeyExchange
   messages is shown below.  If no PSK identity hint is provided, the
   ServerKeyExchange message is omitted.

      struct {
          select (KeyExchangeAlgorithm) {
              /* other cases for rsa, diffie_hellman, etc. */
              case rsa_psk:  /* NEW */
                  opaque psk_identity_hint<0..2^16-1>;
          };
      } ServerKeyExchange;

      struct {
          select (KeyExchangeAlgorithm) {
              /* other cases for rsa, diffie_hellman, etc. */
              case rsa_psk:   /* NEW */
                  opaque psk_identity<0..2^16-1>;
                  EncryptedPreMasterSecret;
          } exchange_keys;
      } ClientKeyExchange;

   The EncryptedPreMasterSecret field sent from the client to the server
   contains a 2-byte version number and a 46-byte random value,
   encrypted using the server's RSA public key as described in Section
   7.4.7.1 of [3].  The actual premaster secret is formed by both
   parties as follows: concatenate an uint16 with the value 48, the
   2-byte version number and the 46-byte random value, an uint16
   containing the length of the PSK (in octets), and the PSK itself.

   This corresponds to the general structure for the premaster secrets
   (see Note 1 in Section 2) in this document, with "other_secret"
   containing both the 2-byte version number and the 46-byte random
   value.

   Neither the normal RSA ciphersuites nor these RSA_PSK ciphersuites
   themselves specify what the certificates contain (in addition to the
   RSA public key), or how the certificates are to be validated.  In
   particular, it is possible to use the RSA_PSK ciphersuites with
   unvalidated self-signed certificates to provide somewhat similar
   protection against dictionary attacks as the DHE_PSK ciphersuites
   defined in Section 3.




Eronen & Tschofenig       Expires June 17, 2005                 [Page 8]

Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004


5.  IANA considerations

   IANA does not currently have a registry for TLS-related numbers, so
   there are no IANA actions associated with this document.

   For easier reference in the future, the ciphersuite numbers defined
   in this document are summarized below.

      CipherSuite TLS_PSK_WITH_RC4_128_SHA          = { 0x00, 0x8A };
      CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA     = { 0x00, 0x8B };
      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA      = { 0x00, 0x8C };
      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA      = { 0x00, 0x8D };
      CipherSuite TLS_DHE_PSK_WITH_RC4_128_SHA      = { 0x00, 0x8E };
      CipherSuite TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8F };
      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA  = { 0x00, 0x90 };
      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA  = { 0x00, 0x91 };
      CipherSuite TLS_RSA_PSK_WITH_RC4_128_SHA      = { 0x00, 0x92 };
      CipherSuite TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x93 };
      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA  = { 0x00, 0x94 };
      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA  = { 0x00, 0x95 };

   This document also defines a new TLS alert message,
   unknown_psk_identity(115).

6.  Security Considerations

   As with all schemes involving shared keys, special care should be
   taken to protect the shared values and to limit their exposure over
   time.

6.1  Perfect forward secrecy (PFS)

   The PSK and RSA_PSK ciphersuites defined in this document do not
   provide Perfect Forward Secrecy (PFS).  That is, if the shared secret
   key (in PSK ciphersuites), or both the shared secret key and the RSA
   private key (in RSA_PSK ciphersuites), is somehow compromised, an
   attacker can decrypt old conversations.

   The DHE_PSK ciphersuites provide Perfect Forward Secrecy if a fresh
   DH private key is generated for each handshake.

6.2  Brute-force and dictionary attacks

   Use of a fixed shared secret of limited entropy (for example, a PSK
   that is relatively short, or was chosen by a human and thus may
   contain less entropy than its length would imply) may allow an
   attacker to perform a brute-force or dictionary attack to recover the
   secret.  This may be either an off-line attack (against a captured



Eronen & Tschofenig       Expires June 17, 2005                 [Page 9]

Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004


   TLS handshake messages), or an on-line attack where the attacker
   attempts to connect to the server and tries different keys.

   For the PSK ciphersuites, an attacker can get the information
   required for an off-line attack by eavesdropping a TLS handshake, or
   by getting a valid client to attempt connection with the attacker (by
   tricking the client to connect to wrong address, or intercepting a
   connection attempt to the correct address, for instance).

   For the DHE_PSK ciphersuites, an attacker can obtain the information
   by getting a valid client to attempt connection with the attacker.
   Passive eavesdropping alone is not sufficient.

   For the RSA_PSK ciphersuites, only the server (authenticated using
   RSA and certificates) can obtain sufficient information for an
   off-line attack.

   It is RECOMMENDED that implementations that allow the administrator
   to manually configure the PSK also provide a functionality for
   generating a new random PSK, taking [4] into account.

6.3  Identity privacy

   The PSK identity is sent in cleartext.  While using a user name or
   other similar string as the PSK identity is the most straightforward
   option, it may lead to problems in some environments since an
   eavesdropper is able to identify the communicating parties.  Even
   when the identity does not reveal any information itself, reusing the
   same identity over time may eventually allow an attacker to perform
   traffic analysis to identify the parties.  It should be noted that
   this is no worse than client certificates, since they are also sent
   in cleartext.

6.4  Implementation notes

   The implementation notes in [11] about correct implementation and use
   of RSA (including Section 7.4.7.1) and Diffie-Hellman (including
   Appendix F.1.1.3) apply to the DHE_PSK and RSA_PSK ciphersuites as
   well.

7.  Acknowledgments

   The protocol defined in this document is heavily based on work by Tim
   Dierks and Peter Gutmann, and borrows some text from [7] and [2].
   The DHE_PSK and RSA_PSK ciphersuites are based on earlier work in
   [6].

   Valuable feedback was also provided by Philip Ginzboorg, Peter



Eronen & Tschofenig       Expires June 17, 2005                [Page 10]

Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004


   Gutmann, David Jablon, Nikos Mavroyanopoulos, Bodo Moeller, Eric
   Rescorla, and Mika Tervonen.

   When the first version of this draft was almost ready, the authors
   learned that something similar had been proposed already in 1996
   [13].  However, this draft is not intended for web password
   authentication, but rather for other uses of TLS.

8.  References

8.1  Normative References

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

   [2]   Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
         for Transport Layer Security (TLS)", RFC 3268, June 2002.

   [3]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
         2246, January 1999.

   [4]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness
         Recommendations for Security", RFC 1750, December 1994.

   [5]   Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
         3629, November 2003.

8.2  Informative References

   [6]   Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni,
         "Pre-Shared-Key key Exchange methods for TLS",
         draft-badra-tls-key-exchange-00 (work in progress), August
         2004.

   [7]   Gutmann, P., "Use of Shared Keys in the TLS Protocol",
         draft-ietf-tls-sharedkeys-02 (expired), October 2003.

   [8]   Krawczyk, H., "Re: TLS shared keys PRF",  message on
         ietf-tls@lists.certicom.com mailing list 2004-01-13,
         http://www.imc.org/ietf-tls/mail-archive/msg04098.html.

   [9]   Zeilenga, K., "LDAP: String Representation of Distinguished
         Names", draft-ietf-ldapbis-dn-15 (work in progress), October
         2004.

   [10]  Hoffman, P. and M. Blanchet, "Preparation of Internationalized
         Strings ("stringprep")", RFC 3454, December 2002.




Eronen & Tschofenig       Expires June 17, 2005                [Page 11]

Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004


   [11]  Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1",
         draft-ietf-tls-rfc2246-bis-09 (work in progress), December
         2004.

   [12]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites
         to Transport Layer Security (TLS)", RFC 2712, October 1999.

   [13]  Simon, D., "Addition of Shared Key Authentication to Transport
         Layer Security (TLS)",  draft-ietf-tls-passauth-00 (expired),
         November 1996.

   [14]  Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin, "Using
         SRP for TLS Authentication", draft-ietf-tls-srp-08 (work in
         progress), August 2004.





































Eronen & Tschofenig       Expires June 17, 2005                [Page 12]

Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004


Authors' and Contributors' Addresses

   Pasi Eronen
   Nokia Research Center
   P.O. Box 407
   FIN-00045 Nokia Group
   Finland
   Email: pasi.eronen@nokia.com


   Hannes Tschofenig
   Siemens
   Otto-Hahn-Ring 6
   Munich, Bayern  81739
   Germany
   Email: Hannes.Tschofenig@siemens.com


   Mohamad Badra
   ENST Telecom
   46 rue Barrault
   75634 Paris
   France
   Email: Mohamad.Badra@enst.fr


   Omar Cherkaoui
   UQAM University
   Montreal (Quebec)
   Canada
   Email: cherkaoui.omar@uqam.ca


   Ibrahim Hajjeh
   ENST Telecom
   46 rue Barrault
   75634 Paris
   France
   Email: Ibrahim.Hajjeh@enst.fr


   Ahmed Serhrouchni
   ENST Telecom
   46 rue Barrault
   75634 Paris
   France
   Email: Ahmed.Serhrouchni@enst.fr




Eronen & Tschofenig       Expires June 17, 2005                [Page 13]

Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004


Appendix A.  Changelog

   (This section should be removed by the RFC Editor before
   publication.)

   Changes from -04 to -05:

   o  Omit ServerKeyExchange message (in PSK/RSA_PSK versions) if no
      identity hint is provided.

   Changes from -03 to -04:

   o  Added a note about premaster secret "general structure" in
      Sections 3 and 4.

   o  Something in the I-D submission procedure had removed all
         circumflexes from -03 version, turning e.g. "2^16" (two-to-
         the sixteenth power) to "216" (two hundred and sixteen).
         Let's try again.

   Changes from -02 to -03:

   o  Aligned the way the premaster secret is derived.

   o  Specified that identities must be sent as human-readable UTF-8
      strings, not in binary formats.  Changed reference to RFC 3629
      from informative to normative.

   o  Selected ciphersuite and alert numbers, and updated IANA
      considerations section to match this.

   o  Reworded some text about dictionary attacks in Section 6.2.

   Changes from -01 to -02:

   o  Clarified text about DHE_PSK ciphersuites in Section 1.

   o  Clarified explanation of HMAC-SHA1/MD5 use of PRF in Section 2.

   o  Added note about certificate validation and self-signed
      certificates in Section 4.

   o  Added Mohamad Badra et al. as contributors.

   Changes from draft-ietf-tls-psk-00 to -01:

   o  Added DHE_PSK and RSA_PSK key exchange algorithms, and updated
      other text accordingly



Eronen & Tschofenig       Expires June 17, 2005                [Page 14]

Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004


   o  Removed SHA-1 hash from PSK key exchange premaster secret
      construction (since premaster secret doesn't need to be 48 bytes).

   o  Added unknown_psk_identity alert message.

   o  Updated IANA considerations section.

   Changes from draft-eronen-tls-psk-00 to draft-ietf-tls-psk-00:

   o  Updated dictionary attack considerations based on comments from
      David Jablon.

   o  Added a recommendation about using UTF-8 in the identity field.

   o  Removed Appendix A comparing this document with
      draft-ietf-tls-sharedkeys-02.

   o  Removed IPR comment about SPR.

   o  Minor editorial changes.































Eronen & Tschofenig       Expires June 17, 2005                [Page 15]

Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004


Intellectual Property Statement

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

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

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


Disclaimer of Validity

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


Copyright Statement

   Copyright (C) The Internet Society (2004).  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.




Eronen & Tschofenig       Expires June 17, 2005                [Page 16]