[sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 23 April 2020 19:25 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: sipcore@ietf.org
Delivered-To: sipcore@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E11B33A12BD; Thu, 23 Apr 2020 12:25:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-sipcore-sip-token-authnz@ietf.org, sipcore-chairs@ietf.org, sipcore@ietf.org, Jean Mahoney <mahoney@nostrum.com>, mahoney@nostrum.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.127.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <158766991009.32224.6031347936963900326@ietfa.amsl.com>
Date: Thu, 23 Apr 2020 12:25:10 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/ls6l21iQYGhaHrUCRvWCI6_ABE4>
Subject: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 23 Apr 2020 19:25:15 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-sipcore-sip-token-authnz-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I support Roman's Discuss. The "Bearer" authentication challenge includes the address (or name?) of an authorization server to contact to obtain tokens, as mentioned in multiple places in the document (noted in the COMMENT section). Our experience in the OAuth world has shown that several classes of vulnerabilities are possible when the client blindly attempt to use any provided AS, and that a whitelist of "allowed" or "trusted" ASes is needed for secure operation. I believe that the same is true for the SIP usage, and we should mention this requirement explicitly. Section 1.2 tries to apply the OAuth confidential/public client distinction to SIP UACs, but it does so in a non-analogous fashion: the OAuth distinction is for the client's ability to protect credentials that identify the client itself; the usage in this document refers to protecting *user* credentials and obtained tokens. I don't think that it's appropriate to invoke the OAuth terminology when using it for a different meaning. Both Public and Confidential OAuth clients are capable of providing the necessary protections for *user* credentials (though they are of course not guaranteed to do so), which leaves me unclear on what the intended requirements actually are. 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? Furthermore, I didn't find much guidance in 7235 or 3261 about when to include the "realm" parameter in Proxy-Authorization; do we want to give any guidance here? (That is to say, I almost didn't find where it was even defined as possible to do so...) I'm also not sure if we're attempting to profile RFC 6749 and always require a refresh token to be issued, or just have some editorial tweaks to make to avoid suggesting that we do have such a requirement (noted in the COMMENT). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1 The OpenID Connect 1.0 specification [OPENID] defines a simple identity layer on top of the OAuth 2.0 protocol, which enables clients to verify the identity of the user based on the Please make it clear that these are OAuth/OIDC clients, not SIP clients. Section 1.3 OAuth 2.0 doesn't require the issuance of a Refresh token, but the discussion here implies that for the SIP case there will always be a refresh token. If we're profiling 6749 in this manner, we should be more explicit about the requirement to issue refresh tokens. * ID Token: this token contains the SIP URI and other user-specific details that will be consumed by the UAC. nit: I don't think we should use the definite article in "the SIP URI" since we haven't discussed any such SIP URI usage yet. That is, we should say what it's used for, e.g., "a SIP URI associated with the user". * Structured Token: a token that consists of a structured object that contains the claims associated with the token, e.g. JWT as defined in [RFC7519]. nit: comma after "e.g.". * Reference Token: a token that consists of a random string that is used to obtain the details of the token and its associated claims, as defined in [RFC6749]. It doesn't technically have to be random (though in practice it should contain signficant random elements); "opaque" might be better wording. Section 1.4.1 Perhaps Figure 1 could include some indication that steps 5 and 6 are optional/do not always occur (in the case when the access token is a self-contained JWT)? In step [2], the registrar challenges the UA, by sending a SIP 401 (Unauthorized) response to the REGISTER request. In the response, the registrar includes information about the AS to contact in order to obtain a token. The UAC needs to have a preconfigured whitelist of acceptable ASes in order to avoid directing the user's credentials to malicious sites. The registrar validates the access token. If the access token is a reference token, the registrar MAY perform an introspection [RFC7662], as in steps [5] and [6], in order to obtain more information about the access token and its scope, per [RFC7662]. I think we could tighten up the normative language a bit here. In particular, the registrar MUST validate the token in some fashion; for reference tokens, the main ways to do that are either inspection or (essentially) being the party that issued the token in the first place. Otherwise, after the registrar validates the token to make sure it was signed by a trusted entity, it inspects its claims and acts upon it. I think we can also be more specific than "a trusted entity" -- in this flow, it looks like the registrar should know exactly which entity should have signed the token in question (for the user in question), and should not accept a signed token from a different entity that happens to be trusted to issue other tokens. Section 1.4.2 (Similarly, Figure 2 could note that steps 3 and 4 do not always occur, and the text about token validation should remain parallel between examples.) Section 2 I note that RFC 3261 explicitly disclaims any definition of authorization systems, which is not true for this document, given that OAuth is an authorization system :) Section 2.1.1 Required) response with a Proxy-Authenticate header field. If the WWW-Authenticate or Proxy-Authenticate header field indicates "Bearer" scheme authentication and contains an address to an authorization server, the UAC contacts the authorization server in order to obtain tokens, and includes the requested scopes, based on a local configuration (Figure 1). [whitelist of allowed ASes, again] The detailed OAuth2 procedure to authenticate the user and obtain these tokens is out of scope of this document. The address of the authorization server might already be known to the UAC via configuration. In which case, the UAC can contact the authorization server for tokens before it sends a SIP request (Figure 2). nit: I think that "in which case" functions as a conjunction, which makes this an incomplete sentence. The tokens returned to the UAC depend on the type of authorization server (AS): an OAuth AS provides an access token and refresh token [RFC6749]. The UAC provides the access token to the SIP servers to Again, this implies that refresh tokens are always issued; RFC 6749 is quite clear that "issuing a refresh token is optional at the discretion of the authorization server". authorize UAC's access to the service. The UAC uses the refresh token only with the AS to get a new access token and refresh token before the expiry of the current access token (see [RFC6749], section (New refresh token is also optional.) 1.5 Refresh Token for details). An OpenID Connect server returns an additional ID-Token containing the SIP URI and other user-specific details that will be consumed by the UAC. [same comment as above about "the SIP URI".] If the UAC receives a 401/407 response with multiple WWW- Authenticate/Proxy-Authenticate header fields, providing challenges using different authentication schemes for the same realm, the UAC selects one or more of the provided schemes (based on local policy) and provides credentials for those schemes. RFC 3261 seems to be written in a world that assumed that Basic and Digest are the only defined HTTP authentication schemes, and since it prohibits Basic, that there would only be one authentication challenge (type) possible. This text righly acknowledges that we are opening the field up and could have cases where multiple authentication schemes are possible; however, it goes even further and admits the possibility of using them simultaneously. It seems like this places an onus on us to give some indication of the semantics when multiple schemes are used at the same time. Do the authenticated identities need to match? Or are we asserting that both/all identities are consenting to the request in question? (If we don't have a concrete use case in mind, perhaps the "or more" is just opening a box that we don't need to open right now.) Section 2.1.2 access to it. Endpoints that support this specification MUST support encrypted JSON Web Tokens (JWT) [RFC7519] for encoding and protecting access tokens when they are included in SIP requests, unless some other mechanism is used to guarantee that only authorized SIP endpoints have access to the access token. I think we may want "MUST support" (always) and "MUST use, unless some other mechanism". I'd also suggest a quick note that TLS remains fine for protecting the UAC/AS interaction where the refresh token is used. Whatever is done, please harmonize with Section 5 that has essentially the same text. Section 2.1.3 Based on local policy, the UAC MAY include an access token that has been used for another binding associated with the same Address Of Record (AOR) in the request. Just to check: there's no real privacy considerations with such use, as its the same parties interacting and there are other identifiers (e.g., IP addresses) to confirm that it's the same client communicating to the server? Also, is it clear what will be done (new token request) when the MAY is not heeded? Section 2.1.4 The text here just talks about "a valid access token" and similar, without saying a whole lot about it being related in any way to the specifics of the authentication challenge. Is there something useful to say about, e.g., the token in question having been issued by the authorization server indicated in the challenge? Section 2.2 authorization credentials acceptable to it, it SHOULD challenge the request by sending a 401 (Unauthorized) response. To indicate that it is willing to accept an access token as a credential, the UAS/ Registrar MUST include a Proxy-Authentication header field in the response that indicates "Bearer" scheme and includes an address of an nit(?): I'd consider just making this a declarative statement, a la "the UAS/registrar includes a Proxy-Authentication header field with the "Bearer" scheme to indicate that it is willing to accept an access token as a credential" (but that wording is incomplete and would need to be fleshed out a bit more). authorization server from which the originator can obtain an access token. nit: "address of" an AS, does that mean bare IP address only or is a DNS name okay? [RFC7519]. If the token provided is an expired access token, then the UAS MUST reply with 401 Unauthorized, as defined in section 3 of [RFC6750]. If the validation is successful, the UAS/Registrar can continue to process the request using normal SIP procedures. If the validation fails, the UAS/Registrar MUST reject the request. Is "expired" the only case that should get a 401 vs. outright rejection, as stated here? Section 2.3 sending a 407 (Proxy Authentication Required) response. To indicate that it is willing to accept an access token as a credential, the proxy MUST include a Proxy-Authentication header field in the response that indicates "Bearer" scheme and includes an address to an [same comment as above about normative vs. declarative statement] Also, please keep the text parallel between sections -- this copy has at least one nit ("address to an" vs. "address of an"). Section 3 If an access token is encoded as a JWT, it might contain a list of claims [RFC7519], some registered and some application-specific. The I don't think there's a question of whether a JWT will contain a list of claims :) Maybe "If the access token is encoded as a JWT, it will contain a list of claims [RFC7519], which may include both registered and application-specific claims"? Section 4 This section claims to cover WWW-Authenticate. What specification will the SIP use of Bearer for Authorization operate under? challenge =/ ("Bearer" LWS bearer-cln *(COMMA bearer-cln)) side note: is there a mnemonic for the "cln" in "bearer-cln"? bearer-cln = realm / scope / authz-server / error / auth-param nit: realm is already included in auth-param, though I don't see a harm in calling it out explicitly. realm = <defined in RFC3261> auth-param = <defined in RFC3261> RFC 3261 defers to RFC 2617 (now obsoleted by 7235) for both of these; we could perhaps short-circuit the chain and say "defined in RFC 7235". Section 5 We should probably note that SIP makes much heavier use of proxies than is common in the web world of OAuth. I'm happy to see that some privacy considerations are being added in response to Barry's review. Section 8 I think RFCs 8252 and 8414 could be just informative.
- [sipcore] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk via Datatracker
- Re: [sipcore] Benjamin Kaduk's Discuss on draft-i… Paul Kyzivat
- Re: [sipcore] Benjamin Kaduk's Discuss on draft-i… Olle E. Johansson
- Re: [sipcore] Benjamin Kaduk's Discuss on draft-i… Christer Holmberg
- Re: [sipcore] Benjamin Kaduk's Discuss on draft-i… Benjamin Kaduk
- Re: [sipcore] Benjamin Kaduk's Discuss on draft-i… Christer Holmberg
- Re: [sipcore] Benjamin Kaduk's Discuss on draft-i… Olle E. Johansson
- Re: [sipcore] Benjamin Kaduk's Discuss on draft-i… Rifaat Shekh-Yusef
- Re: [sipcore] Benjamin Kaduk's Discuss on draft-i… Paul Kyzivat
- Re: [sipcore] Benjamin Kaduk's Discuss on draft-i… Christer Holmberg
- Re: [sipcore] Benjamin Kaduk's Discuss on draft-i… Christer Holmberg
- Re: [sipcore] Benjamin Kaduk's Discuss on draft-i… Paul Kyzivat
- Re: [sipcore] Benjamin Kaduk's Discuss on draft-i… Rifaat Shekh-Yusef
- Re: [sipcore] Benjamin Kaduk's Discuss on draft-i… Christer Holmberg
- Re: [sipcore] Benjamin Kaduk's Discuss on draft-i… Paul Kyzivat
- Re: [sipcore] Benjamin Kaduk's Discuss on draft-i… Rifaat Shekh-Yusef
- Re: [sipcore] Benjamin Kaduk's Discuss on draft-i… Christer Holmberg
- Re: [sipcore] Benjamin Kaduk's Discuss on draft-i… Paul Kyzivat
- Re: [sipcore] Benjamin Kaduk's Discuss on draft-i… Rifaat Shekh-Yusef
- Re: [sipcore] Benjamin Kaduk's Discuss on draft-i… Benjamin Kaduk
- Re: [sipcore] Benjamin Kaduk's Discuss on draft-i… Benjamin Kaduk
- Re: [sipcore] Benjamin Kaduk's Discuss on draft-i… Rifaat Shekh-Yusef
- Re: [sipcore] Benjamin Kaduk's Discuss on draft-i… Christer Holmberg