Subject: Re: [NSIS] Key management

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

*> From [email-masked]  Fri Nov  8 09:24:37 2002
  *> To: Bob Braden <[email-masked]>
  *> cc: [email-masked], [email-masked]
  *> From: Melinda Shore <[email-masked]>
  *> Subject: Re: [NSIS] Key management 
  *> Date: Fri, 08 Nov 2002 12:24:21 -0500
  *> X-AntiVirus: scanned by AMaViS 0.2.1
  *> 
  *> > 	1) IPSEC bases security associations on the IP dst address.  RSVP had
  *> > 	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.  
  *> 

Melinda,

(Believe me, the RSVP WG really did NOT want to invent any new
security mechanism, and we tried hard to use IPsec. but...)

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.

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

I don't understand.  Devices along the path are either NSIS-trusted
and have keys for NSIS neighbors, or they aren't.  Maybe you are
pointing out the inherent insecurity of the transitive trust model,
that worries the security folks?  Sorry if I am missing something.

Bob

  *> 
  *> > 	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).
  *> 
  *> 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
  *> 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Melinda Shore <[email-masked]>
Date: Fri, 08 Nov 2002 13:07:43 -0500

> its IP destination address, not the next hop address, and that is what

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.

> that worries the security folks?  Sorry if I am missing something.

Transitivity may work for identity authentication but I'm
less comfortable with it for things like confidentiality.
That is to say, identity (are you are who you say you are?)
is a yes/no question, assuming that you have a high degree
of confidence in the authentication mechanism in every hop
along the path.  

I think that when things like access policy are involved the
question becomes stickier.  Let's say that I've got two NATs
in the path and they belong to two different administrative
domains (they have independent administrative policies).  If
we rely on hop-by-hop security, the first NAT in the path
(with respect to the sender) is going to get a copy of the
second NAT's keying material, assuming that we use some sort
of key exchange rather than either using pre-shared keys or
doing some sort of public-key based key exchange at this
layer, as well, which can be quite costly.  Whether or not
you trust that first NAT with the second NAT's keys is going
to be a matter of policy, and while the question of provable
identity isn't orthogonal to that question it's at least at
a slight tilt.

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.  

Melinda

---

From: Michael Thomas <[email-masked]>
Date: Fri, 8 Nov 2002 10:22:08 -0800 (PST)

> this problem might have some bearing on overall protocol design.

   #include <std.disclaimer.hopelessly.behind>

   This is not a small point. One of things my draft
   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)?
   The one thing I'm pretty certain of is that cross realm
   RSVP with policy will probably not work.

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

---

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

hi mike!

>    RSVP with policy will probably not work.

initially i was also confused about the usage of policy objects in rsvp and
their relationship to accouting. then i found the following document written
by shai herzog: Building Blocks for Accounting and Access Control in RSVP.
the document was also published as an ietf draft a long time ago
(draft-ietf-rsvp-lpm-arch-00.txt). it gives a good overview how these
objects are used. you might want to take a look at it.

i have to agree with bob that the receiver-initiated signaling approach of
rsvp does not necessarily mean that the receiver has to pay.

ciao
hannes

---

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

hi bob

it was often mentioned that the chain of trust (=transitive trust) model
breaks if one of the nodes along the path is compromised. this is true, but
it is hard to find an approach which is much better considering the way how
a signaling protocol work. some published qos security paper addressed this
issue and applied additional security protection on top of the hop-by-hop
security protection. unfortunately this might not solve all problem and
additionally introduces performance problems.

the functionality of a signaling protocol might make it difficult to decide
whether something is an attack or a failure behavior.

a short comment to end-to-end security:
i do not believe that end-to-end security for qos signaling is really an
option for the following reasons:
- a signaling protocol requires intermediate nodes to inspect, modify and
add message parts. hence only some non-mutuable fields can be protected or
incremental protection. the meaning for an end host might be questionable.
- protocol operations like proxying might require some sort of delegation.
- applying end-to-end security between two arbitrary hosts might be a
deployment problem in general

if there are some objects which are only relevant for end hosts (and not for
intermediate nodes at all) then why is it necessary to ship them with a
signaling protocol.

