[sipcore] Thoughts about draft-ietf-sipcore-sip-token-authnz-02.txt
worley@ariadne.com (Dale R. Worley) Sat, 13 July 2019 01:01 UTC
Return-Path: <worley@alum.mit.edu>
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 5407212004F for <sipcore@ietfa.amsl.com>; Fri, 12 Jul 2019 18:01:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.685
X-Spam-Level:
X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net
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 vsQdpRauEv8y for <sipcore@ietfa.amsl.com>; Fri, 12 Jul 2019 18:01:11 -0700 (PDT)
Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 620DB12000E for <sipcore@ietf.org>; Fri, 12 Jul 2019 18:01:11 -0700 (PDT)
Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-04v.sys.comcast.net with ESMTP id m6C4hiL9KUhOfm6PVhakra; Sat, 13 Jul 2019 01:01:09 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1562979669; bh=3FaOlKAn8cagEEZcuVSnDJCk+rrH17vIQeIHYbYU7pY=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=T5oKtnqNDAFXlcvE1a36+WDL8v3PHsl8KUf1ohl5hWjMxcIuZe1sVeQxwqOORksFh sbkPRL+n1cvb7ne+G17KzIhHMea3htxaWoWgH1TGJxi08ZR8uZ7KUwRJiLkn5bYcDg VLkigbYiY/sgaQgQpEVGBz7iuo3t7t/7ncIvaTRoRvErWOM3kCsXwaFzGgLsYD7vFg UAB9yKwaotPQ6I/5GFQIAqiqJFvAeA1pxjqctFWbg2pgy3HVZMC3+74/+dUIcZ1STW ABGaIAL8gR0uejaN1fbg/Pion5X5lerJvxq2L1fzQufHZ0e//WdF3t99U7p7SnCTw3 hUYmwJ/6OIl2Q==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-13v.sys.comcast.net with ESMTPA id m6PUhmngMa9P8m6PVhVQB2; Sat, 13 Jul 2019 01:01:09 +0000
X-Xfinity-VMeta: sc=0;st=legit
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 x6D116Ci021278 for <sipcore@ietf.org>; Fri, 12 Jul 2019 21:01:06 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id x6D115J0021275; Fri, 12 Jul 2019 21:01:05 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: sipcore@ietf.org
Sender: worley@ariadne.com
Date: Fri, 12 Jul 2019 21:01:05 -0400
Message-ID: <87zhlipx2m.fsf@hobgoblin.ariadne.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/72IjffZIrIkgD_x0oplzHdBpiJU>
Subject: [sipcore] Thoughts about draft-ietf-sipcore-sip-token-authnz-02.txt
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: Sat, 13 Jul 2019 01:01:15 -0000
I've finally gotten out from under a bureaucratic problem with my employer and taken a look at sipcore-sip-token-authnz and its e-mail thread. My, my... I haven't read the thread thoroughly, but I've at least skimmed every message up until some time yesterday. But I think I have reasonably well formulated the following observations. 1. I find the new draft considerably easier to understand than the older ones. I'm not sure why; as Christer notes, everything in it is in the older ones. But I suspect that the somewhat narrower scope of the new draft allows me to see the overall concept even when the details aren't particularly clear. So that's a significant advance. I don't see the current version as being near WGLC but rather as a good presentation of the high-level design concept. It's the point where you can start seeing the path to WGLC. 2. One somewhat philosophical point is that the current version presents the work as implementing two (somewhat generic) call flows. But of course, SIP isn't defined in terms of call flows that SIP entities implement by having telepathic knowledge of where they are in particular call flows, but rather in terms of specific internal states of SIP entities which cause them to respond in defined ways to incoming messages. The collective effect of these action specifications makes an unlimited number of useful call flows work. So in this case, we need to dissect each step of these call flows and lay out the specific behaviors that have to be executed by the participating entities. In addition, this is the place to discern which of these behaviors fit into the various existing patterns and structures of SIP. 3. One thing that's clear is that we're really defining a new authentication scheme, named "Bearer", which is used in coordination with an OAuth authorization server. Based on this, it's clear that the scheme can be used in any context any other scheme could be used, as long as the target supports it. This includes for authenticating to a UAS (e.g., a voicemail server) or to a proxy. And we get this functionality "for free"; we don't need to define any more machinery for these uses beyond what is needed to support REGISTER authentication. 4. The question arose on the mailing list whether Proxy-Authenticate is ever used. I know that the sipX family of PBXs uses it. The general pattern is that the proxy demands that the UAC authenticate itself, and then passes authenticated INVITEs to their destination UASs. The destination phones are configured to only accept requests from the IP address of the PBX. This allows a very simple authentication scheme at the UAS to be leveraged into more sophisticated authentication of all incoming requests by a more intelligent proxy. This structure also supports the standard SIP usage where the process of permitting an INVITE to flow *from* a UAC is not coupled to whether or not the UAC is registered. (Of course, a UAS can only *receive* an INVITE to its AOR if it is registered for that AOR.) The draft seems to presume that the ability to send INVITEs is implicitly controlled by whether the UAC has an active registration ... but that is not standard SIP. 5. If I understand it correctly, a SIP request is authenticated by an Authorization header containing the Bearer scheme and a valid access token. As others have noted, any device which can copy the access token can issue any request in the name of the token's user. This situation requires that the SIP messages be fully protected from eavesdropping and that a message containing such an Authorization header must never be handled by an untrusted entity. This is a particularly strict situation. The draft recognizes this and the Security Considerations section says The UAC MUST always make sure that it is communicating with the right registrar/proxy using TLS and proper validation of the server certificate and the identifier in that certificate to protect the access token in transit. However, this restriction is sufficiently different from current practice that it should also be mentioned in the earlier, "operational" sections. This situations sounded familiar to me ... I eventually realized that it is exactly the situation with HTTP Basic authentication. It's also the reason why SIP rejected using Basic authentication. We need a way to use OAuth authentication that has the property of Digest authentication that the values in the Authorization header are bound in some way to the particular request. It seems to me that there are a couple of ways out of this problem. a) Given that OAuth designates the token we are using as "bearer", it's possible that OAuth provides a different mode of operation with the needed properties. b) Use the access_token as essentially the "passwd" value in a clone of the Digest algorithm. This requires that the Authorized header has some other way of indicating to the authenticator what access_token it used. Presumably that information could be bundled into a parameter of the (authenticated user) "uri" parameter of the header. 6. One new UA behavior is where the UAC coordinates the process of the user providing his credentials, forwarding them to the authorization server, and receiving the tokens. I don't see any need to standardize how this is triggered and operates, other than that the contents of the HTTP POST and its response ([01]/[02] or [10]/[11]) need to be properly specified. I assume that these are specified by the OAuth specification, but we need to ensure that our draft clearly specifies whatever parameters are needed by the generic OAuth specification. The reason for being careful with this is that in order to ensure interoperability at the boundary between the UAC and the authorization server, their communication is not truly "out of scope of this specification" but rather "delegated by this specification to the OAuth specification". 7. Similarly for the conversation between the SIP authenticator and the authorization server. 8. Given that Bearer is a new authorization scheme, it doesn't directly demand any new UAC behavior regarding registration. But the REGISTER [12] may introduce a new behavior: Currently, a UAC can only REGISTER for a particular AOR; that AOR appears as the To and From URIs. But in this call flow, it's possible that the UAC does not know which AOR it will eventually attempt to register to, only the SIP domain. So we may need to extend RFC 3261 to provide a "generic" REGISTER form, whose purpose is not to obtain a registration but rather to provoke a 401 response containing the authz_server value that the UAC needs, REGISTER sip:biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 20 To: <sip:biloxi.com> From: <sip:biloxi.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:192.0.2.4> Once the user is done with the OAuth handshake, the UAC will know the AOR to register to and can send a normal REGISTER. 9. It seems to me that there should be a stated constraint that the registrar must not issue a registration that is valid for longer than the future validity of the access_token that is used to authenticate the registration request. Presumably this is straightforward to implement in an OAuth context. 10. Both call flows show the UAC obtaining a refresh_token from the authorization server but there is no illustration of the operations that the UAC will do to use the refresh_token to obtain an access_token with longer validity. It is probably worth illustrating this, as it is a different interaction that the authentication server must support. 11. In regard to the sip.token media feature tag, it's not clear that it is particularly useful. Presumably, if the authenticator of a request accepts the Bearer scheme for one of its realms, whenever it gives a 401/407 response, it will always include a WWW-Authenticate/Proxy-Authenticate header for the Bearer scheme and that realm, and that header will include an authz_server parameter. If the UAC does not accept Bearer for a particular realm, it will ignore such a header, so there is little cost of sending it to a UAC that does not support it. Dale
- [sipcore] Thoughts about draft-ietf-sipcore-sip-t… Dale R. Worley