Re: [Dime] Question on realm validity in answer messages

Jouni Korhonen <jouni.nospam@gmail.com> Fri, 09 May 2014 07:29 UTC

Return-Path: <jouni.nospam@gmail.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3ADA1A0206 for <dime@ietfa.amsl.com>; Fri, 9 May 2014 00:29:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_HLt12GnOJO for <dime@ietfa.amsl.com>; Fri, 9 May 2014 00:29:50 -0700 (PDT)
Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 10B091A01F8 for <dime@ietf.org>; Fri, 9 May 2014 00:29:49 -0700 (PDT)
Received: by mail-la0-f42.google.com with SMTP id el20so151478lab.1 for <dime@ietf.org>; Fri, 09 May 2014 00:29:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=EPgiMdQbHj+35nevK4lY5DcNlG2nFz3Z3maxi+pwIw8=; b=QpaVJf3iNX4eXD68QXdBfi91zUYiWivDYFnQKXFbSU3tYILjeT7DaOcBpgaol2jPof dUjr++esJyljeRGQ24b2UdpCDmQBCgh2NQtP+/KNtZchk/ujB5HQcUSvgTmJ/ROgxF8v gSMR/xkBLuQoUV7OfEJbLWMcDDllrI75xPjXVUtEtd81HUVjvm4cIPS1lzloAsMSxzHx 4MrQNIVDWJgwYXtprOB3Bkmkw7ugcO6nzzilAyH6b/ViA7mUKA+KmdnVxeiUTjldn+pw ahlFIGOJrWMr/I4ZNo4sxjwlYkjd1nqejLIWdgxHuxGXxy2IKM57fBJmloBCb/gbVKUU RHFA==
X-Received: by 10.152.20.137 with SMTP id n9mr701111lae.39.1399620584493; Fri, 09 May 2014 00:29:44 -0700 (PDT)
Received: from [192.168.250.244] ([194.100.71.98]) by mx.google.com with ESMTPSA id q4sm3686719lbh.20.2014.05.09.00.29.43 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 May 2014 00:29:43 -0700 (PDT)
Message-ID: <536C83E7.5060106@gmail.com>
Date: Fri, 09 May 2014 10:29:43 +0300
From: Jouni Korhonen <jouni.nospam@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Marco Stura <mstura@ooredoo.com>, "dime@ietf.org" <dime@ietf.org>
References: <0EFE155B2AF9B44A9537DA67801704F96B3341E2@ROCK5.qtel.ad.pri> <536BD60A.6070202@gmail.com> <0EFE155B2AF9B44A9537DA67801704F96B334D22@ROCK5.qtel.ad.pri>
In-Reply-To: <0EFE155B2AF9B44A9537DA67801704F96B334D22@ROCK5.qtel.ad.pri>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Znhoy4NrAWSvCD3QNaGC34wmqFw
Subject: Re: [Dime] Question on realm validity in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 May 2014 07:29:59 -0000

Hi

5/9/2014 9:31 AM, Marco Stura kirjoitti:
> Thank you Jouni and all folks that replied.
>
> I wanted to hear opinions without giving mine first. I agree that we cannot find any explicit specification language, but I think this kind of configurations are not really standard and are against the spirit of AAA.

There is one thing that kind of assumes that the realm is not to be 
changed. The duplicate detection is based on e-2-e identifier and the 
origin-host. So that thing may get confused if the answer messages are 
from a different realm than the request was sent to.

> If we think what AAA was invented for, it is all about communicating with the home server that is authoritative to authenticate/authorize the user. The home server shall match the user's home realm.  If we look at the definition of realm in RFC 6733:
>
> Realm
>
>        The string in the NAI that immediately follows the '@' character.
>        NAI realm names are required to be unique and are piggybacked on
>        the administration of the DNS namespace.  Diameter makes use of
>        the realm, also loosely referred to as domain, to determine
>        whether messages can be satisfied locally or whether they must be
>        routed or redirected.  In RADIUS, realm names are not necessarily
>        piggybacked on the DNS namespace but may be independent of it.
>
> Then further on in the RFC it is said that the ream may be derived from the NAI and then populated in the Destination-Realm. Alternatively one could use other mechanisms in the client to determine what realm is authoritative for the user, but whatever mechanism must not be dictated by the implementation of the server or servers composition, it must be a standard mechanism. Otherwise it will never be possible to implement things like roaming. One example is the NAI, another example is the IMSI derived home realm as defined in 3gpp TS 23.003.
>
> By definition there is only one realm that is authoritative, not many different realms (or domains). In my example the realm that is authoritative for the user is "sprealm", as the user belong to that. Therefore a configuration with servers belonging each to a different realm (none of the realm is actually matching the home realm) it's not what I would call a Diameter compliant implementation, as none of the servers can actually be said to serve the user's home realm. Furthermore, again in the spirit of AAA, the Destination-Realm AVP shall not be changed by agents as per diameter request routing processing defined in section 6.1.
>
> IMHO a Diameter compliant implementation would exactly look as the one described by David, which I report below:
>
> If all of the servers were in the same realm (say realmX), a conversation would work like this:
> - client sends message to Dest-Realm=realmX, (Dest-Host unspecified)
> - client realm-routing indicates the proxy can handle it and forwards to proxy.
> - based on lack of Dest-Host, proxy realm-routing table determines any of Servers 1-3 (all of realmX) can handle it.
> - the proxy selects a host in realmX (e.g., Server1) by any appropriate algorithm
> - e.g., Server1 answers the message with Origin-Host=Server1 and Origin-Realm=realmX
> - proxy transparently passes the Origin-Host=Server1 and Origin-Realm=realmX
> - if client needs to continue the session, the client makes subsequent requests to Dest-Host=Server1 and Dest-Realm=realmX
>
> What I described in my original email it's actually an horrible hack of Diameter :-) Do you agree?

