Subject: RE: finding services : DCS, OCSP, Timestamping, ..

From: Alan Lloyd <[email-masked]>
Date: Mon, 25 Jan 1999 15:46:17 +1100

> -----Original Message-----
> From:	Stephen Kent 
> Sent:	Monday, January 18, 1999 9:11 AM
> To:	Alan Lloyd
> Cc:	[email-masked]
> Subject:	RE: finding services : DCS, OCSP, Timestamping, ..
> 
> Alan,
> 
> Well, we may be getting closer, but I'm not completely sure.
> 
> >> I think we have to pay close attention to the specific services in
> >> deciding
> >> what constitutes a good way to find appropriate servers.  For
> >> revocation, I
> >> think the CA has an obligation to state how/where is makes
> revocation
> >> data
> >> available, because the CA is the ultimate authority for this data.
> >> Thus,
> >> for example, we can bind into each cert one or more CRL
> distribution
> >> pointers. If a CA chooses to delegate that authority to some 3rd
> >> party, it
> >> needs to do so in a highly secure fashion.
> >	[Alan Lloyd]
> >	The X.500 CA related data structures do provide some of this.
> >The  CA entry can have  its CRL DP  reference pointing to a directory
> >entry of a third party that has the CRL DP with signed CRLs in. My
> usual
> >point here is that it is easier to add a new data structures to a
> >directory service to solve the prolem than hand config info objects
> with
> >server knowledge all over the place.
> >	I think the issue is that its back to the approach of hand
> >crafted knowledge of where things are and configuring them into
> >everything or using the naming/knowledge/authentication/ACI regimes
> of
> >directory services and appyling these in the CA issuer/subject and
> CRL
> >DP objects.
> >
> >	The directory service provides exactly that - named items in  a
> >distributed environment. So why try to emulate that service in data
> >structures with manual effort.
> 
> I'm confused by this example. If I attack the directory and change the
> CRL
> pointer to a different entry, this would be a serious security
> problem,
> unless the CRL in the other entry is signed by the CA.  If so, then
> what
> difference does it make in which entry it is stored?  Is your
> suggestion
> that the layer of indirection provided by the directory is important,
> even
> if the CRL is signed by the same entity in any case?
	One can cite if one attacks a directory entry but I would expect
that a CA entry with its cert and CRL DP, etc is well protected from
casual writes - protected via authentication mechanisms and access
controls for CA modification only. The same issue would be with an
unprotected DB .

	At least the directory provides a distributed, profileable -
authentication and ACI regime which will be designed and deployed
according to a cost/trust and service model.

> >
> >> One could include a set of OCSP
> >> server pointers, which would permit a more robust mechanism, though
> at
> >> the
> >> cost of cert size growth.
> >>
> >> For a directory system to provide a highly secure way to discover
> such
> >> delegation, I think we must have some way for a CA to post a
> signed,
> >> dated,
> >> attestation that provides the equivalent info.  We currently have
> no
> >> structure for such data.  Also, there is a potential performance
> >> tradeoff
> >> here as well, i.e., use of a directory server seems to add another
> >> level of
> >> indirection to the process, thus requiring more network accesses,
> ...
> >	[Alan Lloyd]  Dont think of the directory as a server, but as a
> >distributed service. If things are all over the place then by
> definition
> >the network traffic through a directory service will be the similar
> or
> >less than the client making the same requests to independent items.
> Its
> >just that with the directory service, the directory service has the
> >distribution mechanisms and knowledge all built in. And in this case
> all
> >the client does is access the single interface of the directory
> service
> >with requests for named items. Whereas with the client identifying
> with
> >bits of config info from many data structures (eg. like the WEB mode
> of
> >working), just means that all such structures are hand configured and
> >the client has many connections to retrieve all these fragments. And
> in
> >addition, each time the client connects to these fragmented servers,
> it
> >has to authenticate itself. Yet more hand crafted configuration,
> >replicated passwords and/or and key management.
> >	Ie. The latter model is more complex, key management starts to
> >get N*N, its harder to manage and has more network traffic and
> >interaction from the clients perspective.
> 
> We certainly disagree here.  Nothing in the example I described
> changes the
> key management to an order N**2 problem, from an order N problem. We
> certainly are NOT introducing passwords into these systems; we are
> trying
> to replace them with certificates.  I still don't see how the number
> of
> transactions does not grow as a result of putting more data into the
> directory.  Your comment is rather vague on this point; perhaps the
> intent
> is to say that "if we distribute all of the admin data need to
> communicate,
> then  what's a few more items?"  I understand that analysis, and might
> agree with it in general.  But, if we pursue that path, we will
> definately
> create a more fragile system, by requiring a greater number of
> directory
> accesses and requiring that the directory services be highly
> available.  I
> think your point is that this is a good tradeoff if it results in an
> easier
> to manage system, overall.  Here too I think we need to look at
> specific
> cases; sometimes the tradeoff may be appropriate, but in other cases
> we may
> be creating unacceptably fragile systems.  Maybe my work on the Trust
> in
> Cyberspace report for the NRC over the last 2 years has heightened my
> concerns over fragile infrastructures :-).
> 
	However, with a robust - distributed directory service - that is
designed to be robust - some of those concerns should dissipate. After
all the phone system is a very big infrastructure that in general
supports a service and one tends to think that any failure in any
component does not bring the whole system down. Infrastructure design
always makes sure that their is no single point of failure for the whole
service and that any failure only criples a componenet of area of the
service.
	All I am saying that directory system designs should parallel
