doc/protocol/draft-santesson-tls-ume-04.txt

   1
   2
   3
   4
   5 INTERNET-DRAFT                                  S. Santesson (Microsoft)
   6 Updates: 2246, 4346 (once approved)             A. Medvinsky (Microsoft)
   7 Intended Category: Standards track                   J. Ball (Microsoft)
   8 Expires September 2006                                        March 2006
   9
  10
  11                        TLS User Mapping Extension
  12                     <draft-santesson-tls-ume-04.txt>
  13
  14
  15 Status of this Memo
  16
  17    By submitting this Internet-Draft, each author represents that any
  18    applicable patent or other IPR claims of which he or she is aware
  19    have been or will be disclosed, and any of which he or she becomes
  20    aware will be disclosed, in accordance with Section 6 of BCP 79.
  21
  22    Internet-Drafts are working documents of the Internet Engineering
  23    Task Force (IETF), its areas, and its working groups.  Note that
  24    other groups may also distribute working documents as Internet-
  25    Drafts.
  26
  27    Internet-Drafts are draft documents valid for a maximum of six months
  28    and may be updated, replaced, or obsoleted by other documents at any
  29    time.  It is inappropriate to use Internet-Drafts as reference
  30    material or to cite them other than a "work in progress."
  31
  32    The list of current Internet-Drafts can be accessed at
  33    http://www.ietf.org/1id-abstracts.html
  34
  35    The list of Internet-Draft Shadow Directories can be accessed at
  36    http://www.ietf.org/shadow.html
  37
  38
  39 Abstract
  40
  41    This document specifies a TLS extension that enables clients to send
  42    generic user mapping data in a supplemental data handshake message
  43    defined in RFC TBD. One such mapping is defined, the UpnDomainHint,
  44    which may be used by a server to locate a user in a directory
  45    database. Other mappings may be defined in other documents in the
  46    future.
  47
  48    (NOTE TO RFC EDITOR:  Replace "RFC TBD" with the RFC number assigned
  49    to draft-santesson-tls-supp-00.txt)
  50
  51
  52
  53
  54
  55
  56 Santesson, et. all                                              [Page 1]
  57 \f
  58 INTERNET DRAFT         TLS User Mapping extension             March 2006
  59
  60
  61 Table of Contents
  62
  63    1  Introduction ................................................    2
  64    2  User mapping extension ......................................    3
  65    3  User mapping handshake exchange .............................    4
  66    4  Message flow ................................................    7
  67    5  Security Considerations .....................................    8
  68    6  References ..................................................    9
  69    7 IANA Considerations ... ......................................    9
  70    Authors' Addresses .............................................   10
  71    Acknowledgements ...............................................   10
  72    Disclaimer .....................................................   11
  73    Copyright Statement ............................................   11
  74
  75 1.  Introduction
  76
  77    This specification defines a TLS extension and a payload for the
  78    SupplementalData handshake message, defined in RFC TBD [N6], to
  79    accommodate mapping of users to their user accounts when using TLS
  80    client authentication as the authentication method.
  81
  82    The UPN (User Principal Name) is a name form defined by Microsoft
  83    which specifies a user's entry in a directory in the form of
  84    userName@domainName.  Traditionally Microsoft has relied on such UPN
  85    names to be present in the client certificate when logging on to a
  86    domain account.
  87
  88    This has however several drawbacks since it prevents the use of
  89    certificates with an absent UPN and also requires re-issuance of
  90    certificates or issuance of multiple certificates to reflect account
  91    changes or creation of new accounts.
  92
  93    The TLS extension defined in this document provide a significant
  94    improvement to this situation as it allows a single certificate to be
  95    mapped to one or more accounts of the user and does not require the
  96    certificate to contain a UPN.
  97
  98    The new TLS extension (user_mapping) is sent in the client hello
  99    message. Per convention defined in RFC 4366 [N4], the server places
 100    the same extension (user_mapping) in the server hello message, to
 101    inform the client that the server understands this extension. If the
 102    server does not understand the extension, it will respond with a
 103    server hello omitting this extension and the client will proceed as
 104    normal, ignoring the extension, and not include the
 105    UserMappingDataList data in the TLS handshake.
 106
 107    If the new extension is understood, the client will inject
 108    UserMappingDataList data in the SupplementalData handshake message
 109
 110
 111
 112 Santesson, et. all                                              [Page 2]
 113 \f
 114 INTERNET DRAFT         TLS User Mapping extension             March 2006
 115
 116
 117    prior to the Client's Certificate message. The server will then parse
 118    this message, extracting the client's domain, and store it in the
 119    context for use when mapping the certificate to the user's directory
 120    account.
 121
 122    No other modifications to the protocol are required. The messages are
 123    detailed in the following sections.
 124
 125
 126 1.1  Terminology
 127
 128    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 129    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 130    document are to be interpreted as described in RFC 2119 [STDWORDS].
 131
 132    The syntax for the TLS User Mapping extension is defined using the
 133    TLS Presentation Language, which is specified in Section 4 of [N2].
 134
 135 1.2  Design considerations
 136
 137    The reason the mapping data itself is not placed in the extension
 138    portion of the client hello is to prevent broadcasting this
 139    information to servers that don't understand the extension.
 140    Additionally, if mapping information were to be considered
 141    confidential, the addition of a new user mapping message type could
 142    allow the data to be encrypted using the server's public key.
 143
 144
 145 2  User mapping extension
 146
 147    A new extension type (user_mapping(TBD)) is added to the Extension
 148    used in both the client hello and server hello messages. The
 149    extension type is specified as follows.
 150
 151
 152       enum {
 153            user_mapping(TBD), (65535)
 154       } ExtensionType;
 155
 156    The "extension_data" field of this extension SHALL contain
 157    "UserMappingTypeList" with a list of supported hint types where:
 158
 159       struct {
 160             UserMappingType user_mapping_types<1..2^8-1>
 161       } UserMappingTypeList;
 162
 163    Enumeration of hint types (user_mapping_types) defined in this
 164    document is provided in section 3.
 165
 166
 167
 168 Santesson, et. all                                              [Page 3]
 169 \f
 170 INTERNET DRAFT         TLS User Mapping extension             March 2006
 171
 172
 173    The list of user_mapping_types included in a client hello SHALL
 174    signal the hint types supported by the client. The list of
 175    user_mapping_types included in the server hello SHALL signal the hint
 176    types preferred by the server.
 177
 178    If none of the hint types listed by the client is supported by the
 179    server, the server SHALL omit the user_mapping extension in the
 180    server hello.
 181
 182    When the user_mapping extension is included in the server hello, the
 183    list of hint types in "UserMappingTypeList" SHALL be either equal to,
 184    or a subset of, the list provided by the client.
 185
 186 3  User mapping handshake exchange
 187
 188    The underlying structure of the SupplementalData handshake message,
 189    used to carry information defined in this section, is defined in RFC
 190    TBD [N6].
 191
 192    A new SupplementalDataType [N6] is defined to accommodate
 193    communication of generic user mapping data. See RFC 2246 (TLS 1.0)
 194    [N2] and RFC 4346 (TLS 1.1) [N3] for other handshake types.
 195
 196    The information in this data type carries one or more unauthenticated
 197    hints, UserMappingDataList, inserted by the client side. Upon receipt
 198    and successful completion of the TLS handshake, the server MAY use
 199    this hint to locate the user's account from which user information
 200    and credentials MAY be retrieved to support authentication based on
 201    the client certificate.
 202
 203
 204       struct {
 205             SupplementalDataType supp_data_type;
 206             select(SupplementalDataType) {
 207                case user_mapping_data: UserMappingDataList;
 208                }
 209       } SupplementalDataEntry;
 210
 211       enum {
 212             user_mapping_data(TBD), (65535)
 213       } SupplementalDataType;
 214
 215
 216    The user_mapping_data(n) enumeration results in a new supplemental
 217    data type UserMappingDataList with the following structure:
 218
 219
 220       enum {
 221
 222
 223
 224 Santesson, et. all                                              [Page 4]
 225 \f
 226 INTERNET DRAFT         TLS User Mapping extension             March 2006
 227
 228
 229              upn_domain_hint(0), (255)
 230       } UserMappingType;
 231
 232       struct {
 233              opaque user_principal_name<0..2^16-1>;
 234              opaque domain_name<0..2^16-1>;
 235       } UpnDomainHint;
 236
 237       struct {
 238              UserMappingType user_mapping_version
 239              select(UserMappingType) {
 240                    case upn_domain_hint:
 241                         UpnDomainHint;
 242              }
 243       } UserMappingData;
 244
 245       struct{
 246          UserMappingData user_mapping_data_list<1..2^16-1>;
 247       }UserMappingDataList;
 248
 249
 250    The user_principal_name parameter, when specified, SHALL contain a
 251    Unicode UPN, encoded as a UTF-8 string in the following form:
 252
 253       user@domain
 254
 255    For example the UPN 'foo@example.com' represents user 'foo' at domain
 256    'example.com'.
 257
 258    The domain_name parameter, when specified, SHALL contain a domain
 259    name in the "preferred name syntax," as specified by RFC 1123.
 260
 261    The UpnDomainHint MUST at least contain a non empty
 262    user_principal_name or a non empty domain_name. The UpnDomainHint MAY
 263    contain both user_principal_name and domain_name.
 264
 265    The UserMappingData structure contains a single mapping of type
 266    UserMappingType.  This structure can be leveraged to define new types
 267    of user mapping hints in the future.  The UserMappingDataList MAY
 268    carry multiple hints; it is defined as a vector of UserMappingData
 269    structures.
 270
 271    No preference is given to the order in which hints are specified in
 272    this vector.  If the client sends more then one hint then the Server
 273    SHOULD use the applicable mapping supported by the server.
 274
 275    This document does not specify how the server stores the
 276    user_principal_name, or how exactly it might be used to locate a
 277
 278
 279
 280 Santesson, et. all                                              [Page 5]
 281 \f
 282 INTERNET DRAFT         TLS User Mapping extension             March 2006
 283
 284
 285    certificate.  For instance, it might be appropriate to do a case-
 286    insensitive lookup.  It is RECOMMENDED that the server processes the
 287    user_principal_name with a stringprep profile [N7] appropriate for
 288    the identity in question, such as Nameprep [N8] for the portion
 289    domain portion of UPN, SASLprep [N9] for the user portion of the UPN
 290    and stringprep appendix B.3 [N7] as mapping table for case folding.
 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 Santesson, et. all                                              [Page 6]
 337 \f
 338 INTERNET DRAFT         TLS User Mapping extension             March 2006
 339
 340
 341 4  Message flow
 342
 343    In order to negotiate to send user mapping data to a server in
 344    accordance with this specification, clients MUST include an extension
 345    of type "user_mapping" in the (extended) client hello, which SHALL
 346    contain a list of supported hint types.
 347
 348    Servers that receive an extended client hello containing a
 349    "user_mapping" extension, MAY indicate that they are willing to
 350    accept user mapping data by including an extension of type
 351    "user_mapping" in the (extended) server hello, which SHALL contain a
 352    list of preferred hint types.
 353
 354    After negotiation of the use of user mapping has been successfully
 355    completed (by exchanging hello messages including "user_mapping"
 356    extensions), clients MAY send a "SupplementalData" message containing
 357    the "UserMappingDataList" before the "Certificate" message. The
 358    message flow is illustrated in Fig. 1 below.
 359
 360       Client                                               Server
 361
 362       ClientHello
 363        /* with user_mapping ext */ -------->
 364
 365                                                       ServerHello
 366                                       /* with user-mapping ext */
 367                                                      Certificate*
 368                                                ServerKeyExchange*
 369                                               CertificateRequest*
 370                                    <--------      ServerHelloDone
 371
 372       SupplementalData
 373        /* with UserMappingDataList */
 374       Certificate*
 375       ClientKeyExchange
 376       CertificateVerify*
 377       [ChangeCipherSpec]
 378       Finished                     -------->
 379                                                [ChangeCipherSpec]
 380                                    <--------             Finished
 381       Application Data             <------->     Application Data
 382
 383              Fig. 1 - Message flow with user mapping data
 384
 385    * Indicates optional or situation-dependent messages that are not
 386    always sent according to RFC 2246 [N2] and RFC 4346 [N3].
 387
 388
 389
 390
 391
 392 Santesson, et. all                                              [Page 7]
 393 \f
 394 INTERNET DRAFT         TLS User Mapping extension             March 2006
 395
 396
 397 5  Security Considerations
 398
 399    The UPN sent in the UserMappingDataList is unauthenticated data that
 400    MUST NOT be treated as a trusted identifier. Authentication of the
 401    user represented by that UPN MUST rely solely on validation of the
 402    client certificate. One way to do this in the Microsoft environment
 403    is to use the UPN to locate and extract a certificate of the claimed
 404    user from the trusted directory and subsequently match this
 405    certificate against the validated client certificate from the TLS
 406    handshake.
 407
 408    As the client is the initiator of this TLS extension, it needs to
 409    determine when it is appropriate to send the User Mapping
 410    Information. It may not be prudent to broadcast this information to
 411    just any server at any time, as it can reveal network infrastructure
 412    the client and server are using.
 413
 414    To avoid superfluously sending this information, two techniques
 415    SHOULD be used to control its dissemination.
 416
 417       - The client SHOULD only send the UserMappingDataList in the
 418         supplemental data message if it is agreed upon in the hello
 419         message exchange, preventing the information from being sent
 420         to a server that doesn't understand the User Mapping Extension.
 421
 422       - The client SHOULD further only send this information if the
 423         server belongs to a domain to which the client intends to
 424         authenticate using the UPN as identifier.
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448 Santesson, et. all                                              [Page 8]
 449 \f
 450 INTERNET DRAFT         TLS User Mapping extension             March 2006
 451
 452
 453 6 References
 454
 455    Normative references:
 456
 457    [N1]      S. Bradner, "Key words for use in RFCs to Indicate
 458              Requirement Levels", BCP 14, RFC 2119, March 1997.
 459
 460    [N2]      T. Dierks, C. Allen, "The TLS Protocol Version 1.0",
 461              RFC 2246, January 1999.
 462
 463    [N3]      T. Dierks, E. Rescorla, "The TLS Protocol Version 1.1",
 464              RFC 4346, January 2006.
 465
 466    [N4]      S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen,
 467              T. Wright, "Transport Layer Security (TLS) Extensions",
 468              RFC 4366, February 2006.
 469
 470    [N5]      Mockapetris, P., "Domain Names - Concepts and
 471              Facilities", STD 13, RFC 1034, November 1987.
 472
 473    [N6]      S. Santesson, "TLS Handshake Message for Supplementary
 474              Data", RFC TBD (currently: draft-santesson-tls-supp-00,
 475              Date 2006.
 476
 477    [N7]      P. Hoffman, M. Blanchet, "Preparation of Internationalized
 478              Strings (stringprep)", RFC 3454, December 2002.
 479
 480    [N8]      P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile
 481              for Internationalized Domain Names (IDN)", RFC 3491,
 482              March 2003.
 483
 484    [N9]      K. Zeilenga, "SASLprep: Stringprep Profile for User Names
 485              and Passwords", RFC 4013, February 2005.
 486
 487
 488
 489
 490 7 IANA Considerations
 491
 492    IANA needs to establish a registry for TLS UserMappingType values.
 493    The first entry in the registry is upn_domain_hint(0). TLS
 494    UserMappingType values in the inclusive range 0-63 (decimal) are
 495    assigned via RFC 2434 [IANA] Standards Action.  Values from the
 496    inclusive range 64-223 (decimal) are assigned via RFC 2434
 497    Specification Required.  Values from the inclusive range 224-255
 498    (decimal) are reserved for RFC 2434 Private Use.
 499
 500
 501
 502
 503
 504 Santesson, et. all                                              [Page 9]
 505 \f
 506 INTERNET DRAFT         TLS User Mapping extension             March 2006
 507
 508
 509 Authors' Addresses
 510
 511
 512    Stefan Santesson
 513    Microsoft
 514    Finlandsgatan 30
 515    164 93 KISTA
 516    Sweden
 517
 518    EMail: stefans(at)microsoft.com
 519
 520
 521    Ari Medvinsky
 522    Microsoft
 523    One Microsoft Way
 524    Redmond, WA 98052-6399
 525    USA
 526
 527    Email: arimed(at)microsoft.com
 528
 529
 530    Joshua Ball
 531    Microsoft
 532    One Microsoft Way
 533    Redmond, WA 98052-6399
 534    USA
 535
 536    Email: joshball(at)microsoft.com
 537
 538
 539
 540 Acknowledgements
 541
 542    The authors extend a special thanks to Russ Housley, Eric Resocorla
 543    and Paul Leach for their substantial contributions.
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560 Santesson, et. all                                             [Page 10]
 561 \f
 562 INTERNET DRAFT         TLS User Mapping extension             March 2006
 563
 564
 565 Disclaimer
 566
 567    This document and the information contained herein are provided on an
 568    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 569    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 570    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 571    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 572    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 573    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 574
 575
 576 Copyright Statement
 577
 578    Copyright (C) The Internet Society (2006).
 579
 580    This document is subject to the rights, licenses and restrictions
 581    contained in BCP 78, and except as set forth therein, the authors
 582    retain all their rights.
 583
 584
 585 Expires September 2006
 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 Santesson, et. all                                             [Page 11]