Subject: [NSIS] an nsis security assumption? (was: RE: Comments on framework draf t)

From: "Hancock, Robert" <[email-masked]>
Date: Sun, 20 Oct 2002 00:18:11 +0100

Hi all,

a quick comment on melinda's Q7:

[snip]
[Melinda]
>   *> 7) Rely on internal or external security mechanisms?  (Can
>   *>    we punt on this until we know more about the protocol?)
>   *> 
> 
[Bob]
> The general security issues are pretty much independent
> of the protocol details, I would claim.  They are also hard,
> if you go beyond the hop/hop security of RSVP1.
> 
> You could have broadened your question from "security" to "policy".
> 
> Bob Braden

[reh] for what it's worth [?] the current working assumption in the framework document is that security at the basic NSIS [cstp-like] layer is purely local ("hop by hop") and is limited to various aspects of message protection and the authentication needed to support it. 

any policy/authorisation issues are assumed to be so signalling application specific that they might as well be handled in the layer above, where non-local-scope aspects might also be considered. 

my understanding is that this is pretty well the same as the functionality division between 2747 and 2750 in RSVP1. i guess we're assuming that nothing since then has suggested the split should be changed (in particular, that there is no point in trying to define a more powerful 'security' capability within the base NSIS protocol).

robert h.
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 
> 
========================================================================================
Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply.

---

From: Bob Braden <[email-masked]>
Date: Sat, 19 Oct 2002 17:05:38 -0700 (PDT)

*> > 
  *> [Melinda]
  *> >   *> 7) Rely on internal or external security mechanisms?  (Can
  *> >   *>    we punt on this until we know more about the protocol?)
  *> >   *> 
  *> > 
  *> [Bob]
  *> > The general security issues are pretty much independent
  *> > of the protocol details, I would claim.  They are also hard,
  *> > if you go beyond the hop/hop security of RSVP1.
  *> > 
  *> > You could have broadened your question from "security" to "policy".
  *> > 
  *> > Bob Braden
  *> 
  *> [reh] for what it's worth [?] the current working assumption in the framework document is that security at the basic NSIS [cstp-like] layer is purely local ("hop by hop") and is limited to various aspects of message protection and the authentication needed to support it. 
  *> 
  *> any policy/authorisation issues are assumed to be so signalling application specific that they might as well be handled in the layer above, where non-local-scope aspects might also be considered. 
  *> 
  *> my understanding is that this is pretty well the same as the functionality division between 2747 and 2750 in RSVP1. i guess we're assuming that nothing since then has suggested the split should be changed (in particular, that there is no point in trying to define a more powerful 'security' capability within the base NSIS protocol).
  *> 

Robert,

Yes, all you say is true, and this division is the best I know how to
do about signaling security.  Yet security is still a hard problem, and
maybe we need some other approach; I am not sure.

Bob

  *> robert h.
  *> > _______________________________________________
  *> > nsis mailing list
  *> > [email-masked]
  *> > https://www1.ietf.org/mailman/listinfo/nsis
  *> > 
  *> > 
  *> ========================================================================================
  *> Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply.
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis