Kerberos workshop meeting notes:

These were compiled from generous notes contributed by R.L. Bob Morgan, Jeffrey Hutzelman, Steve Rothwell, John Linn, Mike Callahan, Harrison Carter, and Prasad Jonnalagadda

These notes have not been reviewed by ANYONE for accuracy.
Workshop agenda
Steve Rothwell's notes

Kerberos v4 libraries:

MIT has cut over to the Cygnus v4 library and is doing no maintenance work on v4 for UNIX. MIT is still doing some work on the v4 libraries for Windows and Win32. They are using Kclient for the Mac. MIT seems to be moving very strongly toward V5. They are not building or developing any V4 apps under UNIX , but they still have quite a few V4 clients that need to be supported and some of these applications remain to be implemented on non-UNIX operating systems.

Other sites are interested, but moving more slowly. One of the main obstacles seems to be that for many sites, moving to V5 means moving to DCE, and the current DCE kdc does not provide a V4 server. [more on this topic later]

This lead into a brief discussion on the state of authenticated and encrypted telnet:
tytso: they were tring to stay in sync with BSD telnet, but it's too hard to do, so they're not in sync now
tytso and Derrick Atkins (warlord) to work on finishing spec for submission to ietf.

How to get Vendors interested in Kerberos:

Nearly all of the attendees have an interest in getting vendors to support Kerberos. Either because they have an existing Kerberos infrastructure in their organization and wish to have a more integrated security solution or because they are vendors of a Kerberos implementation/infrastructure and they want more vendors to support it in applications so that they will increase their sales to clients. So we briefly discussed what would be needed to increase the visibilty of Kerberos in the marketplace.

First, it is felt that documentation should be provided for writing Kerberized applications. Mike Callhan commented that OpenVision continues to expand its documentation and set of sample apps for applications programmers, and would consider donating some of it to MIT [note that this would tend to be GSSAPI / V5 specific]. Cygnus agreed to provide their Kerb4 to Kerb 5 migration document. It was also agreed that there is a need for better documentation of configuration issues (eg setting up realms, principal maintenance). UMich has a "kerbcheck" program which detects many common client configuration errors, and will make it avaiable to anyone who wants it.

A few people also commentted that MIT lacks a comprhensive Kerberos web page that would lead developers and vendors to wide ranging information about Kerberos. MIT agrees that this is currently the case and hopes to resolve it in the future. Our best effort at the moment is at

Many attendees assertted that a short course on 'Kerberos Fundamentals' would go a long way in familiarizing Kerberos to the user community. During the course of organizing this workshop it was clear that many people that initially responded but did not attend were looking for such a course. We are looking for someone among the attendees to step forward and sponsor or organize such an event.

Someone asked if someone would be willing to write an O'Reilly book. At least one attendee was approached with such an offer in the past but did not have enough time. It is not clear if O'Reilly would be presently interested in the topic, someone felt there was no current interest from the publisher.

