Subject: Comments on draft-ietf-krb-wg-kerberos-clarifications-03

From: Sam Hartman <[email-masked]>
Date: Tue, 08 Apr 2003 16:40:46 -0400

Hi.

I sent out a call for parties not involved in the IETF to review the
Kerberos spec in hopes of getting  feedback on clarity from people not
already familiar with the document for the past few years.

Joel sent me some very useful responses and I wanted to pass them
along to the working group.

I believe that we should make all the changes related to grammar and
proper use of requirements language.

The other additional comments about areas where clarification is
useful seem accurate to me.  However I think it is sufficiently late
in the process that we should hold off addressing these issues until
extensions.

--Sam

Subject: Re: Anyone willing to try and read the Kerberos protocol spec for me?
From: "Joel N. Weber II" <[email-masked]>
To: [email-masked] (Sam Hartman)
Cc: [email-masked], [email-masked]
Date: Sun, 06 Apr 2003 01:18:24 -0500

I suspect I may know too much to be your target audience for
proofreading, but here are some comments anyway.  These comments are
based upon reading through section 3, and reading section 10, and
barely skimming the rest of the document, which has taken all the time
I've been able to allocate to it across two days.  I may provide
furthur comments at some point in the future if I have the time.

The paragraph that starts out with ``In order to add authentication to
its transactions, a typical network application adds one or two
calls'' strikes me as grossly misrepresenting the complexity of the
kerberos API.

The sentence ``Secure name service facilities, if available, might be
trusted for hostname canonicalization, but such canonicalization by
the client SHOULD NOT be required by an KDC implementation.'' is
gramatically wrong, with the ``an KDC''.

I would be interested in advice on how to go about securing my network
time synchronization from network attackers, so that my kerberos
installation can meet the requirements of the RFC; my understanding is
that NTP isn't really there yet, but perhaps things have gotten better
since I was last paying attention.  It might be appropriate for the
kerberos protocol spec to reference an rfc which provides security for
NTP, or something.

I would also be interested in knowing methods for securely
synchronizing a stratum 1 clock to the real time, because as far as I
know WWV and GPS don't offer any good integrity protection.  (In fact,
there's a US Department of Transportation paper on GPS security
weaknesses that came out a couple years ago, which is interesting
reading.  But maybe I'm telling you that which you already knew.)

Given that time synchronization is hard, I think it would be good to
discuss exactly what attacks can't be thwarted by applying additional
challenge/response methods, etc, because it looks to me like there is
at least some extent to which the protocol could be different to make
it less vulnerable to clock issues.  (Applied Cryptography by Schneier
talks about Neuman-Stubblebine right after kerberos, and claims that
the Neuman-Stubblebine removes the need for synchronized clocks.)  I
suspect that any protocol changes for that probably wouldn't be made
at least until the extensions draft is finalized, but it seems like
clarifications does do a certain amount of refering to that which is
not yet specified already.  And if you do not want to add mechanisms
to make kerberos less dependent on accurate time, discussion of why
not seems like it would be worthwhile.

In ``Application servers may choose to process FORWARDED tickets
differently than non-FORWARDED tickets.'', I find myself wondering if
MAY should have been written in all caps.

In ``A client MAY request that the KDCs not check the transited field
by setting the DISABLE-TRANSITED-CHECK flag. KDCs are encouraged but
not required to honor this flag.'', I wonder if the second sentence
should read ``KDCs SHOULD honor this flag.''

I don't understand the OK-AS-DELEGATE flag.  The first paragraph of
that section seems like it could do a better job of giving an example
of why it is useful.  In the second paragraph of that section, I don't
really understand the point of the sentence ``Ignore the value of this
flag.'', and the word ``Security'' in the following sentence probably
shouldn't be capitalized.

I believe that in ``See section 3.7 for a more complete description of
the affect of user to user authentication on all messages in the
Kerberos protocol.'', the word ``effect'' should be used instead of
``affect''.

