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

From: Alan Lloyd <[email-masked]>
Date: Mon, 1 Feb 1999 14:14:12 +1100

As said many times - if you want DNS to have the same capability as
X.500 distributed directories - fair bet it will have to embrace all
that functionality. That should take about 5-10 years. Or the otherway
is do what is being done today, build RADIUS, DHCP and DNS server front
ends on X.500. 
Most have now recognised that distribution and distributed
authentication is key in large scale directory services and that single
LDAP servers on their own  are nothing more than repeating the limited
single central DB type architectures which were applied some 25 years
ago.

However, these can be integerated as a subordinate directory server if
one gets the right directory backbone technologies :-)))

regards alan
> -----Original Message-----
> From:	Andrew Probert 
> Sent:	Monday, February 01, 1999 11:23 AM
> To:	'Alan Lloyd'; 'Stephen Kent'
> Cc:	[email-masked]
> Subject:	RE: finding services : DCS, OCSP, Timestamping, ..
> 
> I have watched this dialogue with interest.
> 
> I must admit to being a fan of directories of any sort and can't but
> help
> comment on some real-world recent things I have seen, in favour of the
> approach..
> 
> The internet is build upon DNS (Domain Name Servers), DHCP
> (Distributed Host
> Control Protocol) et al.  Serious vendors such as CISCO have bought
> companies like American Internet Corporation to get a hold of
> infrastructure
> technologies to help them scale and lo and behold we see things like
> Radius
> Servers being bolted up to directories to give them the sorts of
> backends
> that can scale and perform.  
> 
> How many ISPs can you name that have woeful performance on initial
> connections, whilst I assume they grovel around in poorly designed
> backend
> database to find billing and profile information?  A directory should
> be
> considered to publish customer details internally to a service
> provider as
> well as a restricted profile of information to the outside world!
> 
> Sure systems can get pretty large upon lightweight technologies such
> as DNS
> etc, but they are definately creaking at the seams, especially when
> some
> maniacs are suggesting the next step of extending DNS servers with
> Certificate storage capabilities.
> 
> Andew Probert
> Rotek Consulting   http://www.rotek.com.au
> a Division of Secure Network Solutions
> Tel  +61 3 9690 8877
> Fax +61 3 9690 8171
> 
> 
> 
> > -----Original Message-----
> > From:	Alan Lloyd [SMTP:[email-masked]]
> > Sent:	Monday, February 01, 1999 9:12 AM
> > To:	'Stephen Kent'
> > Cc:	[email-masked]
> > Subject:	RE: finding services : DCS, OCSP, Timestamping, ..
> > 
> > 
> > 
> > > -----Original Message-----
> > > From:	Stephen Kent 
> > > Sent:	Sunday, January 31, 1999 7:16 AM
> > > To:	Alan Lloyd
> > > Cc:	'Stephen Kent'; [email-masked]
> > > Subject:	RE: finding services : DCS, OCSP, Timestamping, ..
> > > 
> > > Alan,
> > > 
> > > < much text deleted>
> > > 
> > > >	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 .
> > > 
> > > 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.
> > > 
> > 	After N years with military X.500 and PKIs I think I do
> > understand this. But in addition to signing data, we can also place
> > "some" trust on the distributed authentication and access controls
> of
> > the directory system. Particularly when the user or certficate
> reader
> > has been requested to do strong authentication on the directory
> service
> > itself to read the CA entry. We do deal with trusted directory
> systems
> > you know.
> > > >
> > > >	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.
> > > 
> > > 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.
> > > 
> > 	And in the case where this extra strengh is needed we can do
> > strong auth and signed ops on the directory service.. with DAP - you
> > know the protocol thats half the size of LDAP with twicw as many
> feature
> > including trusted signed operations :-))).
> > 
> > 
> > > <lots more text delted>
> > > 
> > > >	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?
> > > 
> > > 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.
> > > 
> > 	We need to talk re the two paradigms. Many people find the phone
> > system/directory system paradigm very useful.
> > 	As for infrastructures. They tend to be in fact very big systems
> > - by definition. If OCSP wants to be big - it will become an
> > infrastructure - but if it wants to be big it will have to be
> supported
> > by a big distributed information base... some thing like a directory
> > service. Otherwise its hand carved...
> > 
> > 
> > 
> > > <still more text deleted>
> > > 
> > > >>
> > > >	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.
> > > 
> > > 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 :-).
> > > 
> > 	Theory ! Oh really. How many OCSP servers will be needed for 100
> > m users. What is the information system that supports this?
> > > <yet more text deleted>
> > > 
> > > >	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.
> > > 
> > > 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.  
> > > 
> > 	Thats it. Got it in one. 
> > 
> > > 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.  
> > > 
> > 	Its coming to pass. Simply bnecause all those "servers" being
> > promoted need ... wait for it...
> > 	Information and for that information to be applied in a
> > distributed and common way.
> > 
> > > However, in the mean time, I suggest that we not
> > > degrade the security of PKIs based on these projections.
> > > 
> > 	No infact we are enhancing the PKI with the reality of deployed
> > directory systems.
> > 	A PKI without a business purpose and information and service
> > deployment scaleability will be an orphan technology.
> > 	regards alan
> > 
> > > Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 2 Feb 1999 10:53:08 -0500

