Minutes, Common Authentication Technology (CAT) WG, Oslo IETF, reported by John Linn (RSA Laboratories). The CAT-WG met for one session at the Oslo IETF, with approximately 110 attendees. Discussion was concentrated in four areas: Kerberos-related documents (pk-init and Kerberos-revisions), GSS Java bindings, GSS low-infrastructure mechanisms, and authorization services. Regarding the Kerberos documents, it is planned that a few identified specific issues will be resolved within the next week, with the intent that revised drafts (to be issued during the week following the IETF meeting) will be suitable for parallel last calls within the working group. Relative to GSS Java bindings, the new javabind-02 draft was discussed along with a set of issues that had been raised on the mailing list; it is intended that a successor to this draft will reflect convergence within the group. Concern was raised about the importance of ensuring that SPI concerns are adequately and suitably satisfied, and this topic is to be researched before proceeding towards advancement of the higher-level document. Relative to GSS low infrastructure mechanisms, the current intent is to proceed with progression of LIPKEY following certain identified changes, with SSKM and GSS-Easy to be discussed further on the mailing list. Relative to authorization services, the current intent is not to pursue standards-track documents; a subsequent version of the GAA-API specification may (following coordination with candidate consumer applications) be considered for Experimental status. KERBEROS PK-INIT AND KERBEROS-REVISIONS Cliff Neuman (ISI) led discussion on draft-ietf-cat-kerberos-pk-init-08 and on the kerberos-revisions draft. A new version of pk-init was submitted at the submission deadline. Changes were made to algorithm identifiers. Ephemeral-Ephemeral Diffie-Hellman is now explicitly described as the required mode. Wording about mandatory to implement (MTI) algorithms was clarified, and error messages have been coordinated. More detail is now provided on use of alt names in certificates, pending side resolution of comments from Paul Leach (Microsoft). An encryption certificate field was added. References to pending work will be revisited, to avoid normative citations to non-standards. Resolution will be provided to cover the case where a user's public key may be locally available at the KDC, for which case no CA signature need be verified in order to make use of the key. Comments have been received and are to be resolved from John Linn, Denis Pinkas (Bull), and Paul Leach. Denis suggests use of 2-key 3DES as mandatory, because some countries restrict keys differently depending on whether their lengths are above or below 128 bits. Sasha Medvinsky (General Instrument) suggests that 2-key 3DES can be used, but usage of 2-key 3DES by some peers and 3-key 3DES, absent other tagging, wouldn't be interoperable. Cliff presented a plan for movement of pk-init to completion. Final issues were to be resolved within the IETF week, followed by submission in the next week of a new Internet-Draft reflecting changes. It was suggested, and appeared reasonable in discussion, that pk-init and Kerberos-Revisions proceed to WG and IETF Last-Calls in parallel, as a pair of related documents. A new version of the kerberos-revisions spec is out. In-progress revisions can be viewed at http://www.isi.edu/people/bcn/draft-kerberos-rev.html. Changes include: folding of e-type data into e-data; updates to registered values; swapping of ad (authorization data) elements kdc-signed and if-relevant; clarifications to wording; warnings for implementation choices; fixed few remaining etype/keytype distinctions. A new Internet-Draft and accompanying change summary is planned for the week following the IETF meeting, intended for WG Last-Call. Kerberos-Revisions issues remain regarding required algorithms: there are several 3DES variants, hopefully to be resolved with Ted Ts'o (VA Linux) and Marc Horowitz (Stonecast) during the IETF week. A proposal from Microsoft had recommended an additional algorithm set. Reportedly, Microsoft had indicated resistance to mandatory 3DES; Paul Leach was unfamiliar with the discussion, so had no comment on this question. Another issue concerns handling of newly optional fields. It was reported that discussion had taken place on the krb-protocol list, which was to be restated to the CAT list by Tom Yu (MIT) and/or Cliff Neuman during the IETF week, about changes in ASN.1 syntax that could result in non-interoperability for new and some optional fields. Ticket extensions remain as an open issue, with basically the same status as discussed at the Minneapolis meeting. Ticket extensions are designed to bind additional data (e.g., authorization or audit information) to an authentication credential; issues with their adoption include graceful transition for current client and server implementations not supporting the extensions, and potential misuse of the extensions. Cliff's proposal, which was to be framed to the CAT list during the IETF week, is to allow ticket extensions only when it's known that a client supports new encryption types. Additional Kerberos-Revisions changes will include a list of changes made since RFC-1510, and guidance for transition support. GSS JAVA BINDINGS Mayank Upadhyay (Sun) led discussion on GSS Java bindings. He reported that he had spoken with Michael Smith (TIAA/CREF), and reflected divergences among the Java binding proposals in his discussion. As a goal, a unified GSS Java bindings draft is desired. The gssv2-javabind-02 draft includes a number of changes. Added interfaces: IGSSName, IGSSCred, IGSSContext, GSSFactory. Utility classes are largely unchanged: toRFC2078String has been removed, added setSupplementaryStates has been added. Constructors can now be called on wrapper classes GSSName, GSSCredential, and GSSContext. GSSManager wraps GSSFactory. The new draft introduces a system-wide GSS vs. bundled GSS distinction. Also, it now specifies how to optionally integrate with Java's provider model. This allows a means for vendors to register a system-wide implementation, and offers a means for applications to discover GSS implementations, based on standard classes from java.security (java.security.Provider class, java.security.Security class). The providers list is read by the JVM at startup, and can be changed dynamically. A GSSManager can get the provider list, and can query each GSSFactory implementation about what mechanisms it supports. Applications can access multiple mechanisms from multiple implementations simultaneously. Sample applications have been added to the draft. One pending issue is whether a means should be recommended for applications to find implementations. Mayank believes that a standard means should be specified, and that an application should be insulated from implementation-specific details. He recommends the provider model as offering a solution consistent with Java practice, noting that the Java crypto API uses providers and that an upcoming version of the Java SSL API may also do so. Use of providers is to be confirmed on the mailing list. For multi-mechanism implementations, the concept of an intermediate context layer arises. When the default mechanism is requested, a context isn't bound to a mechanism until context establishment is performed. Thereafter, a means is needed to get at the actual selected mechanism. Several alternatives were discussed: (1) pass all required information when creating context object (but even this isn't sufficient if SPNEGO is used, so didn't seem workable); (2) use a different interface for context establishment, returning a new one for per-message calls (prot-ready might further complicate this choice, though it may still be possible); (3) live with the indirection. Ted Ts'o asked whether the indirection cost of (3) really constitutes a barrier. Mayank believes that no buffer copy would be necessarily be needed. The apparent sense of the room was to accept the indirection of (3). Another issue concerns input-output parameters for the GSS per-message calls. The javabind-02 draft has a container class that is used to pass and return parameters. Usage of this approach is somewhat complicated by the fact that different calls accept and return different combinations of parameters. As an alternative, required input parameters could be passed directly with an interface (e.g.,, MessageResult) returned. Sentiment was neutral; the working position is to keep the approach as currently proposed. An issue arises for channel bindings, as Java doesn't support non-Inet addresses. Peers could, however, agree to insert non-Internet addresses themselves in an externally specified format. As an alternative, the current definition could be modified, defining 22 static constants for different address types analogous to those defined in the GSS C bindings. It was unknown whether any existing implementations interpret channel bindings for non-Inet address types. It was also believed that few if any non-IP GSS apps exist, though Appletalk might be an exception. Ted Ts'o asked whether the current approach would support IPV6 and interoperability between C and Java GSS implementations for either IPV4 or IPV6. It appeared that Java needs an extensible address class (including both IPV4 and IPV6, even though not non-Internet address forms), which Jeff Schiller (MIT) believes it has. Question: does the Java equals method compare Ipv4 and Ipv6 addresses correctly? Some further Java research is needed here. A few other issues are to be considered. The first is whether GSS names should stand free of the Java principal interface. In the javabind-02 draft, java.security.Principal is used for tighter integration with Java security APIs. Mayank considers that this integration might be an issue in browsers where principal constructs are unavailable, and intends to research this point. A request was received on the list for use of type safe constants: an advantage of this approach is compile-time checking, but a disadvantage is switch or case statements cannot be used on such values; this question is to be considered further. Currently, a single exception returns both major and minor status. As an alternative, an exception hierarchy could be constructed. At the cost of complexity, this approach could allow selective dispatch on different errors. A GSS-level question arises here, which John Linn plans to investigate: in what (if any) combinations are different major status codes conformantly permitted to exist in conjunction with one another? It was also pointed out that some implementations may apply different interpretations for minor codes depending on the major status values with which they occur. A question arose as to whether the group should wait to finalize the SPI before advancing the higher-level Java bindings document? Paul Leach, Ted Ts'o, and at least one other individual argued that there's risk in having the high-level doc lead, lest its facilities prove inappropriate and provision of multiple providers prove important. It was noted that prior lessons demonstrate that extensibility is hard, and that it's difficult to anticipate what provisions may be needed. In the interests of balancing these concerns with the agreed intent to advance the high-level document promptly, it was agreed that the appropriate next step was to solicit list discussion of features and characteristics desired in a Java GSS SPI. It was hoped that this would enable determination of whether or not conflicts exist with the high-level Java bindings design. GSS LOW-INFRASTRUCTURE MECHANISMS Wes Doonan (Surety) led discussion on the SSKM draft (draft-ietf-cat-sskm-00.txt), which is based on secret-key cryptography within an SPKM framework. As a general premise, he asserted that GSS is good, and should be used by more applications. He perceives the following deterrents: deployment of some mechanisms requires that many changes be made simultaneously, and uncertainty breeds resistance. He believes that a simple-to-deploy mechanism would help, and that reuse of SPKM and other known technologies is good. SSKM has no changes to SPKM's messages or syntax, or to confidentiality or OWF algorithms, but integrity algorithms are changed to mandate HMAC-SHA. Key establishment algorithms are also changed in SSKM. While rsaEncryption is mandatory in SPKM, SSKM recommends Bellare/Rogaway AKEP2 with DES or 3DES as K-ALGs. Wes believes that this approach is built on a solid cryptographic basis, with a proof of security already in place. Paul Leach believed that exportability isn't an issue for the key size used in key derivation, but noted that the use of different OWFs would impact the ability to share a common password data store. Bob Blakley pointed out the general cryptographic principle that it may be dangerous to reuse the same key within different protocols. Ted Ts'o commented that he doesn't believe that there have been any open source SPKM implementations, so there may not be an apparent straightforward path for deriving an open source SSKM implementation. Wes has implemented SSKM, but doesn't know whether this implementation can be made freely available. It was observed that IBM's free PKI implementation might be a useful basis in this area. Reviewing the sense of the WG as recorded at the Minneapolis meeting, the active position is that advancement of a LIPKEY-based mechanism should be pursued. Mike Eisler (Sun) gave an update on LIPKEY. As high-level review, he described LIPKEY as following the basic SSL model within an SPKM framework, using server-side certificates. Regarding prospective LIPKEY-SSKM integration, his consideration was that this wouldn't be very meaningful, since password usage is different in the two mechanisms. LIPKEY is intended to work over any existing password schemes. SSKM assumes that the target knows the client's password, but LIPKEY assumes that the target knows how to verify the client's password. Other LIPKEY changes and change candidates were presented. The current -01 draft adds an SPKM-3 definition (allowing a secure channel without prior knowledge of a target certificate) and support for anonymous LIPKEY initiators. Changes are planned for OID assignments (SPKM-3 and a NULL-MAC I-ALG) and for an unencumbered signature algorithm. Incorporation of a stronger integrity algorithm than DES-MAC is to be considered. Some discussion took place on LIPKEY's value to the IETF community in general. A GSS-based mechanism is applicable to applications such as NFSV4 (to which LIPKEY is being presented as a potential solution), as well as FTP and some others, but it appears that the general E-mail and web community is implementing and using digest authentication directly rather than adopting GSS. Paul Leach commented, therefore, that provision through GSS isn't solving the broad problem. It was asked whether anyone was interested in specifying a GSS-based digest mechanism. Jeff Schiller, as area director, believed that interest by the NFSV4 WG would be sufficient to motivate proceeding with LIPKEY; Mike believed that such interest does exist. Jeff also observed that the security of LIPKEY is stronger than that of digest. Denis Pinkas presented an update on GSS-EASY, an OWF-based mechanism proposal. Relative to the previous version, the current draft (now available as draft-ietf-cat-gsseasy-00) adds a confounder prefixed before the first block to be encrypted. In prior discussion, concerns had been raised about ASN.1 usage, and about GSS-EASY's encryption scheme. Denis noted that other mechanisms under discussion also use ASN.1, and that a free SNACC ASN.1 compiler is available (see ftp://ftp.fokus.gmd.de/pub/freeware/snacc/). Denis stated that GSS-EASY's encryption scheme has been presented to some knowledgeable experts, and that no flaws have been identified. John Linn summarized the current WG status re low-infrastructure mechanisms as follows: the intent is to proceed on LIPKEY, and to discuss SSKM and GSS-EASY further on the mailing list to decide on future actions for these mechanisms. AUTHORIZATION SERVICES Cliff Neuman gave an update on GAA activities, followed by a broader discussion led by John Linn on authorization directions for the CAT-WG. A new GAA draft is available. ISI has a reference GAA implementation, which is to be released soon. Integration work with the Globus project is concerned with defining CA policy, and for running remote applications. ISI would also like to integrate GAA with other targets on a case-by-case basis; NT ACLs and Diameter were proposed as candidates. It was recognized that a strong set of integrated applications is necessary in order for the approach to be validated. Cliff commented that the GAA document might be ready for a final edit following the upcoming Washington, DC IETF meeting. Changes in the recent GAA draft include the following points. Goals include support for existing ACL and policy formats. The set of defined CA types now includes a CA, and trust constraints for CAs have been added. It is now stated that policy inheritance is to be supported by policy retrieval function and included ACLs. Parameterized operation is supported. Denis Pinkas pointed out the comments he had recently made to the mailing list regarding GAA, and also suggested that it would be worth consulting with Bob Blakley (Dascom) regarding the relationship between GAA and the authorization API contributed by Dascom into the Open Group and currently being discussed there. Bob Blakley stated that he would plan to make this specification available to the CAT WG on an informational basis, and commented that he believes that GAA could be layered under this API. Authorization services and interfaces are a large and important topic. While the CAT WG has long-standing interest in this topic, and approximately 5 attendees expressed possible interest in making active contributions in the area, group discussion of currently existing drafts has been very limited. The demonstrated constituency for CAT's current authorization documents has been small, and significant further effort is required to determine their suitability to satisfy application needs. Webdav was cited as one candidate worthy of investigation. Candidate priorities for authorization services are being discussed on the mailing list, and a summary slide was presented; one attendee commented that ability to support distributed objects and DCOM would be an additional useful criterion. It was recognized that current work merits further visibility and investigation. Marcus Leech (Nortel), for example, observed that GAA might comprise a convergence point between policy and attribute certificates. Given these factors, the WG's current intent (per a suggestion from Jeff Schiller) is to target authorization-related documents produced within CAT for Experimental publication once a suitable level of stability is reached.