Subject: Re: updated kerb chg/set passwd draft

From: Ken Raeburn <[email-masked]>
Date: 22 Jun 2001 14:44:57 -0400

*sigh* I've gotten nearly a month behind on IETF mail.  Now that I get
back to it, not only is there a new draft, but the last-call is
concluded.  Very careless of me.

Jonathan Trostle <[email-masked]> writes:
> 4 byte TCP header is left as is to allow TCP pipelining of set requests.
> Any comments here?

I still think it would've been better IMO to actually specify that
multiple requests may be sent over one TCP session.  Given the text:

        The protocol consists of a single request message followed by
        a single reply message.

I would probably assume that the TCP implementation would have one
such exchange per session, if not for our discussions here.  I
recognize it doesn't explicitly say so, but it doesn't say multiple
exchanges are permitted either, so in writing a client I'd probably
assume that not all servers would permit it, and for simplicity
probably wouldn't try to do it at all.

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

This imposes new requirements on the RFC 1510 protocol implementation
-- the KRB_PRIV handling must now make address checking an option.
More concretely, implementing this recommendation for this protocol
that is an application of the Kerberos protocol will require changes
in the MIT implementation of the Kerberos protocol.  (Easy changes,
yes, but at a level where they shouldn't be required for a Kerberos
application.)

Specifying a particular dummy address (0.0.0.0?) to be used, always or
as an option, probably would've been less of an imposition; since we
don't specify how a KRB_PRIV message must be encoded within
application protocols, the implementation would presumably have to
accept a buffer, address, and other data from application-level code.

Yes, one of the revisions of RFC 1510 (presumably the second) will
make the address optional, and then perhaps implementations will have
to let us indicate that the address shouldn't be checked even if it's
supplied (though I wouldn't bet money on it without some more time to
think about it -- wouldn't including the optional address suggest that
checking really is desired?), but this document is specified for use
with RFC 1510.

Ken

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 22 Jun 2001 16:15:08 -0500

Sorry, Ken. Since all your concerns I thought where addressed with the
revised draft, and you did not say anything, we went ahead. 

We need to discuss the use of addresses in the Revisions at the London meeting.
Hope you can make it. 

(P.S. I will be on vacation next week, and not responding to mail.)

-- 

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