Subject: Working Group Last call - draft-ietf-cat-kerberos-set-passwd-05.txt

From: "Douglas E. Engert" <[email-masked]>
Date: Wed, 02 May 2001 15:49:07 -0500

At the Mineapolis IETF meeting the Kerberos WG agreed to start the last call on:
"Kerberos Set/Change Password: Version 2", John Brezak, J Trostle, Michael Swift,
 Bill Gossman, 04/25/2001. (29667 bytes)

http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-set-passwd-05.txt

The requested changes from the meeting have been made to this latest draft. 
At the request of the authors, we will start a two week last call, which should 
end on May 17. 

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: [email-masked] (Johan Danielsson)
Date: 07 May 2001 14:14:43 +0200

"Douglas E. Engert" <[email-masked]> writes:

> At the Mineapolis IETF meeting the Kerberos WG agreed to start the
> last call on: "Kerberos Set/Change Password: Version 2", John
> Brezak, J Trostle, Michael Swift, Bill Gossman, 04/25/2001. (29667
> bytes)

Has there ever been any discussion on this?

I think this draft is quite horrible. Marc's original version was very
simple, but this adds an enormous amount of ASN.1 garbage just to set
a password.

/Johan

---

From: Martin Rex <[email-masked]>
Date: Wed, 9 May 2001 19:34:39 +0200 (METDST)

> Has there ever been any discussion on this?

I don't remember any discussion on the merit of using ASN.1 here
instead of going plain&simple and straigtforward with a bits&bytes spec.

> simple, but this adds an enormous amount of ASN.1 garbage just to set

Personally, I totally agree.  There's enough ASN.1 in Kerberos already
and it has proven to cause misunderstandings and interoperability problems.

Often, the use of ASN.1 means that the author didn't think about
protocol extensibility or didn't want to think about it and expects
ASN.1 to take care of that.  My impression is however that *good* ASN.1
requires more thought than most flexible and extensible design using
conventional bits&bytes specs.

It is clearly *much* easier to understand, discuss, implement and later
extend conventional bits&bytes protocol specs for the large majority
of software engineers.

