[Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL

Alexey Melnikov alexey.melnikov at isode.com
Wed Dec 3 23:18:19 UTC 2008


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='hamlet at shakespeare.lit/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.




More information about the Standards mailing list