Re: [sipcore] Draft new: draft-holmberg-sipcore-auth-id-00

worley@ariadne.com (Dale R. Worley) Wed, 29 October 2014 21:35 UTC

Return-Path: <worley@ariadne.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96531A90B5 for <sipcore@ietfa.amsl.com>; Wed, 29 Oct 2014 14:35:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 rLtqE2XdNm1z for <sipcore@ietfa.amsl.com>; Wed, 29 Oct 2014 14:35:51 -0700 (PDT)
Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 749DA1A90B1 for <sipcore@ietf.org>; Wed, 29 Oct 2014 14:35:51 -0700 (PDT)
Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-01v.sys.comcast.net with comcast id 99bc1p0022VvR6D019bqvD; Wed, 29 Oct 2014 21:35:50 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-19v.sys.comcast.net with comcast id 99bp1p00D1KKtkw019bqyD; Wed, 29 Oct 2014 21:35:50 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s9TLZmsI018273; Wed, 29 Oct 2014 17:35:48 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s9TLZmm1018272; Wed, 29 Oct 2014 17:35:48 -0400
Date: Wed, 29 Oct 2014 17:35:48 -0400
Message-Id: <201410292135.s9TLZmm1018272@hobgoblin.ariadne.com>
From: worley@ariadne.com
Sender: worley@ariadne.com
To: Christer Holmberg <christer.holmberg@ericsson.com>
In-reply-to: <7594FB04B1934943A5C02806D1A2204B1D4D1148@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com)
References: <7594FB04B1934943A5C02806D1A2204B1D4CC977@ESESSMB209.ericsson.se> <201410272115.s9RLFV0j004631@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D4CF47D@ESESSMB209.ericsson.se> <201410281520.s9SFK2gC007233@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D4D1148@ESESSMB209.ericsson.se>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414618550; bh=fQynsBX3/a7WrxbvNMKC/vO9xz0gwQHsO/5HANgzWnU=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=pTHXc/FkAgYsXitrvEGM11u98j1vZ7NmAaR87ZVg0WRB3LT1uNCQS3VwkpKfohQnD 8DJeQdPTIq3BMSnSkN5UtpSzoGWK3iwJ/06tOK9EZ0xWxhQfP3avyguSgoIYRiEEA6 N+bM4WlSQSIO6G7F4EhA8KUucFSpoLrLkDiogjk6SrcpMkWeJOUEl+rHv/U2Hbf4yW Eu19Hzu2ZHVVi281yMT6rQ2qH05z34LdGsn8BG5Vnnz42F/o+FdI4tqNPt2bGIj0Dk aQlZoIBt/GAf45j9hebeGBSg4ZkaDLACz0Q+gf9Yd7zf753QhVlSXM9cZuGZ+MIXUm 4jI26d9vaotpA==
Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/aMgb7iGRH6hqPiX-wZDonofhqOE
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-auth-id-00
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Wed, 29 Oct 2014 21:35:53 -0000

> From: Christer Holmberg <christer.holmberg@ericsson.com>

> The function is to provide the authorization server identity to the
> S-CSCF (registrar). The S-CSCF MAY use that information when
> authorizing a user. For example, it can check whether the
> authorization server is authorized to provide IMS credentials to the
> user.

When you say "provide the authorization server identity", so you mean
"provide the identity of the authorization server"?  And does that
mean that registrar/S-CSCF will use that as an input to its
authorization check (as basically a string, much like the username and
realm) or is it the DNS name of an authorization server that the
registrar is supposed to query to check the validity of the
credentials?

I think that you mean the former rather than the latter.

In that case, in what way does authorization-entity differ from the
username and realm?

> > I assume that you intend to extend the set of SIP authorization
> > models; it's necessary to describe, at least in outline, what the
> > new authorization model is and how "authorization-entity" is used
> > in it so people can tell whether they want to use it in their SIP
> > implementations and how they would do so.
> 
> The way the IMS core authorizes users as such is not changed. 

OK, but is the way that IMS core authorizes users different from the
usual SIP digest model?  If so, documenting that authorization method
could be useful for broader SIP usage.

> As always, we need to decide whether there is any interest for this
> outside 3GPP. But, I am happy to provide more
> information/clarification.

Granted.  But to determine that, people outside of 3GPP need to know
what the mechanism does, and that's not very clear yet.

Dale