Subject: [NSIS] RE: Mike's security threats comments

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 29 May 2003 10:36:43 +0200

hi mike, 

i looked into your sip security framework draft which describes some threats
against sip to answer one of your questions. please find my comments below:

> -----Original Message-----
> From: Michael Thomas [<mailto:[email-masked]>] 
> Sent: Freitag, 23. Mai 2003 19:57
> To: [email-masked]
> Cc: [email-masked]; Tschofenig Hannes
> Subject: Mike's security threats comments
> 
> 
> 
> Hannes, here are a few random and not well
> integrated on my part's comments:
> 
> in section 2 on end 2 end communication, you state
> that:
> 
>           Providing end-to-end signaling message protection for NSIS
>           would cause difficulties for authentication and key
>           establishment procedures. It would furthermore limit the
>           flexibility of a signaling protocol in general.
> 
> I don't understand why this is especially
> different than end to middle, etc. In fact, I
> don't even understand why it's different from end
> to first hop. If I were attached to a remote
> network (say in an airport lounge) and the end
> host was my desktop machine, it seems to me that
> that's a case where the trust relationship is
> inverted; that is, I'd have a relation with my
> desktop machine, but not the first NSIS hop.
> 
> My general comment here, I guess, is that I'm not
> sure what the overall utility is with these
> distinctions, and/or what they're trying to
> accomplish. I'm not saying that there isn't a
> taxonomy here (I think there is), it's just that
> I'm not sure the distinctions you are trying to
> draw with the examples.
> 
> Maybe it would be better to devise this taxonomy
> two dimensionally, with "adjacent" and "crosses
> trust boundary" as the two axis? This is sort of
> how I think of SIP, for example.

for the discussion it helps to separate 
a) the judgment of how difficult it is to provide message protection
b) between which messages a protection takes place.

ad a) 
the security work should also help people from making design issues without
thinking about their consequences. this is particularly important after the
initial work is finished and people add some extensions (since they always
only refer to the security of the base document). i guess that there is no
doubt that it is more complex to protect certain messages or parts of
messages than others. i thought that it might be good to add some text to
the document somewhere. i am free for suggestions. 

looking at rfc 3473 (see notify message) one has to notice that additionally
considerations have to be made when, for example, end-to-middle protection
is added to the design. 

ad b) 
reading your draft i noticed that your taxonomy uses more than two
dimensions for sip. both sip and nsis involve communication over a number of
nodes hence it might be good to have a more fine granular differentiation
than only "adjacent" and "crosses trust boundary". 
you use: 
- ua to first hop proxy
- ua to intermediate proxy
- end-to-end uac to uas
- proxy-proxy traffic 
(taken from section 3.2)

the differentiation is not only theoretically but can also be found in the
protocol machinery. 

since sip has a different purpose than nsis there are some differences.
rsvp, for example, 

another difference between the text in security threats for nsis draft and
your sip security framework draft is the following: your draft was written
after sip was nearly finished. hence it was possible for you to refer to
certain threats very precisely (even mentioning the details of the message
payloads). we started earlier with the security work in nsis and hence it is
difficult to refer to one particular protocol only - everyone would treat it
as biased or solution-oriented. 
this is the reason why some text paragraphs look a little bit cryptic. i
simply tried to cover all cases. 

~ snip ~ 

> 2.14, Cost control
> 
> I think I understand where you're going here, but
> to me this is a little broader than cost control.

terms: 
how about calling the section "deployment issues" (not "deployment threats")
and labeling this subsection "Advice of charge"?

ciao
hannes

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