Subject: draft-ietf-krb-wg-kerberos-set-passwd-00.txt comments

From: "Joel N. Weber II" <[email-masked]>
Date: Sat, 12 Jul 2003 13:33:48 -0400

It might be useful to have the security considerations section talk
about what the advantages of having sequence numbers are.  (And is it
more lot more important with RC4 than with any of the standards-track
enctypes?)  On the other hand, maybe that belongs in the security
considerations section of the main Kerberos spec rather than in the
set-password document.

The whole thing with supporting both TCP and UDP confuses me a lot.
Is there any good reason to support UDP at all, given that it looks
like perhaps you really want to use TCP to be able to deal with the
complex requests?  It sounds like a client that wants to do UDP has to
know how to fall back to TCP, and a server has to support TCP which is
more state-intensive than UDP.

The set key request has the unfortunate property that someone doing a
DoS attack can leave the client in a state where it doesn't know the
new key, and the server has already changed the key.  A DoS forcing
you to retry an operation is not something we can fix, but we can
prevent a DoS from leaving long-term state broken.  (The fix is to
have the client send an ack to the server after it recieves the key,
and having some way to negotiate this cleanly if people have already
deployed that which is in the draft.)

The way to fix downgrade attacks is probably to wait until we have
extensions allowing for cryptographically-protected errors, and a way
that clients can know that the KDC supports extensions in a
downgrade-attack-proof fashion, and then have a unique principal name
which is only ever used for set-change-password-v2.  Then you only
downgrade if you learn that that principal doesn't exist, and then the
only hard thing is making sure realm administrators actually notice
that they should create the principal when they upgrade.

If a single program supports more than one password changing protocol,
it should probably also have a configuration option to specify which
protocols it should be willing to use with each realm.

If you're going to do an initial ticket request from the KDC anyway,
and if the client needs to get a sequence number from the password
changing server before sending the request anyway, there's no ``but
it's another round-trip excuse'' for not supporting the use of a nonce
from the password changing server in the authorization data field of
the ticket to remove clock issues.  Alternatively, you could require
the initial ticket to come from the master KDC, and just have the KDC
magically know to put a nonce into the ticket, and then you don't need
to modify the client or the protocol at all.

Security considerations should talk about the implications of being
able to get initial tickets from a slave KDC using the an old key and
then running the key change function when there is database skew
because propagation hasn't yet happened.

Given that you have to send your old password when changing a
password, is it necessary to require INITIAL tickets for that case?
Why is the password sent if you're requiring INITIAL tickets?  And how
does an administrator account change another principal's password if
it has a password and not a keytab?

Security considerations should discuss the implications of not having
perfect forward secrecy.

This text:

   The server MUST reject requests that operate on the same principal as
   the client's if the client's principal is not in the same realm as
   the server's principal name or if the client's ticket is not
   INITIAL.

seems somewhat unfortunate with respect to cross-realm keys.  It
appears that it prohibits the administrator of FOO.EXAMPLE.COM who has
no special privileges on BAR.EXAMPLE.COM from changing the key for
krbtgt/[email-masked] in BAR.EXAMPLE.COM's database.

This paragraph:

   Typed holes are not used in this protocol as it is very simple and
   does not require the ability to deal with abstract data types defined
   in different layers.  For this reason, the only way to extend this
   protocol is by extending the ASN.1 module within the framework of the
   IETF; all future extensions to this protocol have to be defined in
   IETF documents unless otherwise specified in a future IETF revision
   of this protocol.

should probably say MUST rather than ``have to be''.

---

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

>>>>> "Joel" == Joel N Weber <[email-masked]> writes:

    Joel> It might be useful to have the security considerations
    Joel> section talk about what the advantages of having sequence
    Joel> numbers are.  (And is it more lot more important with RC4
    Joel> than with any of the standards-track enctypes?)  

I don't think it is more important with rc4.  The Microsoft rc4 spec
is a really well done use of rc4 and I believe it successfully turns
rc4 into a block cipher.

The implementation of cipher state in the MIT RC4 implementation does
weaken things slightly for rlogin and anything else that actually uses
cipher state.  But besides the weak md4-based string2key function, the
rc4 enctype seems strong against the attacks we currently know.

I don't think sequence numbers are needed, but it reduces thrashing on
the replay cache.  I think that the preference for sequence numbers in
not a security preference.

    Joel> The whole thing with supporting both TCP and UDP confuses me
    Joel> a lot.  Is there any good reason to support UDP at all,
    Joel> given that it looks like perhaps you really want to use TCP
    Joel> to be able to deal with the complex requests?  It sounds
    Joel> like a client that wants to do UDP has to know how to fall
    Joel> back to TCP, and a server has to support TCP which is more
    Joel> state-intensive than UDP.