The last call didn't mention that the document is going for standards
track (it may have been mentionen at the IETF meeting or in any
prior list discussion, but I don't remember it).  This means that
all Kerberos implementors should either agree that they like the
spec and its use of ASN.1, because it is going to become the
standard and they will probably have to implement it...

The task itself does probably not justify the use of ASN.1,
a password change protocol is not rocket science.  I don't know
if there is already an installed base implementing this particular
spec, or if there is an installed base implementing a different
spec.

So if any implementor has a *real* problem with this spec, this is
the last (call) chance to bring any such issues to the discussion.

-Martin

---

From: [email-masked] (Johan Danielsson)
Date: 10 May 2001 11:39:09 +0200

Martin Rex <[email-masked]> writes:

> Personally, I totally agree.  There's enough ASN.1 in Kerberos
> already and it has proven to cause misunderstandings and
> interoperability problems.

Very much so since this draft uses CHOICE that isn't used anywhere
else (in Kerberos).

> I don't know if there is already an installed base implementing this
> particular spec, or if there is an installed base implementing a
> different spec.

Not that I know of. We all use Marc's protocol to change passwords,
but that doesn't handle the case of setting someone elses password. I
assume there is an implementation of this, but I don't think it has
any wide use. The MS people will have to answer this.

/Johan

---

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 14 May 2001 14:00:01 -0500

We still have three more days for the last call. 

The only objections I have heard so far have been to the use of ASN.1.

 o Some implementations have been using hand encoded ASN.1 routines and having
   to hand code more ASN.1 is a hardship. 

 o Substantially more ASN.1 was added in this draft then in the informational
   draft. 

 o The addition of the ASN.1 CHOICE is new, and will require more hand coding. 

 o The BER/DER encoding rules need to be specified.

The first three objections are all basically, the same. Therefore I would 
like to ask the Kerberos implementors, if this draft is adapted will they 
implement it or not? If not, why, is it because of the ASN.1?

I agree that the fourth point needs to be clarified. Can the authors recommend
the exact wording and location of chages to be added to the draft to specify BER/DER?

Are there any other technical issues with the draft?

--

---

From: Jonathan Trostle <[email-masked]>
Date: Mon, 14 May 2001 16:11:17 -0700

>the exact wording and location of chages to be added to the draft to specify 

Yes.

Jonathan

---

From: [email-masked] (Johan Danielsson)
Date: 15 May 2001 11:41:13 +0200

"Douglas E. Engert" <[email-masked]> writes:

> Therefore I would like to ask the Kerberos implementors, if this
> draft is adapted will they implement it or not? If not, why, is it
> because of the ASN.1?

To reverse your question, if we don't implement it it's because of the
ASN.1, which does not mean that we won't implement it anyway if we
feel enough need for it.

I would vote for a similar protocol using XDR. Perhaps something like:

  struct {
          NewPasswordOrKeys newpasswordorkeys;
          string *principal<>;
          unsigned *flags;
  } ChangePasswdData;

  union switch(foo) {
  case 0:
          PasswordSequence passwords;
  case 1:
          KeySequence keyseq<>;
  } NewPasswordOrKeys;

  struct {
          int keytype;
          opaque<> keyvalue;
  } EncryptionKey;

  struct {
          EncryptionKey key;
          opaque<> *salt;
          int *salt-type;
  } KeySequence;

  struct {
          opaque<> newpassword;
          opaque<> *oldpassword;
  } PasswordSequence ;

But it should of course be described in terms of bytes sent.

/Johan

---

From: Tom Yu <[email-masked]>
Date: 17 May 2001 21:05:51 -0400

I would like to add a few more comments.  I apologize for the lateness
of this message.

The original Horowitz draft specified that in the request message, the
KRB-PRIV message must be encrypted in the subsession key, and that the
AP-REQ message must specify a subsession key.

Is it a deliberate design choice to no longer use the subsession key?
There are certainly some issues with permitting the client to choose a
subsession key, but an analysis of those issues that leads to no
longer using a subession key would also lead to a design decision to
prohibit the client's choosing of an encryption key (rather than a
password).

Also, we have the following paragraph:

   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
   1510bis.

This is inconsistent with what I recall of the Horowitz draft, since
in that document, there is no additional 4 octet length header in
addition to the 16 bit length header in the actual message.  This may
cause backwards-compatibility issues.

If we are to use DER for the encoding of the ChangePasswdData, the
sentence below

   The user-data component of the message consists of the following
   ASN.1 encoded structure:

should be changed as follows:

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

in order to make clear that DER is to be used and that
ChangePasswdData is the top-level type to be encoded into the KRB-PRIV
message.

For KeySequences, we have this:

    KeySequences :: = SEQUENCE OF KeySequence

which, according to the ASN.1 syntax, may be an empty "SEQUENCE OF".
Do we wish to permit this?  If so, we should clearly specify the
semantics of the server receiving such a message.  If not, we should
constrain it to contain at least one KeySequence, as follows:

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

For ChangePasswdData, we have a problem with the comment describing
the flags field of ChangePasswdData:

    ChangePasswdData :: =  SEQUENCE {
                         -- intervening stuff deleted
                        flags[3]             RequestFlags OPTIONAL
                          -- 32 bit string
                        }

which is inconsistent with a DER encoding of the following:

    RequestFlags :: = BIT STRING {
                      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
    }

I am somewhat surprised, as people at Microsoft originally discovered
the issue with respect to DER encoding of BIT STRINGs with named bits.
If we wish to be consistent with the deployed base of RFC 1510, we
should define RequestFlags as follows:

    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

This requires that at least 32 bits be transmitted in the encoding;
DER requires that if the bits are named, all trailing zero bits are
removed from the encoding.  In any case, the definition of
RequestFlags should be self-consistent in this internet-draft, or it
should be consistent with the deployed base of RFC 1510 and the
revisions we are considering to the KerberosFlags type in 1510bis.

