Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages

From: Bob Braden <[email-masked]>
Date: Mon, 4 Nov 2002 17:25:42 GMT

*> 
  *> hi marcus
  *> 
  *> i would agree to a stronger requirement for confidentiality protection of
  *> signaling messages.
  *> 
  *> how about:
  *> 
  *> "NSIS signaling messages MUST be confidentiality protected between NSIS
  *> nodes."
  *> 
  *> ciao
  *> hannes
  *> 
  *> 

Whoa!!! Strong encryption has a cost, and it is by no means clear that
very many users of your protocol are going to want or need to pay that
cost in order to protect confidentiality of signaling.  Your version
shifts from a requirement for support, which was reasonable, to
a requirement for implementation and use, which is out of bounds.

Bob Braden

  *> > -----Original Message-----
  *> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
  *> > Marcus Brunner
  *> > Sent: Friday, November 01, 2002 11:35 PM
  *> > To: [email-masked]
  *> > Subject: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling
  *> > messages
  *> >
  *> >
  *> >
  *> > Req-Draft: Open Issue 4: Confidentiality of signaling messages
  *> > ---------------------------------------------------
  *> >
  *> > Proposal to change Req 5.7.8
  *> > "The NSIS protocol MUST allow encryption of NSIS messages between NSIS
  *> > nodes."
  *> >
  *> > Currently it says
  *> >
  *> > 5.7.8 Confidentiality of signaling messages
  *> >
  *> > Based on the signaling information exchanged between nodes
  *> > participating in
  *> > the signaling protocol an adversary may learn both the identities and the
  *> > content of the signaling messages. To prevent this from happening,
  *> > confidentiality of the signaling message in a hop-by-hop manner MAY be
  *> > provided. Note that the protection can be provided on a hop-by-hop basis
  *> > for most message payloads since it is required that entities
  *> > which actively
  *> > participating in the signaling protocol must be able to read and
  *> > eventually
  *> > modify the content of the signaling messages."
  *> >
  *> > --------------------------------------
  *> > Dr. Marcus Brunner
  *> > Network Laboratories
  *> > NEC Europe Ltd.
  *> >
  *> > E-Mail: [email-masked]
  *> > WWW:    http://www.ccrle.nec.de/
  *> > Phone: +49 (0) 6221 905 11 29
  *> > personal home page: http://www.brubers.org/marcus
  *> >
  *> >
  *> > _______________________________________________
  *> > nsis mailing list
  *> > [email-masked]
  *> > https://www1.ietf.org/mailman/listinfo/nsis
  *> 
  *> _______________________________________________
  *> nsis mailing list
  *> [email-masked]
  *> https://www1.ietf.org/mailman/listinfo/nsis
  *> 

----- End Included Message -----

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

---

From: Melinda Shore <[email-masked]>
Date: Mon, 04 Nov 2002 12:31:57 -0500

> a requirement for implementation and use, which is out of bounds.

It's also very common for protocols to require encryption
without saying much, if anything, about keying, and keying
is where things go to heck in a handbasket very, very
quickly.  If we're going to require that NSIS entities in
two different domains are going to be able to establish a
security association between them, we need to think long and
hard about where the keys are going to come from.

Melinda

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 5 Nov 2002 09:35:18 +0100

hi melinda!

i agree with you that the key management should be addressed. the question
where the keys come from is independent from integrity or confidentiality
protection. if signaling messages are not protected then there are obviously
some threats. protecting inter-domain signaling messages is also important.
i wouldn't like to make QoS reservations (or installing packet filters at my
firewall) only because of unauthenticated and unprotected signaling message.
the message could basically come from any place in the world.

ciao
hannes

---

From: Melinda Shore <[email-masked]>
Date: Wed, 06 Nov 2002 10:21:47 -0500

> i agree with you that the key management should be
> addressed. the question where the keys come from is
> independent from integrity or confidentiality protection.

Unfortunately it's not completely independent.  For example
the reasonable choices for IPSec are IKE, pre-shared keys
(which is probably a bad choice for us), or KINK, while for
TLS it's PKI.  For us the choice of a keying mechanism is
going to come down to some combination of 1) what security
protocols we use, 2) what our understanding of the
relationships among the entities is going to be (i.e. if
there's just a few PSKs might be fine, if they're all in the
same domain KINK might be fine, etc.), and so on.

I think that at this point the most helpful thing would be
to identify the elements that we'd use as the basis for a
later decision about keying.

Melinda

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 7 Nov 2002 14:43:10 +0100

hi melinda!

please see my comments inline:

> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]]
> Sent: Wednesday, November 06, 2002 4:22 PM
> To: [email-masked]
> Cc: Bob Braden; [email-masked]
> Subject: Re: [NSIS] Key management
>
>

i see your arguments. it is true that in real world protocols you are with
some choices somehow limited in the number of ciphersuites, integrity
algorithms. (an example: if you want to use a special encryption algorithm -
for example camilla - then you might limit your scope of protocols. but i am
not quite sure that one would like to place such contraints.)

the issue i wanted to raise is that key management still has to be discussed
differently to the type of protection later offered.

some examples:
authentication and key exchange protocols for ipsec are: ike, soi (in the
near future) and kink (and others).
they all offer ipsec sas which support algorithms for confidentiality
protection and algorithms for integrity protection

tls has its key management built-in. there are however extensions such that
srp, kerberos or public key based techniques can be used.
still the algorithms tls offers algorithms for confidentiality protection
and for integrity protection.

