[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Ideas from the I&A Forum

I attended the MISSI I&A forum, at the suggestion of one person on this
list, and got a number of ideas for additional <auth> fields -- mostly
related to access to classified data -- but my biggest impression is that
these folks really need what we're producing.  Dr. Gene Hilborn from CDC had
almost produced it -- something he called an SST (secure session ticket)
almost exactly a CRCert -- but IMHO he got mired in the assumption that it's
certificate-like so therefore he had to use and mangle X.509 in order to
make it.

That was a popular assumption -- that X.509 was a given to be used even if
there was no need for identity certification and even if it had to be
modified a little here and a little there in order to do something useful.
When I explained to a few people that we had departed from X.509 because of
the implementation difficulties, I found knowing smiles and a hint of
interest, but it was clear I was speaking heresy.


A general rejection of identity certificates showed up during the
presentations via a focus on ACLs (or attribute certs) and an insistence
that the two functions had to be separate, because the assumed hierarchy of
CAs which makes an identity cert isn't authorized to declare access rights.
The latter have to be declared locally.

In fact, in 1.5 days I heard only one argument for the identity certificates
themselves.  The example used in favor of identity certificates was that NSA
might want to grant some access to the key of a CIA employee, at the request
of the CIA.  Some lower security person in an office at the CIA would make a
STU-III phone call over to a corresponding security officer at Fort Meade
and give the name and SSN of the CIA employee to be granted the access.
Those people operate with (name,SSN) now and always will, or so the argument
goes.  Therefore, when public keys are empowered, they need to receive that
power from the same human procedures in use today.  Therefore, there needs
to be a trusted mapping from (name,SSN) to public key.

The EMPLOYEE: field satisfies this need but I should probably specifically
note that <name> could be (name,SSN) or (name,Employee-#), ....

The surprise to me was that there is a concrete need for certified identity
which I had just not considered.  In my world, voice phone calls almost
never happen -- so the natural thing for me to do is e-mail a public key or
its hash, using authenticated and maybe private e-mail, and introduce the
subject employee that way.  I would never phone or FAX or write a paper memo
for this purpose.


Another recurring theme was "enforcement of least privilege" -- meaning that
an authorization needs to be as specific as possible, as contrasted with the
UNIX superuser sledgehammer.  This suggests to me that there will be a huge
number of <auth>s defined, should the world take this maxim seriously, and
the AUTH: construct would see a great deal of use.


Rich Salz gave a presentation on DCE -- a nice overview -- and listed DCE's
file permission flags.  The hypothetical PKFS: permissions were lacking "X:
execute".  DCE's "C: control (change ACL)" is covered by the ability to
delegate an <auth>.  I still don't know what the DCE "T: test" permission is
good for, so I can't suggest we add it.  Rich?  Of course, the PKFS example
was just hypothetical in the first place, so this probably doesn't matter much.


There was a real desire, in one segment of the intelligence community, for
<auth> fields to be enciphered.  We mentioned this as an aside in the I-D
draft in section 3.14 -- but it looks like there are real users for this.  I
suggest adding an <auth> field:

ENCIPHERED: <byte-string>

to handle this case.  The choice of key (or its indication) or of algorithm
would be up to the issuing/using agent to decide.  That might even be masked
by encryption under some family key.  That's entirely up to them.

More later, perhaps, as I review my notes.

 - Carl