If the decision is made to retain the named bits, a very clear warning
should state that the encoding of the flags must truncate the trailing
bits as required by DER, which is different from what current
implementations of RFC 1510 generate or accept.

On a semantic note, we should consider whether it is wise to permit a
client to explicitly set a key that it claims is a random key.  We may
wish to permit sites to set a policy to prevent this while allowing
KDC-generated random keys.  In the protocol as described, there is no
easy way for the KDC to give the client a random key generated on the
KDC and to require that the client use that key thereafter.  The
closest that an implementation can come to allowing that sort of
policy under the protocol as described is to prohibit the setting of
an explicit encryption key that was not originally generated on the
KDC itself, which would require some moderately hairy caching behavior
on the KDC.

---Tom

---

From: Sam Hartman <[email-masked]>
Date: 17 May 2001 21:17:56 -0400

>>>>> "Tom" == Tom Yu <[email-masked]> writes:

I'd first like to echo the concerns about using ASN.1.  As far as I know,  we have never had a consensus to use ASN.1, but have in the past not quite had a consensus against.
    Tom> must truncate the trailing bits as required by DER, which is
    Tom> different from what current implementations of RFC 1510
    Tom> generate or accept.

    Tom> On a semantic note, we should consider whether it is wise to
    Tom> permit a client to explicitly set a key that it claims is a
    Tom> random key.  We may wish to permit sites to set a policy to
    Tom> prevent this while allowing KDC-generated random keys.  In
    Tom> the protocol as described, there is no easy way for the KDC
    Tom> to give the client a random key generated on the KDC and to
    Tom> require that the client use that key thereafter.  The closest
    Tom> that an implementation can come to allowing that sort of
    Tom> policy under the protocol as described is to prohibit the
    Tom> setting of an explicit encryption key that was not originally
    Tom> generated on the KDC itself, which would require some
    Tom> moderately hairy caching behavior on the KDC.

Agreed.  I believe this is a significant problem (and is the problem I
referred to at the last IETF but never wrote up).  I believe this is
the policy we want to strongly encourage sites to use.

The client should be able to contribute randomness, but even in the
case of a malicious client, the client should not be allowed to choose
the final key.

Constructing a protocol that allows this but is fairly resistant to
crashes is difficult, but I believe worth doing.

We might for example have the KDC send a cookie along with the key it
has chosen, and the client after writing out the key sends in a change
request with the cookie that could potentially prove the key is
permitted by the KDC.

---

From: Jonathan Trostle <[email-masked]>
Date: Thu, 17 May 2001 21:33:13 -0700

>prohibit the client's choosing of an encryption key (rather than a

The concern at the Pittsburg IETF was that the client may not be able to
generate a strong key. If the subsession key is used to encrypt the
KRB_PRIV message, and it is a weak key, then the new password or keys are
vulnerable.
That was why I switched to using the session key. But some clients may be
able to generate a strong key, so it doesn't seem necessary to always
prohibit clients from generating keys. For clients that cannot generate
strong keys, the request-srv-gen-keys option can be used.

>cause backwards-compatibility issues.

I think this is/was consistent with the kerb-revisions for TCP usage at one
point.

>   the ChangePasswdData ASN.1 type described below:

Ok.

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

Thanks.

>                           -- server will return keys

Will do.

>KDC itself, which would require some moderately hairy caching behavior

The hairy caching behaviour on the KDC seemed worth avoiding. Besides, what
is the scenario where the client wants to weaken its own key, yet is
trusted to protect that key?

Thanks,
Jonathan

---

From: Martin Rex <[email-masked]>
Date: Fri, 18 May 2001 14:24:20 +0200 (METDST)

> strong keys, the request-srv-gen-keys option can be used.

It's impossible to prevent the client from doing bad or stupid things.
The client can leak the passwords or the ticket session key or all
of them in many ways.

If you think that the client can *not* come up with sufficient entropy
but you think that the ticket session key is good, then you can
always specify how the client *should* mix the ticket session key
with his own entropy to come up with a good subsession key.

