DRAFT Minutes for krb-wg at IETF62
** IETF 64 - Vancouver, BC
** Kerberos Working Group
** Mon, Nov 7 - 15:10-17:10
Chair: Jeffrey Hutzelman
Scribes: Kurt Zeilenga, Jeffrey Altman
Jabber: Leif Johansson
+ Preliminaries - Jeffrey Hutzelman (5 min)
+ Special Presentation - Jeffrey Altman (5 min)
+ Document Status - Jeffrey Hutzelman (5 min)
+ Technical Discussion (90 min)
- Questioning Kerberos Assumptions - Sam Hartman
- Enctype Negotiation and prot_ready
- Resolving PKINIT issues
+ Update Milestones - Chair and Participants (10 min)
The chair recruited some volunteers to take notes and scribe for
jabber; thanks to all of those who helped. There was the usual
obligatory whining about the network, and then we got down to the
business of reviewing the agenda. Since the only remaining issue
with enctype-nego had already been resolved, discussion of it was
dropped from the agenda.
* Special Presentation
Jeff Altman gave a special presentation to thank Cliff Neuman for
his efforts on Kerberos development and specifically on completing
RFC4120. Cliff was unable to be present in person, but was present
in the Jabber room. In appreciation of his efforts, Cliff will
receive a bound copy of RFC4120, signed by others who worked on the
document, and an iPod Nano.
Cliff (via jabber):
> I appreciate the presentation. It was a long effort to get the
> draft done and I am sorry I can't be here this week.
> And though I am absent, I do not intend my participation to stop.
> There is still much to be done, and the WG has stong leadershop
> to keep it all going.
* Document Status
The chair gave a brief update on the status of current documents.
+ PKINIT has just completed working group last call. Several issues
were raised which will be discussed later in the meeting.
+ A new revision of kerberos-extensions was recently posted.
+ Enctype negotation completed its last call some time ago. Issues
raised have now been dealt with, and it should be read to go to
+ Larry believes he has gone as far as he can with editing referrals,
and asked to turn the editorship over to Ken Raeburn. Ken said
he was willing to take over the document, and the chair approved.
Larry and Ken will deal offline.
+ Larry's anonymity draft will be discussed later during the meeting.
+ Sam said he received an individual submission from Larry of a
document describing Microsoft's RC4 enctype, to be published as
informational. He wanted to know if the WG had any objection to
the publication of such a document as an individual submission.
Ken Raeburn asked if it should be in a form laying out the parameters
required by kcrypto. Sam said it was his belief that the designated
expert [presumably Ken] would review the document for kcrypto compliance.
Cliff supports publication of the document.
No objections were heard.
* Questioning Kerberos Assumptions
Sam Hartman gave his presentation on "Questioning Kerberos Assumptions",
which was originally scheduled for IETF63 but was deferred due to lack
of time. For the contents of the presentation, please see the slides,
which are included in the meeting materials. The presentation was
followed by some discussion...
cliff> WRT: The concluding questions - on mapping of ID's I think there
cliff> is a difference between mapping when one crosses a system bounardy,
cliff> and mapping when one crosses realms within a system.
sam> I disagree
cliff> For example, I think that for straight cross realm kerberos, names
cliff> should be preserved, with the path embedded in transited. But, I
cliff> also feel that when a system requires name mapping to a name in a
cliff> local realm, that such mapping should be possible. Also, when a
cliff> name in one system of authentication is used as a basis for
cliff> authentication in another, then perhaps the name mapping becomes
cliff> required. We dealt with some of this in the pkinit work.
cliff> As to involving the end KDC in cross realm authentication, I
cliff> thought that it is involved. There is the issue of who makes the
cliff> "authorization" decision, and we provided a means for the KDC to
cliff> validate the transited path for the end node, but the final choice
cliff> was on the end node.
... further discussion was deferred to Jabber, since round trip delay was
making an interactive conversation difficult.
Simon Josefsson says his implementation (shishi) deals with the privacy
issues by running Kerberos over TLS, using an extension he previously
described. There was some discussion of the details. In essence, the
reserved bit in the message-length field of Kerberos-over-TCP is set to
indicate the presence of an extension, and the remainder of the field
specifies the extension to be used; one such extension is STARTTLS.
Details can be found at http://josefsson.org/krb5starttls/.
Simon is interested in having the WG pick up this work.
There was objection to a private extension using a bit which is defined
to be reserved for use in a future version of the protocol. The chair
asked whether there was interest within the WG to pick up the task of
defining an extensibility mechanism for Kerberos-over-TCP along the lines
of Simon's proposal; the result was inconclusive.
Sam still believes that having Kerberos depend on TLS and/or a PKI is
bad, but may be changing his mind, due to the difficulty of secure
Kerberos preauth. An encrypted channel may be needed, but Sam wonders
if TLS is the only option; it's model for ciphers is different from that
of Kerberos and more restrictive. He generally supports something like
Simon's TLS proposal, but thinks we need to look at options beyond TLS.
The chair asked whether the WG was interested in picking up Simon's
STARTTLS proposal or work along those lines; the result was inconclusive.
Bob Morgan made some comments about SAML. There were some additional
comments about identities and attribute assertions; after a few minutes
it was suggested that this discussion be deferred to the KITTEN WG,
where it had been started in Paris and would be picked up later in the
There was some discussion of Larry's draft on anonymous tickets. Larry
described an issue raised by Aaron Jaggard, in which a client's identity
could be revealed to a server which the client intended to contact
anonymously. There was some disagreement as to whether this was a real
problem or only a theoretical one. The discussion was deferred at least
until after handling PKINIT issues.
* PKINIT Issues
We discussed issues raised during the last call on PKINIT
+ The ASN.1 module is over-tagged -- the WG is aware of this issue and
has discussed it previously; we will not be reopening it.
+ Use of OCTET STRING wrappers -- the WG discussed this in great detail
and weighed the issues before deciding to use OCTET STRING wrappers;
see ticket #527 in RT. This issue will not be reopened.
+ Constraint style -- the issue of use of formal constriants versus
textual requirements has been discussed extensively, and the current
document reflects the consensus of the working group on this issue.
+ Normative text in ASN.1 comments -- it was the previous consensus of
the group that normative text should not appear _only_ in comments.
Jeff Altman volunteered to look for places where this occurs as part
of his review.
+ We need people to check to be sure the ASN.1 module compiles.
Larry Zhu and Love Hörnquist-Åstrand volunteered to do this.
+ TD-DH-PARAMETERS is not signed
Love wants this TD to be signed; otherwise, he believes there is a
downgrade attack. Larry says the attack can be prevented by use of
suitable configuration to restrict the set of groups that can be used.
Love objects to this, since it means the KDC cannot securely force a
client to use a stronger group than the weakest the client is willing
to support. After some discussion, Love withdrew his objection;
specifically, he said "I fold".
+ AS-REQ not signed in DH case
Love points out that while the AS-REQ is signed in the RSA case, it
is left unprotected in the DH case. He proposes adding a checksum to
the AS-REP, as was done in the RSA case to protect against the attack
found earlier this year by Aaron Jaggard and his research group.
Larry argued that this problem is not specific to PKINIT and should
be solved in a more general way.
Sam proposed a compromise, which is to fix the problem when we deal
with upgrading hash functions. The sense of the room supported the
+ TD-DH-PARAMETERS reference -- Love thinks this is underspecified,
but doesn't have the IEEE document to check. Tom Yu volunteered to
look into it, provided the document is in MIT's subscription.
+ Empty vs missing sequences -- Larry will add text indicating they
+ signed attribute - Larry will add text referencing RFC3369.
+ Introduction - Jeff Altman doesn't like the introduction, and is
planning to propose new text on the list. We can review this and
adopt changes, but we will not hold up the document for this any
longer than it would block for other issues.
+ Hash Upgrade Strategy
Sam says we need to have a strategy for adding negotiation of hash
functions in the future. We don't need the negotiation mechanism,
just a way to trigger it without breaking interoperability. He
believes that it is sufficient to define a set of error codes to be
returned when the hash and signature algorithms used in various places
in the protocol are unsupported.
The chair will review the document before submission to insure that
the requirement is met; others are encouraged to do so also.
* Update Milestones - Chair and Participants (10 min)
The working group reviewed our milestones and came up with updates,
as shown below.
DECISIONS (also see PKINIT issues below)
* Sam's compromise on AS-REQ signing in PKINIT
* chair: Get ECC listed as a WG item
* chair: Send enctype-nego to IESG
* chair: Update milestones
* jaltman: Review PKINIT, find ASN.1 comments
* lzhu, lha: check that the PKINIT ASN.1 module compiles
* tlyu: check on TD-DH-PARAMETERS underspecification
* lzhu: add text on empty sequences
* lzhu: add text on signed attribute
* jaltman: introduction proposal
Done - Consensus on direction for Change/Set password
Nov 05 - PKINIT to IESG
Nov 05 - Enctype Negotiation to IESG
Dec 05 - Last Call on PKINIT ECC
Mar 06 - Issues identified for Anonymous
Mar 06 - Review milestones
Jun 06 - Major issues resolved on Extensions
Aug 06 - Last Call on Extensions
Aug 06 - Last Call on Referrals
Sep 06 - Last Call on Change/Set password