Securely Available Credentials (sacred) Charter

2.5.9 Securely Available Credentials (sacred)

NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date. Last Modified: 06-Mar-02

Chair(s):

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:

Done		Submit first draft of Requirements document
Done		Submit first draft of Frameworks document
Done		Submit second draft of Requirements document
Done		Submit second draft of Frameworks document
Done		Submit first draft of Protocol document (incl. PDU syntax)
Done		Requirements document to Informational RFC
Mar 01		Frameworks document to Informational RFC
Done		Submit second draft of Protocol document
Jun 01		Protocol document to Proposed Standard

Internet-Drafts:

Request For Comments:

RFC	Status	Title

RFC3157		Securely Available Credentials - Requirements

Current Meeting Report

Meeting minutes - SACRED Working Group meeting, 53rd IETF, Minneapolis, MN

Meeting Chair: Magnus Nyström, RSA Security. (Co-chair Stephen Farrell missed the meeting for personal reasons.)

Magnus started the meeting by going over the agenda, which was as follows:

Introduction, agenda walkthrough, WG status - Magnus Nyström

Framework draft - Dale Gustafson

Protocol draft - Merlin Hughes

Updated milestones - Magnus Nyström

All Other Business

Since there were no objections to the proposed agenda, Magnus started with the WG status. He began by reviewing the objectives of this working group, and the objectives of this session. He then summarized the WG status as follows:

There are 2 I-D’s: the Framework ID; the current version is version -03, which was submitted in February; and the protocol I-D. The current version of that is version -02, which was also submitted in February.

Dale Gustafson then spoke on the Framework draft, which is co-authored by himself, Mike Just, and Magnus Nyström. Dale started by reviewing the SACRED Network architecture. He noted that the purpose of the architecture is to allow credentials to be uploaded or downloaded into a variety of devices. The WG’s job is to define a protocol between end-user device and credential server. Management/administration of credential server is beyond the scope of this WG’s charter.

Dale then summarized comments from the SACRED mailing list on previous drafts of the framework document. There were lots of comments in the August - December timeframe, so the authors went through list archives for comments that apply to the framework draft. They also harmonized the framework draft with the latest SACRED protocol draft.

Draft -03 was posted to the mailing list March 4th and again on March 6th (it was the same version). The most important change from draft -02 is the reordering of several document sections. The authors are waiting for comments from WG members to be posted on the mailing list.

Issues remaining on the Framework document include:

- ID/fingerprint: the framework document was updated to use ID/fingerprint for all conditional operations (per recent list discussion), but the latest protocol draft uses the "last update" method. Should the authors change the framework document to match the protocol document, or leave it as is?

- Security considerations section: the authors would like to ask mailing list members to review this section, and determine whether or not it is complete.

Dale then summarized plans for draft-04. The authors expect minimal or no changes for this document going forward. They will put out a revised draft soon, and expect WG last call in May 2002.

Merlin Hughes then summarized the Protocol document, written by Stephen Farrell. Version -02 is current. Merlin summarized the changes from the -01 draft. He then identified the issues that are still open. These include:

- the "multiple substrates" issue;

- the SASL authorization identity issue;

- should we apply for a port number;

- should the DTD or the schema be considered normative;

- fix the DTD extensibility scheme;

- should we specify a max value where "unbounded" is in the schema.

Multiple substrates issue: this relates to how the protocol should be defined, and whether it should be bound tightly to a single lower-layer protocol stack, or left open for implementation on top of a variety of protocol stacks/transport mechanisms. There was lots of discussion of this issue on the list, and at the Salt Lake City IETF meeting, but no clear consensus. Currently, the document defines the bindings for the SACRED protocol to run over BEEP. Since there was no clear consensus to change this, it was decided to leave the protocol the way it is. Anyone who wants to modify the protocol to run over some other transport service will have to do the work himself. Magnus Nyström asked whether the WG felt that the protocol document should be left the way it is, with the PDUs, bindings, and protocol spec all in the same document; or would it be better to split the protocol into two documents, with the PDUs and bindings in a separate document, to make later implementation of the protocol on another transport easier. The WG consensus was to leave it as a single document.

SASL authorization identity issue: the document does not address this at this moment. Bob Morgan suggested that this be modified to explicitly state that this is undefined. That is now legal under the SASL document. There was consensus to do this; Bob was asked to provide words for the document.

Applying for a port number: There was consensus that the WG needs to apply for a port number for its protocol. It was also pointed out that it might be appropriate to register a service name and/or a URI, as SASL requires that all protocols making use of it have a registered GSSAPI service name. It was agreed that we ought to register a service name.

DTD or schema being normative: The WG seemed to favor having the schema be normative, and drop the DTD.

DTD Extensibility scheme: Stephen has agreed to fix this in the next draft; there was no further discussion.

Specifying a max value: The consensus of the group was to leave this as "unbounded".

Merlin stated that Stephen’s plan is as follows: once the meeting minutes from this meeting are published, a summary of issue resolutions will be sent to the list. Then, Stephen will wait a week, and publish the -03 protocol draft. He hopes for WG last call on -03. If all goes well, that’ll be in May.

Magnus then proposed a suggested new WG schedule. For the framework document, he proposed to have the -04 I-D in April; take that to last call in May, and submit the Framework document to IESG in August for publication as an Informational RFC.

For the Protocol document, he proposed taking the Protocol I-D to WG last call in June. (This assumes that there will actually be a couple more iterations of the document, to address last-minute comments.) The Protocol will be submitted to IESG in September for publication as a Standards-track RFC.

Magnus noted that the Protocol document has a dependency on SASL-SRP draft, so it can’t actually be published as an RFC until after that document is done. Magnus asked if anyone had any insights into the progression of the SASL-SRP draft. Lawrence Greenfield said that the last he knew, there were no outstanding issues on that draft, and he has no real idea what’s holding it up. Thus, it’s possible that the block from SASL-SRP will soon be removed.

Given all of that, Bob Morgan suggested that there don’t seem to be three months’ of protocol issues left to be resolved; maybe the work will actually progress faster than the proposed schedule. Magnus said that that would be good; but it’s probably better to set a schedule and beat it than to set a more aggressive schedule and slip.

Bob Morgan noted that there might be IPR concerns around SRP that could hold this work up. Jeff Schiller said that the IPR situation around SRP is "a mess".

David Jablon gave a quick presentation on draft-jablon-speke-00.txt. This individual I-D describes several password authenticated key exchange methods, including SPEKE, and discusses their relation to other methods and patents, including a Phoenix patent. Toward the end of the presentation, Jeff Schiller asked David whether this is a technology that is patented by Phoenix, but in order to use it one has to ask Phoenix for license terms. David asked Jeff if it's proper to discuss license terms in an IETF meeting. Jeff answered no, it's not proper. David answered yes, Phoenix has a patent, with terms obtainable by asking. Jeff Schiller stated that it was inappropriate to be soliciting business in this manner.

The meeting ended at 1400.

Slides

Agenda
Objectives
'draft-jablon-speke-00'
'draft-ietf-sacred-protocol-bss-02'