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

Abstract:This document specifies a two-factor authentication mechanism to check if a XMPP account exists and if it is trying to use or access services or resources of certain device, application or service. Authentication mechanism is based on transmitting a password using Ad-Hoc Commands. Password is calculated from shared secret.
Author:Teemu Väisänen
Copyright:© 1999 - 2014 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status:ProtoXEP
Type:Standards Strack
Version:0.0.1
Last Updated:2013-12-19

WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document is not yet an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.


Table of Contents


1. Introduction
2. Requirements
3. Discovery
4. Glossary
5. Use Cases
    5.1. Authenticate with a Time-Based One-Time Password (TOTP)
    5.2. Authenticate with a one-time pad
6. Error Handling
7. Implementation Notes
8. Business Rules
9. Security Considerations
10. IANA Considerations
11. XMPP Registrar Considerations
    11.1. Protocol Namespaces
    11.2. Field Standardization
12. XML Schema

Appendices
    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History


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:

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:

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.

HMAC
Keyed-Hashing for Message Authentication
HMAC-SHA-256
HMAC-SHA-256 is the realization of the HMAC message authentication code using the SHA-256 hash function.
HMAC-SHA-512
HMAC-SHA-512 is the realization of the HMAC message authentication code using the SHA-512 hash function.
HOTP
HMAC-Based One-Time Password Algorithm
Local Client
An XMPP client that wants to authenticate itself to Remote Client.
One-time pad
Example of perfectly secret encryption scheme.
OTP
A one-time password is a password that is valid for only one login session or transaction.
Prover
Same as Local Client.
Remote Client
An XMPP client that authenticates Local Client.
SHA
US Secure Hash Algorithms
TOTP
Time-Based One-Time Password Algorithm
Verifier
Same as Remote Client.

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

5.1 Authenticate with a Time-Based One-Time Password (TOTP)

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.

Example 1. Local Client (Prover) requests to authenticate with a TOTP to a Remote Client (Verifier)

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

Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form.

Example 2. Remote Client (Verifier) replies with a form to set a TOTP

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

Example 3. Local Client (Prover) submits the TOTP secret form to Remote Client (Verifier)

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

After receiving a correct secret, the Verifier informs Prover of completion.

Example 4. Remote Client (Verifier) informs Local Client (Prover) of completion

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

5.2 Authenticate with a one-time pad

As described in RFC 4949 [10] 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.

Example 5. Local Client (Prover) requests to authenticate with a one-time pad to a Remote Client (Verifier)

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

Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form.

Example 6. Remote Client (Verifier) replies with a form to set a one-time pad

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

Example 7. Local Client (Prover) submits the one-time pad form to Remote Client (Verifier)

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

After receiving a one-time pad, the Verifier informs Prover of completion.

Example 8. Remote Client (Verifier) informs Local Client (Prover) of completion

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

Table 1: Error Conditions

Condition Cause
<feature-not-implemented/> 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.
<service-unavailable/> The ad-hoc commands protocol is not supported.
<payment-required/> 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 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:

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

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

11.1 Protocol Namespaces

The XMPP Registrar includes 'http://jabber.org/protocol/auth' in its registry of protocol namespaces (see <http://xmpp.org/registrar/namespaces.html>).

11.2 Field Standardization

Field Standardization for Data Forms (XEP-0068) [14] defines a process for standardizing the fields used within Data Forms scoped by a particular namespace (see also <http://xmpp.org/registrar/formtypes.html>). The reserved fields for the 'http://jabber.org/protocol/auth' namespace are specified below.

Registry Submission

<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

Copyright

This XMPP Extension Protocol is copyright (c) 1999 - 2013 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://www.xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).

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 <http://xmpp.org/about/discuss.shtml> 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

1. XEP-0175: Best Practices for Use of SASL ANONYMOUS <http://xmpp.org/extensions/xep-0175.html>.

2. RFC 6238: TOTP: Time-Based One-Time Password Algorithm <http://tools.ietf.org/html/rfc6238>.

3. XEP-0146: Remote Controlling Clients <http://xmpp.org/extensions/xep-0146.html>.

4. XEP-0250: C2C Authentication Using TLS <http://xmpp.org/extensions/xep-0250.html>.

5. XEP-0050: Ad-Hoc Commands <http://xmpp.org/extensions/xep-0050.html>.

6. XEP-0030: Service Discovery <http://xmpp.org/extensions/xep-0030.html>.

7. XEP-0115: Entity Capabilities <http://xmpp.org/extensions/xep-0115.html>.

8. RFC 4226: HOTP: An HMAC-Based One-Time Password Algorithm <http://tools.ietf.org/html/rfc4226>.

9. RFC 4086: Randomness Requirements for Security <http://tools.ietf.org/html/rfc4086>.

10. RFC 4949: Internet Security Glossary, Version 2 <http://tools.ietf.org/html/rfc4949>.

11. XEP-0086: Error Condition Mappings <http://xmpp.org/extensions/xep-0086.html>.

12. XEP-0324: Internet of Things - Provisioning <http://xmpp.org/extensions/xep-0324.html>.

13. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

14. XEP-0068: Field Data Standardization for Data Forms <http://xmpp.org/extensions/xep-0068.html>.


Appendix H: Revision History

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

Version 0.0.1 (2013-12-19)

First draft.

(tuv)

END