Subject: RE: [NSIS] Key management

From: Bob Braden <[email-masked]>
Date: Thu, 7 Nov 2002 20:04:51 GMT

*> >
  *> > BTW, we should think about the performance implications of
  *> > doing a key exchange in the transport layer + a key exchange
  *> > 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.
  *> 

I don't see an issue here, in terms of mechanism.  The hash code used
for a hop/hop mechanism for integrity or the encryption for confidentiality
can cover the application layer information as well as the transport
layer.  In terms of my model, it can cover the SAPU as well as any fields
of the CSTP header that you want to protect.  So there will be one key.
Of course, all of this is distinct from end user authentication, which
is almost certainly a PK problem.

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

That is indeed a property of hop/hop security.  However, when you say
authentication here, you cannot be talking about user authentication,
you must be talking about NSIS neighbor authentication.

Bob Braden

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

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

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

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 8 Nov 2002 10:01:44 +0100

hi bob!

please find my comments inline:

> layer.
that's my argument. i only want to point to this issue since some people
argue that you only need to protect the application layer. you can protect
both layers without a problem. why only to protect one?

  In terms of my model, it can cover the SAPU as well as any fields
> of the CSTP header that you want to protect.  So there will be one key.
this is definitely true.

> is almost certainly a PK problem.
not necessarily. a pk-problem will arise if you want any router/network
along the path to authenticate the user authentication. for the first peer
protection there is no pki problem.

> That is indeed a property of hop/hop security.
this can be considered independently of hop-by-hop security protection.
for example: if you use rsvp and pk-based mechanisms then you do not
establish a security association. hence you have expensive processing every
time you include a digital signature.
in case of kerberos rsvp proposes to store the session key of the ticket to
avoid sending the service ticket every time.

>  However, when you say
it depends who is the signaling initiator. if the signaling initiator is the
end point then it must be user authentication since otherwise you cannot
perform policy based admission control (+accounting).
in case of other nodes along the path the identity is not the user.

ciao
hannes