*MACE conference call, March 26, 2001*

*Attendees*

Bob Morgan (chair)
Renee Frost
Michael Gettes
Steven Carmody
Paul Hill
Neal McBurnett
Jim Jokl
David Wasley
Ellen Vaughan
Ben Chinowsky (scribe)

*Discussion*

The first part of the call was devoted to Bob's report from the recent IETF meeting.
- SACRED will be incorporating the HEPKI-TAG scenarios into its requirements document. It's not clear where SACRED is going; their core interest seems to be making it possible to type in a password to get your private keys and other secrets. Bob considers standardizing a way to do this "a good thing."
- Bob asked a couple of knowledgeable people if they thought that commercial cert providers would object to their certs being used to certify CAs as well as end users; the prevailing opinion is that while the cert vendors might have concerns, they are unlikely to go to court over this. Steve Farrell says that you can't turn off the signing bit if you want SSL to work, so vendors won't be using it to restrict usage. Bob now thinks that vendor restrictions are unlikely to be a serious obstacle to Shibboleth making use of server certs. [AI] David will see what California's agreement with VeriSign says about the permitted uses of server certs.
- Steve Tuecke discussed Globus's plans for cert usage, centering on "impersonation" or (less alarmingly) "proxy" certs. Globus resources are usually licensed to a community; with impersonation certs, when a user authenticates, the community authentication service provides a cert that says the user can assume the identity of the community -- hence "impersonation". The impersonation cert must be accompanied by an identity cert. Steven noted that he had also talked to Tuecke about Globus certs, and that a) they want to find a way to put something inside the impersonation cert to control what can be done with it, and b) the user has to have an account on the resource being used.
- Tim Polk and Jeff Schiller took part in an LDAPEXT discussion of the mapping algorithm to be used for dc naming; "the tide is turning" and the mapping will probably be loosened up. Per HEPKI-TAG's recommendation, LDAPEXT is now recommending that the dc's be placed in the most-significant position within the DN.
- A SASL (Simple Authentication and Security Layer) working group is forming. There have been discussions about applying SASL to HTTP, and it appears that Microsoft is planning an approach along that line.
- The dominant high-level concerns in the IETF right now appear to be "middleboxes" and internationalization. The MIDCOM working group (http://www.ietf.org/html.charters/midcom-charter.html) is trying to develop a protocol that can be used to talk to a variety of middleboxes, with a strong initial focus on firewalls and NATs. It looks like there may be a spec for internationalized DNS within a few months; Bob characterized this as "profoundly scary, because it affects everthing" -- including, for example, creating the prospect of non-Latin characters in dc names. A presentation-layer approach is being taken -- DNS names will have a single standard Unicode-based format, which end systems will translate into something the user can view.

Bob and Ken were calling in from the Microsoft campus, and reported on their visit. Microsoft sees Hailstorm as relevant to Shibboleth, and is interested in briefing MACE on Hailstorm. "Why don't you just use Kerberos?" is one question Bob and Ken have been asked; Microsoft claims that their version has stronger "inter-forest" authentication support. Microsoft is also pursuing SIP as a standard for instant messaging and presence (see http://www.ietf.org/html.charters/simple-charter.html), and is interested in participating in the MACE video work.

Paul noted that lots of people are now "jumping on the SIP bandwagon" and "using it for generalized rendezvous stuff"; within the SIP working group (http://www.ietf.org/html.charters/sip-charter.html), the result has been "lots of dissent on pretty much every topic." Paul also called the group's attention to BURP, the Basic User Registration Protocol; here the idea is to have each user authenticate to a Registration Authority in their local domain.

There was a short discussion of the increasing availability of free wireless Internet access. Sometimes this is deliberate (e.g. http://www.toaster.net/wireless/), and sometimes it's the result of corporate networks not being secured properly. In some cases it's possible to find these networks just by going out and walking around, and there exist tools that make it possible to discover network names.

Finally there was a Shibboleth update. There were some new people on the last Shibboleth call; the discussion centered on the issues of how much user interaction is appropriate at attribute-release time, and whether or not target sites should make specific attribute requests. Bob described the discussion as "contentious" and noted that he was in the minority on some issues. The following day there was a fruitful conversation with IBM's Mark Simpson, Rich Wall, and Mike Nelson. Mark is OK with Shibboleth's decision not to wait for SAML; he also expressed a preference for putting experienced security programmers on the project, rather than the newly-minted computer science graduates earlier suggested. Mark also volunteered to size the programming effort; while it is not yet clear how detailed a specification he will need to do this, Steven would like to start pulling the various Shibboleth documents together into a main architecture document. Michael noted that IBM has also pledged support for the Jesuit Distance Education Network (JNet, http://www.jesuitnet.com) which appears to have strong similarities to Shibboleth. [AI] Michael will find out more about JNet, in particular how it overlaps with Shibboleth. The Shibboleth initial sign-on (ISO) subgroup is planning to identify an existing freely-available Web ISO mechanism and modify it so that in addition to the token it produces now, it produces an XML token aligned more closely with the OASIS work; they are hoping to be able to demo this in mid-May. The ISO subgroup is also working with uPortal on the format of the uPortal token.

*Action Items*

[AI] David will see what California's agreement with VeriSign says about the permitted uses of server certs.
[AI] Michael will find out more about JNet, in particular how it overlaps with Shibboleth.