Subject: updated kerb chg/set passwd draft

From: Jonathan Trostle <[email-masked]>
Date: Thu, 24 May 2001 22:37:04 -0700

I have updated the draft to reflect the comments received during WG last call:

Addressed comment on subsession key: subsession key now used. 

ASN.1 changes (including requirement for DER).

Passwords are UTF8 encoded.

ASN.1 CHOICE removed.

New error code for clients that use keys when required to use passwords.

Words around the use of salt, salt-type.

4 byte TCP header is left as is to allow TCP pipelining of set requests.
Any comments here?

KRB_PRIV: added words here: the recipient should ignore the sender IP
address so the protocol is effective in NAT and dynamic address environments.

More words to define keylength in the KRB5_KPASSWD_ETYPE_SRVGENKEYS discussion.

The draft is enclosed below:

Jonathan

Network Working Group                                   Jonathan Trostle
INTERNET-DRAFT                                             Cisco Systems
Category: Standards Track                                     Mike Swift
                                                        University of WA
                                                             John Brezak
                                                               Microsoft
                                                            Bill Gossman
                                                           Cisco Systems

                Kerberos Set/Change Password: Version 2
              <draft-ietf-cat-kerberos-set-passwd-06.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [6].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This draft expires on November 30th, 2001. Please send comments to
   the authors.

1. Abstract

   This proposal specifies a Kerberos (RFC 1510 [3]) change/set password
   protocol and a Kerberos change/set key protocol. The protocol
   consists of a single request and reply message. The request message
   includes both AP-REQ and KRB-PRIV submessages; the new password is
   contained in the KRB-PRIV submessage which is encrypted in the
   subsession key from the AP-REQ. The original Kerberos change password
   protocol did not allow for an administrator to set a password for a
   new user. This functionality is useful in some environments, and this
   proposal allows password setting as well as password changing. The
   protocol includes fields in the request message to indicate the
   principal which is having its password set. We also extend the
   set/change protocol to allow a client to send a sequence of keys to

Trostle, Swift, Brezak, Gossman                                 [Page 1]

INTERNET DRAFT                  May 2001           Expires November 2001

   the KDC instead of a cleartext password. If in the cleartext password
   case, the cleartext password fails to satisfy password policy, the
   server should use the result code KRB5_KPASSWD_POLICY_REJECT.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [7].

3. Definitions from RFC 1510

   We include some of the relevant ASN.1 definitions from RFC 1510 in
   this section.

      Realm ::=           GeneralString

      PrincipalName ::=   SEQUENCE {
                          name-type[0]     INTEGER,
                          name-string[1]   SEQUENCE OF GeneralString
      }

      KerberosTime ::=    GeneralizedTime
                          -- Specifying UTC time zone (Z)

      HostAddress ::=     SEQUENCE  {
                          addr-type[0]             INTEGER,
                          address[1]               OCTET STRING
      }

      EncryptedData ::=   SEQUENCE {
                        etype[0]     INTEGER, -- EncryptionType
                        kvno[1]      INTEGER OPTIONAL,
                        cipher[2]    OCTET STRING -- ciphertext
      }

      EncryptionKey ::=   SEQUENCE {
                          keytype[0]    INTEGER,
                          keyvalue[1]   OCTET STRING
      }

      Checksum ::=        SEQUENCE {
                          cksumtype[0]   INTEGER,
                          checksum[1]    OCTET STRING
      }

      AP-REQ ::= [APPLICATION 14] SEQUENCE {
              pvno [0]         INTEGER,        -- indicates Version 5
              msg-type [1]     INTEGER,        -- indicates KRB_AP_REQ
              ap-options[2]    APOptions,
              ticket[3]        Ticket,
              authenticator[4] EncryptedData
      }

Trostle, Swift, Brezak, Gossman                                 [Page 2]

