final minutes...

[Stephen Farrell <stephen.farrell@xxxxxxxxxxxx>]

Hi & happy new year all,

No corrections having been received these are now the final
minutes for the San Diego meeting.

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@xxxxxxxxxxxx
Ireland                             http://www.baltimore.com


SACRED WG, Thursday, 14 December 2000, 147 attendees.
Minutes collected by John Linn (RSA Laboratories).

INTRODUCTION

Stephen Farrell (Baltimore) opened the meeting, which was the group's first
meeting as a WG. SACRED WG contact information is available on the IETF web
page. Co-chair Magnus Nystrom (RSA Security) was unavailable for the meeting
because of a schedule conflict. Stephen outlined the following WG goals
intended between now and the next meeting: get the requirements document
suitable for WG Last-Call, and issue a next-to-last draft for the framework
document. Before/during/after next meeting, intended work items include
candidate protocol drafts and selection of standards track protocol(s).

REQUIREMENTS DRAFT

Stephen led a discussion on the requirements draft
(draft-ietf-sacred-reqs-00.txt), which he co-authored with Al Arsenault
(Diversinet), who was not available at this meeting.  The overall goal is to
develop one or more solutions that allow for secure transfer of credentials
from one device to another.  Credentials can include private keys, trusted
root keys, etc.  Solutions must fit a defined protocol framework and a
common set of requirements agreed to by the WG.  Stephen emphasized that
more active document review and discussion on the list is needed. Many
attendees indicated that they had read at least one of the current drafts.

It had been noted around the time of the SACRED BOF held at the Pittsburgh
IETF that both credential server and direct transfer scenarios were valid.
The WG charter seeks to provide solutions for both scenarios, with either
one or two distinct approaches, and the requirements draft discusses their
respective advantages and disadvantages. Little attention has recently been
paid to the direct transfer approach; Stephen solicited proponents to
contribute material in this area.  Absent such contributions, it may be
deferred.

Specific requirements follow.  Note: the requirements as recorded in these
minutes are briefly paraphrased.  See draft-ietf-sacred-reqs-00 for full
texts.

Proposed requirements on framework:
*       MUST support both server and direct approaches
*       Server and direct SHOULD use same technology as far as possible
*       MUST allow for protocols which support different user authentication
schemes
*       Protocol MUST NOT depend on internal structure of any credential
type of format. Regarding this requirement, Stephen believed, in response to
a query from John Linn (RSA Laboratories), that it means that protocol
characteristics shouldn't vary based on a credential's own protection even
if some of the cryptographic layers applied within the protocol may be
redundant.  This continues a discussion on the list, which hasn't yet
reached closure.  Bob Morgan (U. Washington) interpreted the position as
stating that the protocol must assume credential elements to be highly
sensitive and themselves wholly unprotected.
*       MUST allow use of different transports

