[ietf-enroll] Charter

Wed May 28 18:04:55 EDT 2003

SACRED depends on enrollment to establish trust between the device and the
credential server. (Either some direct enrollment or via an existing PKI
or whatever).

ENROLL provides the functionality for that enrollment.

Personally I like the term INTRODUCTION instead of 'enrollment' because it
clarifies this conversation: This group provides INTRODUCTION so that
device can enroll to obtain credentials. SACRED provides mechanisms for
moving credentials between devices.

	- Max

On Wed, 28 May 2003, Trevor Freeman wrote:

> I cannot speak for Russ, but the charter does not mention roaming
> credentials, only enrolling.
> Trevor
>
> -----Original Message-----
> From: Alper Yegin [mailto:alper at docomolabs-usa.com]
> Sent: Wednesday, May 28, 2003 11:37 AM
> To: Trevor Freeman; Russ Housley; jimsch at exmsft.com; IETF-Enroll
> Subject: Re: [ietf-enroll] Charter
>
>
> > 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?
>
> This does not sound like how Russ describes Enroll:
>
> "SACRED is about credential portability.  ENROLL is about getting the
> credential in the first place."
>
> Your example is not about my device getting the credentials in the first
> place, it is about my device using its existing credentials to access a
> service.
>
>
> Alper
>
>
> > 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
> >
> >
>
>
> _______________________________________________
> ietf-enroll mailing list
> ietf-enroll at mit.edu
> https://mailman.mit.edu/mailman/listinfo/ietf-enroll
>