Subject: comments on draft-ietf-krb-wg-kerberos-set-password

From: Sam Hartman <[email-masked]>
Date: Sun, 13 Jul 2003 04:45:42 -0400

Editorial comments:

* The table of contents appears in the middle of numbered sections.
  Before last call an author should review id-nits and rfc-editor
  instructions.

If you are going to refer to clarifications, you might as well avoid
normative references to RFC 1510.

Semantic comments:

We should consider whether using port 464 is such a great idea.  The
MIT kadmind before 1.3 did not return  wrong version errors if
incorrect version packets were sent to the kadmind.  Some versions of
the Microsoft implementation also do not support wrong version
errors.  Depending on how long we plan to take to implement the
protocol, this may or may not be an issue.

Why does the TCP version of the protocol need an additional length?

Quoting section 4.2.1:

    Both the client and server MUST destroy the authentication context
    after each operation.

The concept of an authentication context is specific to
implementations; please rephrase in terms of not reusing krb-priv
session keys.  If you find there is no easy way to rephrase this,
bring up the problem when we are rephrasing things for
kerberos-extensions.

    UDP clients MUST not request the use of sequence numbers, otherwise
    it cannot generate the KRB-PRIV prior to receiving the AP-REP.

Please see section 5.5.1 in clarifications; this claim is not true.

    Clients MAY refuse to operate version 2 of the protocol over UDP; it
    is RECOMMENDED that servers reject version 2 UDP requests.

What?  This sentence is not internally inconsistent.  If servers
SHOULD reject UDP then clients either MUST NOT or SHOULD NOT send UDP.
But why would you want servers to reject UDP anyway?

Section 4.2.2 make even more significant use of the non-existent
concept of an authentication context.  It also assumes that these
non-existent entities have expirations; they do not in the two
Kerberos implementations I know of that support the concept.

Remove the first paragraph of section 4.3.2; we can add that as part
of defining the next minor version.  Instead simply say that clients
MUST use minor version 0.

In section 4.4:

    All operations are to be performed by the server on behalf of the
    client principal.

    The client SHOULD use "kadmin/changepw" as the server principal name
    for this protocol.  The server MUST have a principal name of
    "kadmin/changepw" and MAY have a principal name of "kadmin/setpw."

We have traditionally only used the kadmin/changepw principal for
operations that should be allowed even by clients with expired
principals.  For other operations clients can use another principal,
which cannot be used as service principal by clients with expired
tickets.  Also, the Microsoft protocol allows some operations to be
performed by tickets without the initial flag set.  In short, I think
we want to think carefully about what operations can be performed by
what principals.

The current document does not indicate whether a server may require
initial tickets for all requests.  If this is going to be permitted
the document should call it out as a valid policy and indicate that
clients either SHOULD or MUST support it.  This is already sort of
done for the case where the client's principal is the same as the
target principal.

I'm uncomfortable with section 4.6.  For one thing, it is only OK to
use the language tag extension provided by extensions if the server's
application code uses the language tags it gets from the library.  It
also seems to wiggle around the version issue too much.

Section 6 includes the name-type in principalname.  Why?

Why is the major pvno included in the request in section 6?

Why do you need a null error response.

IN section 7.2:

    Clients MAY specify key enctypes to set with new passwords, but
       generally SHOULD NOT do so.  If a client requests specific enctypes
          then the server MUST NOT create keys from the new password of any
             enctype other than those requested by the client.

Why do we want to have this functionility?  Also, do we really want to
make it mandatory for the server not to generate keys outside this
enctype list.?

Why should servers not normally tell the client what enctypes are
created?

As far as I can tell, this document completely fails to deal with
atomicity of requests or with allowing a client to specify a specific
key to use with the set-key request.

I thought both of these were requirements for the protocol.

It is my understanding that we were going to deal with
atomicity/failure by returning cookies to the client whenever the
server generates a key or client.  The client would then execute a
subsequent request that included the cookie and the key and actually
made the change.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 Jul 2003 08:56:08 -0700

>   Before last call an author should review id-nits and rfc-editor

Will fix.

> normative references to RFC 1510.

Right, rfc1510 will be obsolete.

> protocol, this may or may not be an issue.

I don't think using port 464 is an issue.

> Why does the TCP version of the protocol need an additional length?

For compatibility with RFC3244 (the MS version of the set-pw protocol).

> bring up the problem when we are rephrasing things for

Or get rid of UDP as a transport for set-pw, yes (though I think there
should be no problem re-phrasing this).

> Please see section 5.5.1 in clarifications; this claim is not true.

Thank you.

> SHOULD reject UDP then clients either MUST NOT or SHOULD NOT send UDP.

"not internally inconsistent"?

