RE: Some SACRED blasphemy

[Magnus Nystrom <magnus@xxxxxxxxxxxxxxx>]

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.
> 
> -----Original Message-----
> From: Chris M. Lonvick [mailto:clonvick@xxxxxxxxx]
> Sent: Tuesday, January 09, 2001 1:15 PM
> To: Covey, Carlin; 'ietf-sacred@xxxxxxx'
> Subject: Re: Some SACRED blasphemy
> 
> 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