Subject: [Ietf-krb-wg] krb-wg report

From: Larry Zhu <[email-masked]>
Date: Thu, 26 Mar 2009 12:58:46 -0700

Krb-wg met Tuesday afternoon.

Chair: Jeffrey Hutzelman and Larry Zhu

Scribe: Shawn Emery

AD: Tim Polk

We reviewed the changes in our current Internet Drafts.  We discussed issues raised in list discussions and consensus calls. There are two outstanding issues for draft-josefsson-kerberos5-starttls, namely KDC-certificate validation and channel bindings.  It is noted that current starttls implementations can only handle pre-shared certificates. We decided that starttls should require certificate validation using pre-shared certificates. There is no consensus how the certificates can be verified otherwise with alternative options involving various EKUs and SANs proposed.  The lack of channel bindings will be handled in a separate document. Due to these limitations, the starttls document should be published as is as informational, except to update it to reflect the certificate validation decision. The channel binding document krb5starttls-bootstrap is adopted as a working group item. These decisions are to be verified on the list.

We then discussed an issue involving the RFC3961 PRF for AES. We found that all current implementations truncate the output to multiple of AES cipher block size 16 bytes while the specification in RFC3961 does not truncate. We decided to adopt the PRF with truncation as the official PRF but we are to find out what is the right process to do this and we will involve the document author Ken and security AD Tim Polk. The decision is to be verified on the list.

After the PRF discussion, we turned our attention to two issues in the preauth document. Sam made the presentation. One is how to detect thus prevent the FAST padata from being stripped by active attackers. An AD element will be used to indicate FAST padata is used to mitigate the threat. Another issue is that TLS-finished style checksum adds some complexity to implementers but no significant benefits. We will remove the finished checksum in the next revision.

We also have the following additional action items and decisions:

1) Updates to the data model document have been made based on WGLC comments. We will start another WGLC. Follow up: jhutz and Leif.

2) Anonymity document has one new open issue regard to exported names. Larry Zhu is going to propose a solution and go through the list. We have good and healthy discussions. Followup: Larry

3) Love proposed an alternative proposal to use the server nonce to allow both the client and the KDC contribute the ticket Session key. Larry Zhu and/love will write up the idea and propose it to the list. Followup: Larry and Love.

4) IAKERB WGLC is concluded. One comment is to be addressed by adding appropriate text to the security considerations section. Followup: Larry to update, and Jhutz to forward it to IESG

5) Ticket extensions adopted as work group item. Followup: jhutz

6) DHCP options to be added to allow KDC discovery, adopted as working group item, and to update the krb-wg charter. Followup: jhutz

7) The preauth ID to be updated and start WGLC. Followup: Sam Hartman to publish -11 based on the group decisions, 3 designated volunteer reviewers to complete review in the next weeks timeframe: Cliff Newman, Love, and Nicolas Williams

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 27 Mar 2009 09:48:15 +0100

Larry Zhu <[email-masked]> writes:

> We then discussed an issue involving the RFC3961 PRF for AES. We found
> that all current implementations truncate the output to multiple of
> AES cipher block size 16 bytes while the specification in RFC3961 does
> not truncate.

That's wrong.  RFC 3961 always truncates.  For AES it truncates the hash
output to 1 byte and for DES3 it truncates the hash output to 8 bytes.

/Simon

---

From: Tom Yu <[email-masked]>
Date: Fri, 27 Mar 2009 06:33:58 -0400

> output to 1 byte and for DES3 it truncates the hash output to 8 bytes.

    pseudo-random function    tmp1 = H(octet-string)
                              tmp2 = truncate tmp1 to multiple of m
                              PRF = E(DK(protocol-key, prfconstant),
                                      tmp2, initial-cipher-state)

It specifies "multiple of m", not _which_ multiple of m.  There are
several reasonable interpretations of how to do this.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 27 Mar 2009 11:43:32 +0100

> several reasonable interpretations of how to do this.

Is there any reasonable interpretation that does not involve truncation?

/Simon

---

From: Larry Zhu <[email-masked]>
Date: Fri, 27 Mar 2009 08:46:28 -0700

"truncate tmp1 to multiple of 1byte" means "truncate tmp1 so that tmp1 after the truncation is a multiple of 1 bytes". Since tmp1 is already a multiple of 1 bytes without truncating anything, it means no truncation is needed. This is essentially the same no-input-truncation/padding-for-stream-ciphers interpretation which is fairly common and I have seen it elsewhere.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Josefsson
Sent: Friday, March 27, 2009 3:44 AM
To: Tom Yu
Cc: [email-masked]
Subject: Re: [Ietf-krb-wg] krb-wg report

/Simon

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 27 Mar 2009 09:03:29 -0700

Since everyone's agreed the spec needs to be fixed, isn't this  
discussion moot?

> Is there any reasonable interpretation that does not involve  

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Greg Hudson <[email-masked]>
Date: Fri, 27 Mar 2009 12:05:41 -0400

> Is there any reasonable interpretation that does not involve truncation?

I think the *only* reasonable interpretation of RFC 3961 is to truncate
to the nearest multiple of m, which is no truncation at all if m is 1
byte.  It's pretty obvious that the purpose of the truncation is to make
E(..., tmp2, ...) work, not because truncation is good for the heart.

That said, the wording is ambiguous and we've seen multiple examples of
people reading it to mean "truncate to m", so clearly the wording is
bad, which is another reason to throw away that particular construction
and pretend that it was never specified.