After reading Internet Draft RFC 1113ID (recently mailed to this
list), I re-read Draft RFC 1115A. Now I have a question.
Regarding the MAC form of MIC ("MIC-MAC" rolls off the tongue
nicely, no?), section 4.1 of 1115A says that the MAC:
"...is computed using the DES CBC mode of operation...[requiring]
a 64-bit cryptographic key. For our purposes, this key is
derived as a variant of the DEK used for message text encryption."
However, in a MIC-ONLY or MIC-CLEAR message, there is no "DEK used for
message text encryption" because the message text is not encrypted.
So, what key is used? Well, I suppose it's the DEK carried in the
Key-Info: field; but the wording above is unfortunate.
My question is, what is the IV used for the MAC DES-CBC operation in
the MIC-ONLY/CLEAR case? In ENCRYPTED messages, the IV is carried in
the DEK-Info: field, but MIC-ONLY and MIC-CLEAR messages do not have
such a field. Section 4.6.1.1.2 (on MIC-ONLY) says:
"The 'DEK-Info:' field can be omitted for all 'MIC-ONLY' messages."
and MIC-CLEAR has the same fields as MIC-ONLY.
A plausible answer might be that MIC-ONLY/CLEAR messages that use MAC
for the MIC must also have a DEK-Info: field just to supply an IV for
the MAC operation. That wouldn't be very tasty, given that the first
quantity in the DEK-Info: field specifies the "message text encryption
algorithm", which is none in this case. If this is the answer,
perhaps the RFC should state (in section 4.6.1.1.2) that a DEK-Info:
field is required for MIC-ONLY/CLEAR messages using MAC. And perhaps
the first quantity of the DEK-Info: field should be optional -- for
just this case.
Myself, I think that an even better solution is to specify a fixed
value IV for the MAC DES-CBC computation, but I'm not enough of a
cryptographer to know whether this would weaken the MAC.
-Allan