IETF Logo Mail Archive

Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply

Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> Sun, 26 April 2020 15:58 UTC

Return-Path: <rifaat.ietf@gmail.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A76F3A03EC for <sipcore@ietfa.amsl.com>; Sun, 26 Apr 2020 08:58:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 q1GYSalu3VZ2 for <sipcore@ietfa.amsl.com>; Sun, 26 Apr 2020 08:58:45 -0700 (PDT)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 923DF3A0A34 for <sipcore@ietf.org>; Sun, 26 Apr 2020 08:58:45 -0700 (PDT)
Received: by mail-il1-x130.google.com with SMTP id r2so14359184ilo.6 for <sipcore@ietf.org>; Sun, 26 Apr 2020 08:58:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CbKCgwrqUO4CZ7xvR7ovXjF8XbiDKXD1sm2wKmOXCzA=; b=dW01RjCcQ7a17Xdggt9nnpF1iLYSnZHJHtza7IZzhGUmvlMPDr3JWTan0CW9XOZ7Hf bF5bOqCAJCQZhKCY76qhw3J51P8a01nSqvI2+XMERTI434ws203QYGIIbZgN40jZ5PCj yhZMZvWfWMFmoCU+CPzo1NaCqAAMKTOoZ6jt5+HQLne5p8mYt0ATM5DE+bXLXTLEuVtu +oGMtrL/UZGLaMsmG3sB5qjxAUinPbOepxJv12b9WSqtUJLVM0B14leoO0u9vQMm3XJP FKnX8RGTQ9MBlJ7lgcQfp4JQvdBYxfqmjzGS1Msk3IB4aeiss1yLaPw5oHJDRxLNq796 4WSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CbKCgwrqUO4CZ7xvR7ovXjF8XbiDKXD1sm2wKmOXCzA=; b=AMHqhknBCGj34qTMRQogfuJW/z2/jvaH7eJ7ONIYov+7MefipBOlpGIIKxOcqqUnmW m0H/+vz5qXOfdt8eTKqD9sWsWWYmWbCcq2vSTFd25AX2sFyEJA6DD9v8m/UNdG9xxuLz M9Vne3dV8OhliNahf/73fvIZA1Sk0hrNHIuje+YU5gD5T2rcEDGnfSUIasbG8I+YD6sf HxGll4wmXM908emWphcnNGmatwEmAAPf7m7euRs4fEP9pgSffyiIkCuENCMa7TXBMdYT PFt7Dq5b9YWTvIjhlnoOnlNrcdde65UQMYQCgbonbkCjcULzCRREsqqOhWcTnzy3BIdj LvEQ==
X-Gm-Message-State: AGi0PuYHi0CDjWN4vT/9AINqk+xqWxoA3OYnVtibqYgL5/av/cUOV//w ioteCDJcbeftY3QrGyS7KLIP5L0vtsFhFGkeCUE=
X-Google-Smtp-Source: APiQypI+YGZ3dfyL+xiKxzM4Vh9/q772yfu0sTsF+Mwjlthss3dL2nGseVYLqN2Tco7BTwVafOF9Urz1GXarWRETekU=
X-Received: by 2002:a92:d3c5:: with SMTP id c5mr17750304ilh.73.1587916724723; Sun, 26 Apr 2020 08:58:44 -0700 (PDT)
MIME-Version: 1.0
References: <158766991009.32224.6031347936963900326@ietfa.amsl.com> <CAGL6epJR916uMf-eeihvRyZRD3u-CR73v=C0pRGmbCi_tmbPEw@mail.gmail.com> <6EBE66ED-E26B-4B92-B776-1F799E095DB7@ericsson.com> <ddffc5ff-4f7d-072e-d807-6ab5a9adc807@alum.mit.edu>
In-Reply-To: <ddffc5ff-4f7d-072e-d807-6ab5a9adc807@alum.mit.edu>
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Sun, 26 Apr 2020 11:58:34 -0400
Message-ID: <CAGL6epJ+s7d7fNB8NiZQhicuxjvZbnjLnZN6OSMb9LsnXF3S3Q@mail.gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Cc: SIPCORE <sipcore@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004f67f505a433ac4e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/xKR4rEQJCVEeO_UQjb-omxyrJU8>
Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Apr 2020 15:58:52 -0000

Paul,

What you described is the theory; have you seen this deployed in practice?

Regards,
 Rifaat


On Sun, Apr 26, 2020 at 10:28 AM Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> On 4/25/20 7:27 PM, Christer Holmberg wrote:
> > Hi Benjamin,
> >
> >>> Section 2.3 states that:
> >>>
> >>>     When a proxy wishes to authenticate a received request, it MUST
> >>>     search the request for Proxy-Authorization header fields with
> 'realm'
> >>>     parameters that match its realm.  It then MUST successfully
> validate
> >>>
> >>> https://tools.ietf.org/html/rfc7235#section-4.4 suggests that it is
> not
> >>> expected to have a sequence or list of Proxy-Authorization header
> fields
> >>> present in a single request that are intended to be interpreted by
> different
> >> proxies.  Is this text compatible with that part of RFC 7235?
> >
> > RFC 3261 allows multiple Proxy-Authorization header fields.
>
> * Here is a situation when they come into play:
>
> UAC ----- P1 ------- P2 ------- UAS
>
> On the first request from UAC toward UAS, P1 challenges with a
> Proxy-Authenticate containing realm P1.
>
> UAC retries, including Proxy-Authorization for realm P1. P1 is happy and
> passes the request along. P2 challenges with realm P2.
>
> UAC retries again. It adds Proxy-Authorization for realm P2, but also
> including the credentials for P1. P1 is happy and passes the request
> along. P2 is also happy and passes the request along to UAS.
>
> Note that UAC must *remember* to include the P1 credentials in the
> second retry because there is no Proxy-Authenticate for P1 in the 407
> from P2. Similarly, in future messages toward UAS the UAC should
> remember to include credentials for P1 and P1.
>
> * A more complex case is:
>
> UAC ----- P1 -|------ P2 ------ UAS-A
>                |
>                |------ P3 ------ UAS-B
>
> On the first request from UAC toward UAS, P1 challenges with a
> Proxy-Authenticate containing realm P1.
>
> UAC retries, including Proxy-Authorization for realm P1. P1 is happy.
> If it does parallel forking then it passes the request along to both P2
> and P3.
>
> P2 challenges by returning a Proxy-Authenticate for realm P2.
>
> P1 buffers that response while awaiting a response from P3.
>
> P3 challenges by returning a Proxy-Authenticate for realm P3.
>
> P2 passes a response back to UAC with Proxy-Authenticates for realms P2
> and P3.
>
> UAC retries again. It adds Proxy-Authorization for realms P2 and P3, but
> also including the credentials for P1. P1 is happy and passes the
> request along to both P2 and P3.
>
> P2 finds its Proxy-Authorization and happily passes the request along to
> UAS-A.
>
> P3 finds its Proxy-Authorization and happily passes the request along to
> UAS-B.
>
>         Thanks,
>         Paul
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>

v2.23.0 | Report a Bug | By Email