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

   1
   2 Kerberos Working Group                                     Matt Crawford
   3 Internet Draft                                                  Fermilab
   4                                                        10 September 2003
   5
   6               Passwordless Initial Authentication to Kerberos
   7                        by Hardware Preauthentication
   8                      <draft-ietf-krb-wg-hw-auth-03.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
  16     working documents of the Internet Engineering Task Force (IETF), its
  17     areas, and its working groups.  Note that other groups may also
  18     distribute 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
  47
  48
  49 Expires March 15, 2004          Crawford                        [Page 1]
  50 \f
  51 Internet Draft    Passwordless Hardware Authentication 10 September 2003
  52
  53
  54     may need to connect to their site while they have no immediate
  55     access to a computer with Kerberos software or any other trusted
  56     secure remote-access mechanism.  Requiring hardware
  57     preauthentication in addition to a password for all such users is an
  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 in the
  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] and [KRB5bis]:
  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, padata-type, padata-value.
  75
  76     These terms are defined in [KRB5bis]:
  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 Expires March 15, 2004          Crawford                        [Page 2]
 106 \f
 107 Internet Draft    Passwordless Hardware Authentication 10 September 2003
 108
 109
 110 3.1.  Initial AS Request and reply
 111
 112     The service, on behalf of the user, prepares a KRB_AS_REQ [KRB5]
 113     message with the flag OPT-HARDWARE-AUTH set in the kdc-options
 114     field, in addition to any other desired options and lifetimes.  The
 115     service sends this message to a KDC.  If the KDC's policy permits
 116     this form of authentication for the user named in the request, and
 117     the request is acceptable in all other respects, the KDC determines
 118     what hardware preauthentication methods are available for the user
 119     principal and constructs a KRB_ERROR message with the error-code set
 120     to KDC_ERR_PREAUTH_REQUIRED.  The e-data field of this KRB_ERROR
 121     message contains a sequence of PA-DATA which includes an element
 122     with padata-type equal to PA-ALT-PRINC and an empty padata-value.
 123     In addition to that are any elements needed for hardware
 124     preauthentication of the user.  Typically this will consist of an
 125     element with padata-type PA-SAM-CHALLENGE and padata-value
 126     appropriate to the authentication method.
 127
 128
 129 3.2.  Second AS Request
 130
 131     The service, upon receiving the KRB_ERROR message from the KDC, must
 132     process the PA-ALT-PRINC element by selecting a principal whose
 133     long-lived key it has access to, and which is in the same realm as
 134     the client.  This principal will be referred to as the alternate
 135     principal.  It processes the PA-SAM-CHALLENGE normally, except that
 136     whenever the user's long-lived (password-derived) encryption key is
 137     called for, it uses the alternate principal's key instead.
 138
 139     The service constructs a second KRB_AS_REQ, again with the OPT-
 140     HARDWARE-AUTH flag set in the kdc-options field, and this time with
 141     a padata field which includes at least these two PA-DATA items, in
 142     this order:
 143
 144         One with padata-type equal to PA-ALT-PRINC and as padata-value
 145         the encoded PrincipalName of the alternate principal,
 146
 147         One with padata-type equal to PA-SAM-RESPONSE and padata-value
 148         constructed as it would be for normal hardware
 149         preauthentication, but with the alternate principal's key used
 150         in place of the user's key.
 151
 152     Other PA-DATA may be present before, between or after these items.
 153
 154     The service sends this second KRB_AS_REQ to a KDC.
 155
 156
 157
 158
 159
 160
 161 Expires March 15, 2004          Crawford                        [Page 3]
 162 \f
 163 Internet Draft    Passwordless Hardware Authentication 10 September 2003
 164
 165
 166 3.3.  Final AS Reply
 167
 168     The KDC begins processing the AS request normally.  When the PA-ALT-
 169     PRINC field is encountered, the KDC does the following:
 170
 171         First, if this use of the alternate principal named in the
 172         request is against local policy, or if the alternate principal
 173         does not exist in the database, a KRB_ERROR message with error-
 174         code KDC_ERR_PREAUTH_FAILED is returned and processing ends.
 175
 176         Then, the alternate principal's key is fetched from the database
 177         and held for use in subsequent processing.  It will be needed to
 178         process the PA-SAM-RESPONSE and to encrypt the enc-part of the
 179         KRB_AS_REP if authentication is successful.
 180
 181     The remainder of the AS request processing is normal, with the noted
 182     substitution of the alternate principal's key for the user's.
 183
 184     The service, upon receiving a KRB_AS_REP, uses the alternate
 185     principal's key to decrypt the enc-part, saves the user's credential
 186     and takes appropriate measures to ensure that the KRB_AS_REP came
 187     from a legitimate KDC and not an imposter.
 188
 189
 190 4.  IANA Considerations
 191
 192     As of this writing, management of Kerberos protocol parameters has
 193     not been delegated to IANA.  No new naming or numbering spaces are
 194     created by this specification.  Two new values from existing spaces
 195     are defined:
 196
 197         The flag OPT-HARDWARE-AUTH is a previously unused bit in the
 198         kdc-options field of a KDC-REQ-BODY [KRB5].  The assignment of
 199         bit 11 is expected [BCN].
 200
 201         The preauthentication type PA-ALT-PRINC is denoted by padata-
 202         type 24 [KRB5bis].
 203
 204
 205 5.  Security Considerations
 206
 207     There are no means provided here for protecting the traffic between
 208     the user and the service, so it may be susceptible to eavesdropping,
 209     hijacking and alteration.  This authentication mechanism is not
 210     intended to be used as an alternative to the Kerberos client/server
 211     authentication exchange, but as an improvement over making an
 212     unprotected connection with a Kerberos password alone, or a password
 213     plus a single-use authenticator.
 214
 215
 216
 217 Expires March 15, 2004          Crawford                        [Page 4]
 218 \f
 219 Internet Draft    Passwordless Hardware Authentication 10 September 2003
 220
 221
 222     The alternate principal's key MUST be involved in construction of
 223     the PA-SAM-RESPONSE padata-value, to prevent an adversary
 224     constructing a KRB_AS_REQ using that data but a different alternate
 225     principal.  In practice, this means that the response data alone
 226     must not determine the encryption key for the padata-value.
 227
 228     A service impersonator can obtain a presumably-valid SAM response
 229     from the user which may (or may not) be usable for impersonating the
 230     user at a later time.  And of course in the case of successful
 231     authentication the service obtains access to the user's credentials.
 232     As always, if the service host is compromised, so are the
 233     credentials; but at least the service host never has access to the
 234     user's password.
 235
 236     A service host which accepts a Kerberos password for access
 237     typically protects itself against an impostor KDC by using the
 238     received ticket-granting credential to get a ticket for a service
 239     for which it has the key.  This step may be unnecessary when the
 240     service host has already successfully used such a key to decrypt the
 241     ticket-granting credential itself.
 242
 243     Use of this authentication method employs the service's long-term
 244     key, providing more ciphertext in that key to an eavesdropper.  This
 245     key is generally of better quality than a password-derived key and
 246     any remaining concerns about the strength of the KRB_AS_REP are
 247     better addressed by a general mechanism applicable to all AS
 248     exchanges.
 249
 250
 251 6.  Acknowledgments
 252
 253     The first implementation of this extension grew from a beginning by
 254     Ken Hornstein, which in turn was built on code released by the MIT
 255     Kerberos Team.
 256
 257
 258 7.  References
 259
 260     [BCN]     Newman, C., private communication.
 261
 262     [FTPSEC]  Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC
 263               2228.
 264
 265     [KRB5]    Kohl, J., and C. Neuman, "The Kerberos Network
 266               Authentication Service (V5)", RFC 1510.
 267
 268     [KRB5bis] Neuman, C., T. Yu, S. Hartman, and K. Raeburn, "The
 269               Kerberos Network Authentication Service (V5)", Work in
 270
 271
 272
 273 Expires March 15, 2004          Crawford                        [Page 5]
 274 \f
 275 Internet Draft    Passwordless Hardware Authentication 10 September 2003
 276
 277
 278               progress.  (Currently draft-ietf-krb-wg-kerberos-
 279               clarifications-04.txt.)
 280
 281     [KWORD] S. Bradner, "Key words for use in RFCs to Indicate
 282         Requirement Levels," RFC 2119, March 1997.
 283
 284     [TELAUTH] Ts'o, T. and J. Altman, "Telnet Authentication Option",
 285               RFC 2941.
 286
 287 8.  Author's Address
 288
 289     Matt Crawford
 290     Fermilab MS 369
 291     PO Box 500
 292     Batavia, IL 60510
 293     USA
 294
 295     Phone: +1 630 840-3461
 296     EMail: crawdad@fnal.gov
 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 Expires March 15, 2004          Crawford                        [Page 6]