Subject: RE: [NSIS] Reliability and Security

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 3 Oct 2003 10:03:26 +0100

hi all,

> - NTLP and NSLP security are combined. This would result 
>   in chains of trust. Complex.
i think this depends on what you mean by 'combined'.
(see later).

> - NTLP has no security, security is done by NSLP. Bad idea, 
>   DoS attacks should be inhibited at the lowest possible 
>   level.
this i entirely agree on. one of the benefits of allowing the use
of a well known transport protocol in the NTLP is that you can
inherit the DoS protection techniques that have been thought out
for the newer protocols (sctp/dccp).

> - NTLP and NSLP have separated security mechanisms. Not very 
>   nice if operators must locate errors. If possible, 
>   separate instances of the same security mechanism.
i don't really see the problem here. provided the failing layer reports
errors in a helpful way, what do you see going wrong?

> - If you look at the example I've added below, NSLP may 
>   benefit from chains of trust. Is there a smart way of 
>   organising them?
i'm sorry but i didn't really follow it. the node names and
nslp names seem to get swapped between hannes and your text?

> - We'll have to agree which protection is required at what 
>   level (I'm e.g favouring NTLP with authentication only).
if you mean 'authentication and key exchange which enables
message protection (integrity, confidentiality) but no
authorisation aspects' then I agree also (and this is also
what the framework says).

a particular question (this is *my* scenario with *my*
terminology):
suppose nodes A and B both implement NSLP Q and are communicating
over a direct NTLP connection which has been set up with mutual
authentication and message integrity protection,
IF node B's authorisation policy is 'I will do anything that
node A asks if I can actually do it' does that require an
NSLP level security association to secure that authorisation,
or can it be inferred from the underlying NTLP association?

r.

> - There may be more options. Let's try to classify solutions 
>   in terms of security, complexity and scaleability. 
> 
> The WG must take decisions and opinions will be split. 
> But I think it's time to make some progress on the security 
> issue.
> 
> Regards, Rüdiger
> 
> 
> |for security (and in particular for security association 
> |establishment) the following issues are of importance: 
> |
> |- node A has to learn that a security association has to be 
> |  established to some node C. 
> |  node A and C support NSLP X; node B only NSLP Y
> |  how and when is this information obtained?
> 
> wouldn't your example have to be extended to nodes X,
> Y and Z all support NSLP A and peer in the order shown. 
> The are separated by an unknown number of NTLP hops. In 
> some cases, it may be desireable for NSLP Z to directly 
> signal to NSLP X.
> 
> |- at which layer are messages protected? (ntlp/nslp)
> |
> |we have seen a number of protocol proposals in the past. there 
> |it can easily be seen that differences exist which have an 
> |impact on security. it is important to make the default mode 
> |of operation very clear and precise.
> |
> |ciao
> |hannes
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 3 Oct 2003 18:12:37 +0200

hi robert, 
hi ruediger, 

> this i entirely agree on. one of the benefits of allowing the 
> use of a well known transport protocol in the NTLP is that 
> you can inherit the DoS protection techniques that have been 
> thought out for the newer protocols (sctp/dccp).

do you think it is sufficient to rely on the mechanisms offered by newer
transport layer protocols from a security point of view? 

> i don't really see the problem here. provided the failing 
> layer reports errors in a helpful way, what do you see going wrong?

i don't see this as a problem too. you have to be more specific here to
address your concern. 

> nslp names seem to get swapped between hannes and your text?

please clarify. 

> what the framework says).

i guess i have to explain this in more detail - i will provide some text. 
many authorization issues which we have described so far in our nsis-authz
and nsis-aaa drafts are concerned with a  user requesting a qos resource.
there are, however, other authorization issues here. 

anyway, some authorization decisions can only be made at the nslp layer
where some additional information is available. 
however, it does not mean that you do not provide security at a lower layer
(such as integrity, replay and confidentiality protection). an example: rsvp
provides integrity and replay protection with the rsvp integrity object
which protects the entire message. unfortunately an authentication and key
exchange protocol is missing which provides the keys for this security
association. an authorization decision can be made with the identity used in
such an authentication and key exchange protocol. with the user identity
representation rfc some additional mechanism have been added which aim to
provide information about the user identity. 

> suppose nodes A and B both implement NSLP Q and are 
> communicating over a direct NTLP connection which has been 
> set up with mutual authentication and message integrity 
> protection, IF node B's authorisation policy is 'I will do 
> anything that node A asks if I can actually do it' does that 
> require an NSLP level security association to secure that 
> authorisation, or can it be inferred from the underlying NTLP 
> association?

i guess it would be good to clarify what it means to have a security
association at a particular layer. 
to me it means which parts of the nsis message are covered by a particular
security association. if, however, the entities terminate a different
physical entities then it is difficult to pass the identity up to the nslp
for additional authorization. i will provide some more details on this.  

ciao
hannes

> --
> Registered Office: Roke Manor Research Ltd, Siemens House, 
> Oldbury, Bracknell, Berkshire. RG12 8FZ
> 
> The information contained in this e-mail and any attachments 
> is confidential to Roke Manor Research Ltd and must not be 
> passed to any third party without permission. This 
> communication is for information only and shall not create or 
> change any contractual relationship.
>