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

From: Charlie Perkins <[email-masked]>
Date: Wed, 21 Mar 2001 10:59:46 -0800

Hello folks,

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

Regards,
Charlie P.
Binding Key Establishment for Mobile IPv6

Abstract

A method is proposed for providing key information for use
between a mobile node and correspondent node, to be used
for the purpose of authenticating Mobile IPv6 Binding Updates.
The key districution is secure except against man-in-the-middle
attacks, when the attacker resides in the routing path between
the correspondent node and the mobile node's home agent.
The key can be used for authenticating subsequent Binding Updates
from the same mobile node, substantially reducing the number
of key establishment cycles needed for maintaining efficient
communication paths between the mobile node and correspondent
node.

Introduction

Mobile IPv6 specifies the use of a Binding Update destination
option for use between a correspondent node and a mobile node.
This Binding Update associates a "care-of address" to the mobile
node's "home address" enabling direct routing of packets to
the current point of attachment in use by the mobile node.
Unfortunately, there may be many instances where no pre-existing
security association is available for use by the correspondent
node to authenticate a Binding Update from the mobile node.

In order to solve this problem, we propose a method by which
a correspondent node supplies some random data for use by the
mobile node as input to an algorithm for creating a security
association.  This security association, once established
between the mobile node and the correspondent node, is then
used to create the authentication data that is required to be
supplied as one of the security fields of the Binding Update
destination option.

Without introducing reliance upon use of certifiable public
keys, it is quite difficult to avoid all attacks against the
correspondent node that might allow some malicious third part
to masquerade as the mobile node.  However, we can at least
make sure that any such malicious node would have to reside
on the routing path between the correspondent node and the
home agent.  This substantially reduces to the vulnerability
to such attacks, since the specific routing path required
amounts to an extremely small proportion of the Internet.

In this protocol specification, several new messages are
introduced:
- Binding Warning, which is sent by a mobile node to a
  correspondent node as an indication that a new care-of
  address should be obtained for the one of the mobile node's
  addresses.
- Binding Request, which is sent by a correspondent node
  to the address of the mobile node in order to elicit
  a Binding Update.

In addition, the following extension is specified for
use in messages to the correspondent node.
- Binding Authentication Key Establishment Extension, which
  supplies a key to be used by the correspondent node when
  verifying authentication data supplied by the mobile node
  to ensure the integrity of the Binding Update data.

Subsequent sections provide an overview of the operation of
the key establishment mechanism, the format of the protocol
messages, and detailed specification for the message formats.
Although a specific authentication algorithm is proposed,
it should be noted that other authentication algorithms
may be proposed in the future.  However, for interoperability,
all correspondent nodes SHOULD implement the algorithm
specified in this document.

NOTE: I don't care what the algorithm is, so if the one
      in this document isn't right, I don't mind taking
      someone's suggestion about using another one.

============================ Terminology ============================

RFC 2119

Cookie

Key

Binding Key

Security Association

============================ Overview ============================

A mobile node MUST have any security association with a correspondent
node before it can securely supply a Binding Update to that correspondent.
If no security association exists for that purpose, the mobile node
SHOULD send a Binding Warning to the correspondent node, asking it to
start the process of establishing the needed security association
with the indicated address of the mobile node.

When a correspondent node receives a Binding Warning message,
it selects an appropriate 64-bit random number and inserts it
into the Cookie field of the Binding Request message.  It then
sends the Binding Request to the home address of the mobile node.
The Binding Request message MUST NOT contain any routing header
entries with any current or previous care-of addresses used to
send packets to the indicated address of the mobile node.

Similarly, if a correspondent node determines for any reason
to establish a Binding Key with the mobild node, it may send
a Binding Request with a newly selected cookie to the mobile
node, even if the mobile node has not issued the Binding
Warning message to the correspondent node.

When the home agent gets the Binding Request, it MUST tunnel
the packet to the mobile node.  The tunneled packet SHOULD
include an IPSec ESP header to assure privacy for the
Cookie data supplied by the correspondent node.

When the mobile node gets the tunneled Binding Request, it
first decapsulates the packet.  Before the mobile node processes
the Binding Request, it SHOULD ensure that the message was
tunneled from its home agent.

