IETF Logo Mail Archive

Re: [radext] RFC 5090 RADIUS client

Yehoshua Gev <yoshigev@gmail.com> Thu, 12 July 2012 09:44 UTC

Return-Path: <radext-bounces@ietf.org>
X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org
Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1122C21F876C; Thu, 12 Jul 2012 02:44:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342086242; bh=M8YjZ4Pza4PCh8FmXxosVUCW6MK27Yzh2ebzSxKXsz4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=o92jFFVrKoPSteyHgJwTsDinDBXAwt5V45laYQqqrRnTEEH1DpxUh3FafvZdg8L3Y YuWXEPEEssHYQy/vMwiDjSEZ6O+9aqZ+ILTtycOQ3YjQe+9KCUkzVlFnMscPY9FGY/ DzsiDITo6U4oS+UkUUBDl+Qxfqc3NgNaO2oVRRbg=
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3364621F876C for <radext@ietfa.amsl.com>; Thu, 12 Jul 2012 02:44:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 Nd7kfjYUj6Q8 for <radext@ietfa.amsl.com>; Thu, 12 Jul 2012 02:44:00 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8F82221F8766 for <radext@ietf.org>; Thu, 12 Jul 2012 02:44:00 -0700 (PDT)
Received: by obbwc20 with SMTP id wc20so3239669obb.31 for <radext@ietf.org>; Thu, 12 Jul 2012 02:44:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6LgUZ8QdJjS4eMMqumW9ZIHCUTPY+8bHVyoPd3m7sqQ=; b=BIZdOxeqJcEkYibiS00u5qGRMYr5auNZ4UOnJG+M4A1w3i/rgqdB7NfgF3FAoMCfd7 DwQilN089ltO25ZxakI07w8zd2jpwLt2DrxBQVXHKda4edgp+l9MebntTHGS4DJc10lZ mCEx9etw11VNFUQnXlIVRoeU1YcbZDYl7DrA4sjVjqJX+bUiuWjnMEpHTHWM2J+8sZlP uwBT+uE6R7M7mXZxzjmSwXUwXsdp0omek6ux+gs+TdnOL90Y5u+Zeoorcfv0rdvzBOPP bAS43f4tJdxwOqVPJNRJmZzm6l7bFlzJsxuAcczYhdQ3dgIVFalPnjfUwYpf+fNt4IT3 UP2g==
MIME-Version: 1.0
Received: by 10.60.25.6 with SMTP id y6mr54724825oef.42.1342086273108; Thu, 12 Jul 2012 02:44:33 -0700 (PDT)
Received: by 10.60.120.74 with HTTP; Thu, 12 Jul 2012 02:44:32 -0700 (PDT)
In-Reply-To: <4FFDA6DF.7040403@deployingradius.com>
References: <CAF_j7ybJ8yK-mrFr=zaJEVpsAHmfxiauYh4Atwv=aGuXdNTY-Q@mail.gmail.com> <4FFDA6DF.7040403@deployingradius.com>
Date: Thu, 12 Jul 2012 12:44:32 +0300
Message-ID: <CAF_j7yYKJ8-j9fw4598NUyYsU4w5mE-+CRYBxq9ocx4WmRYANQ@mail.gmail.com>
From: Yehoshua Gev <yoshigev@gmail.com>
To: Alan DeKok <aland@deployingradius.com>
Cc: radext@ietf.org
Subject: Re: [radext] RFC 5090 RADIUS client
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: radext-bounces@ietf.org
Errors-To: radext-bounces@ietf.org

Thanks.
So the client would have to store the State attribute value until
receiving the new INVITE?

Yehoshua

On Wed, Jul 11, 2012 at 7:16 PM, Alan DeKok <aland@deployingradius.com> wrote:
>
> Yehoshua Gev wrote:
> > I hope that someone could answer some questions I have encountered with
> > when designing a SIP server supporting RFC 5090.
>
>   The implementation status of RFC 5090 is poor.  i.e. most
> implementations still use the format define in
>
>   doc/rfc/draft-sterman-aaa-sip-00.txt
>
>   I would suggest surveying RADIUS servers for their support of RFC
> 5090, versus their support of that draft.
>
> > 3. Statefulness
> > The RFC does not state whether the RADIUS client (HTTP-style server) can
> > work without keeping state.
> > Especially that it must respond with the State attribute in subsequent
> > Access-Request (section 5).
> >
> > If I understand the digest authentication scheme correctly, I believe
> > that the opaque directive is used for state.
> > Can opaque be used to store the State attribute?
>
>   No.  The State attribute is separate, and must be treated as separate.
>
> > May the RADIUS client modify the opaque directive, to include the both
> > Digest-Opaque and State attributes?
>
>   I would suggest "no".
>
>   Alan DeKok.
_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

v2.23.0 | Report a Bug | By Email