ciao
hannes

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Bob
> Braden
> Sent: Friday, November 08, 2002 6:49 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [NSIS] Key management
>
>
>

---

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

hi melinda!

why do you think that a nat might be able to get the key material of a
different nat?

sender <--------> Nat1 <------------> Nat2 <-----------> receiver

if peer-to-peer security is used then  a signaling message is secured
between sender and nat1 and again secured between the two nats. if you only
use peer-to-peer security then the sender trusts the nodes along the path to
work in the expected way. a corrupted nat might for example create a wrong
nat binding and you would not be able to detect it. but this results from
the way how signaling protocols work.

ciao
hannes

---

From: Melinda Shore <[email-masked]>
Date: Wed, 13 Nov 2002 08:01:11 -0500

> sender <--------> Nat1 <------------> Nat2 <-----------> receiver

We were talking specifically about transitive trust and
hop-by-hop (at the NSIS transport layer) security
mechanisms.  If we rely on the latter for securing key
exchanges between the sender and Nat2 in order to support
end-to-middle security at the application layer between the
sender and Nat2, the keying material in flight will
decrypted and re-encrypted at Nat1.  That's not really very
secure, and in environments where Nat1 and Nat2 are under
different administrative control it's quite risky.

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Wed, 13 Nov 2002 08:33:50 -0500

> incremental protection. the meaning for an end host might be questionable.

There is at least one case under consideration (NAT) where a
box in the middle of a network *must* authenticate itself to
the signaling initiator (there may be some issues with
security gateway discovery, as well - I need to think about
that some more).  That has to be protected end-to-end
between the NAT and the signaling initiator.  Now, it may be
possible (probable, even) that we'd have to set up an
additional secure channel between them to do this, but I do
think it's some clear that there are some security problems
here that can't be solved with hop-by-hop protection alone.

> deployment problem in general

Applying hop-by-hop security between two arbitrary devices
isn't going to be any easier.

Melinda

---

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

hi melinda!

please see my comments inline:

> decrypted and re-encrypted at Nat1.

if you perform end-to-middle authentication and key agreement then you nat1
does not learn the key.

if you provide end-to-middle authentication you still have to provide
peer-to-peer protection. end-to-middle is only an additional protection for
some specific objects. you need to know to whom you send these protected
objects. if you apply
- a digital signature for verification at nat2 then nat1 does not learn any
key
- a keyed message digest (based on a preshared secret) then nat1 does not
learn any key
- a key exchange betwen sender and nat2 then nat1 does not learn they key.

as a more concrete example:
the rsvp integrity object would provide peer-to-peer protection. if you
would include a service ticket for nat2 in the policy data object then this
would be an end-to-peer protection. based on the security of kerberos nat1
would not be able to decrypt the ticket to receive the session key.

>  That's not really very

ciao
hannes

---

From: Melinda Shore <[email-masked]>
Date: Wed, 13 Nov 2002 09:53:32 -0500

> if you perform end-to-middle authentication and key agreement then you nat1

That's not necessarily true.  If we rely on hop-by-hop
security provided by the NSIS transport layer for protecting
the key exchange, it most certainly will learn the key.

> peer-to-peer protection. 