INTERNET DRAFT                  May 2001           Expires November 2001

      APOptions ::= BIT STRING {

              reserved (0),
              use-session-key (1),
              mutual-required (2)
      }

      Ticket ::= [APPLICATION 1] SEQUENCE {
              tkt-vno [0]     INTEGER,        -- indicates Version 5
              realm [1]       Realm,
              sname [2]       PrincipalName,
              enc-part [3]    EncryptedData
      }

      -- Encrypted part of ticket
      EncTicketPart ::= [APPLICATION 3] SEQUENCE {
              flags[0]        TicketFlags,
              key[1]          EncryptionKey,
              crealm[2]       Realm,
              cname[3]        PrincipalName,
              transited[4]    TransitedEncoding,
              authtime[5]     KerberosTime,
              starttime[6]    KerberosTime OPTIONAL,
              endtime[7]      KerberosTime,
              renew-till[8]   KerberosTime OPTIONAL,
              caddr[9]        HostAddresses OPTIONAL,
              authorization-data[10]  AuthorizationData OPTIONAL
      }

      -- Unencrypted authenticator
      Authenticator ::= [APPLICATION 2] SEQUENCE  {
              authenticator-vno[0]    INTEGER,
              crealm[1]               Realm,
              cname[2]                PrincipalName,
              cksum[3]                Checksum OPTIONAL,
              cusec[4]                INTEGER,
              ctime[5]                KerberosTime,
              subkey[6]               EncryptionKey OPTIONAL,
              seq-number[7]           INTEGER OPTIONAL,
              authorization-data[8]   AuthorizationData OPTIONAL
      }

      AP-REP ::= [APPLICATION 15] SEQUENCE {
              pvno [0]        INTEGER,        -- represents Kerberos V5
              msg-type [1]    INTEGER,        -- represents KRB_AP_REP
              enc-part [2]    EncryptedData
      }

      EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
              ctime [0]       KerberosTime,
              cusec [1]       INTEGER,
              subkey [2]      EncryptionKey OPTIONAL,
              seq-number [3]  INTEGER OPTIONAL

Trostle, Swift, Brezak, Gossman                                 [Page 3]

INTERNET DRAFT                  May 2001           Expires November 2001

      }

   Here is the syntax of the KRB-ERROR message:

      KRB-ERROR ::=   [APPLICATION 30] SEQUENCE {
              pvno[0]         INTEGER,
              msg-type[1]     INTEGER,
              ctime[2]        KerberosTime OPTIONAL,
              cusec[3]        INTEGER OPTIONAL,
              stime[4]        KerberosTime,
              susec[5]        INTEGER,
              error-code[6]   INTEGER,
              crealm[7]       Realm OPTIONAL,
              cname[8]        PrincipalName OPTIONAL,
              realm[9]        Realm, -- Correct realm
              sname[10]       PrincipalName, -- Correct name
              e-text[11]      GeneralString OPTIONAL,
              e-data[12]      OCTET STRING OPTIONAL
      }

   The KRB-PRIV message is used to send the request and reply data:

      KRB-PRIV ::=     [APPLICATION 21] SEQUENCE {
                   pvno[0]                   INTEGER,
                   msg-type[1]               INTEGER,
                   enc-part[3]               EncryptedData
      }

      EncKrbPrivPart ::=   [APPLICATION 28] SEQUENCE {
                   user-data[0]              OCTET STRING,
                   timestamp[1]              KerberosTime OPTIONAL,
                   usec[2]                   INTEGER OPTIONAL,
                   seq-number[3]             INTEGER OPTIONAL,
                   s-address[4]              HostAddress,
                                                        -- sender's addr
                   r-address[5]              HostAddress OPTIONAL
                                                        -- recip's addr
      }

4. The Protocol

   The service SHOULD accept requests on UDP port 464 and TCP port 464
   as well. Use of other ports can significantly increase the complexity
   and size of IPSEC policy rulesets in organizations that have IPSEC
   capable nodes.

   The protocol consists of a single request message followed by a
   single reply message.  For UDP transport, each message must be fully
   contained in a single UDP packet.

   For TCP transport, there is a 4 octet header in network byte order
   that precedes the message and specifies the length of the message.
   This requirement is consistent with the TCP transport header in