Alan,

Let metry to condense our debate to spare the rest of the list from reading
lost of text:

1. You state that "in addition to signing data, we can also place
>"some" trust on the distributed authentication and access controls of
>the directory system. Particularly when the user or certficate reader
>has been requested to do strong authentication on the directory service
>itself to read the CA entry. We do deal with trusted directory systems
>you know."

You also say "And in the case where this extra strengh is needed we can do
>know the protocol thats half the size of LDAP with twicw as many feature
>including trusted signed operations."

This line of argument seem to ignore the fact that the vast majority of
successful, detected attacks against computers of any sort are effected
through exploitation of design, implementation, or management
vulnerabilities that are NOT prevented through the use of cryptography for
communication security, including signed directory operations.  This
characteristic has been true for the last 20+ years and is well documented
through analysis of CERT advisories.  A vast set of directory resources
provides an obvious target and if one were to adopt the approaches you
promote, which place ever greater reliance on these resources, the value of
these targets grows enormously.  That is why signing data that is stored in
any repository, and not relying on secure management of a set of
repositories, is a preferred security paradigm.

2. Later, in response to my observation that the phone system is not a
great analogy for the global, distributed directory system you envision you
say "We need to talk re the two paradigms. Many people find the phone
system/directory system paradigm very useful. As for infrastructures. They
tend to be in fact very big systems>- by definition. If OCSP wants to be
big - it will become an>infrastructure - but if it wants to be big it will
have to be supported by a big distributed information base... some thing
like a directory
service. Otherwise its hand carved..."  This response seems to ignore all
of the details of my argument of why the phone system is a poor analogy,
and the vast evidence of the fragility of this and analogous
infrastructures.  I refer you to the recent "Trust in Cyberspace" report by
the (U.S.) National Academy of Sciences, which makes similar point.  Of
course, as a member of the committee that wrote the report, I may be
prejudiced :-). Also, your comment about the growth of OCSP seems to focus
on ONE way of using it, namely having a network of TTPs act as oracles for
queries about certificate status or validity.  This is not the only model
for OCSP, and it is not the one that prompted the development of OCSP.  If
CAs operate OCSP responders for the certs that they issue, there is no need
to create the sort of highly vulnerable infrastructure you seem to propose.
OCSP servers operated by CAs, vs. outsourcing OCSP services for a CA to a
TTP, don't concentrate vulnerabilities, they distribute them.  So,
depending on the model one envisions, OCSP may be fine froma  security
standpoint, or it can be made into another disaster waiting to happen.

