OTP-ValidationService: Summary, Pending Changes, and Issues

1. OTP-ValidationService: Summary, Pending Changes, and Issues John Linn, RSA Laboratories OTPS Workshop, October 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 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

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

9. Current Draft Status • Current Draft 2 (29 August) made changes including: • qualified XML Schema references, UpperCamelCase naming • added ClientInfoType extension to enable linkage of validation operation with client-provided identifier • added ServerInfoType extension to carry server state for use in load-balanced environment • added statement about TLS/SSL encapsulation as mandatory-to-implement security method, • added statements about TLS/SSL ciphersuites and XML Encryption/Signature algorithms to be supported for interoperability

10. Planned changes for subsequent draft • Expand discussion of string comparison rules • Add SignatureValidationFailed, DecryptionFailed error codes • Allow requests for challenges to identify user and/or device's key

11. Issues Being Discussed: I • RequestID uniqueness, generation, relation with ClientInfoType? • ACTION PROPOSED: no change required • Naming convention for enumerations? • ACTION PROPOSED: no change required • Discriminate OTP vs. PIN failures at VS level or leave for method-specific <Reason> where desired? • ACTION PROPOSED: no VS-level change required

12. Issues Being Discussed: II • Cross-method <Reason> code definitions? • ACTION PROPOSED: clarify that reason codes are to be defined at method level, not by individual implementations, and can therefore support interoperation across different implementations of an OTP method • Display message internationalization; administrative vs. end-user usage? • ACTION PROPOSED: clarify intent as being confined to administrator-directed messages, with any corresponding end-user display or internationalization outside VS scope

13. Issues Being Discussed: III • Further discussion re PIN encryption? • ACTION PROPOSED: clarify that externally encrypted representations may be carried, within VS datatype constraints • Same payload for requests and responses, or split into two types? • DISCUSSION REQUIRED: tentative preference for splitting • Further processing rules or protocol mechanisms re optional encryption? • DISCUSSION REQUIRED: could be left wholly to local policy, or processing rules could state that valid encrypted requests should receive encrypted responses

14. Areas With Intended Support, Seeking Independent Validation • Challenge-response profile example • MQ support • Indicating authentication strength within verification responses • Supporting multiple challenge-response sets

15. 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?