[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some comments on IPSEC proposals
It appears that by failing to be as vicious as possible about Phil
Rogaway's lack of understanding of the architecture of IPSP that I
have inspired people to take him seriously. It also appears that Phil
has been lobbying people to have them comment. I can understand how
even an intelligent reader, going through his comments, could become
confused about the architectural issues here. However, let me say that
I found his comments to be almost completely without merit. Other than
a few comments about places where the text used ambiguous language
(i.e. textual ambiguity) I found almost nothing of value in what he
had to say.
Ron Rivest writes:
> I was stimulated in part to provide these comments by Phil Rogaway's note:
>
> [ROG] Problems with Proposed IP Cryptography
> <draft-rogaway-ipsec-comments-00.txt>
Phil doesn't understand the architecture.
> 2.1 "AUTHENTICITY = INTEGRITY" [cf ROG 1.]
>
> I agree entirely with Phil here; the distinction between message authenticity
> and message integrity is vacuous here, and the proposed documents should be
> rewritten to use just a single term (message authenticity) for this notion.
> (I support Phil's recommendation 1.)
This is a serious problem? It's a textual change.
> 2.2 "ENCRYPTION DOES NOT GUARANTEE INTEGRITY" [cf ROG 2.]
>
> Again, Phil is on target here.
No he isn't.
> The proposed documents have a confused and ambiguous discussion as
> to how authenticity is to be achieved.
They are completely clear. The problem is that Phil doesn't undstand
that "ESP can provide authentication" doesn't mean "ESP provies
authentication". As for how it is achieved, that depends on the
individual transform. The DES transform, as defined, does *not*
provide authentication. Each transform provides authentication and/or
privacy in a transform dependant manner.
> 2.3. "IT IS WORTHLESS TO ENCRYPT KNOWN HEADERS" [cf ROG 3.]
>
> Here Phil recommends (his recommendation 3) that the encryption of
> known headers should be forbidden, on the grounds that AH, and not ESP,
> should be used for authenticity. I agree.
> (I support Phil's recommendation 3.)
I'm not sure what you mean here.
> 2.4 "DON'T ENCRYPT MESSAGE AUTHENTICATION CODES" [cf ROG 4.]
>
> Although it is not uncommon to encrypt MACs, Phil is exhibiting excellent
> taste by suggesting that the scope of the authentication header should
> include the encrypted packet, rather than vice versa. While I don't know
> of any security weaknesses from the proposed organization, Phil's suggestion
> is cleaner and preferable.
This is a transform issue, not an architectural issue. Because Phil
seemed to have no understanding of how the architecture works, of course...
> (I support Phil's recommendation 4.)
>
> 2.5 "DEFINE TRANSFORMS GENERICALLY" [cf ROG 5.]
>
> This recommendation is just common sense in support of better modularity
> in the description of what is being proposed.
> (I support Phil's recommendation 5.)
There is no good reason for this and there is lots of reason not to
want it.
> 2.6 "MANDATE HARDWARE-EFFICIENT *AND* SOFTWARE-EFFICIENT TRANSFORMS"[cf ROG 6
.]
>
> Efficiency is clearly an important issue when we are talking about
> operations that affect potentially every packet on the Internet.
> I think that the main point here is that there should be considerable
> freedom to choose alternative encryption techniques.
And the drafts make it clear that sides are free to negotiate any
security transform they wish. What is the issue here?
> (I have no problem with Phil's recommendation 6.)
>
> 2.7 "USE 128-BIT KEYS" [cf ROG 7]
>
> The key sizes should either be totally arbitrary (perhaps up to some
> generous limit, such as 4096 bits), at the user's discretion, or else
> be fixed at 128 bits as Phil proposes.
Pardon, but as I've noted, this is a transform issue, not an
architectural issue, and individual tranforms are free to pick what
parameters they want. We are mandating a few baseline transforms for
interoperability, but thats it.
> 2.8 "THE MAC MECHANISM" [cf ROG 8]
Let me point out that the fact that we have modular transforms renders
this entire issue fairly unimportant. We can replace transforms as we
like.
> Keyed-MD5 may be a plausible choice at the current instant, but we should be
> prepared for the fact that in the very near future we may see
> significantly better alternatives proposed and sufficiently evaluated
> to be considered as replacements.
And that is why the architecture makes it easy to replace transforms
at will.
> 2.9 "THE ENCRYPTION MECHANISM" [cf ROG 9]
>
> Phil suggests that "at this point, it may be irresponsible for any NEW
> proposal to specify DES in a mode of operation which is susceptible to
> 2**56 complexity key-exhaustion." I agree. The proposal to use triple-DES
> in a mode that is potentially compatible with single-DES (due originally,
> I believe, to Walt Tuchman), can satisfy those users who want the efficiency
> (and security) of single-DES.
I wanted to mandate 3DES but the feeling was that it wasn't a good
idea for a variety of reasons. A 3DES transform has been defined but
is not being made explicitly part of the baseline -- however it is my
expectation that vritually everyone is going to implement it.
> 3.1 KEY DISTRIBUTION / KEY AGREEMENT
>
> These proposals are incomplete and essentially unusable without at
> least one specific proposal for non-manual key distribution or key
> agreement.
We understand that. Thats why we are working on a key distribution
proposal. We aren't stupid. It looks like Photuris, which is a variant
on the Diffie-Hellman based STS protocol, is going to be used.
> I think that the current proposals should be held in abeyance (and worked on)
> until a complete package including key distribution and/or key agreement
> is also ready for consideration; I see little harm, and much potential
> good, in doing so.
I see enormous harm. The current proposals do us a lot of good RIGHT
NOW. There are dozens of manufacturers preparing to unleash
incompatible versions of this same thing on the world. The IPSEC
working group has delayed its output for years already -- there is no
reason not to move forward to draft right now.
> 3.2 LACK OF SPECIFICITY OR CLARITY
>
> There are many places where the proposals are insufficiently clear about
> what is intended, so much so that an implementor can not proceed. Here
> is a small list of items I noticed. (This is not intended to be comprehensive
.)
> [SA]
> p 6: "SHOULD let that SPI become stale..."
> (when is an SPI stale?)
After sufficient time has elapsed for it to be reasonable that the
counterparty would not attempt to reuse the value. It is hard to set a
time value on this in stone because it is dependant on too many things
that will change with time and technology. There are plenty of similar
magic values in the TCP documents and we've survived it.
> [AH]
> (page 6) It is recommended here and in other
> places [e.g. AHMD p. 1] to use "pseudo-random" values
> (here for the SPI,
Actually, the SPI is an *arbitrary* value, not a randomly generated
number. The rest of the document makes this clear.
in AHMD for the authentication key).
> How is a user to pick a "pseudo-random" value?
Security considerations makes it clear that the authentication key
must selected as any other key is selected -- i.e. it can't be
guessable and otherwise can be selected by some random process. We
don't specify a process because that is up to the key management
system, which might assign it using Diffie-Hellman, a voting
mechanism, selection based on a key generator box on one of the
machines, etc.
> Are
> counters suitable for the SPI? Is a linear-congruential generator
> suitable?
ANY mechanism is suitable. The documents make this clear. Some
implementations may wish to assign them in a way that makes hashing
efficient. Some may wish to assign them with a counter. Some may wish
to assign them by counting upwards by the value of the national debt
of Vanuatu modulo the phase of the moon. It makes no difference.
> (page 7-8) "This requirement is placed in order to allow for
> future IP optional headers which the receiver might not know about
> but the sender necessarily knows about if it is including such
> options in the packet." (I have no idea what this means.)
You removed the context.
" The sender MUST compute the authentication over the packet as that
packet will appear at the receiver."
The construction is awkward but makes it clear that you do the
authentication over the packet as it will look when the receiver gets
it, excluding things that will be stripped along the way.
> [AHMD]
> [ESP]
> (page 6) "If strict red/black separation is being enforced..."
> (This term needs a reference or a definition.)
Its a DOD term of art.
> (page 7) "If no key exists for this session or the attempt to
> decrypt fails,"
> It is not clear what it means for the decryption to fail.
ESP doesn't just mean "privacy", it can also mean
"authentication". Also, there are checksums in the underlying packet,
like IP layer checksums, that can fail.
> The authors seem to imply that the it means that the next
> layer of protocol has a problem with the decrypted text, which
> is, in my opinion, a poor choice.
What is your alternative?
> I think that the only reason
> decryption should "fail" is that decryption is impossible
> (e.g. the ciphertext is not a multiple of the cipher block
> size). Authentication failure should be used to detect all
> other problems.
This is a matter of pragmatism. In practice, there often won't be
any other way to detect the problem.
> (page 8) If user-oriented keying is not in use..."
> This paragraph makes no sense to me. It should be elaborated.
> What is the attack that is being prevented here?
Bellovin's attack, among others.
> [ESPDES]
> (page 3) "The session key SHOULD be changed at least as frequently
> as every 2**32 datagrams."
> What is the justification for this condition? What attack
> is being prevented here?
Attacks. 1)IV replication and 2) attacks based on excessive use of the
key. Its a SHOULD, not a MUST.
> (page 3) "This field is considered to be transparent, though most
> users will not be able to make sense of its contents."
> This sentence pretends to be transparent, but this reader could
> not make sense of its contents.
Do you grok the Transparent/Opaque boundary in the datagram? The IV is
an arbitrary number and thus has no meaning, but it is in the
transparent part of the datagram, not the opaque part.
> 3.3 HOST-ORIENTED vs USER-ORIENTED KEYING
>
> In [SA, section 4.4] it is stated that "support for user-oriented keying
> SHOULD be present in all IP implementations".
>
> Since "users" as such are not named principals at the IP protocol level,
> we are getting into strange territory here.
This has been discussed in detail. Please read the extremely extensive
archives and IETF proceedings.
> It is not clear what "support for user-oriented keying" means. Does
> this merely mean that each user can be associated with a separate SPI,
> or does it mean that the host system must support secure multi-user
> processing somehow (e.g., so one user can not read another user's key
> by probing memory addresses assigned to the other user)?
Neither. It really means that there has to be support to allow use of
different keys for different TCP or UDP sessions in process between
two hosts. The reason is to allow users to avoid sharing keys. There
are attacks, due to Bellovin, among others, if two mutually hostile
users are sharing a key that they do not know.
> The entire discussion on user-oriented keying seems confused (or at least
> confusing). This capability ought to be more carefully described, or
> dropped. I'm tempted to recommend just dropping it.
Perhaps that is because you are stepping in to the middle of a
discussion that lasted for a very long time (over a year) without
having carefully read all the rationale behind all the components of
the design.
> More broadly, these documents need to have a clearer philosophical position
> as to what their goals are. In particular, these documents should make it
> clear how what they are doing differs from security protocols that work
> at higher layers of the protocol stack. It would seem sensible to think
> that a protocol at this IP layer should ONLY worry about security between
> hosts, and let protocols at higher layers take care of security between
> end-users or their applications.
That isn't the goal.
> Bringing in users and userids to this protocol risks great confusion
> and muddled systems.
Users and userids are NOT in this protocol. The requirement is much
simpler than that and has several good justifications.
> 3.4 USE OF MD5
>
> The language in [AH, section 4] says "If a block-oriented authentication
> algorithm (e.g. MD5 or MD4) is in use and the IP packet is not an integral
> number of blocks, the authentication data calculation is performed using
> zero bytes at the end to pad the length out to an integral number of blocks
> [Riv92]."
>
> This is VERY confused, since MD5 (and MD4) are byte-oriented algorithms
> that are specified to normally take variable-length byte-strings as input.
> It is not necessary (and may even be dangerous) for the user to supply his
> own padding!
The examples were perhaps bad, but MACs in the general case may be
block oriented.
> 3.5 AUDIT LOGS
>
> In [AH, page 9] and other places, it is stated that the system "MUST
> record the authentication failure in the system log or audit log."
>
> Given the rate at which bad packets can be delivered to a system by a
> malicious adversary, it may not be too hard for the adversary to fill
> up the disk of a complying implementation with the audit log. I think
> the "MUST" should be downgraded to "SHOULD".
The requirement is prehaps inapropriate.
> 4. CONCLUSIONS
>
> I feel that the proposed protocols are not sufficiently worked out to
> allow proceedings with them as a proposed standard.
1) We are attempting to proceed with them as a draft standard.
2) a proposed or draft standard is not a standard.
Perry
Follow-Ups:
References: