RE: [NSIS] review - some security comments on documents

[Tschofenig Hannes <[e-mail]>]

hi michael, 

it is great that you took your time to read our documents. please find my
comments inline:

> 
> I was asked to review the requirements, framework and theats 
> documents,
> from a security perspective. To be clear my background is 
> Firewalls, IPsec,
> key management, and I spent some time trying to build 
> programmable fast
> path policy-based classifiers.  I was also involved in the 
> Security Policy
> Protocol (SPP) as a firewall vendor - i.e. trying to solve the problem
> of getting IPsec through firewalls before the term NAT was around. 
> 
> REQUIREMENTS
> 
> My general comment is that this protocol is too general.

as a background: this was our first document in the nsis working group.
at the beginning we haven't had a clear idea what we were addressing in the
working group in detail. 
for example, nat/fw signaling was not in scope at that time. 

hence, all requirements are rather high-level. later we decided that we
should move forward and finish the work on the requirements rather than
re-writing them again to, for example, reflect the two-layer architecture. 

> A 
> key symptom of
> this is that the requirements are not prioritized. The key thing is,
> when compromises need to be made, on what basis will the 
> compromise be made?

that's always a problem with requirements. if you look at other working
groups then you will notice that the requirements are not prioritized as
well. 

> 
> Since security is a major requirement, and there are multiple 
> operational
> requirements which are very hard to secure, how will things bend?

could you be more specific?

> 
> FRAMEWORK
> 
> The framework document excited me. I thought, this is going to be some
> sophisticated protocol - end to end, plus hop-to-hop, with 
> mutable objects,
> and immutable objects, and some way to insert and delete objects while
> avoiding unwanted manipulation by intermediate nodes. In the end, the
> framework document actually specified far more requirements than the
> requirements document. Most of the additions are very 
> specific security
> requirements. 

you are right. the framework is more specific than the requirements document
since it was written much later and we had more ideas what we are going to
solve and how. 


> 
> While I understand why there are two documents from a strict 
> work-flow 
> point of view, I think it may be simpler to have one 
> document, perhaps 
> one that isn't quite as big.
> 
hmmm. in the past we have received a number of comments regarding document
restructering. restructuring the documents again and again is very time
consuming and might not add that much value. 


> THREATS
> 
> The threats document needs work. I was expecting a 
> threat-model. What things
> need to be defended against. Well, again the protocol is too 
> general to do
> this, so the document is a bit of a mismash of different things. 
> 
> Who do we need to trust to make this protocol work? 
> 
> {And, is that a realistic business model? If not, can we 
> change the trust
> model to one what matches reality?}
> 
> {Please don't tell me that the IETF doesn't do business 
> models. We do. "Best
> effort zero-settlement" has been the business model for most of the
> Internet. Our current protocols current support that model. 
> QoS proposes
> different business models, so we need to know who pays, who gains, and
> where is the possible fraud. We need to know this so that we 
> can find out if
> the security protects these relationships.) 

certainly true. 
the initial focus of the working group was oriented towards qos signaling.  
we wrote a separate draft which addresses authorization aspects in qos
signaling to raise peoples attention (; actually two drafts have been
written). you might want to take a look at them: 
http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-qos-authz-issues-00.t
xt and 
http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-aaa-issues-01.txt
http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-aaa-issues-01.pdf

unforunately, we have not received proper attention. 

another thing regarding the threat model: you have different security
requirements at different layers: first, you need to worry about the
signaling exchange between neighboring nodes itself itself and then you need
to worry about what you actually signal. you can compare this to diameter.
diameter itself needs some the same is true for sip. we tried to capture
these issues with Figure 2 in [THREATS]. 

a document handling issue: it is difficult to address all threats of all
possible signaling applications in the threats draft itself. it took us some
time to think about the threats and the problems of nat/firewall handling.
we have placed them in the nat/firewall nslp draft. some other threats are
very specific to some signaling protocols but not present in others. 

> 
> A key thing that concerned me is that NSLP objects could be 
> inserted/deleted,
> reordered, or even replayed, by NE that are participating in 
> the hop-by-hop
> security.  End-to-end integrity would protect the objects, 
> but not their
> existence.