Yes.

>
> BR,
> Marco
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
> Sent: Thursday, May 08, 2014 10:08 PM
> To: dime@ietf.org
> Subject: Re: [Dime] Question on realm validity in answer messages
>
>
> Your load balancer is misbehaving. Unfortunately you don't find any exact specification language to prohibit the proxy vendor doing this.
>
> - Jouni
>
>
>
> 5/8/2014 8:44 AM, Marco Stura kirjoitti:
>> Dear all,
>>
>> I'm facing the following situation.
>>
>> |----------------------------
>> SPrealm--------------------------------------------------|
>>
>>
>> _----------- Server 1(realm a)
>>
>>
>>                                    _
>>
>>
>> _
>>
>> Client ------------------ Proxy(SPrealm) ---------------- Server
>> 2(realm b)
>>
>>
>> _
>>
>>
>>                                                         _
>>
>>
>> _
>>
>>
>> ---------- Sever 3 (realm c)
>>
>> The implementation is such that the Proxy is load balancing by
>> selecting the internal Server where the subscriber data are
>> provisioned, based on user identity.
>>
>> The Client is sending an application specific authorization request to
>> the Proxy for NAI user@SPrealm, Destination-Realm == SPrealm.
>>
>> The Proxy selects e.g. Server 2 based on user@SPrealm and send the
>> request there changing the Destination-Realm to realm b.
>>
>> Server 2 processes the request generates an answer and send it to the
>> Proxy with Origin-Host == server2@realm b, Origin-Realm == realm b.
>>
>> The Proxy forward the answer to the Client, that receives a successful
>> authorization answer from a realm that is different from the one
>> supposed to serve the user (as in the NAI).
>>
>> The client terminates the session with STR to Destination-Host ==
>> server2@realm b, Destination-Realm == realm b, Termination-Cause ==
>> Diameter_bad_answer
>>
>> The Proxy and the Servers are part of the same implementation, which
>> apparently requires this kind of configuration to work.
>>
>> In RFC 6733 (or RFC 3388) it is not explicitly stated how to deal with
>> cases where a successful authorization answer is coming from a server
>> located in a different realm than the home realm of the user (as per NAI).
>>
>> However, to say the least, this configuration is quite bizarre and the
>> client IMHO is right to terminate the session as this behavior may
>> looks to the client like an answer from a malicious node. But I don't
>> remember any discussion on this aspects back at the Diameter protocol
>> development time.....
>>
>> Any opinion on this scenario?
>>
>> BR,
>>
>> Marco
>>
>>
>> ----------------------------------------------------------------------
>> --
>>
>> The information in this email and any attachments thereto may contain
>> information that is confidential, protected by intellectual property
>> rights, and may be legally privileged. It is intended solely for the
>> addressee(s). Access to this email by anyone else is unauthorized. Any
>> use, disclosure, copying, or distribution of the information contained
>> herein by persons other than the designated addressee is unauthorized
>> and may be unlawful. If you are not the intended recipient, you should
>> delete the message immediately from your system. If you believe that
>> you have received this email in error, please contact the sender. Any
>> views expressed in this email and its attachments are those of the
>> individual sender except where the sender expressly states them to be
>> the views of Ooredoo.
>>
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>
> ________________________________
>
> The information in this email and any attachments thereto may contain information that is confidential, protected by intellectual property rights, and may be legally privileged. It is intended solely for the addressee(s). Access to this email by anyone else is unauthorized. Any use, disclosure, copying, or distribution of the information contained herein by persons other than the designated addressee is unauthorized and may be unlawful. If you are not the intended recipient, you should delete the message immediately from your system. If you believe that you have received this email in error, please contact the sender. Any views expressed in this email and its attachments are those of the individual sender except where the sender expressly states them to be the views of Ooredoo.
>