Subject: last call comments: draft-ietf-krb-wg-kerberos-set-passwd, part I

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sat, 13 Jan 2007 02:02:48 -0800

1.	Section 3. Please expand on the first use of the word RPC.

2.	Section 3. "All protocol data is wrapped KRB-PRIV messages"
                                               ^ 
                                             Missing "in" here
3.	Section 3.1.1. "Requests and responses are exchanged using the
same framing as in
  [RFC3244], but with the following differences:"
   The wording here sounds like it is updating 3244. That won't work
because this ID is on the stands track. Can you describe the framing and
make this self contained? You can describe the difference in an
appendix.
4.	Section 3.1.1. The wording seems to discourage new AP-REQ
exchanges. What is the rationale?
5.	Section 3.2.1. It is not clear to me if a larger major version
is preferred over lower version #s. please clarify.
6.	Section 3.3. On the INITIAL flag. Should the server enforce the
"initial" flag with a MUST? Can you describe the threat model of
enforcing the INITITAL flag.
7.	Language tag negotiation: "Clients MAY expect such server
behavior and send the language tag lists only once per-TCP session".. Do
you intend that there are multiple messages (more than 2) per-TCP
session? Please clarify.
8.     On the extensibility: I support Love's suggestion, there should
be extensibility points based on typed-holes.

--Larry

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 19 Jan 2007 13:47:07 -0600

> 1.	Section 3. Please expand on the first use of the word RPC.

Sure.

> 2.	Section 3. "All protocol data is wrapped KRB-PRIV messages"

*nod*

>    The wording here sounds like it is updating 3244. That won't work

It isn't -- it's copying it by reference.

> make this self contained? You can describe the difference in an

Good point -- the copy has to be by value.

> exchanges. What is the rationale?

That they are expensive (specifically: the replay cache requirement is a
big pain and slows things down).  Most users of this protocol won't need
to do more than one or two operations at a time and only rarely, but
administrators doing password-reset type operations will presumably make
use lots of operations every day.

> is preferred over lower version #s. please clarify.

Toss a coin.  I don't care.

> enforcing the INITITAL flag.

I'm not sure what you're asking.  The text says SHOULD, and the
rationale is that use of INITIAL tickets complicates administration in
multi-realm environments.

A requirement that INITIAL tickets be used is good for principals acting
on themselves (e.g., changing their passwords) because this allows KDC
implementations to limit users with expired passwords to INITIAL tickets
for the password changing service, which in turn simplifies KDCs because
the password expiration check need only be done in the AS.

Is there a threat model that justifies requiring the use of INITIAL
tickets here?  Did MIT document one regarding kadmin/kadmind's use of
INITIAL tickets?

> you intend that there are multiple messages (more than 2) per-TCP

Yes!

> be extensibility points based on typed-holes.

I agree as well, and I'll remove the extensibility markers gladly.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 19 Jan 2007 17:31:17 -0500

> I agree as well, and I'll remove the extensibility markers gladly.

<div role=participant>

These really have separate purposes, and I think the existing document does 
the right thing for both.

Extensibility markers are there to allow a future version of the protocol 
to have more fields without ending up in a situation where an older peer 
discards packets because they don't parse correctly.  We ran into this 
problem in a major way with RFC1510, which is why kerberos-extensions 
essentially has all-new messages instead of reusing existing ones with a 
few new fields.  I am quite wary of defining a new Kerberos-related 
protocol which uses ASN.1 without extension markers.

Typed holes are for allowing people to independently define extensions to 
the protocol.  I believe this protocol already has the only typed holes it 
needs; specifically, the choices in the Op-req, Op-rep, and Op-err messages 
are context-tagged and have extensibility markers, which essentially means 
they are typed holes, though not opaque ones (another term for "typed hole" 
is "discriminated union").  Similarly, the spaces for error codes and 
password quality codes are both extensible.

Incidentally, I would prefer to see error and pw quality codes defined by 
number, rather than as enum's, so that it is clear what values are used and 
that they cannot simply be re-sorted in a future protocol version.  These 
should also probably be the subject of IANA registries.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 19 Jan 2007 17:33:58 -0600

On Fri, Jan 19, 2007 at 05:31:17PM -0500, Jeffrey Hutzelman wrote:
> discards packets because they don't parse correctly.  [...]

I would agree, but in the case of this protocol extensibility by
addition of new operations should suffice (even if it leads to a
proliferation of slightly different varianst of the same operation over
time).  If relying only on typed holes for extensibility would help
implementors, then let's.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 19 Jan 2007 19:21:22 -0500 (EST)

> implementors, then let's.

I think it would be reasonable to eliminate the extensibility markers from
the various {Req,Rep,Err}-* types.  I do think that Request, Response, and
Error-Response need to be extensible, though.