1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-17 06:45:04 -05:00
xeps/xep-0257.xml
Peter Saint-Andre 64a830c57f initial version
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2598 4b5297f7-1745-476d-ba37-a9c6900126ab
2009-01-05 21:15:36 +00:00

199 lines
10 KiB
XML

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Client Certificate Management for SASL EXTERNAL</title>
<abstract>This specification defines a method to manage client certificates that can be used with SASL External to allow clients to log in without a password.</abstract>
&LEGALNOTICE;
<number>0257</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0178</spec>
<spec>XEP-0189</spec>
</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
<shortname>NOT YET ASSIGNED</shortname>
<author>
<firstname>Dirk</firstname>
<surname>Meyer</surname>
<email>dmeyer@tzi.de</email>
<jid>dmeyer@jabber.org</jid>
</author>
<revision>
<version>0.1</version>
<date>2009-01-05</date>
<initials>psa</initials>
<remark><p>Initial published version.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2008-11-28</date>
<initials>dm</initials>
<remark><p>Add Security Considerations, improve reference to XEP-0178.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2008-11-18</date>
<initials>dm</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>An XMPP client needs a user name and a password to log into an account. Many clients provide a mechanism to store these credentials to automatically log in into an account. While this practice is very user friendly, it is a security risk for some devices. Mobile devices like a phone or a laptop may get stolen, providing the thief with the required password. Mobile phones are particular insecure: providing the password on the keypad for each log in is too complicated and the risk of loosing the phone is high.</p>
<p>A solution to this problem is to allow a client to log in without knowing the password. XMPP as specified in &rfc3920; and provisionally clarified in &rfc3920bis; allows the use of any SASL mechanism (see &rfc4422;) in the authentication of XMPP entities, including the SASL EXTERNAL mechanism. &xep0178; defines the usage of X.509 certificates used in the TLS handshake. This document provides a mechanism to manage different user certificates.</p>
</section1>
<section1 topic='Certificate Management' anchor='manage'>
<p>From the user's point of view the initial client configuration is the same. The user needs to provide the user name and the password for the client to connect to the XMPP server. The main difference is that the client MUST NOT store the password for later use and MUST create an X.509 certificate for future logins. It does not matter if the certificate is self-signed or issued by a trusted third party.</p>
<section2 topic='Add X.509 Certificate' anchor='add'>
<p>After the client has logged in and created the certificate, it uploads the certificate to the server. The XML representation of the certificate from &xep0189; is used to describe a certificate. The client also SHOULD provide a name for the certificate to make it possible for the user to manage the different client certificates.</p>
<example caption='Client Uploads an X.509 Certificate'><![CDATA[
<iq type='set'
from='hamlet@shakespeare.lit/denmark'
id='append'>
<append xmlns='urn:xmpp:tmp:saslcert'>
<name>Mobile Client</name>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>428b1358a286430f628da23fb33ddaf6e474f5c5</name>
<x509cert>
MIICCTCCAXKgAwIBAgIJALhU0Id6xxwQMA0GCSqGSIb3DQEBBQUAMA4xDDAKBgNV
BAMTA2ZvbzAeFw0wNzEyMjgyMDA1MTRaFw0wODEyMjcyMDA1MTRaMA4xDDAKBgNV
BAMTA2ZvbzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0DPcfeJzKWLGE22p
RMINLKr+CxqozF14DqkXkLUwGzTqYRi49yK6aebZ9ssFspTTjqa2uNpw1U32748t
qU6bpACWHbcC+eZ/hm5KymXBhL3Vjfb/dW0xrtxjI9JRFgrgWAyxndlNZUpN2s3D
hKDfVgpPSx/Zp8d/ubbARxqZZZkCAwEAAaNvMG0wHQYDVR0OBBYEFJWwFqmSRGcx
YXmQfdF+XBWkeML4MD4GA1UdIwQ3MDWAFJWwFqmSRGcxYXmQfdF+XBWkeML4oRKk
EDAOMQwwCgYDVQQDEwNmb2+CCQC4VNCHesccEDAMBgNVHRMEBTADAQH/MA0GCSqG
SIb3DQEBBQUAA4GBAIhlUeGZ0d0msNVxYWAXg2lRsJt9INHJQTCJMmoUeTtaRjyp
ffJtuopguNNBDn+MjrEp2/+zLNMahDYLXaTVmBf6zvY0hzB9Ih0kNTh23Fb5j+yK
QChPXQUo0EGCaODWhfhKRNdseUozfNWOz9iTgMGw8eYNLllQRL//iAOfOr/8
</x509cert>
</keyinfo>
</append>
</iq>
]]></example>
<p>The server either returns an empty result or an error. From now on the client can use that certificate to authenticate the user using SASL EXTERNAL.</p>
</section2>
<section2 topic='Request a list of all Certificates'>
<p>A user may want to get a list of all certificates that can be used for SASL EXTERNAL. The client can query the list of the items by sending an items iq stanza.</p>
<example caption='Client requests List of X.509 Certificates'><![CDATA[
<iq type='get'
from='hamlet@shakespeare.lit/denmark'
id='query'>
<items xmlns='urn:xmpp:tmp:saslcert'/>
</iq>
]]></example>
<p>The server then returns the list of all known certificates including the user provided name.</p>
<example caption='Server sends List of known X.509 Certificates'><![CDATA[
<iq type='result'
to='hamlet@shakespeare.lit/denmark'
id='query'>
<items xmlns='urn:xmpp:tmp:saslcert'>
<item id='428b1358a286430f628da23fb33ddaf6e474f5c5'>
<name>Mobile Client</name>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>428b1358a286430f628da23fb33ddaf6e474f5c5</name>
<x509cert>
...
</x509cert>
</keyinfo>
</item>
<item id='571b23d99892f4566017426e92c377288ed6c983'>
<name>Laptop</name>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>571b23d99892f4566017426e92c377288ed6c983</name>
<x509cert>
...
</x509cert>
</keyinfo>
</item>
</items>
</iq>
]]></example>
</section2>
<section2 topic='Revoke a Certificate'>
<p>The user may want to revoke a certificate from a stolen or compromised device. Another reason is that the client created a new certificate because the current one will expire in some days. After the client created a new certificate for itself it MAY revoke the old certificate for future usage.</p>
<example caption='Client revokes an X.509 Certificate'><![CDATA[
<iq type='get'
from='hamlet@shakespeare.lit/denmark'
id='revoke'>
<revoke xmlns='urn:xmpp:tmp:saslcert'/>
<item id='428b1358a286430f628da23fb33ddaf6e474f5c5'>
<compromised/>
</item>
</revoke>
</iq>
]]></example>
<p>The revoke stanza can contain more than one item to revoke. The server MUST remove the certificates with the given ids from the list. If the additional information compromised is added, the server SHOULD close the stream to a client logged in using that certificate for the SASL EXTERNAL mechanism.</p>
</section2>
</section1>
<section1 topic='SASL EXTERNAL' anchor='sasl'>
<p>The protocol flow is similar to the one described in XEP-0178. Only step 9 is different: the certificate does not need to be signed by a trusted entity if the certificate was uploaded by the user. The server still MUST reject the certificate if it is expired. The client certificate SHOULD include a JID as defined in sections 15.2.1.2. and 15.2.1.3. in rfc3920bis: a JID MUST be represented as an XmppAddr, i.e., as a UTF8String within an otherName entity inside the subjectAltName.</p>
<example caption='subjectAltName using the "id-on-xmppAddr" format'><![CDATA[
subjectAltName=otherName:id-on-xmppAddr;UTF8:hamlet@shakespeare.lit
]]></example>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>&xep0077; defines a mechanism to change the password without knowing the current one. If the server supports password change it MUST return not-authorized for clients logged in using SASL EXTERNAL and MAY include a password change form requiring the old password.</p>
<example caption='Password Change'><![CDATA[
<iq type='set' to='shakespeare.lit' id='change1'>
<query xmlns='jabber:iq:register'>
<username>hamlet</username>
<password>newpass</password>
</query>
</iq>
]]></example>
<p>If the sending client has logged in using SASL EXTERNAL and the server supports XEP-0077 password changes it returns a form to change the password. If the client has logged in with the current password, the server MAY change the password without a form as specified in XEP-0077.</p>
<example caption='Server Returns Password Change Form With Error'><![CDATA[
<iq type='error' from='shakespeare.lit' to='hamlet@shakespeare.lit/denmark' id='change1'>
<query xmlns='jabber:iq:register'>
<x xmlns='jabber:x:data' type='form'>
<title>Password Change</title>
<instructions>Use this form to change your password.</instructions>
<field type='hidden' var='FORM_TYPE'>
<value>jabber:iq:register:changepassword</value>
</field>
<field type='text-single' label='Username' var='username'>
<required/>
</field>
<field type='text-private' label='Old Password' var='old_password'>
<required/>
</field>
<field type='text-private' label='New Password' var='password'>
<required/>
</field>
</x>
</query>
<error code='405' type='cancel'>
<not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
]]></example>
<p>If a client is allowed to change the password without knowing the current password, the additional security provided by this document is compromised</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='ns'>
<p>Until this specification advances to a status of Draft, its associated namespace shall be "urn:xmpp:tmp:saslcert"; upon advancement of this specification, the &REGISTRAR; shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.</p>
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<p>The XML schema will be provided in a later version of this document.</p>
</section1>
</xep>