Subject: Re: Some SACRED blasphemy

From: "Chris M. Lonvick" <[email-masked]>
Date: Tue, 09 Jan 2001 14:14:44 -0600

At 11:04 AM 1/9/01 -0800, Covey, Carlin wrote:
>SACRED persons, I hope that I may be forgiven a minor blasphemy ....
>
>Both the SACRED requirements document and the SACRED framework document make
>reference to
>"entities" that use credentials.  In reading through the documents though,
>they seem to be
>making the assumption that an entity is a "user" who wants to make the
>credentials
>that are available to her in the context of some device environment, also
>available to
>her in a different device environment.
>
>I think a little broader view is potentially useful.  
---remainder deleted for brevity---

Hi Carlin,

This was somewhat discussed a while ago.  Check the archives for
items around this one:
  http://www.imc.org/ietf-sacred/mail-archive/msg00092.html

I would really _not_ like for this WG to make any real distinction 
between "user", "proxy", "good guy", "supreme being", or "device",
nor any of the entities which you describe at this time.  The scope 
of work is laid out to allow for a protocol to transfer credentials.  
While your thoughts are valid, let's try to deliver that functionality 
first.  After that, perhaps the WG may be re-chartered to address 
the issues you raise.  

I'll say that the issues that I raised before were more along the 
lines of _not_ making a limiting distinction about who was the 
"user".  I'll repeat my previous thoughts here:  It would be really
nice if the products of this WG could be used to transfer the
credentials between devices that are not closely associated with
a real person.  I am trying to keep up with the discussions and
drafts here to see if there are any problems with that concept (none 
so far).  However, I realize that if an impasse is reached, the 
decision must go towards the strict definition of the person.

I'd suggest that you also watch the list and IDs to see if there is 
going to be anything that may limit or exclude your idea.  (I don't
think there has been so far.)  When the IDs are far enough along 
and stable, I'll support your ideas and also see if an official 
designation needs to be made for the router administrator who may
also be known as your definition of a security administrator.

Thanks,
Chris

---

From: "Covey, Carlin" <[email-masked]>
Date: Tue, 9 Jan 2001 13:32:27 -0800

Bill,

I believe that at the requirements and framework level we need to be
concerned
about the roles that various entities have, not their particular
implementation.
While the currently preferred implementation for credential creation and
consumption
is the "process", there is no conceptual reason why we couldn't employ
alternative 
implementations such as hardware state machines, data-flow models, or some
bio-electronic goo.

I agree with you that the "credential" is the end result of whatever
information 
processing is needed to achieve the desired security goal, be that
authorization, 
privacy, integrity, non-repudiation, etc. This information could be
distributed
among many physically separated entities, as it is in a PKI, so there is no
one
place where the "credential" exists.  For example, an X.509 certificate is a
credential only if the subject maintains the privacy of the private key, and
the
relying party is ensured that the matching public key is bound to that same
subject.
The credential that SACRED is supposed to port to another processing context
is
the subject's private information for authenticating himself or ensuring his
privacy,
and/or the trusted information for authenticating other subjects.  

But I'm waxing too philosophical here.  I'm sorry.  Perhaps I missed your
point?

- Carlin Covey
  Cylink Corp.

-----Original Message-----
From: Bill Manning [mailto:[email-masked]]
Sent: Tuesday, January 09, 2001 12:32 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Some SACRED blasphemy

% 
% SACRED persons, I hope that I may be forgiven a minor blasphemy ....
% 
% Both the SACRED requirements document and the SACRED framework document
make reference to
% "entities" that use credentials.  In reading through the documents though,
they seem to be
% making the assumption that an entity is a "user" who wants to make the
credentials
% that are available to her in the context of some device environment, also
available to
% her in a different device environment.
% 

And I always thought that processes create/consume credentials, not people
or devices.
People generate (seeds/salt/tokens/secrets) and processes in devices work on
that input to 
generate/store/move/display/consume the results, which I think of as
credentials. 

-- 
--bill

---

From: "Covey, Carlin" <[email-masked]>
Date: Wed, 10 Jan 2001 07:29:27 -0800

Magnus,

Thank you for that reassurance.  I am quite content.

Regards, Carlin

------------------------------
- Carlin Covey
  Cylink corp.

-----Original Message-----
From: Magnus Nystrom [mailto:[email-masked]]
Sent: Wednesday, January 10, 2001 2:09 AM
To: Covey, Carlin
Cc: [email-masked]'
Subject: RE: Some SACRED blasphemy

Carlin, All,

As we all know, this working group is about how to make credentials
available to users in a secure manner, regardless of their current
computing platform. The charter also mentions that "only authorized
clients should be allowed to download credentials".

The charter does not, however, make any attempt to define the
authorization authority ("authorizer"), nor the entity responsible for
generating the user's credentials ("source"). But to me, this doesn't
imply that these entities - or their needs from a protocol standpoint -
are excluded from the SACRED domain or its protocols. On the contrary, I
think it is valuable if their needs could be kept in mind somewhat when
finalizing the Requirements document, and, perhaps, the Framework document
(which perhaps will be integrated in whatever Protocol document will be
develope) as well. Perhaps these constituencies should be defined in the
Requirements document, even. Whether the charter needs to be re-written or
not if/when we need to deal more explicitly with these issues is not clear
to me; it appears, however, that it not necessarily would be the case.

But as Chris points out, I feel our focus now should be on developing the
protocol for transfer of credentials as well as some portable credential
format.

Regards,
-- Magnus
Magnus Nystrom
RSA Security

On Tue, 9 Jan 2001, Covey, Carlin wrote:

> Chris,
> 
> Thanks for the pointer to the previous discussion.  I too, do not want
> the protocol to make a distinction between various types of entities,
> but I do think there needs to be a distinction between at least the
> three roles that I mentioned:  source, destination and authorizer.
> 
> I agree that it is appropriate for the working group to focus on 
> developing a protocol for the simplest case first: a straightforward
> transfer of credentials with shared knowledge among the source,
destination
> and authorizer (for instance, we may assume for now that they are all 
> the same human being).
> 
> The reason for my "blasphemy" was that I wished to ensure that the 
> requirements and framework documents were not later interpreted as
> excluding a need for more sophisticated versions of the credential
> transfer protocol to handle the more general cases.  If the working 
> group feels that this is not an issue, I'm satisfied.  I am a little
> concerned at your mention of possibly rechartering the group at some
> later date to address these issues.  I'm content to postpone addressing
> these issues, but in my reading of the working group charter it seems
> to me that no rechartering is needed to address these issues.  Chairs?
> 
> - Carlin Covey
>   Cylink Corp.
> 
> From: Chris M. Lonvick [mailto:[email-masked]]
> Sent: Tuesday, January 09, 2001 1:15 PM
> To: Covey, Carlin; [email-masked]'