If the Binding Request suboption contains the Cookie suboption,
the mobile node creates a key according to the following
algorithm:
	Key := HMAC_MD5 (Cookie || CN IPv6 Address || Cookie)
where "CN IPv6 Address" is the IPv6 address of the correspondent
node sending the Binding Request, available as the Source IP
address from the encapsulated IPv6 header.  The mobile node MUST
create a new security association for the correspondent node,
associate the key with the new security association,
and insert this new security association into its security policy database
with the appropriate indications to enable future use when creating
the Authentication Data for the Binding Update destination option.

The mobile node then uses the key to create the Authentication
Data for the requested Binding Update destination option.  The default
algorithm for creation of the authentication data is as follows:
	Auth_data  :=  HMAC_MD5 (Key  ||  Previous Fields  || Key)
The mobile node then obscures the key according to the following algorithm:
	Hidden_Key  :=  Key XOR Cookie

Finally, the mobile node creates a Binding Key Establishment
suboption for the Binding Update message, and inserts the
Hidden Key into the appropriate field of the suboption.

When the correspondent node receives the Binding Update, it
first checks to see if there is a Binding Key Establishment
suboption.  If so, then it retrieves the hidden key according
the following algorithm:
	Key  :=  Hidden_Key XOR Cookie
The correspondent node then checks the validity of the
Authentication Data by performing the same calculation
with the newly established Key, as was performed by the
mobile node when creating the key data.

===================== Packet Formats ==========================

=================== Security Considerations ==========================

