Subject: RE: Comments Re: [seamoby] ct problem statement

From: Kulwinder Atwal <[email-masked]>
Date: Sun, 10 Jun 2001 03:33:11 -0400

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
> Sent: Friday, June 08, 2001 3:54 PM
> To: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1
> Cc: 'Charles E. Perkins'; Gary Kenward; [email-masked]'; 'seamoby'
> Subject: RE: Comments Re: [seamoby] ct problem statement
> 
> 
> 
> 
> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Thursday, June 07, 2001 3:41 PM
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: 'Charles E. Perkins'; Gary Kenward; [email-masked]'; 'seamoby'
> Subject: Re: Comments Re: [seamoby] ct problem statement
> 
> 
> On Thu, Jun 07, 2001 at 03:43:29PM -0500, Nakhjiri 
> Madjid-MNAKHJI1 wrote:
> > Hi Charlie,
> > 
> > Correct me if I am wrong, 
> > I have not been very successful in finding specs that
> > discriminate between authentication and authorization.
> > So far I have only seen it in AAA Arch. 
> > Otherwise people use authentication credentials
> > and authorization credentials interchangably.
> > 
> > So we created a requirement that the CT peers should
> > mutual authenticate each other prior to CT. Do you think
> > a separate requirement for authorization is needed?
> 
> 
>    Authentication
>       The act of verifying the identity of an entity (subject).
> 
>    Authorization
>       The act of determining whether a requesting entity 
> (subject) will
>       be allowed access to a resource (object).
> 

Hello Kulwinder

Thanks for the answer.  It conforms exactly with my previous understanding.

If you want to quote this message and answer to the mailing list, that
would be fine with me, but I didn't see a reason to send my request
for clarification to the mailing list.

Regards,
Charlie P.

> MN>> Sure. I get it, but my question is:
> do we have different credential for authentication and 
> authorization today?

I believe the confusion was started by this statement.

Some definitions:

1. Credential: A certificate (Indentification Card, Digital Signature)
issued by a trusted third party.

2. Authentication: The act of verifying the indentity of an entity by
checking for a valid credential.
 
3. Authorization: The act of determining whether a requesting entity will be
allowed access to a resource which may depend on several inputs of which
authentication one such input. (others: job function/service aggreement)

Consider the following process:

1. Present Credential to Security Authority.
2. Authenticated? Yes.
3. Authorized? Yes.
4. Grant Access.

Or,

1. Present Credential to Security Authority.
2. Authenticated? No.
3. Deny Access.

The Authorization step is moot after failing the Authentication step.
Therefore, the term "Authorization Credential" has no value, since the
credential is never presented to the authorization process, but to the
authentication process.  Without Authentication there can be no
Authorization.

Present Credential -> Authenticate -> Authorize -> Grant Access.

Read the first few lines of:
http://www.vsm.com.au:8000/ht_root/doc/htd/htd_1200.html#159

Infact, the term "credential" stands on its own to convey the correct
meaning. It does not need adjectives like authentication, security, or
authorization.  

- Kulwinder.

> Madjid

---

From: Charlie Perkins <[email-masked]>
Date: Sun, 10 Jun 2001 07:15:21 -0700

Hello Kulwinder,

I'm still trying to identify the problem that prevented me from
satisfying <mat@cisco>'s  "security 101" criterion.  Thanks
for your comments.  I have a couple of follow-on questions.

Isn't it possible to have authorization without authentication?

In other words, isn't it possible to grant authorization based
on verification of some credential that doesn't provide any
assurance of identity?

Currency comes to mind, and then electronic cash, but other
credentials are possible and relevant to the discussion.
I realize that such things begin to blur the line between a
credential and a tradable resource.  As you have pointed
out, relying on credential verification itself begins to blur the
line between authentication and authorization.

Maybe an example would help.  Suppose I put something
in a treasure chest, which cannot be opened except with
a key I happen to have.  Then I give you the key and tell
you how to use it to open the treasure chest.

Doesn't your possession of that key mean that you have
authorization to open the treasure chest?  Surely, the
treasure chest isn't going to care about your identity.
To me, this means that authorization does not require
authentication.

It should be clear how to map this example into the [seamoby]
realm of authorizing access to transferable context information,
and very relevant to the eventual discussion we should be
having.

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Sun, 10 Jun 2001 07:54:45 -0700 (PDT)

> line between authentication and authorization.

I don't think so. Unless you just found the money
laying on the street or something, the
authentication step happened when the previous
entity gave *you* the money. Even if you found it
on the street, you are just pointing out a
weakness in the security scheme (I doubt that
ecash carries this vulnerability forward). Note
also that there is an explicit authentication step
being done by the merchant: that the currency is a
valid currency backed by name-your-government. 
This serves as a trusted third party. Note also
that there may be many levels of hierarchy here:
VISA/BofA/Federal Reserve/US gubberment.

 > To me, this means that authorization does not require

