Peter, Jim,
This is a serious problem, imo. If Bob receives an AuthenticatedData from
Alice but it is not really from Alice, then there really is no authentication,
despite the promise that AuthenticatedData provides authentication. What
security service is AuthenticatedData providing in this case? If the Charles
is the attacker, then cannot Charles strip off his RecipientInfo from the
AuthenticatedData, in which case, Bob has no way of knowing that Alice
originallly sent the AuthenticatedData to two parties?
A difference between SignedData and AuthenticatedData is that with the latter
Bob cannot prove (cryptographically) to others that Alice authenticated
anything. That's the motivation to use AuthenticatedData instead of SignedData.
***
Maybe AuthEnvData is a little different from AuthData, though. For example, if
the key management mechanism is key transport, so Alice provides no
certificate, then effectively Alice is anonymous. In that case, the MAC only
protects integrity of the message from modification in transit, it does not
provide authentication. (Cf. TLS with unauthenticated clients, where records
are MAC for a similar purpose.) If AuthEnvData is used for that lesser
purpose, then the substitutuion attack by Charles is not as significant,
because Alice is essentially anonymous.
From reading 5083, I interpret its intent only to be add integrity to EnvData,
since CBC mode does not provide full integrity. However, for some choices of
key management, it has the further capability of authenticating the sender
(i.e. if the key management authenticates the sender, which in does in all
cases except key transport). This is a useful capability and should be noted.
Regardless, it should be emphasized that, at least in the case of key
transport, that no actual authentication is provided (just integrity).
Otherwise, evidently there is a risk of misinterpretation.
Best regards,
Dan
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Peter
Gutmann
Sent: Friday, May 09, 2008 9:26 AM
To: ietf-smime(_at_)imc(_dot_)org; ietf(_at_)augustcellars(_dot_)com;
pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz;
trevorf(_at_)EXCHANGE(_dot_)MICROSOFT(_dot_)com
Subject: RE: weak authentication issue with rfc5083
"Jim Schaad" <ietf(_at_)augustcellars(_dot_)com> writes:
I believe you have misunderstood the issue that Trevor raised.
His problem is:
1. I send you and him a single Authenticated Message.
2. He takes the common CEK in the original message, uses it to create a MAC
on an new message and then sends it on to you.
As is always true with Authenticated messages, there is no proof of origin.
He worries that you might be confused and believe the second messages was
from me rather than from him. Since they both use the same CEK that is not a
factor that could be used to distinguish them.
Ah, OK, thanks. How serious a threat is this in practice though? Wouldn't
people just use asymmetric auth if they're worried about proof of origin? I
realise it's kind of an interesting problem to solve, but does it need solving
beyond a security considerations note "If you're seriously worried about proof
of origin use a signature"?
Peter.