If the home agent does not encrypt the Binding Request packet
when tunneling it to the mobile node (as in section~\xref{over},
the key establishment will be vulnerable to any malicious node
present along the routing path from the home agent to the
mobile node.

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 21 Mar 2001 21:31:39 +0200

> Here's what I wrote up last night after our

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 21 Mar 2001 21:26:52 +0100

=> this is enough to assume real trouble if this is used between
two mobile nodes (even I am sceptical some have predicted that
a large part of the Internet will be mobile.

Sorry

[email-masked]

PS: I believe we need the two essential parts of IKE phase one:
 - shared secret with Diffie-Hellman or similar mechanisms
 - authentication (binding acknowledgement needs symetrical
   authentication)
The first must be end-to-end, the second is the hard part but
easier to provide, for instance if you have a third party (like
between MN-HA using the AAA network, cf draft-perkins-aaav6-03.txt
or instantiation draft-dupont-mipv6-aaa-00.txt).
We can reuse many ideas of the authentication/authorization brain
storming (I have archives).

---

From: Michael Thomas <[email-masked]>
Date: Wed, 21 Mar 2001 15:02:12 -0800 (PST)

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

 > 
 >   Dan.
 > 
 > On Wed, 21 Mar 2001 10:59:46 PST you wrote
 > > 
 > > Hello folks,
 > > 
 > > --------------AEBC641D4795CA0B8063A13A
 > > Content-Type: text/plain; charset=us-ascii;
 > >  name="Draft"
 > > Content-Transfer-Encoding: 7bit
 > > Content-Disposition: inline;
 > >  filename="Draft"
 > > 
 > > --------------AEBC641D4795CA0B8063A13A--
 > >

---

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

_authorization_ then. 

  Note that if you actually read the proposal you'd see that it says:
"A method is proposed for providing key information for use between a
mobile node and correspondent node, to be used for the purpose of
*authenticating* Mobile IPv6 Binding Updates." (emphasis mine).

  Dan.

On Wed, 21 Mar 2001 15:35:05 PST you wrote
> Dan Harkins writes:
>  >   Oh darn, that's right. That pesky authentication stuff. 
> 
>   s/authentication/authorization and get back to me.
> 
> 			Mike
> 
> 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:
>  > 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]
>  >

---

From: Michael Thomas <[email-masked]>
Date: Wed, 21 Mar 2001 15:35:05 -0800 (PST)

Mike

In that case I

---

From: Michael Thomas <[email-masked]>
Date: Wed, 21 Mar 2001 19:55:28 -0800 (PST)

Well, I didn't write that text but suffice it to
say you still haven't answered my original
question.

		Mike

Dan Harkins writes:
 >   Maybe you can explain to me how this key is being used to provide
 > _authorization_ then. 
 >

---

From: András Méhes <[email-masked]>
Date: Thu, 22 Mar 2001 13:51:05 +0100

What is the reason for the Hidden_Key
and the Binding Key Establishment suboption?
It seems as if the CN could compute the key itself.

> Key := HMAC_MD5 (Cookie || CN IPv6 Address || Cookie)

Am I missing something?

--andrás

---

From: Dan Harkins <[email-masked]>
Date: Thu, 22 Mar 2001 07:17:02 -0800

suffice. Pick your favorite one. 

  My point was that you cannot authenticate a message with unauthenticated
keys and the same people that can muck with a binding update (which I assume
is motivating this) are the people who can play man-in-the-middle against
this scheme. That is regardless of the existence of, or the distaste in
using, some entity to act as a trusted third party.

  Dan.

On Wed, 21 Mar 2001 19:55:28 PST you wrote
>  > >  > >  >   If the binding updates are important enough to require cryptog
>raphi
>  > >c
>  > >  > Piper, Harkins                                          	[Page 1
>]
>  > >  > Piper, Harkins                                          	[Page 2
>]
>  > >  > Piper, Harkins                                          	[Page 3
>]
>  > >  > Piper, Harkins                                          	[Page 4
>]
>  > >  > Piper, Harkins                                          	[Page 5
>]

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 23 Mar 2001 09:42:11 -0800 (PST)

I think this discussion will go on and on and we will eventually  end 
up re-inventing IKE. Why can't we just do IKE phase I using self
signed certificates (as suggested by someone...) and use this
shared secret to generate a token (SHA-1(Home address, care of address,
sequence number, Secret) - which will be used to tell the correspondent
node that you have moved. 

I will write up something more formal on this.

-mohan

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 23 Mar 2001 14:06:58 -0800 (PST)

> Other attacks will follow as soon as I figure out how to do them :-)
Even IKE stores state before responding to the first packet from
the initiator. Only Photuris does not have this by negotiating
cookies separately. We can use similar mechanisms to achieve
the same here. I think we need requirements before discussing
a solution.

-mohan

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 23 Mar 2001 16:43:29 -0800

Hello Mohan,

>          I think we need requirements before discussing
> a solution.

I think the requirements can be stated as,
"First, do no harm".  Translated into Internet
terms, this means that our solution should not
introduce any vulnerability beyond what would
be experienced by a stationary node on its
IPv4 network.  This is an approximation, of
course, to be adjusted according to whatever
understanding we might develop.

There are two major problems identified by the
recent security discussants that are preventing
Mobile IPv6 from becoming Proposed Standard.
First is to eliminate reliance on AH, since the common
deployment model(s) for AH is not precisely
compatible with the usage envisioned with the
Binding Update.  There are various small problems,
which are all solvable by adding more security
related fields to the Binding Update, and then
just not using AH (or ESP) for doing the authentication.
But this isn't the biggest source of our pain.

The other major problem has to do with key
establishment between the mobile node and the
correspondent node.  The dictum to "do no harm"
that we should try to get a key between the nodes
without creating vulnerabilities to any attackers,
except _perhaps_ those that might be posed by a
malicious node between the correspondent
node and the home network.  This is a solvable
problem.

Placing ever more subtle requirements on the
problem may be satisfying for the perceptive
individuals who can thus demonstrate the depth
of their understanding, but it isn't doing to help us
get to Proposed Standard.

Is my statement of requirements sharp enough?
If not, can you suggest an improvement?

Regards,
Charlie P.

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 23 Mar 2001 17:32:37 -0800

So, have you figured out how to do them?

vijay

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 23 Mar 2001 17:52:44 -0800 (PST)

> node and the home network.  This is a solvable
Key management itself does not have any major issues (all
of them are minor) as it is possible to achieve
what we want if the MN is communicating with HA.
Two main problems are :

1) Authorization problem.
2) IPsec AH does not seem to scale as we need to maintain one IPsec
   SA per MN on the CN.

