Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update

From: Dan Harkins <[email-masked]>
Date: Wed, 21 Mar 2001 15:34:22 -0800

Oh darn, that's right. That pesky authentication stuff. In that case I 
recommend you use the pre-shared key for the Internet. It was an April
Fools draft but it provides you with the level of security you seem to
want and doesn't have any of those nasty scaling problems associated
with public key infrastructure.

  I've attached a copy of it for you.

  Dan.

On Wed, 21 Mar 2001 15:02:12 PST you wrote
> Dan Harkins writes:
>  >   If the binding updates are important enough to require cryptographic
>  > protection then the keys have to be authenticated. 
> 
>  What treaty organization did you have in mind to be the
>  third party?
> 
>        Mike

Network Working Group                 Derrell Piper, The Electric Loft
INTERNET-DRAFT                      Dan Harkins, Anvil Brewing Company
draft-ieft-ipsec-internet-key-00.txt                     April 1, 1998

              The Pre-Shared Key for the Internet Protocol
                 <draft-ietf-ipsec-internet-key-00.txt>

                          Status of this Memo

   This document is an Internet Draft. Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and working groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet Drafts as reference
   material or to cite them other than as "work in progress."

   To learn the current status of any Internet Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Australia), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

      0. Table Of Contents
      1. Abstract
      2. Discussion
      3. Terms and Definitions
      4. Pre-Shared Key Definition
      5. Security Considerations
      6. Acknowledgments
      7. References

1. Abstract

   Recent efforts from the IPsec Working Group of the IETF in securing
   the Internet ([AH], [KA98], [ESP], [ESPCBC], [ESPNULL], [DES],
   [DESMAC], [HMACMD5], [HMACSHA], [HC98], [DOI], [IPCOMP], [ISAKMP],
   and [OAKLEY]) imply the continued use of pre-shared keys.  This
   document defines the Pre-Shared Key for the Internet.

Piper, Harkins                                          	[Page 1]

INTERNET DRAFT                                             April 1, 1998

2. Discussion

   Pre-shared keys are normally used for interoperability purposes.  The
   basic idea is that two parties sharing a common secret can
   communicate securely.  This idea has been used since cryptography
   first sprung onto the scene.  For a complete history of cryptography,
   see Wired magazine.

   An additional motivation is that pre-shared keys are, for the most
   part, unencumbered technology.  (It's speculated that RSA Data
   Security, Inc. has made various claims relating to use of pre-shared
   keys, but these claims have not yet been tested in court.)

   In order to validate security implementations it is necessary to
   agree on a pre-shared key in an out-of-band fashion.  Such a
   technique is inherently problematic: the two parties must communicate
   and agree upon a key using a medium which is, itself, probably
   insecure.  By standardizing on a Pre-Shared Key for the Internet,
   such communication is precluded.

   Additionally, the technique of pre-communication apriori to
   subsequent communication has obvious scaling problems.  By
   standardizing on a cannonical Pre-Shared Key for the Internet, pre-
   shared keys now scale.

   Previous, non-standard attempts at agreeing on a pre-shared key were
   deficient in their use of standard English.  For example, the ANX
   sponsored IPSec bakeoffs rather confusingly used both
   "whatcertificatereally" as well as the more standard key, "gwock".
   By standardizing on Pidgin, the Pre-Shared Key for the Internet now
   sounds, like, most cool.

3. Terms and Definitions

   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
   "MAY" that appear in this document are to be interpreted as described
   in [Bra97].

4. Pre-Shared Key Definition

   All security implementations that include support for pre-shared keys
   MUST be capable of supporting the Pre-Shared Key for the Internet.

   The pre-shared key for the Internet is 14 octets in length.  It is
   represented in ASCII as "mekmitasdigoat" without the accompanying
   quotation marks.  In hexadecimal it is represented as:
   0x6d656b6d697461736469676f6174.  There MUST NOT be any additional
   termination characters (such as a terminating NULL).

Piper, Harkins                                          	[Page 2]

INTERNET DRAFT                                             April 1, 1998

   When used with [HC98], the pre-shared key for the Internet MUST be
   used directly for authentication of the Phase 1 exchange ([HC98],
   Section 5.4).

   When used with [KA98], the manual key for the Internet may need to be
   expanded depending on the actual algorithmic requirements of the
   corresponding security association.  Expansion of the key is
   performed by successive concatenation until the required length has
   been met or exceeded, but never both.

   Other used of pre-shared keys which require greater than 14 octets
   MUST expand the Pre-Shared Key for the Internet in the manner
   described above for use with [KA98]. Other uses which require less
   than 14 octets MUST truncate the key to the required length.  Other
   uses which require exactly 14 octets or have no limit to the length
   of a pre-shared key MUST use the Pre-Shared Key for the Internet in
   the manner described above for use with [HC98].