The main problem with this sentence is that a client can't very much
"refuse" to try v2 over UDP since the client is the initiator and "to
refuse" implies that it would be responding to an offer [to run v2 over
UDP].

> But why would you want servers to reject UDP anyway?

Because it's not as a efficient as set-pw v2 over TCP.

Like I've said, I'm more than willing to get rid of UDP as a transport
for this protocol.

> Kerberos implementations I know of that support the concept.

Indeed.  The trouble is that the framing allows the client to send an
AP-REQ with every request over TCP; perhaps that should be fixed.

> MUST use minor version 0.

*nod*

> we want to think carefully about what operations can be performed by

Did you intend for the last sentence above to refer to the service
principals of the set-pw service?

Why do we need so many principal names for the same service?

Why should the type of request that the client wants to make have
anything to do with the service principal name for this service?

I think we should have a single service principal for this protocol.

> done for the case where the client's principal is the same as the

It's implicit in that servers can respond with a ProtocolErrorCode code
of "initial-ticket-required."

> also seems to wiggle around the version issue too much.

For this reason I used "SHOULD" and "SHOULD NOT" in the first paragraph
of section 4.6.

> Section 6 includes the name-type in principalname.  Why?

Oh, good catch.  I'll remove that.

> Why is the major pvno included in the request in section 6?

For no good reason :)  - I'll remove it.

> Why do you need a null error response.

Er, consistency?  I wanted the CHOICE tags of the "Op-*" types to be
consistent.  But yes, there can be no error response to the "null"
request.

> make it mandatory for the server not to generate keys outside this

In the past, whenever it's been useful to set the enctypes list for new
passwords it's generally been due to enctype handling bugs in legacy
Kerberos implementations.

I'm open to removing this functionality.

> Why should servers not normally tell the client what enctypes are

For the same reason that clients should not normally specify them (we're
talking about password changing, yes?  when changing keys the resulting
enctypes are always communicated to the client).

> I thought both of these were requirements for the protocol.

I do not recall this, but I do recall that we've discussed the atomicity
issue.

Is it useful for clients to set specific keys?

> subsequent request that included the cookie and the key and actually

I will add this functionality.

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 15 Jul 2003 04:16:06 -0400

Will respond in detail more later, quite possibly after the WG
meeting.

I believe that it is a requirement to be able to set specific keys.  I
know that was one of the significant features being added to the
protocol between the Microsoft version and v2.  I believe that it is
useful for realm shared keys among other things.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 15 Jul 2003 15:50:36 +0200 (CEST)

> Why do we need so many principal names for the same service?

I thought Sam was clear, but I'll try to clarify further...

Certain KDC implementations, including the MIT one, provide a flag which
can be set on a service principal that allows initial tickets for that
service to be issued even to principals whose password/key is expired.
Note that this flag does _not_ allow the KDC to issue tickets to expired
principals_; it only permits the issue of tickets to clients using expired
_keys_.

This flag is generally set on principals belonging to password-changing
services such as kadmin/changepw.  This allows a user whose password has
expired to obtain a ticket for that service, so he can change his
password.

It is important that the service be able to restrict principals using
expired keys to be able to perform only a very narrow range of operations.
For example, we want a user with an expired password to be able to change
it, but we probably don't want an admin with an expired password to be
able to rekey a critical service.

However, there is no direct mechanism for a KDC to indicate to a service
that a ticket was granted to a principal using an expired key.  So
instead, we use two service principals, only one of which
(kadmin/changepw) has the flag set, and allow client using the service
with the flag set to perform only specific operations (namely, change
their own password).  Clients wishing to perform other operations must
use the more general service principal.

> I'm open to removing this functionality.

I'd actually prefer to see it remain.  It's not so important for users
with passwords, where the particular client software being used to perform
an initial authentication will choose an enctype it supports (and for
which there is a key in the kdb) and perform a string-to-key operation.
However, it is quite important when keying a service principal, where it
is critical that the kdb contain only keys for enctypes which the server
software can actually support.

> Is it useful for clients to set specific keys?

Yes; there are a variety of cases where it is useful for a client to be
able to specify a specific key value.  Sam has pointed out one example,
where a cross-realm key must be set to the same value in the databases of
multiple realms.  Similar issues come up in other cases; for example, a
key for a user or service may be generated and stored on a cryptographic
hardware device in a fashion that does not allow the user to select an
arbitrary key.

So, it is useful to be able to set both specific and random
server-generated keys.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 15 Jul 2003 08:02:31 -0700

> use the more general service principal.

Noted.  But this service is not just any service.  Are we to expect that
the set-pw service cannot determine whether a client principal's
password is expired when it can determine all sorts of other facts about
principals and their password change history for password quality policy
checking[*]?