nsis is not really an end-to-end signaling protocol, in most cases. you
might want to take a look at section 4 of the
<draft-tschofenig-nsis-aaa-issues-01.txt> draft. there we argue that
hop-by-hop security makes a lot of sense in qos signaling with the
corresponding authorization model (we called it New Jersey Turnpike Model,
just to give it a name). a different model (we called it New Jersey Parkway
Model) makes everything very, very difficult - with little utility. 
you have to trust the intermediate nodes to a certain degree since they can
do all sorts of things. 



> NSTL/NSLP need an NXT-like (DNSSEC) object which is always
> present, so that the receiver can know if objects were 
> removed/inserted.

certainly an interesting idea. if you look at the rsvp security property
drafts then you see that some people already proposed similar things but
they have never been deployed anywhere (in case of qos signaling). 

for nat/firewall signaling we are currently investigating the need for
end-to-end protection. 
there, however, you have the problem that you only signal a packet filter
which might change along the path and, in presence of nats, has no meaning
to the other end. 

> 
> A major threat that I see is CPU exhaustion of the slow-path. 
> Specifically,
> NSTL's section 8.4 - the system MUST aggregate well. But more 
> than that,
> it must DEFEND that aggregation at the edges. 

i we need to talk about this issue in more detail. i am not sure what we
both mean the same with aggregation. 
which draft you are referring? 

> 
> I want to suggest that there are strong arguments for having 
> an integrity
> protocol where one can examine the contents of the message 
> first, (since
> that is often rather cheap to do) determine if it actually 
> changes state,
> and only if the message needs to be acted on, THEN confirm 
> the integrity
> of the message. AH, btw, is one integrity protocol that 
> permits this. If
> one needs hop-by-hop privacy, then one has to provision the 
> decryptor to run
> at anticipated wire-speed to be able to examine the packets, but the
> authenticator, (which might even be public key based) does not need to
> run at that speed.

we fully agree that you need to have integrity protection. 
steve bellovin was one of those persons that insisted on having support for
encryption (unlike in rsvp where only integrity protection is offered). 

performance considerations are a separate issue. usually signaling message
protection is the least thing we worry about. the key exchange creates more
headaches. additionally, if you propose end-to-end security then things get
really difficult. 


> 
> I also want to suggest that the security and trust model be 
> fully developed
> before any other details are filled on.

do you have a draft were we can look at to see what you would like to see?

> 
> The threats document also seems to have been written in 
> isolation from the
> framework and requirements document.
why do you think so? 

the requirements document was written before we started the work on the
threats document. 

 I think it should parallel the
> requirements, explaining why there is a requirement, for instance, for
> hop-by-hop security, or end-to-end object integrity, etc..
you are certainly right. we will double-check whether there is some
consistency in there. 
if there are inconsistencies then i am guilty for it since i wrote the
section in the requirements draft, threats draft and the framework draft. 

> 
> OTHER DOCUMENTS
> 
> I was not asked specifically to review the nstl-00 or 
> application specific
> documents, but I did take a look at them. 
> 
which one? 

gimps ntlp?
the nat/firewall nslp or the qos nslp? 

i give you an answer for all three of them: 

