Please note: These minutes are preliminary. Please send comments and corrections to Jeffrey Hutzlemna, <jhutz@cmu.edu>
| Chair | Jeffrey Hutzelman |
|---|---|
| Scribes | Jeffrey Altman, Dave Christiansen, Shawn Emery, Douglas Engert |
Note: due to the nature of the work being performed, large portions of this meeting were not logged in point-by-point detail, but were instead recorded in the form of spreadsheets representing feature matrices developed in the course of the meeting. While some were more active than others, everyone present at the meeting contributed at least once to that work.
Blue sheets were passed around, albeit on green paper. (These were passed around at various points as people came in and out over the course of the 2-day session. A complete list of attendees is available in the online proceedings archive.)
The chair asked for scribes. Jeffrey Altman volunteered to scribe to Jabber for the first session, but indicated he was not willing to be the sole scribe for the 2-day meeting. Much of the contents of these minutes came from the logs of Jeff's Jabber scribing.
Some welcoming remarks were given by Klaus Schutz, Director of Development for Windows Security Access Control at Microsoft. Klaus gave us a brief presentation on Microsoft's position and future directions with respect to Kerberos.
There was a brief update on outstanding issues with PKINIT. There was no actual discussion of these issues, as PKINIT was not on the agenda for the interim meeting.
The agenda was bashed. Conclusion was that we would begin with a review of process requirements and other materials related to advancing specs through the standards process, then move on to spend the bulk of the meeting time on actually defining what data would need to be collected.
--- Break ---
Sam Hartman gave an overview of what needed to be accomplished from a process point of view in order to advance a specification. Several conditions must be met:
Interoperability reports that have been filed for other protocols can be found at http://www.ietf.org/IESG/implementation.html. They vary quite widely in how detailed they are. One example of a protocol with a simple report is OTP. At the other end of the spectrum, draft-ietf-idr-bgp-implementation-02.txt is very complex.
Other points:
There was general discussion over what level of detail would be needed in terms of protocol features.
There was discussion on what process to use in constructing the list of features.
Work proceeded on defining a feature matrix for RFC3961 and RFC3962, the Kerberos cryptographic framework and additional AES enctypes. The detailed discussion which went on during this process was not recorded, but its outcome was, in the form of a spreadsheet. The complete feature matrix spreadsheet is available in the online proceedings.
As part of our implementation report for RFC3961, we need to note that rsa-md4-des-k, des-mac, and des-mac-k are considered HISTORIC and are documented for informational purposes only. So, we don't care if there are interoperable implementations for the purpose of progressing RFC3961 to Draft Standard.
After lunch, work proceeded on defining a feature matrix for RFC4120, the core Kerberos specification. As before, the detailed discussion was not recorded, but the results were. The second page of the feature matrix spreadsheet documents features for RFC4120.
--- Break ---
Although server-side rejection of unrecognized authorization data is an implementation detail rather than a proper protocol feature, we are including itin the feature matrix because there are serious security issues if this is not done correctly.
There was some discussion about how to identify features for RFC4121. Sam proposes essentially going over all of the messages, examining the options for each message, and then considering corner cases.
We started off by doing additional passes over RFC4120, doing things like looking for all occurrances of RFC2119 keywords in the document, to determine if they pertained to protocol features we missed. Mostly we found text describing features we already knew about, or behaviors that did not correspond to protocol features. However, we did find a few additional features, which were added to the spreadsheet.
--- Break ---
After the morning break, we completed the work on developing a feature matrix for RFC4120. In total we identified at least 52 distinct features in the core Kerberos protocol.
David Christiansen gave a presentation on gssMonger, a tool for automating interoperability testing of Kerberos and GSS-API.
The afternoon began with developing a feature matrix for RFC4121, the Kerberos GSS-API mechanism. Again, while the detailed discussion was not recorded directly, the work done was recorded in the form of a spreadsheet containing the feature matrix. The complete spreadsheet documenting the feature matrices for all three protocols is available in the proceedings.
--- Break ---
With work on feature matrices complete, the remainder of the afternoon was spent discussing open issues on kerberos-extensions, also known as RFC1510ter. The majority of the discussion focused on the longstanding and contentious issue of exactly what form the ASN.1 definitions of the protocol messages should take.
More details to be filled in later; see the jabber logs.
David Christiansen produced a table documenting the positive and negative points raised for each of the possibile approaches. This table is available in the proceedings as a spreadsheet.