doc/standardisation/draft-ietf-krb-wg-hw-auth-04.txt

   1
   2
   3
   4
   5
   6
   7
   8
   9
  10
  11 Kerberos Working Group                                     Matt Crawford
  12 Internet Draft                                                  Fermilab
  13                                                          21 October 2006
  14
  15               Passwordless Initial Authentication to Kerberos
  16                        by Hardware Preauthentication
  17                      <draft-ietf-krb-wg-hw-auth-04.txt>
  18
  19
  20
  21 Status of this Memo
  22
  23     By submitting this Internet-Draft, each author represents that any
  24     applicable patent or other IPR claims of which he or she is aware
  25     have been or will be disclosed, and any of which he or she becomes
  26     aware will be disclosed, in accordance with Section 6 of BCP 79.
  27
  28     Internet-Drafts are working documents of the Internet Engineering
  29     Task Force (IETF), its areas, and its working groups.  Note that
  30     other groups may also distribute working documents as Internet-
  31     Drafts.
  32
  33     Internet-Drafts are draft documents valid for a maximum of six
  34     months and may be updated, replaced, or obsoleted by other documents
  35     at any time.  It is inappropriate to use Internet- Drafts as
  36     reference material or to cite them other than as "work in progress."
  37
  38     The list of current Internet-Drafts can be accessed at
  39     http://www.ietf.org/1id-abstracts.html.
  40
  41     To view the list Internet-Draft Shadow Directories, see
  42     http://www.ietf.org/shadow.html.
  43
  44
  45 Abstract
  46
  47     This document specifies an extension to the Kerberos protocol for
  48     performing initial authentication of a user without using that
  49     user's long-lived password.  Any "hardware preauthentication" method
  50     may be employed instead of the password, and the key of another
  51     principal must be nominated to encrypt the returned credential.
  52
  53     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  54     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  55
  56
  57
  58 Expires April 26, 2007          Crawford                        [Page 1]
  59 \f
  60 Internet Draft    Passwordless Hardware Authentication   21 October 2006
  61
  62
  63     document are to be interpreted as described in [KWORD].
  64
  65
  66 1.  Motivation
  67
  68     Many sites using Kerberos for authentication have users who are
  69     often, or even always, away from the site.  Sometimes these users
  70     may need to connect to their site while they have no immediate
  71     access to a trustworthy computer with Kerberos software or any other
  72     trusted secure remote-access mechanism.  Requiring hardware
  73     preauthentication in addition to a password for all such users is an
  74     incomplete solution because an eavesdropper with access to both the
  75     remote users' path to the host in the site and that host's path to
  76     the KDC can still steal the user's credential.
  77
  78     This document specifies a method by which a Kerberos application
  79     server can request that a KDC authenticate a user using a hardware
  80     preauthentication method and use a key held by the server in the
  81     decryption of the KDC's reply, in place of the user's password.
  82
  83
  84 2.  Definitions
  85
  86     The following terms used here are defined in [KRB5] and [KRB5bis]:
  87
  88         KDC_ERR_PREAUTH_FAILED, KDC_ERR_PREAUTH_REQUIRED, KRB_AS_REQ,
  89         KRB_ERROR, PrincipalName, e-data, enc-part, error-code, kdc-
  90         options, padata-type, padata-value.
  91
  92     These terms are defined in [KRB5bis]:
  93
  94         PA-SAM-CHALLENGE, PA-SAM-CHALLENGE2, PA-SAM-RESPONSE, PA-SAM-
  95         RESPONSE2.
  96
  97     The term "service" denotes some Kerberos service which normally
  98     requires a client/server authentication exchange [KRB5] for access
  99     and which is capable of both communicating with the KDC's
 100     Authentication Service and interacting with the user to the extent
 101     required to carry out a single-use authentication mechanism (SAM).
 102     It must have access to some principal's long-lived key.  Telnet and
 103     FTP services are examples.
 104
 105     The Kerberos Authentication Service will be denoted by "AS" to avoid
 106     confusion with the service.
 107
 108
 109
 110
 111
 112
 113
 114 Expires April 26, 2007          Crawford                        [Page 2]
 115 \f
 116 Internet Draft    Passwordless Hardware Authentication   21 October 2006
 117
 118
 119 3.  Method
 120
 121     This mechanism is intended to be employed when a user connects to a
 122     service which normally allows only Kerberos-authenticated access.
 123     When the service determines that the user will not authenticate (for
 124     example, it receives a telnet "WONT AUTHENTICATION" command
 125     [TELAUTH], or an FTP "USER" command without a preceding "AUTH"
 126     command [FTPSEC]), it may accept a user principal name and attempt
 127     to perform passwordless hardware authentication in the following
 128     manner.
 129
 130
 131 3.1.  Initial AS Request and reply
 132
 133     The service, on behalf of the user, prepares a KRB_AS_REQ [KRB5]
 134     message with the flag OPT-HARDWARE-AUTH set in the kdc-options
 135     field, in addition to any other desired options and lifetimes.  The
 136     service sends this message to a KDC.  If the KDC's policy permits
 137     this form of authentication for the user named in the request, and
 138     the request is acceptable in all other respects, the KDC determines
 139     what hardware preauthentication methods are available for the user
 140     principal and constructs a KRB_ERROR message with the error-code set
 141     to KDC_ERR_PREAUTH_REQUIRED.  The e-data field of this KRB_ERROR
 142     message contains a sequence of PA-DATA which includes an element
 143     with padata-type equal to PA-ALT-PRINC and an empty padata-value.
 144     In addition to that are any elements needed for hardware
 145     preauthentication of the user.  Typically this will include an
 146     element with padata-type PA-SAM-CHALLENGE or PA-SAM-CHALLENGE2 and
 147     padata-value appropriate to the authentication method.
 148
 149
 150 3.2.  Second AS Request
 151
 152     The service, upon receiving the KRB_ERROR message from the KDC, must
 153     process the PA-ALT-PRINC element by selecting a principal whose
 154     long-lived key it has access to, and which is in the same realm as
 155     the client.  This principal will be referred to as the alternate
 156     principal.  It processes the PA-SAM-CHALLENGE normally, except that
 157     whenever the user's long-lived (password-derived) encryption key is
 158     called for, it uses the alternate principal's key instead.
 159
 160     The service constructs a second KRB_AS_REQ, again with the OPT-
 161     HARDWARE-AUTH flag set in the kdc-options field, and this time with
 162     a padata field which includes at least these two PA-DATA items, in
 163     this order:
 164
 165         One with padata-type equal to PA-ALT-PRINC and as padata-value
 166         the encoded PrincipalName of the alternate principal,
 167
 168
 169
 170 Expires April 26, 2007          Crawford                        [Page 3]
 171 \f
 172 Internet Draft    Passwordless Hardware Authentication   21 October 2006
 173
 174
 175         One with padata-type appropriate for hardware token-based
 176         preauthentication, such as PA-SAM-RESPONSE or PA-SAM-RESPONSE2,
 177         and padata-value constructed as it would be for normal hardware
 178         preauthentication, but with the alternate principal's key used
 179         in place of the user's key.
 180
 181     Other PA-DATA may be present before, between or after these items.
 182
 183     The service sends this second KRB_AS_REQ to a KDC.
 184
 185
 186 3.3.  Final AS Reply
 187
 188     The KDC begins processing the AS request normally.  When the PA-ALT-
 189     PRINC field is encountered, the KDC does the following:
 190
 191         First, if this use of the alternate principal named in the
 192         request is against local policy, or if the alternate principal
 193         does not exist in the database, a KRB_ERROR message with error-
 194         code KDC_ERR_PREAUTH_FAILED is returned and processing ends.
 195
 196         Then, the alternate principal's key is fetched from the database
 197         and held for use in subsequent processing.  It will be needed to
 198         process the PA-SAM-RESPONSE, PA-SAM-RESPONSE2, or similar
 199         preauthentication data, and to encrypt the enc-part of the
 200         KRB_AS_REP if authentication is successful.
 201
 202     The remainder of the AS request processing is normal, with the noted
 203     substitution of the alternate principal's key for the user's.
 204
 205     The service, upon receiving a KRB_AS_REP, uses the alternate
 206     principal's key to decrypt the enc-part, saves the user's credential
 207     and takes appropriate measures to ensure that the KRB_AS_REP came
 208     from a legitimate KDC and not an imposter.
 209
 210
 211 4.  IANA Considerations
 212
 213     No new naming or numbering spaces are created by this specification.
 214     Two values from existing spaces are defined in [KRB5bis] for the
 215     mechanism of this document:
 216
 217         The flag OPT-HARDWARE-AUTH is bit 11 in the kdc-options field of
 218         a KDC-REQ-BODY.
 219
 220         The preauthentication type PA-ALT-PRINC is denoted by padata-
 221         type 24.
 222
 223
 224
 225
 226 Expires April 26, 2007          Crawford                        [Page 4]
 227 \f
 228 Internet Draft    Passwordless Hardware Authentication   21 October 2006
 229
 230
 231 5.  Security Considerations
 232
 233     There are no means provided here for protecting the traffic between
 234     the user and the service, so it may be susceptible to eavesdropping,
 235     hijacking and alteration.  This authentication mechanism is not
 236     intended to be used as an alternative to the Kerberos client/server
 237     authentication exchange, but as an improvement over making an
 238     unprotected connection with a Kerberos password alone, or a password
 239     plus a single-use authenticator.
 240
 241     The alternate principal's key MUST be involved in construction of
 242     the PA-SAM-RESPONSE (or PA-SAM-RESPONSE2) padata-value, to prevent
 243     an adversary constructing a KRB_AS_REQ using that data but a
 244     different alternate principal.  In practice, this means that the
 245     response data alone must not determine the encryption key for the
 246     padata-value.
 247
 248     A service impersonator can obtain a presumably-valid SAM response
 249     from the user which may (or may not) be usable for impersonating the
 250     user at a later time.  And of course in the case of successful
 251     authentication the service obtains access to the user's credentials.
 252     As always, if the service host is compromised, so are the
 253     credentials; but, with this mechanism, at least the service host
 254     never has access to the user's password.
 255
 256     A service host which accepts a Kerberos password for access
 257     typically protects itself against an impostor KDC by using the
 258     received ticket-granting credential to get a ticket for a service
 259     for which it has the key.  This step may be unnecessary when the
 260     service host has already successfully used such a key to decrypt the
 261     ticket-granting credential itself.
 262
 263     Use of this authentication method employs the service's long-term
 264     key, providing more ciphertext in that key to an eavesdropper.  This
 265     key is generally of better quality than a password-derived key and
 266     any remaining concerns about the strength of the KRB_AS_REP are
 267     better addressed by a general mechanism applicable to all AS
 268     exchanges.
 269
 270
 271 6.  Acknowledgments
 272
 273     The first implementation of this extension grew from a beginning by
 274     Ken Hornstein, which in turn was built on code released by the MIT
 275     Kerberos Team.
 276
 277
 278
 279
 280
 281
 282 Expires April 26, 2007          Crawford                        [Page 5]
 283 \f
 284 Internet Draft    Passwordless Hardware Authentication   21 October 2006
 285
 286
 287 7.  References
 288
 289     [FTPSEC]  Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC
 290               2228.
 291
 292     [KRB5]    Kohl, J., and C. Neuman, "The Kerberos Network
 293               Authentication Service (V5)", RFC 1510.
 294
 295     [KRB5bis] Neuman, C., T. Yu, S. Hartman, and K. Raeburn, "The
 296               Kerberos Network Authentication Service (V5)", RFC 4120.
 297
 298     [KWORD] S. Bradner, "Key words for use in RFCs to Indicate
 299         Requirement Levels," RFC 2119, March 1997.
 300
 301     [TELAUTH] Ts'o, T. and J. Altman, "Telnet Authentication Option",
 302               RFC 2941.
 303
 304 8.  Author's Address
 305
 306     Matt Crawford
 307     Fermilab MS 368
 308     PO Box 500
 309     Batavia, IL 60510
 310     USA
 311
 312     Phone: +1 630 840-3461
 313     EMail: crawdad@fnal.gov
 314
 315 Disclaimer of Validity
 316
 317     This document and the information contained herein are provided on
 318     an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
 319     REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
 320     INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
 321     IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 322     THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 323     WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 324
 325
 326 Copyright Statement
 327
 328     Copyright (C) The Internet Trust (2006).  This document is subject
 329     to the rights, licenses and restrictions contained in BCP 78, and
 330     except as set forth therein, the authors retain all their rights.
 331
 332
 333     Acknowledgment
 334
 335
 336
 337
 338 Expires April 26, 2007          Crawford                        [Page 6]
 339 \f
 340 Internet Draft    Passwordless Hardware Authentication   21 October 2006
 341
 342
 343     Funding for the RFC Editor function is currently provided by the
 344     Internet Society.
 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 Expires April 26, 2007          Crawford                        [Page 7]