There is one obvious problem with using a ticket session key instead
of the subsession key for message protection (integrity/encryption),
which is that successor communications authenticated with a cached
kerberos ticket will be vulnerable to a message replacement
attack with messages from the previous session based on the
same ticket.  I don't know whether that is an issue for
the particular case here, but in general this potential vulnerability
should not be ignored -- i.e. every use of the session key for
message protection should indicate why it is *not* a problem
-- or not do it for the risk of giving a bad example.

-Martin

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 18 May 2001 09:10:30 -0500

The two week period for the WG last call of draft-ietf-cat-kerberos-set-passwd-05.txt
has ended. 

There has been quite a bit of discussion, most in the last three day. There appears
to be a number of outstanding technical questions, which leads the chair to conclude
that there is NOT consensus to move this draft forward at this time. 

But with some work these issues could be resolved, and we could have another
last call prior to London. 

I would like to try an summarize the issues:

   o ASN.1 or not. I heard a lot of grumbling, but no real technical opposition.
     The introduction of CHOICE was the biggest complaint, so I would like to 
     ask it there is any way to remove this. Could there be two separate message types?
     Could the two choices be listed as optional, but with the stipulation that
     one and only one should be present? i.e. can we kept the ASN.1 constructs
     to the subset of ASN.1 used in 1510? 

   o The BER/DER encoding rules need to be specified. DER is what is specified in 1510
     so there appears to be agreement on DER. 

   o Should the password be UTF8? Sounds like it should. 

   o Ken Raeburn had many good comments about salt type, entropy and choice of 
     the kadmin/setpw principal name. All of these need to be addressed.

   o Tom Yu also had many good comments about the ASN.1, and the flag bits. These
     need to be addressed, and as Tom suggested, kept compatible with 1510.

   o Tom's comments on the use of the subsession key and questioning the ability
     of the client to generate keys needs to be addressed. 

--

---

From: Martin Rex <[email-masked]>
Date: Fri, 18 May 2001 21:44:52 +0200 (METDST)

Martin Rex wrote:
> 
>   - dynamically allocate exactly one chunk of memory of
>     size  len = sizeof(struct passwd_set_change_s) + p_len - 8
> 
>   - clear the beginning of that chunk and copy the received pdu
>     into that buffer at offset sizeof(struct passwd_set_change_s)

nitpicking myself: the "whole" PDU includes the two bitfields
and therefore one would use
         len = sizeof(struct passwd_set_change_s) + p_len
without the -8

-Martin

---

From: Jonathan Trostle <[email-masked]>
Date: Fri, 18 May 2001 12:52:59 -0700

>with his own entropy to come up with a good subsession key.

Right. If I recall correctly the MIT implementation seeds the subsession
key with the session key.

>attack with messages from the previous session based on the

Actually a pretty good point. There is no problem with change operations
since the tickets won't be cached. But there is a problem with set
operations. So I will change the spec. to say the client SHOULD use the
session key as one of the inputs into the generation of the subsession key.
The subsession key will be used to encrypt the KRB_PRIV message.

Additionally, I will specify that the timestamp and usec fields in the
KRB_PRIV message MUST be present and MUST be copies of the same fields from
the authenticator in the AP_REQ message.

Thanks,
Jonathan

---

From: Martin Rex <[email-masked]>
Date: Fri, 18 May 2001 21:59:35 +0200 (METDST)

Martin Rex wrote:
> 
> struct passwd_set_change_s {
>    char   * target_name;
>    char   * target_realm;
>    uint32   request_flags;
>    char   * newpasswd;
>    char   * oldpasswd;
> };

Hmmm.  I should add explicit length fields for all the strings here,
Kerberos target_name and target_realm are allowed to contain binary 0
characters when I remember correctly.

A protocol spec should distinguish octet string (kerberos name and realm)
and printable string (old and new password) and define that octet strings
may contain binary nuls and every character counts while printable strings
are UTF8-encoded and must not contain nuls, in particular no trailing nuls.
While being octect strings, the kerberos name and realm should be
UTF8 as well...

