On Wed, 16 Jun 2004, Dave Crocker wrote:
Given the amount of effort we put into fleshing out the text and
working on clarity and completeness, it is not likely that any of its
irrelevance or digressiveness will be obvious to us. So, again, your
comments say exactly what you think needs to be changed, right?
Yes, I think the high-level structure of the specification is up to you; I
was reviewing it mainly from the point of view of trying to understand
how to implement it.
If I were going to make suggestions about how to structure the spec, I'd
throw away HNA and the CSV overview. I'd improve the CSA spec with a more
precise explanation of the authentication process (in a separate section).
If you want to keep HNA in something like its current form, then I suggest
that it should describe each authentication method with reference to a
subject domain that is to be authenticated and what other protocol
information it is compared with. e.g. the forward DNS method is to look up
the A or AAAA records for the subject domain and ensure that one of the
addresses is the same as the client IP address from the TCP connection.
The TLS method is to require a client certificate with a common name that
corresponds to the subject domain.
Actually that doesn't work very well because CSA's input into the forward
DNS process is the CSA SRV target domain, not the EHLO domain. In the TLS
case perhaps the subject domain is the output of the process rather than
an input.
The problem with a strict separation between authentication and
authorization in the presentation of CSV is that the protocol does not
separate them as described. In fact if my understanding of the protocol is
correct (see below) then the description in the CSV draft that
authorization follows authentication is wrong. The process is interleaved:
look up the authorization record; look up the authentication record; check
authentication; check authorization.
The DNA spec is not really tied to CSV in the way your document structure
suggests -- it's useful as the next step after any domain authentication
system (SPF, CID, DK, etc.).
Our conclusion is that for this very constrained use, [forward-only
checking is sufficient]. It won't surprise anyone that we won't be
surprised if the community concludes otherwise
I didn't work out that that was what your protocol requires until after
reading both HNA and CSA. I think most of the discussion in HNA is
relevant only in a rationale document, not a spec. (There are no useful
SHOULDs or MUSTs in it!) However the spec should probably explain why a
full forward-and-reverse DNS consistency check isn't necessary.
TF> HNA section 4 Independent Policy Services
reliability is often part of the input to an accreditation process.
TF> draft-ietf-marid-dsvcsa-00
TF> Sections 4 & 5
TF> These sections overlap rather a lot. They also omit to specify what the
TF> server should do if the client's CSA records has invalid data.
What do you mean by "invalid" data? How is invalidity assessed?
Outside the spec. E.g. a non-zero port, or a weight that isn't 0, 1, or 3,
or a priority that isn't 1, etc.
TF> The protocol specified in this draft appears to be (I'm reading between
TF> the lines here) that the EHLO domain name stated by the SMTP client is
TF> used to look up a SRV record. This record states in the weight field if
TF> that name may be used by an SMTP client, and it also contains a target
TF> name. The DNS reply should contain additional data, being the IP address
TF> records associated with this target name. One of these must match the
TF> client IP address from the SMTP connection in order for the EHLO domain
TF> name to be considered valid. Or maybe (according to HNA) the IP addresses
TF> associated with the EHLO domain itself must match the connection IP
TF> address. Or maybe the reverse DNS must agree too. This is not clear. It's
TF> also not clear how this relates to the RFC 2821 nix on EHLO checks.
wow. what a really excellent summary! wish we had written it, and thoroughly
appreciate that you did. it will be a nice addition to the doc.
I'm glad you like it :-) The question still remains about the
authentication process. Does it use the addresses of the client EHLO
domain? (As I understand it, no.) Or does it only use the CSA SRV target
domain? (AIUI, yes.) Does it use both? if so, how? (AIUI, no.) What about
reverse DNS? (AIUI, no.)
--
Tony Finch <dot(_at_)dotat(_dot_)at> http://dotat.at/