Mee too.

    Joel> The set key request has the unfortunate property that
    Joel> someone doing a DoS attack can leave the client in a state
    Joel> where it doesn't know the new key, and the server has
    Joel> already changed the key.  

Yes.  Not having this attack was (if I remember correctly) an explicit
requirement of the protocol.

    Joel> The way to fix downgrade attacks is probably to wait until
    Joel> we have extensions allowing for cryptographically-protected
    Joel> errors, and a way that clients can know that the KDC
    Joel> supports extensions in a downgrade-attack-proof fashion, and

I don't think there is such a way.

    Joel> If a single program supports more than one password changing
    Joel> protocol, it should probably also have a configuration
    Joel> option to specify which protocols it should be willing to

    Joel> use with each realm.

Disagreed.  There was a discussion of this on krbdev a while back.
Basically having a bunch of configuration options makes technology
harder to deploy.

I could agree with MAY have a configuration option, not SHOULD.

    Joel> If you're going to do an initial ticket request from the KDC
    Joel> anyway, and if the client needs to get a sequence number
    Joel> from the password changing server before sending the request
    Joel> anyway, there's no ``but it's another round-trip excuse''
    Joel> for not supporting the use of a nonce from the password
    Joel> changing server in the authorization data 
    Joel> field of the
    Joel> ticket to remove clock issues.  

But there is we're using Kerberos and Kerberos doesn't do that issue.

    Joel> Security considerations should talk about the implications
    Joel> of being able to get initial tickets from a slave KDC using
    Joel> the an old key and then running the key change function when
    Joel> there is database skew because propagation hasn't yet
    Joel> happened.

You seem to assume there is a slave kdc not multi-master.  But I agree
with your point if restated properly.

    Joel> Given that you have to send your old password when changing
    Joel> a password, is it necessary to require INITIAL tickets for
    Joel> that case?  

Consider hardware preauth.

    Joel> Why is the password sent if you're requiring
    Joel> INITIAL tickets?  
So you can add the password to password history tables etc etc.

    Joel> Security considerations should discuss the implications of
    Joel> not having perfect forward secrecy.

Or have PFS;)

---

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

> considerations section of the main Kerberos spec rather than in the

Sequence numbers are required when running this protocol over TCP.

> more state-intensive than UDP.

Compatibility was the reason.  However, it may well be worth dropping
UDP altogether.

There is no situation in which TCP is a requirement; TCP is a more an
optimization than anything else.

For example, changing the keys of several principals in a short space of
time would require fewer AP-REQs if the set-passwd protocol is run over
TCP than it would if run over UDP.

Another example: password changes can require multiple round-trips (1st
password fails the pw quality policy one way, 2nd another, ...); when
running the set-passwd protocol over UDP each round-trip requires an AP
exchange.

> deployed that which is in the draft.)

Agreed (and no, noone's deployed the protocol described in this version
of the I-D).

> that they should create the principal when they upgrade.

But we can't wait.  The downgrade attack here (version 2 -> version 1)
is not exactly the sort that leads to security compromises (I think) -
but it could be annoying.

Another way to fix it would be to fix deployed implementations of v1 and
rfc3244 and then set a flag for v2 implementation indicating whether
they should allow un-protected downgrades.

> protocols it should be willing to use with each realm.

And whether it should expect protected or unprotected un-supported
version replies.

> to modify the client or the protocol at all.

Please, let's not conflate issues here.  I myself am not willing to go
with fundamental changes to the Kerberos protocol made outside the
context of the Kerberos extensions work that we very much want to get
started on soon enough.  I consider this proposal to be a fundamental
change to the way Kerberos AP exchanges work.

> because propagation hasn't yet happened.

Hmmm, ok.

> password, is it necessary to require INITIAL tickets for that case?

Good question.  Partly because the protocol as it stands would allow
one principal to change another's password (provided it authorized to do
so).  I.e., the client principal of the AP-REQ and the target principal
need not be the same.

> Why is the password sent if you're requiring INITIAL tickets?  And how

For password quality checking purposes.  Having the old password also
facilitates the implementation of password synchronization from the KDC
to other systems.

> it has a password and not a keytab?

I don't understand this question.

> Security considerations should discuss the implications of not having

I disagree.  Future extensions to Kerberos may add perfect forward
security in a way that is backwards compatible with existing protocols
that use Kerberos AP exchanges.  Perhaps clarifications' security
considerations should mention the lack of PFS (perhaps it does - I'll
check later).

> krbtgt/[email-masked] in BAR.EXAMPLE.COM's database.