Trostle, Swift, Brezak, Gossman                                 [Page 4]

INTERNET DRAFT                  May 2001           Expires November 2001

   1510bis.

   Request Message

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         message length        |    protocol version number    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          AP-REQ length        |         AP-REQ data           /
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       /                        KRB-PRIV message                       /
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   All 16 bit fields are in network byte order.

   message length field: contains the number of bytes in the message
   including this field.

   protocol version number: contains the hex constant 0x0002 (network
   byte order).

   AP-REQ length: length of AP-REQ data, in bytes. If the length is
   zero, then the last field contains a KRB-ERROR message instead of a
   KRB-PRIV message.

   AP-REQ data: (see [3]) For a change password/key request, the AP-REQ
   message service ticket sname, srealm principal identifier is
   kadmin/changepw@REALM where REALM is the realm of the change password
   service. The same applies to a set password/key request except the
   principal identifier is kadmin/setpw@REALM. The authenticator in the
   AP-REQ MUST contain a subsession key (which will be used to encrypt
   the KRB-PRIV user data field - see below). The KDC may have stronger
   pseudorandom generating capability then the clients; thus, the client
   SHOULD use the session key as an input (along with additional locally
   pseudorandom generated bits) into the generation of the subsession
   key. To enable setting of passwords/keys, it is not required that the
   initial flag be set in the Kerberos service ticket. The initial flag
   is required for change requests, but not for set requests. We have
   the following definitions:

                   old passwd   initial flag  target principal can be
                   in request?  required?     distinct from
                                              authenticating principal?

   change password:  yes         yes           no

   set password:     no          policy (*)    yes

   set key:          no          policy (*)    yes

   change key:       no          yes           no

Trostle, Swift, Brezak, Gossman                                 [Page 5]