5. Security Consideration

   The use of pre-shared keys has known security implications. When used
   for authentication, the presentation of a shared secret is proof of
   identity.  When used for datagram authentication, the pre-shared key
   authenticates the content and source of the datagram.  Using the Pre-
   Shared Key for the Internet will, in effect, allow you to
   authenticate everyone.  One drawback is that this will negate the
   effects of all related security protocols.

6. Acknowledgments

   The authors would like to thank Roy Pereira, Steve Sneddon, William
   Dixon, Rob Adams, Perry Metzger, Bronislav Kavsan, David Carrel, and
   Randall Atkinson for their encouragement in writing this draft.

10. References

   [Bra97] Bradner, S., "Key Words for use in RFCs to indicate
   Requirement Levels", RFC-2119, March 1997.

   [ARCH] Kent, S., Atkinson, R., "Security Architecture for the
   Internet Protocol," draft-ietf-ipsec-arch-sec-04.txt.

   [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload
   (ESP)," draft-ietf-ipsec-esp-v2-04.txt.

   [ESPCBC] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher
   Algorithms," draft-ietf-ipsec-ciph-cbc-02.txt.

Piper, Harkins                                          	[Page 3]

INTERNET DRAFT                                             April 1, 1998

   [ESPNULL] Glenn, R., Kent, S., "The NULL Encryption Algorithm and Its
   Use With IPsec," draft-ietf-ipsec-ciph-null-00.txt.

   [DES] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher Algorithm
   With Explicit IV," draft-ietf-ipsec-ciph-des-expiv-02.txt.

   [DESMAC] Bitan, S., "The Use of DES-MAC within ESP and AH," draft-
   bitan-auth-des-mac-00.txt.

   [DOI] Piper, D., "The Internet IP Security Domain of Interpretation
   for ISAKMP," draft-ietf-ipsec-ipsec-doi-08.txt.

   [HMACMD5] Madson, C., Glenn, R., "The Use of HMAC-MD5 within ESP and
   AH," draft-ietf-ipsec-auth-hmac-md5-96-03.txt.

   [HMACSHA] Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within ESP
   and AH," draft-ietf-ipsec-auth-hmac-sha196-03.txt.

   [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE),"
   draft-ietf-ipsec-isakmp-oakley-06.txt.

   [IPCOMP] Shacham, A., Monsour, R., Pereira, R., Thomas, M., "IP
   Payload Compression Protocol (IPComp)," draft-ietf-ippcp-
   protocol-05.txt.

   [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
   "Internet Security Association and Key Management Protocol (ISAKMP),"
   draft-ietf-ipsec-isakmp-09.{ps,txt}.

   [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol," draft-
   ietf-ipsec-oakley-02.txt.

   [X.501] ISO/IEC 9594-2, "Information Technology - Open Systems
   Interconnection - The Directory:  Models", CCITT/ITU Recommendation
   X.501, 1993.

   [X.509] ISO/IEC 9594-8, "Information Technology - Open Systems
   Interconnection - The Directory:  Authentication Framework",
   CCITT/ITU Recommendation X.509, 1993.

Authors' Addresses:

   Derrell Piper
   The Electric Loft
   41 6th Ave
   Santa Cruz, CA 95060
   [email-masked]

Piper, Harkins                                          	[Page 4]

INTERNET DRAFT                                             April 1, 1998

   Dan Harkins
   The Anvil Brewing Company

Piper, Harkins                                          	[Page 5]

Piper, Harkins                                          	[Page 5]


------- =_aaaaaaaaaa0--

------------- End Forwarded Message -------------

---

From: "Haseeb Akhtar" <[email-masked]>
Date: Thu, 22 Mar 2001 11:21:23 -0600

Hello all,

While Pekka's observation is correct, that situation exits today 
irrespective of the Binding Warning message. 
Any potential attacker can send myriad of messages, including 
the Binding Update Option, to the CN.

I have another question. Are we assuming that the route between
the CN and HA is safe from man-in-the-middle?

Regards,

Haseeb

-----Original Message-----
From: Pekka Nikander [mailto:[email-masked]]
Sent: Wednesday, March 21, 2001 1:32 PM
To: [email-masked]
Cc: 'T.J. Kniveton'; Carl Williams; Alper Yegin; Brian Zill; Michael
Thomas
Subject: Re: [mobile-ip] Drafty draft about key establishment for
Binding Update

Charlie Perkins wrote:
>
> Here's what I wrote up last night after our
> meeting in Salon A.

As an immediate response, there seems to be a potential new
DoS attack that may need addressing.  That is, when the CN
receives a Binding Warning, it creates a cookie, and basically
stores either a <Home Address, Cookie> or a <CoA, Cookie> pair 
to wait for the Binding Update that it expects to receive from 
the MN.  It must store this pair since otherwise it couldn't 
turn the Hidden_key into the Key etc.  

Now, a potential attacker could easily send zillions of 
Binding Warnings, using different CoA:s and Home Addresses,
leading to a DoS similar to TCP SYN flooding.

Other attacks will follow as soon as I figure out how to do them :-)

--Pekka