Subject: [proxies] Recap for -00 draft

From: Katrin Hoeper <[email-masked]>
Date: Fri, 02 May 2008 10:07:22 -0400

Hi,

it's good to see that we already had some good discussions on this list.
I would like to briefly recap and outline next steps for a first draft.

So far we seem to have collected:

I. USE CASE
1) a worldwide WLAN that enables roaming registered users to access 
information free of charge
(thanks Stefan for your detailed description)

II. THREATS:
1) proxies can listen to traffic
2) insert fake accounting  packets

III. FEASIBILIY
-easy to sniff traffic for proxies
-most attributes readable due to AAA hop-by-hop security

IV. SEVERITY
-depends on the content of the exchanged data
When data contains valuable user information (such as the user's 
age), this information can be correlated with the user identity and 
then be exploited.
-depends on national laws and regulations
-depends on whether offered services are free or paid

-some providers seem to be more worried about malicious insiders and 
outsider sniffers rather than proxies

V. SOLUTIONS
There have been some proposals but I'd like to keep this discussion 
for later on, after we decided if and how we should continue. (see my 
<http://www.ietf.org/mail-archive/web/proxies/current/msg00001.html>previous 
post)

NEXT STEPS & CALL FOR COMMENTS
I will now go ahead and put together a -00 draft about items I-IV 
using our 
<http://www.ietf.org/mail-archive/web/proxies/current/msg00000.html>Philadelphia 
discussion, 
<http://www.ietf.org/mail-archive/web/proxies/current/msg00001.html>ppt 
slides, and the discussion on this list as input.

Please send other information that you would like to be included in 
the 00 draft to the list. Also let me know if you disagree with 
previous discussions (items I-IV, not solutions!). Off course, 
everybody is more than welcome to volunteer as a co-author. Just let me know.

We definitely need more use cases. I will try to cover all aspects 
listed under IV. Severity in the use cases. It would be very helpful 
if people could send me more "real implementation" examples of 
networks using proxies, especially the architecture of such networks 
and the particular functions of proxies in them (e.g. what data do 
they need to know).

  Katrin

----------
Katrin Hoeper
Computer Security Division
National Institute of Standards and Technology (NIST)
100 Bureau Dr. Mail stop: 8930
Gaithersburg, MD 20899
(301) 975 - 4024
_______________________________________________
Proxies mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/proxies

---

From: Alan DeKok <[email-masked]>
Date: Fri, 02 May 2008 18:02:26 +0200

> (thanks Stefan for your detailed description)

  I'll see if I can write up a description of a commercial global
roaming system.

> 2) insert fake accounting  packets

  - users can use stolen credentials
  - visited networks can listen to traffic
  - visited networks can insert fake accounting packets
  - home network can authenticate the user, and then
    refuse to pay the proxy or the visited network

> -most attributes readable due to AAA hop-by-hop security

  - everyone in the "AAA trust" boundary can see all of the traffic,
    and lie about any of it.

> When data contains valuable user information (such as the user’s age),
> this information can be correlated with the user identity and then be
> exploited.

  I would add a section "mitigating factors".  These are not *solution*,
but pragmatic self-interest.

 - if the visited networks have a pattern of theft/fraud, the
   proxies and/or home networks will refuse to work with them
 - if the proxies have a pattern of theft/fraud, the
   visited and/or home networks will refuse to work with them
 - if the home networks have a pattern of refusal to pay bills,
   the visited networks / proxies will refuse to work with them
 - if a user has a pattern of theft/fraud, the home network will
   refuse to authorize their access

  i.e. as soon as someone gets caught doing bad things, it's in everyone
