Re: DRAFT minutes, SACRED WG San Diego meeting

[Stephen Farrell <stephen.farrell@xxxxxxxxxxxx>]

Thanks again for taking such good minutes John. If anyone has any
corrections, please post them in the next two days.

Stephen.

"Linn, John" wrote:
> 
> SACRED WG, Thursday, 14 December 2000
> DRAFT 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.

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