INTERNET DRAFT                  May 2001           Expires November 2001

   policy (*): implementations SHOULD allow administrators to set the
   initial flag required for set requests policy to either yes or no.
   Clients MUST be able to retry set requests that fail due to error 7
   (initial flag required) with an initial ticket. Clients SHOULD NOT
   cache service tickets targetted at kadmin/changepw.

   KRB-PRIV message (see [3]) This KRB-PRIV message must be encrypted
   using the subsession key from the authenticator in the AP-REQ. The
   authenticator MUST contain a subsession key. The timestamp and usec
   fields of the KRB-PRIV message MUST be present, and the data values
   MUST be copies of the same data values from the authenticator. The
   recipient should ignore the sender address field in the KRB-PRIV
   message.

   The user-data component of the message contains the DER encoding of
   the ChangePasswdData ASN.1 type described below:

    ChangePasswdData ::=  SEQUENCE {
                        passwds [0]          PasswordSequence OPTIONAL,
                        keys [1]             KeySequences OPTIONAL,
                          -- exactly one of the above two will be
                          -- present, else KRB5_KPASSWD_MALFORMED
                          -- error will be returned by the server.
                        targname[2]          PrincipalName OPTIONAL,
                          -- only present in set password/key: the
                          -- principal which will have its password
                          -- or keys set. Not present in a set request
                          -- if the client principal from the ticket is
                          -- the principal having its passwords or keys
                          -- set.
                        targrealm[3]         Realm OPTIONAL,
                          -- only present in set password/key: the realm
                          -- for the principal which will have its
                          -- password or keys set. Not present in a set
                          -- request if the client principal from the
                          -- ticket is the principal having its
                          -- passwords or keys set.
                        flags[4]             RequestFlags OPTIONAL
                          -- 32 bit string
                        }

    KeySequences ::= SEQUENCE (SIZE (1..MAX)) OF KeySequence

    KeySequence ::= SEQUENCE {
                     key[0]        EncryptionKey,
                     salt[1]       OCTET STRING OPTIONAL,
                           -- depends on enc type, not currently used
                     salt-type[2]  INTEGER OPTIONAL
                           -- depends on enc type, not currently used
    }

    PasswordSequence ::= SEQUENCE {
                        newpasswd[0]  OCTET STRING,
                        oldpasswd[1]  OCTET STRING OPTIONAL

Trostle, Swift, Brezak, Gossman                                 [Page 6]

INTERNET DRAFT                  May 2001           Expires November 2001

                          -- oldpasswd always present for change
                          -- password but not present for set
                          -- password, set key, or change key
                          -- NOTE: the passwords are UTF8 strings.
    }

    RequestFlags ::= BIT STRING (SIZE (32..MAX))
                      -- reserved(0)
                      -- request-srv-gen-keys(1)
                           -- only in change/set keys
                           -- if the client desires
                           -- server to contribute to
                           -- keys;
                           -- server will return keys

   The server must verify the AP-REQ message, check whether the client
   principal in the ticket is authorized to set/change the password/keys
   (either for that principal, or for the principal in the targname
   field if present), and decrypt the new password/keys. The server also
   checks whether the initial flag is required for this request,
   replying with status 0x0007 if it is not set and should be. An
   authorization failure is cause to respond with status 0x0005. For
   forward compatibility, the server should be prepared to ignore fields
   after targrealm in the structure that it does not understand.

   If the passwds field is present, it contains the new cleartext
   password (with the old cleartext password for a change password
   operation). Otherwise the keys field is present, and it contains a
   sequence of encryption keys.

   In the cleartext password case, if the old password is sent in the
   request, the request MUST be a change password request. If the old
   password is not present in the request, the request MUST be a set
   password request. The server should apply policy checks to the old
   and new password after verifying that the old password is valid. The
   server can check validity by obtaining a key from the old password
   with a keytype that is present in the KDC database for the user and
   comparing the keys for equality. The server then generates the
   appropriate keytypes from the password and stores them in the KDC
   database. If all goes well, status 0x0000 is returned to the client
   in the reply message (see below). For a change password operation,
   the initial flag in the service ticket MUST be set.

   In the key sequence case, the sequence of keys is sent to the change
   or set password service (kadmin/changepw or kadmin/setpw
   respectively). For a principal that can act as a server, its
   preferred keytype should be sent as the first key in the sequence,
   but the KDC is not required to honor this preference. Application
   servers SHOULD use the key sequence option for changing/setting their
   keys. The change/set password services should check that all keys are
   in the proper format, returning the KRB5_KPASSWD_MALFORMED error
   otherwise.

Trostle, Swift, Brezak, Gossman                                 [Page 7]

