Subject: Re: [NSIS] Key management

From: Bob Braden <[email-masked]>
Date: Fri, 8 Nov 2002 17:08:54 GMT

*>  > 
  *>  > It turned out that IPsec as currently defined was not directly
  *>  > applicable to the hop/hop case.  It seemed quite possible to define a
  *>  > third form of IPsec for this purpose, but the security folks were not
  *>  > particularly interested in helping the QoS folks with their problem.
  *>  > As a result, the RSVP WG was forced to roll their own (RFC 2747).
  *>  > Maybe that decision can/should be revisited in NSIS.
  *> 
  *> FYI, Steve Bellovin just published a draft
  *> *-useipsec-00.txt which is probably relevant to
  *> this. Do you happen to recall the reasons why
  *> there was pushback? I suspect I know, but it
  *> would be good to hear it.
  *> 
  *> 	 Mike
  *> 

Mike,

I turned to Bob Lindell, who does not suffer from my senior moments.
Here is his summary:

	This is just off the top of my head.  I'll think about it some more.

	1) IPSEC bases security associations on the IP dst address.  RSVP had
	security associations with the next RSVP capable router along the path.

	2) IPSEC did not adequately support multicast at the time (i.e. a
	security association based on a logical (group) destination address,
	rather than a physical unicast destination address).

	Bob

This sounds right to me, too.

Bob Braden

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Melinda Shore <[email-masked]>
Date: Fri, 08 Nov 2002 12:24:21 -0500

> 	security associations with the next RSVP capable router along the path.

That still leaves the possibility of establishing IPSec SAs
between individual routers rather than end-to-end.  We've
been talking about doing hop-by-hop security anyway.  

Still, among the things that we need to consider is that for
the NSIS application (or whatever we're calling it today)
that needs security services across hops (end-to-end or
end-to-middle) this effectively means that the transport
layer isn't really secure since some devices that are along
the path but not participating may be decrypting and
re-encrypting (or verifying and re-authenticating) messages
in the transport layer, and they can peer into packet
contents, or change them.

> 	rather than a physical unicast destination address).

This is still more-or-less true; the msec working group is
hard at work but I don't think they've gotten any documents
into WG last call yet.

Melinda

---

From: Michael Thomas <[email-masked]>
Date: Fri, 8 Nov 2002 21:58:33 -0800 (PST)

> 	rather than a physical unicast destination address).

   At the risk of putting my foot in my mouth (again!),
   this doesn't make very much sense for hop-by-hop
   kinds of security. As I think Melinda pointed
   out, IPsec is obviously a non-starter for
   anything which requires getting something to
   and from the two RSVP hosts, but I don't see
   how these comments are applicable. for
   hop-by-hop.  For (1), I'd think that it would
   just be a transport mode SA to the next hop,
   and for (2), although the DST address is a
   multicast address RFC 2401 supports that for
   selectors, and I don't think this implies that
   you need group keying between the next hops...

   So, I'm still lost.

	   Mike

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 11 Nov 2002 09:18:32 +0100

hi mike!

i guess the problem pointed out here is that
- if you want to secure rsvp traffic in a hop-by-hop fashion then you need
to have some traffic selector which knows which ipsec sa to apply. if you
however have more than one possible path then you might experience problems
when selecting the security association since the ip packet is addressed to
the destination and not to the next host (at least for the rsvp path
message).

ciao
hannes

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Michael Thomas
> Sent: Saturday, November 09, 2002 6:59 AM
> To: Bob Braden
> Cc: [email-masked]; [email-masked]
> Subject: Re: [NSIS] Key management
>
>
> Bob Braden writes:
>  >   *>  >

---

From: Michael Thomas <[email-masked]>
Date: Tue, 12 Nov 2002 09:56:48 -0800 (PST)

> the destination and not to the next host (at least for the rsvp path

Hannes,

A point I brought up in the MIP WG is that there
are two general ways one can envision using IPsec:

1) Use IPsec as a filtering mechanism such that unauthorized
   traffic is not able to make it into the unprotected
   part of the network/kernel/apps. I believe that is the
   model you are suggesting here.

2) You use IPsec as a means of blocking unauthenticated
   traffic (ie, all packets you receive will be bound to
   strong credentials) and you push the authorization
   check up to the app.

The advantage of the second is that you can
divorce yourself from IP address based filtering
and all of the unpleasant side effects that brings
(eg, the slippery slope of IPaddr == identity).

		Mike

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 13 Nov 2002 10:10:26 +0100

hi melinda

in one of your previous mails you raised the question of where to apply
security protection:

i try to give an example based on rsvp:

(my) assumptions:
- ip is the transport
- everything else is the application

example:

- the rsvp integrity object does not provide protection of the transport .
- if you use ipsec (if you can) then you would also protect the transport
mechanism of rsvp.

- rsvp also allows a second integrity object to be used: the integrity
object within the policy object. depending on the configuration of your
nodes a rsvp aware node might also be a policy aware node. if so then you
protect your rsvp message with the integrity object and additionally the
policy object with another integrity object. a kerberos ticket in the policy
object might allow key management to support keys maybe (my interpretation)
for both objects.
assuming the a different configuration you would allow end-to-middle
security:

host a <-------> rsvp aware node (not policy aware) <-------> rsvp and
policy aware node

 |-----peer-to-peer--------------|		 |-----peer-to-peer--------------|
 |---------------------------------end-to-middle---------------------------|

if security protection terminates at different places then you need to think
about the key managment for both.

> But again, I think this is a problem for the application,
> not the transport.  The transport needs to protect itself
> against forgeries, theft of service, etc., and I don't think
> it's necessarily the job of the NSIS transport to protect
> the NSIS application.

ciao
hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 13 Nov 2002 10:13:37 +0100

hi mike

> (eg, the slippery slope of IPaddr == identity).

this is a good categorization. both models related to each other. my
intention at this point was only to raise signaling protocol protection and
not data traffic. there is clearly some relationship to nsis. in case of (1)
i think you speak about secure network access. ip spoofing threats can be
prevented by using this model.

your second model is certainly a resonable approach. you do not really need
ip addresses as identities since you execute an authentication and key
exchange protocol before you can use ipsec sas. these identities can then
also be used for authorization and accounting.

i hope i got your point.

ciao
hannes