Subject: [NSIS] Security Threats for NSIS & RSVP Security Properties documents

From: [email-masked]
Date: Thu, 22 May 2003 12:19:49 +0300

Hi all,

I would like to gage WG opinion on the following documents:

Security Threats for NSIS 
http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt

RSVP Security Properties 
http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt

My question is, are they ready or soon to be ready for WG last call?
If anyone has open issues with them, please comment on them.  If you
have not read them, please do so.  These documents will have impact
upon the protocol work we will be doing.

Also, perhaps the editor of the documents could comment on this - 
Hannes, do you feel that either document is ready for WG last
call?

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

---

From: Michael Thomas <[email-masked]>
Date: Fri, 23 May 2003 10:56:57 -0700 (PDT)

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.

Section 2.1, MITM Attacks:

This first paragraph is interesting, but it seems
rather odd to be placed in a discussion of MITM
attacks. Its more of a discussion about state
establishment considerations -- though important,
is it relevant to a discussion of threats?

In general in this section, it sort of mixes
threats and solutions. That is, establishing an SA
is what one generally does to counter some set of
threats. Though proper SA establishment may in
turn have its own threats, I'm not sure they're
relevant to this document which I sort of view as
a "what security threats does the design need to
have answers for."

My suggestion is to phrase this only in terms of
the threats, not ways of countering them in 1, 2
and 3.

Section 2.2, eavesdropping

I think it's worth parsing apart the difference
between adjacent and non-adjacent eavesdropping. 
That is, what happens when signaling
intermediaries can snoop. The analogous SIP
situation is proxies and SRTP keys. This is
distinct from non-participants eavesdropping 
via sniffers, etc.

Section 2.2, Combining...

This section really seems to be about DoS. What I
don't really see here -- and maybe it just needs
to be separate bullets -- is a discussion of CPU
and state-storage attacks. Eg, leveraged attacks
by making a non-complex message force a node to do
expensive modular arithmetic, as well as the whole
subject of state retention/spoofing. The latter is
a particular concern, I'd think, because of the
possibility to source-spoof combined with PATH
state. I might be wrong, but I don't think that
RSVP handles this well.

2.14, Cost control

I think I understand where you're going here, but
to me this is a little broader than cost control.
What this really says to me is that any implicit
trust of the access provider's network as is the
current case with dialin networks is suspect in
the brave new world of wireless, etc. The *threat*
to my mind is that I might accidentally connect to
a bogus or sleazy provider. (the solution being
strong auth/authz of the provider).

Part of that threat might be addressed by knowing
cost structures of the remote provider, but I'm
not entirely sure that that's a threat per se so
much as a (debatable) requirement of the protocol.
One can envision a rate structure XML site which
the mobile downloads/contacts which is outside of
the domain of NSIS, after all.

	   Mike

---

From: Melinda Shore <[email-masked]>
Date: Fri, 23 May 2003 14:42:42 -0400

> desktop machine, but not the first NSIS hop.

I don't think that the issue here is end-to-endness as it is
that, in this case, end-to-end necessarily actually means
hop-by-hop and there can be some non-trivial trust issues in
there.

Melinda

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 25 May 2003 19:28:40 +0200

hi mike, 

thank you for reading the document and sending comments.

please see my comments inline: 

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

ruediger geib gave me a similar comment to the "difficulty" of end-to-end
vs. end-to-middle security. 

i am open for changing terms. the difficulty of protecting messages or
payloads heavily depends on the given scenario and on the information you
have in advance. 

i have read you sip security framework document but i do not have the
details in mind. i will re-read it again to see whether it helps me. 

the terms "adjacent" and "crosses trust boundary" might not be sufficient, i
guess. 
(i assume that you mean adjacent as belonging to the same admin domain). 
the problem is that you might easily establish security between neighboring
domains in some cases whereas in others this is more complicated. 
an example: network access authentication and end-to-end mobile ip security

> is it relevant to a discussion of threats?

i guess it is important. if you want to mount attacks against a protocol
then the phase where the security association is established is a good
place. 

it is also good to point to a typical protocol behavior to split
authentication and key exchange from the actually signaling message
protection. 

> threats and solutions.

i tried hard to avoid solutions. however, it is fair to say that security
mechanisms follow typically patterns. i tried to describe these patters in
details and their relevance for nsis. 

since nsis might be used in a number of scenarios and between different
nodes at different parts of the network it is difficult to capture all
possible combinations. hence i have separated the discussion into the
subcategories. 

> That is, establishing an SA

i have subdivided these issues in more details. i have briefly described
what happens if you have no authentication (or unilateral authentication).
the result is obvious. 

since nsis is not an attempt to design pathcoupled signaling protocols from
scratch it is fair to look at existing protocols. these protocols show that
some security is provided but in certain cases not sufficient (e.g. weak
authentication).

i cannot exclude security protocols itself from the discussion since
protocols such as rsvp define their own security mechanisms. 
(i.e. if you use standard security mechanisms then you usually do not have
to worry about replay attacks. if you need to create your own security then
you need to consider it.)

> the threats, not ways of countering them in 1, 2

i will go through the text again and try to remove solution oriented parts. 

> distinct from non-participants eavesdropping 

might be an idea. 

the analgon with srtp is somewhat misleading since nsis is not a protocol
for commucation purely between end hosts (srtp establishes keys and sas
between the end hosts only). 
 
> subject of state retention/spoofing.

you are right that this section mainly addresses dos attacks specifically
addressed to the topic of the section. 
a separate section talks about dos attacks (see section 2.9). 

spoofing is covered in a separate section (see section 2.5).

 The latter is
> to me this is a little broader than cost control.

terms :-) 
what term do you suggest instead of cost control? 

> strong auth/authz of the provider).

interesting that you mention this part. i have discussed this issue with
outer ietf members and it turned out that this issue is relevant for a
number of groups such as pana, nemo, eap, mobile ip, etc. 

i placed it in a separate section (labeled as deployment threats) since it
is actually not a threat. if you have a different name, then please let me
know.  that's the reason why is introduced the section with the following
text: 
"
This section addresses problems which could appear during the deployment of
an NSIS protocol in a real-world environment. Although these problems are
theoretically not an obstacle for practical reasons they can represent
threats worth a consideration. 
" 

this section should address the problem that in a mobile environment there
has to be a mechanism which allows the authorizing entity (the entity which
triggers the qos reservation) to know how much it actually costs. i wouldn't
use a "service" where i have no idea about the costs. this is actually one
place where i can see the usefulness of non-repudiation. 

> the domain of NSIS, after all.

now you go into a solution discussion.  
actually a number of people have proposed different
protocols/payloads/languages for exchanging cost information. if you look in
the "nsis aa" draft then you will notice that something similar is actually
required for more advanced scenarios. 

> 	   Mike

ciao
hannes