A general issue was identified regarding the vulnerabilities list: should it
stay? Should more items be added?  General protocol requirements were
identified as follows:
*       Transfer both to and from a device MUST be supported
*       Credentials MUST never be present in cleartext at any device other
than the end user's. Comment: "end user device" needs clear definition. Bob
Moskowitz (ICSA) commented that this is out of scope as a protocol
requirement per se, but it was agreed that characteristics of the protocol
shouldn't, e.g., force credentials to be stored in cleartext on the server.
*       Transferred credentials SHOULD be authenticated in some way
*       Transferred credentials MUST be integrity protected in some way
*       Protocol MUST support a range of crypto algorithms
*       Protocol MUST support various credential types and formats (e.g.,
X.509, PGP, PKCS #12). John Linn and Eric Rescorla (RTFM) commented that the
protocol isn't "supporting" opaque objects in a strong sense, except to the
extent of tagging their types.  Perhaps the requirement should be restated
to "allow", Stephen suggests? This could be an end entity support
requirement, but not really one imposed on the protocol per se.
*       One mandatory to support credential format MUST be defined
*       One mandatory to support user authentication scheme MUST be defined
*       Credentials MAY be labeled with a text handle to allow the end user
to select amongst a set of credentials or to name a particular credential.
*       Full I18N support is required.
*       Protocol MUST be able to support privacy (anonymity) for the client.
Eric Rescorla was skeptical that this can be feasibly and comprehensively
accomplished.  Radia Perlman (Sun) asked whether it could be sufficient to
do an anonymous Diffie-Hellman exchange before sending identity information,
even though this wouldn't be secure against an active attacker?
*       Transferred credentials MAY incorporate timing information, e.g., a
time-to-live value determining the maximum time usable following
transfer/download.

Credential server protocol requirements:
·       Downloads and uploads MUST be supported
*       Credentials MUST only be downloadable following user authentication.
Radia Perlman asked whether a not-yet confirmed partial authentication
operation would be sufficient.
*       MUST be possible to ensure authenticity of credential during upload
*       Different user devices MAY be used to upload/download/manage the
same set of credentials
*       Credential server MUST NOT have easy access to the cleartext
credentials. Comment: given prior requirements, how can any cleartext
access, whether easy or not, be allowed?  Phill Hallam-Baker (VeriSign)
observed that this isn't appropriately framed as a protocol requirement per
se, but that it is important that characteristics of the protocol not imply
that cleartext storage must be required at participating peers. Steve
Bellovin (AT&T Research) pointed out that there may be an operational need
for some mechanism, duly authenticated and authorized, to allow override;
this may imply need for an additional requirement.
*       Credential servers MUST be authenticated to the user for all
operations except (possibly) download
*       MUST be possible to authenticate the credential server to user prior
to download, if the user is capable of verifying the authentication
*       User SHOULD only have to enter a single secret
*       Sharing of secrets across multiple servers MUST be possible.
*       MUST support "away-from-home" roaming operation to remote domains,
enabling domain-based location of appropriate remote credential server. Bob
Morgan commented that designs should seek consistency with existing service
location approaches.
*       Users MUST be able to manage their credentials stored on the
credential server (comment: protocol must support, but users, vs.
administrators, may not necessarily be permitted to perform management
operations.)
*       Users MUST be able to retrieve a list of their credentials stored on
a server, add credentials to the server, delete credentials from the server
(same comment as on previous bullet)
*       Client-initiated authentication information change MUST be supported
*       User SHOULD be able to retrieve a list of access/changes to
credentials
*       Protocol MUST support user self-enrollment
*       Protocol MUST NOT prevent bulk initialization of a credential
server's repository.
*       Additional desired requirement (Charlie Kaufman (Iris)): no
pre-configuration of cryptographic information on client.  Eric Rescorla
concurs.
*
*       Direct transfer requirements:
*       SHOULD be possible to authenticate
*       SHOULD be possible for acceptance to be acknowledged
*
*       Open issues:
*       Vulnerabilities
*       Robustness
*       Performance
*       Bootstrapping
*       Separation or not of: user authentication, credential protection, [!
There was another element in this bullet, as I recall. What was it?]

FRAMEWORK DRAFT

Next, Dale Gustafson (Future Foundation) led a discussion on the SACRED
framework draft. This document presents an abstraction of SACRED protocol,
leaving open authentication and key management schemes, credential
format(s), and bindings/transports. Dale's discussion:
*       Introduction: Credentials may be used and shared among a variety of
clients, in either client-server or peer-peer exchanges. Credential format
is currently open, but PKCS #12 and PKCS #15 are cited as candidates. .
There is intent to support several authentication methods and credential
formats, with one of each specified as mandatory.
*       Network Architectures: Dale presented an overview of the
client-server model and possible protocol flow diagrams for operations.
Three basic operations (GET, PUT, DELETE) were proposed.
*       Authentication methods: Candidates include username/password, OTP,
strong password, and HTTP over TLS (for server authentication, or also to
authenticate remote clients).  Eric Rescorla pointed out that other
functional requirements imply that, if TLS is used, at least server side
authentication is needed.  John Linn observed, following on list discussion,
that this implies that a trusted root key must be held before the TLS
connection is established; therefore, the trusted root key cannot be
transferred as part of credentials downloaded over that connection.
*
*       The following open issues were identified for the framework draft:
*       Peer-Peer protocol
*       Should user authentication method and data be linked to a specific
credential or to a user's identity, thereby applying to all of that user's
credentials?
*       Is the proposed set of operations sufficient?
*       Credential format(s) selection
*       Authentication method(s) selection.

Charlie Kaufman observed an apparent collision among assumptions. Some
participants are trying to solve the initial bootstrap operation problem,
and others are assuming that existing configuration data exists and can be
leveraged.  He suggested that perhaps a simple protocol could be defined to
obtain the trusted roots, then to take advantage of them for other
operations in a subsequent phase.   Stephen thought that these cases would
both be handled in one protocol, and that it would ordinarily be appropriate
to take advantage of configured data whenever available.  Charlie asserted
that a single approach wouldn't necessarily be effective and appropriate for
all scenarios. Steve Bellovin thought that a 2-phase or 3-phase protocol
might be needed in many cases. It was also noted that documentation of
operational scenarios would provide useful clarification.

PASSWORD-BASED CREDENTIALS DOWNLOAD AND PDM

Next, Radia Perlman gave a presentation on desirable properties for strong
password-based credentials download, drawing on work with Charlie Kaufman
and Eric Rescorla. The proposal is documented in
draft-perlman-strong-cred-00.txt; this is not currently cited as a SACRED WG
document but can become one at a later date.  Issues raised in Radia's
discussion:

*       Why use strong password protocols?  They're cheaper and more
convenient than smart cards. They also avoid problems with reliance on trust
anchors for server authentication, and reduce the need for users to rely on
a browser's UI to indicate when connections are secured.
*       Mutual authentication vs. credential download protocols: Many strong
password protocols have features that are unnecessary for credential
download (authentication, avoidance of PW-equivalent storage at server).  A
protocol specifically oriented to credential download protocol can be
stateless for servers. Radia cited the following as desired properties for
credential download protocols: secure; unencumbered; stateless for server;
low computation for server; few messages; good enough performance at client;
no cryptographic configuration at client
*       Performance: Radia argued that server performance is the primary
concern, as long as a client's performance level is acceptable for a
once-per-session operation.
*       Since last meeting, the name PDM (Password Derived Moduli) was
chosen for the proposed approach. Also, investigation clarified that
protocols like SRP, which were designed for mutual authentication have
various undesired properties including statefulness. The PDM technique
involves the following steps: have a deterministic method to derive a safe
(Sophie-Germaine) prime p from a password; store p and a user's credentials
at a server; store also B and 2**B mod p; do Diffie-Hellman using 2 as base,
mod p.  To speed up the client side, tell the user a single character hint,
which is 6 bits of p.  The following results were obtained for generating
safe primes on a Pentium II/400: mean values for 512-bit modulus: 8 secs
without hint, .11 sec with a hint; 1024-bit modulus: 111 secs. without hint,
1.8 with hint.
*       Work had been undertaken with Tom Wu on a new S3P-RSA protocol with
good client performance, but the approach proved to be broken.
*       Radia discussed several FAQs about PDM.  PDM is not intended for
"wimpy devices like PDAs", which ordinarily travel with a person and can
therefore appropriately be configured with a strong secret for that person.
The generated hint is different from a longer password because it's
machine-supplied and can be forgotten without loss of access, but at the
cost of some more processing time. As an additional performance enhancement,
Radia considered it likely that with PDM, a Diffie-Hellman exchange can
safely use a smaller modulus given the use of secret moduli; each PW guess
would effectively require breaking Diffie-Hellman. It's notable that PDM
requires one exponentiation operation at the server, while the best known
mutual authentication protocols (SRP) require at least 2.  In conclusion,
she summarized that PDM is unencumbered to the authors' knowledge, offers
acceptable performance at the client, and good performance at the server.
Radia was asked whether PDM would just be used for download, rather than
other operations.  She thought this was probably the case with other,
harder, operations being better performed from more richly
configuration-equipped clients.  In any case, though, it is necessary for
users to take care in choosing and trusting the machines where their
credentials become available.
*       In subsequent discussion about possible approaches, Radia expressed
concern about multi-server approaches' operational characteristics, in terms
of delay and availability impacts.  With regard to TLS authentication, it
was suggested that anonymous TLS could be used, with another scheme (e.g.,
SRP or other strong password protocol) then applied to authenticate the TLS
finish message.

CLOSING REMARKS

In closing discussion, Stephen asked attendees whether anyone wished to
write proposals for additional authentication protocols or credential
formats.  None were suggested.  A volunteer offered to draft some material
on operational scenarios.