Subject: Re: The case against directories

From: [email-masked]
Date: Sun, 23 Mar 2003 12:16:52 -0700

ref:
http://www.garlic.com/~lynn/aadsm13.htm#38 The case against directories

we've had some long term experience in this. the kerberos reference ....
was from one of the audit visits that my wife and I did on project athena
.... and sitting thru an extended detailed description of the "new"
cross-domain kerberos protocol .... and various subsequent discussons.

however, going back even further ... almost 25 years ago ... a couple of us
were sitting around friday night trying to think up ways of getting upper
management interesting in online use. one of the compelling business uses
was an online telephone directory (for some 450,000 or so employees &
increasing). we had some simple objectives .... 1) online lookup elapsed
time faster than reaching for a local site paper directory and looking it
up, 2) take 2 person weeks or less to implement, 3) take less than a half
person day per month to support, 4) in addition to existing informaiton
like name, telephone number, internal mail-stop ... allow it to grow into
things like email address.

so we started contacting various plant sites .... asking for process that
would regularly transmit the machine readable copy that they used for
producing the site's paper directory. It turned out what started to consume
the most time were discussions with the site security officers about
security classification of an online directory .... that was only available
inside the corporation ... and only contained name and telephone number ...
and was an exact duplicate of the paper directory. Paper directories were
classified internal use only .... the security officers wanted to classify
the equivalent information (even if it was only name and telephone number)
when made available online at a significantly higher security level (even
if it was only accesable from inside the corporation).

much longer (including technical) description of the online telephone
directory effort:
http://www.garlic.com/~lynn/2003b.html#45 hyperblock drift, was filesystem
structure (long warning)

note that the internal network at the time was larger than the
internet/arpanet and continued larger up thru approximately 1985.
http://www.garlic.com/~lynn/internet.htm#4 Internet (TM) and USPTO
http://www.garlic.com/~lynn/internet.htm#0 Internet and/or ARPANET
http://www.garlic.com/~lynn/internet.htm#22 internal network's 1000th node
http://www.garlic.com/~lynn/2003d.html#59 unix

