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