Subject: Comments on draft-ietf-cat-kerberos-set-passwd-06.txt

From: Sam Hartman <[email-masked]>
Date: Wed, 27 Feb 2002 00:15:38 -0500 (EST)

I have three major concerns with the set-password draft:

1) It modifies the Kerberos protocol .    It seems that an application
   of Kerberos should not modify the Kerberos protocol in the process
   of specification of that application.

2)  International passwords set using this protocol will be compatible
    neither with current implementations nor with revisions to the
    protocol likely to come out of the  working group.  In addition,
    the proposal is likely to break as Unicode normalization rules and
    character sets change over time.

3) The protocol misuses ASN.1 and does not properly specify
    extensibility behavior; this will mean that future extensions will
    likely need to be new protocols.

4)  The client, rather than the KDC chooses random keys for services.

I will provide details about these concerns, but first I would like to
apologize that I am bringing these issues to the attention of the IESG
at such a late date and that they were handled badly within the WG
last call.  Some of the issues (#1, parts of #3, and #4) were brought
up during one of the two working group last calls on this document.
However many of the people bringing forward these issues have been
focusing on the Kerberos protocol itself rather than auxiliary
documents like the password changing protocol.    From my  perspective
it seems like people did take the time to review the document and
bring up comments but did not manage to find time to follow through on
their comments, and so these issues are still present.

			    Issue Details

Changes to Kerberos Protocol:

In section four of the document, the protocol says that a recipient
should ignore the sender address:

     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.

However, according to RFC 1510, this check is not optional:

  The
     recipient verifies that the operating system's report of the sender's
     address matches the sender's address in the message, and (if a
     recipient address is specified or the recipient requires an address)
     that one of the recipient's addresses appears as the recipient's
     address in the message.  A failed match for either case generates a
     KRB_AP_ERR_BADADDR error. 

We can resolve this inconsistency either by claiming that the set
password protocol revises the Kerberos protocol and amends RFC 1510 or
  claiming that since the Kerberos protocol mandates the check, all
  vendors have a good reason for violating the should in the password
  protocol and thus the should clause has no effect.  From my standpoint
  making either claim is undesirable and the password protocol should
  either wait for a Kerberos protocol that does not mandate address
  checks or should work with the existing protocol.

  Internationalization:

  The set-password protocol transports passwords, encoded as UTF-8
  strings in ASN.1 octet strings.  No mention is made of UTF-8
  normalization rules, character set repertoire, etc.    

  This presents two problems.  First, there are significant issues using
  Unicode passwords with existing Kerberos implementations.  Most of
  these issues are discussed in draft-ietf-krb-wg-info-ascii-00.txt.
  It would be easy for a user of this protocol to change to a password
  that  clients in the realm cannot use.

  This might be acceptable.  However, I'm much more concerned about the
  evolution of this protocol as Kerberos adopts a real
  internationalization solution.  It seems likely that Kerberos will
  adopt a profile for stringprep (draft-hoffman-stringprep-00.txt) as
  part of the internationalization solution.  In the terms of section 6
  of that draft, passwords are stored strings.  Interoperability
  problems can result if a codepoint that is mapped out, prohibited or
  allowed ever moves to another category.  For stored strings,
  interoperability problems can result if an unassigned codepoint is
  used in a stored string.

  Since the set password draft uses Unicode without specifying
  normalization or mapping rules, it seems very likely that both of
  these types of interoperability problems will eventually result  when
  a real internationalization solution is adopted.  That is, passwords
  set with this protocol may stop working as clients begin to implement
  the Kerberos normalization and mapping rules.

  ASN.1 and Extensibility uses:

  Section 4 of the document requires that servers and clients be
  prepared for extensions to the structures:

For
   forward compatibility, the server should be prepared to ignore fields
   after targrealm in the structure that it does not understand.

Unfortunately, the ASN.1 sequence is defined without an
extension marker.  As we are finally discovering with the base Kerberos
protocol many ASN.1 implementations will reject an encoding of a
sequence containing unexpected fields .  While there has been some
debate within the working group on how important it is to fix the
ASN.1 in the Kerberos protocol, it seems clear that standardizing
protocols that have known broken ASN.1 is a bad idea.