Anyway -- is there any interest in pursuing such an alternative
non-ASN.1 encoding?

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 18 May 2001 21:32:36 +0200 (METDST)

Thanks for the summary.

Douglas E. Engert wrote:
>    o ASN.1 or not. I heard a lot of grumbling, but no real technical
>      opposition.  The introduction of CHOICE was the biggest complaint,
>      so I would like to ask it there is any way to remove this.
>      Could there be two separate message types?  Could the two choices
>      be listed as optional, but with the stipulation that one and only
>      one should be present? i.e. can we kept the ASN.1 constructs

My "technical" opposition was that only very few people have the
necessary expertise to use ASN.1 and *not* hurt themselves and others.

It takes experts to spot the hidden treasures (problems) that are not
visible to mere mortals and ASN.1 illiterates like me, but what really
scares me is that they were not visible to the document authors either,
*NO* deja vue with the bitfield.
I'm really glad that Tom Yu finally looked at the document.

One possible approach to remove the CHOICE is to create two seperate
"protocol versions", with an almost identical top-level structure
one for changing/setting the password and one for setting keys
-- which is what the CHOICE seems to do in the middle of the
protocol unit instead of using the protocol version to do the switch.

This would help the non-ASN.1 implementors and they could reuse their
parser for the top level structure.  The ASN.1 guys would have to
duplicate the top-level structure, but they don't seem to care about
code size anyway.

I'm still willing to make an ASN.1-free proposal over the weekend.
But if the majority of the working group wants to stick with ASN.1
then I can as well spent the weekend with my family.

My approach to for transfer encoding would be something like this:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  contents  bit-field (32-bit big endian)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  criticality bit-field (32-bit big endian)                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  length-a (16-bit big endian) |   element-a                   /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /    element-a continued (lengh-a octets)                       /
      /                                                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /               | length-b (16-bit big endian)  |  element-b    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /    element-b continued (lengh-b octets)                       /
      /                                                               /
        .............

      /          tail of element-n                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Now the individual bits in the content bitfield are assigned to
known data elements/structures, and the parser starts processing
the contents bitfield from bit 0 to 31 and each time it finds a "0" bit,
it means that this element is not contained in the body and if it finds
a "1"-bit it parses the data element from the body (beginning after the
criticality bitfield) by first reading the 16-bit length field and then
reading the indicated amount of octets.

After decoding it can be decided if all relevant information was
transferred and optional default values can be added for values that
were not transferred.

A parser for this is extremely easy to write, small, fast and robust.
* simple parser functions for the basic datatypes, probably
  an octet-string and 8-bit, 16-bit and 32-bit integers are sufficient
  for this protocols, more are conceivable.
* a loop accross the contents bitfield that sets the pointers to
  the next element when a present-bit is found
* a switch( bit-number ) to process/copy recognized elements
  into the local representation
* for backwards compatibility with old implementation upon
  extension of the protocol: unrecognized elements are ignored when
  the assiciated criticality-bit is 0, otherwise it means that
  we definitely cannot process the request and return an error

e.g.: picking the password-set/change protocol

 /* Assignment of bits for content bitfield */
#define FIELD_TARGETNAME   (1<<0)
#define FIELD_TARGETREALM  (1<<1)
#define FIELD_FLAGS        (1<<2)
#define FIELD_NEWPASSWD    (1<<3)
#define FIELD_OLDPASSWD    (1<<4)

#define ERROR_RETURN(x)    { rc = (x); goto error; }
#define SAFE_FREE(x)     if ( 0!=(x) ) { free(x); (x)=0; }

int
parse_passwd_change_set_pdu( unsigned char              * p_ptr,
			     size_t                       p_len,
			     struct passwd_set_change_s * pp_rval )
{
   int               i;
   uint32            content_bits;
   uint32            critical_bits;
   unsigned char   * end;
   unsigned char   * elem;
   size_t            elem_len;
   int               field;
   int               rc = 0;

   /* clear return value */
   memset( pp_rval, 0, sizeof( *pp_rval ) );

   if ( p_len < 8 )
      ERROR_RETURN(-1);