If we are not going to solve (1) and we don't like (2), we need
a new mechanism all we need is to establish a shared secret and authenticate.
All the mechanisms are in IKE for doing this. The
shortcomings discussed before are not valid anymore. Once the secret
is established, as MN moves, all we need is a token to send a new
binding update. We can construct the token in such a way that replay
attacks etc. can be avoided. Wouldn't this move it to proposed
standard faster than any other solution ? If there is a possibility
to avoid some attacks, then we should seek that approach. Otherwise,
there will be too many opinions and we will spend a lot of time
discussing about it in the mailing list.

-mohan

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 23 Mar 2001 17:55:48 -0800

Why not just store the key in the Binding Update List 
entry maintained by the MN and in the Binding Cache Entry
maintained by the CN. This way you can have MIPv6 running
on a node completely independent of IKE/SPD/IPsec?

Vijay

Charlie Perkins wrote:
>   ------------------------------------------------------------------------

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 23 Mar 2001 18:09:15 -0800

Hi Mohan,

just one comment with one of the statements you made..

> 2) IPsec AH does not seem to scale as we need to maintain one IPsec

I dont understand what you mean by it doesnt scale. if a million
nodes are connected to a CN, it has to maintain a million binding 
cache entries. it has to maintain a million bits of other info
(could be anything) for each MN.

vijay

---

From: Francis Dupont <[email-masked]>
Date: Mon, 26 Mar 2001 10:51:14 +0200

I think this discussion will go on and on and we will eventually  end 
   up re-inventing IKE. Why can't we just do IKE phase I using self
   signed certificates (as suggested by someone...)

=> me... Self signed certificates is in IKE the weakest form of
authentication.

   and use this
   
=> there are many good ideas in IKE (at least for the crypto part).

=> I have thought more about mobile IPv6 security:
 - the home registration must use the best security available,
   ie. strong authentication.
 - section 10.9 (smooth handoff) is a bit special and is easy to do
   if it is prepared before the handoff (after it is a real security mess).
 - with a smart use of nonces the CN should be able to verify both the
   home address and the care-of address (by sending crypto messages to both).
   This makes the security scheme weak only to MITM attacks on both
   CN-HA and CN-MN paths: in general this implies the MITM is closed to
   the CN and is able to use any kinds of attack (including attacks against
   PKIs and/or DNS).
   This idea is the only case where we can find something better than raw IKE.

Regards

PS: about home address option: I believe the firewall of the visited network
must be mobility aware: don't think a security manager will authorize
source routing through his domain without notice! So we need a security
of the visited domain too, to leave the home address option in the cleartext
of every packets or fragments (as in ID 13) is a good point but we need more,
for instance a standard way to give mobility parameters (home address and
home agent address) to local AAA...

---

From: Francis Dupont <[email-masked]>
Date: Mon, 26 Mar 2001 11:17:02 +0200

cookies separately.

=> and only Photuris has no DoS problem with cookies (ie. Photuris
is right and IKE wrong about this).

   I think we need requirements before discussing a solution.
   
=> another vote to finish draft-glass-mobileip-security-issues ASAP?

---

From: Francis Dupont <[email-masked]>
Date: Mon, 26 Mar 2001 14:30:48 +0200

=> Vijay, Mohan did say this is his opinion: this is one of the arguments
against the current Mobile IPv6 security...

Regards

PS: any deduction about my own opinion from this is likely correct... (:-)

---

From: Mohan Parthasarathy <[email-masked]>
Date: Mon, 26 Mar 2001 09:38:03 -0800 (PST)

> against the current Mobile IPv6 security...
Sorry for the confusion. I was summarizing the IESG (and others) concerns
about using AH for solving the mobile IPv6 security problem.
I did not mean to use the word "scale". Hence, if we don't want to use AH
and not solve the authorization problem, why can't we just use the IKE
part alone ? If this is also considered heavy weight, all new solutions
should be compared against this. 

-mohan

-mohan

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 26 Mar 2001 21:19:17 +0300

Mohan,

> part alone ?

