doc/protocol/draft-otto-tls-sigma-ciphersuite-00.txt

   1
   2
   3
   4 TLS Working Group                                                T. Otto
   5 Internet-Draft                                            April 27, 2007
   6 Intended status: Standards Track
   7 Expires: October 29, 2007
   8
   9
  10                   A Privacy-enhancing TLS ciphersuite
  11                 draft-otto-tls-sigma-ciphersuite-00.txt
  12
  13 Status of this Memo
  14
  15    By submitting this Internet-Draft, each author represents that any
  16    applicable patent or other IPR claims of which he or she is aware
  17    have been or will be disclosed, and any of which he or she becomes
  18    aware will be disclosed, in accordance with Section 6 of BCP 79.
  19
  20    Internet-Drafts are working documents of the Internet Engineering
  21    Task Force (IETF), its areas, and its working groups.  Note that
  22    other groups may also distribute working documents as Internet-
  23    Drafts.
  24
  25    Internet-Drafts are draft documents valid for a maximum of six months
  26    and may be updated, replaced, or obsoleted by other documents at any
  27    time.  It is inappropriate to use Internet-Drafts as reference
  28    material or to cite them other than as "work in progress."
  29
  30    The list of current Internet-Drafts can be accessed at
  31    http://www.ietf.org/ietf/1id-abstracts.txt.
  32
  33    The list of Internet-Draft Shadow Directories can be accessed at
  34    http://www.ietf.org/shadow.html.
  35
  36    This Internet-Draft will expire on October 29, 2007.
  37
  38 Copyright Notice
  39
  40    Copyright (C) The IETF Trust (2007).
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55 Otto                    Expires October 29, 2007                [Page 1]
  56 \f
  57 Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
  58
  59
  60 Abstract
  61
  62    This document describes a TLS ciphersuite which is based on the SIGMA
  63    protocol.  By its careful adoption in the TLS handshake protocol, the
  64    proposed ciphersuite is able to inherit features of the SIGMA
  65    protocol.  The ciphersuite provides active identity protection,
  66    forward secrecy, deniability and adjustable security strength.  A
  67    similar ciphersuite offering these features has not yet been proposed
  68    so far.
  69
  70
  71 Table of Contents
  72
  73    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  74      1.1.  TLS and its handshake protocol . . . . . . . . . . . . . .  4
  75      1.2.  The SIGMA protocol . . . . . . . . . . . . . . . . . . . .  5
  76      1.3.  Requirements notation  . . . . . . . . . . . . . . . . . .  6
  77      1.4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
  78    2.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  8
  79    3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
  80    4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
  81    5.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
  82    6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
  83      6.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
  84      6.2.  Informative References . . . . . . . . . . . . . . . . . . 13
  85    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
  86    Intellectual Property and Copyright Statements . . . . . . . . . . 15
  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 Otto                    Expires October 29, 2007                [Page 2]
 112 \f
 113 Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
 114
 115
 116 1.  Introduction
 117
 118    This document specifies such a new ciphersuite, which encapsulates
 119    the SIGMA protocol [SIGMA] into the TLS handshake messages and
 120    therefore inherits its valueable features.  Further information about
 121    SIGMA can be found on the author's website, which is
 122    http://www.ee.technion.ac.il/~hugo/sigma.html
 123
 124    In the remainder of this document, we use the term TLS-SIGMA for our
 125    proposal.
 126
 127    TLS-SIGMA offers
 128
 129    Forward Secrecy:
 130
 131       This is achieved by the authenticated Diffie-Hellman key exchange
 132       which is the cryptographic core of the SIGMA protocol.
 133
 134    Adjustability:
 135
 136       The cryptographic strength is determined by the choice of the
 137       Diffie-Hellman group.  We call this feature adjustable security
 138       strength.
 139
 140    Active Identity Protection:
 141
 142       The Identity of the Client is protected against active attacks.
 143       This is achieved because the server autenticates prior to the
 144       client.  Only if the client could identity the server properly, he
 145       sends his identity.
 146
 147    Deniability:
 148
 149       In contrast to many other ciphersuites, the conversation between
 150       client and server is deniable, in the sense, that by carrying out
 151       the TLS-SIGMA handshake, there exists no proof for the server
 152       having talked to the client, at least none which can withstand at
 153       a court, and vice versa.
 154
 155
 156    One might argue that there already exist numerous TLS ciphersuites
 157    with a DH key exchange, for example TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
 158    and ask where the particular advantages of this ciphersuite are.
 159
 160    The crucial point is that with RSA as key exchange mechanism and the
 161    mutual authentication case, the client computes in CertificateVerify
 162    a signature over all handshake messages (see Section 7.4.8 of
 163    [RFC2246]), that is
 164
 165
 166
 167 Otto                    Expires October 29, 2007                [Page 3]
 168 \f
 169 Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
 170
 171
 172    CertificateVerify = SIG(Client; g^x, g^y, CertServer, CertClient)
 173
 174    and thus provides an undeniable proof that the conversation has taken
 175    place.
 176
 177 1.1.  TLS and its handshake protocol
 178
 179    TLS has its origin in the SSL protocol developed by Netscape
 180    Communications in early 1990s.  In the meantime, it became the major
 181    protocol to establish a cryptographially protected context between
 182    two communicating parties.
 183
 184    One of the most valuable features of TLS is its flexibility in that
 185    initially, both sides agree on a set of cryptographic algorithms, a
 186    so-called ciphersuite.  Such a ciphersuite comprises an algorithm for
 187    authentiation and key exchange, a stream or block cipher for bulk
 188    encryption and finally, an algorithm for hashing.
 189
 190    While SSL realized this flexibility by a complicated negotiation, TLS
 191    has facilitated the procedure, in that the client sends the server
 192    all his supported ciphersuites, whereafter the server selects one of
 193    them according to his policy or aborts the protocol, if none suitable
 194    is among them.
 195
 196    TLS is designed having addition of further ciphersuites in mind.
 197
 198    The TLS handshake protocol's main intention is to
 199
 200    o  negotiate certain session parameters,
 201
 202    o  authenticate the server to the client, and optionally, the client
 203       to the server and
 204
 205    o  establish a shared cryptographic secret.
 206
 207    If the handshake has finished successfully, a cryptographically
 208    protected channel is established between the two parties, which can
 209    be used to exchange securely further data.  The message flow of the
 210    TLS handshake protocol is shown the following figure.
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223 Otto                    Expires October 29, 2007                [Page 4]
 224 \f
 225 Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
 226
 227
 228          Client                                               Server
 229          ------                                               ------
 230
 231    (1)   ClientHello                -------->
 232                                                          ServerHello
 233    (2)                                                 (Certificate)
 234                                                    ServerKeyExchange
 235                                                 (CertificateRequest)
 236                                     <--------        ServerHelloDone
 237    (3)   (Certificate)
 238          ClientKeyExchange
 239          (CertificateVerify)
 240          ChangeCipherSpec
 241          Finished                   -------->
 242    (4)                                              ChangeCipherSpec
 243                                     <--------               Finished
 244
 245
 246
 247                           Figure 1: TLS handshake
 248
 249 1.2.  The SIGMA protocol
 250
 251    SIGMA is a family of cryptographic key-exchange protocols that
 252    provide perfect forward secrecy via a Diffie-Hellman exchange
 253    authenticated with digital signatures.  It has been proposed already
 254    in 1995.  It has gained many popularity by building the cryptographic
 255    basis for the signature-based modes of IKE and IKEv2.
 256
 257    The protocol has very valuable features which motivated us to
 258    incorporate it into TLS.
 259
 260    The SIGMA specification offers two subprotocols, SIGMA-I and SIGMA-R,
 261    where I and R stand for Intiator and Responder.  SIGMA-I is a three-
 262    message protocol and provides active identity protection for the
 263    initiator, while SIGMA-R consists of four messages and provides
 264    active identity protection for the responder.  Obviously, only the
 265    SIGMA-I seems to be suitable to be built-in in TLS, so that we
 266    restricts on it in the following.
 267
 268    Figure Figure 2 depicts the message flow of SIGMA-I.
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279 Otto                    Expires October 29, 2007                [Page 5]
 280 \f
 281 Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
 282
 283
 284     A                                                          B
 285     |                         g^x                              |
 286     |--------------------------------------------------------->|
 287     |                                                          |
 288     |     g^y, ENC (Ke; B, SIG(B; g^x,g^y), MAC(Km; B) )       |
 289     |<---------------------------------------------------------|
 290     |                                                          |
 291     |          ENC (Ke; A, SIG(A; g^y,g^x), MAC(Km; A) )       |
 292     |--------------------------------------------------------->|
 293
 294                              Figure 2: SIGMA-I
 295
 296    The SIGMA specification allows to replace the peer's exponential by a
 297    nonce, but we omit this modification.  The protocol derives Ke, Km
 298    and a session key Ks from the Diffie-Hellman shared key, but they
 299    have to be computationally independent.  On page 20 of [SIGMA] the
 300    refinement to add some sense of direction to the MAC, i.e. we replace
 301    MAC(Km;A) MAC(Km; "0",A) and MAC(Km;B) by MAC(Km; "1",B).
 302
 303    Finally, we replace (according to the rationale on page 21 of
 304    [SIGMA]) the pair (SIG(B; g^x,g^y), MAC(Km; B)) by SIG(B; MAC(Km;
 305    g^x,g^y,B))) and vice versa for the pair (SIG(A; g^y,g^x), MAC(Km;
 306    A)).
 307
 308    The terminology does not deviate too much from existing work.  The
 309    semantic is as follows.  ENC(K;X) stands for encryption of X with key
 310    K. g^x and g^y are Diffie-Hellman keys.  SIG(A;X) stands for A's
 311    signature on the content X. MAC (K;X) stands for computing a MAC over
 312    X keyed by K.
 313
 314    Ke and Km are derived from the Diffie-Hellman shared secret g^(xy)
 315    through a PRF, while they must be cryptographically independent.
 316
 317 1.3.  Requirements notation
 318
 319    In this document, several words are used to signify the requirements
 320    of the specification.  The key words "MUST", "MUST NOT", "REQUIRED",
 321    "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
 322    and "OPTIONAL" in this document are to be interpreted as described in
 323    [RFC2119].
 324
 325 1.4.  Terminology
 326
 327    This document frequently uses the following terms:
 328
 329
 330
 331
 332
 333
 334
 335 Otto                    Expires October 29, 2007                [Page 6]
 336 \f
 337 Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
 338
 339
 340    client:
 341
 342        One side of the connection.
 343
 344    server:
 345
 346        The other side of the connection.
 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 Otto                    Expires October 29, 2007                [Page 7]
 392 \f
 393 Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
 394
 395
 396 2.  Protocol Overview
 397
 398    This section describes how SIGMA-I is built in the TLS handshake
 399    protocol.  Specifying a new ciphersuite means to re-define the
 400    semantic or content of existing handshake messages or to add
 401    extensions to the initial Hello exchange.
 402
 403    SIGMA-I fits perfectly in the message flow, if the client takes the
 404    role of the initiator, and the server of the responder.
 405
 406    First, the client sends in an extension of the TLS ClientHello his
 407    Diffie-Hellman public key g^x to the server, together with the DH
 408    group he desires.  Possible choices are the prime groups defined in
 409    IKEv2 [RFC4306] or in [RFC3546].  Table Figure 3 summarizes the
 410    choices.
 411
 412    +--------------------+------+-------------+
 413    | DH group specifier | bits | defined in  |
 414    +--------------------+------+-------------+
 415    | 0x0001             |  768 | RFC 4306    |
 416    +--------------------+------+-------------+
 417    | 0x0002             | 1024 | RFC 4306    |
 418    +--------------------+------+-------------+
 419    | 0x0003             | 1536 | RFC 3546    |
 420    +--------------------+------+-------------+
 421    | 0x0004             | 2048 | RFC 3546    |
 422    +--------------------+------+-------------+
 423    | 0x0005             | 3072 | RFC 3546    |
 424    +--------------------+------+-------------+
 425    | 0x0006             | 4096 | RFC 3546    |
 426    +--------------------+------+-------------+
 427
 428                             Figure 3: DH groups
 429
 430    The server then verifies whether the selected / proposed DH group is
 431    accceptable.  If no, the TLS handshake fails and the server sends a
 432    corresponding message to the client.  Otherwise, the server selects a
 433    private key y, computes g^y and sends this parameter in an extension
 434    of the ServerHello back.  The Certificate message contains the
 435    server's certificate (which corresponds to the identity B in the
 436    SIGMA-I message flow), ServerkeyExchange contains the encrypted
 437    signature and hash according to message 2 in Figure X.
 438
 439    Both sides are now able to compute the premaster secret.  The server
 440    computes SK = (g^x)^y, the client computes SK = (g^y)^x.  The master
 441    secret and keyblock are derived as specified in TLS v1.0.
 442
 443    The client sends now in the Certificate message his certificate
 444
 445
 446
 447 Otto                    Expires October 29, 2007                [Page 8]
 448 \f
 449 Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
 450
 451
 452    (which corresponds to the identity A in the SIGMA-I message flow),
 453    and in ClientKeyExchange the encrypted signature and MAC, according
 454    to message 3 in Figure Figure 2.  The CertificateVerify message is
 455    not sent.  For RSA ciphersuites, this message would contain a
 456    signature over all previously exchanged handshake messages.  Applying
 457    this signature would destroy SIGMA's properties.
 458
 459    According to the rationale above, we show the message flow for TLS-
 460    SIGMA :
 461
 462
 463          Client (A)                                           Server (B)
 464          ------                                               ------
 465
 466    (1)   ClientHello (g^x)          -------->
 467                                                       ServerHello (g^y)
 468    (2)                                                  Certificate (B)
 469
 470                                                       ServerKeyExchange
 471                                     ENC(Ke; SIG(B; MAC(Km; g^x,g^y,B)))
 472
 473                                     <--------           ServerHelloDone
 474    (3)
 475          ClientKeyExchange
 476          ENC(Ke; SIG( A; MAC(Km; g^y,g^x,A)))
 477
 478          ChangeCipherSpec
 479          Finished                   -------->
 480    (4)                                                 ChangeCipherSpec
 481                                     <--------                  Finished
 482
 483
 484
 485                       Figure 4: TLS-SIGMA ciphersuite
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503 Otto                    Expires October 29, 2007                [Page 9]
 504 \f
 505 Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
 506
 507
 508 3.  IANA Considerations
 509
 510    -TBD-
 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 Otto                    Expires October 29, 2007               [Page 10]
 560 \f
 561 Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
 562
 563
 564 4.  Security Considerations
 565
 566    -TBD-
 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 Otto                    Expires October 29, 2007               [Page 11]
 616 \f
 617 Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
 618
 619
 620 5.  Acknowledgments
 621
 622    Add your name here.
 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 Otto                    Expires October 29, 2007               [Page 12]
 672 \f
 673 Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
 674
 675
 676 6.  References
 677
 678 6.1.  Normative References
 679
 680    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 681               Requirement Levels", BCP 14, RFC 2119, March 1997.
 682
 683    [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
 684               Levkowetz, "Extensible Authentication Protocol (EAP)",
 685               RFC 3748, June 2004.
 686
 687 6.2.  Informative References
 688
 689    [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
 690               RFC 2246, January 1999.
 691
 692    [RFC2407]  Piper, D., "The Internet IP Security Domain of
 693               Interpretation for ISAKMP", RFC 2407, November 1998.
 694
 695    [RFC2408]  Maughan, D., Schneider, M., and M. Schertler, "Internet
 696               Security Association and Key Management Protocol
 697               (ISAKMP)", RFC 2408, November 1998.
 698
 699    [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
 700               (IKE)", RFC 2409, November 1998.
 701
 702    [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
 703               Diffie-Hellman groups for Internet Key Exchange (IKE)",
 704               RFC 3526, May 2003.
 705
 706    [RFC3546]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
 707               and T. Wright, "Transport Layer Security (TLS)
 708               Extensions", RFC 3546, June 2003.
 709
 710    [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
 711               RFC 4306, December 2005.
 712
 713    [SIGMA]    Hugo Krawczyk, "SIGMA: the 'SIGn-and-MAc' Approach to
 714               Authenticated Diffie-Hellman and its Use in the IKE
 715               Protocols", Springer LNCS Advances in Cryptography -
 716               CRYPTO 2003 Proceedings, LNCS 2729, 2003.
 717
 718    [TLSPSK-Perf]
 719               Mario Di Raimondo, Rosario Gennaro, Hugo Krawczyk,
 720               "Deniable Authentication and Key Exchange.", CCS 06
 721               (Conference on Computer and Communications Security) URL:
 722               , October 2006.
 723
 724
 725
 726
 727 Otto                    Expires October 29, 2007               [Page 13]
 728 \f
 729 Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
 730
 731
 732 Author's Address
 733
 734    Thomas Otto
 735    Germany
 736
 737    Email: t.otto@tu-bs.de
 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 Otto                    Expires October 29, 2007               [Page 14]
 784 \f
 785 Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
 786
 787
 788 Full Copyright Statement
 789
 790    Copyright (C) The IETF Trust (2007).
 791
 792    This document is subject to the rights, licenses and restrictions
 793    contained in BCP 78, and except as set forth therein, the authors
 794    retain all their rights.
 795
 796    This document and the information contained herein are provided on an
 797    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 798    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 799    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 800    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 801    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 802    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 803
 804
 805 Intellectual Property
 806
 807    The IETF takes no position regarding the validity or scope of any
 808    Intellectual Property Rights or other rights that might be claimed to
 809    pertain to the implementation or use of the technology described in
 810    this document or the extent to which any license under such rights
 811    might or might not be available; nor does it represent that it has
 812    made any independent effort to identify any such rights.  Information
 813    on the procedures with respect to rights in RFC documents can be
 814    found in BCP 78 and BCP 79.
 815
 816    Copies of IPR disclosures made to the IETF Secretariat and any
 817    assurances of licenses to be made available, or the result of an
 818    attempt made to obtain a general license or permission for the use of
 819    such proprietary rights by implementers or users of this
 820    specification can be obtained from the IETF on-line IPR repository at
 821    http://www.ietf.org/ipr.
 822
 823    The IETF invites any interested party to bring to its attention any
 824    copyrights, patents or patent applications, or other proprietary
 825    rights that may cover technology that may be required to implement
 826    this standard.  Please address the information to the IETF at
 827    ietf-ipr@ietf.org.
 828
 829
 830 Acknowledgment
 831
 832    Funding for the RFC Editor function is provided by the IETF
 833    Administrative Support Activity (IASA).
 834
 835
 836
 837
 838
 839 Otto                    Expires October 29, 2007               [Page 15]
 840 \f