Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard)

[Alexey Melnikov <[e-mail]>]

Peter Saint-Andre wrote:

>>1).
>>    
>>
>>>  7.  The initiating entity MUST provide an authzid during SASL
>>>      negotiation. The authzid-value MUST be a valid JID of the form
>>>      <domain> (i.e., a domain identifier only) for servers and of the
>>>      form <user@domain/resource> (i.e., node identifier, domain
>>>      identifier, and resource identifier) for clients. The initiating
>>>      entity MAY process the authzid-value in accordance with the rules
>>>      defined in Addressing Scheme (Section 3) before providing it to
>>>      the receiving entity, but is NOT REQUIRED to do so; however, the
>>>      receiving entity MUST verify that the authzid-value provided by
>>>      the initiating entity conforms to the rules defined therein.
>>>      
>>>
>>Not all SASL mechanisms are capable of transmitting authorization 
>>identity, so this requirement might be problematic.
>>
>>Also, the revision of RFC 2222 says that the client must not specify 
>>authorization-id unless it wants to impersonate some other entity:
>>
>>  As a client might not have the same information as the server,
>>  clients SHOULD NOT themselves try to derive authorization identities
>>  from authentication identities when clients could instead transmit an
>>  authorization identity of the empty string.
>>
>>So, the text should be reworded reflect that an authorization identity 
>>is optional and that if one is provided, it is in the form described above.
>>    
>>
>
>My understanding from an earlier thread on the XMPP WG list was that
>providing the authorization identity in this manner was the approach
>preferred by the SASL community. I think the fundamental issue here is
>that for XMPP clients, the authorization identity is a "full JID" (i.e.,
>node@host/resource) that is asserted by the connecting client, not
>derived by the server. Perhaps this usage is not consistent with the
>definition of authorization identity in RFC 2222? We'd have to look at
>the implications of this for client assertion of a full JID (perhaps
>this should be defined only in draft-ietf-xmpp-im).
>
There are two issues here:
1). Format of an authorization identity - your document has to define it
2). Requirement to always specify authorization identity.

Short answer to the second issue is probably "you can't do that".
But here I will try to give a long answer to explain that you probably 
don't need 2 anyway.

This is a bit tricky. SASL defines two types of identities. 
Authentication identity is derived from your authentication credentials 
and its format is SASL mechanism specific. Authorization identity is 
protocol specific. If authorization identity is not specified ("empty 
authorization identity"), it is derived from the authentication 
identity. This is the usual case ("just act as yourself").

However is authorization identity is specified, additional authorization 
checks take place. The server has to verify that the authentication 
identity can act as the authorization identity.  Authorization identity 
is useful, for example, when an administrator (or proxy server) wants to 
authenticate as himself, but act as the user.
In XMPP case I can also imagine a client that tries to authenticate as 
"node@host", but act as "node@host/resource".

So, what does this means for a server implementor? The text below 
describes my implementation experience and doesn't specify a standard of 
any kind.

Usually deployed SASL mechanisms (PLAIN/CRAM-MD5/DIGEST-MD5) don't put 
any restrictions on how an authentication identity looks like.
So, in most cases "node@host/resource" (for the client-to-server) or 
"host" (for the server-to-server) format will be used.

For Kerberos mechanisms (KERBEROS_V4, GSSAPI), authentication identity 
has the format dictated by Kerberos (usually user@realm or 
service@realm). An XMPP implementation will have to internally map 
Kerberos principals to XMPP JID format (or host), before verifying an 
authorization identity, if the one was provided.

Of course, there is also SASL EXTERNAL that can be used together with 
TLS. In this case authentication identity will have syntax of a DN.

The bottom line is that the syntax used for authorization identities for 
a protocol is [most likely] the syntax that is going to be used 
internally by the server and is the same syntax that is used by the user 
in the "enter your username" dialog for the protocol.

(Hopefully this makes sense ;-)).

So, the paragraph should probable read:

 7.  An authorization identity used in SASL is a valid JID of the form
      <domain> (i.e., a domain identifier only) for servers and of the
      form <user@domain/resource> (i.e., node identifier, domain
      identifier, and resource identifier) for clients. ...


Regards,
Alexey
__________________________________________
Isode Limited, http://www.isode.com

Cell: [phone]

IETF standard related pages:
http://orthanc.ab.ca/mel/devel/Links.html

Personal Home Page: http://orthanc.ab.ca/mel
__________________________________________