Kerberos Working Group (KRB-WG) Minutes Meeting : IETF 82, Taipei International Convention Center, Taipei, Taiwan Time : 0800-1100, FRIDAY, November 18, 2011 Location: 201 DEF Chairs : Sam Hartman Jeffrey Hutzelman Larry Zhu Scribe : Shawn Emery *** Introduction/Agenda (Chairs) The meeting opened with the usual introductions and agenda bashing. - Discussion of the general-pac draft will not happen at this meeting. [ We are considering holding a virtual interim to discuss this topic sometime in January, 2012 --jhutz 16-Dec-2011 ] - Leif Johansson will lead a discussion of open issues on kdc-model - Tom Yu will lead a discussion on new authorization data types. *** WG Status Update (Chairs) The chair (Sam Hartman) updated the group on recent activity on our documents: - New RFC [RFC6448 --jhutz] on cleartext KRB-CRED; thanks to Russell Yount for this work. - Publication request: DHCP option for IPV6 (thanks Sakane) - Camellia-CTS is in WGLC with intended status Informational. The authors have asked for publication on standards track; please send comments to the mailing list. - KDC model in AD review - Working on resolving discusses on OTP - IETF Last Call just ended on gss-cb-hash-agility No secdir or Gen-ART comments yet. Sam also reported some changes in document editorship. - Love Hörnquist Åstrand has had less time lately to work on documents. - The chairs have added additional editors to two of Love's documents: - Tom Yu will help with draft-lha-des-die-die-die - Margaret Wasserman will help with draft-ietf-krb-wg-pkinit-alg-agility - Sam will recuse himself from chair/shepherd roles relating to the PKINIT hash agility document, since someone from his company will be editing. - Both documents have outstanding unresolved comments. - Thanks to Love for his efforts on these and other documents. *** OTP Preauth (Sam Hartman, as chair) There is one outstanding DISCUSS relating to internationalization. Proposal on the table is to use SASLprep: - Not really where we want to be, but it's what we have. - No one has come up with anything better. - ADs would prefer not using SASLprep, but had no alternative. - WG could choose to delay until something better comes along. In favor of using using SASL-Prep: for: rough consensus against: none There's also an issue related to potential password collisions due to normalization and other mappings. The AD's would like us to add text pointing out this issue; Sam had proposed the following on the list: If PINs contain international characters, similar looking or similar functioning characters may be mapped together. For example, the combined and decomposed forms of accented characters will typically be treated the same. Users who attempt to exploit artifacts of international characters to improve the strength of their PINs may experience false positives in the sense that PINs they intended to be distinct are not actually distinct. This decision was made in order to improve usability across the widest variety of input methods. Users can choose other methods to add strength to PINs. Ok with adding security considerations text. for: "reasonably strong" consensus against: none Simon Josefsson raised two issues on the mailing list. The first is that we don't specify whether SASLprep is used in storage or query mode. - It seems clear we want query mode; - The chair asked for objections to this; none were raised - Lacking any objections, the editor will be directed to make this change. Simon's second issue is that he believes it's underspecified how to know what OTP format to use (decimal/hex vs alphanum vs binary). - The chair said it would require fairly strong support to make a change of this sort this late in the process. - The chair asked whether there was any support for Simon's concern; there was no response. - Leif Johansson suggested polling implementors to see if this issue came up in their implementation attempts. OTP down to one DISCUSS, need Pete Resnick to clear. *** Referrals (Sam Hartman, as editor) Sam gave an update on the state of referrals: Version 12: - Old document - Sam became editor about a year ago - made a bunch of changes; discussed on the list - tried to align w/existing implementations, - removed anything that didn't get implemented. Version 13: - Cleaned up references to features that have been removed - There were some assumptions were made that U2U was harder than other parts of Kerberos, but it turned out the same problems cropped up elsewhere. Referrals is an aliasing mechanism; there's a long-term alias, but the name it maps to can change. Ideally, you want to do authorization against the more-stable long-term name. People thought that applied only to U2U, but really it applies everywhere. There is already a mechanism to allow a service to find out the client's long-term identifier; the document was updated to point out this is valuable even outside U2U. Sam is asking for a Working Group Last Call on this version. [ The WGLC started 16-Dec-2011 and ends 6-Jan-2012 --jhutz ] *** KDC Data Model (Leif Johansson) A variety of issues were raised during AD review, most of which were resolved fairly easily. There are four remaining issues, which Leif summarized before moving on to discussing each issue in detail. The first issue discussed relates to text which clarifies the use of RFC2119 requirements language in this document. - Leif explained that the complexity arises because the document uses RFC2119 language to specify requirements on more than one level: + Requirements on schemas that implement this model (i.e. what elements must be part of the schema) + Requirements imposed by schemas (i.e. what elements must alwasys be present) This is particularly difficult as the different schema languages have different ways of specifying requirements. The WG had spent some time developing text to attempt to review this, but Stephen Farrell commented during AD review that it was difficult to understand. Leif attempted to rewrite the section, which has started a mailing list discussion. - Sam said that part of his problem understanding the rewritten text is that it seems to have dropped a third level, which relates to what must be supported by implementations. He explains this as the difference between whether a field is optional in an LDAP schema (a requirement on what operators must put in the database) and whether an implementation must implement a feature. For example, of course every principal does not need to have aliases, but are implementations required to support them? Sam thinks this third level is more important than the existing second level relating to whether a field is optional or not, and that the rewrite failed to capture that. - Leif was not sure he agreed, but acknowledged that he's been looking at this long enough he may not be able to see the problem clearly. - Leif suggested that one resolution would be for someone to suggest new text to handle this. He's not sure he's doing a good job capturing it. Unfortunately, there were no volunteers. - Stephen Farrell said that if the WG decides to go back to the first version, he won't block on that basis, but doing so might draw DISCUSS comments from other ADs. - Nicolas Williams said (via jabber) that he'd review the issue. The next issue relates to whether or not to keep an existing informative reference to the set-change-password document. - XXX why ref - The set-password document is currently inactive, as no one has been interested in working on solving that problem. - If someone were interested in working on key management, going back to that draft would be a good starting point; in fact, Sam says he'd argue fairly strongly that any such work must start from that point. - Leif doesn't see the point of having the reference. It's a general observation that we don't expect password management via this model. - Leif seemed to believe the reference wouldn't survive publication anyway; Sam explained that this was not the case. - Nico made some comments on this issue via jabber, which he will take to the mailing list. The third issue is whether to keep a reference to "enterprise names" (from referrals), or to instead refer more generically to a concept of aliases without specific reference to referrals. - Sam says that normal aliases typically live in the same namespace as the rest of the names, while enterprise aliases typically do not. Enterprise names are a bit more complicated, and require specific handling that implementations are expected to obey (for example, they force canonicalization) - Sam's not sure whether this distinction means we need to call out enterprise names explicitly, but wants the WG to be aware of the issue. - Leif says the original text said "enterprise names/aliases", so the more general alias part is already there. - No one else had any input. - Leif suggested dropping the reference to enterprise names. There was some discussion as to whether the changes made so far would require another WGLC on this document. Sam asked whether the IETF last call might be sufficient. [ As shepherd, I don't think the changes discussed so far and various editorial changes will require a new WGLC. But I'll look into it once a new document has been posted. --jhutz ] The final issue is whether principalNumberOfFailedAuthenticationAttempts should count forever, or wrap or reset at some point. - Sam asked that implementors be consulted, since there are multiple implementations and it would be good to align with them. - Tom Yu wasn't sure how MIT handled it, but thought it might reset when a principal is reset after a lockout. - This discussion will be taken to the mailing list. The group returned briefly to comments Nico made on Jabber related to how server alias referrals should work. Sam said that Nico's suggestion was really a fairly major change, and asked that he take it to the mailing list along with a use case. *** GSS-API Preauth (Sam Hartman, as chair) We received a request to adopt a GSS-API-based preauth method. - Clearly within our charter - Mechanism for doing Kerberos preauth based on GSS-API authentication - Use case: use abfab (GSS-EAP) to authenticate to Kerberos - Can be used with FAST or alone without a secure channel - Call for adoption resulted little discussion or response - Sam brought up a use case, which also got little response. This draft might not be the best answer for Sam's use case. If we adopt this _and_ decide Sam's use case is interesting, we might end up with two ways to use abfab to authenticate Kerberos (one using GSS-EAP and one using EAP directly). - Feedback so far has been in favor of adopting, but making Sam's use case work might require some "tortured" changes to GSS-API, which would not be very generic. - To make forward progress, we need more people to care. - The chair asked for people to review this draft and become active in the discussion. *** New Authorization Data Types (Tom Yu) Tom reported the MIT Kerberos Consortium has heard several requests from sponsors for specific types of authorization data. [ Discussion of these proposals was highly intermixed and IMHO rather confusing. In the interest of making the discussion easier to follow, I've tried to record what happened on a topic-by-topic basis rather than in strict linear order --jhutz ] The first AD type Tom mentioned was Level-of-Assurance data. - Leif reported that there is an effort underway to create an IANA registry for LoA definition. This has been discussed in communities with an interest in LoA information. He will provide a reference. - Tom said he would be surprised if implementing this using the registry turned out to pull in a large framework and a lot of work. - Sam said that using SAML authentication contexts [as Leif had already suggested; see below --jhutz] would pull in a lot of complexity. Tom agreed, and said he didn't think that was the right approach. - Leif thinks LoA shouldn't be done explicitly at all, and instead should be obtained through something else. For instance, via a container that carries either SAML or a [XXX] token. - Sam objects that this would push the complexity to each RP [Kerberos service] rather than keeping it in the KDC. Tom's second proposal was for a generic set of site-defined attributes. - Attributes would be named by strings - This might overlap some with SAML. - Leif pointed out there was an attempt some time ago to develop a method of embedding SAML assertions in Kerberos PACs. Code was produced, but protoocl discussions never went anywhere. - Leif also pointed out that if this problem were solved using SAML, and the SAML authentication context were also included, then LoA information would also be conveyed. - Sam mentioned that Microsoft has announced support in Windows 8 for string-based claims in some form. He thinks we should consider how important it is to be compatible with Windows and/or SAML semantics. Tom's third and final topic was conveying X.509 extended attributes. - Nico also suggested including the client certificate in authorization data. - Tom said that might work, but any application receiving that data would then have to be able to decode the entire certificate. There was some discussion of whether to take on work in this area. - The chair asked for volunteers willing to work on drafts in this space Write: Tom, Thomas, Leif, Alexey Review: Sam, Melinda, Shawn - That this work is clearly within our charter. - As we finish some of the work currently underway, the ADs should be happy with letting us taking on some of this work. - Stephen Farrell (as AD) pointed out this could be a large body of work, depending on what we choose to do. He wanted to get an idea of how much work would be involved. - Tom indicated that he specifically worded the proposal to consist of three fairly tightly-constrained work items. For example, he specifically mentioned site-defined string-key attributes, to scope more tightly than the SAML framework - Sam believes that if you focus on the use cases and choose in each case not to pull in a large framework, then the work is very well contained. With a large framework, specification might not be bad, but implementation will be "tricky". - Leif argued that any specifications would have to be reasonably aligned w/Windows. Nico raised a proposal relating to the PAC/PAD draft [which was not actually discussed at this meeting], to reduce ticket size by sending a set of "anonymous" credentials authorized to retrieve the PAC data rather than sending the PAC itself. Leif said experiences with this approach in SAML had not always been successful. *** Open Mic None.