*MACE-WebISO Conference Call*
October 30, 2001

*Participants*

Nathan Dors -- Washington(chair)
Jim Farmer -- JA-SIG
Scott Fullerton -- Wisconsin
Dan Jones -- Colorado
Bob Morgan -- Washington
Ryan Muldoon -- Wisconsin
Russ Tokuyama -- Hawaii
Steve Willey -- Washington
Nate Klingenstein -- Internet2(scribe)

*Discussion*

        There is now a somewhat public sub-site on the Pubcookie website
for the external release of Pubcookie, with freely downloadable versions of
the ISAPI filter and the CGI script.  This could almost be considered the
1.0 release, and the group now looks forward to making Pubcookie a true
WebISO system.

Threat Models

        The current threat model that Pubcookie is, in Steve's words, built
on a "belt and suspenders" approach by trying to use the same protection
and encryption for all cookies and communications.  Basically, every
transmission or cached item is signed and then encrypted.  The Pubcookie
team wanted to do away with this cover-all approach and evaluate each
cookie and message individually based on the parties and communications
involved to determine the amount of security safeguards that need to be in
place.  Servers using Pubcookie also share a key, which is a significant
hassle, and the group would like to be able to limit this to an automated
function with optional limitations on registration for administrative
purposes.
        Perhaps the most interesting question that the group needed to
consider in evaluating the threat model is whether SSL would be presumed
available or required for interactions with the target webserver.  The
policy of Pubcookie use at the University of Washington is that it's always
used within an SSL context, but this could obviously differ in any
deployment.  This could be a problem for some universities because the use
of SSL greatly increases the load on the target server.  However, if all
paths are presumed protected like this, then slightly less work needs to go
into the formatting of the cookie and the authentication in general.  To
slightly lessen the performance degradation, the session could switch back
and forth between SSL protection and a plain HTTP link; to do this with
reasonable protection against session hijacking, however, the IP address of
the client would have to be recorded by the server.  This is limited in
effectiveness by schemes such as proxies which change IP address with every
request, for example, so there would need to be some understood tradeoff
between dealing with these random proxies or denying some users access.
        There was additional discussion about the regulation of the
websites which would be able to use Pubcookie authentication.  If there
were an alert and access needed to be immediately discontinued to a
Pubcookie-based server, it's not clear that this would be possible in the
current design.  To this end, the group suggested the implementation of a
parallel test infrastructure with limited lifetime keys.  Another
interesting option suggested was that if all communications are going to be
based on SSL, then there are already certificates on all host machines.
These could hypothetically be re-used for the Pubcookie trust
infrastructure, but dubious is whether it is kosher or not to re-use SSL
server certs for other purposes.
        [AI] The Pubcookie team agreed to try to get out a draft of their
security discussion in time for the next conference call.  This will
attempt to enumerate the different attacks that the group is trying to
consider and craft a common language to discuss them.  The one mentioned on
this call was "going fishing", where a webserver sits around looking for
cookies scoped to a particular domain to retrieve them.  Many more attacks
will be discussed.

*Action Items*

1.  The Pubcookie team agreed to work to get out a draft of their security
discussion in time for the next conference call.