Subject: RE: [mobile-ip] A less drafty draft

From: Phil Roberts <[email-masked]>
Date: Wed, 11 Apr 2001 17:26:00 -0400

> -----Original Message-----
> From: Francis Dupont [mailto:[email-masked]]
> Sent: Wednesday, April 11, 2001 5:22 PM
> To: [email-masked]
> Subject: Re: [mobile-ip] A less drafty draft 
> 
>    
> => do you propose to create a new WG or to add a security 
> statement in the
> charter? (I believe the second solution is the best one)

I'm not sure what Phil (the other one) is proposing, but we don't
need a security statement in our charter.  All protocols that are
produced for Proposed Std must have a security considerations section.
It's our responsibility to make sure our protocols are secured.  The
assumptions we've made about what and how we could make MIP v6 secure
were mistaken to some degree.  The task at hand now, as I explained
in an earlier post, is to get a better set of requirements, reconsider
our assumptions, and update the MIP v6 draft in a way that is secure
enough to satisfy the IESG.  We're trying to involve folks with security
clue in every step of this activity.

Phil

---

From: Jean-Michel COMBES <[email-masked]>
Date: Thu, 12 Apr 2001 16:20:58 +0200

Hi Phil,

Phil Roberts a écrit :

> in an earlier post, is to get a better set of requirements,

