[ietf-enroll] Charter

[Trevor Freeman]

SACRED is a mechanism to allow me to store credential on a server and
upload them onto a device. 
ENROL is looking to allow a device which has been loaded with 0 or more
credentials including passwords (which are not covered by SACRED) and PK
credentials, to negotiate with a service on what it what to use. i.e. I
have a credential from foo and bar, do you accept either as a token to
provide me network access?
Allowing me to store credential on a server seems to me completely
orthogonal to negotiating to use said credentials.
Trevor

-----Original Message-----
From: ietf-enroll-bounces at mit.edu [mailto:ietf-enroll-bounces at mit.edu]
On Behalf Of Alper Yegin
Sent: Tuesday, May 27, 2003 8:51 PM
To: Trevor Freeman; Russ Housley; jimsch at exmsft.com; IETF-Enroll
Subject: Re: [ietf-enroll] Charter


> Can you be more specific? I have also read the SACRED charter and I
> don't see the overlap. ENROLL is targeting negotiation to reuse
existing
> credential 

What exactly do you mean by "negotiation to reuse existing credentials?"

The SACRED charter talks about a server-based scheme where "Credentials
are
uploaded to the server by one device (e.g., a desktop computer); they
can be
stored there and downloaded when needed by the same or a different
device
(e.g., a mobile phone, PDA, or laptop computer)."

"Downloading from the server" part above sounds like "reusing existing
credentials".

> or get new credentials. We are not making any assertion about
> what comprises the starting set of credentials or how they get to any
> given point in the network.


OK, we care about how those credentials will get to the host, right?
Somehow the client will have to prove its ownership of the credentials
to
the other end (server) and receive them? Or, prove authorization to get
a
new set of credentials from the server. Maybe this is the difference:
the
former is SACRED, the latter is ENROLL. But how would this impact the
protocol design, this is what I'm trying to understand...

Alper

> 
> Trevor
> 
> -----Original Message-----
> From: ietf-enroll-bounces at mit.edu [mailto:ietf-enroll-bounces at mit.edu]
> On Behalf Of Alper Yegin
> Sent: Tuesday, May 27, 2003 11:53 AM
> To: Russ Housley; jimsch at exmsft.com; IETF-Enroll
> Subject: Re: [ietf-enroll] Charter
> 
> 
> Reading the charter of SACRED, and messages on this mailing list, I
> think
> there may be some overlap between the ENROLL protocol and server-based
> SACRED protocol. The end-result might be some protocol re-use between
> the
> two. Note that IPSRA was being considered for both protocols at some
> point.
> 
> Alper
> 
>> SACRED is about credential portability.  ENROLL is about getting the
>> credential in the first place.
>> 
>> Russ
>> 
>> 
>> At 10:33 PM 5/25/2003 -0700, Alper Yegin wrote:
>> 
>> 
>>> It'd be useful to understand how this work relates to or differs
from
> the
>>> work SACRED WG is doing. Any comments on this?
>>> 
>>> Alper
>>> 
>>> On 4/28/03 12:03 PM, "Jim Schaad" <jimsch at nwlink.com> wrote:
>>> 
>>>> Here is a candidate charter for people to take shots at.
>>>> 
>>>> Description of Working Group:
>>>> 
>>>> There are many cases where a user needs to obtain credential
> information
>>>> from a service provider and provide for some type of information
for
>>>> validation of identity.  This working group will look at some of
the
>>>> cases dealing with the use of cryptographic algorithms for
providing
>>>> this information.
>>>> 
>>>> When doing enrollment of a user against a service provider, three
> pieces
>>>> of information need to be provided or created in order to support
>>>> authentication of the user to the provider and to allow for
> additional
>>>> security services to be provided any information exchanged.  These
>>>> pieces of data are:
>>>> 
>>>> 1.    The name of the entity being enrolled,
>>>> 2.    A piece of keying information to be used
>>>> 3.    A set of permissions for operations for the entity being
>>>> enrolled.
>>>> 
>>>> This group will create a model to be used in describing enrollment
>>>> procedures and create a document for a framework how this is to be
> done.
>>>> The group will then produce three documents profiling the use of
the
>>>> framework for the following cases:
>>>> 
>>>> 1.    A shared secret key
>>>> 2.    A base asymmetric key
>>>> 3.    A bound asymmetric key (e.g. an X.509 certificate).
>>>> 
>>>> Additionally, the group will consider the case of using a credit
> card
>>>> profiling the framework.
>>>> 
>>>> Goals and Milestones:
>>>> 
>>>> Sept 2003    First draft of model
>>>> Dec 2003    Last call on model document
>>>> Nov 2003    First draft of Framework document
>>>> April 2004    Last call on module document
>>>> March 2004    First draft of secret key profile
>>>> March 2004    First draft of bare asymmetric key profile
>>>> March 2004    First draft of bound asymmetric key profile
>>>> Aug 2004    Last call on secret key profile
>>>> Aug 2004    Last call on bare asymmetric key profile
>>>> Aug 2004    Last call on bound asymmetric key profile
>>>> 
>>>> 
>>>> _______________________________________________
>>>> ietf-enroll mailing list
>>>> ietf-enroll at mit.edu
>>>> https://mailman.mit.edu/mailman/listinfo/ietf-enroll
>>>> 
>>> 
>>> _______________________________________________
>>> ietf-enroll mailing list
>>> ietf-enroll at mit.edu
>>> https://mailman.mit.edu/mailman/listinfo/ietf-enroll
>> 
>> 
> 
> _______________________________________________
> ietf-enroll mailing list
> ietf-enroll at mit.edu
> https://mailman.mit.edu/mailman/listinfo/ietf-enroll
> 
> 

_______________________________________________
ietf-enroll mailing list
ietf-enroll at mit.edu
https://mailman.mit.edu/mailman/listinfo/ietf-enroll