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

From: Magnus Nystrom <[email-masked]>
Date: Fri, 1 Dec 2000 11:04:56 +0000 (GMT Standard Time)

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:[email-masked]]
> > > Sent: Wednesday, November 22, 2000 7:28 AM
> > > To: [email-masked]
> > > 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 [email-masked]
> > > 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:
> > >       [email-masked].
> > > 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

---

From: Mike Just <[email-masked]>
Date: Fri, 1 Dec 2000 08:24:46 -0500

Magnus,

Just two comments below.  Thanks for your responses.

> Sent: Friday, December 01, 2000 6:05 AM
> To: Mike Just
> Cc: [email-masked]

<.....snip.....>

> > have to refine the wording in several additional places to makethis more
clear.
> should probably read something like "..., that is, when TLS is used,

[MJ] I guess that "requiring" and "being able to" aren't that different to
me. Your rewording sounds fine in any case.

<.....snip.....>

> implementation is discussed.

[MJ] I sounds like we're on the same page. My thinking was that if I were
able to successfully authenticate to a server to obtain only your protected
credentials and it were completely infeasible for me to obtain your
credentials from these protected credentials, then there's probably no
reason to have authentication to the server in the first place. I don't
think this is the case, hence the requirement for server authentication.   

Mike J.

---

From: Mike Just <[email-masked]>
Date: Fri, 1 Dec 2000 08:24:57 -0500

Dale,

Thanks for your responses.  Magnus' responses answer some of my follow-ups.
I have a few additional comments below. 

> From: Dale Gustafson [mailto:[email-masked]]
> Sent: Thursday, November 30, 2000 12:20 PM
> To: Mike Just
> Cc: 'Magnus Nystrom'; [email-masked]; Stephen Farrell

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