Re: DRAFT minutes, SACRED WG, Minneapolis IETF

[Stephen Farrell <stephen.farrell@xxxxxxxxxxxx>]

Folks - comments on these are due by next Friday 30th.

Stephen.

"Linn, John" wrote:
> 
> 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.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@xxxxxxxxxxxx
Ireland                             http://www.baltimore.com