1 / 18

OTP-ValidationService

OTP-ValidationService. John Linn, RSA Laboratories 11 May 2005. OTP-ValidationService (OTP-VS) Overview. OTP-VS uses XML Schema, defines a web service request/response protocol to validate OTP credentials

rhonda
Télécharger la présentation

OTP-ValidationService

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OTP-ValidationService John Linn, RSA Laboratories 11 May 2005

  2. OTP-ValidationService (OTP-VS) Overview • OTP-VS uses XML Schema, defines a web service request/response protocol to validate OTP credentials • Using OTP-VS, a relying party (RP) can ask an authentication service (AS) whether OTP data that it has received successfully authenticates a claimant • OTP-VS uses OTP-WSS-Token to represent OTP data • Supports ancillary OTP-related functions (obtaining challenges, PIN management, resynchronization) • Validation transactions can be secured "in band" within OTP-VS protocol (using XML Signature, XML Encryption), externally (e.g., SSL/TLS, IPsec, WSS:SMS), or by relying on security properties of environment • Generic service can be profiled to support the needs of particular OTP methods

  3. OTP-VS Usage Scenario Application Request with OTP OTP-VS Claimant RP AS User OTP-VS operates in a web service environment; claimant-RP protocol can be arbitrary

  4. OTP-VS Premises and Assumptions • RP has prior knowledge of the set of OTP methods that the AS supports • Depending on method and situation, an OTP-VS transaction may span one or more request-response round trips • For example, could request and obtain challenge, then provide an OTPToken based on the challenge to be validated • For another example, PIN change, then authenticate using the new PIN • SOAP binding defined, other bindings possible

  5. OTP-VS Transaction Identifiers and Sequencing • RequestID and SessionID identify the transaction to which messages belong • Client generates new RequestID for initial request • If more than single round-trip, server provides SessionID and client uses that value in subsequent RequestIDs • SequenceID protects sequence integrity of multi-round transactions • Initialized by server, incremented for subsequent roundtrips

  6. OTP-VS Status Framework • Outer level: String codes with enumerated values (e.g., "Continue", "Complete", "Abort", "AccessDenied", others) • Any value except "Continue" or "Complete" terminates transaction • Inner level: CredentialStatus • Generic StatusCodes: "OK", "Unknown", "Failed" • <reason> code, defined for method and/or environment • <message> string, typically describing <reason> value

  7. OTP-VS Signatures • The <signature> element is of type ds:SignatureType from XML Signature and must be present when optional “native” OTP-ValidationService RP authentication is being used. • The URI attribute of the <ds:Reference> element of the <ds:SignedInfo> child element of the <signature> shall reference the complete <validationRequest>element instance by being the NULL ("") reference (i.e., when present, the signature shall be made over a complete <validationRequest> element, excluding the <signature> element itself; this is the http://www.w3.org/2000/09/xmldsig#enveloped-signature transform defined in XML Signature). • Before performing the signature calculation, the RP must canonicalize all elements the signature shall be made over, in accordance with Exclusive XML Canonicalization. • The <ds:KeyInfo> child element of the <signature> element SHALL identify the signing key. • The AS must verify that the signing key is associated with the identified RP and must verify the signature before performing any security-related processing of the request.

  8. OTP-VS Encryption • A validation request or response may optionally be encrypted. In this case, a sender shall form an ordinary (i.e. plaintext) validation request or response, encrypt its content using the XML Encryption “Content” type, and then replace the contents of the plaintext validation request or response with an <encryptedRequest> or <encryptedResponse> element that carries the encrypted data in its <xenc:CipherValue> element. • In a reciprocal fashion, a recipient of a validation request or response carrying an <encryptedRequest> or <encryptedResponse> element shall decrypt the <xenc:CipherValue> child of this element and replace the content of the received validation request or response (i.e. the <encryptedRequest> or <encryptedResponse> element itself) with the decrypted data, before processing the content of the request. • When applying both encryption and signature, signatures are applied first (on plaintext data) • Note: Encryption approach does not protect top-level message attributes

  9. OTP-VS Selected Basic Types <complexType name="Request" abstract="true"> <attribute name="version" type="otps-vs:Version" use="required"/> <attribute name="requestID" type="otps-vs:Identifier" use="required"/> <attribute name="sequenceID" type="nonNegativeInteger"/> </complexType> <complexType name="Response" abstract="true"> <attribute name="version" type="otps-vs:Version" use="required"/> <attribute name="status" type="otps-vs:Status" use="required"/> <attribute name="requestID" type="otps-vs:Identifier"/> <attribute name="sessionID" type="otps-vs:Identifier"/> <attribute name="sequenceID" type="nonNegativeInteger"/> </complexType> <complexType name="CredentialStatus"> <sequence> <element name="code" type="otps-vs:StatusCode"/> <element name="reason" type="otps-vs:ReasonCode" minOccurs="0"/> <element name="message" type="string" minOccurs="0"/> </sequence> </complexType>

  10. OTP-VS Status Codes <simpleType name="Status"> <restriction base="string"> <enumeration value="Continue"/> <enumeration value="Complete"/> <enumeration value="Abort"/> <enumeration value="AccessDenied"/> <enumeration value="MalformedRequest"/> <enumeration value="UnknownRequest"/> <enumeration value="UnknownCriticalExtension"/> <enumeration value="UnsupportedVersion"/> <enumeration value="UnsupportedOTPAlgorithm"/> <enumeration value="Unauthorized"/> <enumeration value="NotAuthoritative"/> <enumeration value=”NoCredentials”/> </restriction> </simpleType>

  11. OTP-VS Payload and DataRequest <complexType name="Payload"> <choice> <element name="otpToken" type="otps-wst:OTPToken"/> <element name="challenge" type="otps-vs:Challenge"/> <element name="newPIN" type="otps-vs:NewPin"/> <element name="dataRequest" type="otps-vs:DataRequest"/> <any namespace="##other" processContents="strict"/> </choice> </complexType> <complexType name="DataRequest"> <choice> <element name="needChallenge"/> <element name="needNextOTP"/> <any namespace="##other" processContents="strict"/> </choice> </complexType>

  12. OTP-VS NewPIN <complexType name="NewPin"> <sequence> <element name="pin" type="string" minOccurs=”0”/> </sequence> <attribute name=”required” type=”boolean” default=”false”/> <attribute name=”alphanumeric” type=”boolean"default=”false”/> <attribute name=”minLength” type=”nonNegativeInteger”/> <attribute name=”maxLength” type=”nonNegativeInteger”/> </complexType>

  13. <complexType name="ValidationRequest"> <annotation> <documentation xml:lang="en"> Message sent to Validation service to initiate or continue validation of OTP credentials. </documentation> </annotation> <complexContent> <extension base="otps-vs:Request"> <choice> <sequence> <element name="payload” type="otps-vs:Payload"/> <element name="extensions" type="otps-vs:Extensions" minOccurs="0"/> <element name=”signature” type=”ds:SignatureType” minOccurs=”0”/> </sequence> <element name="encryptedRequest" type="xenc:EncryptedDataType"/> </choice> <attribute name=”algorithmID” type=”anyURI”/> <attribute name="siteID" type="otps-vs:Identifier"/> <attribute name="update" type="boolean" default="true"/> </extension> </complexContent> </complexType> OTP-VS ValidationRequest

  14. OTP-VS ValidationResponse <complexType name="ValidationResponse"> <annotation> <documentation xml:lang="en"> Message sent from Validation service responding to a validation request. </documentation> </annotation> <complexContent> <extension base="otps-vs:Response"> <choice> <sequence> <element name="credentialStatus" type="otps-vs:CredentialStatus" minOccurs=”0”/> <element name="payload” type="otps-vs:Payload" minOccurs=”0”/> <element name="extensions" type="otps-vs:Extensions" minOccurs="0"/> <element name=”signature” type=”ds:SignatureType” minOccurs=”0”/> </sequence> <element name="encryptedResponse" type="xenc:EncryptedDataType"/> </choice> <attribute name=”algorithmID” type=”anyURI”/> </extension> </complexContent> </complexType>

  15. OTP-VS SOAP Binding Aspects • OTP-VS requests and responses carried within SOAP bodies • Single unencoded request or response carried in a body • SOAP faults generated only for messages that cannot be processed at OTP-ValidationService layer • Other errors reported within OTP-VS status framework • SOAPAction value defined for optional HTTP header use, other HTTP headers unconstrained • Cache-Control should be set to disable caching

  16. OTP-VS Security Service Requirements • Authentication • Generally AS to RP, sometimes RP to AS as well • Confidentiality • Generally when carrying OTP or PIN values, other needs vary • Integrity • Generally, at per-message and transaction sequence levels • Non-repudiation • May be needed for some accountability scenarios

  17. OTP-VS Possible Futures • Schema changes • Adopt UpperCamelCase naming convention • Alignment with OTP-WSS-Token identifiers • XML Schema namespace qualification? • Other methods or extended facilities • Profile to carry EAP within OTP-VS web service transaction?

  18. OTP-VS Next Steps • Agreement and stabilization of document content • Consideration of added features or new methods • Methods can be specified separately from base document • Possible future contribution of document?

More Related