3. In our discussion about the nature of OCSP support, you state "How many
OCSP servers will be needed for 100m users. What is the information system
that supports this?"  Again, this seems to confuse your model for OCSP use
vs. other approaches, as noted above.  We both agree that distributed
directories are a good and necessary part of most PKIs; the issue is
whether we should use them in a fashion that creates new vulnerabilities.

4. I stated that "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." You responded "Thats it. Got it in one.'
well, it is nice to be clear on this point. However, you have not provided
a set of coherent, comprehensive arguments to presuade me to believe that
your assertion. Insetad, the argument seems to be that of course it will
happen becauise it must happen to enable the future and because the use of
such serves is being actively "promoted."  This does not sound like an
architecture to me; it sounds like a marketing pitch from a seller of
directory technology and/or services.  This is the PKIX WG mailing list.
We try to develop standards for PKI technology that based on sound
architectural principles, period.

5. Finally, in response to my complaint that your proposals would degrade
the security of PKIs, you respond "No infact we are enhancing the PKI with
the reality of deployed directory systems. A PKI without a business purpose
and information and service deployment scaleability will be an orphan
technology."  This does not respond to my point.  It deflects the question
by asserting, again without substantiation, that yours is the ONLY/BEST
approach to achieving scaleability, and it makes the highly questionable
claim re the reality of deployed directory systems.  We don't conduct
debates on this list based on assertions about the inevitability of a
partciular solution; we debate proposals based on their merits.

Steve

---

From: Alan Lloyd <[email-masked]>
Date: Fri, 5 Feb 1999 14:22:19 +1100

> Sent:	Friday, February 05, 1999 10:14 AM
> To:	Alan Lloyd
> Cc:	[email-masked]
>  <deleted text from my point #1>
> 
> >	I got confused with your logic in this  debate  - are you
> >agreeing with me.
> 
> Not at all, and I don't think the argument was unclear.
> 
> >	If you want to talk threat to large scale systems I will. And
> >yes all threats to systems are generally operational ones (cutting
> >cables, power, sand in the fuel line etc.)
> 
> First, a threat is defined as a motivated, capable adversary" so the
> use of
> the term "threat" here is inappprpriate.  
	Groan...

> Second, we have simple
> counterexamples to your assertion, e.g., the massive, distributed
> switch
> failure suffered by AT&T due to a propogated software error.  Benign
> failures for such systems may often be of the "backhoe induced fading"
> variety, but malicious attacks need not follow the same profile.
	No doubt there are millions of examples ...

> >	In military we have a term - a big system is a big target. Eg.
> >the Internet, the Telephone network... However, that does not stop
> them
> >being built. So we tend to follow through threat analysis with risk
> >assessment, risk avoidance and risk acceptance. After all, even
> living
> >is a risk :-).
> 
> Yes, but some of us are better at risk avoidance than others :-).
> However,
> smart designers try to avoid creating unnecessary risks in systems
> through
> over concentration.
	As per the subject line - smart designers of eg transport
systems actually buy the cars, the ships and planes - they invet the
transport system , they dont keep inventing core technologies when they
are already there. eg If one wants to find some thing and a directory
service can provide that - one should not handconfigure every
certificate on the planet with server config info....

> >	To debate signed data as being the preferred paradigm and saying
> >putting that in a secure or insecure large scale repository ( a
> >directory service)creates an operational risk - (which is obvious) so
> >dont build one... seems a pointless statement. For the
> cryptographically
> >protected information to have any UTILITY AT ALL in a large scale
> >system,   it has to be provided by something in a way that can be
> found
> >by those distributed users who wish to use it.
> 
> Now it's my turn to question the logic of your statements. Please
> stick to
> responding to specific points, not issuing general, fluffly
> pronouncements.
	But I like fluffy things :-)