- ntlp: we need to work on the security description. the next version will
contain more content. 
- qos nslp: we are working on the security issues. we basically have add the
content of the previously mentioned qos authorization drafts in there (and
at the same time try to keep the document at a low pagecount.) currently the
qos document contains no security since we haven't had time to finish all
the work. please note that this is not the first security document. it is a
merge of previous document which contained security. however, the process of
merging document takes some time - work in progress.if you look at the qos
authorization documents than you will be convienced that we serioulsly
tooked at qos authorization (based on steve bellovin's request). 
- nat/fw nslp: see below.

> I think that the NSTL is the key to the security.
ntlp - gimps: 

it is the key for security between neighboring nodes. it cannot address
authorization issues for nslp applications. 

> While I am 
> very impressed
> with this -00 document, I think it is wrong to start with 
> packet formats,
> and whether or not TLS, UDP, IPsec, is useable. 

agreed. the ntlp suffers from detailed threats. unfortunately, editing was
done in the last minute and i had no chance to add some text. we discussed
threats at the mailing list but we haven't incorporated them into the draft
yet. 

the ntlp is also not the first document in this area. we have had a number
of other documents before. some of them had such a detailed security
consideration section that people said: "this is not a security protection -
keep the security consideration section shorter."

> 
> Please start with the public keys - when will they be used, 
> how/if will they
> be strongly authenticated, etc.  Maybe that goes into the 
> framework document.

i guess we need to discuss this issue in more detail. 

> 
> The QoS document claimed that all of this would be offloaded 
> to some AAA
> protocol -- I think that this is a cop out. I need to know how the AAA
> will provide the integrity protection, the authentication and 
> authorization
> that is required.
> 
> Section 7 of NSTL basically reads as "just use IPsec".
> NOT ENOUGH. Think about the relationships and where the keys 
> will come from.
> IKE is signaling. Maybe using signalling to secure signaling 
> is the wrong 
> choice. Maybe not.
> 
> Please find and read draft-ietf-ipsp-spp-01.txt.
> 
> I read: "An alternative approach would be to use raw IP with the RSVP
> protocol numbers and a new RSVP version number."
> This may also conserve/preserve silicon!
certainly not my idea (since it also creates problems with some ipsec
implementations with regard to the supported traffic selectors).

> 
> I have a question from ignorance of deployed hardware:
> Are RAO filters really available in production fast-path 
> silicon? I know that
> some silicon vendors can cope, because they are 
> programmable/configurable,
> but what about those that aren't? 

this issue is, among many others, discussed in the analysis document. 
you might also want to take a look at michael's web page which talks about
the impact of ip option processing: http://www.welzl.at/ip-options/


> 
> In the NAT-FW document, it says: 
> 3.2
>    "Discovering security gateways, which was also mentioned as an
>     application for NSIS signaling, for the purpose of 
> executing an IKE
>     to create an IPsec SA, is already solved without requiring NSIS."
> 
>    really? I didn't know that it was solved. Do tell!

we tried to scope our work. our work started with installation of packet
filters in a path-coupled way. we are not developing a solution for ike to
discover ipsec gateways. you might want to take a look at tunnel endpoint
discovery (ted) for such a solution.


> 
> The QoS and NAT-FW document is clearly too preliminary for me 
> to be able to
> evaluate whether or not the requirements or features of the 
> framework have
> been satisfied by this protocol. In particular, no statements 
> are made about 
> the trust relationships, or who may edit what mutable fields, 
> etc.

for nat-fw draft: actually the draft contains a fair amount of discussion on
trust relationships (see section 3.5, section 4., appendix b, appendix D).
that's more than i have ever seen in the are of path-coupled firewall
signaling.

there are no requirements for nat/firewall signaling. melinda shore
suggested the idea in the midcom working group. she presented her idea at
the tist bof and the work was moved to nsis. 

> I was
> hoping that there might be enough meat here to saw whether or not the
> framework requirement were useful/complete. 

the framework focuses on qos signaling and not really on nat/firewall
signaling. 

> 
> OTHER:
> 	are there really RMF's capable of managing the resources for all
> 	paths through a network? I thought that the ATM folks 
> tried to do
> 	this and failed, and this was one of the reasons that ATM didn't
> 	get the deployment that was originally envisioned?

that's a qos question which many folks in the nsis working group will be
glad to give you an answer for :-)

thanks again for your detailed comments and for the time looking at the
drafts. your comments will certainly improve the quality of the documents. 

ciao
hannes

> 
> ]       ON HUMILITY: to err is human. To moo, bovine.         
>   |  firewalls  [
> ]   Michael Richardson,    Xelerance Corporation, Ottawa, ON  
>   |net architect[
> ] [e-mail]      
http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security
guy"); [


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQCbyqoqHRg3pndX9AQFR/AQAsIXy5Ekd75e9BAWMqX1DdxeZKICdI8fi
2+SX3nd34LzTMI5kTsBtCm5Pohl2Gn0B8s3jFkIeZ5qClCZp/Q7yEqz0+52vjJoJ
vwPNNvbJM31bpdY8hlY4ajA9OkNlYCfnexfoMr6G6I0hqpHlwnpDCs+ykK9d8M19
pu0UFTKR09A=
=nK5K
-----END PGP SIGNATURE-----

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

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