If I read correctly the IESG statement (I might be misreading it),
the concern is not about using AH per se but about "[the] significant 
overhead associated with building and maintaining AH/IPsec SAs", 
where "building" basically means running IKE.  I certainly agree 
that building a large number of AH SAs does require a lot of 
messages and a heavy daemon (the IKE deamon).   However, I am not 
so sure about the cost of "maintaining" a large number of SAs,
especially if the traffic flowing over those SAs is so small that
rekeying is not needed.  Thus, if we can establish some "special
purpose" AH SAs using some lighther protocol than IKE, I still think that
it might be a good idea to use AH or even integrity preserving ESP to 
protect the actual BUs.

By the way, if somebody has good numbers about the typical memory
print of an AH or ESP SA, it would be very interesting to see them.

--Pekka

---

From: "Paul Francis" <[email-masked]>
Date: Mon, 26 Mar 2001 10:30:02 -0800

> If I read correctly the IESG statement (I might be misreading it),

Where can I find the IESG statement?  I don't see it at
http://www.ietf.org/IESG/actions.html.

PF

---

From: Mohan Parthasarathy <[email-masked]>
Date: Mon, 26 Mar 2001 10:47:12 -0800 (PST)

> where "building" basically means running IKE.  I certainly agree 

I think the concern was more than that.

     a) There is significant overhead associated with building and 
      maintaining AH/IPsec SAs (both in terms of state that needs to
      be maintained, but also in terms of required message flows, and
      the processing required to implement those flows). This has
      negative implications for larger servers that process many 100s
      of thousands of connections at a time.

This talks about building and maintaining AH/IPsec SAs though i
don't understand the maintenance part :-)

b) The processing rules for authenticating a Binding Update with AH
      are complex and are apparently not readily supported by the
      current generation of IPsec/IKE implementations (e.g., the IPsec
      policies are needed that specify sufficient granularity about
      IPv6 packets containing binding updates). There is a concern
      that this will not be rectified in the short term or that
      providing this level of granularity is even approriate for
      IPsec, leading to a possible result that the Binding Update
      won't be implemented/supported at all, (or even worse) that it
      will be used without proper authentication.

This essentially talks about the lack of selectors for specific destination
options and the inability to negotiate one using IKE. I don't think
this is really that big a serious issue when compared to others.

> it might be a good idea to use AH or even integrity preserving ESP to 
We need to define what lighter protocol is ? Less secure (this needs
to be broken down further e.g. Is man in the middle attack ok ?
Is DoS attack ok ?), fewer roundtrips, less computational overhead
etc. This is the draft i was mentioning earlier at the IETF :

draft-snoeren-tcp-migrate-00.txt

which essentially does a diffie-hellman exchange and establishes
a shared secret. When the connection needs to be migrated, it
provides a token (HMAC of sequence numbers etc.). A similar one
can be done here. I think there is no authentication in this.
We can get it by routing packets through Home Agent if we feel
that it is sufficient.

-mohan

---

From: Michael Thomas <[email-masked]>
Date: Mon, 26 Mar 2001 11:54:37 -0800 (PST)

Dan Harkins writes:
 >   I don't have any particular treaty organizations in mind. Any one will

   You'll get no argument from me on this account.
   However this is all about picking one's poison. 
   If you think that the MIM attack is credible 
   enough that this is all loony-toon, by all means
   say so, and more importantly show some credible
   attack scenarios. It serves nobody to rehash old
   ground if we're headed for another unacceptible 
   dead end.

		Mike

---

From: Francis Dupont <[email-masked]>
Date: Tue, 27 Mar 2001 11:18:56 +0200

=> because of its sparse usage I believe the problem is more in the
creation/lookup/cleanup price in CPU cycles than in the memory print,
ie. we should get something similar to a lot of short TCP connections
with the 2MSL time wait replaced by medium lifetime (short lifetimes
will cost to much in IKE, long lifetime are not very secure and can give
very large tables... IPsec SA lifetimes are not easy to deal with for
this kind of applications).

Regards

