XEP-xxxx: Two-factor user authentication with a shared secret

1. Introduction¶

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:

• A knowledge factor that means something only the user knows. In this application this knowledge is a shared secret known only by the Prover and Verifier, and a full JID of the Verifier where a password calculated from this secret must be sent to. Notice that Prover's XMPP account's username and password are not necessarily used as knowledge factors, if, e.g., mechanisms presented in Best Practices for Use of SASL ANONYMOUS (XEP-0175) [1] are used.
• The second factor is a possession factor that means something only the user has, e.g., a device or application that the user wants to use. The shared secret can be told only to certain Prover XMPP account that is running in a certain device or in certain application.

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 RFC 6238 [2] but are implemented as two XMPP clients. When using terms of Remote Controlling Clients (XEP-0146) [3], Prover is Local Client and Verifier is Remote Client.

Several mechanisms for client-to-client authentication, such as C2C Authentication Using TLS (XEP-0250) [4] 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 Ad-Hoc Commands (XEP-0050) [5]. 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.

2. Requirements¶

This document addresses the following requirements:

• Enable the Verifier entity to perform authentication of their users (e.g., humans) by verifying that a Prover entity holds a shared secret.
• Verifier's and Prover's XMPP accounts do not necessarily need to know each other beforehand nor be contacts.
• Re-use existing XMPP and Jabber protocols wherever possible.

3. Discovery¶

A client MAY advertise any authentication commands it supports via Service Discovery (XEP-0030) [6] (as described in XEP-0050).

If these commands are advertised, Entity Capabilities (XEP-0115) [7] 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.

4. Glossary¶

The following table lists common terms and corresponding descriptions.

5. Use Cases¶

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:

1. Authenticate with a Time-Based One-Time Password (TOTP)
2. Authenticate with a one-time-pad
3. Authenticate with a ...

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 Ad-Hoc Commands (XEP-0050) [5], password generation algorithms described in RFC 4226 [8] and RFC 6238 [2], and randomness requirements described in RFC 4086 [9], and know about one-time pads and perfect secrecy.

<iq from='juliet@example.com/chamber'
    to='juliet@example.com/balcony'
    type='set'
    id='set-totp-1'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           action='execute'
           node='http://jabber.org/protocol/auth#set-totp'/>
</iq>
        

<iq from='juliet@example.com/balcony'
    to='juliet@example.com/chamber'
    type='result'
    id='set-totp-1'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           node='http://jabber.org/protocol/auth#set-totp'
           sessionid='set-totp:20131020T1320Z'
           status='executing'>
    <actions>
	  <complete />
    </actions>
    <x xmlns='jabber:x:data' type='form'>
      <title>Time-Based One-Time Password</title>
      <instructions>Send a Time-Based One-Time Password</instructions>
      <field type='text-single'
             var='totp'>
             label='TOTP'>
      </field>
    </x>
  </command>
</iq>
        

<iq from='juliet@example.com/chamber'
    to='juliet@example.com/balcony'
    type='set'
    id='set-totp-2'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           node='http://jabber.org/protocol/auth#set-totp'
           sessionid='set-status:20131020T1320Z'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='totp'>
        <value>218418045</value>
      </field>
    </x>
  </command>
</iq>
        

<iq from='juliet@example.com/balcony'
    to='juliet@example.com/chamber'
    type='result'
    id='set-totp-2'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           node='http://jabber.org/protocol/auth#set-totp'
           sessionid='set-status:20131020T1320Z'
           status='completed'/>
</iq>
        

<iq from='juliet@example.com/chamber'
    to='juliet@example.com/balcony'
    type='set'
    id='set-otpad-1'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           action='execute'
           node='http://jabber.org/protocol/auth#set-otpad'/>
</iq>
        

