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
Disclaimers:
These notes have not been reviewed by ANYONE for accuracy.
Workshop agenda
Attendees
Steve Rothwell's notes
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.
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 http://web.mit.edu/kerberos/www/
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 (nlgilman@cygnus.com) 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
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.
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
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
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
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 (http://www.cs.cmu.edu/~visigoth/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 (KLP.WTO@umich.edu or http://www.itd.umich.edu/NNMKLP or http://www.itd.umich.edu/~umklp ) 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.
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
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.
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.
MIT's 1.0 will be out by 1/1/97 See http://web.mit.edu/kerberos/www/ 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.
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 (richardw@microsoft.com) 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 (http://www.ietf.cnri.reston.va.us/ids.by.wg/cat.html)
"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 iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) 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 http://web.mit.edu/cartel/ntgina.html
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.
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
http://web.mit.edu/tytso/www/krb5-ccache-proposal.html
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.
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.
How Netscape Navigator key-generation works:
- Netscape added a new form field tag
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
What are vendors up to?
Apple
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
Sun is still working on GSS support for ONC RPC and NFS.
Netscape
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.
OSF
v4 support in DCE secd
ask your vendor, Bill Sommerfeld did the hacks a few years ago [more on this topic later]
Microsoft
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]
Kclient
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.
- 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.
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
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
Authman
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.
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.
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.
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).
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.
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.
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.
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.
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.)
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.