Client Service Authorization $Cambridge: hermes/doc/antiforgery/draft-crocker-csa-rewrite,v 1.1 2004/08/16 14:45:59 fanf2 Exp $ 3 Model The current protocol is applicable to services in which the client declares its affiliation by asserting a domain name. An example of such a service is SMTP, in which the domain name is stated as the argument to the EHLO or HELO command. This is the identification stage. CSA specifies how a server can authenticate that the client's identification is correct, and that the client is authorized to act as a client for this service. This is accomplished by looking up a SRV record and associated information in the DNS. A single lookup will usually return all the information needed for both authentication and authorization. The protocol's result has two parts: 1. An authenticated domain name, or a determination that the client's identity is unknown. 2. An authorization status: either positive (the client may use this service), negative (the client may not use this service), or unknown. If the authentication succeeds, the domain name MAY be used to look up accreditation information for the client, e.g. using Right-Hand-Side Black List (RHSBL) services, or the accreditation services detailed in [ID-Marid-CSVDNA]. Along with the authorization status, the accreditation information MAY be used as input when deciding whether or not to accept requests from the client. Although a conceptual framework might list the steps as authentication followed by authorization followed by accreditation, they MAY run in parallel. CSA has a tight coupling between authentication and authorization which aims to make this optimization the usual case. A server MAY also run accreditation lookups in parallel to the CSA lookup, since the accreditation lookup does not depend on the result of CSA. Thus, those responsible for maintaining CSA DNS records SHOULD make allowance for the fact that the response of the accreditation service can arrive at the server before the response to the DNS SRV query detailed here. As a result, the server MAY not follow-up partial or truncated UDP responses for expediency. 4 Mechanism After the client identification stage, the server's procedure is: 1. Given a client that is requesting a and has stated a , perform a DNS lookup of: QNAME = _client._. QCLASS = IN QTYPE = SRV 2. If there is no SRV RR matching this QNAME, the authentication has failed and the authorization is unknown; otherwise at least one record exists. SRV RRs that are not valid according to the specification in the next section MUST be discarded. If there are no valid SRV RRs the authentication has failed and the authorization is unknown. These SRV RRs contain the authorization information for the client's domain. This information cannot be used until the client has been authenticated, as follows. 3. The IP addresses associated with the target field of each SRV RR are looked up in the DNS, with a QTYPE of A for IPv4 connections and a QTYPE of AAAA for IPv6 connections. According to [RFC2782] these target addresses SHOULD be returned in the Additional Data section of the response to the query in step 1, in which case this lookup is not necessary. 4. If the IP address of the client does not appear in the list of addresses for a given target, then the SRV RR from which the target was obtained MUST be discarded. If the IP address of the client does appear in the list of addresses for a given target, then the client's domain name has been authenticated. The SRV RR from which the target was obtained is retained for checking authorization. 5. If all the SRV RRs have been discarded then the authentication has failed. The authorization status is negative. If the client's domain name has been authenticated, the server can then determine the authorization result as follows. 6. There may be one or more SRV RRs resulting from step 4. The server examines their weight fields. If they are all unknown, the authorization is unknown. Else if some are positive and some are negative, the authorization is unknown. Else if they are all positive, or if some are unknown and some are positive, the authorization is positive. Else if they are all negative, or if some are unknown and some are negative, the authorization is negative. 5 Client Service Authorization SRV Record The intended use of [RFC2782] SRV records was to aid discovery and selection of servers by prospective clients. Implementing this client authorization mechanism for the server, the Priority, Weight, and Port fields are no longer used for either discovery or selection. Thus these three fields are assigned different meanings, as described below. The Service and Proto fields are also used slightly differently than specified in [RFC2782]. The Proto field is used to specify the service, and the Service field is used to state that this record is for client authorization. The SRV CSA Record has the following contents: _Service._Proto.Name : TTL : Class : SRV : Priority : Weight : Port : Target 1. Service _client 2. Proto The service name prepended with an underscore, as specified for the Service field in [RFC2782]. For example, _smtp. 3. Name Domain name that is to be authorized. [These first three fields become the QNAME _client._..] 4. TTL Standard DNS meaning [RFC1035]. 5. Class Standard DNS meaning [RFC1035]. SRV-CSA records are only defined for the IN Class. 6. Priority Priority defines the revision level of this protocol, which is currently 1. Other values are invalid. 7. Weight Weight is used to indicate the authorization associated with the target domain name. It is in the form of a bit-field: the bit valued 1 indicates whether authorization is known; and the bit valued 2 indicates whether authorization is positive. Higher-valued bits are reserved and MUST be zero. The resulting possible values for weight are as follows. Other values are invalid and MUST NOT be used. SUMMED VALUE MEANING 0 Authorization Not Available 1 Not Authorized 3 Authorized 8. Port This field MUST be zero. 9. Target The meaning of Target differs from [RFC2782] as follows: If this record is defined as being an Not Authorized, then the field Name as used in the QNAME is used as the target rather than the "." as a means to prevent excessive traffic on root DNS servers by errant implementations. 6 Applying CSA to SMTP The SMTP [RFC2821], [RFC0821] protocol already includes an identification stage, when the client asserts a domain name in the HELO or EHLO command. Client Service Authorization can be used to authenticate this domain name and determine if the client is authorized to use this affiliation when sending email. For example, if a client starts an SMTP conversation by stating EHLO pc53.office.example.com the SMTP server will start the CSA process by doing a DNS lookup of the SRV RR set for _client._smtp.pc52.office.example.com If the result of CSA is a failed authentication or an unknown authorization, the server SHOULD proceed according to local policy, as if CSA had not been performed. If the result is a negative authorization, the server MAY reject all attempts to send email with a "550 Client not authorized" error. If the authentication succeeds, the server MAY consult an accreditation service using the client's domain name in order to decide how favourably to look on the client's requests.