Subject: Re: [NSIS] Key management

From: Bob Braden <[email-masked]>
Date: Fri, 8 Nov 2002 18:27:16 GMT

*> 
  *> > No, that doesn't help.  A Path message still has the session address as
  *> > its IP destination address, not the next hop address, and that is what
  *> > IPsec looks at.
  *> 
  *> Right, but I thought the addressing model is still open.  I
  *> prefer end-to-end addressing myself, but in the new IETF
  *> spirit of including security in protocol gestalt perhaps
  *> this problem might have some bearing on overall protocol design.

OK, that's fair. 

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

---

From: Bob Braden <[email-masked]>
Date: Fri, 8 Nov 2002 18:50:33 GMT

*> 
  *>    This is not a small point. One of things my draft

Agreed.  In the end, this is why RSVP today is used in enterprise
networking but not in the general Internet.  You cannot in general have
QoS without some sort of policy pushback, either administrative (in a
corporation) or financial (in the Internet).

  *>    went into at some length is the fact that I couldn't
  *>    figure out what sort of accounting model for lack of
  *>    a better phrase was intended for policy objects. When
  *>    the receiver sends RESV's and there are potentially
  *>    many PEP's in the path, who's responsible for supplying
  *>    those policy objects? I couldn't find any guidance in
  *>    RFC 2750. Are they loaded up front by the receiver,
  *>    or can they be inserted hopwise (sort of a relay model)?

Policy objects that contain user certificates might be supplied by
the entities that initiate the signaling, e.g., the end systems.
Or they might be supplied at administrative boundaries, e.g.,
a corporation might supply the policy object when a reservation
crosses the border into the ISP.  These alternatives were discussed
in papers and documents a few years ago.  Shai Herzog, who played
a key role in starting the COPS work, wrote and talked about these
issues, during his thesis work under Deborah Estrin.

However, to make this real requires a set of multilateral agreements on
economic and policy models, and there has not been the will to make
that happen.  There is also an issue of a forum to do this
administrative design; the IETF is not really suitable.  It would
be easier if the Internet, like the phone system, had started as a
commercial monopoly and later broke up.

  *>    The one thing I'm pretty certain of is that cross realm
  *>    RSVP with policy will probably not work.

I don't see a technical protocol problem, only a problem of agreeing on
policies and procedures.

  *> 
  *>    Also: it's always struck me as odd that it's
  *>    effectively a "receiver pays" kind of model. I understand
  *>    *why* it's that way (RSVP is receiver oriented), but it
  *>    still strike me as odd. Maybe I'm bellheaded and haven't

The receiver-pays model was suited to support video broadcasting in the
Internet.  It also has scalability advantages, for large multicast
groups.   However, I believe that RSVP was actually agnostic about
this; the payment could be based on Policy objects carried downstream
in Path mesasges, giving a sender-pays model.

  *>    be properly enlightened, but it seems worth considering
  *>    at least both kinds of "pay" models.
  *> 
  *>    Please go easy on me for using hot button words
  *>    like "pay" and "accounting" etc... I mean them
  *>    metaphorically...
  *> 
  *> 		Mike
  *> 

No, au contraire, pay and accounting are inseparable from QoS.

Bob Braden

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 11 Nov 2002 00:55:20 -0000

Hi Melinda,

My point (poorly expressed maybe) is that the framework is currently still something that could be split up pretty well any way you want, so we can't start with an analysis of the threats against its components. Some criteria are needed to motivate the framework decomposition in the first place: what part should security considerations play? And how should those considerations be expressed?

I'd love it if we could stucture the framework any way we liked and then demand it to be securable. But that demand is much more likely to be successful if we make a nod to feasibility at the outset.

Cheers,

Robert H.

PS I believe that the range of security environments we're trying to address is already captured in the requirements, and it is "the lot". Given that we're being discouraged from thinking about fundamentally different basic protocols for different environments, we should be looking for an overall assessment of the impact on the framework decomposition.

> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]]
> Sent: 10 November 2002 22:13
> To: Hancock, Robert
> Cc: [email-masked]
> Subject: Re: [NSIS] Key management 
> 
> 
> > 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.
>

---

From: Bob Braden <[email-masked]>
Date: Sun, 10 Nov 2002 19:34:27 -0800 (PST)

*> 
  *>    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
  *> 

And I am at a loss for how to explain it more clearly than
Bob Lindell already did.

Bob Braden