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

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

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

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

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" — code, defined for method and/or environment — string, typically describing value

OTP-VS Signatures The 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 element of the child element of the shall reference the complete element instance by being the NULL ("") reference (i.e., when present, the signature shall be made over a complete element, excluding the element itself; this is the 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 child element of the 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.

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 or element that carries the encrypted data in its element. In a reciprocal fashion, a recipient of a validation request or response carrying an or element shall decrypt the child of this element and replace the content of the received validation request or response (i.e. the or 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

OTP-VS Selected Basic Types

OTP-VS Status Codes

OTP-VS Payload and DataRequest

OTP-VS NewPIN

OTP-VS ValidationRequest Message sent to Validation service to initiate or continue validation of OTP credentials.

OTP-VS ValidationResponse Message sent from Validation service responding to a validation request. <element name="credentialStatus" type="otps-vs:CredentialStatus" minOccurs=”0”/>

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

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

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?

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?