Minutes of 3/15 core & protocols concall

[Hal Lockhart <hal.lockhart@entegrity.com>]

Thanks to Jeff Hodges. I combined his notes with mine.

This was the first meeting of the combined core assertions and protocols
groups. Unfortunately neither chairman was able to attend. The start of the
meeting was delayed 20 min or so by problems with the conference service.
Some people who wanted to attend may have given up.

present: carlisle, hal, jeffh, charles, rlbob, irving, nigel

Hal acted as conference leader.

Agenda
1. Debate single data structure concept
2. Debate 3 vs. 4 corner model
3. Debate issues in email exchange between Tim and Hal

The discussion got into the area of terminology. The decisions on
terminology from the previous day's usecase concall were reviewed.

Item #1

Having a common format for assertions was considered goodness. It was
observed that there currently were 4 possible types of assertions - Authn,
Attribute, Session and the type emitted by a PDP, which currently does not
have an agreed name.

A question was raised if a PDP is queried as to whether to allow access and
returns yes/no, is that an assertion or just a protocol message. There was
some consensus that it would be good to treat this as an assertion as well.

The generalization that assertions can stand alone, be stored and reused and
that their semantics are independant of how they are delivered seemed to be
generally agreed.

Item #2

The following was generaly agreed.

Model includes six entities:
System Entity (user or software process)
*Authentication Authority
*Attribute Authority
*Session Authority
*Policy Decision Point
Policy Enforcement Point

Four (marked with *) can emit assertions. 

hal: tim's model shows two domains, but today we're seeing that there might
be
up to five, tho in reality, will likely be two or three. in principle any
grouping is possible. 

the model defines all the entities & their assertions & interactions, but we
don't worry about counting the number of corners. 

Jeff: asked about the two "views" of the hal/orchard model that folks were
mentioning. 

hal & rlbob: one is ostensibly contained in only a mail msg sent by Eve (?)
entitled "Hal/David model", the other is embodied in the
draft-sstc-use-domain-01 doc. The two are intented to be consistent,
represent different aspects of model.

me: shouldn't the former be wrapped into a doc?

Hal: will do so, will likely roll it into draft-sstc-use-domain-02

Item #3

"authenticator" -- what's this?

Hal: tim's notion of an "authenticator" is a notion for doing X in just one
or
more specific environments, rather than being a general thing. 

Hal: assertion needs to be bound to both the issuer & subject of the
assertion

*** <some discussion of being able to "prove" whether one is a legitimate
issuer
of an assertion. > 

carlisle: assertion needs to be bound somehow to the subject, might be done
several ways. 

hal: 
  purchase order is signed
  verify signature, get the ident cert of the signer.

carlisle: then you end up with the public key of the signer, and the pk IS
the
authenticator.

carlisle: the "authenticator" is the thing you use to determine who's, say,
signed this thing. thus when using PK stuff, the "authenticator" is the PK
buried in the cert associated with the signature. 


rlbob brought up that insome scenarios use of a "bearer" object is
acceptable
(e.g. an authn cookie a la netpoint et al), and in other scenarios one wants
to
actively determine whether the principal one is interacting with is bound to
stuff in the assertion/object/msg in question.


hal: drawing distinct btwn long-term authn cred like a passwd and one like a
SSO
cookie -- differences in the way one uses these things

also distinction in that in one case presentation of the info
(authenticator) is
done explicitly (passwd in realtime) and implicitly wrt a cookie the browser
caches and passes back & forth. 



next subitem: 

further discussion of Tim Moses' msg (RE: The Hal/David model; 
          Tue, 13 Mar 2001 11:45:29 -0500;
security-services@lists.oasis-open.org)


carlisle: "sensitivity" attr is something that travels btwn pdp & pep

Jeff: I claim "sensitivity" as carlisle is talking about is essentially MLS
(multi-layer security systems) and we can look at the relevant literature
and
decide whether it is a notion we want/need to incorporate. 

hal & carlisle & nigel: sensitivity is an "attr of resources". 

carlisle: we should handle it in the same vein as "authenticator" -- it is
something we allow for in the SAML arch, some embodiments may or may not
make
use of it.

Sensitivity as a resource attribute, which may or may not be used seemed to
be generally acceptable. It was suggested that perhaps a term with less
baggage should be used.


*** AI: I signed up to research the "sensitivity et al" term & concepts


Hal: mentioned a book with distrib formalisms that he will send a ref to the
list about

RLBob: mentioned that X.509 4th edition has a section on PMI that has a
bunch of
stuff about attribute certs that is relevant to our attr authority.