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

Magnus,

This all looks fine to me, though I might change some wording when
I'm editing, so barring objections I'll add these in for the next
rev.

Stephen.

Magnus Nystrom wrote:
> 
> Stephen,
> 
> In the posting I made on Dec 6th, there was a suggestion to modify the
> protocol document to allow for other security context establishment
> mechanisms apart from SRP. While it is necessary to mandate one
> authentication mechanism for interoperability reasons, I do not think
> that it should be left completely unspecified how to implement support
> for other mechanisms, in particular since the current draft is based
> on BEEP which supports SASL which in turn supports many mechanisms.
> 
> Specifically, the changes that I would like to see are:
> 
> -Section 1, second para:
> 
> Delete first sentence, since, e.g., cTLS is also allowed. Rephrase the
> paragraph to:
> 
>         The protocol uses [BEEP] for its exchange model
> 
> (or possibly: "The protocol is profiled for BEEP...", see separate
>  thread "BEEP adjustments")
> 
>         and its payloads consist of a set of XML messages defined
>         herein. The protocol sets out to meet the requirements in
>         [REQS]. In particular, security requirements in [REQS] are met
>         by mandating support for TLS [TLS] and/or SRP [SRP].
> 
> -Section 2.1.2:
> 
> Change second para to:
> 
>    The purpose of this operation is to setup a new account on the
>    server.  The information required for a "new" account
>    will depend on the SASL mechanism used.  For [SRP], it will consist
>    of the username and SRP password verifier with no associated
>    credentials.
> 
> -Section 2.1.4:
> 
> Remove the current subsection, and replace it with:
> 
>    2.1.4 Modify Account
> 
>    The purpose of this operation is to allow the client to change the
>    information required for authentication.  The information required
>    will depend on the authentication method used. For [SRP] it will
>    consist of a salt and a password verifier value.  Once the account
>    information has been changed, the server will respond an error or
>    acknowledgement message."
> 
> -Section 2.3:
> 
> (The reasons for the changes proposed for this section are as follows:
> The security requirements are not really cTLS, sTLS or SASL-SRP, but
> rather the security services these protocols provide. It therefore
> seems more correct to identify these required services, and then
> identify protocols that provides them, and finally mandate a minimum
> set -that must be supported in order to guarantee interoperability-
> among those protocols)
>
> Delete the last sentence in the first paragraph, and delete the
> listing after it. From this follows that the Note also will be
> deleted. Replace the remaining text with:
> 
>       Operation                 Security REQUIRED
>       ---------                 -----------------
>       Information request       NONE
>       Create account            Server authentication,
>                                 Privacy, Integrity
>       Remove account            Mutual authentication,
>                                 Privacy, Integrity
>       Modify account            Mutual authentication,
>                                 Privacy, Integrity
>       Credential upload         Mutual authentication,
> `                               Privacy, Integrity
>       Credential download       Mutual authentication,
>                                 Privacy, Integrity
> 
>    The security requirements can be met by several mechanisms. This
>    document REQUIRES credential servers to support TLS and SASL-SRP.
>    Clients MUST support SASL-SRP or TLS.
> 
>    The mandatory-to-implement TLS cipher suite for SACRED is
>    TLS_RSA_WITH_3DES-EDE_CBC_SHA.
> 
>    For SASL-SRP, all three security services (privacy,
>    replay protection, and integrity) MUST be used.
> 
> [The issue of the authorization identity have to be dealt with in a
> separate thread]
> 
> -Section 3:
> 
> Change "PWChangeRequest" to "ModifyAccountRequest" throughout the
> section.
> 
> -Section 3.5:
> 
> Replace current text with:
> 
>    Contains one or more element containing the information
>    required to create an account for the identified authentication
>    mechanism.  The actual information contained in the element will be
>    defined by the authentication mechanism but for SRP it will contain
>    the account name, salt and password verifier for that account.
> 
> -Section 3.7:
> 
> Replace current text with:
> 
>    Contains one or more element containing new authentication
>    information for identified authentication mechanisms.  The actual
>    information contained in the elements will depend on the mechanism
>    but for SRP it will contains a new salt and password verifier for
>    the account.
> 
> -Appendix A:
> 
> If the above proposal is accepted, it means that the schema must be
> updated to allow for other SASL mechanisms and changed PDU names. In
> the message I sent to the list on Dec. 6 there was a proposal on how
> to achieve this (separate from the http/BEEP issue), although that
> proposal was flexible enough to handle also non-SASL mechanisms. It is
> probably ok to limit ourselves to SASL (and TLS) mechanisms for now,
> but my suggestion is to make use of the parts of that proposal that
> are needed for the above. Of course I (and Gareth) are willing to help
> out in formulating that schema.
> 
> BR,
> -- Magnus

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