Subject: Security stuff was RE: Comments Re: [seamoby] ct problem statemen t

From: Phillip Neumiller <[email-masked]>
Date: Tue, 5 Jun 2001 08:34:52 -0400

Hello,

> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]]
> Sent: Tuesday, June 05, 2001 8:06 AM
> To: Louis-Nicolas Hamer
> Cc: 'seamoby'
> Subject: Re: Comments Re: [seamoby] ct problem statement
> 
> 
> > But can we all agree that we don't need to re-invent a specific 
> > security solution for CT? Basically, you guys are stating that 
> > the IETF security area, with all it's experts did not do a good 
> > job designing current security solutions and that we need to
> > re-invent the wheel once again.

Why not?  That's what mobile IP has done... :-)
> 
> I don't see anybody saying that.  There's actually a rich
> set of security mechanisms published by the IETF - the task
> is to identify the requirements and then choose the 
> appropriate tool to solve the problem.  Context transfer
> may have requirements, like performance, that would be
> difficult to meet if you were to wave hands and use IKE to 
> key up and establish SAs.  

Why?  Why can't this be done once and then kept around for
some deemed useful period of time?

>So while this isn't the time to
> choose mechanisms it certainly is the time to be pretty
> clear about what the requirements will be.  "Use existing
> IETF protocols" will be one requirement, but there must be
> others. 

Yes, like:

Is encryption (a block cipher presumably) needed?
Is authentication needed?
Is authorization needed?
Will it work over/through common firewall systems and VPNs?
Will it work over/through NATs?
Can it work with IPSEC?
How does it work with PKI?
Does this conversation belong on the CT list?

Can somebody please answer these questions?

Thanks,

pdn

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 05 Jun 2001 07:41:34 -0700

> Why not?  That's what mobile IP has done... :-)

This needs additional information to be understood correctly.
There were two problems.

1. The Mobile IP group was instructed that use of AH was problematic
   because the SPD selection mechanism did not mesh well with the
   requirement to authenticate data in a destination option (vs., say,
   authenticating the payload).

2. Further, it was determined that providing the mechanism (Binding
   Update) for enabling direct routes between mobile node and
   correspondent node was inadequate unless there was also a
   reasonable mechanism for creating the security association for
   carrying out the needed authorization check.

The above quoted sentence _might_ be misinterpreted to mean that
people in the mobile-ip working group did not want to use IPsec
mechanisms.  That would be wrong.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 05 Jun 2001 08:05:55 -0700

Hello Phil,

> some deemed useful period of time?

Suppose we assume that two neighboring access routers already
have a security association, and that a mobile node has a
security association with one of them.  When the mobile node
moves to the other one, it seems logical to me to use the
inter-access-router security association to establish a
security association between the mobile node and the new
access router.  As far as I know, IKE can't do this.

Maybe IKE should be used to set up the security associations
between the access routers.

>> IETF protocols" will be one requirement, but there must be

How about, "Use existing IETF protocols wherever appropriate
according to performance and feature requirements"?
I reckon this is what you meant, anyway.

> Is encryption (a block cipher presumably) needed?

This probably depends on characteristics of the access network.

> Is authentication needed?

Probably not.

> Is authorization needed?

I think this is the central requirement.

> Will it work over/through common firewall systems and VPNs?

I think the basic mechanism should be designed to work with the
best performance possible, and then extended to work in other
scenarios.  Where is our authorized firewall automatic configuration
protocol anyway when we need it?

> Will it work over/through NATs?

Bzzzt.

> Can it work with IPSEC?

What does this mean?

> How does it work with PKI?

This question cannot be answered until the basic
message flows are identified.  By "basic", I mean
the stuff that makes the context get transferred.
After that is known, then probably the PKI details
could be worked out.  My guess is that the latter
might even be a separate protocol, but who knows?

> Does this conversation belong on the CT list?

.... why not here??? ....

> Can somebody please answer these questions?

Please be more specific.  Select from among the
following:

1. Authoritative answers
2. Thoughtful answers
3. Knee-jerk responses
4. Seat-of-the-pants wisdom
5. Educated guesses
6. Wild guesses
7. Incoherent babble