JMC :
For the moment, I saw at least two solutions to secure BU but no set of
requirements (unless you speak about Thomas Narten's mail). Did I miss
something ?

> reconsider

Regards.
JMC.

--

France Telecom R&D - DTL/SSR
Jean-Michel COMBES, Internet/Intranet Security
E-Mail : [email-masked]
Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19
PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214

---

From: Jean-Michel COMBES <[email-masked]>
Date: Thu, 12 Apr 2001 17:17:21 +0200

Hi Mike,

Excuse me but this wasn't a remark, just a question. I should have to change
my mail subject ...

Regards.
JMC.

Michael Thomas a écrit :

> Jean-Michel COMBES writes:
>  > JMC :
>    Yes, it's very upsetting to see Charlie throw
>    down the gauntlet here which will surely start
>    a draft war. I thought we had all agreed
>    to wait for the chairs to put together the
>    requirements based on feedback from the IESG
>    so that we could at least have some basis to
>    evaluate drafts in light of *their* requirements.
>    As it is right now, this is all pure speculation
>    and will only serve to lengthen this process.
>
>                    Mike

--

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 12 Apr 2001 09:31:26 -0700

Hello Michael,

Michael Thomas wrote:

>    a draft war.

I sure am surprised to see this reaction.  We don't need
to have a draft war.  We need to expedite work towards a
goal.  If BAKE doesn't meet the requirements set forth,
then either it has to be modified or discarded.

My experience is that when someone is motivated to get
the job done and has the ability to do it, good results
are possible.  It's better to take advantage of the drive
and motivation engendered by the need for immediate
action.  I feel that we need to get the security issues
resolved sooner rather than later, and Pekka and I were
motivated to try to accomplish something.  I'd prefer
that not be characterized as something malevolent, but
whether you prefer to do so is, of course, your choice.
I'd rather you see it as a solid step towards a goal,
but again...

>                  I thought we had all agreed

You and I have been in some of the same rooms where the
requirements were pretty clearly laid out.  We are both
waiting for more official formulations.  There is a lot
of work to do.  I don't intend to do anything to lengthen
the process.  On the contrary.  Furthermore, it will be
the responsibility of Pekka and myself to make sure our
draft meets the requirements, as they become more
concretely formulated.  How will this result in lengthening
the process?
 
Our draft is not pure speculation, and it's intended to
be part of a draft war, and we have constructed no gauntlet.

Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 12 Apr 2001 09:54:51 -0700 (PDT)

What you are of course not bringing up is that
Dave Oran and I had a concrete draft on this
subject from *before* IETF 50 which I shared with
both you and Pekka. I see that you two have
incorporated several of the features of the draft
as well, though unacknowledged. I have been
waiting to publish it because we agreed to wait
for the chairs to lay out the ground rules and
form the design team. Yet you've decided -- again
-- to take matters into your own hands and start
the process that is very likely to extend this for
a very long time.

Express faux-surprise all you like. I find it
rather disingenuous. It needn't have been this
way.

		Mike

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 12 Apr 2001 10:10:13 -0700

Hello Michael,

The effort in this draft stems from the triangle I drew
on the paper in that room on Tuesday night.  Pekka
graciously offered to fill out the details, which he
has done in "impeccable" fashion.

> both you and Pekka.

I didn't bring up your draft, because it wasn't
relevant to the discussion in your note.  I assume
now that you believe in the possibility of a draft
war between your draft and the BAKE draft.  Fine.
I don't really have time to fight.

>                       I see that you two have
> as well, though unacknowledged.

I have no conscious recollection of taking any
ideas from your draft.  However, if you would like
to be acknowledged, please craft the acknowledgement
you want and (within reason and agreement from Pekka)
I'll include it in the Acknowledgement section.

>                                  I have been

I decided to take action that Tuesday night, and I didn't
hear anyone say not to.  I did in fact, send out a
primitive version of the draft that same week.  It did
not elicit this kind of heavy-handed accusation from you,
nor any request to delay further development.  I didn't
ask you to stop working on your draft, either.

> rather disingenuous. It needn't have been this

I may be a lot of things, but I'm not a liar.
And what is "it", that needn't have been this way?
I still want to get a good solution ASAP.  I'm sure
you can help very much if you so choose.

Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 12 Apr 2001 07:58:20 -0700 (PDT)

Mike

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 14 Apr 2001 09:13:46 +0300

Michael,

Please accept my sincere apologies that I have hurt 
your feelings by being involved in a process that
has caused you hard feelings.  And please forgive me that
I cannot say much more, partly because I don't understand
all that is going on, partly because of my vocabulary lacking.

Charlie, I think that we definitely must acknowledge
Michael and Dave Oran and a number of other people in
the BAKE draft.  It was an oversight from my part that I did
not check the acknowledgements section wrt the people that
helped me/us.  My apologies to everybody involved --
I definitely recognize some of you, but please don't get
upset if I/we forget you even from the next revision of the 
BAKE draft.  (And when you inidicate our fault, it would
be nice if you remember that kindness hurts less. :-)

That said, let me express my belief that developing
requirements in isolation from what is technically possible
and what is not is seldom if ever the most productive
way of conducting things.   BAKE is a result of designing
from one starting point.  Michael, your still unpublished design
is another.  Things being as they are, maybe you should go
ahead and submit it to the directories.  SUCV (which I like 
very much) is a result from starting at another starting 
point.  My still unpublished but SUCV resembling design 
is yet another.  The CAM approach by Microsoft Research is 
still yet another.  I have probably forgotten some, and there 
are sure others to appear.

In the case of Mobile IPv6 security, I think that we still
do not know what is technically possible and what is not.  
That is, I am aware of quite little scientific work 
that covers cryptographic protocols that are meant 
to build relative security out of "nothing".  That
is, according to a commonly accepted principle, you cannot
build secure security associations unless you have already
some existing security relationship.  However, what you
can do and what you cannot, if you don't have an existing
relationship, is (to my knowledge) largely unknown.

That is, independent of whether we proceed to a Proposed 
Standard within a very quick timeframe or not, I do expect 
the scientific crypto protocols community to take apart our 
standards proposal and to rip it into pieces.  In fact, I 
think it would be best to proceed into a PS as soon as 
possible, since that would give us some publicity, leading 
to increased interest in "beating us" by the crypto protocol 
analysis people.  And that, in turn, is the only way we can 
increase our knowledge and eventually get a solution whose 
limitations we do understand properly.

Yet in other words:  my only motivation in getting the BAKE
draft out soon was to foster analysis and discussion so
that we would, in the end, get the best possible protocol
that we can get, given our current level of understanding.
The fact that you, Michael, and maybe some other people feel
betrayed (or whatever) is most unfortunate, and I cannot
but express my apologies.

Yours sincerely,

--Pekka

> rather disingenuous. It needn't have been this

...snip... (the rest cut away)

---

From: Fred Baker <[email-masked]>
Date: Sat, 14 Apr 2001 01:41:36 -0700

At 09:13 AM 4/14/2001 +0300, Pekka Nikander wrote:
>That is, according to a commonly accepted principle, you cannot build 
>secure security associations unless you have already some existing 
>security relationship.

You actually can, but they are of limited value. IKE generates a security 
association ex nihilo using a diffie-helman algorithm, which allows you to 
keep private information private and enables you to be sure you are still 
talking with the same person. The problem you are referring to is that you 
don't authoritatively know who that person *is* apart from a security 
association demonstrably set up with the person you intend. You are 
depending on a dynamic association (and therefore key) to authenticate the 
Home Agent or the Mobile Node and determine whether either is authorized to 
instruct you to change your binding association. But a dynamic association 
only tells you that you are talking with the same process you spoke with 
before, not that the process is indeed the authorized agent. For all you 
know, it is a law enforcement agency wishing to inspect your 
communications, or the bad guys who want to use your communications to your 
harm.

>That is, independent of whether we proceed to a Proposed Standard within a 
>very quick timeframe or not

IMHO, you can go to PS with optimized routing (which I think is a truly 
cool feature) if and only if you can solve the authentication/authorization 
problem, because you don't want people hijacking connections, and IPSEC 
unfortunately forces you into assuming some form of global PKI. The 
simplest thing for the working group will be to cull that out separately 
and take the dogleg routing part to PS. Optimized Routing can then be done 
with a little less pressure. As I understand it, Optimized Routing is 
something the Correspondent Node is required to understand, but not 
required to use. This would be consistent with that.

A simple suggestion *might* be to have the mobile node send its 
correspondent a certificate containing the appropriate public key, so that 
the correspondent can know for certain that it received something properly 
authenticated. Problem there is the exchange that would carry that - it is 
one thing for the mobile node to include an option, but it is quite another 
for it to send a separate exchange using a different protocol and assume 
that the correspondent is using the protocol, and no firewall has decided 
to block it, and no snooper got in and sent a different one first. Who 
authorizes the authority?

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 18 Apr 2001 22:20:06 +0300

Fred Baker wrote:
> association demonstrably set up with the person you intend. 

I known and agree.  Here we have a terminology issue.  With a "secure 
security association" I meant something where you know the "identity" 
of your peer.  (I don't want here to go to the hairy issue of what is 
identity.)  And since you know the "identity" of your peer, you can
probably somehow deduce in which respects you can trust your peer.

> You are 

Sure.  That is the reason why the Home Agent is explicitly involved in BAKE.  
I don't see any major difference, in this respect, between using D-H and 
using the symmetric key procedure that we use in BAKE.  Either way, you 
are vulnerable to certain active attackers.

As a related question, how would you define the "process [that] is indeed
the authorized agent"?  What is the qualification that makes the agent
an authorized one?  Who or what provides that authority?  How do you check
that the agent possesses the authority?

In the case of CAM/SUCV, the major idea is to use host ID part of an
IPv6 address as an implicit security association, binding a public key to
an IPv6 address.  

http://www.tml.hut.fi/~pnr/publications/draft-nikander-ipng-pbk-addresses-00.txt
goes a little bit further, and defines "address ownership" in terms of 
binding a public key to an IPv6 address like CAM/SUCV, checking the reachablity
of the agent through that address, and requesting the agent to provide
a previous hash value in a series of hash values, i.e., a one time password.
Thus, that gives one practical answer to how to check if an agent is authorized.

> problem, ...

> authenticated.

I don't see how this would be any better than, e.g., just running D-H.
Whose signature should the certificate include?  How does the CN know
that the issuer of the certificate is authorized to provide statements
about what home addresses the MN may use and what not?  Or, as you say,

> ... Who authorizes the authority?

Some people are promoting some sort of a global PKI, and those blinded
by AAA think that everybody would use it.  PKI or AAA will definitely work 
for some, but IMHO scalability and deployment problems will be quite hard.

Both BAKE and CAM/SUCV/... approaches look for solutions at a different
direction.

--Pekka