IETF Logo Mail Archive

[Dime] RAR Message with possible ReAuth-Reqiest_type

"Satyanarayana Danda (sdanda)" <sdanda@cisco.com> Sat, 23 November 2013 08:06 UTC

Return-Path: <sdanda@cisco.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 BACE91AE154 for <dime@ietfa.amsl.com>; Sat, 23 Nov 2013 00:06:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.025
X-Spam-Level:
X-Spam-Status: No, score=-10.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 WCIGrWhAQmiv for <dime@ietfa.amsl.com>; Sat, 23 Nov 2013 00:06:56 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 7C29A1AE13E for <dime@ietf.org>; Sat, 23 Nov 2013 00:06:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9150; q=dns/txt; s=iport; t=1385194009; x=1386403609; h=from:to:subject:date:message-id:mime-version; bh=gxibfxhPZ5AR85t2IHorooDjfs8JXU01rcr9n1Z1c30=; b=mLEGyBBzrtXMX2lDlqmRl67AJBQW8XAK9OskgOxIf5bJOwrf77FkOjNH FPxyTjRm22O6ZJLj/jFHjNBitAHNkKpuU7WxfOdhmhxlIXO/iNS19aME9 wTnW3n5i8wuT4klrvGT0z0uqsjTWezFPh3BhPGq0Pp0asNwhgHPFJ/uBs A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlYFAHRhkFKtJV2Y/2dsb2JhbABZgkNEOFO8HYEZFm0HgicBBC1eASpWJgEEG4d5oG2gAReOMiSDWIETA6Jfh0eDKIFqJBw
X-IronPort-AV: E=Sophos;i="4.93,757,1378857600"; d="scan'208,217";a="1691947"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP; 23 Nov 2013 08:06:49 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAN86mrp016490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dime@ietf.org>; Sat, 23 Nov 2013 08:06:48 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Sat, 23 Nov 2013 02:06:48 -0600
From: "Satyanarayana Danda (sdanda)" <sdanda@cisco.com>
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: RAR Message with possible ReAuth-Reqiest_type
Thread-Index: Ac7oIvOUceYo/p9gSMuOeAA17B6+vA==
Date: Sat, 23 Nov 2013 08:06:48 +0000
Message-ID: <E06F3B652F60A4409C49D8E840BEEC921E46790E@xmb-rcd-x14.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.142.106.121]
Content-Type: multipart/alternative; boundary="_000_E06F3B652F60A4409C49D8E840BEEC921E46790Exmbrcdx14ciscoc_"
MIME-Version: 1.0
Subject: [Dime] RAR Message with possible ReAuth-Reqiest_type
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: Sat, 23 Nov 2013 08:06:58 -0000

Hi folks,

I am looking for a case where Re-Auth-Request is sent to NAS with subscriber credentials captured via web Portal (web-logon) case.
>From RFC 6733, we do have two options set in ReAuth-Request-Type AVP of the action expected. From my use-case standpoint, I would like to inform
NAS to take AUTHENTICATE_ONLY action by sending AA-Request for credential validation.
Since this is not specified as part of this RFC, do you see this needs to be addressed?

Please let me know in case you want more details on the use-case.

Thanks
Satya

<snip>
Re-Auth-Request-Type AVP



   The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and

   is included in application-specific auth answers to inform the client

   of the action expected upon expiration of the Authorization-Lifetime.



   If the answer message contains an Authorization-Lifetime AVP with a

   positive value, the Re-Auth-Request-Type AVP MUST be present in an

   answer message.  The following values are defined:



   AUTHORIZE_ONLY 0



      An authorization only re-auth is expected upon expiration of the

      Authorization-Lifetime.  This is the default value if the AVP is

      not present in answer messages that include the Authorization-

      Lifetime.



   AUTHORIZE_AUTHENTICATE 1



      An authentication and authorization re-auth is expected upon

      expiration of the Authorization-Lifetime.
</snip>

v2.23.0 | Report a Bug | By Email