the phone system re replicated/distributed paths and redundancy
features. Thus a "trust" can be placed on them - like any infrastructure
- water, gas, roads, etc. Otherwise what is the alternative to the
design of large scale systems?

> >
> >	As a bit of an after thought and thinking about OCSP-directory
> >integration. In a multi domain environment where domain a users send
> a
> >signed transaction to users in domain b. And domain A uses
> convetional
> >CA/CRL processes for its own validation , but domain B choses to use
> >OSCP validation processes, the certificate server configuration
> approach
> >will have problems. The point is that a user or a CA in one domain
> may
> >not know or care (at that level) the validation techniques of another
> >domain as this will be a system design and policy issue.
> >	It would be very hard for a CA issuer in any domain to foresee
> >where the cert would be propageted to and what servers (and the
> server
> >configs and mechanisms) it would be validated on. Naturally very
> small
> >systems dont have this issue.
> 
> Validation for certificates is a standard process, codified in X.509
> and
> PKIX. It is not a purely local policy matter.  Local policy comes into
> play
> with regard to how to make use of the data extracted from the
> certificate.
> Also, some aspects of the validation process are under the control of
> the
> CA issuing the certificate being validated, e.g., marking extensions
> with a
> critical bit or choosing to use CRLs vs. OCSP.
> 
	Thats the CA theory view that may not serve an operational
world. The transaction with a cert has a business/policy component also
and that must be tied to the cost/trust/business models that apply
certificates. ie. the theoretical CA model need not rule in all cases.
> >	I still quite like that the approach that a receiving client of
> >a cert, presents it to its "local" validation process (via OCSP) and
> >that server, can off load that to other OCSP validation servers if it
> is
> >necessary -  and these OCSP servers use the distributed information
> >services of the directory to find CRLs or validation items or
> references
> >to where CRLs might live. ie the business policy for within domains
> and
> >between domains is engineered as directory information objects
> (signed
> >or otherwise) according to trust requirements.
> 
> Here is where we disagree again, though I appreciate the attraction
> this
> holds. As I noted some time ago, if one offloads all of the validation
> process, in order to construct a very thin client, then the
> opportunities
> for subverting validation for a potentially large number of
> subscribers is
> greatly increased. The local validation server becomes a prime tagret
> for a
> wide range fo attacks, and its required high availability makes denial
> of
> service an even greater concern.  
> 
	As said, when one designs a distributed directory service
infrastructure with directory enabled processes attached to the service
for such things like org chart generation, subject matter context
clumping  and possibly cert validation and... specialised seach/data
engines for fingerprint validation, etc , then these processes by nature
are context sensitive (or insesnitive) - mult path, distributed
processes . ie with directory enabled distributed processing, the whole
system, service and processing paradigms change - including the
configuration and single point of failure models.

	The telephone network is very similar to the PKI validation
model that is needed for global services. Multi domains, multi services,
global roaming and distributed-fast authentication. As directories make
the phone system work, so will directories make big PKIs work.

	regards alan

	 With cacheing and normal, client
> validation capabilities, an inability to access a directory for a CRL
> may
> be an annoyance, but may not be fatal in many instances.  However, if
> one
> pushes off all of the processing, ...
> 
> Steve

---

From: Stephen Kent <[email-masked]>
Date: Sat, 30 Jan 1999 15:15:58 -0500

Alan,

< much text deleted>

>controls for CA modification only. The same issue would be with an

Certs and CRLs are signed and thus we rely less on the directiry system to
protect them, since tampering is evident to the user.  As soon as we talk
about relying on unsigned data items in a directory, the security situation
is quite different.

>according to a cost/trust and service model.

Yes, but that regime should not be relied upon for cert processing, exccept
to mitigate denial of service concerns, i.e., one shoud rely on a directory
in a cert processing context only to the extent that one needs some
repository for signed objects.  To extend that reliance to unsigned
objects, in a fashion that could undermine the security of cert processing,
would be negligent.

<lots more text delted>

>design of large scale systems?

Well, I now work for a phone company, and I do not believe the analogy is a
good one.  Directories in the phone system have very simple access models
and (legitimate) subscribers have very restricted access capabilities.
When phone phreaks have gone after the phone system, they are often
successful. The fundamental issue here is that one should rely on any
infrastructure ONLY to the extent that is intrinsic in that infrastructure.
When we rely on infrastructures in ways beyond their design intent, we get
into trouble.  the OCSP server ID example does that, in my opinion.

<still more text deleted>

>certificates. ie. the theoretical CA model need not rule in all cases.

Of course PKI designs are driven by many factors, but that doesn't mean we
have to be sloppy about security, and you have not provided any models that
quantitatively compare the tow models we are debating.  This is the PKIX
mailing list in the IETF; we worry about real CA concerns, not just
theoretical ones. Your directory-centric perspective on these issues
strikes me as much more theoretical :-).

<yet more text deleted>

>the phone system work, so will directories make big PKIs work.

As I noted above, I work for a large phone company and I dispute the
validity of the analogy.  What it seems to boil down to is an assertion by
you that directories will be ubiquitous, very fast, ultra reliable, and
sufficiently secure so that we should abandon the crypto-integrity model
upon which X.509 is based.  Clearly this is not the case today, so let's
just see if the directory model you envision comes to pass.  if so, I'll
withdraw my objections.  However, in the mean time, I suggest that we not
degrade the security of PKIs based on these projections.

Steve