> >	Also note  and please do note that a directory is a distributed
> >information function - that provides greater utility than
> conventional
> >databases. One of these can be used in a Top secret env, many can be
> >used privately on a restricted network or thousands can be used on
> low
> >value, high volume transaction , global service systems. The
> >trust/cost/risk/integrity and threat issues of these  are all
> >operational/project/deployment issues.. and have very little to do
> with
> >with the details of a signed cert or cRL (although they do factor in
> the
> >debate).
> >	ie do I use Type 1 algorithms to sign certs but leave the power
> >switch for the CA visible on the road side.
> 
> Oh please, no more "directories as panacea" rhetoric.
	Well it seem I seem to make these announcements because the
debate is still that we need to find things  - so therefore we must
configure everything with knowledge and use all sorts of protocols -
However,  all this effort can be saved by using a directory service as
per its design of 10 years ago.

> <deleted text of my point #2>
> 
> >	See conmments above. Again the logic confuses me. I will always
> >agree that one can build a small system without an infrastructure.
> :-)
> >In fact a small system is not an infrastructure :-))) ... One can put
> a
> >dozen OCSP servers around a CA - not a problem.
> >	However if one want to run a business level system with
> >tranactions and users that are verified for business products/ access
> >with profiles  for global use- what is the information model,
> who/what
> >administers it, how is it distributed and deployed, what is the
> >busines's product, customer and inter-oganisation acquisition
> strategy
> >and what are the information policies and procedures that deal with
> >that....These are the system issues..
> >
> >	Where does this "information" stuff live - in a commercially
> >optimised way....
> >
> >	Big systems are infrastructure, by definition. And threats are
> >always on them. This does not mean that because of theoretical
> ideology
> >we will always build small ones. PKI systems and directories means
> that
> >infrastructure, large scale PKI systems can be built ( may be not for
> >everything) but there is a big market for them - because they are big
> >systems - and as everyone knows, the engineering processes in small
> >systems eg LDAP is a lot different to big ones (distributed directory
> >services)
> 
> No, big systems are not necessarily infrastructures. "Infrastructures"
> are
> systems that serve other systems in an underlying, supportive fashion.
	Groan

> A big system built for a given application, which is an end unto
> itself, is
> not an infrastructure.  
	Telephone systems ?? The Intenet

> But we are taking about PKIs, so I don't mean to
> dwell on the erroneous defintion above.  However,  I again find that
> your
> responses seem orthogonal to my comments, i.e., they do not refute my
> criticisms, but rather make more high level statements in support of
> your
> position.  This is a waste of my time, and that of the mailing list
> members.
	I dont think its a waste of time. I think this list has to get
the thing its responsible for ie. the design of PKIs -and that design
into a commercial and operationally accepted state.
	My views are quite simple - protocols and servers do not a
system make. Globalising information systems are a requirement in todays
world. Infrastructure services of the telephone system. the intenet and
PKI function will underpin this. I have put up drafts re validation via
directories - no comment.
	I hear CRLs and where things are, knowlege, distribution and
business policies re information systems are the issues. AND the only
way do deal with this is more syntax - which means the PKI configuration
army - high costs to users. NOT ACCEPTABLE 
	This is the same debate I had with the LDAP list re the LDAP
configuration army and replicating everything to everywhere.. Now that
everyone realises that LDAP servers on their own dont do much and are
expensive to run  - distribution as per X.500 seems to be accepted and
announced as a basic feature ...by the worlds biggest IT companies .

	If the scope of the work on this list is to keep adding syntax
to data objects that requires masses of human configuration then go for
it. Operational costs need to be considered.

	If the scope of the work is get to grips with large scale
information systems that use PKI - why not progress it.

> >> OCSP servers operated by CAs, vs. outsourcing OCSP services for a
> CA
> >> to a
> >	Operational and system design issues... Can debate this for
> >ever, if all we have to argue with is a protocol spec and a signed
> data
> >item.
> 
> if we were debating this would be true, but you're ducking my points,
> so
> it's hardly a debate :-).
> 
	I missed the point because there was not one. The text above
says ther are a number of scenarios in applying OCSP severs - agree
	and depnding how this done - and the weather, and sadam hussein,
the el nino effect or monica - that may be a disaster or not.

