Re: more coments on draft-ietf-sacred-protocol-bss-00

Thanks Marshall, I'll incorporate those.

Stephen.

"Marshall T. Rose" wrote:
> 
> here are my comments, mostly editorial. (obviously, if the group has
> consensus for http, we can ignore the beep related comments.)
> 
> *** section 1, 2nd paragraph:
> >    The security of the protocol is based on [SRP]. The protocol uses
> >    [BEEP] as its transport layer and the [SASL] SRP mechanism [SASL-
> >    SRP] to encapsulate the SRP exchanges. The payloads consist of a set
> >    of XML messages defined here. The protocol sets out to meet the
> >    requirements in [REQS].
> 
> beep isn't a transport layer, so either:
> 
>     s/as its transport layer/for its exchange model/
> 
>     s/transport layer/session layer/
> 
> *** section 2, sections 2.1.1-2.1.6
> 
> it would be a lot easier if there were three paragraphs in each of these six
> sessions.
> 
>     - the first paragraph says "The purpose of this operation is..."
> 
>     - the second paragragh says "The X sends the A ... The Y sends the B
> ..."
> 
>     - the third paragraph says "This operations requires XXX security"
> 
> *** section 2.1, editorial remark regarding "tuned"
> 
> the term "tuned" is a term of art in beep. typically, sessions are "tuned
> for security" (a generic expression) or "tuned for privacy" or "tuned for
> authentication" (both more specific expressions).
> 
> you can probably replace the editorial remark with an example of a session
> being tuned, e.g., one of the examples from section 3 of rfc 3081.
> alternatively, if you'd like to show an example of SRP, scroll down to the
> end of the message, and i've put in an example:
> 
> *** Section 2.2:
> 
> >    Where there is a choice (e.g. Remove account), servers MUST support
> >    both options and clients MUST support at least one of the options.
> 
> s/Remove account/either SRP or cTLS/
> 
> *** Section 4.1
> 
> the URIs used to start the profile are inconsistent with the one defined at
> the beginning of section 4.
> 
> *** Section 4.3
> 
> >    code  meaning
> >    ====  =======
> >    777   Extension (ProcessInfo) used not supported
> >    778   Required extension (ProcessInfo) not present
> 
> appendix e of rfc 821 introduced the "theory of reply codes", which has
> modestly evolved since 1981. a reply code is a three-digit number. the first
> digit is 1-5 and indicates success/failure,
> permanent/transient/intermediate. the third digit is 0-9 and is an
> instance-identifier. the second digit is interpreted as:
> syntax (0), informational(1), connection(2), security(3),
> application-specific(5).
> 
> since these two codes reflect a permanent error, the first digit should be
> 5. since they reflect application-specific requirements, the second digit
> should be 5. the third digit can be something that isn't already used.
> 
> *** Section 5, IANA Considerations
> 
> here are two new open questions:
> 
> 1. should we apply for a port number?
> 2. should we define a url scheme?
> 
> *** Appendices A & B
> 
> it would be nice if this material was consistently indented, capitalized,
> etc., to make it easier to read...
> 
> /mtr
> 
> ps: here is what tuning for authentication and privacy looks like using SASL
> SRP:
> 
> #######
> 
>     L: <wait for incoming connection>
>     I: <open connection>
>     L: RPY 0 0 . 0 170
>     L: Content-Type: application/beep+xml
>     L:
>     L: <greeting>
>     L:    <profile uri='http://iana.org/beep/TLS' />
>     L:    <profile uri='http://iana.org/beep/SASL/SRP-SHA-160' />
>     L: </greeting>
>     L: END
>     I: RPY 0 0 . 0 52
>     I: Content-Type: application/beep+xml
>     I:
>     I: <greeting />
>     I: END
>     I: MSG 0 1 . 52 184
>     I: Content-Type: application/beep+xml
>     I:
>     I: <start number='1'>
>     I:    <profile uri='http://iana.org/beep/SASL/SRP-SHA-160'>
>     I:        <![CDATA[<blob>...</blob>]]>
>     I:    </profile>
>     I: </start>
>     I: END
>     L: RPY 0 1 . 170 783
>     L: Content-Type: application/beep+xml
>     L:
>     L: <profile uri='http://iana.org/beep/SASL/SRP-SHA-160'>
>     L:     <![CDATA[<blob>...</blob>]]>
>     L: </profile>
>     L: END
>     I: MSG 1 0 . 0 559
>     I: Content-Type: application/beep+xml
>     I:
>     I: <blob>...</blob>
>     I: END
>     L: RPY 1 0 . 0 429
>     L: Content-Type: application/beep+xml
>     L:
>     L: <blob>...</blob>
>     L: END
>     I: MSG 1 1 . 559 82
>     I: Content-Type: application/beep+xml
>     I:
>     I: <blob>...</blob>
>     I: END
>     L: RPY 1 2 . 429 66
>     L: Content-Type: application/beep+xml
>     L:
>     L: <blob status='complete' />
>     L: END
> 
>         ... successful transport security negotiation ...
> 
>     L: RPY 0 0 . 0 127
>     L: Content-Type: application/beep+xml
>     L:
>     L: <greeting>
>     L:    <profile uri='http://iana.org/beep/transient/sacred/bss' />
>     L: </greeting>
>     L: END
>     I: RPY 0 0 . 0 52
>     I: Content-Type: application/beep+xml
>     I:
>     I: <greeting />
>     I: END
> 
> #######

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