XMPP Extensions Editor wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Client Certificate Management for SASL EXTERNAL
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.
URL: http://www.xmpp.org/extensions/inbox/sasl-external-cert-handling.html
The XMPP Council will decide at its next meeting whether to accept this
proposal as an official XEP.
This is quite sensible reminds me of an older IETF effort called SACRED
(see RFC 3767 and friends).
I've scanned the document and have some quick comments/questions:
Example 4. Client revokes an X.509 Certificate
<iq type='get'
from='[EMAIL PROTECTED]/denmark'
id='revoke'>
<revoke xmlns='urn:xmpp:tmp:saslcert'/>
<item id='428b1358a286430f628da23fb33ddaf6e474f5c5'>
<compromised/>
Where is <compromised> defined?
</item>
</revoke>
</iq>
[...]
3. SASL EXTERNAL
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.
I assume this proposal doesn't prevent use of properly certificates
signed by a CA, which were not uploaded?
4. Security Considerations
I think this XEP-to-be should REQUIRE at least use of TLS integrity
protection and/or SASL security layer with integrity protection.
Without that any man-in-the-middle that can inject data into a TCP
stream can upload arbitrary certificates (for which he/she has the
private key), so effectively giving himself/herself full access to the
account.
