2) the signing public keys, and some way to trace back the chain of
trust,
is carried with the message
The chain of trust in IIM is DNS, with obvious trust
limitations. Absent DNSSEC, I'm not sure what you would sign it with.
The obvious alternative is to provide self-validating (i.e. certified) keys
by-value in a message. It is not obvious to me that this approach is
bankrupt if you only use domain-based assertions; for user-based assertions,
employing certificates is definitely problematic (because of enrollment,
costs, etc).
Personally, I think the problems with acquiring/validating keys by-reference
are not limited to intentional amplification attacks. I think the load on
these servers will be substantial for certain classes of messages regardless
of whether or not anyone is actively trying to crater the service. The
privacy issues you list in 9.2 of the IIM draft are also material, and
become more significant when user-based assertions are used. I'm not sure
that my concerns about this are dispelled by a mention of 'trusted proxies',
though there are perhaps specific trusted proxy architectures in which this
would be significantly alleviated.
Most of this is true for any message identity architecture that expects keys
to be acquired/validated by a network call, and is merely exacerbated by the
fact that a) because IIM focuses on user-based assertions, validators will
have to validate keys more often than they would for domain-based
assertions, and b) your approach can entail hitting both the DNS and a KRS,
i.e. multiple network accesses per validation. Any by-reference key
distribution/validating scheme also brings in to play lots of other
interesting architectural points about who can act as a verifier, if
endpoints can verify identity assertions when they are off-line, etc.
Jon Peterson
NeuStar, Inc.
-Jim