On Fri, 31 Aug 2001 09:15:17 PDT, ned(_dot_)freed(_at_)mrochek(_dot_)com said:
And the mail store should trust these values why?
Because there's a trust relationship between the mail store and the transfer
agent, brought about by some sort of explicit configuration. The transfer
agent
may be identifiable as such in a variety of ways: SASL authentication,
physically secure link, VPN, etc.
No problem - can whoever ends up doing the RFC make sure to include
that in the 'Security Considerations' section (or maybe even go so far as
to only allow passing LDAP key/value pairs if other means have been used to
authenticate the submitter)?
SASL is pretty well understood - I'd have no problem with "if the other
end SASL-authenticated that they're the MTA, believe their LDAP". On the other
hand, I've seen more than one case where people used crypto boxes at both
ends of a leased line to run a secure PPP link - but one end or the other
was also on a subnet, did not do per-interface filtering of packets, and
was subject to TCP seq num prediction attacks...
Similar comments apply to most VPN handwaving - there's good VPN products,
and they're crappy ones.
Ned knows how to use the building blocks, Chris knows how, Larry knows how,
people keep claiming I know how - but I can think of a number of vendors
that *will* get it wrong unless they're specifically told "Here, use one of
these 3 blocks - don't use the green ones though, they need purple ones too
to make them fit..."
This sort of thing is done all the time and works quite well.
This sort of things is done all the time and written about on Bugtraq too ;)
Hardly. We have all the tools necessary to do such things securely and without
them becoming invitations to passing bad data around. The real risk here is
stale data, not bad data.
Yes, as long as the tools are correctly used. If they're not used, or used
incorrectly, bad data is a danger.
/Valdis