Correct.

Perhaps others too will find this obnoxious or unnecessary; perhaps the
"MUST" there should be changed to "MAY."

> should probably say MUST rather than ``have to be''.

If typed holes were provided then 3rd parties could be allowed to extend
the protocol without IETF action (but with IANA action, perhaps,
depending on how the structure of the type ID [e.g., INTEGER vs. OID vs.
Relative-OID]).  But since no provision is made for extensibility
outside the IETF process it should be clear that extensions could only
be pursued within the IETF, as with most proposed standard and standard
protocols.  I don't think a "MUST" is needed here.

Cheers,

Nico
--

---

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

>     Joel> state-intensive than UDP.

Sam> Mee too.

I'd be more than happy to get rid of the UDP case and get ird of that
awful framing for any messages other than the initial ones (for version
negotiation).

Initially I thought it'd be worthwhile to support version negotiation
and to have backwards compatibile framing.  Eventually it became clear
that version negotiation could not be done safely without also fixing
deployed implementations, and so there's less incentive to keep UDP in
the mix.

> requirement of the protocol.

I don't remember that, but I'm not opposed to fixing this.

I'll have this fixed in -01, sometime after the meeting.

> I could agree with MAY have a configuration option, not SHOULD.

Yes, as long as the insecure version negotiation problem does not cause
security problems.

Cheers,

Nico
--

---

From: "Joel N. Weber II" <[email-masked]>
Date: Mon, 14 Jul 2003 12:14:55 -0400

I think that if nobody can propose text explaining in which
circumstances the use of UDP is preferable to TCP, and vice versa, I
would advocate dropping UDP from the spec.

Would it be reasonable to say that a client MAY or SHOULD tell the
user which password changing protocol it has ended up deciding it is
going to use, possibly as a warning message when it falls back to an
older protocol?

Req-change-pw probably needs to have old-pw made OPTIONAL, at least so
that it can support password changes by an administrator who doesn't
know the old password.

The draft does talk about INITIAL tickets, in 4.4 Use of Kerberos V:

   The server MUST reject requests that operate on the same principal as
   the client's if the client's principal is not in the same realm as
   the server's principal name or if the client's ticket is not INITIAL.

As an editorial point, it would be more readable if the INITIAL ticket
issue weren't in the same sentence as the same vs different realm
discussion.

I see no evidence that the draft says anything about whether INITIAL
tickets are required for operations by an administrative principal.

I believe the only case where we might possibly want to not require
INITIAL tickets is in the case where it is known that the password is
entirely sufficient to authenticate (no preauthentication beyond the
password itself required), and a password change request is sent which
includes the old password.  I believe we should either say that a
server MUST accept non-INITIAL tickets in this case, or we should say
that it MUST NOT accept non-INITIAL tickets.

It's also not clear to me whether the draft is saying that queries
that do not change keys require INITIAL tickets.

---

From: "Joel N. Weber II" <[email-masked]>
Date: Mon, 14 Jul 2003 12:41:23 -0400

> but it could be annoying.

I think I meant to say ``we can wait on worrying about fixing the
downgrade attack'', precisely because people say there appear to not
be security problems.  I expect that we don't necessarily want to
delay set password until after extensions.

> considerations should mention the lack of PFS (perhaps it does - I'll

Is there some reason why we can't have text that acknowleges the
possibility that the underlying Kerberos spec will gain this feature
in the future?

clarifications has this text:

   The Kerberos protocol in its basic form does not provide perfect
   forward secrecy for communications. If traffic has been recorded by
   an eavesdropper, then messages encrypted using the KRB_PRIV message,
   or messages encrypted using application specific encryption under
   keys exchanged using Kerberos can be decrypted if any of the user's,
   application server's, or KDC's key is subsequently discovered. This
   is because the session key use to encrypt such messages is
   transmitted over the network encrypted in the key of the application
   server, and also encrypted under the session key from the user's
   ticket-granting ticket when returned to the user in the KRB_TGS_REP
   message. The session key from the ticket-granting ticket was sent to
   the user in the KRB_AS_REP message encrypted in the user's secret
   key, and embedded in the ticket-granting ticket, which was encrypted
   in the key of the KDC. Application requiring perfect forward secrecy
   must exchange keys through mechanisms that provide such assurance,
   but may use Kerberos for authentication of the encrypted channel
   established through such other means.

With a lot of imagination, I might be able to figure that that implies
that an attacker who already knew your old key and eavesdrops on your
key changing will be able to learn your new key.  I'm sure I wouldn't
have figured that out a few years ago without strong hints.

Who is the target audience of the security considerations sections?
(This is not merely a rhetroical question; it doesn't seem to be all
that well defined.)

---

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

> would advocate dropping UDP from the spec.

I believe MIT's kadmind supports set-pw v1 only over UDP.

IF MIT and MS had correctly implemented wrong-major-version replies
using KRB-PRIV rather than KRB-ERROR then due to v1 working only over
UDP v2 would have to support UDP as a transport in order to securely
negotiate set-pw major version.

That would be the argument for supporting set-pw v2 over UDP.

Unfortunately there appears to be no way to securely negotiate set-pw
major versions.  And I doubt that patches will be made to deployed v1
and/or rfc3244 implementations to fix the problem.

Therefore I think that: a) getting rid of UDP as a transport for set-pw
v2 is ok, b) using a different port number for set-pw v2 is ok, and c)
getting rid of the framing from v1/rfc3244 is ok.

