Re: [secdir] Secdir review of draft-josefsson-kerberos5-starttls-07

[Simon Josefsson <[e-mail]>]

Magnus Nyström <[e-mail]> writes:

> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.

Thank you for the review!

> This document defines a new Kerberos extension to allow Kerberos
> protocol runs over TLS.
>
> I do not have any general issues with this document but a few
> questions/comments:
>
> Section 1: "The TLS protocol has been studied by many parties.  In
> some threat models, the designer prefer to reduce the number of
> protocols that can hurt the overall system security if they are
> compromised." This statement seems to me like a strange reason to
> motivate this work - Kerberos is equally well studied (at least) as
> TLS and this memo does not reduce the number of protocols in the
> system (c.f. the recent TLS renegotiation vulnerability)

I have removed the paragraph.

That paragraph was intended to contrast with PKINIT which to my
knowledge has not been studied as thoroughly as the core Kerberos
protocol or TLS.

> Section 3: In the packet flow, why are the first two Kerberos
> exchanges ([0x70000000 & STARTTLS-bit] and [0x00000000]) wihtin square
> brackets? Is it because they're seen as a separate protocol, or some
> other reason? A clarification would be helpful.

Good catch -- after studying that part, I noticed that it is also
incorrect.  It should be 0x80000000 | STARTTLS-BIT.  Further, the binary
operator was not explained.  The brackets are indeed not helpful.  Here
is the new text:

   A complete packet flow for a successful AS-REQ/REP exchange protected
   by this mechanism will be as follows.  The "STARTTLS-bit" is a
   4-octet value with only the bit allocated for this extension set, and
   | is the binary OR operation.

       Client                                               Server

        [ Kerberos V5 TCP extension mechanism negotiation starts ]

       0x80000000 | STARTTLS-bit  -------->
                                                       0x00000000
                                    <--------

Further, when reading the protocol explanation in the previous section,
it wasn't clear that the client actually initiates the communication,
and there were no pointer on handling errors at that point.  Here is the
new text:

   The protocol is as follows.  The client requests the extension by
   setting the STARTTLS bit in the TCP extension mechanism bitmask.
   (How to deal with extension negotiation failures at this point is
   described in [RFC5021].)  After the server has sent the 4-octet value
   0x00000000 to indicate support of this extension, the stream will be
   controlled by the TLS protocol and its framing.  The TLS protocol is
   initiated by the client.

> Section 5: "Use of TLS, even without server certificate validation,
> protects against some attacks that Kerberos V5 over UDP/TCP do not.
> Requiring server certificates to be used at all times would enable
> attacks in those situations": a) It would be useful to give examples
> of attacks that unauthenticated TLS protects against that Kerberos V5
> does not protect against.

I have added:

     (For example, passive network sniffing between the user and the KDC
     to track which Kerberos services are used by the user.)

> b) Last sentence is ambigious - if server certs are required and the
> client verifies them I do not see what attacks would be enabled. I
> assume the last sentence intends to say that requiring server certs to
> be used when clients cannot validate will enable some attacks but I am
> not sure.

Good catch, it didn't say what was intended.  I have changed it to:

   To require server certificates to be validated at all times would
   lead to disabling of TLS when clients are unable to validate server
   certificates, and this may have worse security properties than using
   TLS and not validate the server certificate would have.

It feels a bit clumsily, suggestions on easier ways to express the same
intent are welcome.

> Section 5: "When clients have the ability, they need to be able to
> validate the server certificate" I suggest rephrasing to: "When
> clients have the ability, they MUST validate the server certificate"

I have made this change.

Regards,
/Simon