2.6.16 Securely Available Credentials (sacred)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-06-27

Chair(s):

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

Security Area Director(s):

Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:

Russ Housley <housley@vigilsec.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
Done  Submit second draft of Protocol document
Done  Framework doc ready for WG last call
Done  Protocol doc ready for WG last call
Done  Frameworks document to Informational RFC
Done  Protocol document to Proposed Standard

No Current Internet-Drafts

Request For Comments:

RFCStatusTitle
RFC3157 I Securely Available Credentials - Requirements
RFC3760 I Securely Available Credentials - Credential Server Framework
RFC3767 Standard Securely Available Credentials Protocol

Current Meeting Report

Sacred WG IETF-63 meeting notes

Note takers:

Tim Moses, Stefan Santesson
Jabber log:
http://www.xmpp.org/ietf-logs/sacred@ietf.xmpp.org/2005-08-03.html

(Stephen: Thanks for the excellent notes!)

Summary:

Although sacred has completed all its chartered milestones, the results were somewhat unsatisfactory since the WG chose not to adopt a strong password scheme (EKE, SPEKE, etc.). There is now a possibility that some relevant IPR positions may have changed, so the WG met to explore this.

Igor Faynberg (Lucent) and Robert Mol (Phoenix) took actions to clarify their IPR positions by the end of the month.

There was also interest in moving any new protocol from BEEP to HTTP, but only if a strong password scheme is adopted.

Once the Lucent and Phoenix actions are done, then we will have a list discussion to determine whether there is WG concensus to re-do the sacred protocol to use one or more strong password schemes.

1. Agenda:

- Agenda bashing (Stephen, TCD)
http://down.dsg.cs.tcd.ie/misc/sacred/SACRED-AGENDA.ppt
- History (Stephen, TCD))
http://down.dsg.cs.tcd.ie/misc/sacred/SACRED-AGENDA.ppt
- Technical Overview (Radia, Sun)
http://down.dsg.cs.tcd.ie/misc/sacred/SACRED-TECHOV2.ppt
- PAK (Alec,Lucent)
http://down.dsg.cs.tcd.ie/misc/sacred/SACRED-PAK2.ppt
- SPEKE (Robert,Phoenix)
http://down.dsg.cs.tcd.ie/misc/sacred/SACRED-SPEKE2.ppt
- OPAKE (James,Docomo)
http://down.dsg.cs.tcd.ie/misc/sacred/SACRED-OPAKE2.ppt
- Discussion (all)
- Questions to the room (Stephen)
http://down.dsg.cs.tcd.ie/misc/sacred/SACRED-AGENDA.ppt

The meeting was chaired by Stephen Farrell. (co-chair Magnus Nystrom was unable to attend.)

2. Stephen reviewed the history and current status of the working group.

The group was formed in 2000. It has produced three RFCs: 3157 on requirements, 3760 on the framework and 3767 on a protocol using DIGEST MD-5, TLS and BEEP. He indicated that some found this solution unsatisfactory, largely because it demands too much infrastructure and configuration.

Strong password schemes were considered, but were rejected, largely due to IPR concerns.

Stephen asked the group who had implemented the existing RFCs. Only RSA responded positively. Stephen said that he was also aware of an academic implementation.

The meeting had been called to discuss the way forward, in particular whether we can get concensus to adopt a strong password scheme and disbanding the working group. He acknowledged that a decision would not be reached at the meeting, but that we were aiming to be in a position to make such a decision in the next month or so.

3. Radia Perlman gave an overview of some strong password schemes. The requirement is to log-on to the network from any device, without using a smart card and without user-specific configuration of the access device. The solution must resist an off-line dictionary attack and eavesdropping.

Radia gave overviews of EKE, SPEKE and PDM. She pointed out that these protocols provided authentication and use four exchanges. But, simply for credential download, each protocol can be reduced to two exchanges.

Radia also overviewed alternative schemes, such as the TLS scheme currently standardized by SACRED.

4. Gareth Richards (RSA) presented a proposal for an HTTP binding for the existing SACRED scheme. He said that the approach had been implemented and proven to be practical. The proposal relies on a "SASL over HTTP" scheme described in a personal draft. It had been necessary to define an error response and a positive acknowledgment response.

Gareth listed outstanding questions: Is the approach acceptable? What content type should be assigned? Should a port number be reserved? Should the scheme use existing HTTP error responses?

Sam Hartman indicated that the HTTP SASL draft will not advance in its current form. He felt that momentum for progression did not exist.

Peter Sylvester suggested that SRP should be considered. Stephen said that SRP had been considered in the original round.

Uri Blumenthal said that the working group should define a strong-password scheme using HTTP.

5. Alec Brucilovsky (Lucent) described the PAK scheme. He asserted that it satisfies the requirements and proposed a work item to standardize it. He said that an open-source implementation was available under the Plan 9 license.

A working group member asked about the DoS performance, as the server was required to perform an exponentiation prior to client authentication. Alec suggested a variant that would require only a multiplication.