I feel like the text about application servers maintaining replay
caches leaves some questions unanswered.  The text that reads ``for
example, a challenge-response sequence initiated by the server after
authentication, or use of a server- generated encryption subkey'' is a
good start, but I feel like I would have a much better understanding
of how to evaluate a protocol if there was a paragraph on that instead
of a part of a sentence.  I do not know of any text that explicitly
says whether the krb5 support in openssh is designed in such a way
that the replay cache is unneeded.  Same goes for krb5 in tls.  And if
a replay cache is needed, there needs to be some text for the system
administrator explaining how to make sure that the replay cache is
properly maintained across reboots; I've never seen such text, which
suggests that if such text has been written, many people who should
have read it haven't.

Given there being more potential for a sysadmin to accidentally create
insecurity when a replay cache is used, I wonder if the text should
say that new application protocols SHOULD be designed in such a way
that the replay cache isn't needed.

I also feel like it would be good to have some text in the kerberos
draft about what a protocol needs to do in order to be secure if the
replay cache isn't used.  Perhaps the correct thing is to give one
example of a protocol that removes the need for a replay cache, and a
list of all of the the crucial features that that protocol needs to
thwart the various possible attacks, and perhaps note that there may
be other very different ways to achive the same level of security.
Maybe the text already sort of does this but depends on having a
greater understanding of security protocols than I have.

In ``If multiple servers (for example, different services on one
machine, or a single service implemented on multiple machines) share a
service principal (a practice we do not recommend in general, but
acknowledge will be used in some cases), they should also share this
replay cache, or the application protocol should be designed so as to
eliminate the need for it.'', it seems like there should be some
instances of the word SHOULD in all caps, or something.  Actually, I'm
kind of surprised that the replay cache sharing isn't a MUST.

The stuff on how the client picks kdcs to ask for cross realm tickets
feels kind of vague.  If I were trying to write a kerberos
implementation based only on this document, I would probably end up
with something that worked but that was gratuitously different than
every other kerberos implementation on the planet.  There's not
necessarily anything wrong with that, but a lot of the rest of this
text is extremely clear and precise, and the cross realm ticket stuff
isn't up to the same standard.

I'm a little confused about why ``Implementations SHOULD accept any
checksum algorithm they implement that both have adequate security and
that have keys compatible with the sub-session or session key.'' is
under *generation* of KRB_SAFE and not *reciept*.

Under KRB_PRIV, the sentence ``Then the timestamp and usec and/or the
sequence number fields are checked.'' should probably start a new
paragraph, unless that checking only happens when using directional
addresses.

There are various references to authenticators, but in the text I have
read thus far I don't really feel like I have a clear understanding of
the range of things one can usefully do with them, or what exactly
their contents can be; I feel like there are occasional glimpses of
things one can do with them, but no good explaination of the big
picture.

In the list of recommended algorithms, I'm a bit confused, because I
thought I've used MIT kerberos to create principals with
des3-hmac-sha1, yet the draft recommends supporting des3-cbc-sha1.

If you are going to recommend that implementations support single DES
as you are currently doing, you should provide some justification,
either along the lines of ``we think the EFF was on crack four or five
years ago when they said single DES was insecure'' or ``this is not
really as secure as we would like, but we really need it for
interoperability because blah blah blah''.  I have a feeling that when
I think single des is likely to die soon, I may be being overly
optomistic about how fast old implementations will die, how fast krb4
will die, and or how long clarifications will remain the current krb5
spec.  If single DES is to be recommended, I think it would also be
good to explicitly describe the conditions which need to be met before
its use can be depreciated.

The language under security considerations about off-line dictionary
attacks doesn't strike me as strong enough.  kerberos is substantially
more vulnerable to weak passwords than any other form of security,
AFAICT, and if that is true the spec should say that.  Pointing to
documentation of what sort of password is actually strong enough might
also be good.