2.6.10 Securely Available Credentials (sacred)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 23-Oct-00


Stephen Farrell <stephen.farrell@baltimore.ie>
Magnus Nystrom <magnus@rsasecurity.com>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>

Security Area Advisor:

Marcus Leech <mleech@nortelnetworks.com>

Mailing Lists:

General Discussion:ietf-sacred@imc.org
To Subscribe: ietf-sacred-request@imc.org
In Body: (un)subscribe
Archive: http://www.imc.org/ietf-sacred/mail-archive/

Description of Working Group:

The credentials used in a public key infrastructure (PKI) typically consist of a public/private key pair, a corresponding certificate or certificate chain and some trust or root certification authority information. They are usually stored on a desktop or laptop system as part of an application specific store. Currently, support for credential export/import is uneven and end users need to get too involved with the mechanics of creating and maintaining their PKI credentials.

Application specific stores also mean that users cannot easily use the same credential in multiple applications or on multiple devices. In effect, today, credentials aren't portable. PKIs that use hardware tokens (e.g., smart cards, PCMCIA cards) do allow for portability of the user's credentials, however, most systems do not use hardware tokens, but would benefit if similar portability features were available. Ideally, users would be able to use a common set of credentials with their desktop and laptop PCs, PDAs, cell phones, and other Internet-ready devices. Even where hardware tokens are used, there may also be substantial benefit derived from using credential portability protocols in support of management functions such as, for example, installation, token recovery (e.g. locked PIN), or token replacement.

There are at least two possible solutions for providing credential portability. The first involves the use of a "credential server". Credentials are uploaded to the server by one device (e.g., a desktop computer); they can be stored there and downloaded when needed by the same or a different device (e.g., a mobile phone, PDA, or laptop computer).

A second solution involves the "direct" transfer of credentials from one device to another (e.g., from a mobile phone to a PDA). Although there may be servers involved in the transfer, in security terms the transfer is direct - that is, there is no "credential server" that takes an active part in securing the exchanges.

While it might be possible that a single protocol can be developed for both types of solution, two different protocols may be needed: one for interacting with a "credential server"; and the other to facilitate the "direct" transfer of credentials.

Security is at a premium for this working group; only authorized clients should be allowed to download credentials; credentials must be protected against eavesdropping and active attacks; attackers must not be able to successfully replace an entity's credentials at a credential server; etc. In general, the security provided by such systems will be less than is provided in systems using hardware tokens, as the hardware tokens tend to be more resistant to improper inspection and modification. However, in many environments, the security offered will be sufficient.

Availability is also at a premium. Credentials must be available to many different types of client with different characteristics in terms of processing power, storage and network connectivity.

The working group will produce:

1) An informational document(s) describing and identifying the detailed requirements for any protocol in this area, along with an architectural view of any such protocol.

2) A standards-track document(s) describing the details of the adopted or developed protocol.

The WG will specifically take into account the requirements of the IPSRA WG, and the protocols selected by this WG should provide a solution for a subset of those requirements.

Goals and Milestones:

Oct 00


Submit first draft of Requirements document

Nov 00


Submit first draft of Frameworks document

Dec 00


Submit second draft of Requirements document

Dec 00


Submit second draft of Frameworks document

Dec 00


Submit first draft of Protocol document (incl. PDU syntax)

Mar 01


Requirements document to Informational RFC

Mar 01


Frameworks document to Informational RFC

Mar 01


Frameworks document to Informational RFC. Submit second draft of Protocol document

Jun 01


Protocol document to Proposed Standard


No Request For Comments

Current Meeting Report

SACRED WG, Thursday, 14 December 2000, 147 attendees.


1. Introduction, Agenda walkthrough and Working Group Status (5 min) WG Chairs
2. Requirements Draft discussion (35 min) A. Arsenault
3. Framework Draft discussion (30 min) D. Gustafsson
4. Desirable properties for strong password-based credentials download protocols (15 min) R. Perlman
5. Authentication methods, actual protocol and credential formats - proposals and discussion (30 min) All - led by chairs
6. Wrap up (5 min) WG Chairs

Documents which will be discussed under agenda item 2 and 3 are:


For agenda item 4 and 5, attendees are recommended to read RFC 2945.

Minutes collected by John Linn (RSA Laboratories).


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


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?]


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.


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.


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.


SACRED Requirements Document
Protocol Framework, Draft Specification
Credentials Download