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

Re: access-granting protocol (was Re: PK Authentication (...))

> Are we agreed that authorization protocol is independent of authentication
> protocol but both are necessary components of an access-granting protocol?

Absolutely.  I often hear people claim that it's not worth making a
distinction between authentication and authorization because they are
inseparable - one without the other is worthless.

That's only half right.  Authorization and accounting are worthless
without strong authentication.  Authentication by itself is meaningless
- what good does it do you to know for sure who someone is if you
aren't going to take some action based on that knowledge. Authorization
(granting access) and accounting (auditing or charging for it) are
ends.  Authentication is just a (necessary) means to those ends.

But the reason for keeping them separate is for simplicity.  An
authentication protocol can be made simple enough to analyze with
confidence, and a single simple protocol can satisfy most user's
requirements.

Not so with access control.  As you point out, the requirements are
so varied and the meanings so open to interpretation that it is
difficult to get agreement.  But it makes things a bit easier if
you can say with assurance that an ID (your "signer" or "signee"
using whatever representation you choose) is participating at the
other end of your protocol, without having to wonder if the authorization
mechanism has somehow weakened the binding between the ID and the
entity it represents.

The process I propose is:

1) define a standalone PK authentication protocol
2) use it, or any other authentication mechanism (S/Key, Kerberos,
    biometric, or plain password :-), as a building block in the
    access-control scheme, knowing that it has a particular level
    of assurance.

You are focused on #2, which is good.  It means you can take #1 for
granted.  But my primary concern is making #1 ubiquitous.



> Except, when we did the proxy demo, we were forced to assume that possession
> of a Fortezza card issued by DoD amounted to authorization to access through
> the firewall.  That is an improper mixing of concepts.  The certificate on
> the Fortezza card attests only to the existence of a DN in the DoD's name
> tree.  It says nothing about authorization to access a network.

Perhaps you misunderstood the purpose of the demo.  The firewall in
question was to separate one large heterogeneous network (the NIPRNET)
from another (the Internet), solely for the purpose of enhancing the
availability of the NIPRNET infrastructure.  For this purpose, possession
of a DoD-issued card is a reasonable criterion to use for granting access
to the transport facilities of the network.  It was up to individual
service providers (federal agencies, military bases, whatever) to set
up and use their own methods of access control for their own resources.

> The trouble
> was that nothing in Fortezza's X.509 world is equipped to express
> authorization -- unless v3 adds a field for such accesses, but I have
> stated elsewhere why I believe that approach is unworkable.

Nothing[1] in "Fortezza's X.509 world" (or the Fortezza card itself, which
knows *nothing* about X.509 certificates) is intended to express
authorization.  It is intended to provide an authenticated unique ID,
period.  That ID happens to be an X.509 DN, but could just as easily
be a globally-unique serial number or a hash of a public key.

It is up to a policy maker to decide what to do with the ID - it is
the network administrator (DISA) that decides that it is OK for any
DoD person to access the DoD network - he could do that by storing
a huge list of every public key issued to all DoD users on the firewall,
or by checking for a O=DoD in a certificate's distinguished name.
One method is more efficient than the other, but the mechanism is not
what created the access policy in the first place.

( [1] That isn't strictly true - the MSP-enhanced public key format has
privilege bits, and certificate storage labels are used as usage
hints, but those are both outside the scope of X.509.)

> This might work for a company as small as TIS, but in the example we were
> doing at TIS, the firewall was between the internet and milnet, if I
> remember correctly, so the idea of having a list of authorized users is
> unworkable.
>
> Instead, one needed an authorization certificate or ticket...the thing I've
> been describing in cert.html and on this list.

I don't want to downplay the usefulness of authorization certificates - 
they are being put to good use in at least one large program I'm aware
of.  But to imply that a static list of authorized users is unworkable
except at "a company as small as TIS" is misleading.

I presume that AOL, Compuserve, MSN, and every dial-up Internet access
provider that charges for service maintains a list of it's own
authorized users.  If they ever migrate from userid/password to some
form of real authentication, I suspect they will still do access control
based on access control lists, not based on capability certificates or
tickets.  The raw number of users isn't a big factor - the degree of
centralized control is far more important.