Kerberos Working Group - IETF 63 meeting summary
- Agenda bashing - the KDC certificate naming issue was moved to the start of the agenda at the request of Russ Housley, so he could participate in that discussion and them move on to another meeting.
- The chairs gave an update of the status of documents which have been sent to the IESG, and of ongoing work:
+ Kerberos clarifications - published as RFC4120
+ The GSSAPI-CFX document - published as RFC4121
+ PKINIT - close to done; 2 issues will be discussed today
+ OCSP-for-PKINIT - done; will be ballotted with PKINIT
+ RFC1510ter - not much progress
+ Referrals - authors think it is nearly ready for WGLC
+ Enctype-Nego - needs updates from last call comments
+ Set/Change PW - author thinks last issue is resolved
- There was a long discussion on ticket #837, related to identifying KDC certificates. We began with a review of the chair's message of July 18, 2005, which attempted to summarize the problem (Message-ID <Pine.LNX.4.33L.email@example.com>)
>> Two questions to be answered.
The sense of the room was that the email message correctly summarized the problem, and also correctly described what appears in pkinit-26 and -27.
>> 1) Is cert appropriate for use by pkinit kdc?
>> 2) Does the cert refer to the kdc for the realm we're talking to?
>> Hum. This is the correct way to break down?
>> many yes, none no.
>> Required to implement means "every client must accept a certificate that
>> contains the required mechanism".
The current document specifies the use of the KerberosPrincipalName SAN with the principal name of the TGS (krbtgt/REALM@REALM) to identify a certificate for use with PKINIT and belonging to a particluar realm's KDC(s). The sense of the room was to keep this method and to keep it as the REQUIRED method for both usage and naming.
The sense of the room was that no other naming methods needed to be specified, but that clients should be permitted to accept certificates with other names based on local policy (also permitted by -27).
>> Russ Housley: how does the CA become authoritative about which entity
There was much contention on the issue of whether an EKU should be required when certificates are associated with a KDC by means of local policy, and, if not, whether it should be specified at all; this question remained unresolved.
>> is authoritative to act as the KDC?
>> Take all of the IE browser trust anchors, if any of the trust anchors
>> can be used to verify, then there is a problem.
>> Stefan, Microsoft: Believes the Security Considerations text should be
>> sufficient to deal with the problem.
>> Russ agrees provided that the Security Considerations text specifies
>> what happens if you get things wrong.
>> We still don't know where the name is going to appear.
>> There is no fundamental issue
>> May the cert be used for pkinit, does it have the pksan, or the eku,
>> or local policy?
>> can we deploy with subjectAltName? If so, we don't need DNS name for
>> validating KDC.
>> Sam: many sites want to store hash or serial of client certs instead
>> of subjectAltName.
>> Karthik Jaganathan (JK): says Microsoft wants to be able to use hash
>> or serial number but this is covered by the local policy statement.
>> Typically not the case that the KDC CA is signed by a public CA.
>> Jeffrey Hutzelman: how difficult is it for non-MS CAs to add obscure
>> v3 extensions?
>> Russ: all CAs have a mechanism. the worst one is pass in a hex string
>> representing the extension. this is fine or one or two certs, it is
>> really hard for client certs.
>> Larry Zhu: its not clear what direction is.
>> jhutz: the current document does not specify the use of dns name. I
>> want to confirm whether we have consensus.
>> jhutz; a client must determine that the cert is allowed to be used for
>> a KDC, and that the cert belongs to the KDC.
>> Sam: if there is going to be an EKU, implementation must be required.
>> <scribe missed much of the discussion while fixing laptop>
>> Sam: The DS bit does not distinguish whether the cert is allowed to be
>> used for a web server or a kdc.
>> Requiring the EKU is silly if it is not a required test. The required
>> test is subjectAltName, then the EKU makes no sense.
>> A specific EKU must be specified which we have not done.
>> Stefan: you check to see if the EKU value is valid for a particular
>> application. Hence "any" versus a specific oid.
>> A SubjectAltName form that is specific to KDCs removes the need for an
>> <not taking minutes of miscommunication about which certs we are
>> Sam: RFC 3280 Section 220.127.116.11 says that an application to require an
>> EKU. Want the model Stefan is proposing.
>> jhutz: There is a proposal to drop the EKU specification ...
>> Nicolas Williams; (without mic) do we have consensus that the
>> Stefan: if you have an EKU, ...
>> jhutz: let's defer
>> JK: is it any easier to implement the EKU than to implement the
>> Russ: no. if the eku is not known, the entire eku block must be
>> manually encoded.
>> Stefan: every service should have an EKU, but no one should be
>> required to implement it
>> Sam: its really bad to define an EKU and not mandate implementing it.
>> you get into a situation where some clients that do not implement
>> support get a bad
>> Russ: support dropping eku. if subjectAltName is required to
>> implement and must be the only one present. you only get into trouble
>> if more than one name is present.
>> if the cert with local policy allows acceptance of other names, then
>> you must have an eku or something else to remove the ambiguity.
>> Stefan: scratch previous comment. drop the eku
>> Sam: propose require "subjectAltName id-pksan OR local policy plus
>> Sam: What will microsoft support?
>> JK: we are in favor of dropping the eku and adding appropriate
>> security text.
>> Sam: russ has convinced me that if there is going to be local policy
>> then there must be something like an eku to remove ambiguity.
>> Stefan: we cannot change the eku processing behavior described in
>> Russ: objects to acceptance of "ANY". There is no way with "ANY" to
>> determine whether or not the CA meant for the use of the cert with a
>> We have rat-holed on this. Back to the list.
- Andre Scedrov (UPenn) and Aaron Jaggard (Tulane) have been doing formal analysis of Kerberos protocols...
>> Formal verification of Kerberos basic and cross-realm pass validation.
... and gave a presentation on a problem they found in PKINIT in RSA mode. They described two approaches which they believe would fix the problem. One involves having the KDC sign the AS-REQ; the other involves having it sign the client's identity. The former approach is essentially what Larry has proposed in pkinit-27, and they believe that will fix the problem.
>> Great works guys!!!
After some discussion, there was general agreement that the approach taken by pkinit-27 was acceptable, and to a certain extent even preferred.
>> Sam; authenticated clear-text. Its time for us to solve the
Love Hörnquist-Åstrand objected to the use of a keyed checksum which was sitting right along side its key (both in a structure signed by the KDC); Sam pointed out that the use of a keyed checksum allowed us to use RFC3961 cksumtypes, which essentially come only in keyed variants.
>> authenticated clear-text problem.
It was pointed out that ASN.1 comments are not the best place to have the only copy of a normative requirement (wrt the client. The editor will fix this.
>> Andrei: more wording needs to be added to -27 stating that the
>> client MUST verify the checksum
- Sam Hartman gave some brief comments on some assumptions currently made in Kerberos which he would like to see go away. Unfortunately, there was not time for significant discussion; we will likely see the full version of this presentation in Vancouver.
>> Sam: I think Kerberos is broken
>> ... three assumptions may be wrong:
>> whether this single principal identifier that never changes is what we
>> if we add SAML, can principal name go away?
>> destination's KDC is not involved in cross-realm, this has policy
>> all of this is Extensions scoped work.
- There will be an interim meeting September 19,20 at Microsoft for the purpose of doing work needed to advance RFC's 3961, 3962, and 4121 to draft standard. Further information is available online at http://dl.central.org/dl/ietf-krb-wg/200509/