Ideally we will either agree to a way to securely negotiate set-pw
major versions or to (a), (b) and (c).

Also, draft-ietf-krb-wg-kerberos-set-passwd-00.txt is based on
draft-ietf-cat-kerberos-set-passwd-06.txt, whence much of the UDP and
framing stuff came.

> going to use, possibly as a warning message when it falls back to an

Perhaps.  Could the user reasonably do something with the information?

> that it can support password changes by an administrator who doesn't

Yes.  Will fix.

> issue weren't in the same sentence as the same vs different realm

Ok.

> tickets are required for operations by an administrative principal.

The draft does not say much about administrative principals.

> that it MUST NOT accept non-INITIAL tickets.

Also, we may need a way to deal with changing hw-preauth parameters.

> that do not change keys require INITIAL tickets.

A distinction between idempotent and non-idempotent requests could be
made.

Cheers,

Nico
--

---

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

> delay set password until after extensions.

If we can wait then we may not want to get rid of UDP as a transport or
get rid of the framing or change the port number.

> clarifications has this text:

[...]

> have figured that out a few years ago without strong hints.

We've known this was a problem with Kerberos for a long time.  PFS would
fix it, yes.

Normally I would say that this lack of PFS should be noted in
clarifications and should not be repeated by every spec that refers to
clarifications.

That said, I think yours is a convincing argument for either adding PFS
to the set-pw protocol or for making special note of the issue in the
set-pw I-D.

Note, if we end up deciding that we don't care for UDP as a transport,
or port 464 or the framing from v1/rfc3244, then we might as well
consider running this over SSHv2 as the transport ;)

> (This is not merely a rhetroical question; it doesn't seem to be all

The I-D nits page says:

"Security Considerations section
      Must have meaningful exploration of security issues raised by
      proposal, should include both risks and description of solutions
      or workarounds
"

Cheers,

Nico
--

---

From: "Joel N. Weber II" <[email-masked]>
Date: Mon, 14 Jul 2003 13:01:33 -0400

> Perhaps.  Could the user reasonably do something with the information?

Depends on the user.

The average user of an Athena workstation at MIT is going to ignore
that sort of warning.

But I would react to seeing that warning by wondering why I am getting
it, I think, and if there was a misconfiguration of my KDC that could
cause that, I would probably notice and fix it, and otherwise I'd
probably assume there was buggy code or an attacker or something.

> Also, we may need a way to deal with changing hw-preauth parameters.

Yes, but I think we should consider this out of scope for the moment.

While it would take some time, I don't think it would be challenging
to grow this protocol to support all the administrative requests
anyone could possibly want, and I think we should instead focus on
building consensus on the basic framing issues, whether or not to
support UDP, etc.

I'm also not sure exactly what is needed in the way of hw-preauth
parameters.  It may vary somewhat with the preauth method being used.

---

From: "Joel N. Weber II" <[email-masked]>
Date: Mon, 14 Jul 2003 13:19:38 -0400

> We've known this was a problem with Kerberos for a long time.  PFS would

Who's the ``we''?

I don't think we're necessarily writing security considerations solely
for the benefit of the handful of people commenting on the spec
(although doing so with a less well understood protocol can be a valid
way to help make sure that everyone has thought about things clearly).

> to the set-pw protocol or for making special note of the issue in the

Is there clear evidence that set-pw is actually going to get
implemented substantially sooner than extensions?

> consider running this over SSHv2 as the transport ;)

``And while we're at it, we'll just use TLS with X.509 certificates to
protect the initial ticket requests.  With the option to use TLS with
krb5 instead if you prefer DCE-RFC-26 functionality.''

>	  proposal, should include both risks and description of solutions

