doc/specifications/draft-ietf-krb-wg-hw-auth-00.txt

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