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

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