DRAFT minutes, SACRED WG, Minneapolis IETF
Linn, John <jlinn <at> rsasecurity.com>
2001-03-26 15:48:32 GMT
DRAFT minutes, SACRED WG, Minneapolis IETF
Minutes 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, added
clarifications, 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, 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. PDM was considered
weaker in terms of client CPU requirements and ease of implementation, but
stronger in terms of number of communications roundtrips. OTP was
considered stronger in terms of client CPU requirements, numbers of
roundtrips, and ease of implementation, but weaker in security.
Radia Perlman (Sun) argued that DH-EKE's and SPEKE's augmented modes, which
avoid storage of password-equivalent data at servers, incur overhead that is
unnecessary in the SACRED application. She noted, further, that this
overhead is intrinsic to SRP. Stephen Farrell asked whether the WG should
concentrate on one of the first four, or 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 also
commented that SRP might arguably infringe on the EKE patent, and suggested
that this should be investigated. 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.
RSS Feed