   content_bits  = (p_ptr[0]<<24) + (p_ptr[1]<<16) + (p_ptr[2]<<8) + p_ptr[3];
   critical_bits = (p_ptr[4]<<24) + (p_ptr[5]<<16) + (p_ptr[6]<<8) + p_ptr[7];
   end      = p_ptr + p_len;
   elem     = &(p_ptr[8]);
   elem_len = 0;

   for ( i=0 ; i<32 ; i++ ) {
      field = (1<<i);
      if ( 0==(content_bits & field) ) continue;   

      if ( elem + 2 ) > end )
	 ERROR_RETURN(-2);

      elem_len  = (elem[0]<<8) + elem[1];
      elem     += 2;

      if ( elem + elem_len > end )
	 ERROR_RETURN(-3);

      rc = 0; /* prepare common error handling after switch */

      switch( field ) {

        case FIELD_TARGETNAME:
		rc = copy_octet_string( elem, elem_len, &p_rval->target_name );
		break;

	case FIELD_REALMNAME:
		rc = copy_octet_string( elem, elem_len, &p_rval->realm_name );
		break;
		  
	case FIELD_FLAGS:
		rc = copy_int32( elem, elem_len, &p_rval->request_flags );
		break;

	case FIELD_NEWPASSWD;
		rc = copy_string( elem, elem_len, &p_rval->new_passwd );
		break;

	case FIELD_OLDPASSWD:
		rc = copy_string( elem, elem_len, &p_rval->old_passwd );
		break;

	default:
		if ( (critical_bits&field) )
		    ERROR_RETURN(-4);
		break;

      }

      if ( 0!=rc )
	  goto error;

      elem += elem_len;

   }

   if ( 0!=rc ) {
	SAFE_FREE(p_rval->target_name);
	SAFE_FREE(p_rval->realm_name);
	SAFE_FREE(p_rval->new_passwd);
	SAFE_FREE(p_rval->old_passwd);
	memset(p_rval, 0, sizeof(*p_rval));
   }

   return(rc);

}

One of the things that I don't like about ASN.1 is that most parsers
allocate tons of small objects and fragment memory like crazy.
Now if you have a multithreaded architecture, this heavy calling
of malloc()/free() has the overhead of an additional synchronization
object.

The above parser can be optimized easily:

 - use a datastructure like this:

          size_t   target_name_len;
          char   * target_realm;
	  size_t   target_realm_len;
          uint32   request_flags;
          char   * newpasswd;
	  size_t   newpasswd_len;
          char   * oldpasswd;
	  size_t   oldpasswd_len;
      };

  - parse the contents by assembling the Integers and
    just memorizing begin and length of all string/octet string objects

  - for cleaning up its just one single piece of memory
    that has to be free()d

... people who do care about code size, robustness, speed, dynamic
memory footprint should get the idea by now.

-Martin

---

From: Jonathan Trostle <[email-masked]>
Date: Fri, 18 May 2001 14:21:26 -0700

At 09:10 AM 5/18/01 -0500, you wrote:
>The two week period for the WG last call of 
>draft-ietf-cat-kerberos-set-passwd-05.txt
>has ended. 
>
>opposition.

I will remove CHOICE. Your suggestion makes sense.

Will do.

Will do.

>     the kadmin/setpw principal name. All of these need to be addressed.

kadmin/setpw is needed since changepw tickets are not cached. I can add
words to handle his entropy issue.

Will do.

>     of the client to generate keys needs to be addressed. 

Will change to subsession key per my email to Martin Rex.

There is one thing I'm not sure on: 4 byte TCP header - is that still part
of kerb-revisions? Tom Wu raised an issue on backwards compatibility here.

There is one other comment that you did not mention: Sam Hartman's comment
regarding having the KDC require the request-srv-gen-keys option. This
requires having the KDC keep state and is problematic. I can think of some
easy DoS attacks here as well. I previously asked him for a scenario where
this is useful and have never received a response. So I don't plan to make
a change to the spec. here.

Jonathan