Some application vendors have expressed an interest in adding Kerberos support to their applications but do not have the resources to run their own Kerberos realm for internal testing of the product. At least one vendor has an extreme situation of this because they OEM their application to many other vendors. Such vendors would like to have a test realm available to them. During this discussion Cygnus tenatively agreed to provide this as a no cost service. Contact Nancy Gilman ( at Cygnus for further discussion. Cygnus should be able to provide support for people needing to test both v4 and v5 style relams. Derrick and Jeffrey Hutzelman volunteered Dementia for cross-realm and AFS kaserver testing as well.

Apple suggested that the Kerberos community needs to address v4-v5-DCE interoperability and inter-realm issues. There are some problems that need to be solved and we need to provide a clear paper that discusses the issues and the various solutions.

What are vendors up to?


Erik Fair, also Apple's [Erik is no longer with Apple] most visible IETF participant, was their representative here, seemed very interested in working with people to better support Kerberos on MacOS. However, there aren't a lot of resources, so he needs help convincing management and engineers to do things, and to do the right thing. still fighting with both marketing and IS Garry Hornbuckle now reporting to Heidi Roizen Applelink going away in March


Sun is still working on GSS support for ONC RPC and NFS.


Martin Haeberli is now director of technology for Netscape. As far as anyone can tell Netscape has no plans to offer any type of Kerberos support or integration.

Peoplesoft and Informix

Cornell has commitment from Peoplesoft and Informix to do GSS for the Mac. FWIW, it looks like informix has committed to GSS support, probably including a sample implementation based on V5.


v4 support in DCE secd ask your vendor, Bill Sommerfeld did the hacks a few years ago [more on this topic later]


yes they're doing V5 for NT 5.0, will backport to W95, SSI API is similar to GSS but of course no encryption for now [ more on this on Thursday]


Cornell University presented information about Kclient. It was originally developed by Mandarin Consortium for the Macintosh, there is also a version for Win16 and a Win32 will be made available.

KClient is available publicly, and not restricted to Mandarin consortium members. Project Mandarin is at least moving away from code development, and so will probably not be doing much more on Kclient, either. They are looking for a home for it. There will be a need for more development soon; as of MacOS 8, the sort of driver interface that is currently used by all the Mac Kerberos implementations will be going away, so any such software will need to be reimplemented. [Since the meeting it has been announced that the Mandarin consortium is dissolving, the consortium is making sure that Kclient will continue to be maintained and distributed.]

Mandarin on Win tries to write only to CUSSP API, not to the Kclient API, on project 2000 their version of AIS

1.6 (from 1.5) added server-side stuff on Mac 1.7, from Dartmouth - A menu-bar icon to authenticate
- A floating window to show who is authenticated. Closing this window destroys the tickets.
- Support for user-selectable ticket lifetime
- Fuzzy-matching of user's names to figure out who to authenticate as
- Some code to thwart keystroke capture utilities.

Eudora, Keyserver may be the only commercial apps written to Kclient at this time. There also some telnet implementations using it.

UMich has "kerbcheck" to check settings for Kerberos compatibility for Win

Time Skew Issues:

some have noted that KDC will give TGT with up to 15 minute skew but app servers usually require no more than 5 minutes so set your KDC not to do that

Ted clarified that Kerberos server by default allows up to 5 minutes time difference. There is a strong need for synchronizing the servers and client machines using nntp. However, it is generally agreed that synchronization of a Macintosh is troublesome.

A surprisingly common failure mode is for a KDC to be configured to allow the time skew seen during a ticket request to be larger that the time skew which other Kerberized servers will accept. MIT has played with code in the KDC to detect the client's offset from "accepted time" and record it in the granted ticket.

IP addr change upon re-dialup causes weird problems
have kerb check and let user know
but IP addr isn't available
so change credential struct to have orig client IP
or add another ticket
Mac KClient already has this fixed?
not an issue for us since kaserver doesn't check IP?
not a K5 problem since IP addr is in the cred
and you can also get cred that is not tied to IP


UMich is not doing any more development on AuthMan, but it's not going away anytime soon. Authman guy now at Netscape but they need to support it on Mac more or less indefinitely.

OS/2 support

it's there in K4 DLL, but not thread-safe grad student left, may be available for consulting? app-level mutex stuff is the only way to go MIT working on getting rid of blocking IO for NT. Update: MIT broke the native OS/2 support in the latest release. Does anyone care?

Kerberos and the WEB

Kerberos and Web: The majority of the talk on this subject came from universities. The implementation variations at different universities were discussed; many (maybe even half?) used SSL (secure socket layer). All these models are basically authenticating the user. Implementations either use a proxy configuration or a callback mechanism.

Cornell developed SideCar. [The notes for this are pretty sketchy, does anyone have any better information.]

At Cornell, they hard coded the authorization stuff into CGI.

They are using SideCar to do print authentication as well. They are also using a hack to map AppleTalk to IP addresses. Stanford observed that this is similar to the Webstar plugin. ArmorCar [SideCar?] can look at local users/groups.

Mandarin permit server is the central ACL facility used for many things. There is an explicit "no auth allowed" setting so someone doesn't turn it on again for a bad guy but, permissions go in but never seem to go away (in general).

At CMU, the Shelob ( client was developed to talk to the Web Server. They need to support Mach and Ultrix. The system is based on a proxy which uses kernel groveling to see who's talking to it, then it sets itself to your uid. CMU computing services is rewriting much of it in Java. [Further?] info in andrew2. There is a privilege server hands out capabilities to cgi programs. This is time-limited to solve a problem of limiting power of broken cgi's.

Umich's KLP ( or or ) is developing a taxonomy of Kerberized Web approaches, and is building a web page documenting all known work on the topic.

KLP uses a K4 ticket in header. The same code base is used for different platforms. Presently deployed for use in house.

Netscape has some hack to do use-proxy decision based on Javascript specify URL in prefs of where to get script from ignores whether Javascript is on or off. [Anybody have a better write up?]

Stanford has developed their own Webauth. [further info or a pointer?]

MIT Ecat

Ksign, some are already calling Ksign a legacy system, even before it has been deployed, with two of MIT's vendors commited to using it, while it would be difficult to get more of their vendors to use the system. Ted presented the model. It is an electronic secure trade transactions system on the web. It coordinates the order transactions from MIT to the vendors order DB through 'transd' daemon. Transd daemon transact with AMEX (for credit card payments) and Vendor DB.

Although this system has many points of failure MIT has decided to deploy it. They already agree that they wouldn't use a design like this again. The "transd" part was the problem; it's the hairy part written and supported by Netmarket, who dropped it when they were purchased and most of the development staff left. The vendor operators did not start off too clueful so it was failing a lot, that's a problem so they tried to figure out what to do. Originally the project never had enough clout to fix the problems. Recenly many of the business problems have been fixed and late testing was showing a 95% success rate. It has been decided to deploy this system to MIT in March of 97.

MIT expects to redesign the system during the next year. Most likely moving to a PK based system with client side certificates.

Breakout sessions

Windows Credential Cache Issues:

Ted presented a 'proposed specification' for Windows Credential cache. He opined to keep the information in dll's. This strategy will be implemented to work in both 16-bit as well as 32-bit environments.

This was covered at the end of the day in a breakout session, and summarized the next day, at which time Microsoft made supportive noises about the proposal.

Mike Callahan gave Ted new names for DLL's: GSSAPI.DLL is now GSS16.DLL for 16 bit windows and GSS32.DLL for WIN32 LIBKRB5.DLL is now KRB516.DLL and KRB532.DLL ADMIN.DLL is now KADM516 and KADM532 RPC is now RPC16.DLL and RPC32.DLL

Mac breakout

UI issues for future v5 interface on the Mac. The various v4 communities talked about what they liked and what they didn't.

Student systems at Dartmouth avoid putting a user's name on page with personal info on it they were horrified aout a floating window with the user's name in it. CMU changes the background bitmap to indicate that a user is logged in. NCSU sets ML to lock screen after 2 minutes, and log out after 10. There is concern with the general issue of having proper hooks into boot sequence. There were comments and hope that Apple may address some of this because of needs in the home market.

The Mandarin environment deals with timeout etc, external to Kclient. A notification manager can be called from faceless application so maybe an agent could use that for something?

There was a suggestion that the interface could use "system" windows too, via text services manager. It was pointed out that this method is not a supported or documented. Someone got some interal source code. Maybe Apple would be willing to release this for real.

Support for drivers is going away at some point in future versions of MacOS. It appears that CFMs are the way to do it. MIT shipping CFM-based V5 for 68K and PPC for SAP. Unfortunately it presently stores tickets in a file while KClient stores tickets in memory. A better login is needed for V5 now that it's stable.

Side comment on GSS: even MIT folks other than Ted don't know how to use it very well at this point. The API has a steep learning curve.

Chris Cotton an MIT alum at Apple is working on cyberdog, wants kerb in it, 4 or 5.

KDC on MacOS? Cornell almost finished it with v4 no one has tried non-UNIX for v5 KDC. (See later notes on Microsoft :( ). v5 client libs are very multi-platform but the applications are not at this time.

What about Hesiod? How about a generic lookup interface that abstracts hesiod, LDAP, etc any previous practice?

Intercon Interprint works with MacLeland (Andy Maas did it ...) uses hesiod to look or printer list, show it in Chooser, then uses kerberos to talk to MIT klpd.

There was talking of reviving discussion between the Mac developers via a mailing list. Brown has set up a list a long time ago but it wasn't used lately. Try to publicize this and get the traffic going agin.

Day 2

The integration work performed at the University of Illinois between GSS-API and Java seems to be currently moribund (its responsible graduate student having proceeded to other activities), but is available as a basis for follow-on work by anyone interested. Some other prototype-level work has been done at Stanford and Cornell. It was noted in discussion that two rationales and approaches have been posed for use of GSS-API/Kerberos in conjunction with Java: (1) implementation of Kerberos within Java as a portability vehicle, and (2) implementation within Web browsers as a means to provide distributed security for Java-based applications. General sentiment showed more interest in (2).

We spent a short time talking about UIUC's JGSS (Java GSS), and other issues related to Kerberos authentiction from Java apps, and authentication of/by Java applets. Unfortunately, no one from UIUC was around to discuss it, but some other people said some stuff.

CMU had some comments that indicated that when securing Java connections signed applets make all the difference. However there is strong contention with this statement. Many believe that the technique is not sufficient.

Someone brought up shttp, (secure HTTP), which was on the agenda for yesterday. SHTTP (for which Kerberos hooks had been defined) is widely perceived to be dead, largely due to lack of interest from Netscape and Microsoft. It seems to have lost to SLL, in the eyes of both the IETF and the vendors. Both Netscape and Microsoft believe that their certificate-based systems (i.e. SSL) are better (and already implemented) ways of doing the same thing. Microsoft has, however, implemented a private version of Kerberos-protected HTTP. Interest exists within some quarters (Charles Schwab being cited as an example) in DCE-protected http. There was an assertion (which one attendee found surprising) that the Web Consortium's HTTP 2.0 will, driven by requests from Netscape, include CORBA V2.0 in its Internet interoperability mode.

Kerberos 5

The base Kerberos protocol specification (RFC-1510) is overdue for revision; Ted will approach its author (Cliff Neuman). Marc Horowitz (Cygnus) hopes to provide an update to the secure FTP specification, and a separate draft on behalf of the Triple-DES working activity, shortly.

MIT's 1.0 will be out by 1/1/97 See for the current status and availability.

Windows 3.11 support is in the release tree. NT won't be integrated yet, but in a separate tree. A subsequent release will include the NT support in the main tree. Cygnus does have NT support in their tree. This work will form a large part of the subsequent MIT NT support.

Triple-DES support will also accompany the release but on an unofficial basis; discussions have been underway between Kerberos developers and cryptographers about specific design (intended to be documented during November in an Internet-Draft).

MacOS support is there with CFMs for PowerPC and 68K. The UI is rank theft of KClient, and needs lotsa work, let's do it! There is a modified NCSA Telnet for the Mac in the tree. As of November it did not support encryption but did support authentication. CMU has been working on NiftyTelnet on the Mac with v4 encryption.

MIT is using the GSS API CFMs, DLLs, and shared Solaris libraries with SAP's client. MIT's intent is that all internal MIT applications which are to be integrated henceforth with Kerberos technologies will do so through GSS-API, not through lower-layer Kerberos APIs. Repeat after me, "Kerberos is a protocol, it is not an API."

Mike Callahan spoke on OV's approach, as implemented in netsock, of encapsulating GSS-API within a C++ communications class; the concept and presentation were received with interest.

Microsoft and Kerberos v5

Microsoft will be including Kerberos within NT 5.0 as the basis for distributed authentication with NT domains. In addition to supporting access to Kerberos via SSPI (a Microsoft-defined variant of GSS-API), access via the standards-compatible version of GSS-API will also be supported, though specific dates were not announced.

It was said that NT 5.0 Beta release will be Q1CY97 (end of Jan'97). It should be noted that Microsoft had several authentication projects ongoing. Microsoft now is committed to their project which is a standards-compatible Kerberos implementation. They wrote it from scratch using the published RFCs and draft standards. It does not support the admin API.

Richard Ward ( stated that Microsoft's code currently uses different name types and string-to-key algorithms than MIT Kerberos, but that this would be aligned by NT beta time. Microsoft will expose only the SSPI/GSS-API interface layer, not lower Kerberos layer APIs, though a separate ticket cache interface may be provided. SSPI facilities will be back-ported to Win 3.1 and MS-DOS platforms.

The ticket cache is stored in virtual memory, but may be ticket cache GSS-compatible, using snego (

"The Simple and Protected GSS-API Negotiation Mechanism", E. Baize, D. Pinkas, 05/15/1997. (32523 bytes)

This draft document specifies a Security Negotiation Mechanism for the Generic Security Service Application Program Interface (GSS-API) which is described in [1]. The GSS-API provides a generic interface which can be layered atop different security mechanisms such that if communicating peers acquire GSS-API credentials for the same security mechanism, then a security context may be established between them (subject to policy). However, GSS-API doesn't prescribe the method by which GSS-API peers can establish whether they have a common security mechanism. The Simple and Protected GSS-API Negotiation Mechanism defined here is a pseudo-security mechanism, represented by the object identifier ( which enables GSS-API peers to determine in-band whether their credentials share common GSS-API security mechanism(s), and if so, to invoke normal security context establishment for a selected common security mechanism. This is most useful for applications that are based on GSS-API implementations which support multiple security mechanisms.

Microsoft intends to extend to GSS-V2 support; this will be scheduled once the GSS-V2 high-level and C bindings specifications have advanced to RFC level.

Richard noted that Internet Explorer 3.0 and IIS can now support a "web-authenticate/Kerberos" or "WWW-AUTHENTICATE header" [not sure which is correct pbh] indicator in http, which allows GSS-based http protection (extensible to multi-hop transactions through the GSS_CONTINUE_NEEDED facility). "Just stick in base64'd GSS-encoded ticket ..." It works because both ends just pass it to SSPI interface. They do not have a specification but there is an example somewhere… This is done via Microsoft's KDC and will not support the MIT/OV administrative interfaces.

Currently, Microsoft is using SSPI/Kerberos for authentication only, recommending SSL where privacy is required, but per-message confidentiality interfaces are to be provided in NT 5.0. Microsoft's Kerberos usage includes authorization data (group identifiers) within tickets; this is somewhat analogous to DCE PACs but a single principal is used to represent both the KDC and privilege server functions. The PACs are based on the NT SIDs. It is this feature that will cause the most problems for sites with existing Kerberos infrastructures and attempting to integrate NT into the existing infrastructure.

"Directory Services and the KDC are tightly bound." Cross-realm traversal is based on walking the DNS hierarchy, though short-cut paths may be configured. There was also mention of cross-realm management via policy objects in directory, administered via LDAP. This should be in beta 1.

Microsoft plans to use the same code-signing scheme for SSPI providers as is applied for Crypto API (CAPI) providers, presumably preserving the same export treatment as a result; Richard commented that the Microsoft web site references to export were maintained by the Microsoft legal department, and should therefore be relatively trustworthy. The CSP SDK is export-controlled and MS has to sign CSPs. They will do so only if you say you're not exporting, or you have judgement from Commerce for exportability.

GINAs are still the way to provide support for other services during login but the implementation needs work based on feedback from customer sites. E.g. people are upset that only one GINA may be used. For more information about GINAs and Kerberos see

DCE and Kerberos version 5 interoperability

Doug Engert (Argonne National Labs) led a discussion about Kerberos interoperability, particularly regarding DCE. As mentioned yesterday, OSF has no intention at the moment of supporting V4 in DCE, though this would not be technically difficult to accomplish.

The MIT V5 KDC does provide a V4 server that serves V4-style tickets from the V5 database. Such a service would be possible for the DCE registry and KDC, and some work was done on this, but no one is shipping such in their product, due to a perceived lack of demand. Some sites have done single-service translators. For example, you have a modified aklog that gets a service ticket from the V5 or DCE KDC, and hands it to a translation server, which gives you a V4 service ticket for AFS. Also, it should be possible to set up a separate V4 database, with a service running on the V4 server that would give out tickets from the V4 database when presented with a V5 service ticket.

Although DCE code is based on K5-beta 4, and cache and keytab locations differ, Doug has achieved interoperability with K5-beta 7, including cross-realm authentication with DCE 1.1. The cross-realm setup requires that three principals be established with the same key: two for each direction with MIT Kerberos and a third within the DCE cell.

Divergences between MIT and OSF re cross-realm traversal rules have reportedly been fixed with recent modifications provided to MIT. The DCE registry editor can be used to make keytabs for use with MIT Kerberos.

In DCE that Authentication Server is splittable from privilege information. So you could theoretically do authentication via a non-DCE server and then pass that something to the Privilege Server for evaluation. This can be key to working with multiple authorization domains. One comment that this "needs to move from cute trick to a design principle." Using this idea an MIT Kerberos ticket can be used to replace the DCE authentication service exchange, but a privilege server exchange is still needed for subsequent DCE operations; this mode of operation successfully exploits forwardable ticket facilities and might also be useful for MIT/NT interoperability scenarios. [This won't quite work so well with NT because of some MS design decisions. Pbh ]

DCE 1.2.2 was development-frozen last week [November '96]; among other features, it includes a facility for login integration with public key certificates.

There's a fair number of academic sites interested in DCE and AFS. Gradient Technologies is considered a key DCE player, but was not represented. They have DCE on NT coming out soon, their port to the Mac "is delayed".

On several occasions Ted emphasized that he felt that V5 was a sensible waypoint for V4 installations who want to upgrade to DCE.

Of more interest, at least to CMU, was a discussion of interoperability between V4 and V5, and transition from one to the other. Ted T'so begin with an overview of the incentives behind supporting backward compatibility for V4 in the V5 server, and a description of some of the mechanisms provided to support this.

There are several components available to handle conversion. - Mechanism to convert a V4 database to a V5 database (non-interactive) - A KDC is available that can serve V4 TGT's from a V5 database - A service is (or will be) available that can serve V4 service tickets from a V5 TGT - A kadmind is available to allow users of V4 admin clients to change their passwords, even though a V5 database is in use. Other admin operations are not currently available to V4 admin clients, though Ted would like to make them available sometime after Kerberos 1.0.

The current state [November '96] of affairs at MIT is that the master Kerberos server is a V4 server. However, one of the slaves is a V5 server, so each time a slave propagation occurs, the V5 server converts the V4 database to a V5 database. Users can use V4 or V5 clients for most operations, but must use V4 clients for password changes.

Note that K5 supports multiple string to keys with hint to client as to which one to use.

v4 GSS mechanism? DEC may have done one some time but it's lost now.

more vendor stuff

Oracle SNS v2 does K5 now (as well as DCE). Oracle Secure Network Services V2 for Windows is dependent on use of Cybersafe's Kerberos library and its ticket caching model. On UNIX, SNS has separate options for MIT and Cybersafe Kerberos; specifics of differences weren't discussed.

Work is underway, including OV, on defining a common credential cache access DLL to enable single sign-on when multiple Kerberos-integrated applications coexist on an end system. One approach for login integration for Win95, proposed by someone from the University of Michigan, involves construction of a pseudo-network provider. More information on this topic can be found at

CMU has GINA for simple access control also tries Netware "guest" login, deployed since 9/96. CMU is also working on zephyr for NT, and klpr.

UMich one does much the same but also has hooks to do SMB/Samba login ... mounts whatever is in user's profile not done yet, has to work by January also have "pseudo network provider" for W95

Open Vision has one too, but it doesn't do access control

MIT has implemented a client-server Kerberized version of CVS (the version control system, not the drugstore :-), with clients on both NT and UNIX platforms. [Actually someone else (Cygnus?) did the Unix client and server, MIT has added this support to the NT and Mac clients. Pbh ] MIT had also done preliminary, uncompleted work on a GSS-ized compressor for the X protocol.

Cygnus has a GSS-ized FTP with forwardable tickets, tailored for use with AFS; support is also provided for X9.9 DES-based token authenticator cards.

In addition to GSS integration within SAP R/3, SAP has also implemented a GSS-ized version of lpr, but its availability (if any) independent of R/3 is unknown.

MIT has license for Wlprspl, and source to Thomas Heil's wlpr2.dll they added Kerberos v4 and Hesiod support to the DLL. If you have a source license for wlpr2.dll you can get their mods. Or if you have a license for wlprspl you can get their kwlpr2.dll binary.

Some comments on Kerberos scalability

The MIT Kerberos database has 40,000-50,000 principals; peak observed transaction load was about 5/second, 1/sec is normal. Note that the number of users at MIT is smaller than this but students have a ".extra" principle to get at some of their data from the registrar's office. CMU has 17,000 - 20,000 principals, North Carolina has about 40,000 principals. Michigan's is about 70,000 but is based on the AFS (V4) kaserver. (Many of the universities are still using Kerberos V4 and are concerned with transition issues.)

Mark Horowitz mentioned that Cygnus has filled a Beta 7 database with over 1 million principals and managed more than 200 transactions per second on "wimpy" (old Sun?) hardware.

PAM, Pluggable Authentication Module

There's now a freeware Linux implementation of Pluggable Authentication Modules (PAM), the proposal originated by Sun, now a part of the X/Open CDE, and soon to become part of DCE. Unlike NT GINAs, PAM allows stacking of multiple login mechanisms. PAM checks passwords against the constraints of all stacked mechanisms before entering them into any. Ted Ts'o encouraged development of a Kerberos V5 PAM module, but no commitments have been made.

Public Key Infrastructure and Kerberos

After lunch, Jeff Schiller started to talk about X.509, SSL, and how they can be related to Kerberos. He started out with an overview of what SSL does and how, and the motivations behind setting up a Kerberos-based CA.

How Netscape Navigator key-generation works: - Netscape added a new form field tag , with "name" and "challenge" fields. This tag is rendered as a pulldown menu allowing the user to select a key length. When the form is submitted, Netscape will generate a key pair. - The private key is stored in a Berkeley DB_HASH file, key.db, in the Netscape preference directory. - If the user has never generated a key before, Netscape gives the user a dialog box, allowing them to set a password to protect the key database, and set preferences controlling how quickly the password will be expired after the user types it. - Netscape then generates an object consisting of the generated public key plus the value of the "challenge" attribute (from the KEYGEN tag), encrypted with the generated private key. The resulting object is base-64 encoded, and sent as the value of the KEYGEN-tagged form field. - At this point, the first part of the process is complete. - Sometime (anytime) in the future, the CA sends Netscape a document of type Application/X-509-User-Cert, the contents of the document must be a X.509 certificate, certifying the user's key. If Navigator can find the resulting key in the key.db file, it adds the resulting key pair as a usable personal certificate.

What MIT does: - Basically, they have a server that sends the user a form containing fields for his Kerberos ID and password, and a KEYGEN tag. When Navigator sends the form back, the CA CGI attempts to get and verify a TGT for the user, and if it is successful, sends a signed X.509 certificate back to the WWW client. Note that KEYGEN is unique to Netscape at this time and that MIT is not supporting MS IE. - Naturally, any servers wishing to use such certificates to authenticate clients must have a copy of the CA's public key that it trusts.

What Verisign does: - Class 1 certificate: Asserts that the public key in the certificate belongs to someone who reads email (legitimately or not) at the email address specified in the certificate. - Class 2 certificate: Requires credit-card number, which is compared (along with the address the user provided) against credit bureau reports. Not perfect, but much better than Class 1, especially after the user gets the bill and doesn't complain.

What MSIE does: - Instead of supporting KEYGEN, MSIE uses an ActiveX script that invokes a DLL that the user must download. Microsoft only recently (days ago) decided to give away the relevant DLL. Of course, there's still the problem of the user being able to know that the DLL they're downloading.

Some of the problems:

A User can get a client certificate on one machine, but can't transfer it to another machine in most cases. Microsoft has proposal for "personal effects transfer" protocol but this is not a standard yet.

However if you can get a certificate via Kerberos and you own CA they're cheap. You could even get one at public workstation. However you would not want to use this for encrypted email J Because of course once you send mail or sign anything that will be stored or archived your keys become valuable and not something you want to throw away.

which key to use? The browser has a few options, " ask me, or use this one, or let browser choose." But browser choosing only works under SSL 3.0

which CA? Thebrowser has to trust CAs for certs for *servers* , *servers* have to trust CAs for clients. So MIT has two, one for servers, one for individuals.

Revocation? servers can use any protocol for accessing CRLs however browsers can't deal with this yet. You have to revoke the CA and therefore all the client certificates in the worse case.

S/MIME coming fast how about a way to translate PGP key into X.509 cert on the fly when you want it, eg to send S/MIME mail

availability of Diffie-Hellman after 3/97 will put more pressure on RSA to make their contracts more friendly