Re: [proxies] Review of draft-hoeper-proxythreat-01.txt (Part 1)

[Klaas Wierenga <[e-mail]>]

Bernard Aboba wrote:

Bernard,

Fair points, but aren't you than essentially saying "forget about the 
threats and write *only* a deployment draft"?

Klaas

>  > I am not very much in favor of mixing security considerations with
>  > operational considerations of proxies. It is my understanding that these
>  > are of a different nature. I would prefer to work from the assumption in
>  > this document that we stay out of any debate about whether proxies are a
>  > good or a bad thing but rather take it as a given and analyse the
>  > security and privacy threats that result.
>  
> The point is that the IETF has been working on this problem for a long time
> already.   Multiple areas within the IETF have had major issues with 
> proxies,
> and in toto, there are probably several hundred pages of threat analyses and
> proposals (some implemented, some not).  Many of the issues encountered
> by different areas are very similar (e.g. the discussion relating to SRTP
> keying in SDP is not very different from the discussion of key transport
> in AAA). 
>  
> Given this extensive body of work, the question is how to move forward. 
> One of the things we learned from the NAT debate was that it was
> critical to develop a detailed understanding of how NATs deployed in the
> field actually behaved.  In many cases the actual behavior was
> more complex and variable that we had believed originally. 
>  
> Similarly, I believe that understanding how proxies are actually deployed
> and used is critical.  For example, at present inter-domain
> key transport via proxies is very rarely deployed (EDUROAM is the only
> major deployment I am aware of).  This is because 802.11i has not caught
> on in hospitality, hotspots or carriers, where web portals are 
> overwhelmingly
> popular.  In enterprise, where 802.11i has caught on, but there is not much
> interest in inter-domain key transport, probably because most of the local
> access networks don't support IEEE 802.11i.
>  
> Aside from IEEE 802.11, the major wireless technology that has contemplated
> use of EAP keying along with AAA roaming is WiMAX.   However, WMF v1.0 
> roaming
> support is weak (there is no mandatory-to-implement user authentication 
> mechanism),
> so that most of the initial deployments don't support roaming.  In 
> addition, wholesaling
> is also not well supported (AAA servers need to obtain a certificate 
> from the WMF,
> at considerable cost).  As a result, there is not much chance that 
> inter-domain
> key transport will be deployed for WiMAX in the near future.
>  
> Some similar observations can be made relating to the deployment of 
> inter-domain
> SIP with SRTP.  Neither SIP inter-domain use nor SRTP support are common 
> today,
> and the intersection of the two is virtually non-existent.   So while 
> end-to-end
> security might seem like a useful goal, in practice there is not much 
> movement
> toward that in evidence.  It's barely possible to even purchase a 
> handset with
> minimal SRTP (e.g. RFC 3711) support today.
>  
> My takeaway from all this is that real world deployments appear to have a
> very low complexity tolerance.  Even technologies which are frequently
> assumed to be well established (e.g. EAP, 802.1X) frequently exceed that
> tolerance level.
>  
>  > An operational considerations document would be a welcome separate
>  > document, but let's not mix these two. In a way the latter document to
>  > some extent will explain how the security threats can be overcome (in
>  > addition to other operational considerations).
>  
> The IETF has already produced lots of documents relating to "solutions"
> to the proxy security problem.  The AAA WG alone spent 5 years on this,
> producing three different proposals, two of which have actually been
> implemented (e.g. Diameter Redirect and AAA/Kerberos integration).
>  
> So neither a problem analysis nor proposed solutions are new.  

_______________________________________________
Proxies mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/proxies