Re: [tram] HA1 vs HA1b with TURN

Oleg Moskalenko <mom040267@gmail.com> Wed, 21 October 2015 21:12 UTC

Return-Path: <mom040267@gmail.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCC41B30B1 for <tram@ietfa.amsl.com>; Wed, 21 Oct 2015 14:12:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.15
X-Spam-Level:
X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001] autolearn=no
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 NGuxRjoEHMxh for <tram@ietfa.amsl.com>; Wed, 21 Oct 2015 14:12:53 -0700 (PDT)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (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 9FAF61B30B9 for <tram@ietf.org>; Wed, 21 Oct 2015 14:12:52 -0700 (PDT)
Received: by wicfx6 with SMTP id fx6so109332200wic.1 for <tram@ietf.org>; Wed, 21 Oct 2015 14:12:51 -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=jQNZ6X2uqHjr0+v9iFbHUfXB/mHCO7ULcMMxwCNT8iw=; b=XjoLl4iP+/L75impYQraTbKkWqb0az5hClYFGb1ClEjqF6Bg5pjZEo8RFZNyX0t46B N9UlkCfxPIkb2/FM4pT+4ieaw88wYNNTjY67ltsY7P+Ow58kYdnLWfiuNpcIdTwNqLWv V5xrpClj9KlsgMfufcJbclcS/Fg65pleKCEv+wJYBCo8VmIZns7VHXFBWLVMZUN9qtNc h2Onk9HtsJQV2WWfYZA38FJQ97oyzEf0fNAK+IdPvW9XmRD7GGCOKEJUeLBpRfg7WL0q D9t0vfPXs9224bQRsrlRgjbvcnit43rgErc2YoyXGPzFOdEUqgnuybj0/bzhoBP33138 XOTA==
MIME-Version: 1.0
X-Received: by 10.180.39.178 with SMTP id q18mr12985441wik.57.1445461971201; Wed, 21 Oct 2015 14:12:51 -0700 (PDT)
Received: by 10.194.178.162 with HTTP; Wed, 21 Oct 2015 14:12:51 -0700 (PDT)
In-Reply-To: <5627F681.3010601@pocock.pro>
References: <5627F681.3010601@pocock.pro>
Date: Wed, 21 Oct 2015 14:12:51 -0700
Message-ID: <CALDtMr+mDth+faY+vtNVvg7m66Aa4RXzDdYic79iG2uZLQsRLA@mail.gmail.com>
From: Oleg Moskalenko <mom040267@gmail.com>
To: Daniel Pocock <daniel@pocock.pro>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tram/8Amd2nVKfI_hMqJebzYwnGOXOb4>
Cc: "tram@ietf.org" <tram@ietf.org>
Subject: Re: [tram] HA1 vs HA1b with TURN
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Oct 2015 21:12:54 -0000

Hi Daniel

please see below:

On Wed, Oct 21, 2015 at 1:33 PM, Daniel Pocock <daniel@pocock.pro> wrote:
>
>
> I've been working with a few projects that use the "HA1b" for DIGEST and
> HMAC, e.g.
>
> HA1 = H(user:realm:password)
>
> HA1b = H(user@domain:realm:password)
>     where domain (sometimes) == realm
>
> When a client is configured (user enters their SIP or XMPP address and
> their password for the first time), the client doesn't really know if it
> should use the HA1 or HA1b approach.  Many default to HA1 but give the
> user the option to manually configure an auth username.
>
> Furthermore, when a SIP client sends a request, the request includes
> things like a request URI, From and To headers that allow the server or
> proxy to work out which realm to challenge with (if it supports more
> than one realm).  The initial request to a TURN server doesn't give such
> clues, consequently, the TURN server typically just has a single realm.
>  RFC 5389 s10.2.1.1 specifies that the client should not send username
> or realm values with the first request to the server.  It is in these
> scenarios that HA1b can be particularly useful for virtual hosting on a
> single TURN server on a single UDP port.
>
> Therefore, a few things come to mind:
>
> - could the client send some attribute in the first request (RFC 5389
> s10.2.1.1) to inform the TURN server about the full username@domain?

there is ORIGIN draft:

https://tools.ietf.org/html/draft-ietf-tram-stun-origin-06

that is the attribute that you are looking for - it allows building a
server that supports multiple realms. I am not sure about its future,
but coturn supports that functionality.

Also, there is a third-party authorization RFC 7635 that also allows
multiple realms, but it is rather different from the usual scheme.

But the TURN server is never using HA1b, that is not a standard
feature. With ORIGIN, you may have same user names in different
realms, and those users exist independently because all data and the
authentication are using realm as part of the key.

>
> - could the TURN server challenge include some attribute telling the
> client to use the HA1b approach?

Not in the current scheme.

>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram