Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt

"Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> Mon, 07 November 2011 17:11 UTC

Return-Path: <hannes.tschofenig@nsn.com>
X-Original-To: abfab@ietfa.amsl.com
Delivered-To: abfab@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A683221F8B0C for <abfab@ietfa.amsl.com>; Mon, 7 Nov 2011 09:11:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.696
X-Spam-Level:
X-Spam-Status: No, score=-106.696 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7T0voK+xJGA for <abfab@ietfa.amsl.com>; Mon, 7 Nov 2011 09:11:46 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id CFF0521F8B05 for <abfab@ietf.org>; Mon, 7 Nov 2011 09:11:45 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pA7HBiUO031911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Nov 2011 18:11:44 +0100
Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pA7HBfwr030426; Mon, 7 Nov 2011 18:11:43 +0100
Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Nov 2011 18:11:42 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 07 Nov 2011 19:13:24 +0200
Message-ID: <999913AB42CC9341B05A99BBF358718DBDD109@FIESEXC035.nsn-intra.net>
In-Reply-To: <tslfwi0kr2r.fsf@mit.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt
Thread-Index: AcydT/QvvX+PVv/vRlKGnojZOsGP0QAHHBkw
References: <CADD53EA.3587B%josh.howlett@ja.net> <tslfwi0kr2r.fsf@mit.edu>
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: ext Sam Hartman <hartmans@painless-security.com>, Josh Howlett <Josh.Howlett@ja.net>
X-OriginalArrivalTime: 07 Nov 2011 17:11:42.0393 (UTC) FILETIME=[51F6D290:01CC9D70]
Cc: abfab@ietf.org
Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt
X-BeenThere: abfab@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" <abfab.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/abfab>, <mailto:abfab-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/abfab>
List-Post: <mailto:abfab@ietf.org>
List-Help: <mailto:abfab-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/abfab>, <mailto:abfab-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Nov 2011 17:11:46 -0000

There are two aspects: 

1) How can you technically find the server you need to talk to?
Diameter has defined a DNS based discovery procedure.

2) Is the Diameter entity you talk to indeed some entity you trust?

The IETF Diameter specifications only talk about (1) and not about (2). 
They implicitly assume that (2) is addressed somehow outside the realm
of the IETF. 

There is a relationship between the two issues. Depending on how you
address (2) you may constraint the solutions for (1). Not only the AAA
community had made that observation but also the RAI guys with their
work on SIP when the had initially planned to model the proxy-to-proxy
interaction according to email. 

In Diameter the DNS based discovery was not used by anyone at few years
back; this was the time when I co-chaired the DIME group and helped to
organize interop-events were we had gotten feedback from the other
implementers. Everyone was using nailed-up connections (and they used
IPsec) and so the need to dynamically discover servers did not arise. 

Ciao
Hannes

-----Original Message-----
From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf
Of ext Sam Hartman
Sent: Monday, November 07, 2011 3:20 PM
To: Josh Howlett
Cc: abfab@ietf.org
Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt

>>>>> "Josh" == Josh Howlett <Josh.Howlett@ja.net> writes:

    >> 
    >> On 11/06/2011 09:56 PM, Sam Hartman wrote:
    >>>>>>>> "Josh" == Josh Howlett <Josh.Howlett@ja.net> writes:
    >>> 
    Josh> While Diameter supports proxies, it does not require them
    >>> for Josh> trust establishment and routing between federated
    >>> partners as Josh> in the RADIUS case.
    >>> 
    >>> what does this statement mean? I'm obviously missing some
    >>> important feature of Diameter, which is unsurprising because I
    >>> know very little about it.
    >> 
    >> I think Josh is saying that Diameter uses SRV records much like
    >> RADSEC.

    Josh> Yes, that kind of thing.

Yeah, but how does that help me without a trust relationship?
_______________________________________________
abfab mailing list
abfab@ietf.org
https://www.ietf.org/mailman/listinfo/abfab