Or were you merely inquiring about capability,
instead of placing an imperative?

Regards,
Charlie P.

---

From: Mark Smith <[email-masked]>
Date: Tue, 05 Jun 2001 08:43:51 -0700

> This probably depends on characteristics of the access network.

I'd like to suggest this depends more on the characteristics of the 
context being transfered.  I don't care too much whether someone sees 
the current state of my header compression.  I care a WHOLE LOT about 
someone seeing my authentication information.

Of course it also depends on the characteristics of the AN, but I'd 
think more on the data.

> I think this is the central requirement.

What good is authorization without authentication?

oldAR: "Yeah, this guy is authorized."
newAR: "Really?  Who is he?"
oldAR: "Uh, he's, well, authorized."
newAR: "I don't buy it."

Maybe I'm just paranoid, but I'd like to suggest that authentication and 
authorization go hand-in-hand.

The only possible exception to this is when the two ARs trust each other 
(within the same administrative domain.)  In this case, oldAR could 
simply tell newAR "Yep, this guy's been authenticated."   The advantage 
to this is that the MN's authentication information is no longer being 
sent in CT.  (It would (hopefully) also make the context smaller.)  But 
unless they trust each other, I still think authentication is important.

-Mark

---

From: "Melinda Shore" <[email-masked]>
Date: Tue, 5 Jun 2001 12:39:32 -0400

> someone seeing my authentication information.

I think this is generally (okay, absolutely) true, with
the caveat below ...

> authorization go hand-in-hand.

At the risk of inciting giggles, I should point out that
some networks are considered trusted and that pretty much
any traffic on them would be considered legitimate.  You
could argue that this does constitute weak authentication.
Authentication and authorization are orthogonal and should
be treated as such.  I don't think that it's always 
necessarily the case that authorization needs to depend on
cryptographic authentication.  

Melinda

---

From: Mark Smith <[email-masked]>
Date: Tue, 05 Jun 2001 09:59:21 -0700

I guess my only response to this is that a trusted network has implicit 
authentication at setup time, so your example fits by description..  :)

So, in short, we agree, I'd just like to make sure the authentication 
requirement makes it in there.   Setting up a pre-authenticated, trusted 
network qualifies as authentication.

-Mark

 > > context being transfered.  I don't care too much whether someone
 > > sees the current state of my header compression.  I care a WHOLE LOT
 > > about someone seeing my authentication information.
 >
 > > Maybe I'm just paranoid, but I'd like to suggest that authentication
 > > and authorization go hand-in-hand.
 >
 >
 > At the risk of inciting giggles,

Hehehehehehehehe....   Oh.  Sorry...  :)

 > I should point out that
 > be treated as such.  I don't think that it's always necessarily
 > the case that authorization needs to depend on

---

From: Michael Thomas <[email-masked]>
Date: Tue, 5 Jun 2001 10:16:31 -0700 (PDT)

> Why not?  That's what mobile IP has done... :-)

   As many have pointed out, the need to create an application
   layer security scheme for BU's came as a rude awakening to
   the MIP WG. It certainly wasn't their desire.

 > some deemed useful period of time?

   Right. There is probably a requirement hiding here:

   o the protocol MUST be able to pre-establish associations
     with CT peers to avoid possible keying, transport
     three way handshakes, etc, latency during context transfer.
 > Is encryption (a block cipher presumably) needed?

   Yes.

 > Is authentication needed?

   Yes.

 > Is authorization needed?

   Yes. Both from the CT peer, and the whatever triggered
   the CT peer (eg, MN).

 > Will it work over/through common firewall systems and VPNs?

   Define "firewall". If you don't mean "NAT" then it should.

 > Will it work over/through NATs?

   I think this should be a *non* requirement. It's very
   likely that CT payloads would need to fixed up by the
   NAT which would destroy the ability to detect e2e
   message integrity, replays, etc.

 > Can it work with IPSEC?

   Define "work". If you mean tunnel mode, I think it's
   the same as your VPN question. Otherwise it sounds like
   solution space.

 > How does it work with PKI?

   Keying is orthogonal.

 > Does this conversation belong on the CT list?

   Probably.

		Mike