Yes.  As I'm thinking about it, the question running through my head
is ``what does `meaningful exploration' really mean?'' and I suspect
it implies that we should probably explore the implications of a lack
of PFS as it applies to password changing.  But it took thinking about
it for several minutes before I realized that meaningful exploration
might have this meaning.

I think it would be valuable for the IETF to explore what it feels the
scope of security considerations sections should be, because it seems
to not be well defined at the moment.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 Jul 2003 10:33:51 -0700

> > We've known this was a problem with Kerberos for a long time.  PFS would

The Kerberos community.

> > to the set-pw protocol or for making special note of the issue in the

Here I've conceded that we should either do something now to get PFS
into set-pw v2 or document the issue in its security considereations.

> implemented substantially sooner than extensions?

Set-pw is significantly simpler than rfc1510 alone, never mind extended
Kerberos (with its backwards compatibility requirements).

Clarifications certainly took quite a bit of time to specify and I'm not
sure we can say that it's been fully implemented yet.  I think
extensions will take some time to happen, probably some amount of time
comparable to what it took to get clarifications to the IESG.

> krb5 instead if you prefer DCE-RFC-26 functionality.''

Whatever we get consensus for.  The point was that I started from
draft-ietf-cat-kerberos-set-passwd-06.txt and kept the UDP/TCP
transport, port number and protocol framing from it, more or less, in
great part to make set-pw version be negotiable, but if we give up on
version negotiation then we're free to make sure that the transport
provides PFS.

Though I was being somewhat facetious about SSHv2, thus the wink smiley.

> to not be well defined at the moment.

There's a mailing list for this:

http://www.ietf.org/maillist.html

Cheers,

Nico
--

---

From: "Joel N. Weber II" <[email-masked]>
Date: Mon, 14 Jul 2003 14:26:33 -0400

> > > We've known this was a problem with Kerberos for a long time.  PFS would

I don't remember actually seeing this documented in any canonical
Kerberos reference document.  (I've known about it, but only because
Sam Hartman has told me about it.  And I don't think that assuming the
reader is familiar with all the oral tradition is correct.)

But I think we've sufficiently agreed on where we're going from here.

> comparable to what it took to get clarifications to the IESG.

OK.  I think you have more perspective on this than I do.

I think if we want PFS now, rather than doing this specifically for
the set-passwd protocol only, perhaps we should think about having an
authorization-data element in the AP-REQ's authenticator that contains
the public number that the client generates, and pick some way for the
server to send its public number back to the client (probably in a
KRB-PRIV message which is sent immediately after the AP-REP).

> Though I was being somewhat facetious about SSHv2, thus the wink smiley.

Yeah, and my use of the quotation marks was also intended to be
facetious, though the use of quotation marks to mean that may well be
constrained to a certain group, and perhaps I should avoid that usage
outside of that group.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 Jul 2003 11:42:32 -0700

> reader is familiar with all the oral tradition is correct.)

The "Kerberos community" is not a formal institution either.

> KRB-PRIV message which is sent immediately after the AP-REP).

If we must have PFS now then set-pw ought to first do a DH exchange then
an AP-REQ exchange with the checksum field of the Authenticator set to
some value derived from the DH exchange (e.g., a checksum of g^x mod p
|| g^y mod p).

Extensions will give us a 1-round-trip AP exchange w/ PFS (with support
for it negotiated by by the client and the KDC on behalf of the server).

But we can live with the extra round-trip in set-pw v2 if we need DH now.

The authorization-data typed hole in the authenticator is not a good
vehicle for ad-hoc addition of same-round-trip PFS to the AP exchange.
For that we really need a typed hole in the encpart of the AP-REP and
that will have to wait for extensions.

Cheers,

Nico
--

---

From: "Joel N. Weber II" <[email-masked]>
Date: Tue, 29 Jul 2003 13:18:07 -0400

I am starting to think that if you want PFS for password changing, it
may be best to do the PFS via preauthentication.  The advantage is
that if you have the KDC's public diffie-hellman key, and you know you
have verified that out of band, and you know you trust your kerberos
binaries etc, and an attacker has your old compromised long term key,
the attacker isn't going to be able to successfully do a MitM attack
and learn your new key.

(Alternatively, we could define something so that you could use a
KDC's long term diffie hellman key later in the protocol exchange, but
that seems like it would be needless extra complexity for no gain.)

And of course, the primary benefit of diffie-hellman in AP-REQ/AP-REP
is that when the server you're talking to isn't the KDC, the traffic
becomes unreadable to someone with knowlege of all of the KDC's keys,
assuming they aren't doing a MitM attack.  Since password changing
involves talking to the KDC, I don't think there is any particular
benefit to doing diffie-hellman at the AP-REQ or a later stage instead
of doing it sooner.