Subject: [mobile-ip] Question on draft-arkko-mipv6-bu-security-00.txt

From: Erik Nordmark <[email-masked]>
Date: Tue, 23 Oct 2001 17:25:25 +0200 (CEST)

The abstract to the draft says
     The Mobile IP working group is  currently  searching  for  a  security
     solution  that  enables  semi-secure, weak authentication between IPv6
     Mobile Nodes and Correspondent Nodes in the the global Internet.  Sub-
     sequent  Binding  Updates  messages  will  then  be  cryptographically
     integrity protected to prevent abuse of the mechanisms for route opti-
     mization.   

I don't recall seeing a requirement that all but the first BU be 
cryptographically protected. Is there such a requirement?

I was thinking that a possible "corner" in the design and solution space
was a mechanism that makes each binding update be done through a 3-way
handshake i.e. the return routability property is verified for each
BU. Folks might argue about the performance and performance tradeoffs for
such an approach - but I think it at least make sense to consider such
an approach.

  Erik

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 23 Oct 2001 19:13:06 +0300

> cryptographically protected. Is there such a requirement?

The intention was to say that e.g. a BAKE authentication takes
place and creates an SA, and then all BUs will be protected by
this SA. The first BU should of course be included in this protection

> such an approach - but I think it at least make sense to consider such

This is indeed an important issue. Somewhere in the draft I think
I mentioned that we must first decide whether we want this authentication - SA
model. It has been proposed that each BU could perform the authentication,
and then no SA would be needed. Looking at the proposals, this produces
typically a 3-message BU rather than just a single BU. OTOH, if you don't
have long-lasting CN-MN relationships, you are bound to get this anyway.

It is important to realize that the authentication - SA model is just an
*optimization*. That is, it brings no added functionality beyond reducing
the number of messages. Most people that I've talked to seem to feel
that the optimization is a necessary one, though.

It is interesting to note that if the WG decides to adopt the authentication-only
model then there'd be an easy conclusion to the -14 vs. ah discussion: neither
option would be needed!

Another interesting note is that if we pick solution 6.4 then this could live
with the authentication-only solution in the global Internet (with 3 messages
per BU), and where local PKI is available this could be reduced to ipsec-only
(with 1 message per BU).

Question: how useful will route optimization be, if every movement must be
announced by three messages, not one?

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 23 Oct 2001 18:42:53 +0200 (CEST)

> I mentioned that we must first decide whether we want this authentication -
> SA model. It has been proposed that each BU could perform the authentication,

Yep. And a 3-way BU might incur different crypto algorithm compute cost
on the MN and CN than something which establishes a SA as part of
the 1st BU.

BTW: The draft (after reading some more) talks about authentication
and never about authorization aka address ownership of the home address. 
I think return routability is one presumed
source of authorization and SUCV like solutions provide another model
for authorization.

Clearly the WG needs to do something about both authorization and 
authentication and at some level the solutions to the two might be independent.
But the draft seems to state that the only problem is one of authentication
which isn't correct. (But perhaps the authorization discussion and tradeoffs
could be clarified by another I-D.)

> that the optimization is a necessary one, though.

But the SA model is also likely to have different security properties that
an 3-way BU. Some of this is hard to discuss without a concrete 3-way proposal
to look at but it seems to me like in the SA case a node that was a MiTM at
some point in time but later, due to the MN moving, is no longer on the path,
can cause different damage in the 2 cases. With an SA approach that attacker 
could acquire the keying material and use that to affect communication
between the MN and CN until the keying material "times out".
In the 3-way BU model such an attacker could only affect the BUs as long as it
remains on the path.

> It is interesting to note that if the WG decides to adopt the
> authentication-only model then there'd be an easy conclusion to the -14 vs.
> ah discussion: neither option would be needed!
> 

It would be good to understand the performance aspects of BUs in general,
but I haven't seen any real data being exchanged in the WG.

One observation is if the MN doesn't move often, but talks to many CNs,
then there might be just one BU per CN (to tell the CN not to go through the 
HA). Thus this will be at least a 3-way handshake in all cases (and more if
IKE is used I think). In such cases establishing a SA is wasted effort.