IPR questions were raised. Sam Hartman said that he had reviewed a Plan 9 license recently and found it unsuitable for his purposes because it required enhancements to be returned to Plan 9. Igor Faynberg suggested that these questions should be considered by attorneys. He offered to present any questions to Lucent attorneys. Sam said the group would be interested in a patent license, in addition to the current software license, as the IETF process requires several independent implementations.

During the meeting, Uri consulted the advertised Plan 9 license terms. He said that the Plan 9 license is OSI certified. He couldn't find a provision requiring enhancements to be returned to Plan 9. Uri offered that, provided the IPR concerns can be satisfactorily resolved, PAK looks like a promising solution.

Stephen asked the Lucent representatives to report on the current licensing terms for EKE, in addition to PAK. The Lucent representative should liaise with the WG chairs (and via them, with the AD, Russ Housley) aiming to provide a response by the end of the month.

6. Robert Mol (Phoenix) presented on SPEKE. He gave an overview of identity theft. He mentioned that SPEKE helps with these issues. It has been standardized in IEEE P1363 and is already identified in the SPEKE framework document. He listed four companies that have implemented SPEKE. Phoenix has a roadmap for SPEKE that includes an SDK, browser plug-ins and Java APIs.

A generic Phoenix IPR declaration has been posted on the IETF Web-site. He showed an extract that indicated the terms were RAND. He gave a contact at Phoenix for commercial issues.

Sam Hartman requested that Phoenix offer an opinion concerning the applicability of their patent to SRP.

Uri suggested that, unless the terms were RF, it would not be acceptable. Sam Hartman suggested that RAND may be acceptable and RF may be unacceptable, as sub-licensing terms must be considered. The true test is whether or not implementers find the terms acceptable.

Bill Summerfield (and others) said that licensing terms must clearly indicate RF.

Stephen said we need license text that is specific to the use of SPEKE in the implementation of an IETF specification. Phoenix was asked to provide such text by the end of August.

7. James Kempf (DoCoMo) gave a presentation on OPAKE. It is based on oblivious transfer, but uses a trick to overcome the traditional drawback of such techniques (performance) by batching multiple challenges.

He gave performance figures for their implementation, which showed some dozens of milliseconds on various platforms (this was for a security level equivalent to s four digit PIN). The technique is described in a paper, which includes a security proof.

DoCoMo has filed for a patent. But DoCoMo is committed to offering licenses under RFC 1822 (Photuris) terms, which are RF.

Stephen said that the work was very new and would require (extended) scrutiny.

There were questions about IPR terms. Radia Perlman asked for clarification. James Kempf said that the terms were RF. She asked why OPAKE was not encumbered by the PAKE patent. James suggested that the PAKE patent may be challenged on prior-art grounds. Charlie Kaufman suggested that DoCoMo might establish the applicability of the PAKE patent. James said DoCoMo was not likely to take that on, but other attorneys may take on the task.

Uri asked about the size of the algorithm parameters: number of primes and their sizes. James said that the primes were 11 bits in size. He thought that increased security demanded more primes, rather than larger ones. He suggested that those interested in this aspect should consult the paper.

Ken Rayburn said that Kerberos also needs a solution to the credential download problem. James Kempf said that EAP also needs one.

Greg Lebovitz observed that confidence in security and IPR are the primary discriminators for a solution. He asked whether the technical issues should be resolved elsewhere. Stephen and Russ Housley both indicated that the selection of a technique was central to the group's charter, so SACRED is the right place to address the technical issues.

8. Stephen canvassed working group opinion on several questions. There was discernible support for exploring PAK, some support for exploring SPEKE, similar support for exploring OPAKE and likewise for exploring other schemes. There was support for defining an HTTP binding.

Stephen asked for hums:

Modulo acceptable IPR, should the wg investigate:
  • PAK - medium hum
  • SPEKE - smaller hum
  • OPAKE - medium hum (but recognising early-days)
  • SRP/EKE/etc. - medium hum
Modulo doing one of the above:
  • HTTP - strong hum for change from beep to http

Stephen asked for the following show-of-hands:

Who wants to use a new SACRED protocol? (Abuot 50% of those present)
Who would implement a new SACRED protocol? (~7)
Who would work actively to define a new SACRED protocol? (~7, same folks)
Who wants to close the working group? (1)

Stephen asked the respondent to the last question for the basis of his position. The person represented Microsoft and said that Kerberos had a need, and the resources, to solve this problem and that IPR issues would be an obstacle to the standardization of a strong password scheme, Another speaker pointed out that this group had not demonstrated success. Perhaps, the Kerberos group should be allowed to solve the problem.

9. Stephen summarized. He said that feedback from patent holders is expected by the end of August. Discussion on the list could then proceed and the way forward be determined.

Slides

Agenda
Password-based Credentials Download Protocols
The PAK proposal for sacred WG
SPEKE Simple Password-authenticated Exponential Key Exchange
OPAKE: Password Authenticated Key Exchange based on the Hidden Smooth Subgroup assumption