if you create your own authentication and key exchange protocol (and a
seperate protocol for sa parameter negotiation) you might want to limit it
only to confidentiality protection. but you might want to have a particular
reason for that.

> later decision about keying.
i think that the basis for a authentication and key exchange protocol
selection should be the trust relationships and the architectural
assumptions.
you mention that ike with pre-shared secrets might not be the right choice.
this would be such an architectural assumption. these type of trust
relationships and assumptions need a careful investigation (e.g. based on
scenarios).

ciao
hannes

---

From: Melinda Shore <[email-masked]>
Date: Thu, 07 Nov 2002 09:19:19 -0500

> differently to the type of protection later offered.

Absolutely, and this is where many other IETF documents
leave something (ahem) to be desired.  But still, you can't
talk about key management completely independently of the
security protocol.  As I said, I think for the purposes of
requirements and framework it is probably best to identify
what the context and broad criteria for the decision will
be.  For example, issues like the ability to operate across
domains come into play.  This is where your threat analysis
document becomes very useful.

Melinda

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 7 Nov 2002 16:00:47 +0100

hi melinda!

i agree with you that key managment is a very important issue for nsis. as
you mentioned there are some areas which deserve particular attention when
it comes to deployment issues. especially the area of inter-domain and the
first-peer communication is difficult. for intra-domain there is a large
degree of freedom for a network operator to chose whatever mechanism and key
management infrastructure is best suitable.

considering the large number of scenarios and applications where nsis
should/could be used it is difficult to specify exact requirements.
proposing only a single mechanism might be good in some environments but
might not fit for others. hence my personal opinion is to use some ietf
standardised mechanisms which give some degree of freedom. ipsec is an
example of such a protocol. it only worries about protection of data
traffic. it gives a network architect (or network operator) the possiblity
to either choose between ike (and the different authentication mechanisms),
son-of-ike and kink (kerberos based). packetcable peoplemight for example
want to use ipsec (and kink as key management protocol) to protect nsis
signaling messages whereas telecom people might not want to use kerberos to
authenticate their users.

ciao
hannes

---

From: Melinda Shore <[email-masked]>
Date: Thu, 07 Nov 2002 10:24:09 -0500

> standardised mechanisms which give some degree of freedom. 

While I agree with both points I don't think that one
follows from the other.  Again, I think that we need to lay
out the context and trade-offs.  We know from experience
that "just use IPSec" isn't going to lead to interoperable,
secure, implementable specifications.  The decisions that
are ultimately made about key management will hinge on 1)
the specific keying problems we're trying to solve, and 2)
the security protocol(s) this is/are selected to protect
both the transport layer and the application.  

BTW, we should think about the performance implications of
doing a key exchange in the transport layer + a key exchange
in the application layer.  It may be desirable (more
efficient) to use a secure channel established in the
transport layer to do keying for the application, and that
has implications for how the transport is secured (i.e. it
relies on confidentiality protection).

Melinda

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 7 Nov 2002 17:13:56 +0100

hi melinda!

please find my comments inline:

> secure, implementable specifications.
i agree with you that it is not just that simple. i, however, favor an
approach where standard mechanisms are used as far as possible. this saves
both work and mistakes.

>  The decisions that
> the specific keying problems we're trying to solve,
what do you mean by keying problem. do you refer to symmetric vs. asymmetric
cryptography?

> and 2)
true. i can agree to that.

> in the application layer.

we should always keep performance in mind. hence i argue that it might not
the most performance efficient approach to have security at both layers if
they terminate at the same endpoints.

we should, however, have no illusion about the fact that an authentication
and key exchange is associated with some cost. keys and security
associations do not appear by magic.

related to performance i would also like to point a typical approach in this
area (and other area as well): to establishment a security association which
can then be used to protect signaling messages (or parts of it)
the benefit of this approach is that an authentication and key establishment
is done once. protection of a possibly large number of signaling message can
then done by very efficient means.

>  It may be desirable (more
what do you mean by keying for the application based on the secure channel?

ciao
hannes

---

From: Melinda Shore <[email-masked]>
Date: Thu, 07 Nov 2002 11:32:48 -0500

> approach where standard mechanisms are used as far as possible. this saves

There's no disagreement here, other than that I think that
the options may be more constrained than you're suggesting.

> what do you mean by keying problem. do you refer to
> symmetric vs. asymmetric cryptography?

No, higher level than that (transforms are mechanism, and we
don't specify mechanism quite yet).  The problems may be
things like establishing secure channels between entities
that don't have pre-existing relationships, or keying across
a potentially hostile network.

> they terminate at the same endpoints.

I think we're arguing the same thing, but it still comes
back to decisions that are made in the framework.  For
example, if the transport layer is keying hop-by-hop but you
want NSIS applications (say, NAT communication) to be able
to do bidirectional authentication, you face the problem of
getting keys between the NAT, which may be more than one hop
away from the NSIS initiator, and the NSIS initiator
itself.  

> associations do not appear by magic.

Of course, but you still need to do the right thing.
Pre-shared keys makes keying cheap but it has other
attributes that might make it unattractive for some
scenarios.  What are the tradeoffs?

> what do you mean by keying for the application based on the secure channel?

What you described above - establishing a secure channel at
the transport layer and letting the application use it to
exchange keys.  But as I've said there may be application
considerations that come into play, like the problem of
authenticating devices multiple hops away.

Melinda