On September 2, 2005 at 16:47, Dave Crocker wrote:
1. The language here does not make an "implication". It states a behavior qui
te
explicitly and it explains why it happens and why it is not required to happe
n.
2. What can be returned in Additional Information is the logical equivalent o
f
doing an A record query; if it is not returned then an A record query must be
done.
Then state this explicitly in the specification.
An explicit address record query is only mentioned in a parenthetic
comment versus being clearly defined in the authentication procedures.
Therefore, there is no explicit statement about this. The document
should state:
If the SRV query result does not include the address records for
the EHLO domain in the Additional Data section, the SMTP server
MUST perform a separate address query on the EHLO domain for
authenticating the SMTP client.
Another not-as-clear-as-it-could-be part is the following text
in step 4 of Section 4:
Target addresses MAY be returned in the Additional Data section,
or a query for address records of the target name may be needed
to determine the associated address(es). This MAY be used to
satisfy the authentication function specified in Certified Server
Validation[ID-CSV].
This text states that the additional address records *MAY* be
used for authentication.
Shouldn't the text state:
If the address record of the EHLO domain name is provided in
the Additional Data section of the SRV query result, the SMTP
server SHOULD considered the SMTP client authenticated.
I.e. If it is the intent of the authors to use the address record
in the Additional Data section, then the document should explicitly
state this intent (SHOULD could even be changed to MUST). The text
"MAY be used to satisfy the authentication function" states that use
of the address record is optional.
If optional behavior is allowed, then it must be explicitly stated
somewhere how the SMTP server will authenticate the EHLO domain
if it chooses not to use the address records provided in the SRV
query result: basically stating that the server must perform an
address query.
Note, the ID-CSV draft uses SHOULD, which appears to contradict
the "MAY" in CSA:
If the list is returned and the actual IP address of the sending
SMTP client is in it, the receiving SMTP server SHOULD consider
the EHLO domain name to be authenticated.
BTW, no where in the ID-CSV draft does it state that the SMTP
server MUST perform an address query on the EHLO domain name if
the address record is not provided in the SRV query result. This
step should not be inferred but explicitly stated.
In general, conformance to a specification should not rely on implied
procedures. All procedures should be explicitly mentioned and defined.
On a somewhat related comment: It is odd that the only place that
actual steps (in a list form) for authentication are provided given in
the Overview section of ID-CSV. Would it not be cleaner to specify
authentication procedures in the CSA specification since the process
of determine authentication involved actions that are performed to
determine authorization?
Since reliable authorization requires authentication (which is
mentioned in ID-CSV) CSA should define both since the information
obtained to determine authorization is used to verify authentication.
It seems that CSV can be reduced to two documents, CSA and DNA,
since ID-CSV mainly contains overview and introductory information.
Side note: There is no clear step-by-step "authentication function"
listed in ID-CSV. The procedure is provided in general prose within
a section indicating authorization procedures. There is no section
title "Authentication Function" in ID-CSV and no clear indication
that authentication can be done separate from authorization. This
appears to go against one of the design approached mentioned
in ID-CSV:
A proposal or its implementation well might combine some of these
steps. However it is important to consider them independently,
in order to ensure that the proposal specifies that they are
performed in a valid manner, or at least that the constraints of
the proposal are clear for each of these conceptual functions. This
specification distinguishes each of these logical steps and defines
their operation separately.
It seems that authentication is combined with authorization versus
being separated. If a clear separation is desired, an authentication
procedure that just an address lookup on the EHLO domain to see
if it matches the IP of the connection should be clearly defined
(e.g. section with appropriate title).
The authentication method that "piggy-backs" on the authorization
process can be documented as an optimization allowing authentication
and authorization to be done together to minimize DNS queries.
My $0.02,
--ewh
_______________________________________________
ietf-clear mailing list
ietf-clear(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-clear