PS: in fact the ISAKMP SA lifetime should be large in order to pay
only a phase 2 when the IPsec SA pair must be rebuilt but this works
only when the MN/initiator can use its home address in phase 1, ie.
this doesn't work at least with the home agent (a dedicated mechanism
will be able to benefit from the two addresses contrary to IKE).

---

From: Francis Dupont <[email-masked]>
Date: Tue, 27 Mar 2001 11:39:39 +0200

Is DoS attack ok ?),

=> there are minimal requirements but I believe we should do our best.

   fewer roundtrips, less computational overhead
   etc. This is the draft i was mentioning earlier at the IETF :

=> in my hands...

=> we can do something better: send a part of needed things directly
to the care-of address and the remainder to the home address (through
the home agent) so the MN will need to get the traffic from both paths
(and the MITM will need to intercept the traffic on both paths).

Regards

---

From: Jari Arkko <[email-masked]>
Date: Tue, 27 Mar 2001 14:43:42 +0300

There were some questions on this list relating to
exactly what the scalability issues wrt security are,
and how costly it is to maintain large numbers of
SAs etc. Maybe I can offer some thoughts on the
subject from the point of view of an IPsec
implementor (even on small systems):

* I'm pretty sure the IESG is talking about the
  overhead in setting up the SAs, not e.g. the
  overhead of IPsec AH itself. Why? See below...

* The header overhead per secured BU packet shouldn't
  be a concern. There aren't enough BU packets to
  make this significant.

* The cryptographic processing (e.g. MAC verification)
  shouldn't be a concern either. Again, you won't be
  doing all your traffic with these. And even if you
  were - what do you demand: that you can have security
  but not have to execute any cryptographic operations
  at all? MAC verification must be one of the cheapest
  cryptographic operations.

* Memory consumption. Well, essentially an SA needs
  an SPI number (4 bytes), protocol (1 byte), secret
  (e.g. 16 bytes), various algorithm etc indicators
  (say 4 bytes), and maybe a couple of other things
  such as sequence numbers. So, in conclusion you
  could spend in the best case maybe some dozens
  of bytes, typical implementations perhaps use
  something in the order of a few hundred bytes
  at the worst. (Adding encryption algorithm that
  needs a large table to speed things up could
  set you up for an additional few kilobytes.)

  Of course there also has to be some sort of
  policy information that determines which
  packet should be protected how, but I haven't
  counted this as that sort of thing depends to
  vary a lot between systems, and is in any
  case the same for all possible security schemes.

  In conclusion, the memory consumption varies
  as you use different length keys and different
  algorithms, but isn't really that significant.
  Think you need million SAs and claim that IPsec
  AH doesn't scale in terms of memory needed? Well,
  I'll use again my argument about the use of some
  crypto at least. Otherwise you won't have security.
  And if you have some cryptographic operations, do
  you think you're going to survive without any
  secrets or connection identifiers whatsover, or
  sequence numbers? Don't think so. No security
  costs less than security, but all security schemes
  will require _some_ amount of storage.

* What about the overhead in setting up the SAs then?
  Where are the concerns? (Don't you just love the
  divine wisdom we are getting from the iesg, it
  is very hard to decipher their input.)

  Here I think we see several issues. One, there
  is again a number of cryptographic operations
  which are very heavy this time: Diffie-Hellman,
  RSA, ... Second, protocols to negotiate this
  are complex. Third, how do we set up the trust
  for the protocols to work, do we need a global
  PKI?

*
I firmly believe the trust part is the hard
  one here. Almost everybody agrees that building
  global PKIs is neither possible nor desirable.
  I think this is what the IESG is worried about.

* Cryptographic operations for the set-up.
  This is a hard one, too, particularly for
  small systems. Before you decide that you
  can't afford protocol X because it uses
  algorithm Y which is heavy, please decide
  what are the security requirements! If you
  *can* compromise on Man-in-the-Middle protection,
  for instance, then maybe something can be done.
  Otherwise...

* Protocol complexity. Yeah. A lot of the
  complexity comes from the PKI stuff, by the
  way. Avoid that and you get rid of it...
  Not avoid it and it won't help much if you
  simplify your keying protocol or the packet
  protection protocol... Also, when you consider
  things like KINK in a global context you'll
  propably have to do Kerberos *and* public
  key schemes with PK-Init.

