Re: SACRED Protocol (long!)
Magnus Nystrom <[email protected]> Thu, 6 Dec 2001 10:30:45 -0500 (Eastern Standard Time)
| Newsgroups | gmane.ietf.sacred |
|---|---|
| Message-ID | <Pine.WNT.4.31.0112061028560.1472-100000@mnystrom-lap> |
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>