Yes, but it's not sufficient to protect a key exchange
between the sender and Nat2.  Unless we're using pre-shared
keys (and I think that's a baaaaaad way to key this) we're
going to have to do this in the NSIS application and we're
almost certainly going to have to do it out-of-band.  This
is one case, and I think it's not an isolated one, where you
cannot safely assume that trust is transive and where
hop-by-hop security is inadequate for protecting signaling.

Melinda

---

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

hi melinda!

please see my comments inline:

> From: Melinda Shore [mailto:[email-masked]]
> Sent: Wednesday, November 13, 2002 2:34 PM
> To: [email-masked]
> Cc: Bob Braden; [email-masked]; [email-masked]
> Subject: Re: chain of trust
>
>
> between the NAT and the signaling initiator.

i consider end-to-end as a protection between a nsis initator and a nsis
responder. for end-to-end signaling these are usually two end hosts. nsis
iniator to a nat box would then be a end-to-middle authentication.

>  Now, it may be

i agree with you. this is why i argue that you need some end-to-middle
protection in addition to peer-to-peer security. this peer-to-peer security
might also use different mechanisms.

> isn't going to be any easier.

i personally think that peer-to-peer protection is much easier than
end-to-end protection for the following reasons:

- intra-domain communication
if you setup your network you exactly know which routers support nsis and
could possibly communicate with each other. in this case even pre-shared
secrets might be used (as rsvp does it today). you can take a look at mpls
networks (and signaling with rsvp-te) to see how the security works and how
difficult it is to setup keys between two adjacent routers.

- first-peer communication
this communication heavily depends on the scenario. for enterprise networks
this is not too difficult because of the higher degree and basically no
mobility. rsvp proposes mechanisms which work. windows 2000 used kerberos in
rsvp for this purpose for their rsvp implementation. packetcable people use
the integrity object.

in the mobile case things are more difficult. some working groups which deal
with this issue is ipsra and pana. especially pana tries to provide a secure
network access. seamoby might also be relevant (and mobileip) since they
also assume something going on between the mobile node and the access
router.

- inter-domain communication
inter-domain qos signaling is an on-going work. security protection might
depend on whether nsis signaling messages are transparent within the core
network. if there is no nsis node in the core network then the signaling
messages are effectively processed at the edges of the access networks only.
in this case there might be a concern regarding key management. but the same
concern might then also be applicable to aaa communication. the accouting
architecture might in general have an impact.

ciao
hannes

---

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

hi melinda!

> the key exchange, it most certainly will learn the key.

this is the place where concrete examples are useful:

- if you run ike/kink/tls between two nodes then a third node should learn
the key. (except if you send the key to him).

- if you have hop-by-hop protection and additionally a rsvp policy object
(with a kerberos ticket in it) then you do not allow other nodes to learn
the key. an other example: cms can be used for diameter to transport session
keys between a home aaa server to the aaa attendant. these keys are not
revealed to the intermediate aaa server. still there is security protection
between the aaa servers in addition to the cms mechanism.

i guess (and hope) that we do not want to invent a new nsis key exchange
protocol which uses hop-by-hop security to transport keying material.

> almost certainly going to have to do it out-of-band.

an example:
you can use nsis to transport a cms object. cms allows authentication and
key transport/key agreement. it allows to protect messages with symmetric
and asymmetric mechanisms. if you have configured a pre-shared key (or
exchanged public keys/certificates) out-of-band then this is great. you can
immediately use them.

in some cases you might have some pre-shared secrets or use session keys
with a security mechanism. i would not generally argue that these keys are
bad. in some cases they might be quite useful (for example: if you have
already established a security association).

  This
> hop-by-hop security is inadequate for protecting signaling.
this is true. that is the reason why i raised the end-to-middle discussion.
also rsvp added it later and it seems to be a useful concept. it might
require some rework (by using existing mechanisms) to incorporate recent
developments.

ciao
hannes

---

From: Melinda Shore <[email-masked]>
Date: Wed, 13 Nov 2002 10:36:41 -0500

> the key. (except if you send the key to him).

Do you mean "should not learn?"  Anyway, this is true, but
those are all out-of-band.  If we go back to the original
proposal, that hop-by-hop security should be adequate
because we can rely on the transitivity of trust, we can
find examples where it's not true and where we would need
additional mechanism.  That's all I'm trying to say, and I'm
not proposing inventing anything.

Melinda

---

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

hi melinda!

> Do you mean "should not learn?"
capture, retrieve, obtain

>  Anyway, this is true, but
> those are all out-of-band.
do you classify the rsvp policy object type of mechanism as out-of-band?

>  If we go back to the original
i fully agree with you that peer-to-peer security is not sufficient for all
scenarios. sometimes end-to-middle (or also middle-to-middle) might be
required (there are example especially in the midcom area).

ciao
hannes

---

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

hi melinda!

> Do you mean "should not learn?" 
yes - true (=> not learn). 

ciao
hannes