If, for a given communication between a MN and CN, the MN moves multiple times
within the lifetime of the SA, then it would make sense to establish an SA.

But folks are likely to have different views at which "granularity" MIPv6
will be used which effects how many times a MN would move while communicating
with a given CN, so I don't see an easy way to resolve this.

  Erik
``

---

From: Michael Thomas <[email-masked]>
Date: Tue, 23 Oct 2001 10:10:02 -0700 (PDT)

> announced by three messages, not one?

Jari,

There's actually a third option that is in between
the simplicity of always performing a three way
handshake, and the overhead of performing
ephemeral Diffie Hellman's. Something to observe
about the DH exchange is that what it primarily
creates is shared state between the two nodes
which can be used for subsequent binding updates
to have some belief that they are from the same
sender.

Using strong cryptography, you'd ordinarily
exchange credentials at this point to eliminate
man in the middle attacks and positively verify
the peer. However, since we are foregoing that
protection in the name of scalabilty, the DH
exchange is _only_ being used as a means of
establishing shared state. The reason is that it
is only as strong as the initial return
routability test; if you don't believe that that
test is sufficient, djinning up a key based on
that test does not make subsequent transactions
any safer.

Where this leads me is to question why we need
something as expensive as a DH exchange. Why not,
instead, just exchange large random numbers which
can be kept in sync by the MN and CN. Essentially,
this would mimic TCP's use of SEQ/ACKSEQ, but
forgo the connection aspects of TCP (ie, what's
needed is "soft" connection state, rather than
"hard" state as with TCP). I believe that this too
meets all of the requirements, and would allow us
to have an initial 3 way handshake with subsequent
updates only requiring a single exchange. Indeed,
it is probably a better fit for the requirements
since it sidesteps the thorny issues surrounding
any use CPU intensive asymmetric cryptography.

	     Mike

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 23 Oct 2001 23:11:52 +0300

> source of authorization and SUCV like solutions provide another model

The term 'authentication' was used in my draft to (inaccurately) describe
'all that BAKE and other proposals do' ;-) Depending on the proposal,
they use various kinds of schemes, such as return routability or pk hash
properties. Is the authorization a correct term to use here? What if in some
cases we have strong authentication and authorization? In the weak case
we don't seem to have any real authentication, only authorization.

As a side note, we'd also benefit from some terminology to replace 'weak
authentication' with something that doesn't sound so negative...

> In the 3-way BU model such an attacker could only affect the BUs as long as it

Yes, there may be some differences in the security properties as you point out.
After I sent my previous e-mail I started thinking about the various replay
attack scenarios and the effect of SA/no-SA on them; there may be differences
in that as well. It is not clear to me if the sequence number in a BCE is zeroed
when the entry is created or when the SA associated with it is created.

As to your specific example, there's a difference depending on whether the
MN makes an attempt to send a BU or not. If it sends a BU it will detect that
it didn't get an ACK, and will rerun BAKE, recreating the security association
and there is no problem. If the MN is not sending BUs (perhaps because it
is not communicating with the CN), then the attacker is "free" to use the SA
at will until it expires.

Jari

---

From: Michael Thomas <[email-masked]>
Date: Tue, 23 Oct 2001 13:39:30 -0700 (PDT)

> we don't seem to have any real authentication, only authorization.

With the weak version, we have both. It works as
follows: you claim to be at address ::w.x.y.z, and
the CN in order to authenticate you sends you off
on a return routability test. By completing the
test, you are authenticated as that address
(albeit weakly) and this in and of itself is
sufficient to authorize you to change that and
only that address's current binding (as opposed to
authorizing you to change the binding for any
address, etc).

 > authentication' with something that doesn't sound so negative...

I feel the opposite. I think we should be very up
front about the fact that this doesn't use strong
authentication so that we don't look like yokels
who found the security equivalent of a perpetual
motion machine. Otherwise somebody like Bruce
Schneier is going to come along and point out the
obvious, implying that we were so stupid that we
actually believed that this was a strong
authentication alternatative...

		Mike

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 24 Oct 2001 10:55:53 +0200 (CEST)

> 'all that BAKE and other proposals do' ;-) 

After reading the complete document I found the "address ownership" section 
which has some of what I was looking for. (BTW: It's a 
really good document summarizing the issues and options).