In addition, the contents of the salt and salt type fields (and their
use) is unspecified.  There seems to be an impression in the draft
that salt strings are enctype specific and that salt types are not
needed with current crypto systems.  The hope seems to be (expressed
more clearly in list discussion than the draft) that future crypto
system documents will make it clear what to put in these fields.  

These assumptions are inconsistent both with existing practice and
with draft-ietf-krb-wg-crypto-00.txt.  Salt types are not defined in
that draft, but the usage of the salt string is defined.  The salt
string is crypto system independent; significant effort was recently
made to maintain the crypto system independence of salts even for
AES.  I do not see any document that is likely to come forward and
clarify these fields in the set-password protocol in the future; as
such I am concerned that these fields will confuse vendors and
implementers.  I suspect we will have interoperability problems
because salt type is a well-defined concept in several
implementations, so it is likely the field will be  used   with
conflicting/different/non-standard values.

Security of keys (issue 4):

I'll warn that I seem to be the primary proponent of this issue.  It
may well be there is not working group consensus on this issue; no one
has disagreed with me on the list that this is important, but no one
picked up the issue when I became too busy to follow through with the
author.

Traditionally Kerberos KDCs have chosen random keys for services
(possibly excluding the Microsoft implementation).  The security of
the Kerberos authentication protocol  depends on the quality of the
KDC's randomly generated session keys, so assuming that the KDC is
able to generate service keys  of high quality seems not
unreasonable.  Certainly it seems reasonable to assume the KDC will
have better entropy than a random service machine.  Ideally the
service would also be able to contribute entropy to the key  setup,
but this is not current practice for several implementations.

In such implementations it often requires less privilege to set a key
to a random value than it does to set a key to an explicit value.
This prevents services from choosing weak keys.

The current set-password proposal allows a service to request that the
KDC contribute entropy to a key it is choosing.  However the client
ultimately gets to choose what key is written to the database, so the
client can choose a weak key.

I have two concerns.  First, it would be nice if a mechanism were
provided to give the KDC the final decision about which key was used,
so that the privilege distinction between set to explicit key and set
to random key can be maintained.

More importantly, the current structure of the protocol seems to
increase the likelihood that clients will simply implement the
one-exchange set-key using only client entropy rather than the more
complex variant allowing the KDC to contribute entropy.  It might have
been more reasonable to make this variant required on both client and
server, or required on client and optional on server than the current
MUST for server and no recommendation for client.

Thanks for consideration,

--Sam

---

From: [email-masked]
Date: 27 Feb 2002 09:14:26 +0100

>     likely need to be new protocols.

I see Sam's issues (1) - (3) as a general problem, namely that this
protocol is between rfc1510 and the future rfc on Kerberos 5.  While
being based on RFC1510, it tries to be compatible with some future
enhancements that are believed will arrive in the new RFC.  This seems
like a bad idea.  Either it should be solely based on 1510 or wait for
the new RFC to come and be based on that.  What will be status of this
protocol if the issues are not resolved in the forseen way in the
upcoming new Kerberos RFC?  Trying to be compatible with a future
standard leaves dangling threads (such as the unspecified and `unused'
salt fields).

This document also brings up new issues not handled in either 1510 or
the current i-d on kerberos revisions, such as a preferred ordering of
keys for a principal.  I think that is something that should be
described in the Kerberos rfc and not in the change/set password one.

The `key version' in the user-data portion of the reply message is
only 16 bits.  The specification of that same quantity is unlimited in
1510, and while still unlimited in the revisions i-d, there seems to
be consensus around a 32 bit value.  I believe a common implementation
uses 32 bits for key version numbers and if that's the case it seems
bad to limit the field in this protocol to 16 bits.

/assar

---

From: Matt Crawford <[email-masked]>
Date: Wed, 27 Feb 2002 11:37:15 -0600

> [...]
> However the client ultimately gets to choose what key is written to
> the database, so the client can choose a weak key.

Worse, the client could choose a key that is derivable from a weak
password.  Maybe this is what you meant, but I think it's worse than
a client with a poor RNG -- a realm supporting this service would be
completely unable to enforce a password quality policy!