[Standards] Re: [Standards-JIG] Notes on JEP-0178: Best Practices for Use of SASL EXTERNAL - client part of the JEP

Mridul mridul at sun.com
Fri Jan 26 18:49:52 UTC 2007

Joe Hildebrand wrote:
> On Jan 25, 2007, at 2:12 PM, Peter Saint-Andre wrote:
>>>   Clause 3: I do not think, that we have to check the existence of
>>>   the account the user authenticated as (= that has been included in
>>>   the certificate). We just have to check, that the account the user
>>>   tries to authorize as does exist. The authorization identity should
>>>   always be an XMPP address, therefore we do not need this clause that
>>>   way. But we may have some words on an authentication policy. 
>>> Therefore
>>>   it might be possible that the authentication identity is just a
>>>   Common Name in the certificate, and the certificate with that CN
>>>   might be allowed (e.g. by an LDAP entry) to authorize as an XMPP
>>>   address, that is passed in the SASL exchange, and that has been found
>>>   in that LDAP directory.
>> Well pgm and I talked about this use case about a year ago -- the 
>> idea is that the cert does not contain any XMPP address but does 
>> contain a Common Name and the server can use that information to 
>> match the CN with an XMPP address. But it seems in this case that the 
>> client should (must?) include an authorization identity, right?
> Please not MUST.  It's quite common in our customer base for certs to 
> have been already generated before XMPP has been considered.  As well, 
> the users don't necessarily know what their user names are, since they 
> just put in a smart card to log in.  With this combination, there's no 
> way for the client to know what to put in as the authorization 
> identity, and the server just has to look at the cert, and figure out 
> in some way what the associated JID is.
> --Joe Hildebrand

In this case of no xmpp-oid, the authorization id will be "node derived 
from cn in cert"@"domain from 'to' in stream"  when no authorization id 
is specified by client for sasl external ?
We do not support sasl external for clients, but just want to clarify 
the expectation for client certs.


More information about the Standards mailing list