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

From: Kulwinder Atwal <[email-masked]>
Date: Mon, 11 Jun 2001 01:00:20 -0400

> -----Original Message-----
> From: Charlie Perkins [mailto:[email-masked]]
> Sent: Sunday, June 10, 2001 10:15 AM
> To: Kulwinder Atwal
> Cc: 'seamoby'
> Subject: Re: Comments Re: [seamoby] ct problem statement
> 
> 
> 
> 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?

No.  Even when it seems like it maybe, the authentication is implicit, or
"out of band".

> 
> 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.

Lets consider currency.  A one hundred dollar bill issued by a central bank
looks quite different than a one hundred dollar bill drawn by six year old
child.  The authentication process happens when you pick up the two bills
and realize one is authentic.  

When you hand the two bills to a merchant the merchant will also look at the
two bills determine one is authentic (Authentication) and allow
(Authorization) you to make a purchase with only the authenticated bill.
But, the merchant may realize sufficient funds are not available to make
change for you, if you decide only to purchase a piece of gum.  In this case
the merchant has authenticated the currency, but not authorized the use of
the currency.

The indentity being verified with currency is the indentity of the central
bank.  Looking at a twenty dollar bill in my wallet, I notice that the bill
is signed by two individuals with the central bank, under the statement
"This note is legal tender" and the name of the central bank.

The currency itself is a credential of the central bank.  The indentity
being verified by the credential is the indentity of the central bank.
Since we believe it is unlikely that the bill is forged, it is our trust
(trust relationship) in the central bank that allows us to use it.

Currency has value and is a credential that verifies the identity of the
central bank.

> 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?

It is not my identity the chest is verifying.  It it the indentity of the
key.  If the identity of the key is correct (Authenticated) such that its
pattern matches the lock, the lock will allow (Authorize) the chest to open.

> Surely, the
> treasure chest isn't going to care about your identity.
> To me, this means that authorization does not require
> authentication.

Further you verified my identity before giving me the key.  You
authenticated me as really being me and not some imposter posing as me.
After you were certain it was me you authorized my access to the chest by
giving me the key.

There are two seperate Authentication/Authorization processes invovled.

1. You authenticate my identity and authorize me to hold the key.
2. The lock authenticates the key and authorizes the chest to open.

This is possible because a key holder (you) can delate trust by passing the
key after completing step 1.  Most people do not consider step 1. as a
'real' step becuase it is usually implicit.  

But, consider that the shared secret (credential) is not a key/lock
combination, but instead is a username/password combination.  

Software has no way of performing implicit 'delagation of trust' operations
on the username/password combination.  

For Context Transfer to work, software MUST have a method of delagating
trust between an MN and ARs so that a MN can move from oldAR to newAR
without a breach in security.

- Kulwinder.

> 
> 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.
> 
> 
> 
> 
> 
> Kulwinder Atwal wrote:
> 
> > > -----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: Cedric Westphal <[email-masked]>
Date: Mon, 11 Jun 2001 01:08:25 -0700

> No.  Even when it seems like it maybe, the authentication is implicit, or

[Cedric] I think most of the confusion here comes from different level of
authentications.
Personal authentication vs. group authentication
strong authentication vs. weak authentication.

In order to get authorization, you need some level of authentication.
You don't have to be identified all the way to your finger prints. Proving
that you belong to a given group is usually enough.

So you are right when you say that showing some credentials does
relieve you of (strong/personal) authenticating, since the credential
is already a (weak/group) authentication.

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

[Cedric] It is possible, as long as the credential give some assurance of
belonging to the authorized group. So it is a weak authentication.
(that there is a strong authentication to get the credential is not a
requirement, and as long as you accept the credential, who cares.
Take credit card on-line. As long as someone gives you a
credit card number (the credential) that is valid (the weak authentication),
then that person can access your service. You don't give a damn how the
user got the card number in the first place.

> and realize one is authentic.

[Cedric]  As far as the user is concerned, he provides a weak authentication
(belongs to the group: has the ability to pay/has the right credential, not the
credential drawn by a 6-yo).

> "This note is legal tender" and the name of the central bank.

[Cedric] The identity really verified is that the user belongs the the
authorized
group (valid money=right credential=belongs to 'can access service since he/she
has paid' group).

> > line between authentication and authorization.

[Cedric] Question is: why do you do authentication for? If you eventual
purpose is to charge the user for the service he receives, then the
credential is a solvability credential anyway, so why not currency.

> pattern matches the lock, the lock will allow (Authorize) the chest to open.

[Cedric] once again, it is not the identity of the key or the bank. The
authentication
is just that the user (key holder) belongs to the authorized group (those who
have
the correct keys).

> > To me, this means that authorization does not require

[Cedric] The chest does not require strong authentication. Does require weak
authentication.

> After you were certain it was me you authorized my access to the chest by

[Cedric] how you get access to the key is none of the chest problem. Maybe you
whacked Charlie on the head, the chest don't care. In a context transfer
framework,
it means that there MUST be a weak authentication process to perform CT.
CT does only care about Step 2 below.

Cedric.