Subject: DRAFT minutes, SACRED WG, Minneapolis IETF

From: "Linn, John" <[email-masked]>
Date: Mon, 26 Mar 2001 10:48:32 -0500

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.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Mar 2001 16:14:38 +0100

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

Stephen.

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

---

From: Dale Gustafson <[email-masked]>
Date: Tue, 27 Mar 2001 09:04:46 -0600

Hi John,

A very complete and accurate summary.

General comments, inline.

Best Regards,

Dale Gustafson

"Linn, John" wrote:

Opening status summary: Relative to posted milestones, the SACRED WG
is

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

Al Arsenault (Diversinet) led discussion on the requirements draft,
which he

had coauthored with Stephen Farrell. An -00 version had been posted
last

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

requirements that are specific to server-based vs. direct transfer
cases.

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

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

organization, sufficiency of GET-PUT-DELETE operations, credential
format(s)

credentials, each with friendly names. An -01 draft, co-authored with
Mike

Just (Entrust) and Magnus, was posted 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

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

changes to the framework, so preparation and discussion of at least
one more

I think the cardinal issues of 1) credential formats, 2) authentication
methods, and 3) transport protocols need further discussion.  I've
scanned the most recent messages on authentication methods from Yongge,
Tom, Radia, and Steven.

A few (somewhat) related opinions ...

1) Mandatory Credential Format

It's hard to know enough to choose or define a single credential format
that will be implemented across a wide variety of Internet devices, able
to convey a wide range of user credential data, and used in a truly interoperable
(any-to-any) fashion.  A fairly tall order.  I think it's pretty
clear that there is no ideal format already defined.  A deeper understanding
of the requirements for a single, flexible credential format that can be
used with many different devices _might_ indicate the need to develop a
new, relatively simpler, secured credential format.

However, other work need not be held up awaiting the next credential
format (if deemed necessary) -- implementers can work with existing formats
such as PKCS-7/certs-only, PKCS-12, PKCS-15, and even proprietary formats.
My priority order, assuming we choose from existing formats is:

- PKCS-12 + PKCS-7 (certs-only) -- existing P-7 & P-12 versions
as implemented by IE and NC et. al. (my 1st choice)

- PKCS-15 -- secure application support ?

- PKCS-12 (newest version) -- any support yet?

2) Mandatory Authentication Method

I'm not sure how much extra the market is willing to pay for the very
best strong-password algorithm/capability or how important it is (e.g.
to achieve interoperability) to choose a single mandatory authentication
algorithm up front..  I think the right thing to do here is make it
easy for implementers to choose whichever authentication algorithm they
prefer and let the market decide based on a superset of the standards-relevant
issues.

If we need a single mandatory to implement (MTI) method in the standard,
I prefer PDM at this point because PDM has a clear technical advantage
since it can be accomplished with an exchange of two messages.  OTP
clearly has lower overhead but may be problematic due to technical complications
involved with precomputing, storing, and replenishing multiple hashed passwords,
choosing the next expected pw for a "roaming" user, etc. seems awkward.
I think the technical aspects can sort themselves out fairly quickly.

In any event, it would not be that difficult for servers to support
more than one authentication method.  With planning, the additional
logic needed to support more than one algorithm would probably be implemented
largely within the credential server.

3) Mandatory Transport Protocol

I believe the preferred transport protocol will be http (not http/tls)
because it's tailor made for this type of application.  I don't know
enough about BEEP yet to comment on when it would be a viable alternative.
It might take a while for BEEP to establish market penetration levels with
range and reach on the same scale as http.

[no further comments below here]

Magnus led a discussion on three key open issues:
protocol, authentication

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

features within the protocol (LV).  His summarized results were
as follows:

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

application.  Stephen Farrell suggested that BEEP-formatted tokens
might be

transferred using HTTP and/or SASL. RL Bob Morgan asserted that the
ability

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

should be self-contained for security purposes or should instead be
layered,

foreknowledge of trusted root keys, though some ciphersuites (e.g.,
SRP,

Kerberos) have been defined which do not require certificates.
Intellectual

metrics: client CPU requirements, number of communications roundtrips,
level

of security, and ease of implementation. Each of DH-EKE, SPEKE, and
SRP were