> Depending on the proposal,

I think authorization is the best term for the general concept. (See RFC 2828)
In this case the question is whether a given nodes is authorized to
redirect packets for a given home address. This could be expressed as
"does the node own the address" but that might rat-hole into what
"ownership" means - ISPs only lend IP address prefixes to their customers etc.

Clearly the strength of the authorization and authentication can differ.
For instance, one could envision a (bad) solution which is to use IKE to
setup a SA between the CN and the CoA, and then have the MN at the CoA say
"trust me I'm really this home address". This would be a case with
no possible authorization check but with strong authentication.
If instead IKE is used between the home address and the CN
then the authorization ends up being return routability since IKE would send
packets to the home address.

I don't know whether the weak form should terminology-wise be viewed to
lacks authentication. RFC 2828:
    $ authenticate
      (I) Verify (i.e., establish the truth of) an identity claimed by
      or for a system entity. (See: authentication.)
One could view return routability as verifying (subject to MITM etc)
that the identity claimed in that of the MN at its home address.

Of course, the packets carrying the BU (or a BSA exchange before the BU)
might not be authentic since there is no strong integrity check 
(and "authentication" often includes the inegrity part).

Unless there is a better suggestion I think it makes sense to view
return routability as both providing weak authentication that the sender
is the MN at its home address, and as such being authorized.

But ... perhaps I'm out in the weeds.
If you can just authenticate the identity of the MN then of course the MN
is authorized to redirect its own packets. So we might not need
to use "authorization" but instead discuss how to verify the "identity" of the 
MN.  The weak identity check is: is capable of receiving packets addressed 
to the home address (which of course any node in the path between the CN
and home address are)
When binding part of the address to a public key the identity check becomes:
the entity can prove it posseses the private key.

One can also envision other approaches to establishing the identity
but they have deployment problems such as using certificates tied
to the IP address (which means that the CA needs to verify that
the entity indeed "is" or "owns" the IP address before handing out the CERT).
Or using a DNSsec secured in6.arpa tree which contain a public keys and
the MN holds the corresponding private key. Thus the fact that the admin 
creates this entry in the DNS means that the admin has assigned that home 
address to the MN. And the in6.arpa delegation tree provides authority to do
that from the IANA and down. (But this requires DNSsec to be deployed for
all of in6.arpa.)

> authentication' with something that doesn't sound so negative...

"MN identity verified using return routability"?
"MN identity verified using the routability to the home address"?

> Yes, there may be some differences in the security properties as you point
> out. After I sent my previous e-mail I started thinking about the various
> replay attack scenarios and the effect of SA/no-SA on them; there may be
> differences in that as well. It is not clear to me if the sequence number in
> a BCE is zeroed when the entry is created or when the SA associated with it
> is created.

I think you need a local timestamp on the CN in the no-SA case - but 
I should try to write this down. 

The SA case might be have differences depending on the details of such a 
protocol. For instance there is potentially two different cases: the initial 
SA created after the first BU, and what happens after the CN has
discard the BCE (and the SA) but the MN retains the SA in the binding update 
list.

> it didn't get an ACK, and will rerun BAKE, recreating the security
> association and there is no problem. If the MN is not sending BUs (perhaps
> because it is not communicating with the CN), then the attacker is "free" to
> use the SA at will until it expires.

Assuming that the BUs sent to CNs always ask for an ACK. The current spec
seems to say that the ACKs only only required for BUs sent to the HA.
Of course, if it turns out that HA options can be sent until it is known
that the CN has a BCE then all BUs need to be acked.

  Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: 29 Oct 2001 14:34:16 +0100

> authentication' with something that doesn't sound so negative...

Yes, the term "weak authentication" is at least misleading to me.  One
can have strong/weak algorithms, terms that traditionnally refer to
resisting brute-force, but not to routability or infrastructure.

I suppose that, at some of its origins, "weak authentication" was used
to refer to Unix login authentication, passwords being stored locally
and subject to traffic analysis.  Contrasted to "strong auth" that
would imply third-party hosts to authenticate.

Thus I would propose "weak auth"   - "infrastructure-free authentication"
                     "strong auth" - "infrastructure-based authentication".

Alex