Re: I-D ACTION:draft-ietf-sacred-framework-00.txt

[Magnus Nystrom <magnus@xxxxxxxxxxxxxxx>]

Mike,

Just a few additional remarks.

On Thu, 30 Nov 2000, Dale Gustafson wrote:

[...]
> > Some comments:
> >
> > - [Section 1, 1st para] In motivating the requirement for roaming, it's stated
> > that import/export tools exist, but not for all environments. Another
> > statement worth making here is that the use of such tools is also impractical
> > for the typical user.

Agreed.

[...]
> > - [Section 3.1, 2nd bullet] The requirement for http might be ok, but why
> > require TLS. This gets into the argument that you mention in Section 6,
> > regarding the (de)coupling of the credential and protocol protections. The
> > strong password algorithms of Section 4.2 would not require TLS protection,
> > for example.
> 
> In this draft, we removed a few restrictions that had been suggested earlier --
> originally HTTP over TLS was the only transport considered and was mandantory.
> In this revision HTTP / TLS is not the only possible transport protocol.  We may
> have to refine the wording in several additional places to make
this more clear.

Note also that it only says "must be able to..." - it does not
require TLS. I agree that the memo requires some clarification in
this respect however, e.g. Section 3.1.1, first item in the list
should probably read something like "..., that is, when TLS is used,
only cipher suites..."

[...] 
> > - [Section 5] I think that an important property for the ultimate credential
> > format is that it be extensible. This would support interoperability yet still
> > allow vendors to transport additional, vendor-specific attributes.
> 
> Since the credential is an opaque object, vendors are free to define whatever
> they need.

Yes, but even though it is opaque for the server, it is not opaque
for the client, so in order to ensure interoperability we need to
mandate some credential format. Both PKCS #12 (through the extensible
SecretTypes object set) and PKCS #15 (e.g. through the DataObject
type) are extensible.

> > - [Section 6] Regarding the credential protection, I think that the credential
> > object should be protected, independent of the protection of the transport
> > protocol, though additional protection must also be provided by the transport
> > protocol. The protection of the credentials ensures they need not be in the
> > clear at the credential server, while the transport protection offers
> > increased protection (especially necessary since the credentials themselves
> > will likely be protected by a password-derived key).

Yes, I would tend to agree.

> > - [Section 7, last sentence] For this reason, I think that server
> > authentication needs to be required (as I've also stated above).

If a client authenticating to a credential server (for the purpose of
downloading its credentials) have to reveal information which can be
used by an attacker to get access to the client's credentials, then I
agree. As it will likely be the case that clients do reveal some
information of that kind, I am inclined to strengthen the "SHOULD" to
a "MUST" - but let's revisit this when the actual protocol
implementation is discussed.

-- Magnus

> > > -----Original Message-----
> > > From: Magnus Nystrom [mailto:magnus@xxxxxxxxxxxxxxx]
> > > Sent: Wednesday, November 22, 2000 7:28 AM
> > > To: ietf-sacred@xxxxxxx
> > > Subject: Re: I-D ACTION:draft-ietf-sacred-framework-00.txt
> > >
> > >
> > > Dear Working Group,
> > >
> > > The I-D mentioned above is a first attempt at defining a framework for
> > > sacred -operations, protocol functionality and authentication options.
> > > Several sections are still incomplete, and others will surely be
> > > re-drafted. It is our hope, however, that the draft will
> > > serve both as a
> > > basis for discussions in San Diego (as well as on this
> > > mailing list), and
> > > as a stepping-stone for a better understanding of the
> > > challenges we face.
> > >
> > > -- Magnus & Dale
> > >
> > >  On Wed, 22 Nov 2000 Internet-Drafts@xxxxxxxx
> > > wrote:
> > >
> > > > A New Internet-Draft is available from the on-line
> > > Internet-Drafts directories.
> > > > This draft is a work item of the Securely Available
> > > Credentials Working Group of the IETF.
> > > >
> > > >     Title           : Securely Available Credentials - Framework
> > > >     Author(s)       : D. Gustafson, M. Nystrom
> > > >     Filename        : draft-ietf-sacred-framework-00.txt
> > > >     Pages           : 15
> > > >     Date            : 21-Nov-00
> > > >
> > > > As the number, and more particularly the number of different types,
> > > > of devices, connecting to the Internet increases,
> > > credential mobility
> > > > becomes an issue for IETF standardization. This draft
> > > responds to the
> > > > requirements listed in [SACRED}. It presents a strawman
> > > framework and
> > > > outlines protocols for securely available credentials.
> > > >
> > > > A URL for this Internet-Draft is:
> > > >
> > http://www.ietf.org/internet-drafts/draft-ietf-sacred-framework-00.txt
> > >
> > > Internet-Drafts are also available by anonymous FTP. Login with the username
> >
> > > "anonymous" and a password of your e-mail address. After logging in,
> > > type "cd internet-drafts" and then
> > >       "get draft-ietf-sacred-framework-00.txt".
> > >
> > > A list of Internet-Drafts directories can be found in
> > > http://www.ietf.org/shadow.html
> > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> > >
> > > Internet-Drafts can also be obtained by e-mail.
> > >
> > > Send a message to:
> > >       mailserv@xxxxxxxxx
> > > In the body type:
> > >       "FILE /internet-drafts/draft-ietf-sacred-framework-00.txt".
> > >
> > > NOTE: The mail server at ietf.org can return the document in
> > >       MIME-encoded form by using the "mpack" utility.  To use this
> > >       feature, insert the command "ENCODING mime" before the "FILE"
> > >       command.  To decode the response(s), you will need "munpack" or
> > >       a MIME-compliant mail reader.  Different MIME-compliant mail readers
> > >       exhibit different behavior, especially when dealing with
> > >       "multipart" MIME messages (i.e. documents which have been split
> > >       up into multiple messages), so check your local documentation on
> > >       how to manipulate these messages.
> > >
> > >
> > > Below is the data which will enable a MIME compliant mail reader
> > > implementation to automatically retrieve the ASCII version of the
> > > Internet-Draft.
> > >
> >
> > -- Magnus
> > Magnus Nyström
> > RSA Security
> 
> 

-- Magnus
Magnus Nystrom
RSA Security