[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard)
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: +44 7753759732
IETF standard related pages:
http://orthanc.ab.ca/mel/devel/Links.html
Personal Home Page: http://orthanc.ab.ca/mel
__________________________________________