Subject: [proxies] Call for comments and co-authors: <draft-hoeper-proxythreat-00.txt>

From: Katrin Hoeper <[email-masked]>
Date: Tue, 14 Oct 2008 11:34:59 -0400

Hello everybody,

I have put together a 00-draft attempting to summarize the 
discussions in Philadelphia and on this list.
Please read the draft and send me your comments:

"Threat Model for Networks Employing AAA Proxies"
<draft-hoeper-proxythreat-00.txt>
http://tools.ietf.org/html/draft-hoeper-proxythreat-00

I am sure  I missed a lot of things and other things need to be 
corrected That's why I need your feedback!
Also, I am seeing myself as the editor of the document and am looking 
for co-authors. Please let me know if you are interested.

I hope to get out a 01-draft before the next IETF meeting, i.e. 
comments (and co-authors ;)) before the end of the month are highly 
appreciated.

Regards,
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: Stefan Winter <[email-masked]>
Date: Thu, 16 Oct 2008 15:44:14 +0200

Hi Katrin,

> I have put together a 00-draft attempting to summarize the discussions
> in Philadelphia and on this list.

Thanks a lot!

> Please read the draft and send me your comments:

Attacks 1-4 are really quite broad in scope. They work on the network
layer and can be applied to all sorts of packets. While what's written
in these sections is true, I wonder if it needs an explicit mention in
this document, which is supposed to deal with AAA proxy-specific attacks.

Attack 5 is more severe than stated in the document: AAA protocols might
send their payload in parts in the clear. Intermediate hops (not only
AAA proxies) may extract information out of these payloads, even without
knowledge of keying material. RADIUS only encrypts a small subset of
attributes on the wire. Diameter communication MUST be encrypted with
IPSec or TLS (but there was talk going on on the dime list for making
this a SHOULD in 3588bis, IIRC).

5.2.2 re "[Editor's note: Is this true?]": Access-Request packets in
RADIUS can be unauthenticated and thus be replayed. This will happen if
the Message-Authenticator digest is not present in the request. This is
NOT RECOMMENDED as per RFC5080, but possible (and existing deployed
practice).

5.2.8, re "[Editor's note: Are AAA attributes typically protected?]":
There are key wrapping schemes that provide encryption between the ends
of the AAA communication for individual attributes. They require
out-of-band signalling of the wrapping keying material though, and are
not an inherent protocol feature. So while they can be protected it is
"typically" not the case (at least in the networks I work with, maybe
other people have other experiences).

Oh, and a typo in section 6:

This section uses the thread model 

-> threat

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473