Subject: Re: Comments on Meeting Minutes

From: Dale Gustafson <[email-masked]>
Date: Fri, 17 Aug 2001 12:25:16 -0500

Hi Stephen,

Sorry I wasn't able to attend the meeting in London.  Hopefully, a good time was had
by all.

A couple of comments, inline.

Best Regards,

Dale Gustafson
Future Foundation Inc.
+1 651.452.9033 office
+1 218.343.9724 mobile

Stephen Farrell wrote:

> Hi All,
>
> Here are the draft minutes from yesterday's meeting (thanks to Al Arsenault for
> taking good notes).
>
> Any comments/corrections by Friday next (17th).
>
> Regards,
> 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
>
> DRAFT MINUTES OF THE SACRED WORKING GROUP MEETING
>
> 9 August 2001
> 51st IETF London, UK
>
> The SACRED working group met once in London, on Thursday morning at 09:00 am. 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
>  - 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.  Replace PDM with SRP as described in RFC2945.  Factors that could influence
> this include the connection-oriented nature of BEEP, and the fact that the short
> prime work is a bit cryptographically "new".
>
> 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 the 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 Gustafson, 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.

There may be a better way to word this.  I'd say the mechanics of changing the
document were editorial in nature -- not a lot of new text was added.  The
applicable mailing list comments incorporated, primarily from the Feb-Apr timeframe,
are clearly substantive.

> 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.

If it's not too late, I'd like to suggest we not raise everyone's hopes too high
that we'll be able to maintain perfect harmony between the protocol framework
document and the protocol document(s).  The framework document will tend to
articulate the conventional wisdom visa-vis what appear to be the best available
methods for user authentication via strong password, credential formats, transport
protocols, and other major technical issues common to SACRED protocols. For example,
a protocol document may need to push the state of the art in one or more technical
areas so there may be some differences between it and the framework.  A difference
between the two documents does not necessarily imply that one of the two needs to be
changed immediately.

> 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.

I'd also ask if there's anything the WG chairs and document authors can do to
stimulate more group discussion.  Perhaps this particular topic is unique enough
that we need to do something special.

This group is distinctly unique -- usually the WG chairs need to ask for *less*
group interaction :-)

> 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 10:00 am.