Subject: Re: SACRED Protocol (long!)

From: Magnus Nystrom <[email-masked]>
Date: Thu, 6 Dec 2001 10:30:45 -0500 (Eastern Standard Time)

All,

Given the discussion regarding SACRED's dependence on BEEP and
BEEP's support of SASL, please find below a suggestion for some
modifications to the current protocol draft.

In particular, the proposal below aims to fullfill the following
objectives:

-allow SACRED protocol exchanges to run on top of any reliable
 transport, including SOAP, http, BEEP, and other protocols,
-allow easy integration of other SASL mechanisms than SRP into the
 protocol, and
-allow the use of other security context establishment techniques
 than those provided by SASL.

We claim that the proposal achieves these objectives by:

-integrating support for SASL within SACRED itself, and
-defining XML schema that separates the basic SACRED protocol
 from the specifics of various authentication frameworks (e.g. SASL).

The security context establishment framework is integrated into
SACRED by defining a BindRequest and BindResponse message pair
(c.f. RFC 2251), as well as a BindInfoRequest and BindInfoResponse
pair (used when creating accounts).

The security context establishment at account creation is solved in
the current draft by relying on TLS. Our proposal is to instead use
SASL GSSAPI, and in particular a slightly modified version of the
SPKM-3 mechanism defined in RFC 2847. The advantage of this is that
we maintain transport independence.

We also define the use of a "fingerprint" that allows a client to
conditionally ask for credentials. This allows for bandwidth savings
when a local cache exists in the client (c.f. the framework draft).

I will try to describe this proposal in more detail in SLC next week,
but feedback, questions and comments on the mailing list are of course
both welcome and solicited.

-- Magnus and Gareth Richards.

----------------

2.1: Text should be added indicating that clients and servers MUST
    support all operations, unless otherwise mentioned.

2.1.1: Indicate that it is optional for a client to support this
    operation.

2.1.2: Indicate that it is optional for a client to support this
    operation. Remove TLS text. I.e., suggest to change the
    subsection to:

 "2.1.2 Create Account

   This operation requires server authentication.

   The purpose of this operation is to set-up 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.

   The client sends a CreateAccountRequest and the server responds with
   an error or acknowledgement message.

   Client support of this operation is optional."

2.1.4: Remove the current para, and replace it with:

  "2.1.4 Change 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."

2.1.5: Add sentence stating that the operation requires a
  mutually authenticated session.

2.1.6: Add sentence stating that the user MUST be authenticated by
   the server and  the server SHOULD be authenticated by the client.

Add new subsection 2.1.7 as follows:

  "2.1.7 Bind

   This operation establishes a security context between the server
   and the client. A framework for negotiation of security
   mechanisms is provided. The established security context enters
   into effect immediately after the servers successful BindResponse
   message."

2.2: Replace current text with:

 "2.2 Session Security

   All implementations MUST support SASL SRP [SASL-SRP]. Implementations
   that support the CreateAccount operation MUST support SASL GSSAPI
   [SASL-GSSAPI]."

  2.2.1 SRP

   The SASL SRP mechanism MUST be implemented and MUST use the SASL
   security layer with all three security services (confidentiality,
   replay protection and integrity) and MUST use the mandatory-to-
   implement algorithms from [SASL-SRP].

  2.2.2 GSSAPI

   An implementation MUST support the GSSAPI SASL mechanism which in
   turn must support the SPKM GSS-API mechanism.

   The SPKM implentation MUST support:

   - The NULL-MAC [LIPKEY] and sha1WithRSAEncryption algorithmgs as
     I-ALGs. (Targets MUST not use this algorithm.)
   - AES  as a C-ALG.
   - SHA-1 [FIPS] as an O-ALG.

   << QOP bitmap needs to be defined.>>"