[*]  This I-D does not specify what kinds of pw quality policies
     implementors may provide for, so technically one ought not assume
     that stateful policies (e.g., "no pw change more often than once a
     day" or "no password reuse").  However such stateful policies are
     the norm, from what I can tell.

But I have no fundamental objection here.  If we agree on two service
principals for the set-pw service, then so be it.

> software can actually support.

I did not offer to remove enctypes from the set keys request/response,
just password changes.

And note, a KDC need only share a single key with a service, for use in
ticket encparts but it does need to know what enctypes the service
supports for use in session key enctype "negotiation."

This is something I've been mulling for a few weeks: rfc1510 Kerberos
has clients negotiate session (and sub-session) key _enctype_ with the
KDC acting on behalf of services, and extensions will have clients
negotiate additional items (e.g., support by service for extensions)
with the KDC acting on behalf of services.

Therefore it would be good to have a way for services to inform the KDC
of what features they support that the KDC needs to know about for
negotiation with clients.

I'm working on some ASN.1 for this which, as it stands, would allow
services to tell the KDC about their support for: minor Kerberos
versions (rfc1510, clarifications, '...'), enctypes, transited encoding
types and authorization data types.

> So, it is useful to be able to set both specific and random

Agreed then.  I'll add that back in.

Cheers,

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 15 Jul 2003 19:19:15 +0200 (CEST)

> I did not offer to remove enctypes from the set keys request/response,

However, it's more relevant in the case of password changes.  With a
set/change key request, the client and server must agree on the enctype(s)
of the keys which are set -- if the client is providing keys, it must
provide an enctype, and if the server generates them, it will provide an
enctype in the response.  In other words, it would be difficult to remove
the enctypes from this exchange.

In the case of a password change, the server will be using the password to
generate a set of keys, and it is desirable to be able to control for
which enctypes keys will be generated.  Obviously we _could_ remove this
feature, but I think it would be better to retain it.

> supports for use in session key enctype "negotiation."

You have hit on an important point here, which I forgot because of the
behaviour of the implementations with which I'm most familiar.  The set of
enctypes for which the kdb has keys for a service principal need not be
the same as the set which it believes the service actually supports.  It
is the latter which I believe it is important to be able to limit and/or
restrict.

> types and authorization data types.

Is this something you're working on for set/change passwd?
Following the discussion I just sat in on regarding the LDAP admin work,
I'm beginning to think maybe this belongs there...

> Agreed then.  I'll add that back in.

Wonderful; I'm glad to hear that.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 16 Jul 2003 06:31:02 -0700

> Is this something you're working on for set/change passwd?

Yes.

> I'm beginning to think maybe this belongs there...

Looking at the minutes I thought there might well be some overlap
between the set-pw work and the KDB-admin-through-LDAP work.

Just how much overlap is there?

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 16 Jul 2003 17:16:07 +0200 (CEST)

> Just how much overlap is there?

From what I heard during the LDAP discussion today, there is virtually no
overlap.  The set-pw protocol addresses only mechanisms for changing keys,
while the LDAP work seems to be specifically avoiding this area -- they
seem to be complementary, rather than competing, which I see as a good
thing.  Perhaps someone more familiar with the LDAP work can comment.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 16 Jul 2003 10:01:54 -0700

> thing.  Perhaps someone more familiar with the LDAP work can comment.

In that case I think that having a facility in set-pw by which service
principals can indicate to the KDC what Kerberos features they support
is quite appropriate, just as it is for the KDC to indicate to service
principals what principal name aliases the KDC recognizes for them.

This way you can have nodes that only talk set-pw and only for
password/key changing, and which do not talk LDAP or any other Kerberos
admin protocol and so lack the ability to perform administrative tasks
generally, but can still change their keys and, when their capabilities
are upgraded, for example, they can also tell the KDC about it.

Cheers,

Nico
--

---

From: Wyllys Ingersoll <[email-masked]>
Date: Thu, 17 Jul 2003 03:37:39 -0400

>thing.  Perhaps someone more familiar with the LDAP work can comment.
IIRC - the LDAP info discussion seemed to indicate that the key changing 
stuff would
not be part of the LDAP model, but that set-pw would be used to do key 
updates, thus
avoiding overlap.

-Wyllys

---

From: Leif Johansson <[email-masked]>
Date: Thu, 17 Jul 2003 11:00:29 +0200

Wyllys Ingersoll wrote:

> IIRC - the LDAP info discussion seemed to indicate that the key 
> changing stuff would

Yes that is the intent. I'd like to explore possible semantic overlap 
with the ldap set password
extended operation but the group hasn't made any progress on that so far.

       Cheers Leif