Subject: Updates on issues in draft-ietf-krb-wg-preauth-fw

From: Sam Hartman <[email-masked]>
Date: Sun, 08 Jul 2007 16:51:03 -0400

Hi.  Editor hat on.
Larry and I are submitting a new draft 06.

I wanted to update the WG on disposition (and addition) of open issues.

Draft 05 raised the question of whether adding a new error code
indicating that more data was required in a pre-auth conversation was
desirable.  Hearing no objections either to that section of the draft
or to my mail on the subject to the working group, I'm marking this
issue closed and removning the anchor from the draft.

The current text has an open issue surrounding a requirement that
containers for pre-authentication mechanisms provide a way to encrypt
or checksum the contents of the containers.  The text stating this
requirement is under-justified.  As best I can tell the basic reason
for the requirement is simplicity of analysis.  For example I can
imagine situations where you replace the reply key and then could
substitute in a certificate or response from another request or
client--attacks similar to the pkinit vulnerability that required
addition of a checksum.  So, I'm closing out that issue and adding new
text to 4.2 trying to explain why this requirement is good.  Please
review section 4.2 and let Larry and I know if the text and
requirement are adequate.  Based on these types of attacks it may be
appropriate to do the cheksum at the end of the conversation.

There have been no comments on the open issue in section 6.3 asking
whether Kerberos should remain stateless.  Since neither Larry nor I
supports that change and since we are unaware of anyone who believes
we should take that approach, I'm marking the issue closed and
removing the anchor.

There were two open issues in section 6.4.  Larry has proposed a resolution in the text and requests WG discussion.

Larry proposes introducing a new preauthentication mechanism in
section 6.4 to indicate that the client has finished its outstanding
requests and that the KDC should indicate what is needed next.
Section 6.3 defines kdc_err_more_preauth_data_needed and section 6.4
defines kdc_err_continue_needed.  I don't fully understand the
difference between these errors so clarity is probably required.

Section 6.5 claims that the client name must not be present in the
req-body when FAST is used.  I'm not entirely sure whether this
applies to the outer or inner req-body.  If the inner body, I think
we'll end up revising that if we adopt our proposal to use FAST to
bootstrap extensions.  If the outer body, I think that violates
extensibility rules in 4120.
I think this needs discussion.

I'm not sure that the checksum of the req-body is required in the fast
armor data if we're going to completely ignore that and use our own
kdc-req-body.

Section 6.5.5 contains a newauthenticated timestamp fast factor.  I am
not sure this fast factor actually needs a copy of the kdc-req-body
given that it will be in the armour along side one.