totally random trivia was in the mid-80s i was told that the internal
network had over half of all link encrypters in the world.
http://www.garlic.com/~lynn/2002d.html#9 Security Proportional to Risk
(was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk
(was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002j.html#52 "Slower is more secure"
http://www.garlic.com/~lynn/2003e.html#36 Use of SSL as a VPN

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

[email-masked] on 3/22/2003 7:26 am wrote:

Lynn

well said. Access controls and privacy issues apply regardless of
technologies.

David

---

From: [email-masked]
Date: Fri, 28 Mar 2003 08:34:32 -0700

the one detailed implementation presentation I've seen on a SAML based
product .... looked exactly like Kerberos .... but the transmissions were
SAML-encoded (and carried authorizations in addition to authentication)

misc kerberos
http://www.garlic.com/~lynn/subpubkey.html#kerberos

[email-masked] on 3/28/2003 4:55 am wrote:

> Using authentication systems like OASIS' SAML, organizations can
> (through their employees), authenticate to each others' intranets and
> through this get access to exactly the information they should have
> and in a format that make sense.  The latter may be a directory tree,
> a PDF-file, a database listing, an HTML form, etc.
>
> Unlike directory systems, SAML allows secure access to any kind
> of active or passive information source, including purchasing and
> work-flow systems.

SAML is a good but complex means for communicating
authorizations ans assertions, it is not a whole middleware
infrastructure.

---

From: Russ Housley <[email-masked]>
Date: Fri, 28 Mar 2003 11:16:31 -0500

Phil:

I probably should not get sucked into this thread, but I feel a need to 
reply to some of the suff in this thread.

> > Yet another thread against directories. I wonder when "cases
> > against XML" will be issued after we have found yet another
> > new technology that markets well.
>
>Actually the issue is not angle brackets or not, the issue is
>the primary search key.
>
>The only query that a PKI enabled application wants to make
>is to map a network address to a public key. There is no
>direct support for this in hierarchical directories - unless
>you structure the DIT using DNS names and then you have DNS
>in ASN.1.

This is nonsense.  The query is application specific.  In IPsec, the query 
key is either DNS name or IP address.  In S/MIME, the query key is email 
address.  And, so on.

>SCVP can with modifications serve the exact same purpose as
>XKMS and be equally useful.

We talked about one -- the return of the raw public key.  That was added 
several document generations ago.  I have not dear any other comments.

>In general it is simply not useful to have information that
>is structured for both machine retrieval and human retrieval.

Agree.

> > As already has been stated, the problems are mostly
> > organizational than technical.
>
>The technical issue is still substantial. There is no standard
>query I can issue that is supported ALL by the DEPLOYED directories
>that will allow me to do a lookup on the email address of the
>person I want to contact.

The LDAP community is working on this issue.  And, I hope that a SINGLE 
solution emerges quickly.  The PKIX community has already experienced the 
lack of interoperability that comes from more than one way to achieve the 
same result.

>Therefore there is no standard to do the thing that is useful.

I would hope that there is more than one thing for which the directory is 
useful. ;-)

> > Even if you don't like it, directory supported PKI is being
> > more and more implemented.
>
>No it isn't. We deploy the PKI and then link it to the customer's
>directory if they have one. The applications don't actually
>interact with the PKI though so this does not meet any reasonable
>definiton of 'directory supported'.
>
>You can shut down the directory and degauss the hard drives and
>most PKIs will work exactly as well. Many will work better.

He said, she said...  I am aware of some large environments where 
directories are being used by the infrastructure, and applications are in 
the process of being updated to make use of the directory.  Fine.  You know 
of environments where the applications are not being updated.  Fine 
too.  This is probably as much a statement about the economy as the technology.

Firewalls play a big part in this too.  Most places do not enable directory 
access from the outside.  This means that the certificates that are 
intended to be used by parties outside the enterprise need to be published 
in at least two places.  The only solution I have seen discussed for this 
one is Peter Gutmann's HTTP certificate store.

I would rather have a discussion of the problems with deployment and their 
potential solutions....

> > Banks and other big companies are deploying directories for
> > PKI as well. Are all of them on a dead end road?
>
>Ask if any of those banks intend to make their directory
>accessible beyond the firewall. I think you will find the
>answer is over my dead body.

At least one large enterprise is running two directories, one inside and 
one outside.  The one on the outside contains a subset of the 
population.  This imposes a huge burden on the administrator.

Again, I would rather have a discussion of the problems with deployment and 
their potential solutions....

> > > 2. Internal information  (including employment) is
> > generally not public
> >
> > No problem for directories, since you have well established
> > and good working authentication and access control
> > mechanisms, so everyone can define who is allowed to see the
> > certs.
>
>Nobody trusts those mechanisms, nor should they. Even if
>the software is correct (doubtful even if it is advertised
>as unbreakable) the configuration probably isn't.
>
>We do managed security services as an outsourced service.
>Quite often when we take over a customer's firewalls we
>discover horrors. It is unusualbut not as unusual as it should
>be to find that a $100,000 fault tolerant, redundant etc.
>firewall is being run with all trafic allowed in both directions.

So, some people do not understand the technology that they purchase and 
install.  What does that have to do with this discussion?

What are the problems that really need the attention of the IETF?  Notice 
that I did not say the PKIX WG.  We may find that some of the problems need 
to be worked by PKIX, but there may be others that need to be worked in 
other working groups.

> > Yes, and as I said before, ther might be scenarios in which
> > XML/Web Services technology are more appropriate (I am not
> > making a "case against XML"). Still I know of a lot of
> > scenarios, where existing, well established technology is
> > better for production services.
>
>We have tried X.500 for 15 years now with zero utility
>demonstrated with respect to PKI. LDAP has been arround for
>less time but there is no major architectural difference
>except for the fact that once upon a time LDAP was simpler.
>
>This reminds me of the arguments the physicists used to
>make for FORTRAN. It is tried technology, why move to
>something that is newer, has been designed with a knowledge
>of the architectural limitations of FORTRAN, a better
>understanding of program language design and which empirically
>results in more accurate code with fewer bugs that is
>completed in much less time and is much more maintainable
>afterwards?

Again, we are off topic.  Since we are, I feel obligated to add some fuel 
to the discussion.  We do not know that XML offers us "more accurate code" 
or "fewer bugs."  We do know that some very nice tools have been generated 
to aid programmers.  These tools will lead to "more accurate code" or 
"fewer bugs."  But, in my opinion, similar tools could be developed for 
other approaches, but the product managers of the world have not chosen to 
do so.

Hopefully we can return to fruitful discussion now ...

>Actually SAML is two things, the AAA application statements and
>the assertion framework. The assertion framework absolutely is
>a middleware infrastructure and was designed as such. It is
>intended to be possible to support every X.509 signed data
>construct within that framework and in fact any other statement.
>
>As Tim B-L pointed out the SAML assertion framework is a
>competitor to RDF.

So, how does this help us deploy certificate repositories?  Is SAML going 
to be the access control to such repositories?  Is SAML a consumer of 
certificates, and it needs to access repositories?  Or, both?

Russ

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 28 Mar 2003 10:19:18 -0800

>reply to some of the suff in this thread.

That is what I thought.. but as you know directories suck
you in to threads like these.

> key is either DNS name or IP address.  In S/MIME, the query 

Actually this is precisely the set of semantics we ended up
with in XKMS and the set of semantics I believe need to be
added to SCVP.

> The LDAP community is working on this issue. 

That is good, but in the meantime they should not claim that
they have already solved the problem.

> I would hope that there is more than one thing for which the 
> directory is useful. ;-)

Yes, it is a have standardized a hammer and will insist that
we call everything a nail...

> install.  What does that have to do with this discussion?

It depends whether you consider the job of the IETF to be
the design of protocols that can be secure when deployed by
experts or whether we should develop protocols that are robust
when deployed in real world situations.

It irritates me somewhat that the people who keep asserting
that I am compromised by a financial interest here do not
recognise that high priced consultants might have a similar 
interest here - and no I am not talking about you Russ.

> What are the problems that really need the attention of the 
> IETF?  

I think that we need to address the problem of how the
whole PKI architecture hangs together in a document that
can be understood by the people who are actually on the
front lines.

I don't think that simply repeating the mantra of the
end-to-end ideology helps either. Yes end-to-end is a
good thing, but there are a lot of security issues
itt does not and canot address. Defining these issues
as non-problems as the IETF has done for many years
or railing against firewalls, NAT, etc. as members of
the IAB are wont to do is not helpful.

		Phill

---

From: Russ Housley <[email-masked]>
Date: Fri, 28 Mar 2003 17:20:51 -0500

>with in XKMS and the set of semantics I believe need to be

As Trevor said at the meeting in San Francisco, application-specific 
validation policies are going to be developed.  It is not clear if they 
should be in the base protocol or in a separate document, but everyone 
agrees that it should be done.

Russ