Subject: RE: [NSIS] Key management

From: "Hancock, Robert" <[email-masked]>
Date: Sun, 10 Nov 2002 21:52:53 -0000

hi all,

I think there's a more basic question here than simply 'can we use IPsec for NSIS?'.

If we look at the whole army of available security mechanisms, there are two broad categories:
a) ones which do authentication (and key management) by a bidirectional exchange between a stable pair of endpoints (e.g. a TLS session, IPsec SA, EAP exchange...)
b) ones which rely on a PKI or pre-configured shared keys (or a third party key server) and allow single-shot secure message sending (s/mime and so on), even without knowing the precise identity of the peer you are talking to. These methods are generally either less efficient or less scalable (or both).

On the other hand, the signalling we are talking about in NSIS unavoidably has a component which can only be handled under (b) [path-like messages, especially after a route change and/or sent over an nsis-unaware cloud], but IMHO (b) isn't appropriate to handling all of nsis' security needs. Using techniques from category (a) probably imply building non-trivial association between peers.

I'm well aware that this summary is outrageously abbreviated, but I find it easier to start simple: how much should we tune the structure of NSIS to make securing it easy?

cheers,

robert h.

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: 09 November 2002 05:59
> To: Bob Braden
> Cc: [email-masked]; [email-masked]
> Subject: Re: [NSIS] Key management
> 
> 
> Bob Braden writes:
>  >   *>  > 
>  >   *>  > 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).
> 
>    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
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Melinda Shore <[email-masked]>
Date: Sun, 10 Nov 2002 17:12:48 -0500

> I'm well aware that this summary is outrageously
> abbreviated, but I find it easier to start simple: how
> much should we tune the structure of NSIS to make securing
> it easy?

I have to admit that I don't understand this message very
well.  Starting from mechanism is generally a bad idea (and
I have some quibbles about your dichotomy, but that's
another matter).  The place to start is with understanding
the threats (attacks) against the framework, which is where
Hannes' work becomes highly useful.  What sort of keying
infrastructure you use is going to depend on the problem
you're trying to solve - do you have a handful of nodes
participating or thousands?  Are they in the same
administrative domain or not?  Etc.

Melinda

p.s. As an aside, we have to be careful about specifying
what we mean when we talk about "scalability."  A PKI will
scale in the number of nodes it supports but public key
operations are computationally expensive.  The use of
pre-shared keys can reduce the number of messages required
to authenticate and is less computationally expensive, but
it doesn't scale administratively, etc.
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis