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

Hi Lawrence,

> Section 2.1.2 introduces the "Create Account" operation.  It doesn't have
> any mention of a server wishing to only store credentials for authorized
> users or any way that a server might wish to authenticate a user before
> creating an account for them.  (For instance, a server might require
> authentication using a different SASL mechanism before allowing a user to
> create an account.)
> 
> Or a site with a preexisting authentication infrastructure might already
> have SRP authenticators to use, and there's no need for a user to upload a
> new SRP authenticator.
> 
> Thus, I think account management should be in a seperate section from the
> credential upload/download, and should be an optional part of the server to
> implement.  A baseline SACRED client/server has to support upload/download
> (that's the point) but not necessarily the account management.

Sounds like a good idea. I'll include that next time 'round.

> 
> Section 2.2: authorization identity must equal authentication identity.
> Why is there this restriction?  A client should be able to attempt to
> authorize as some other user; it's a server's site policy that determines
> whether or not this is allowed.  The easiest site policy is to always
> disallow proxying.

It seemed simpler. Is there really a need for separate identities 
for sacred? I wouldn't have thought so.

> (Also, SASL allows a client to send the empty authorization string to
> "derive authorization from authentication credentials".)

Maybe that's a better way to do what I was trying to do.

> Section 2.2: The mandatory to implement TLS cipher-suite appears to also be
> the the only one allowed:
> 
>    The mandatory-to-implement TLS cipher-suite for sacred is:
>    TLS_RSA_WITH_3DES_EDE_CBC_SHA. This MUST be used for both sTLS and
>    cTLS cases.
> 
> Is this really what's intended?  Shouldn't a client and a server be allowed
> to use other cipher suites, as long as both support
> TLS_RSA_WITH_3DES_EDE_CBC_SHA so interoperability is guaranteed?

Why do you want to use other ciphersuites? (I mean now, as opposed to at
some future date.)

> Section 2.3: why only one operation per connection?  

Simplicity.

> I suggest instead that
> clients MUST be prepared to deal with servers that close the connection
> after a single operation and servers SHOULD support multiple commands per
> connection.  To simplify, you might want to say that commands MUST NOT be
> pipelined; the result of a previous command must be received before the
> next command can be sent.

Sounds hard to do, for little benefit. How often will multiple sacred
operations be needed?

> Section 4.3: There should probably be error codes for "over quota" or other
> administrator limitations.

Fair enough. Care to suggest text?

> Appendix C: administrator operations: I don't see an overwhelming need to
> interoperate with administrative operations.  If there's a desire for this,
> further messages can be defined later.

Sounds right. If no-one else wants them they'll go.

> Appendix C: mapping from SASL-SRP id to cTLS certificate: this is a very
> hard problem and is out of scope for SACRED.

People seem to think that all right. I need to think about it. (But note 
that we're not trying to solve the problem in general, just in the case
of sacred.)

> References: There are many normative references to works in progress such
> as XKMS and XBULK. Is the working group concerned that there might be a
> long wait for publication?  Is xkms sufficiently far along?

Are we? :-)

I don't think this is a problem since we'd only be using small bits
of either and could cut&paste at worst.

Cheers,
Stephen.

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