Section 2.3 and 2.4: Replace current text with:

 "2.3 Session Management

   Once an authenticated connection has been established, the client can
   issue as many requests as desired.  However, the client MUST break
   the connection by issuing an UnBindRequest before initiating a new
   authentication exchange.

   All message exchanges are synchronous.  That is, a client MUST NOT
   send a request until it has received the response to any previous
   request.

 2.4 Handling multiple credentials for an account

   Each set of credentials in a user account MUST have an identifing
   name.  This name MUST be included in upload request. If a client does
   not specify an identifier in a download request then all the client's
   credentials will be returned, otherwise the identified credentials
   will be returned.  It is an error for multiple credentials stored
   under the same account to have the same identifier."

Section 3.1: Replace last para with:

   "All response messages will contain a status value indicating the
   success or failure of the request.  They MAY also contain a
   ResponseInfo element containing additional error or failure
   information.

   The status code can be one of the following:

   - Success
   - UnknownError
   - NotSupported, Requested operation is not supported.
   - AccessDenied, Authentication failure.
   - NotFound, The requested credentials could not be found.
   - Modified, The credentials were modified since the last download.
   - NotModified, The requested credentials have not been modified since
     the last download.
   - MalformedRequest The request was recognised but invalid.
   - UnknownRequest The request was not recognised."

Section 3.2: Replace current text with:

 "3.2 Credential Format

   The upload request and download response messages involve credential
   elements.  These elements share the following common fields:

   - Selector contains a string by which this
     particular credential (for this account) can be identified.
   - KeyInfo, contains a ds:KeyInfo.  Implementations MUST support the
     pkcs15 form of ds:KeyInfo containing a network byte order base64
     encoded PKCS#15 token.

   The KeyInfo field is optional in the upload request.  If it is
   omitted then the matching credential is omitted.

   The download response MUST contain a fingerprint of the credentials
   that allow the server to identify the version.  The upload request
   MAY contain this identifier.  If the identifier is omitted then the
   credentials will be replaced unconditionally.  If it is included then
   the server will only replace the credentials if the fingerprint
   equals that stored, otherwise an error will be returned.

   The response MAY also contain (all optional fields may occur
   exactly zero or one times unless otherwise stated):

   - TimeToLive is a hint which clients SHOULD honor, which
     specifies the number of seconds for which the downloaded
     credential is to be usable.  If the element is not present or has
     the value of zero then the credentials do not expire.
   - ClientInfo MAY contain any (typed) information that the
     client is intended to process.  If the client doesn't support any
     of the ClientInfo data, it MAY ignore that data (e.g. if the
     ClientInfo is device specific)."

Repalace Section 3.3 - 3.10 with:

 "3.3 Bind Messages

   The content of the messages in this section depend on the
   authentication framework used.  This document describes the SASL
   binding.

  3.3.1 BindInfoRequest

   Contains a sequence of one or more Mechanism elements naming the SASL
   authentication mechanisms for which the bind information is required.

   This request is normally only sent in preparation for a
   CreateAccountRequest.

  3.3.2 BindInfoResponse

   Contains a sequence of one or more Mechanism element each of which
   corresponds to one in the BindInfoRequest.  Each of these elements
   will contain mechanism specific information required to create
   initial authentication information for the mechanism's element in a
   CreateAccount message.  May also contains a list of supported
   ProcessInfo types.

  3.3.3 BindRequest

   Contains one or more Mechanism elements identifying authentication
   mechanisms supported by the client.  These elements MAY contain a
   Data element containing the clients "initial response" (see [RC2222])
   to the server for that mechanim.

  3.3.4 BindResponse

   Contains one or more Mechanism element identifying SASL
   authentication mechanisms supported by the server.  If the mechanism
   requires an initial server challenge or the BindRequest contained the
   client's "initial response" then the element will contain a Data
   element.

  3.3.5 UnBindRequest

   There is no content to this message apart from the optional
   ProcessInfo.

  3.3.6 UnBindResponse

   There is no content to this message.

  3.3.7 CreateAccountRequest

   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.

  3.3.8 CreateAccountResponse

   There is no content to this message.

  3.3.9 RemoveAccountRequest

   There is no content to this message apart from the optional
   ProcessInfo.

  3.3.10 RemoveAccountResponse

   There is no content to this message.

  3.3.11 ChangeAccountRequest

   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.

  3.3.12 ChangeAccountResponse

   There is no content to this message.

 3.4 DownloadRequest

   This message MAY contain the credential selector string for the
   credential. It MAY also contain a version identifier as contained in
   the DownloadResponse and UploadResponse messages.  The intention is
   that the client will include this identifier when they currently have
   the credentials and wish to download only if the version on the
   server are newer.

 3.5 DownloadResponse

   This message contains the credential.

   Credentials will not be returned if the version information matches
   that of the credentials on the server.

 3.6 UploadRequest

   The message contains the new credential and MAY contain a version
   identifier.  If the identifier is not included then the credentials
   will unconditionally replace any with the same name.  Otherwise they
   will only be replaced if the version information is the same.

 3.6 UploadResponse

   This message will contain an identifer that can can be used as a in a
   DownloadRequest to identify a particular version of a credential.

 3.7 ErrorResponse

   This response message is only returned in response to an unrecognised
   request."

