stpeter at stpeter.im
Wed May 11 14:23:13 UTC 2011
On 5/11/11 8:06 AM, Peter Saint-Andre wrote:
> On 5/11/11 7:57 AM, Matthew A. Miller wrote:
>> * For exactly what error to respond with, I'd rather it be SHOULDs rather than MUSTs, but not strongly enough to object
> I'll check them all for consistency with RFC 6120.
OK, here's the story.
BTW I'm going to number the examples in XEP-0178 so this stuff is easier
to track. :)
1. XEP-0178, Section 2, point 11.b, says:
If the certificate contains more than one valid XMPP address that
corresponds to a registered account on the server (e.g., because the
server offers virtual hosting), then the server SHOULD allow
authentication and authorization of the JID specified as the
authorization identity in the SASL exchange.
If no authorization identity is included, then the server SHOULD return
a SASL failure case of <invalid-authzid/> and close the stream.
I think that is consistent with RFC 6120, Section 220.127.116.11.1.
2. XEP-0178, Section 2, point 11.c, says:
If the certificate does not contain an XMPP address, then the server MAY
attempt to determine if there is a registered account associated with
the user, for example by performing an LDAP lookup based on the Common
Name or other information presented by the client in the certificate; if
such a JID mapping is successful and the mapped JID matches the
authorization identity provided, then the server SHOULD allow
authentication and authorization of that mapped JID.
If JID mapping is unsuccessful, then the server MUST return a SASL
failure condition of <not-authorized/> and close the stream.
If JID mapping is successful but the mapped JID does not match the
authorization identity provided (if any), then the server MUST return a
SASL failure condition of <invalid-authzid/> and close the stream.
Here I think Matt is right and that SHOULD is more consistent with the
base spec (in any case, RFC 6120 doesn't mandate the error here).
3. XEP-0178, Section 3, point 11 says:
Server2 determines if hostname is valid.
1. If the 'from' attribute of stream header sent by Server1 can be
matched against one of the identifiers provided in the certificate
following the matching rules from RFC 6125, Server2 returns success.
Implementation Note: If Server2 needs to assign an authorization
identity during SASL negotiation, it SHOULD use the value of the 'from'
attribute of the stream header sent by Server1.
2. Else Server2 MUST return a <not-authorized/> stream error and
close the stream.
However, RFC 6120, Section 6.4.6 says:
Before considering the SASL handshake to be a success, if the initiating
entity provided a 'from' attribute on an initial stream header whose
confidentiality and integrity were protected via TLS or an equivalent
security layer (such as the SASL GSSAPI mechanism) then the receiving
entity SHOULD correlate the authentication identity resulting from the
SASL negotiation with that 'from' address; if the two identities do not
match then the receiving entity SHOULD terminate the connection attempt
(however, the receiving entity might have legitimate reasons not to
terminate the connection attempt, for example, because it has overridden
a connecting client's address to correct the JID format or assign a JID
based on information presented in an end-user certificate).
Here again I think Matt is right, and this MUST needs to be changed to a
SHOULD for consistency with RFC 6120.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
More information about the Council