> <deleted text of my point #4>
> 
> >	Agree - standards are good - I have been involved with standards
> >for ISO/ITU for 20 years, the military for 8, transport and traffic
> >management for 4 and the IETF for about 8. However please note that
> a
> >set of ASN.1 data definitions is not a system architecture.
> 
> We agree on what is and is not an architecture, but that's about it.
> We
> can compare records re standards participation, if you wish.  I didn't
> do
> much in the ISO/ITU arena, but I've been an active IETF paritcipant
> since
> its inception, served on the IAB for a decade, chaired two WGs in the
> 90s,
> and authored a handfull of standards tracks RFCs over the last decade.
> 
	Salutations :-)

> >	A standard eg. X.500 is 20% of a product which is 20% of the
> >effort in a deployable system.
> >
> >	Let me get these points over.
> >	1. X.509 is part of X.500 - why. X.500 - the directory service
> >supports the distributed authentication process and domain level
> access
> >controls which are needed in a distributed business environment.
> 
> Yes, X.509 was created to support string authentication for X.500, but
> X.509 lives outside of X.500.  Many v3 extensions were added to
> compensate
> for the fact that certs and CRLs will not always be retrieved from
> directories and because reliance on directory access controls, vs.
> signed
> data structures, is a dangerous design approach.  For example, we now
> mark
> CRLs to indicate which ones are for CAs vs. users, rather that relying
> on
> the indications provided by the directory attributes in which they
> were
> stored.
> 
	And I totally disagree with this - my other emails say why. As a
shared secret - its all to do with the NAMES in a certificate AND the
fact that a cert is an attribute of an AUX OC of a structural OC whose
rules applied to an entry in a directory service that gives the game
away....

	I know there are some views are that directories dont exist but
X.509 is OK as a certificate format. eg Why did LDAP take directories
and  focus it down to "a protocol"?

	But reality is setting in isnt it....
	Many suppliers are applying  directory systems to PKIs and OCSP
servers and there are those around this planet who are directory
enabling big applications - and PABXs etc - for the same reasons - ie
information services approach, scaleability and an integrated user
authentication and access control paradigm.

	snip
> Sorry, but this sounds like more fluff to me.
	Fluffy things are good :-) So are boats.

> >	4. If I wanted to pitch the product -  I would not be talking
> >large scale system issues, development approaches and standards.
> 
> Why not?  Systems are composed from products.
	I am tempted but - every one knows we have the best :-)

> >	Please define what you mean by scale and approaches to scale. If
> >one is in the PKI and information services business and writing
> >standards for PKI - which must have a named - globally named
> information
> >components what is the database/protocol that you use that does
> "scale"
> 
> One can design scaleable solutions in various ways.  One may emphasize
> highly distributed, largely independent components with minimal
> interdependence.  One also may emphasize a tightly integrated, highly
> interdependent design approach.  You seem to be proposing the later, I
> am
> advocating the former.
	This is a bit fluffy for me - perhaps I might give these fluffy
things up.
	OR - perhaps I am proposing using an engineering, information
service methodology that you can do both of the above with. After all a
directory service is a function. eg we do support mutual server - server
authentication and signed ops (for some projects)

> >	why does the phone system have a directory service?
> 
> "A directory service?"  We don't have one, we have many.  What's the
> one
> number I call to get a phone number for any subscriber anywhere in the
> world?
	its 0103 :-) 

> >	why are all the PKI vendors on this planet embracing
> >directories?
> 
> Joint marketing opportunities produce increased revenues with lower
> costs,
> irrespective of the merits of the jointly marketed products/services
> :-).
> On a more serious note, users want solutions, and PKI solutions often
> require a directory, though not usually a globaly accessible one, nor
> one
> in which we create unnecessary vulnerabilities.
	agree - magic.

	Perhaps we (on this list can define the issue we are dealing re
naming and addressing, knowledge, etc and see what the alternative
scenarios are re directory services and hand crafted URLs.

	Then we can get down to the points eh.

	regards alan