Tony,
TF> If I were going to make suggestions about how to structure the spec, I'd
TF> throw away HNA and the CSV overview. I'd improve the CSA spec with a more
TF> precise explanation of the authentication process (in a separate section).
CSA is about authorization, not authentication.
The reference to the Additional Information mechanism, within CSA, is
as a convenience rather than really being part of the spec.
TF> If you want to keep HNA in something like its current form, then I suggest
TF> that it should describe each authentication method with reference to a
TF> subject domain that is to be authenticated and what other protocol
TF> information it is compared with. e.g. the forward DNS method is to look up
TF> the A or AAAA records for the subject domain and ensure that one of the
TF> addresses is the same as the client IP address from the TCP connection.
TF> The TLS method is to require a client certificate with a common name that
TF> corresponds to the subject domain.
Adding detail like this, to make VERY clear how each one gets used,
sounds like an excellent idea.
TF> Actually that doesn't work very well because CSA's input into the forward
TF> DNS process is the CSA SRV target domain, not the EHLO domain. In the TLS
TF> case perhaps the subject domain is the output of the process rather than
TF> an input.
Huh? CSA _is_ the forward DNS process. Take the EHLO domain, do a
lookup on _client._smtp.<ehlo domain> and get back the authorization
SRV.
TF> The problem with a strict separation between authentication and
TF> authorization in the presentation of CSV is that the protocol does not
TF> separate them as described.
Yes it does.
TF> In fact if my understanding of the protocol is
TF> correct (see below) then the description in the CSV draft that
TF> authorization follows authentication is wrong.
The text makes clear that the actual excecution might occur
differently. Refer to "A proposal or its implementation" in the
Introduction.
TF> The process is interleaved:
TF> look up the authorization record; look up the authentication record; check
TF> authentication; check authorization.
There is no one, right sequence. Folks will choose different
sequences, for a variety of reasons. This provides yet-another example
of the reason it is essential to be clear that separate functions are
indeed separate in the specification.
TF> The DNA spec is not really tied to CSV in the way your document structure
TF> suggests -- it's useful as the next step after any domain authentication
TF> system (SPF, CID, DK, etc.).
we specified it, so it's tied to this spec. on the other hand, yes,
any component of this could be replaced by some other method of
satisfying the component requirement.
the challenge is to make sure that it indeed does the right
authentication, for example. alghouth spf, cid, and dk may well do
nice authentications, it's not clear to me that any of them have the
right semantics for what CSV is requiring.
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?
TF> Outside the spec. E.g. a non-zero port, or a weight that isn't 0, 1, or 3,
TF> or a priority that isn't 1, etc.
ahh. right. good catch. thanks.
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.
TF> I'm glad you like it :-) The question still remains about the
TF> authentication process. Does it use the addresses of the client EHLO
TF> domain? (As I understand it, no.) Or does it only use the CSA SRV target
TF> domain? (AIUI, yes.) Does it use both? if so, how? (AIUI, no.) What about
TF> reverse DNS? (AIUI, no.)
i think the answer needs to depend on a step-through analysis of
threats. what will be robust against administrative attacks. that
is, what will be open to having a bad guy create dns records to permit
deception, and what won't. in my current, jet-lagged, vacation mental
state, i'm not even close to being able to perform the exercise.
TF> I don't think it's worth making heavy weather of the distinction,
TF> certainly not to the extent of forcing an order of presentation of the CSV
TF> algorithm that has no relation to the order of execution. People are used
TF> to authentication and authorization being very tightly bound; keeping them
TF> apart isn't necessary if it is clear which part of the protocol is
TF> performing which security function.
The "used to" has two responses, both problematic:
1. That may well contribute to the reason folks are so bad at
distinguishing between these two, very different functions and why we
need to be thoroughly, painfully, crystal-ly clear about the
differences between them. To that extent, the anti-spam work is
working in territory that has been sadly lacking much history.
2. In fact authorization is rarely discussed within Internet standards
specifications.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>