NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-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.
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 |
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 |
9 August 2001
51st IETF London, UK
The SACRED working group met once in London, on Thursday morning at 0900. WG co-chairs Magnus Nystrom and Stephen Farrell presided. About 90 people attended.
Stephen Farrell presented the meeting agenda, which was as follows:
Intro & Agenda Bashing
WG Status
Requirement Draft Update
Protocol Draft Discussion
Framework Draft Discussion
PKI Enrollment Information Storage
All Other Business
Wrap Up
Intro & Agenda Bashing
The agenda was accepted as presented.
WG Status
Stephen Farrell presented the working group status. Document status is as follows:
The Requirements document has been approved for publication as an Informational RFC, and is in the RFC editor's queue.
Version -01 of the Framework was posted in March; -02 has recently been published but missed the cut-off date for publication on the IETF Internet Draft web site prior to this meeting. It should appear there soon.
There were two other documents published in June:
Version -00 of the Protocol document, and version -00 of the "PKI Enrollment Information" document.
Requirement Draft Update
Al Arsenault reiterated what Stephen Farrell had said. Since the last IETF, the document has passed WG and IETF last call, and was approved by IESG for publication as Informational RFC. It entered the RFC Editor queue on 19 July.
Protocol Draft Discussion
Radia Perlman presented this document, which she co-authored with Charlie Kaufman, Stephen Farrell, and Marshall Rose. The document is available on the Web site as draft-ietf-sacred-protocol-beep-pdm-00.txt.
This protocol does not yet meet SACRED requirements, but they're working on it. The bases of the protocol are:
PDM for authentication;
PKCS-15 for credential format;
BEEP for transport;
and an XML Schema to define payloads.
Radia discussed the technical content of the protocol, and then moved onto some of the issues. One of the major issues has been the generation of primes for PDM. In the end, with five separate implementations (3 in C, 2 in Java), her implementers managed to get pretty good performance. However, she recommends shorter primes (e.g., 512 bits vs. 1024), which provide significant performance improvements without sacrificing (in her opinion) security.
Things that might change in the proposed protocol include:
a. allow a choice of, and negotiation of, methods, and that we will probably have SRP be the single required method
b. Using a SASL method vs. the current XML payload scheme for authentication
c. The addition of a PKCS #15 profile
d. "Many, many details".
An audience member asked what the advantage was of multiple credentials per user, and what in the protocol allows user to choose among multiple credentials? Radia's response was that it's easy enough to store multiple credentials; it's largely a user-interface issue as to how to allow the user to choose among them.
Stephen Farrell asked how many people had read the draft. About a half-dozen hands were raised.
Framework Draft Discussion
Magnus Nystrom presented this document on behalf of his co-authors, Mike Just and Dale Gustafsson, neither of whom attended the meeting.
Magnus provided a quick background review of the document. It is based on the Requirements document, and provides a framework that must be met by a protocol realizing SACRED's objectives. Magnus noted again that the current draft available on the IETF web site is -01, but -02 has been submitted and will appear shortly. Thus, Magnus discussed the -02 draft.
He described the document contents, then summarized the changes between the -01 draft and the -02 draft. Largely, the changes are editorial in nature: expanding definitions; adding sections to the Security Considerations section; adding references and general notes.
Magnus then turned to the topic of progressing this document. He stated that, rather than progressing this document to an Informational RFC, the authors believe that the better choice might be to stop working on it, and just include relevant material in the protocol document. There will be significant overlap between this framework document and the protocol document, so it didn't seem to make sense to publish redundant information.
John Noerenberg objected to that proposal. He believes that it would probably be better to publish the Framework document separately from the protocol document because they have separate constituencies. The main audience of the protocol document will be implementers, who don't necessarily need all of the background information contained in the Framework document, while the main audience for the Framework document might well be people who need to understand the problem at a higher level. A straw poll conducted by Magnus indicated that a majority of the attendees wanted the Framework published as a separate, Informational RFC. This will be done, but Stephen suggested that it would be better to develop the next revision of the Framework document, and then wait until the protocol documents is completed, and then publish both documents together. This would ensure that the two documents are consistent.
PKI Enrollment Information Storage
Nada Kapidzic Cicovic discussed this document, which is available at draft-ieft-sacred-pkienrollinfo-00.txt. It proposes a way to automate the enrollment of end-entities in a PKI, and limit or eliminate the amount of human intervention currently required.
Nada gave an overview the contents of her document, starting with current models of end-entity enrollment (RA/CA-driven vs. End-entity initiated), and the two types of enrollment information (general RA/CA information, which can be made publicly available; and EE-specific parameters, which may include a shared secret and may need to be kept confidential). She described various usage models, including what types of information may need to be kept in a Personal Security Environment.
The main issue then discussed was the standardization process for this work. It is not clear that it fits under the SACRED charter as it currently reads. Nada's work was presented at the PKCS Ad-hoc in San Francisco in April and the PKCS Forum workshop that took place in Hamburg in June. It is recognized that this is an important part of the overall PKI architecture, but it's not clear where best to address it. So far, there have been very few comments made on this work, either in SACRED or on the PKCS mail list.
The decision made was to continue discussing this work on the SACRED mailing list, but not to progress this I-D towards any type of RFC. It seems to fit better under the PKCS charter.
Once it is completed, a profile of it may be needed for the Protocol document.
All Other Business
No other topics were raised.
Wrap Up
Magnus Nystrom presented a few slides as part of the meeting wrap-up. The big issue is that the activity level in SACRED is too low! It's hard to tell whether there's enough of a constituency to move forward with a standards track document. If there's not enough of a constituency, it will wind up as Experimental.
The chairs asked how many in the room think that they would implement the SACRED protocol should it become a standards-track document? About 10 hands were raised; that was taken as an encouraging sign.
The chairs noted that interested parties should stop being so shy, and participate in discussion on the documents on the list.
Radia Perlman asked what would be so bad if the protocol document winds up as an Experimental document instead of a Standards Track document? The co-chairs replied that they don't have a real problem with that, per se. The real problem is lack of feedback on the work. We don't know if the protocol is as good as it could be with just the minimal review it's getting right now, and publishing it as Experimental is not likely to encourage others to review it and make it better. Also, Stephen Farrell pointed out that the charter says that the SACRED working group will develop a Standards Track protocol, so winding up with an Experimental protocol seems to be failing to live up to our charter.
The meeting adjourned at approximately 1000.
Agenda
Framework document
'draft-ietf-sacred-protocol-beep-pdm-00.txt'
PKI Enrollment Information
Wrap Up