NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Stephen Farrell <stephen.farrell@baltimore.ie>
Magnus Nystrom <magnus@rsasecurity.com>
Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>
Marcus Leech <mleech@nortelnetworks.com>
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/
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.
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 |
Minutes, SACRED WG, Minneapolis IETF
Collected by John Linn (RSA Laboratories)
Magnus Nystrom (RSA Security) and Stephen Farrell (Baltimore), WG co-chairs, led the Minneapolis IETF SACRED session.
Opening status summary: Relative to posted milestones, the SACRED WG is currently running about 2 months late. An -01 version of the requirements Internet-Draft was submitted in January, and an -00 version of the scenarios document in February. An -01 version of the framework document has also been submitted. Stated meeting goals included the following: move the requirements document to WG Last-Call, review the framework document, and discuss specific identified technical topics.
Al Arsenault (Diversinet) led discussion on the requirements draft, which he had coauthored with Stephen Farrell. An -00 version had been posted last fall, and was discussed at the San Diego meeting and in follow-up comments. The -01 version is now available, and is intended to be responsive to the comments received. Changes clarified the overall scope of the effort, tightened requirement wording (e.g., protocol requirements are now confined more tightly to protocol issues), removed internal comments, and enhanced the security considerations section. Protocol requirements discussion includes vulnerability examples, general protocol requirements, and requirements that are specific to server-based vs. direct transfer cases. RL Bob Morgan (U. Washington) stated that he had contributed to instigating the scenarios document based on experience with operational requirements, though was not its author, and solicited review and comments on its content. It was agreed that the material from the scenarios document should be considered for integration into the requirements document. Next steps on requirements document: consider adding scenarios from scenarios document, create a -02 version and have WG last call, consider the result for publication as an Informational RFC.
Dale Gustafson (Future Foundation) led discussion on the SACRED framework draft. It provides a high level description of the architecture and protocols intended to be used to exchange secured credentials. Three basic operations (Get, put, and delete) are defined, with credentials treated as opaque objects with user-specified format. Issues that had been discussed at the San Diego meeting included: peer-peer protocol, user/password/credential organization, sufficiency of GET-PUT-DELETE operations, credential format(s) selection, authentication method(s) selection.
Changes in the -01 version include split-off of peer-peer case, addedclarifications, and a provision that the user may have one or more credentials, each with friendly names. An -01 draft, co-authored with Mike Just (Entrust) and Magnus, was posed on March 6th. Comments on it are being awaited, but none have so far been received. The intent is to initiate WG L-C on a subsequent version by/at the London IETF. Contemplated changes for the -02 version include additional credential management operations like user registration, de-registration, password change, listing of credentials. Key open issues are considered to be: credential formats, mutual authentication methods, and transport protocols. Magnus believes that these can be appropriately specified in a separate document, and considers that the framework document as it stands is appropriately scoped. It was agreed that more review and discussion is needed on the content and proposed changes to the framework, so preparation and discussion of at least one more version following the -02 draft is currently anticipated before WG Last-Call.
Magnus led a discussion on three key open issues: protocol, authentication mechanisms, and credential formats.
Re protocol alternatives, the SACRED protocol is intended to carry both credentials themselves and SACRED-level control information. Magnus proposed that the WG should select one protocol with mandatory-to-implement (MTI) status, but noted that additional choices could be defined separately and used as alternatives. He presented a table comparing several alternatives in terms of three criteria: available client support (CL), firewall traversal capabilities (FW), and ability for SACRED to usefully leverage features within the protocol (LV). His summarized results were as follows:
UDP: CL: Very good; FW: Less; LV: None
TCP: CL: Good; FW: depends; LV: very little
HTTP: CL: Good; FW: good; LV: good
BEEP: CL: None; FW: less; LV: very good
SOAP/SyncML: CL: Little; FW: ?; LV: ?
John Noerenberg (Qualcomm) commented that application area WGs are currently exhibiting tremendous interest in BEEP, and that he therefore expects BEEP support to grow quickly. An attendee asked whether SMTP would be another appropriate candidate; it was suggested that this might be considered, but not as the MTI selection. Regarding HTTP, Ted Ts'o (VA Linux) cited a prior IESG RFC deprecating layering on HTTP. Steve Bellovin (AT&T Research), who was a coauthor of that document, said that its point was primarily to deprecate HTTP as a generalized firewall penetration scheme, and observed that HTTP might in fact be a good and appropriate choice for the SACRED application. Stephen Farrell suggested that BEEP-formatted tokens might be transferred using HTTP and/or SASL. RL Bob Morgan asserted that the ability to leverage security frameworks like SASL should be an important criterion. Another attendee argued that SACRED should be transport-independent, as an arbitrary range of applications might want to consume and integrate it within their messages. In support of this prospect, it was recommended that extensive support services (e.g., such as those provided by BEEP) not be assumed within SACRED's transports. Stephen Farrell considers that XML is the primary candidate for payload definition. A straw poll was taken among the protocol alternatives, but its results were inconclusive. The question is to be reconsidered on the mailing list.
Regarding authentication schemes, one key question whether the protocol should be self-contained for security purposes or should instead be layered, e.g., on TLS. Discussion in the session emphasized self-contained alternatives. It was noted that most TLS usage cases require client foreknowledge of trusted root keys, though some ciphersuites (e.g., SRP, Kerberos) have been defined which do not require certificates. Intellectual property right (IPR) issues are another concern.
Magnus presented a table comparing the alternatives relative to four metrics: client CPU requirements, number of communications roundtrips, level of security, and ease of implementation. Each of DH-EKE, SPEKE, and SRP were considered as neutral in terms of all of these areas. In discussion, PDM was considered weaker in terms of client CPU requirements, but better in terms of server CPU requirements than EKE, SPEKE, or SRP, assuming use of a shorter modulus for PDM. PDM can be done in one round trip with stateless server operation, whereas SRP and the versions of EKE and SPEKE augmented not to require storing password-equivalent data at the server require two roundtrips. Radia Perlman (Sun) argued that this additional overhead was unnecessary for the SACRED application. OTP was considered stronger in terms of client CPU requirements, numbers of roundtrips, and ease of implementation, but weaker in security.
Stephen Farrell asked whether the WG should concentrate on one of the EKE, SPEKE, SRP, or PDM schemes, or should instead instead emphasize OTP schemes, noting that (unlike the other approaches) OTP doesn't generate a key or authenticate the server. Tim Polk (NIST) commented that it didn't appear that requirements had been agreed sufficiently to support selection of an algorithm. A straw poll was taken on algorithm selection, but its results were inconclusive. The question will be revisited on the mailing list.
Next, IPR issues were considered. Magnus noted that an IPR statement for SRP has been posted on the IETF web page. Ted Ts'o commented that the SRP statement, authored by Thomas Wu, seems rather informal, and considered that it might be better to have something authoritative from Stanford. Thomas Wu responded, indicating that the terms as posted can be documented as Stanford's policy. Radia Perlman and Charlie Kaufman (Iris) have previously stated their goal and intent that PRM be unencumbered. Steve Bellovin stated that EKE and DH-EKE are covered by a Lucent-controlled patent; he has no contact or influence with those responsible for licensing, but believes that licensing under some terms would probably be possible. Steve commented that he had heard various claims regarding the applicability of the EKE patent to other strong password techniques like SRP, but declined to involve himself personally in the matter. Ted Ts'o pointed out that the fact of IPR claims covering SPEKE is generally known.
Next, Magnus compared candidate credential formats, in terms of current support (CS), ability for effective leverage by SACRED (LV) and flexibility (FL). The summarized results were as follows:
PKCS #12++: CS: None; LV: None; FL: OK
PKCS#12 (Today's) + PKCS #7: CS: Good; LV: Yes; FL: Less
PKCS#15: CS: Little; LV: Yes; FL: Yes
OpenPGP: CS: Good; LV: Less; FL: Less
John Noerenberg chairs the OpenPGP WG, and believed that this summary understates OPGP's capabilities. He noted that OPGP is designed to be compact and flexible for support of multiple algorithms. Bob Moskowitz (ICSA) observed that different communities may require different formats for compatibility with their technology bases. A straw poll was taken on format choices: its results were inconclusive, and the discussion was deferred to the mailing list.
Nada Cicovic (Entegrity) gave a presentation entitled "Contents of PSE - Certificate Enrollment and Lifecycle." The work derives from PKI Forum's CMP interoperability testing work, and an associated document has been circulated within the PKI Forum. It seeks to standardize representations for a range of information, including: RA/CA details (address, transport protocol, registration protocol); shared secrets used for authentication; allowed/required fields in enrollment certificate template; EE naming information as registered by the RA/CA; RA/CA supported key types; key sizes and usages; and designators for EE vs. CA-performed key generation. The motivations considered for standardization are to enable interoperability between PKI clients and RA/CAs from different vendors, to boost deployment of CMP/CMC, and to enable smooth certificate enrollment, renewal and registration. A question was raised as to whether SACRED was the appropriate forum to pursue the topic. Nada believed that it falls on the line between PKIX and SACRED; as it's PSE information, she stated that PKIX representatives thought it would be more appropriately considered in SACRED. Additionally or alternatively, Nada suggests that it might be considered in PKCS #15. Magnus pointed out that the topic will probably also be raised at the PKCS Forum session which will be convened at the April RSA Conference. Stephen suggested that Nada make materials available for review within the SACRED WG.
A proposed schedule was presented for upcoming SACRED milestones:
March: requirements I-D to WG Last-Call
April: framework -02 I-D
April: protocol -00 I-D
June: framework I-D (-03) to WG Last-Call
Nov: revised protocol I-D to WG Last-Call?
Radia Perlman gave a brief overview of the operation of cryptographic protocols such as EKE and SPEKE, which perform password-modified Diffie-Hellman exchanges. Each modifies the Diffie-Hellman exchange in a different way.
Magnus closed the session, encouraging continuing discussions on the mailing list before the next planned meeting at the London IETF.
Agenda
Sacred Overview
Contents of PSE - Certificate Enrollment and Lifecycle
SACRED - Protocol Discussion
Sacred Requirements