| C A R T E L / 9 7 | - - - - - - - - - | | University of Michigan, Ann Arbor | June 24-25th, 1997
Authentication, Authorization, and Accounting
K4 to K5
UM - move all data from k4 to k5 use Doug Engert's tools for interoperability. No need to change clients cuz Doug's servers can serve up either K4 or K5.
CMU did server transition (from real v4 - installed 5 yrs ago - to v5) 1 month ago. No clients, stock MIT v5 server, v4 password thing that comes with it.
Replication is the same in v4 and v5 but doesn't scale?? (I missed something here) Smarter, newer Kservers have friendlier replication. V5 util has a function that loads a v4 dump. Poopulates db with keys and loads them with v4 salts. Don't know if it is possible with a Kserver instead of a v4 server. Talk to Ken Hornstein (Herrnstein?) at NRL who has done this.
MIT doesn't think the first prod v5 servers will be as solid as the current v4 (up for 5 years at MIT)
Has clients that do v5, for SAP, central accounting. ECAP project (online purchasing) also using this.
Stanford - taken a diff path. Not really migrating as much as bringing in a new service. Running KAS and using DCE as the K5 server. If you go that way, you must still run K4 cuz DCE does not support K4, so you have to synch two db's (always bad). Bill Sumerfeld had a hook in the DCE 1.2 for K4 stuff, Doug Engert has a tool for it (CMU). Promised in 1.2.2 - use DCE
as K5 server but you must duplicate entries for server tabs (services). We synched db's by using K4 kadmind which puts passwd in all appropriate places. Extends to the future as well. We also have another daemon which talks to K4 and DCE directly, does adds and removes users, driven by databases. So, once you sign up for a SUNet ID, you are signed up for all the services. It takes a bunch of work to set up, but is quite automated once it is setup.
We didn't get around the change passwd problems. We need to have everyone change their passwords in the next year. We need to have everyone change their passwords in the next 12 months, added a bunch of strength checking stuff in the kadmin daemon.
Joint work opps: replication issues?
MS - planning K5-lite, incompatible with DCE.? On the wire compatible with MIT v5. Means if you could put NT5 on your desktop, point at your stuff, give it a normal TGT, have access to services, not access to NT services.
Want you to run their KVC to access their services. Will not interoperate with DCE, which wants you to run their KVC. Goal is to run MIT KVC and get into either. MS said they will give MIT sufficient info to let them generate a signed packet with a TGT.
UM - has a lot of realms. Developed some software that would auth in multiple realms if you kept the same passwd in diff realms. OK, but nice if software existed instead of just theirs. Anyone working on support across multiple realms?
MIT(done by CMU) - created keys to support cross-realm auth. Athena trades keys, but you can't do path stuff in V4. Athena services like discuss, zephyr.
Make sure that cross-realm auth is enabled and set access controls on resources and services. Engin resources can't print if they need UM auth to print. Different realms.
UM looks at multiple passwords for realms in the kth distribution. In lieu of cross-realm keys. So, it looks for more than one TGT. Other Kerberos-distributions don't do this.
Stanford doesn't have this problem cuz we only have one realm.
CMU headed toward this problem. Need to know what realm they are logging into, so the burden is on the user. But most resource and service access is compartmentalized.
Does this go away in K5? It's not as bad cuz it's hierarchical, so cmu.edu, blah1.cmu.edu,blah2.cmu.edu all trade keys. Similarly across realms if they are trusted, to get rid of N2 problem of key exchange.
Non Unix Kerberos-clients
UM to the extent they are building any new stuff, it's all K5 (but underneath GSS). However, basically, they are buying rather than building. See no transition problems in clients once the server stuff is ironed out.
Want to move away from K4 cuz of the dictionary attack.
MIT Allen Bjorkland wrote an implementation with a different API. Meeting later this week to merge these two implementations so you could call either API and store tickets in a common cache. V5 vs GSS API's? Makes more sense to write to GSS, says UM, MIT. Must move up to pure V5 to get away from exposure to dictionary attacks.
CMU figures they will never get away from V4
CMU - doing development under K4. Want a base level of stuff for V4. Lack of functions in V4 API, different API for Mac and PC. Mac UI lacking in some ways.
Cornell - not doing anything to get this functionality currently. Mac version done first.
Windows Kclient API is insufficient to implement Telnet!!
Shared work here?? Possible, says MIT.
MIT notes wide interest in API with custom look&feel. Could consider doing this.
Stanford wants naming conventions for windows clients DLL's --
MIT - K5 stuff lacking, how to build it not included, focus on this toward end of summer. Changing UI to make login nicer. Talked to apps like Eudora to see what they wanted. Just hired some mac developers to work on this.
Released an alpha of K4 for the newton earlier this year!
MIT Kerberos MS and DCE - see above
Dave - Java implementation of Kerberos? Anyone know anything? No.
NCSA done by two grad students, not touched in 7-8 months. Uses native methods to call MIT code.
OpenGroup interested in further funding but didn't want to make the source code available. Push to make it available to educational places. Want to write it all in Java (no native methods). Seems like it needs a separate cache (they are talking about non-shareable cache). CMU doesn't know why this is necessary.
Stanford mailing list for java implementation has had some interest from a bunch of different students says the MIT guy.
Joe from UofM - what about copyright student documents? What about student violations?
CMU has the Andrew Police. MPEG data by students, contacted by record companies. On student machines, also on shared CMU servers.
Enforcement - campus cops are kind of dumb. FBI is smarter. Do you attempt to enforce, or do you just shut down to save time?
UM - we aren't cops, don't want to do enforcement
UM asks complainer to contact student directly. Act more quickly for software piracy, ftp holes, etc. UM don't like anon ftp at all. Problems with people putting up random machines in a dorm, Unix, given out an account on that machine to non-UofM people. UM detects and shuts down until the account is shut down. Problem cuz UofM network is created for UofM community.
MIT lets that account exist as long as it is non-commercial.
Users auth to AFS on windows client. Mounted sw library available to faculty/staff. Sets up anon ftp. That's sw piracy.
UM has an agreement people sign when they get an Enet connection. Web site is acceptable. Anon FTP is acceptable as long as they don't break any laws or use too much bandwidth. If it's not patently illegal, they assume that it's OK. They don't censor materials now. Waiting for a supreme court ruling before they do anything else.
CMU - issues with personal certs, remember to destroy at random public machines. Hopes that you could have an auth proxy like ACAP or LDAP to ensure you only have to do this once and it persists across locations.
UM - NS was talking about using LDAP to store public and private keys.
CMU has problem storing a secret that belongs to a user on a centrally managed repository. Public key can go there but private key should not. PK systems problem - people from outside want to use it for authentication.
DEC paper about how to manage keys stored centrally securely. Leaf project. Seemed like they had it right, no one implemented. 2-3 years old now at least. PKCS #11 (pokey) write your apps without knowing much about where publicor private keys live -- X500 or smartcard or whatever. Saw demos a couple of years ago.
MIT has oncampus certification authority. Run by network people.
UM thinking about campus cops running it. For liability reasons. CMU suggests that security could be as high as Kservers, so student or transient staff access would not be a problem.
Would public safety then do all security services, such as Kerberos servers as well??
Not enough for everyone to have public keys, you must have a credentialing authority.
UM demoed Kerberos and PGP thing last year (use Kcredentials to get public key >from Verisign) so we can send authenticated messages.
Verisign is signing keys, therefore it has a private key. Therefore it comes from the regents and probably goes straight to the legal office. ITD reluctant to set up a service that they don't have the power to run.
CMU - thinks that user presenting Kcredentials and gets signed key certificate -- the people who know the ownership of that key is the same as the people who control the Krealm.
UM - mythical person reports to regents, so the authority inheres to the regents. How to construct knowledge infrastructure so regents and designees know what is up is not trivial.
MIT - legal issues? Not using in a lot of ways that you might want to. No purchasing authority. Just a substitute for Kauth. Had existing systems to auth into student info systems. Cut over to X509 certs, to see grades, register for classes. Planned to use for lottery systems for athletic and humanities classes.
Other projects called Ksign2 (or Ecat2) . How to bring in new vendors, how to standardize with other vendors in the world. Not using the Schiller and Atkins scheme.
No verisign cuz of $25 fee, non-portability of keys, no handling of lost certs without fees.
MIT keeps certs with Netscape, in AFS dir, encrypted.
Since there are no CRL's MIT plans to revoke CA if there are any problems -- that's a big response!!
UM using for authenticated web services
Single Sign On
UM - have credentials in a number of realms, approach an interaction server. Want to enter uname/pwd once and have access to full range of services throughout campus. This means Novell and AFS services.
Many other auth realms at UM -- total of 11. MOAD (mother of all databases). Hack through it using OS structures (Unix-> PAM which is table driven and easily extensible)(NT -> GINA).
Multiple GINA issues - needed a Kerberos GINA to deny access based on a user identity. Can call netware login as a service provider
Notre Dame Gary Dobbins has done some GINA wrapper work for the MS GINA.
PAM (pluggable authentication modules)
Copyright - above
Sys Control (hierarchical permissions)
Delegated authority code. We had v1.0, went comm'l after 1.1. Heavily leveraged from K4, set ACL's on specific TCL procedures. Delegate responsibility to consultants. ADM scheme is similar for authority - granting.
But this is K4 and we're moving to K5. Does anyone have any ideas? Nope.
Want to do it in Perl, BTW.
Roland wrote a copy of SafePERL and there are some hooks in K5 that call it -- don't know what state it is in.
Xylan - vendor with a flexible vLAN capability
Accounting and billing
CMU - were charging some fixed % of payroll for funding computing resources. New system is a charge for every user and for every computer connected to the network. Bare minimum for machine connected to net is network access charge, which covers keeping the network happy. Add'l charges for the machine, mods if the machine is remote. Avoid per use fee for printing, dialups, etc. (exception is really expensive printing). Otherwise too much of a burden to track and charge for. Social pressures keeps grads and staff from wasting resources.
CMU undergrad - more billing than in the past, but still not much. Desktop system support for campus, plus levels of consulting. Planned for cost recovery, or at least recoup some of costs. $375 gets you a machine on your desk with OS/ some apps, etc.
Printing policy, billing -- basically just eating costs of printing. Talked about base support and then charging, but no billing infrastructure to students, so they are more interested in accounting.
Stanford - fully affiliated people get a free ride for computing services -- AFS, dial in, site licenses, less affiliated must be sponsored and there fore paid for by someone.
3 types of public access printing - Unix clusters. Libraries. Dorms.
Cluster limits total pages per quarter.
Dorms charge $0.05/page
Library wants to charge per page.
Deal being cut for a debit card that could support this billing
How do we do JE's (journal entries) -- transactions collected in realtime.
Every month (trailing 30 days) generates a set of charges as a single journal that is uploaded into the general ledger.
Next looking to extend model to groups of individuals -- are academic and research groups exempt??
UM- curently give an allocation to all faculty,staff,students eligible to receive. Basic service, subscription, time over 10-40 hours per month at 11/22/44 cents per hour. Printing for $0.08. bills go through central system where bills are created. Billing about $150k/month for dialin access alone!!
Pricing out external connectivity -- MIT getting a free ride. Do we pass cost along to users? Target people using most of the bandwidth? MIT has big servers. Caching doesn't help them, cuz that's outflow, not inflow.
UM is billing $10/month for usage over 1GB/month.
Cornell is doing some sort of Kerberos-printing. To an arbitrary printer, logged against your student account.
CMU has klpr monitor for windows -- thinking about handling admin issues like what printers are available. Pull down with 4000 printers is not a good idea.
UM SAMBA stuff - a number of printers across campus, mainly at larger sites, on their own subnet, serverd by Unix servers that talk Netatalk that also talk to to the accounting and billing stuff. Windows clients will talk to a SAMBA server which will talk to a printing server.
Stanford - don't need a kerberized account, but have a SAMBA server and printing through it.
Allen Bjorlund will submit his work to guy in Australia (Andrew Trickle?) for SAMBA stuff.
UM is running a SAMBA server (today) serving AFS files. Also used as a print server. Also storing preference stuff.
UM (engin) has been doing Kerberized printing via the MIT code slightly modified for about the last year.
Problems with SAMBA printing : students ran out of money (mechanics of managing the accounts). Lack of reporting tools. Technically, only ran into high UID problems (>60,000) for NT. Seemed reliable.