weaker in terms of client CPU requirements and ease of implementation,
but

stronger in terms of number of communications roundtrips.  OTP
was

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

overhead is intrinsic to SRP.  Stephen Farrell asked whether the
WG should

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

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

that licensing under some terms would probably be possible..
Steve also

that this should be investigated.  Ted Ts'o pointed out that the
fact of IPR

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

Nada Cicovic (Entegrity) gave a presentation entitled "Contents of PSE
-

Certificate Enrollment and Lifecycle."  The work derives from
PKI Forum's

circulated within the PKI Forum. It seeks to standardize representations
for

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

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

Stephen suggested that Nada make materials available for review within
the

SACRED WG.

April: framework -02 I-D

April: protocol -00 I-D

Diffie-Hellman exchanges. Each modifies the Diffie-Hellman exchange
in a

different way.

Magnus closed the session, encouraging continuing discussions on the
mailing

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 28 Mar 2001 10:52:22 +0100

Dale,

Two things:-

1. I guess these are less comments on the minutes themselves than they 
are actions we said we'd do in the minutes (so John Linn doesn't need
to read further if he doesn't want to:-)

2. Between this and John's minutes I think we've a reasonable summary of 
the three main issues we face and I'd ask folks to post their 
opinions/questions/comments on each. (As John also noted in the minutes
we're not near concensus on any of the three and I got the impression
that not everyone was following all the issues, so don't feel bad just
asking questions!)

Stephen.

> I think the cardinal issues of 1) credential formats, 2) authentication methods, and 3) transport
> protocols need further discussion.  I've scanned the most recent messages on authentication
> methods from Yongge, Tom, Radia, and Steven.
> 
> It's hard to know enough to choose or define a single credential format that will be implemented
> across a wide variety of Internet devices, able to convey a wide range of user credential data,
> and used in a truly interoperable (any-to-any) fashion.  A fairly tall order.  I think it's pretty
> clear that there is no ideal format already defined.  A deeper understanding of the requirements
> for a single, flexible credential format that can be used with many different devices _might_
> indicate the need to develop a new, relatively simpler, secured credential format.
> 
> However, other work need not be held up awaiting the next credential format (if deemed necessary)
> -- implementers can work with existing formats such as PKCS-7/certs-only, PKCS-12, PKCS-15, and
> even proprietary formats.  My priority order, assuming we choose from existing formats is:
> 
>  - PKCS-12 + PKCS-7 (certs-only) -- existing P-7 & P-12 versions as implemented by IE and NC et.
> al. (my 1st choice)
> I'm not sure how much extra the market is willing to pay for the very best strong-password
> algorithm/capability or how important it is (e.g. to achieve interoperability) to choose a single
> mandatory authentication algorithm up front..  I think the right thing to do here is make it easy
> for implementers to choose whichever authentication algorithm they prefer and let the market
> decide based on a superset of the standards-relevant issues.
> 
> If we need a single mandatory to implement (MTI) method in the standard, I prefer PDM at this
> point because PDM has a clear technical advantage since it can be accomplished with an exchange of
> two messages.  OTP clearly has lower overhead but may be problematic due to technical
> complications involved with precomputing, storing, and replenishing multiple hashed passwords,
> choosing the next expected pw for a "roaming" user, etc. seems awkward.  I think the technical
> aspects can sort themselves out fairly quickly.
> 
> In any event, it would not be that difficult for servers to support more than one authentication
> method.  With planning, the additional logic needed to support more than one algorithm would
> probably be implemented largely within the credential server.
> 
> 
> I believe the preferred transport protocol will be http (not http/tls) because it's tailor made
> for this type of application.  I don't know enough about BEEP yet to comment on when it would be a
> viable alternative.   It might take a while for BEEP to establish market penetration levels with

---

From: Dale Gustafson <[email-masked]>
Date: Wed, 28 Mar 2001 10:10:56 -0600

Hi Stephen,

> to read further if he doesn't want to:-)

I'd agree. These are near-term action items.

> Stephen.

Good point.  This project covers a very wide technical area.  If there's
anything that can't be done
well without the inspired/enlightened counsel of the WG, we've found it.

Best Regards,

--dg