Section 4: Replace the current text with:

  "4 SASL Profile for SACRED

   The GSSAPI host based service name for this profile is "SACRED".

 4.1 Initiation Sequence

   Before any SACRED request can been made, a security context MUST be
   established with the SACRED server. To do this, the client sends the
   server a BindRequest and the server responds with an error or a
   BindResponse. The BindRequest contains a list of the authentication
   mechanisms supported by the client identified by the Name attributes
   of the Mechanism elements.  These elements can optionally contain the
   clients "initial response" contained within a Data element.

 4.2 Exchange Sequence

   The SASL authentication protocol exchange is carried out in the
   exchange of BindRequest and BindResponse messages.  The exchanged
   data is BASE64 encoded without embedded linefeeds within the Data
   elemements of the Mechanism elements.  The Status attribute of the
   BindResponse allows the server to indicate completion or failure of
   the exchange and the same parameter of the BindRequest allows the
   client to abort the exchange.

   The SACRED protocol sets no limits on the length of the exchanged
   data.

   If a security layer is negotiated as part of the SASL exchange, it
   will take effect immediately following the server's completion
   response.

 4.3 Authorization Identity

   If an authorization identity is sent to the server then that identity
   will be used when accessing credentials."

Finally, replace Appendix A with the following:

Appendix A: XML Schema

   All the SACRED protocol elements are defined using XML schema [XML-
   Schema1][XML-Schema2].

   There are three schema defined.

   1. A base schema defining the basic PDU elements but not bound to any
   authentication framework.
   2. A SASL schema defining elements extending base schema elements to
   encorporate SASL specific data.  These elements do not contain any
   authentication mechanism specific elements.
   3. An SRP schema defining SRP element types to be included in the SASL
   elements.

   The namespaces for the three schema and the prefixes used are as
   follows

   xmlns:sacred="urn:sacred-2001-11-27"
   xmlns:sasl="urn:sacred-sasl-2001-11-27"
   xmlns:srp="urn:sacred-sasl-srp-2001-11-27"

   <<These are temporary working names.>>

   The default namespace for unqualified elements is the XML schema
   namespace

   xmlns:"http://www/w3.org/2001/XMLSchema"

 A.1 Base Schema

   <?xml version="1.0" encoding="UTF-8"?>

   <schema
     targetNamespace="urn:sacred-2001-11-27"
     xmlns="http://www.w3.org/2001/XMLSchema"
     xmlns:sacred="urn:sacred-2001-11-27"
     xmlns:xml="http://www.w3.org/XML/1998/namespace"
     xmlns:xbulk="http://www.xmltrustcenter.org/xkms/docs/x-bulk-2001-07-04.xsd"
     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
     elementFormDefault="unqualified" attributeFormDefault="unqualified"

   <!--
     <import namespace="http://www.w3.org/XML/1998/namespace" />
    -->
     <import namespace="http://www.xmltrustcenter.org/xkms/docs/x-bulk-2001-07-04.xsd" />
     <import namespace="http://www.w3.org/2000/09/xmldsig#" />

     <!-- Security Binding -->
     <element name="BindRequest" type="sacred:RequestType"/>

     <element name="BindResponse" type="sacred:ResponseType" />

     <element name="UnBindRequest" type="sacred:RequestType"/>
     <element name="UnBindResponse" type="sacred:ResponseType"/>

     <!-- Information request -->
     <element name="BindInfoRequest" type="sacred:RequestType"/>
     <element name="BindInfoResponse" type="sacred:BindInfoResponseType"/>
     <complexType name="BindInfoResponseType">
       <annotation>
         <documentation xml:lang="en">
           Message type returned by server in response to a BindInfoRequest.
           Contains information required to create an account for a particular
           authentication mechanism.

           The ProcessInfo contains a list of ProcessInfo types supported
           by the server.
         </documentation>

       </annotation>
       <complexContent>
         <extension base="sacred:ResponseType">
           <sequence>
             <element ref="xbulk:ProcessInfo" minOccurs="0"/>
           </sequence>
         </extension>
       </complexContent>
     </complexType>

     <!-- Account Handling -->
     <element name="CreateAccountRequest" type="sacred:RequestType"/>
     <element name="CreateAccountResponse" type="sacred:ResponseType"/>

     <element name="RemoveAccountRequest" type="sacred:RequestType"/>
     <element name="RemoveAccountResponse" type="sacred:ResponseType"/>

     <element name="ChangeAccountRequest" type="sacred:RequestType"/>
     <element name="ChangeAccountResponse" type="sacred:ResponseType"/>

     <!-- Credential Handling -->
     <element name="DownloadRequest" type="sacred:DownloadRequestType" />
     <element name="DownloadResponse" type="sacred:DownloadResponseType" />

     <element name="UploadRequest" type="sacred:UploadRequestType"/>
     <element name="UploadResponse" type="sacred:UploadResponseType"/>

     <element name="ErrorResponse" type="sacred:ResponseType"/>

     <complexType name="ResponseType">
       <sequence>
         <element name="ResponseInfo" type="sacred:ResponseInfoType" minOccurs="0"/>
       </sequence>
       <attribute name="Status" type="sacred:StatusType" use="required"/>
       <attribute name="RequestID" type="integer" use="required"/>
       <attribute name="MajorVersion" fixed="1"/>
       <attribute name="MinorVersion" fixed="0"/>
     </complexType>

     <complexType name="RequestType">
       <sequence>
         <element ref="xbulk:ProcessInfo" minOccurs="0"/>
       </sequence>
       <attribute name="RequestID" type="integer" use="required"/>
       <attribute name="MajorVersion" fixed="1"/>
       <attribute name="MinorVersion" fixed="0"/>
     </complexType>

     <complexType name="ResponseInfoType">
       <sequence>
         <element name="Description" maxOccurs="unbounded">
           <complexType>
             <simpleContent>
               <extension base="string">
                 <!-- FIXME: Xerces 2.0 objects to xml:lang
                 <attribute ref="xml:lang" use="optional"/>
                 -->
               </extension>
             </simpleContent>
           </complexType>
         </element>
       </sequence>
     </complexType>

     <simpleType name="StatusType">
       <restriction base="string">
         <enumeration value="Success"/>
         <enumeration value="UnknownError"/>
         <enumeration value="NotSupported"/>
         <enumeration value="AccessDenied"/>
         <enumeration value="NotFound"/>
         <enumeration value="Modified"/>
         <enumeration value="NotModified"/>
         <enumeration value="MalformedRequest"/>
         <enumeration value="UnknownRequest"/>
       </restriction>
     </simpleType>

     <!-- credential specific operations -->

     <complexType name="DownloadRequestType">
       <annotation>
         <documentation xml:lang="en">
           Message type sent to server to request client credentials.
           Specific credentials may be identified in the request using Selector.
           If specific credentials are not requested then all the user's credentials
           MAY be returned.
         </documentation>
       </annotation>
       <complexContent>
         <extension base="sacred:RequestType">
           <sequence minOccurs="0">
             <element name="Selector" type="string"/>
             <element name="Fingerprint" type="sacred:Fingerprint" minOccurs="0" />
           </sequence>
         </extension>
       </complexContent>
     </complexType>

     <complexType name="DownloadResponseType">
       <annotation>
         <documentation xml:lang="en">
           Message type returned by server in response to a DownloadRequest.
           If specific credentials were selected then only those will be returned,
           otherwise, all the user's credentials MAY be returned.
         </documentation>
       </annotation>
       <complexContent>
         <extension base="sacred:ResponseType">
           <sequence>
             <element name="Credential" type="sacred:DownloadCredentialType" minOccurs="0" maxOccurs="unbounded"/>
           </sequence>
         </extension>
       </complexContent>
     </complexType>

     <complexType name="UploadRequestType">
       <annotation>
         <documentation xml:lang="en">
           Message type sent by client to upload or delete credentials.
         </documentation>
       </annotation>
       <complexContent>
         <extension base="sacred:RequestType">
           <sequence>
             <element name="Credential" type="sacred:UploadCredentialType"/>
           </sequence>
         </extension>
       </complexContent>
     </complexType>

     <complexType name="UploadResponseType">
       <annotation>
         <documentation xml:lang="en">
           Message type returned by server in response to an UploadRequest.
         </documentation>
       </annotation>
       <complexContent>
         <extension base="sacred:ResponseType">
           <sequence>
             <element name="Fingerprint" type="sacred:Fingerprint" minOccurs="0"/>
           </sequence>
         </extension>
       </complexContent>
     </complexType>

     <complexType name="Fingerprint">
       <simpleContent>
         <extension base="string">
         </extension>
       </simpleContent>
     </complexType>

     <!-- A new ds:KeyInfo thing -->
     <element name="PKCS15" type="ds:CryptoBinary"/>

     <!-- credential -->
     <complexType name="DownloadCredentialType">
       <sequence>
         <element name="Selector" type="string"/>
         <element ref="ds:KeyInfo"/>
         <element name="Fingerprint" type="sacred:Fingerprint"/>
         <element name="TimeToLive" type="positiveInteger" minOccurs="0"/>
         <element ref="xbulk:ClientInfo" minOccurs="0"/>
       </sequence>
     </complexType>

     <complexType name="UploadCredentialType">
       <sequence>
         <element name="Selector" type="string"/>
         <element ref="ds:KeyInfo" minOccurs="0" />
         <element name="Fingerprint" type="sacred:Fingerprint" minOccurs="0"/>
       </sequence>
     </complexType>

   </schema>

 A.2 SASL Schema

   <?xml version="1.0" encoding="UTF-8"?>

   <schema
     targetNamespace="urn:sacred-sasl-2001-11-27"
     xmlns="http://www.w3.org/2001/XMLSchema"
     xmlns:sasl="urn:sacred-sasl-2001-11-27"
     xmlns:sacred="urn:sacred-2001-11-27"
     elementFormDefault="unqualified" attributeFormDefault="unqualified"

     <import namespace="urn:sacred-2001-11-27" />

     <annotation>
       <documentation xml:lang="en">
         Schema defining SASL types for SACRED protocol.
       </documentation>
     </annotation>

     <element name="SASLBindRequest"  type="sasl:SASLBindRequestType" substitutionGroup="sacred:BindRequest" />

     <element name="SASLBindResponse" type="sasl:SASLBindResponseType" substitutionGroup="sacred:BindResponse" />

     <element name="SASLBindInfoRequest" type="sasl:SASLBindInfoRequestType" substitutionGroup="sacred:BindInfoRequest" />

     <element name="SASLBindInfoResponse" type="sasl:SASLBindInfoResponseType" substitutionGroup="sacred:BindInfoResponse" />

     <element name="SASLCreateAccountRequest" type="sasl:SASLCreateAccountRequestType" substitutionGroup="sacred:CreateAccountRequest"/>

     <element name="SASLChangeAccountRequest" type="sasl:SASLChangeAccountRequestType" substitutionGroup="sacred:ChangeAccountRequest" />

     <element name="SASLRemoveAccountRequest" type="sasl:SASLRemoveAccountRequestType" substitutionGroup="sacred:RemoveAccountRequest" />

     <complexType name="SASLBindRequestType">
       <annotation>
         <documentation xml:lang="en">
           Element type used by a client to initiate and take part in a
           SASL authentication protocol exchange.

           During initiation, the Mechanism elements are used to identify
           the authentication elements supported by the client and may
           optionally contain Data elements containing the client's
           initial response.

           During the exchange, there must only be single Mechanism
           element and its Data element is used to send the response to
           the server.

           If the client wishes to abort the exchange then it must send a
           response with the BindStatus attribute set to "Abort".  In all
           other cases, the BindStatus must be set to "Continue".
         </documentation>
       </annotation>
       <complexContent>
         <extension base="sacred:RequestType">
           <sequence>
             <element name="Mechanism" type="sasl:SASLMechanismWithData" maxOccurs="unbounded"/>
           </sequence>
           <attribute name="BindStatus" type="sasl:SASLBindStatus" use="optional" default="Continue"/>
         </extension>
       </complexContent>
     </complexType>

     <complexType name="SASLBindResponseType">
       <annotation>
         <documentation xml:lang="en">
           Element type used by the server to respond to the client's
           initial request and to take part in a SASL authentication
           protocol exchange.

           During initiation, the Mechanism elements are used to identify
           the authentication elements supported by the server and must
           be selected from those in the client's request.

           During the exchange, there must only be single Mechanism
           element and its Data element is used to send the challenge to
           the client.

           When the exchange is complete, the BindStatus attribute must
           be set to "Complete".  In all other responses it must be set
           to "Continue".
         </documentation>
       </annotation>
       <complexContent>
         <extension base="sacred:ResponseType">
           <sequence>
             <element name="Mechanism" type="sasl:SASLMechanismWithData" maxOccurs="unbounded"/>
           </sequence>
           <attribute name="BindStatus" type="sasl:SASLBindStatus" use="optional" default="Continue"/>
         </extension>
       </complexContent>
     </complexType>

     <complexType name="SASLBindInfoRequestType">
       <annotation>
         <documentation xml:lang="en">
           Element type used by a client ot request information on
           identified SASL authentication mechanisms.
         </documentation>
       </annotation>
       <complexContent>
         <extension base="sacred:RequestType">
           <sequence>
             <element name="Mechanism" type="sasl:SASLMechanismIdentifier" maxOccurs="unbounded"/>
           </sequence>
         </extension>
       </complexContent>
     </complexType>

     <complexType name="SASLBindInfoResponseType">
       <annotation>
         <documentation xml:lang="en">
           Element type used to return information on a SASL
           authentication mechanism.  This information can then be used
           to form a SASLCreateAccountRequest.
         </documentation>
       </annotation>
       <complexContent>
         <extension base="sacred:BindInfoResponseType">
           <sequence>
             <element name="Mechanism" type="sasl:SASLMechanismInformation" maxOccurs="unbounded"/>
           </sequence>
         </extension>
       </complexContent>
     </complexType>

     <complexType name="SASLCreateAccountRequestType">
       <annotation>
         <documentation xml:lang="en">
           Element type used to create an account with authentication
           information for a particular SASL authentication mechanism.
         </documentation>
       </annotation>
       <complexContent>
         <extension base="sacred:RequestType">
           <sequence>
             <element name="Mechanism" type="sasl:SASLMechanismInformation" maxOccurs="unbounded"/>
           </sequence>
         </extension>
       </complexContent>
     </complexType>

     <complexType name="SASLChangeAccountRequestType">
       <annotation>
         <documentation xml:lang="en">
           Element type used to change the authentication information
           associated with one or more SASL authentication mechanism.
         </documentation>
       </annotation>
       <complexContent>
         <extension base="sacred:RequestType">
           <sequence>
             <element name="Mechanism" type="sasl:SASLMechanismInformation" maxOccurs="unbounded"/>
           </sequence>
         </extension>
       </complexContent>
     </complexType>

     <complexType name="SASLRemoveAccountRequestType">
       <complexContent>
         <extension base="sacred:RequestType">
         </extension>
       </complexContent>
     </complexType>

     <simpleType name="SASLBindStatus">
       <restriction base="string">
         <enumeration value="Complete"/>
         <enumeration value="Abort"/>
         <enumeration value="Continue"/>
       </restriction>
     </simpleType>

     <complexType name="SASLMechanismIdentifier">
       <annotation>
         <documentation xml:lang="en">
           Basic element type used to identify a SASL authentication mechanism.
         </documentation>
       </annotation>
       <attribute name="Name" type="string" use="required"/>
     </complexType>

     <complexType name="SASLMechanismInformation">
       <annotation>
         <documentation xml:lang="en">
           Type used in messages that return information about a SASL
           authentication mechanism.
         </documentation>
       </annotation>
       <complexContent>
         <extension base="sasl:SASLMechanismIdentifier">
           <sequence>
             <any namespace="##other" processContents="strict" />
           </sequence>
         </extension>
       </complexContent>
     </complexType>

     <complexType name="SASLMechanismWithData">
       <annotation>
         <documentation xml:lang="en">
           Type used when a request or response can contain SASL
           mechanism challenge/response data.
         </documentation>
       </annotation>
       <complexContent>
         <extension base="sasl:SASLMechanismIdentifier">
           <sequence>
             <element name="Data" type="base64Binary" minOccurs="0"/>
           </sequence>
         </extension>
       </complexContent>
     </complexType>

   </schema>

 A.3 SRP Schema

   <?xml version="1.0" encoding="UTF-8"?>

   <schema
     targetNamespace="urn:sacred-sasl-srp-2001-11-27"
     xmlns="http://www.w3.org/2001/XMLSchema"
     xmlns:srp="urn:sacred-sasl-srp-2001-11-27"
     xmlns:xbulk="http://www.xmltrustcenter.org/xkms/docs/x-bulk-2001-07-04.xsd"
     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
     elementFormDefault="unqualified" attributeFormDefault="unqualified"

     <import namespace="http://www.xmltrustcenter.org/xkms/docs/x-bulk-2001-07-04.xsd" />
     <import namespace="http://www.w3.org/2000/09/xmldsig#" />

     <element name="MethodInfo" type="srp:MethodInfoType"/>
     <element name="NewAccountInfo" type="srp:NewAccountInfoType"/>
     <element name="ChangeAccountInfo" type="srp:ChangeAccountInfoType"/>

     <complexType name="MethodInfoType">
       <sequence>
         <element name="ServerId" type="string"/>
         <element name="N" type="ds:CryptoBinary"/>
         <element name="g" type="ds:CryptoBinary"/>
         <element name="HashAlg" type="anyURI"/>
       </sequence>
     </complexType>

     <complexType name="NewAccountInfoType">
       <sequence>
         <element name="UserId" type="string"/>
         <element name="salt" type="base64Binary"/>
         <element name="PasswordVerifier" type="ds:CryptoBinary"/>
       </sequence>
     </complexType>

      <complexType name="ChangeAccountInfoType">
       <sequence>
         <element name="salt" type="base64Binary"/>
         <element name="PasswordVerifier" type="ds:CryptoBinary"/>
       </sequence>
     </complexType>

   </schema>

---

From: "Marshall T. Rose" <[email-masked]>
Date: Thu, 6 Dec 2001 13:45:19 -0800

>  than those provided by SASL.

err, the dependence on beep is a good thing simply because it allows you to
avoid having to deal with the 101 administrative issues that arise
otherwise.

if you want to have something that runs on lots of different things, then
can i suggest that you remove the beep support simply because you have very
effectively negated 90% of the advantages of using beep...

/mtr

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 07 Dec 2001 14:32:07 +0000

Magnus, Gareth,

(Trying to split up the issues involved in your proposals...)

Its not clear to me why there's any advantage in adding this, and
it also seems to me to add quite a bit of complexity. So, my
questions are:

- What can I do with this that I couldn't do with just SASL as an 
extensibility mechanism?
- Why would all this be MUST?

Stephen.

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