Browse Source

Accept inbox/client-key.xml as XEP-0399

Jonas Wielicki 1 year ago
parent
commit
c8dc07e7bc
1 changed files with 129 additions and 0 deletions
  1. 129
    0
      xep-0399.xml

+ 129
- 0
xep-0399.xml View File

@@ -0,0 +1,129 @@
1
+<?xml version='1.0' encoding='UTF-8'?>
2
+<!DOCTYPE xep SYSTEM 'xep.dtd' [
3
+  <!ENTITY namespace "urn:xmpp:client-key:0">
4
+  <!ENTITY draft "draft-cridland-kitten-clientkey-00.txt">
5
+  <!ENTITY % ents SYSTEM 'xep.ent'>
6
+%ents;
7
+]>
8
+<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
9
+<xep>
10
+<header>
11
+  <title>Client Key Support</title>
12
+  <abstract>This specification defines an XMPP binding of the supporting functions for the CLIENT-KEY SASL mechanism.</abstract>
13
+  &LEGALNOTICE;
14
+  <number>0399</number>
15
+  <status>Experimental</status>
16
+  <type>Standards Track</type>
17
+  <sig>Standards</sig>
18
+  <approver>Council</approver>
19
+  <dependencies/>
20
+  <supersedes/>
21
+  <supersededby/>
22
+  <shortname>client-key</shortname>
23
+  <registry/>
24
+  <discuss>standards</discuss>
25
+  <author>
26
+    <firstname>Dave</firstname>
27
+    <surname>Cridland</surname>
28
+    <email>dave.cridland@surevine.com</email>
29
+    <jid>dave.cridland@surevine.com</jid>
30
+  </author>
31
+  <revision>
32
+    <version>0.1.0</version>
33
+    <date>2018-01-25</date>
34
+    <initials>XEP Editor (jwi)</initials>
35
+    <remark>Accepted by vote of Council on 2018-01-10.</remark>
36
+  </revision>
37
+  <revision>
38
+    <version>0.0.1</version>
39
+    <date>2018-01-08</date>
40
+    <initials>dwd</initials>
41
+    <remark><p>First draft</p></remark>
42
+  </revision>
43
+</header>
44
+<section1 topic='Introduction' anchor='intro'>
45
+  <p>The CLIENT-KEY SASL mechanism defined in &draft; suggests supporting protocol messages to be present in the application protocol. This specification defines these for XMPP.</p>
46
+</section1>
47
+
48
+  <section1 topic="Typical Flow">
49
+    <p>A typical client might use this protocol alongside that of TOTP, &xep0388;, and &draft; as follows.</p>
50
+    <p>On first use, a client will use a traditional SASL mechanism using SASL2, such as SCRAM. The server will then prompt using &lt;next-authenticate/> to initiate, or perform, TOTP.</p>
51
+    <p>The client will then request a Client Key to reauthenticate later. This may be one or both of a short-term Client Key intended for in-memory storage, perhaps for use with ISR, and a longer-term Client Key used for a "remember this client" to suppress 2FA for a period.</p>
52
+    <p>Later authentications will use CLIENT-KEY or CLIENT-KEY-PLUS, and the server SHOULD suppress TOTP in such cases.</p>
53
+  </section1>
54
+
55
+  <section1 topic="Client Key Support Operations">
56
+    <section2 topic="Client Registration">
57
+      <p>Client registration requests a Client Key from the server. It is typically used to speed reauthentication during a session, and to elide a full reauthentication at the start of a subsequent session.</p>
58
+      <p>In order to register and obtain a Client Key, a client sends an &IQ; of type "set" containing an XML representation of the data required, within a &lt;register/&gt; element qualified by the '&namespace;' namespace, containing four elements in any order. Descriptions of values are here informative; the canonical definition is in &draft;.</p>
59
+      <p>&lt;id/> has a text value of the ClientID, a suitable identifier for the client instance, unique within the scope of the authenticated &BAREJID;.</p>
60
+      <p>&lt;name/> has a text value of the Client Name, a human-readable name for the client instance.</p>
61
+      <p>&lt;key/> has a text value of the ValidationKey, encoded using Base 64. Implementors are strongly advised to take careful note of the requirements of the ValidationKey as discussed in &draft;.</p>
62
+      <p>&lt;ttl/> has a text value containing a integer string representation of the number of seconds the Client Key is requested to last for.</p>
63
+      <p>In the following example, the ValidationKey is H("Random"), and the TTL is for 30 days - a reasonable "Remember this client" option.</p>
64
+      <example><![CDATA[
65
+<iq type='set' id='123456'>
66
+  <register xmlns=']]>&namespace;<![CDATA['>
67
+    <id>213456-987123-123987</iq>
68
+    <name>SuperChatBiscuit on Honest Pete's Mobile OS</name>
69
+    <key>WNiIwIqlYfNw44zul2EhUyqIPXE=</key>
70
+    <ttl>2592000</ttl>
71
+  </register>
72
+</iq>
73
+      ]]></example>
74
+      <p>The server responds with two items of information in a &lt;registered/> element qualified by the '&namespace;' namespace. The EncryptedSecret is contained within a &lt;encrypted-secret/> element as a base64-encoded value, and the &lt;expiry/> element contains a timestamp for expiry.</p>
75
+      <example><![CDATA[
76
+<iq type='result' id='123456'>
77
+  <registered xmlns=']]>&namespace;<![CDATA['>
78
+    <encrypted-secret>WNiIwIqlYfNw44zul2EhUyqIPXE=</encrypted-secret>
79
+    <expiry>2017-10-15T12:00:00Z</expiry>
80
+  </registered>
81
+</iq>
82
+]]></example>
83
+      <p>Note that the expiry time might not be 30 days simply because the client has requested it - the server is free to shorten expiry times.</p>
84
+    </section2>
85
+    <section2 topic="Key Revocation">
86
+      <p>Any authenticated client may revoke a key belonging to the same user by sending an &IQ; of type "set" containing a &lt;revoke/> element qualified by the '&namespace;' namespace, containing a &lt;key/> element whose text value is the ClientID corresponding to the key to be revoked.</p>
87
+      <example><![CDATA[
88
+<iq type='set' id='123456'>
89
+  <revoke xmlns=']]>&namespace;<![CDATA['>
90
+    <id>213456-987123-123987</iq>
91
+  </revoke>
92
+</iq>
93
+      ]]></example>
94
+    </section2>
95
+    <section2 topic="Key Enumeration">
96
+      <p>Any authenticated client may enumerate keys belonging to the same user by sending an &IQ; of type "get" containing a &lt;list/> element qualified by the '&namespace;' namespace.</p>
97
+      <example><![CDATA[
98
+<iq type='get' id='123456'>
99
+  <list xmlns=']]>&namespace;<![CDATA['/>
100
+</iq>
101
+      ]]></example>
102
+      <p>The server responds with an &IQ; of type 'result', containing the &lt;list/> element qualified by the '&namespace;' namespace. This element contains a sequence of &lt;key/> elements each containing (in any order) the &lt;id/>, &lt;name/> and &lt;expiry/> elements as in registration.</p>
103
+      <example><![CDATA[
104
+<iq type='result' id='123456'>
105
+  <list xmlns=']]>&namespace;<![CDATA['>
106
+    <key>
107
+      <id>213456-987123-123987</iq>
108
+      <name>SuperChatBiscuit on Honest Pete's Mobile OS</name>
109
+      <expiry>2017-10-15T12:00:00Z</expiry>
110
+    </key>
111
+    <key>
112
+      <id>313456-987123-123987</iq>
113
+      <name>SuperChatChocolate on Honest Bob's Mobile OS</name>
114
+      <expiry>2018-01-08T12:00:00Z</expiry>
115
+    </key>
116
+  </list>
117
+</iq>
118
+      ]]></example>
119
+    </section2>
120
+  </section1>
121
+
122
+  <section1 topic='Determining Support' anchor='support'>
123
+  <p>Support for this protocol is advertised as the Disco feature '&namespace;'; however clients MAY infer support if the CLIENT-KEY or CLIENT-KEY-PLUS SASL mechanism is supported.</p>
124
+</section1>
125
+
126
+<section1 topic='Security Considerations' anchor='security'>
127
+  <p>Security considerations for this specification are covered within the Internet-Draft &draft; - this specification introduces no further considerations by design, but relies heavily on the guidance given there.</p>
128
+</section1>
129
+</xep>

Loading…
Cancel
Save