No. I could have given you the key but put
restrictions on your authorization to open it (do
not open unless I'm dead...). Again, don't
conflate the strength of either the authentication
or authorization checks (honor in the latter
case) with their existence. 

 > and very relevant to the eventual discussion we should be

What is pertinent with SEAMOBY is third party
delegation and transitive trust arrangements.  The
MN delegates (authorizes) the oldAR to act on its
behalf after being authenticated by oldAR in the
first place. OldAR and newAR have their own trust
arrangement, which includes methods to
authenticate and what is authorized within that
authentication realm/identity. One of those may be
the acceptance of CT. Even then, the job is not
done. NewAR must complete the transaction by
demanding that MN prove its identity to authorize
use of that context. That can either be done
directly (as in the way it initially authenticated
via AAA, say), or through some new authentication
realm (ie, via new secret in the realm of the
AR's).

		Mike

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 11 Jun 2001 10:19:48 -0700

> Isn't it possible to have authorization without authentication?

To me, it doesn't make a whole lotta sense. If you are going to authorize
something prior to authentication, then I would consider the latter step
as unnecessary.

I agree with some that given enough money, you'll authorize anything,
but you still want to make sure that the person asking is in fact the
one that provided you with the cash, right?

> on verification of some credential that doesn't provide any

verification of credentials implies authentication. Authentication
doesn't necessarily provide that you'll know the identity of the
requestor. It really depends on the type of authentication involved.

> credentials are possible and relevant to the discussion.

Right. But if having a bank account number is sufficient to
withdraw money, then this is a form of (admittedly weak) authentication.

Once you've provided your bank account number, authorization would
kick in when you request the amount you want, and the bank's policy
in determining whether you've been authorized is probably something
like:
1. Do you have enough in your account
2. Does it blow your daily limit
3. Do they even have enough in hard cash to give you

> you how to use it to open the treasure chest.

Which is similar to giving me your bank account number (above)
What you've done is authorize someone to have your credentials,
which is used during the authentication process.

> To me, this means that authorization does not require

No, having the key is authentication. Authorization is allowing
the person to take what they do (and assumes that there is an
entity checking this, persumably you).

Note the fact that no one is at the vault implies that your
example involves authentication, but not authorization.

Hope I haven't muddied the waters worse than it already was.

PatC

---

From: Arthur Ross <[email-masked]>
Date: Mon, 11 Jun 2001 11:30:21 -0700

At 10:19 -0700 06/11/2001, Pat Calhoun wrote:
[snip some history]
>Hope I haven't muddied the waters worse than it already was.
Au contraire, Pat -

Once again you guys are, methinks, nibbling around the edges of a much
larger, more profound problem/issue of what I would call the "Evolved
Internet". [Yes, I know that these philosophical soapbox orations of mine
belong in the new list, which I have indeed cc'd.]

When all sorts of entities, from doorknobs to aircraft carriers, and
everything in between, are potential nomadic communication endpoints, the
question of who can see and do what becomes VERY profound, and potentially
VERY complex.

I keep thinking that a good illustrative, prehistoric example/philosophical
model of the kind of thing I am thinking of is the ol' Unix heirarchical
file system. Everything has a nonad [a word I just invented, meaning "group
of nine"] of priviledge flags, corresponding to all possible combinations
of {read,modify,execute} with {owner, group, world}. In this view,
authentication determines which of the three categories an supplicant
belongs to, and authorization says which of the three actions he can
perform. Attached are the owner and group IDs.

As in the Unix model, the privledge sets might be inherited from a "parent"
of some kind by default, or explicity modifiable. An obvious question is
the nature of that heirarchy (or hierarchies) - does it map onto
administrative domains? Routing domains? Or some other independent
structure? How this stuff moves & changes with changes in point of
attachment of a nomadic/mobile node is a highly nontrivial question as well.

In this larger view, the Unix-like model would likely have parameters too,
e.g. the credit limit, or non-monetary resource limits, time windows, etc.

.... just my two cents worth ...

   -- ahmr

---

From: Jonathan Trostle <[email-masked]>
Date: Mon, 11 Jun 2001 12:01:12 -0700

>Isn't it possible to have authorization without authentication?

Sure, unless you are playing a word game where no authentication
is viewed as one type of authentication - i.e. very weak authentication.

>on verification of some credential that doesn't provide any

Yes. This is classically known as a bearer proxy.

>To me, this means that authorization does not require

Yes. Another example would be a VPN or multicast group with 
a single shared secret key. A message protected with such a 
key authorizes the sender as a member of the group. But it 
doesn't allow the receiver to determine the identity of the sender.
To do that, a source authentication security service is needed.

Jonathan

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 11 Jun 2001 12:04:21 -0700

> Au contraire, Pat -

Je ne pense pas.

> perform. Attached are the owner and group IDs.

I wonder why this thread even exists, but I find myself having to correct
your example above. The very fact that a set of permissions have been setup
on a file is NOT authentication. Before I even get access to the said files,
there is another program, Unix login, which checks my credentials, and then
executes the shell with my user and group id. Requesting access to the file
is an authorization decision on the part of the OS. Do I have access to the file?
What is my user id? group id?

Obviously, we aren't going to agree on the very fundamental difference between
authorization and authentication, and we can just agree to disagree.

PatC

---

From: Arthur Ross <[email-masked]>
Date: Mon, 11 Jun 2001 12:47:07 -0700

>authorization and authentication, and we can just agree to disagree.
Pat -

You missed my point completely - I am AGREEING with you 100%. Indeed, the
login, which includes authentication, attaches the formal identity to the
session. The formal identity is then used as an index to the privledges,
a.k.a. authorization. We are in 100% agreement.

My point is that this is a microcosm of a MUCH LARGER ISSUE, which, of
course, is not currently being addressed.

   -- ahmr

   Dr. Arthur H. M. Ross
   1004 Cottage Way
   Encinitas, CA 92024-5857
   Tel: 760-634-8173 (Res.)
        602-677-1021 (Portable)

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 11 Jun 2001 12:41:47 -0700

> course, is not currently being addressed.

Ooops. When you stated "Au Contraire", to me it implied that you disagreed with
me. Sorry I didn't notice that the rest of the text was agreeing with my
previous statement :(

PatC