* I believe somebody mentioned also that IPsec
  can't deal with the policies to protect
  particular extension headers. I believe this
  is an issue that could be dealth with, if
  we wanted to.

Hope this helps,

Jari

---

From: Francis Dupont <[email-masked]>
Date: Tue, 27 Mar 2001 16:50:49 +0200

Almost everybody agrees that building
     global PKIs is neither possible nor desirable.

=> no, I disagree. This is not yet proved impossible and
this is desirable or I don't understand why we are trying
so hard to fix then deploy DNSsec!
So don't say everybody (or add "in the IESG" :-).

Thanks

---

From: Stuart Jacobs <[email-masked]>
Date: Tue, 27 Mar 2001 10:16:26 -0500

I have to add my 2 cents and agree with Francis.  Unless we move to a 
globally authenticatible networking environment we will always be plagued 
with security problems and the only way to scale up to this via PKIs.  We 
do NOT have to have one great PKI rather we should be thinking of a 
multitude of PKIs that are each established for specific purposes.  One can 
instantiate a PKI just for MIP that would provide asymmetric credentials 
bound to NAIs for authenticating NMs, CNs and mobility agents.

>[email-masked]

==========================
Stuart Jacobs CISSP
Sr. Technologist
Verizon Laboratories
40 Sylvan Road Waltham, MA 02451-1128     USA
telephone: (781) 466-3076   fax: (781) 466-2838
[email-masked]     [email-masked]
==========================

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Mar 2001 09:24:53 -0800 (PST)

One quick clarification:

 >   set you up for an additional few kilobytes.)

     Yes. I believe that both twofish and rijndeal
     are about two orders of magnitude slower (maybe
     more, my memory is fuzzy) when you don't use the
     tables. For all practical purposes, you are 
     going to need the tables in all but very special
     cases (read: not IPsec).

		  Mike

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 27 Mar 2001 13:06:26 -0800 (PST)

> (and the MITM will need to intercept the traffic on both paths).

While such complexity helps for some threats it doesn't deal with
MITM positioned close to the CN.
But we can't do much about that threat since the CN doesn't have any 
prestablished association with the HA or MN.

The most important threat to handle (that we can handle) is MITM
attacks on the MNs link.

   Erik

---

From: Erik Anderlind <[email-masked]>
Date: Tue, 27 Mar 2001 17:49:44 -0500

Hi Erik,

> The most important threat to handle (that we can handle) is MITM

Most wireless links provide encryption between mobile and base station.
Examples are GSM, GPRS, IS-95, Cdma-2000, W-cdma. For 802.11b the use of
link encryption (called WEP) is optional to implement. Many 802.11 cards
support it,
but just as for any security, key administration is a hassle and many
sites turn it off.

Is the focus on solving MITM for wired Ethernet and cable? What about
break-ins
to content side DMZs or other places.

Where do we really belive the largest MITM attack risk is? 
(Or is this a faulty approach, since we want to have some assurance that
all places where a MITM attack could be initiated are covered?)

Are we re-solving an 802.11 problem that already has a technical
solution (but which 
perhaps did not take in account "user friendly" key distribution?)

Erik A.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Mar 2001 09:23:40 +0300

>      going to need the tables in all but very special

Well, you're going to need the tables *exactly*
when you need the algorithms in question. Has got
nothing to do with the protocol at hand. My ipsec
implementation, for instance, doesn't allocate
the tables unless encryption is used _and_ the
particular algorithm is used. Same principles apply for TLS,
Kerberos, and any other protocol. In my understanding
of the MIP BU protection, we really don't need
encryption so memory usage for the tables isn't
an issue in this discussion.

Jari

---

From: Francis Dupont <[email-masked]>
Date: Sat, 31 Mar 2001 12:01:03 +0200

=> if the MITM is close to the CN IMHO only a global PKI can help
and we may not assume this is available.

=> exactly.

=> the ESP on the HA->MN tunnel idea gives a good way to handle this.
I have more detailed idea about a solution but I have more to 1000 mails
to read too (:-)...

Regards