Subject: RE: [NSIS] Security Threats for NSIS draft

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 12 Jun 2003 17:21:15 +0200

hi marcus, 
hi miquel, 

thanks for your comments. 

would you also be happy if i add a table which maps the list of the threats
into the groups
- general security threats
- signaling transport related
- NSIS NSLP specific 
?

ciao
hannes

> -----Original Message-----
> From: Marcus Brunner [mailto:[email-masked]]
> Sent: Thursday, June 12, 2003 4:53 PM
> To: [email-masked]; Tschofenig Hannes
> Cc: [email-masked]
> Subject: Re: [NSIS] Security Threats for NSIS draft
> 
> 
> Hannes,
> 
> We find the document very useful, the only thing we are not 
> that happy with 
> is the grouping of the different threats. A proposal could be 
> to group into 
> general security threats, signaling related, and NSIS 
> specific. For people 
> know very well normal security threats it is tiring to go through the 
> document.
> 
> And the format ID-nits etc. needs to be updated.
> 
> Marcus & Miquel
> 
> --On Donnerstag, 12. Juni 2003 10:25 +0300 
> [email-masked] wrote:
> 
> > Hannes,
> >
> > Any chance you'd get this submitted soon, I'd like to start WG call
> > before Vienna.
> >
> >> Security Threats for NSIS
> >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt
> >
> > thanks,
> > John
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> 
> 
> 
> --------------------------------------
> 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
> Mobile: +49 (0) 163 275 17 43
> personal home page: http://www.brubers.org/marcus
> 
> 
> 
> 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Marcus Brunner <[email-masked]>
Date: Fri, 13 Jun 2003 09:33:39 +0200

I think the distinction between signaling transport related NSIS NSLP 
specific is not needed. I think it is difficult to do this because the 
framework on this issue is not stable (at least to my knowledge)

But at least general security and signaling specific threats would make it 
much clearer.

Marcus

--On Donnerstag, 12. Juni 2003 17:21 +0200 Tschofenig Hannes 
<[email-masked]> wrote:

> would you also be happy if i add a table which maps the list of the
> threats into the groups

---

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 19 Jun 2003 10:03:55 +0300 (EEST)

Hi,

I went through the document yesterday evening and this morning. As I am no
security expert, I am not able to comment on the contents and whether what
you say is true or not. As a real newbie in security issues, I can only
comment a little on the presentation. As you mention yourself, the
document is pretty long, thus, some summary would be needed. You do have a
conclusions-section, true, but you could say a little more there, for
example, what are the things RSVP expects to be "there" a priori, e.g.
keys and knowing your neighbor (and what is wrong with the way RSVP
expects things to be?), and why was it that some issue is a problem, e.g.
addressing for signaling messages should be done in a hop-by-hop fashion?
Also, the comment in the conclusions about "public key auth and user id
confidentiality requires improvements" leaves something to wonder, why was
this so and what are these improvements?

Thus, you might enhance your existing list in the conclusions by saying a    
little more (one-two sentences) about the reasons and put pointers to the
sections where a particular problem was described - your doc is 43 pages, 
so it is like a short book, and a reader will surely not remember
everything after one read, even after two.

There are some types here and there, e.g. you seem to use some weird
character as the "'" in "host's" or "user's", it prints out like "M-^R",
pp. 5 "of a nodes", pp. 12 "confidentiality, AND confidentiality of the
signaling messages", Figure 4 is split up on two pages 20-21, same with
Figure 5 (28-29), pp. 21 "In IPSEC is applied in a nested", pp. 34 "It
cannot not be interpreted" > "It should not be" (it can, but it shouldn't
:), pp. 35 "and key exchange should BE separated from".

Hope this helps,
Jukka