else's interest to kick them out of the AAA network.

   Also:

  - home networks inform proxies / visited networks about limits on
    their willingness to pay.  e.g. "allow 10 minutes of access"
  - visited networks are responsible for enforcing these limits
  - home networks refuse to pay for access outside of those limits
    after all... the visited network was *told* to hang up.  If it
    doesn't, the home network isn't responsible for the bill
  - the visited network is responsible for informing the proxies
    and home network that the user is still online, and what they are
    doing (time/traffic accounting).  If they stop, the home network
    can assume that the user has logged off, and refuse to pay for
    further service.
  - if mid-session disconnection is supported, the home network
    can inform the visited network to disconnect the user.  Again,
    the visited network does this, because the home network will
    refuse to pay for service after a disconnection request has been
    sent.

> Please send other information that you would like to be included in the
> 00 draft to the list. Also let me know if you disagree with previous
> discussions (items I-IV, not solutions!). Off course, everybody is more
> than welcome to volunteer as a co-author. Just let me know.

  I'm interested, but I don't know how much time I have.

> listed under IV. Severity in the use cases. It would be very helpful if
> people could send me more “real implementation” examples of networks
> using proxies, especially the architecture of such networks and the
> particular functions of proxies in them (e.g. what data do they need to
> know).

  I'll grab some diagrams and send them over.

  As for the data the proxies need to know... it's as much data as the
visited network can supply.  Which is usually nothing more than user
identification, visited network identification (access points, etc.),
data traffic in/out, and session time.

  Everyone would like to get more data, but the equipment at the visited
networks is so old that it often doesn't support 8 year-old standards.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 2 May 2008 15:30:06 -0700

Comments below. 

Date: Fri, 2 May 2008 10:07:22 -0400To: [email-masked]: [email-masked]: [proxies] Recap for -00 draftHi, it’s good to see that we already had some good discussions on this list.I would like to briefly recap and outline next steps for a first draft. So far we seem to have collected: I. USE CASE1) a worldwide WLAN that enables roaming registered users to access information free of charge(thanks Stefan for your detailed description) II. THREATS:1) proxies can listen to traffic2) insert fake accounting  packets

[BA] It's worthwhile to point out that authentication data may not necessarily take the same path as accounting data.   So an authentication proxy need not necessarily also function as an accounting proxy -- particularly if we are talking about a roaming network in which there is no settlement. 
 III. FEASIBILIY -easy to sniff traffic for proxies-most attributes readable due to AAA hop-by-hop security 
 
[BA] I'd note that Diameter (RFC 3588) distinguishes between types of AAA agents.  In addition to proxies, there are also Re-directs.  This enables the separation of the functions of proxies (described in RFC 2607) to some extent.  For example, an Agent that functions solely as a "route server" can be configured as a Re-direct, without actually needing to gain access to attributes flowing between the Diameter client and server.    IV. SEVERITY-depends on the content of the exchanged dataWhen data contains valuable user information (such as the user’s age), this information can be correlated with the user identity and then be exploited.-depends on national laws and regulations-depends on whether offered services are free or paid  -some providers seem to be more worried about malicious insiders and outsider sniffers rather than proxies V. SOLUTIONSThere have been some proposals but I’d like to keep this discussion for later on, after we decided if and how we should continue. (see my previous post)  NEXT STEPS & CALL FOR COMMENTSI will now go ahead and put together a -00 draft about items I-IV using our Philadelphia discussion, ppt slides, and the discussion on this list as input. Please send other information that you would like to be included in the 00 draft to the list. Also let me know if you disagree with previous discussions (items I-IV, not solutions!). Off course, everybody is more than welcome to volunteer as a co-author. Just let me know. We definitely need more use cases. I will try to cover all aspects listed under IV. Severity in the use cases. It would be very helpful if people could send me more “real implementation” examples of networks using proxies, especially the architecture of such networks and the particular functions of proxies in them (e.g. what data do they need to know).  Katrin

Katrin HoeperComputer Security DivisionNational Institute of Standards and Technology (NIST)100 Bureau Dr. Mail stop: 8930Gaithersburg, MD 20899(301) 975 - 4024