Dale,
Thanks for your responses. Magnus' responses answer some of my follow-ups. I have a few additional comments below.
> -----Original Message-----
> From: Dale Gustafson [mailto:dale.gustafson@xxxxxxxx]
> Sent: Thursday, November 30, 2000 12:20 PM
> To: Mike Just
> Cc: 'Magnus Nystrom'; ietf-sacred@xxxxxxx; Stephen Farrell
> Subject: Re: I-D ACTION:draft-ietf-sacred-framework-00.txt
>
<.....snip.....>
> > - [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.
>
[MJ] True. The administrator has no need to know or modify the authentication data.
> 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.
>
[MJ] It might be. I'm sure it'll be clearer to me once we start discussing some more authentication methods and protocols. I was primarily thinking of security policy enforcement by the administrator in environments where only certain authentication methods might be permitted.
> > - [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.
>
[MJ] I guess that I hadn't thought of this. It sounds a little odd to me (one credential would always have to be retrieved before obtaining some set of remaining credentials) but that's no reason to exclude it :-)
> > - [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.
>
[MJ] I wouldn't want to preclude this model if it means requiring a user to remember two different passwords.
Mike J.