<iq from='juliet@example.com/balcony'
    to='juliet@example.com/chamber'
    type='result'
    id='set-otpad-1'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           node='http://jabber.org/protocol/auth#set-otpad'
           sessionid='set-totp:20131125T1022Z'
           status='executing'>
    <actions>
	  <complete />
    </actions>
    <x xmlns='jabber:x:data' type='form'>
      <title>One-time pad</title>
      <instructions>Send a one-time pad</instructions>
      <field type='text-single'
             var='otpad'>
             label='OTPAD'>
      </field>
    </x>
  </command>
</iq>
        

<iq from='juliet@example.com/chamber'
    to='juliet@example.com/balcony'
    type='set'
    id='set-otpad-2'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           node='http://jabber.org/protocol/auth#set-otpad'
           sessionid='set-status:20131125T1022Z'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='totp'>
        <value>umeet321oop</value> <!-- TODO: VAIHDA -->
      </field>
    </x>
  </command>
</iq>
        

<iq from='juliet@example.com/balcony'
    to='juliet@example.com/chamber'
    type='result'
    id='set-otpad-2'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           node='http://jabber.org/protocol/auth#set-otpad'
           sessionid='set-status:20131125T1022Z'
           status='completed'/>
</iq>
        

6. Error Handling¶

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.

For the syntax of these errors, see Error Condition Mappings (XEP-0086) [11]. Naturally, other errors may be returned as well.

7. Implementation Notes¶

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.

8. Business Rules¶

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:

• The policy MAY allow only anonymous XMPP accounts, only non-anonymous XMPP accounts, or both, to be verified and/or to access certain resources. No additional access control mechanisms are necessarily needed.
• The policy MAY allow, e.g., only JIDs in certain domains, JIDs in a certain whitelist, JIDs in certain roster group(s), or JIDs with certain subscription types to be verified and/or to access certain resources. Additional mechanisms are required, e.g., to check wanted roster.

In each case, the Verifier MAY check Prover's JID right after receiving the first Ad-Hoc command or after a succesful verification process.

If Prover's JID is not approved, the Verifier SHOULD reply with <forbidden/> error message.

After the a succesful verification the Verifier can, e.g.,

• start the wanted process,
• ask access rights from additional provision servers, e.g. with Internet of Things - Provisioning (XEP-0324) [12], and/or
• give access to the wanted resource.

9. Security Considerations¶

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.

10. IANA Considerations¶

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [13].

11. XMPP Registrar Considerations¶

<form_type>
  <name>http://jabber.org/protocol/auth</name>
  <doc>XEP-XXXX</doc>
  <desc>Forms used for authenticating clients</desc>
  <field var='set-totp'
         type='text-single'
         label='Time-Based One-Time Password'/>
  <field var='set-otpad'
         type='text-single'
         label='One-time pad'/>
</form_type>
    

12. XML Schema¶

Because the protocol defined here is a profile of XEP-0050, no schema definition is needed.

Appendices

Appendix A: Document Information¶

Series

XEP

Number

xxxx

Publisher

XMPP Standards Foundation

Status

ProtoXEP

Type

Standards Strack

Version

0.0.1

Last Updated

2013-12-19

Approving Body

XMPP Council

Dependencies

XMPP Core, XEP-0050

Supersedes

None

Superseded By

None

Short Name

NOT_YET_ASSIGNED

This document in other formats: XML  PDF

Appendix B: Author Information¶

Teemu Väisänen

Email

Teemu.Vaisanen@vtt.fi

JabberID

uolevi@gmail.com

Appendix C: Legal Notices¶

Appendix D: Relation to XMPP¶

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue¶

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance¶

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes¶

Appendix H: Revision History¶

Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/

1. Version 0.0.1 (2013-12-19)¶

   First draft.

   tuv

Appendix I: Bib(La)TeX Entry

@report{väisänen2013xepxxxx,
  title = {Two-factor user authentication with a shared secret},
  author = {Väisänen, Teemu},
  type = {XEP},
  number = {xxxx},
  version = {0.0.1},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-xxxx.html},
  date = {2013-12-19/2013-12-19},
}

END