INTERNET DRAFT                  May 2001           Expires November 2001

   For change/set key, the request message may include the request flags
   bit string with the request-srv-gen-keys bit set. In this case, the
   client is requesting that the server add entropy to its keys in the
   KeySequences field. When using this option, the client SHOULD attempt
   to generate pseudorandom keys with as much entropy as possible in its
   request. The server will return the final key sequence in a
   KeySequences structure in the edata of the reply message. The server
   does not store any of the new keys at this point. The client MUST
   make a subsequent change/set key request without the request-srv-
   gen-keys bit; if the server returns KRB5_KPASSWD_SUCCESS for this
   second request, then the new keys have been written into the
   database. A conformant server MUST support this option.

   Reply Message

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         message length        |    protocol version number    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          AP-REP length        |         AP-REP data           /
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       /                          KRB-PRIV message                     /
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   All 16 bit fields are in network byte order.

   message length field: contains the number of bytes in the message
   including this field.

   protocol version number: contains the hex constant 0x0002 (network
   byte order). (The reply message has the same format as in the
   original Kerberos change password protocol).

   AP-REP length: length of AP-REP data, in bytes. If the length is
   zero, then the last field contains a KRB-ERROR message instead of a
   KRB-PRIV message. An implementation should check this field to
   determine whether a KRB-ERROR message or KRB-PRIV message has been
   returned.

   AP-REP data: the AP-REP is the response to the AP-REQ in the request
   packet. The subkey MUST be present in the AP-REP message.

   KRB-PRIV message: This KRB-PRIV message must be encrypted using the
   subkey from the AP-REP message. The client should ignore the sender
   address (the server's address) in the KRB-PRIV message. Reflection
   attacks are prevented since the subkey is used to encrypt the user-
   data field of the KRB-PRIV message. The timestamp and usec fields of

Trostle, Swift, Brezak, Gossman                                 [Page 8]

INTERNET DRAFT                  May 2001           Expires November 2001

   the KRB-PRIV message MUST be present, and the data values MUST be
   copies of the same data values from the AP-REP message.

   The server will respond with a KRB-PRIV message unless it cannot
   validate the client AP-REQ or KRB-PRIV message, in which case it will
   respond with a KRB-ERROR message.

   The user-data component of the KRB-PRIV message, or e-data component
   of the KRB-ERROR message, must consist of the following data.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          result code          | key version (only on success) |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     result string length      |         result string         /
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             edata                             /
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       result code (16 bits) (result codes 0-4 are the same as in the
       original Kerberos change password protocol):

       The result code must have one of the following values (network
       byte order):

       KRB5_KPASSWD_SUCCESS            0 request succeeds (This
                                         value is not allowed in a
                                         KRB-ERROR message)

       KRB5_KPASSWD_MALFORMED          1 request fails due to being
                                         malformed

       KRB5_KPASSWD_HARDERROR          2 request fails due to "hard"
                                         error in processing the
                                         request (for example, there
                                         is a resource or other
                                         problem causing the request
                                         to fail)

       KRB5_KPASSWD_AUTHERROR          3 request fails due to an
                                         error in authentication
                                         processing

       KRB5_KPASSWD_SOFTERROR          4 request fails due to a soft
                                         error in processing the
                                         request

       KRB5_KPASSWD_ACCESSDENIED       5 requestor not authorized

       KRB5_KPASSWD_BAD_VERSION        6 protocol version unsupported

       KRB5_KPASSWD_INITIALFLAG_NEEDED 7 initial flag required

Trostle, Swift, Brezak, Gossman                                 [Page 9]

INTERNET DRAFT                  May 2001           Expires November 2001

       KRB5_KPASSWD_POLICY_REJECT      8 new cleartext password fails
                                         policy; the result string
                                         should include a text
                                         message to be presented to
                                         the user.

       KRB5_KPASSWD_WRONG_SRV          9 policy failure: the client
                                         sent change/set key and
                                         should have sent change/set
                                         passwd, or vice-versa.

       KRB5_KPASSWD_BAD_PRINCIPAL     10 target principal does not
                                         exist (only in response to
                                         a set password or set key
                                         request).

       KRB5_KPASSWD_ETYPE_NOSUPP 11 the request contains a key sequence
                                    containing at least one etype that
                                    is not supported by the KDC. The
                                    response edata contains an ASN.1
                                    DER encoded PKERB-ETYPE-INFO type
                                    that specifies the etypes that the
                                    KDC supports:

                                    KERB-ETYPE-INFO-ENTRY :: = SEQUENCE
                                    {
                                         encryption-type[0]  INTEGER,
                                         salt[1]        OCTET STRING
                                           OPTIONAL -- not sent, client
                                                    -- may ignore if
                                                    -- sent
                                    }

                                    PKERB-ETYPE-INFO ::= SEQUENCE OF
                                                  KERB-ETYPE-INFO-ENTRY

                                    The client should retry the request
                                    using only etypes (keytypes) that
                                    are contained within the
                                    PKERB-ETYPE-INFO structure in the
                                    previous response.

       KRB5_KPASSWD_ETYPE_SRVGENKEYS 12 See the following paragraph.

       The KRB5_KPASSWD_ETYPE_SRVGENKEYS result code is returned when
       the request has the request-srv-gen-keys flag set and the
       server is returning the KeySequences structure defined above in
       the edata field of the reply. The server returns one key sequence
       structure of the same keytype for each key sequence structure in
       the client request, unless it does not support one of the
       keytypes (or etypes). In that case, it returns error
       KRB5_KPASSWD_ETYPE_NOSUPP as discussed above. The server MUST
       add keylength number of bits of entropy to each key, where

Trostle, Swift, Brezak, Gossman                                [Page 10]

INTERNET DRAFT                  May 2001           Expires November 2001

       keylength is the number of actual key bits in the key (minus
       any parity or non-entropy contributing bits). The assumption
       here is that the client may have added insufficient entropy
       to the request keys. The server SHOULD use the client key from
       each KeySequence structure as input into the final keyvalue for
       the returned key. The client MUST make another request after
       receiving a reply with this status, since no keys have been
       written into the database.

       0xFFFF is returned if the request fails for some other reason.
       The client must interpret any non-zero result code as a failure.

       key version (16 bits - optional):
       Present if and only if the result
       code is KRB5_KPASSWD_SUCCESS. This contains the key version of
       the new key(s).

       result string length (16 bits):
       Gives the length of the following result string field, in bytes.
       If the result string is not present, the length is zero.

       result string (optional):
       This field is a UTF-8 encoded string which can be displayed
       to the user. Specific reasons for a password set/change policy
       failure is one possible use for this string.

       edata (optional):
       Used to convey additional information as defined by the
       result code.

5.  Acknowledgements

   The authors thank Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony
   Andrea, and other participants from the IETF Kerberos Working Group
   for their input to the document.

6.  Security Considerations

   Password policies should be enforced to make sure that users do not
   pick passwords (for change password/key) that are vulnerable to brute
   force password guessing attacks.

7.  References

   [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
       9, RFC 2026, October 1996.

   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997

   [3] J. Kohl, C. Neuman. The Kerberos Network Authentication
       Service (V5), Request for Comments 1510.

Trostle, Swift, Brezak, Gossman                                [Page 11]

INTERNET DRAFT                  May 2001           Expires November 2001

8. Expiration Date

      This draft expires on November 30th, 2001.

9. Authors' Addresses

      Jonathan Trostle
      Cisco Systems
      170 W. Tasman Dr.
      San Jose, CA 95134
      Email: [email-masked]

      Mike Swift
      University of Washington
      Seattle, WA
      Email: [email-masked]

      John Brezak
      Microsoft
      1 Microsoft Way
      Redmond, WA 98052
      Email: [email-masked]

      Bill Gossman
      Cisco Systems
      500 108th Ave. NE, Suite 500
      Bellevue, WA 98004
      Email: [email-masked]

10. Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

Trostle, Swift, Brezak, Gossman                                [Page 12]

INTERNET DRAFT                  May 2001           Expires November 2001

   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 25 May 2001 11:41:15 -0400

>    database. A conformant server MUST support this option.

Ok, so, request-srv-gen-keys requests are nothing more than a fancy sort
of "give me some random bit string please" requests, right?

Since there is no server-side state keeping and since the
request-srv-gen-keys requests do not actually set a key, there is no way
for the server to enforce that the client actually use the entropy bits
that the server offers. The server also cannot reject a key for lacking
entropy, as the randomness of a bit string is hard to measure (weak
keys are another matter) (*).

So why not simplify the protocol and remove this request-srv-gen-keys
thing, instead adding a top-level request type by which the client can
ask the server for a certain amount of random data?

(*) Pardon my ignorance. If it is possible to measure the randomness of
a bit string, then there should be an error type to indicate that a
given key is weak. Such an error would be useful anyways since various
etypes may have known weak keys. I don't think a combination of
KRB5_KPASSWD_SOFTERROR with a particular result string would suffice
for handling weak key errors either since result string forms are not
specified in this draft and would require the program be able to parse
such result strings.

Also, what about internationalization? Are clients expected to look up
result strings in message catalogs? If so, should there be a minimal
standard set of known result strings so clients can translate result
strings from a different implementor's server (IMHO, no)? Alternatively,
could the client specify its locale to the server so the server can
translate, if it can, the result string?

Cheers,

Nico
--

---

From: Jonathan Trostle <[email-masked]>
Date: Mon, 28 May 2001 22:26:28 -0700

>ask the server for a certain amount of random data?

A general request of this type shouldn't be part of this draft.

>translate, if it can, the result string?

I've been assuming that the realm is contained within a common language area.

Jonathan

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 29 May 2001 10:21:46 -0400

> A general request of this type shouldn't be part of this draft.

I agree, but my point is that such a request is ALREADY part of the
protocol you're proposing, only not as explicit, and it seems that it
complicates some things -- see Ken Raeburn's comments and questions
about the semantics of the server's adding entropy to a client's key.

If the current proposal were such that the server adds entropy, sets
the key and then returns the key to the client, then I would agree that
separating the entropy request from the set key request would
significantly alter the semantics of the protocol. But as the proposal
is it would seem to me that it would be simplified by separating entropy
requests from the key setting aspect of the protocol.

> I've been assuming that the realm is contained within a common language area.

That assumption would be incorrect at at least one large environment
that is deploying AD with one realm covering all offices world-wide,
similarly with an existing MIT krb5 realm.

Password quality rules can be very complex, depending on how anal a
realm's administrators want to be. Understanding an error message in
English about your new password being too short when your primary
language is Japanese is not very hard, not compared to understanding an
error message about your new password not having enough character
classes present, or enough character class transitions, or not differing
enough from previous passwords, etc...

I see to possibilities for dealing with this:

 - let the server figure out the client's appropriate locale based on
   knowledge of either the client principal's preferred locale, or
   knowledge of the client's location and associated preferred locale

 - the client could specify an optional locale in its request.

As I think about it, I'd be happy enough with the first possibility.
Should text be added to the draft about it? Seems kinda obvious to me,
well, now it does.

Cheers,

Nico
--

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 May 2001 07:49:25 -0700 (PDT)

> similarly with an existing MIT krb5 realm.

   Er, doesn't this make a case for _localization_? Ie, the 
   KDC sends an error code and the local client app translates
   it as necessary? How would the KDC know what language a
   client spoke? Also: I'd think that if you're going to be
   anal about different languages with password weaknesses,
   you'd want to apply uniform rules, not just language
   specific rules. For example, you most certainly wouldn't
   want to allow this in the same realm:

   English speaker: domo-arigato
   Japanese speaker: thank-you

		     Mike

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 29 May 2001 10:57:18 -0400

On Tue, May 29, 2001 at 07:49:25AM -0700, Michael Thomas wrote:
>    it as necessary?

No because hardcoding into the protocol the kinds of password quality
checks that the server can perform is too limiting.

>                     How would the KDC know what language a
>    client spoke?

Either the client tells it, or the server knows. How could the server
know? Well, it knows the client principal and the client host exist; the
same database whence that data comes can also specify either's preferred
local.

>                  Also: I'd think that if you're going to be

Indeed! But this is another issue: it's about wether your dictionary and
password quality rules take into account all of your primary business
languages. This issue is separate from the language in which error
messages are displayed!

Nico
--

---

From: Jonathan Trostle <[email-masked]>
Date: Tue, 29 May 2001 15:09:37 -0700

>Should text be added to the draft about it? Seems kinda obvious to me,

These are some good points. If the client is localized, then it can
translate the 
returned error code into a message in a localized catalog. If the client is
not localized,
it should use the message text as is.

Jonathan