Subject: BEEP adjustments [was: Re: I-D ACTION:draft-ietf-sacred-protocol-bss-01.txt]

From: Magnus Nystrom <[email-masked]>
Date: Tue, 5 Feb 2002 08:51:42 +0100 (W. Europe Standard Time)

(No, _this_ message is _not_ about the substrate issue ;)

Stephen,

Thanks for your work in producing this draft.

In order to clarify the separation between the messages themselves and the
BEEP profile more clearly, I suggest that the places where BEEP is
mentioned before the current Section 4 are rewritten slightly.

Specifically, the changes I would like to see are

Section 1:

s/The protocol uses [BEEP]/The protocol is profiled for BEEP [BEEP]/

Section 2.3:

(See separate posting regarding SRP, but in case that is not well
received, at least:

s/sTLS means that the BEEP session MUST be "tuned" for
server-authenticated TLS/sTLS means server-authenticated TLS/

s/cTLS means that the BEEP session MUST be "tuned" for
mutually-authenticated TLS/cTLS means client-authenticated TLS/

s/SRP means that the BEEP session MUST be "tuned" for SASL-SRP;/SRP means
SASL-SRP;/

and then move the para about "tuned" BEEP sessions to the BEEP profile
section.

Section 2.4:

Drop 2.4 since it does not make things more secure or efficient but adds
confusion (e.g. is there some operational requirement that requires the
server to drop the connection after a successful exchange?)

Section 3.1:

Replace the last two paragraphs with:

   "Where no specific response message is defined for an operation (e.g.
   for UploadRequest) then the transport will indicate success or
   failure.

   All of the response messages defined here MAY contain a Status
   string, containing a value intended for human consumption."

(The BEEP profile already specifies the mapping to BEEP messages)

BR,
-- Magnus

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 05 Feb 2002 12:27:49 +0000

All ok for me, except about 2.4 (see below).

Stephen.

> server to drop the connection after a successful exchange?)

Don't we need to say somewhere whether the session is expected to be
kept open? I don't see any requirement that a sacred server keep the
connection open, and I think its simpler if it just handles a single
transaction per connection/session. Hence the current text. I wouldn't
agree that saying nothing is right though.

-- 
____________________________________________________________
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: "Marshall T. Rose" <[email-masked]>
Date: Tue, 5 Feb 2002 10:59:35 -0800

i think the beep adjustments are fine, as are the srp adjustments.

/mtr

---

From: "Marshall T. Rose" <[email-masked]>
Date: Tue, 5 Feb 2002 11:01:20 -0800

> agree that saying nothing is right though.

well, actually, saying nothing is exactly what you want to do.

it's pretty much up to the initiator to decide what they want to do with the
session.

while a listener should certainly have an idle timeout, it's rather
presumptuous on the part of the listener to handle one request and then
exit.

all section 2.4 does is add a fair amount of implementational burden for no
added gain.

/mtr

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 06 Feb 2002 09:48:42 +0000

> presumptuous on the part of the listener to handle one request and then

For many protocols that's true I guess. However, since we're just 
handling (almost always) credential downloads I'd have thought it 
was just the right behaviour.

However, if you're saying that BEEP makes this a non-issue since
both sides should gracefully terminate (even if one times out),
then I guess I can buy not being so prescriptive. 

So - if no-one wants to keep 2.4 (or similar language), I'll delete 
it, but will add something about avoiding DoS (listener having a 
timeout etc) to the security considerations section. (That text
must nearly be boilerplate by now - anyone know where I can lift
it from?)

Stephen.

---

From: "Marshall T. Rose" <[email-masked]>
Date: Wed, 6 Feb 2002 11:32:47 -0800

> must nearly be boilerplate by now - anyone know where I can lift

in the security section, just add a sentence indicating that, as with all
protocols, a listener implementation should implement an inactivity timer.

/mtr