First draft.
+ This document offers mechanisms to solve the following problem: + There are two XMPP client entities (Verifier and Prover). The + Verifier can be presenting e.g., a physical device, an application + or a service and and the Prover is presenting an XMPP account of + user entity (e.g., a human) that wants to login. + + Before the Verifier can execute or ask executing any access + control mechanism, e.g., to check if the Prover's XMPP accout is + authorized use certain resource(s), the Prover must be authenticated. + We present usage of two-factor authentication in which the following + authentication factors are used: +
++ In addition to these, described mechanism offers possibility to + approve authentication inside only a certain time-slot. +
++ Prover and Verifier entities mean same as in &rfc6238; but are + implemented as two XMPP clients. When using terms of &xep0146;, + Prover is Local Client and Verifier is Remote Client. +
++ Several mechanisms for client-to-client authentication, such as + &xep0250; exist and can be used with the protocol defined in + this document. This document describes a new simple and + extendable protocol for two-factor one-way client authentication + by specifying a profile on &xep0050;. One-way here means that + the actual user (e.g, a human) of Prover's XMPP Client is not + required to know anything about the Verifier. +
+This document addresses the following requirements:
++ A client MAY advertise any authentication commands it + supports via &xep0030; (as described in XEP-0050). +
++ If these commands are advertised, &xep0115; can be used to + query capability of authentication commands in a client. + If the Prover and the Verifier are working on a same physical + device, they both MAY know the exact format and existence of supported + commands. +
++ The following table lists common terms and corresponding descriptions. +
++ This document defines a profile of XEP-0050 that + enables a client to perform the following tasks on a entity + that or which resources it wants to use: +
++ Although this document aims to define common use cases for + authentication, an implementation or deployment MAY support any + subset and MAY support additional commands not defined herein. +
++ Note: The text that follows assumes that implementors have + read and understood XEP-0050, password + generation algorithms described in &rfc4226; and RFC 6238, + and randomness requirements described in &rfc4086;, + and know about one-time pads and perfect secrecy. +
+ ++ Time-Based One-Time Password (TOTP) algorithm described in + RFC 6238 is an extension of the HMAC-based + One-Time Password (HOTP) algorithm defined in RFC 4226, + to support the time-based moving factor. In TOTP, time + reference and a time step replaces the counter in the HOTP + computation. +
+Unless an error occurs (see the + Error Handling section below), the service + SHOULD return the appropriate form.
+ +After receiving a correct secret, the Verifier informs Prover of completion.
++ As described in &rfc4949; one-time pad is an encryption + algorithm in which the key is a random sequence of symbols + and each symbol is used for encryption only one time, + i.e., used to encrypt only one plaintext symbol and thus + produce only one ciphertext symbol and thus produce only one + ciphertext symbol. A copy of the key is used similarly + for decryption. +
+Unless an error occurs (see the + Error Handling section below), the service + SHOULD return the appropriate form.
+ + +After receiving a one-time pad, the Verifier informs Prover of completion.
++ Several error conditions are possible when a Prover sends a + command request to the Verifier, as defined in the following + table. If one of these errors occurs, the Verifier entity MUST + return an error stanza to the requesting Prover. +
+ +Condition | +Cause | +
---|---|
&feature; | +The specific command is not supported (even though the + ad-hoc commands protocol is). | +
&forbidden; | +The requesting entity does not have sufficient + privileges to perform the command. | +
&unavailable; | +The ad-hoc commands protocol is not supported. | +
&payment; | +If the user needs to provide payment in order to access + to resources behind the Verifier (e.g., if the user is not + in the customer database or the customer's account is not + paid up). | +
For the syntax of these errors, see &xep0086;. Naturally, other + errors may be returned as well.
++ Implementations of this protocol MAY introduce extra forms for + commands and MAY use other secret key generation mechanisms than + currently presented TOTP and one-time pad. +
++ There are several secure ways to transmit one-time pads or the + shared secret that is used in TOTP from Verifier to the Prover. + If both Verifier and Prover entities are running in one + application inside one device, the shared secret can be + generated and transmitted inside running implementation and + be removed right after the usage. +
+Presented authentication mechanism offers possibilities to + execute at least the following access policies and different + combinations of them, but their detailed descriptions and how + policies are transmitted to the Verifier are out of scope of + this document:
++ Mechanisms for determining when a command can be executed based + on permissions or rights are considered specific to the + application and/or implementation of XEP-0050, as + defined in XEP-0050. + + In this application a command SHOULD be executed if and only + if it comes from full user's JID that is already known to + the Verifier. This decreases possibility to execute, e.g, + relay attacks. + + Determining other permissions or rights are considered specific + to access policies of systems, as presented in + Business Rules section. +
++ Possibility of executing Denial-of-service (DoS) attacks against + the Verifier can be reduced by ending processing of received + messages coming from not authorized JIDs or containing incorrect + secret as early as possible. +
++ Randomness requirements for security described in + RFC 4086 apply. +
++ When using TOTP, security considerations of + RFC 6238 apply. +
++ When using TOTP, HMAC-SHA-256 or HMAC-SHA-512 functions SHOULD + be used instead of the HMAC-SHA-1 that has been specified for + the HOTP computation in RFC 4226. +
++ When using TOTP, when an OTP is generated at the end of a + time-step window, the receiving time most likely falls into the + next time-step window. A validation system MUST set a policy + for an acceptable OTP transmission delay window for validation. + A larger acceptable delay window would expose a larger window + for attacks, so as in RFC 6238, we RECOMMEND that + at most one time step is allowed as the network delay. +
++ As described in Introduction, the + user of the Prover XMPP client does not necessarily know + anything about the Verifier. In addition to this, the user + does not necessarily know what the device or the application + will do after a succesful authentication. Notice that this + problem relates to every closed source XMPP client + implementations, thus implementations' code SHOULD be open + source. +
++ When using one-time pads, to ensure one-time use, the copy of + the key used for encryption MUST be destroyed after use, as + is the copy used for decryption. +
++ When using one-time pads, commands containing pads that have + incorrect pad length, SHOULD not be executed. +
+ ++ This document requires no interaction with &IANA;. +
+The XMPP Registrar includes 'http://jabber.org/protocol/auth' + in its registry of protocol namespaces (see &NAMESPACES;).
+&xep0068; defines a process for standardizing the fields used + within Data Forms scoped by a particular namespace + (see also &FORMTYPES;). The reserved fields for the + 'http://jabber.org/protocol/auth' namespace are specified + below.
+
+ http://jabber.org/protocol/auth
+ XEP-XXXX
+ Forms used for authenticating clients
+
+
+
+ ]]>
+ + Because the protocol defined here is a profile of + XEP-0050, no schema definition is needed. +
+