[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard
Regarding the Last Call on <draft-ietf-ipsec-isakmp-oakley-07.txt> (aka IKE),
two issues were raised last month that have yet to be addressed as far as
I know. (I haven't received any replies to my suggestions on the IPSEC list
of ways to deal with these issues.)
[1] As Matt Thomas observed, IKE does not specify what action should be taken
in the "original" Encryption Mode of authentication in the event that the
ID payload exceeds the maximum data size for PKCS #1 encryption with the
peer's public RSA key.
Rather than attempt to specify a block chaining mechanism for RSA encryption,
I proposed prohibiting the use of the "original" Encryption Mode whenever
this situation arises. (See the first included message from IPSEC below.)
Depending upon how individual implementations currently react to this
situation, potential effects of the underspecification could vary between
failures of interoperability and failures of the intended authentication
guarantees.
[2] Pau-Chen Cheng suggested that the original Encryption Mode in IKE may
be vulnerable to the small RSA encryption exponent attacks due to Coppersmith
et al.
It appears that the encryption of very long ID payloads with very small
exponents is vulnerable to such attacks. Rather than increasing the minimum
padding size -- thus diverging from the PKCS #1 encryption block format --
I proposed prohibiting the use of RSA encryption exponents below a certain
size in the original Encryption Mode. The lower limit on the exponent size
depends on the size of the modulus in a simple way. (See the second
included message from IPSEC below.)
--
Lewis McCarthy <lmccarth@cs.umass.edu>
--- begin included messages from the IPSEC list ---
From owner-ipsec Fri Mar 20 21:05:05 1998
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA03550 for ipsec-outgoing; Fri, 20 Mar 1998 21:04:51 -0500 (EST)
Message-ID: <35132368.794B@cs.umass.edu>
Date: Fri, 20 Mar 1998 21:18:16 -0500
From: Lewis McCarthy <lmccarth@cs.umass.edu>
Organization: UMass-Amherst Theoretical Computer Science Group, <http://www.cs.umass.edu/~thtml/>
X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha)
MIME-Version: 1.0
To: matt@ljo.dec.com
CC: IP Security List <ipsec@tis.com>
Subject: Re: new IKE draft
References: <9803161550.AA26962@secpwr.watson.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Matt Thomas writes:
>>> (Also what happens in the non-Revised mode if the identification payload is
>>> larger than what can be encrypted via the RSA modulus?)
Good question.
How do existing implementations behave when this situation arises?
I presume there are routine length checks in place
to calculate the PKCS#1 padding length and avoid buffer overflows.
Is the exchange aborted, are some bits of the ID payload ignored (bad),
is the ID payload silently reduced mod N by the crypto engine before
encryption (bad) ??
For encryption, PKCS #1 focuses on the common use of RSA to provide a "digital
envelope" bearing a key for a conventional symmetric cipher.
Secure RSA modulus and symmetric key sizes being what they are, the
issue of plaintext that exceeds the block size just doesn't arise in that
situation.
I'm not aware of any standard that specifies the use of pure RSA for multi-
block encryption, presumably in some CBC-like block chaining mode.
I think the right way to fix this problem is to prohibit use of the "original"
Authentication with Public Key Encryption method if RSA encryption is used and
the length of the ID payload exceeds the data length limit specified in
Section 8 of PKCS #1. If this condition is discovered after the method
of 5.2 has been proposed (and maybe even accepted), the exchange must
be aborted and a different authentication method negotiated. If only
the responder encountered a length problem, then the initiator might
propose use of Auth. with PK Encryption again. *sigh* I'm not sure whether
there's a good Notify message type for the responder to send in this case.
Maybe Invalid-Exchange-Type or Invalid-Key-Information?
Comments?
Incidentally, there doesn't seem to be a bibliographic reference in the
draft for PKCS #1:
[RSA93] RSA Laboratories, "PKCS #1: RSA Encryption Standard",
version 1.5, RSA Data Security, Inc. Public-Key Cryptography
Standards (PKCS), November 1993,
ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs-1.asc
-Lewis <pseudonym@acm.org> <http://www.cs.umass.edu/~lmccarth>
"damn good...and very dangerous" --P.M. Netanyahu, of Ehud Tenebaum
From owner-ipsec Sun Mar 29 23:29:08 1998
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA29741 for ipsec-outgoing; Sun, 29 Mar 1998 23:24:45 -0500 (EST)
Message-ID: <351F21C4.446B@cs.umass.edu>
Date: Sun, 29 Mar 1998 23:38:28 -0500
From: Lewis McCarthy <lmccarth@cs.umass.edu>
Organization: UMass-Amherst Theoretical Computer Science Group, <http://www.cs.umass.edu/~thtml/>
X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha)
MIME-Version: 1.0
To: IP Security List <ipsec@tis.com>
CC: pau@watson.ibm.com
Subject: Re: new IKE draft
References: <9803161550.AA26962@secpwr.watson.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Pau-Chen wrote on 16 Mar 1998:
> Actually, for stronger securuty, I think the input to
> RSA encryption should not be longer than 2/3 of the size of the modulus.
Coppersmith's attack from Eurocrypt `96 imposes this security condition
when the public exponent is e=3. As his paper notes, there are security
tradeoffs between the amount (and location) of padding and the size of the
public exponent. For some realistic modulus and public exponent sizes (e.g.
e=3, |N| = 1024 bits), the minimum 64 bits of PKCS #1 padding isn't enough
to prevent an attack when the adversary knows a good chunk of the
plaintext.
This means trouble for the encryption of long identities in the original PK
Encryption Mode of authentication when the peer's public key has a very
small e, and the adversary has a manageable set of identity guesses to
check.
One way to patch this hole would be to increase the minimum padding
length. This would mean IKE would no longer be doing vanilla PKCS #1
encryption block formatting.
An alternative is to impose a minimum size for the public exponent in RSA
keys used with the original Encryption mode. The adversary's task is
easiest when the ID payload is the longest allowed by PKCS #1 (i.e. k-11
octets in length) and the adversary knows all but a single bit of the ID
payload. Thus only 65 bits of the input to encryption are unknown to the
adversary. Conservatively the public exponent e should satisfy
65 >= n^(1/e), where n is the modulus. (This errs on the side of safety,
since the padding and payload aren't contiguous in PKCS #1, and the
padding isn't the most significant block of bits in the plaintext. But I
think this is not too far off the mark.) For example, for n approximately
2^1024, the requirement would be e > 170.
I mildly prefer the latter option. What does the WG think?
I don't believe these attacks pose a threat to the encryption of nonces in
the original and Revised PK Encryption Modes of authentication. Since the
nonces are randomly generated, the adversary won't start with any partial
information on the nonces. So there's no realistic foothold for a
stereotyped message attack. Because the nonces are random and sufficiently
large, the adversary essentially has no hope of finding groups of
ciphertext susceptible to related message attacks.
--
Lewis http://www.cs.umass.edu/~lmccarth/
--- end included messages from IPSEC list ---
Follow-Ups:
References: