Subject: Draft meeting minutes from the 55th IETF

From: "Nystrom, Magnus" <[email-masked]>
Date: Thu, 21 Nov 2002 08:50:59 -0500 (Eastern Standard Time)

Hi,

Below are the draft minutes from the SACRED WG meeting at the 55th IETF in
Atlanta. Please let me know if there is anything that needs to be
corrected or added. If there are no comments/objections, these will stand
as the meeting minutes. Thanks to Marshall Rose for acting as our Jabber
scribe during the meeting - the Jabber archive formed the basis for these
minutes.

-- Magnus
--
SACRED - 55th IETF, ATLANTA

Meeting Chairs:  Magnus Nyström, RSA Security, and Stephen Farrell,
Baltimore.

INTRODUCTION

Magnus started the meeting by reviewing the objectives of this working
group, and the objectives of this session.  He then summarized the
agenda, which was as follows:

-Introduction, agenda walkthrough, WG status - Magnus Nyström
-Protocol draft - Stephen Farrell
-Timeline
-Any Other Business

Since there were no objections to the proposed agenda, Magnus started
with the WG status:

-The Framework ID is now at the IESG. Final issues were resolved
 earlier this fall and the document was submitted to the IESG on
 September 30.

-The Protocol ID is in its 5th iteration, and with the exception of
 one recently discovered issue, only minor editorial matters remain.

PROTOCOL ID: (S. Farrell)

-Issues remaining: edits rejected on the mailing list, some
 clarifications, and binding of separate authentications.

-Upload response: Agreement not to make use of an UploadResponse
 message, but retain current text requiring clients to download (to
 ensure a fresh copy) before modifying.

-Bob Morgan to add text on the SASL authorization ID issue (needed for
 conformance with RFC 2222).

-Compound authentication issue (see
 draft-puthenkulam-eap-binding-00.txt): Farrell: If the same
 digest-md5 password is used both for sacred and non-TLS HTTP, you
 have problems, the problem is that the web server can be spoofed
 by the attacker, and digest-md5 is a shared secret approach
 Larry Greenfield: Is there even a need to consider this? You should
 not reuse credentials. If the client is going to use the same
 password with multiple servers, then it has to take the same
 precautions with the server and the certificate server. Farrell:
 Ok, not really a man-in-the-middle attack, but still a potential
 problem. We have a couple of options to address this. let's discuss
 after the meeting.

-Timeline: Will try to issue -05 later this week

-Marshall Rose: Did Manning ever come back with the exact issue he had
 with regards to the BEEP tuning? Farrell: no.

CONCLUDING

-Magnus: Suggested schedule: Framework already submitted to IESG,
 right after this meeting, produce -05 and do WG last-call. We plan
 on going to IESG at year's end. After that, let's talk about
 implementation/interop testing. Unless we hear otherwise, this group
 will therefore become dormant until there's time to move the protocol
 document to Draft Standard (after interop testing). Straw poll: How
 many intend or plan to implement the SACRED protocol? 3-4 hands
 shown.

-Magnus: We also have the Peer-to-Peer use case in our charter, but no
 work has been done on it due to lack of interest. Farrell: If anyone
 would like to do the peer-to-peer use case, or a transport other than
 beep, speak up now! Jeff: I'm hoping that the p2p case will become
 more interesting to the IETF, e.g., for jxta soon. Bob Morgan: We can
 of course always use the mailing list to discuss new work? Magnus: Of
 course.

ADJOURN.

-- Magnus

---

From: Marshall Rose <[email-masked]>
Date: Thu, 21 Nov 2002 09:28:43 -0500

> scribe during the meeting - the Jabber archive formed the basis for these

looks fine.

/mtr

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 21 Nov 2002 20:22:18 +0000

>  ensure a fresh copy) before modifying.

But this is a race condition? (unless you've meant "after modifying").

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

---

From: "Nystrom, Magnus" <[email-masked]>
Date: Mon, 25 Nov 2002 10:43:37 +0100 (W. Europe Standard Time)

Well, since we do not lock the credential at the server we will have a
race condition regardless of whether we have an UploadResponse or not. It
would be possible to add a flag to the download "download for
modification" and then don't allow any other "modification downloads"
until an upload happens, but I see several other problems with this
approach (e.g. what happens if an upload does not happen?) and I can't see
a pressing problem here since credential modifications will be quite rare
and why would a user need to do them simulatenously from more than one
client?

To get the fresh timestamp after a successful upload clients will have to
do a new download after the modification too, yes. That is the consequence
of not having the UploadResponse message.

-- Magnus