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

[Dale Gustafson <dale.gustafson@xxxxxxxx>]

Hi Mike,

Thanks for your comments.  I have responded to several of them -- please see my
comments, inline.

Best Regards,

Dale Gustafson


Mike Just 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.
>
> - [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.

> - [Section 3.1.1, 1st paragraph above the sequence diagram] It is stated that
> "[t]he client MAY provide an additional layer of encryption (as defined by the
> credential format) to ensure the credential is not exposed within the
> credential server or repository."  Is there any good reason to not make this a
> MUST?

We have attempted to define a protocol framework that could accomodate any,
arbitrary (opaque) credential, such as:

 - pkcs#15 software token
 - pkcs#12 key pair / certificate file
 - other

I was trying to indicate that the designers of each credential format have
determined (or will determine) which part of the credential needs to be
encrypted.

> - [Section 3.1.2, 2nd bullet] It is stated that "TLS server authentication
> SHOULD be used to authenticate the server."  I think that this is fine, so
> long as we also include something like "Server authentication MUST be used to
> authenticate the server."  Therefore server authentication MUST be used; how
> it is performed depends on the protocol.

Please see earlier comment re: HTTP / TLS is an optional transport layer.  If
anyone disagrees with this choice please speak up.

> - [Section 3.1.4, 4th bullet] Where you say "change password", do you mean the
> password protecting the object containing the credentials or the password used
> for authentication to the server? It is worth splitting these cases up, even
> though it may be that the same password is used to derive the key used to
> protect the credentials and the key used to authenticate to the server.

I mean the password used by the server to authenticate the credential user.

Since the credential is opaque, the server has no inherent capability to decrypt
the credential.

> - [Section 4, end of 2nd paragraph] It is stated that "the user authentication
> method/data may be updated from time to time thereafter by the authorized
> user." Although the user is more suited to update the data, wouldn't an
> administrator be the right person for updating the method?

We assume all devices are not able to support all user authentication methods.
We thought about protecting a single credential with more than one
authentication method / data so the credential could easily be used with
different devices.  This issue needs further consideration.

I think we have assumed throughout that the administrator is not an authorized
user of the credential.

An administrator may need to have some control over which authentication method
or methods are allowed to be used with a given credential but that may be more
an implemention issue for the server application builder.

> - [Section 4.2, 3rd paragraph] The Ford-Kaliski comment (if kept) is equally
> applicable to the OTP schemes in section 4.1 (and any other password-based
> scheme) so that it might be better placed outside of Section 4.2.

> - [Section 4.3] Is this only being considered for the PUT and DELETE
> operations (as opposed to GET) since the goal of this WG is to provide a
> protocol to retrieve such credentials (i.e. chicken-egg problem)?

No.  Download of the first / only credential to a particular device cannot be
done using HTTP over TLS.

Download of credentials 2 - N using HTTP / TLS is possible.

> - [Section 4.4, 4th bullet] I was a little unclear with this paragraph. Does
> this exclude the case where a different key is used for credential protection
> than for authentication even though such keys might be generated from the same
> password?

If it's easy for someone who steals a password verifier from the server to
determine the authentication password (via simple dictionary attack).  And if
that derived password can then be used to both download some else's credential
and decrypt and use that credential, then yes, that's what we want to preclude.

> - [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.

> - [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).

> - [Section 7, last sentence] For this reason, I think that server
> authentication needs to be required (as I've also stated above).
>
> Cheers,
> Mike J.
>
> > -----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