[kitten] AD review of draft-ietf-kitten-sasl-saml-ec-19
Benjamin Kaduk <kaduk@mit.edu> Wed, 02 September 2020 23:02 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1B93A1221; Wed, 2 Sep 2020 16:02:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 hSvPf7X5mYMU; Wed, 2 Sep 2020 16:02:51 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7BBE33A121B; Wed, 2 Sep 2020 16:02:48 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 082N2i5f012218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 2 Sep 2020 19:02:46 -0400
Date: Wed, 02 Sep 2020 16:02:43 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: draft-ietf-kitten-sasl-saml-ec@ietf.org
Cc: kitten@ietf.org
Message-ID: <20200902230243.GH16914@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/dNOr3BnynNrSevKxL-DI7uQ-Nus>
Subject: [kitten] AD review of draft-ietf-kitten-sasl-saml-ec-19
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Sep 2020 23:02:54 -0000
Hi all, Sorry for the slow turnaround on this one -- I had some background reading to do, in addition to the time spent actually reviewing the document. Some high-level comments before I get into the (sometimes very nitty) section-by-section notes: The ECP upstream document says: % It bears noting that the identification of the identity provider, the % determination of its location on the network, and the strong % verification of its identity in communicating with it (in the % following step) are all absolutely critical to the security of this % profile and the protection of the user's credentials. In particular, % the use of ordinary commercial web TLS infrastructure (of the form % common at the time of this specification's authoring) do not provide % strong guarantees, and sole reliance on that mechanism is discouraged. We may need to say something similar. Perhaps the biggest point that's unclear to me is to what extent the IdP has to change in order to use this mechanism. On the one hand, we see claims in Section 1 that "no changes to the SAML IdP are assumed apart from its support for the applicable SAML profile" and in Section 3 that "the IdP can remain unmodified". But in Section 4.7 it's at least implied that the IdP should be verifying the responseConsumerURL and/or AssertionConsumerServiceURL (which the -19 of this document is violating the current format requirements of ("absolute URL")), and in Section 5.3.1 we describe the <samlec:GeneratedKey> element wherein the IdP generates a pseudorandom string to be used for the session key between client/RP. So I think we need to have a more consistent story about what changes are or are not required by an IdP. I think we may want to be a bit more clear about the precise message encoding/boundaries -- what SAML/SOAP structure is included in which SASL container? We do slightly better at the GS2 side of things, but still reference the SASL mechanism for the inner contents of the GSS context tokens. We may also want to mention the recurring difficulty with channel bindings, namely that they only provide full protection if both legitimate endpoints (e.g., the application protocol specification) know that they will always be present on legitimate connections. If they are optional and whether or not to use them is negotiated in-band, a MITM that could intercept a non-channel-bound connection (which typically requires some other credential forgery or vulnerability) can drop the channel bindings entirely or present them to only one side without being detected by the channel binding verification. I'd like to walk through the mutual authentication mechanism in some detail, and I'm not entirely convinced that it provides what is expected from a GSS-API mechanism, at least. (I'll use the GSS-API terminology as I'm more familiar with it.) The initial client response can include a request for "mut" (or, presumably, the acceptor can spontaneously decide to sign its AuthnRequest). But what this triggers is for the acceptor to send a signed SOAP blob to the initiator over the as-yet-untrusted channel, but the initiator does not validate this signature itself. Instead, it's forwarded on to the IdP, and the IdP returns the relevant state in the <ecp:RequestAuthenticated> block. So at this point we know that the IdP says that some acceptor signed a request, and we're going to pass it the assertion from our IdP and assume that if the acceptor accepts that assertion, then it's the same one that produced the signature that the IdP validated. But is that guaranteed to be the case? What if a MITM pretends to be the acceptor, and gets a legitimate, signed, SOAP request from the real acceptor and passes it to the initiator? The IdP will validate it and produce an assertion, but when we send the assertion to the MITM we're not sending it to the real acceptor. Now, strong channel binding would detect the MITM, and if the IdP encrypted the assertion to the acceptor, that would prevent many misuses of the assertion by the MITM (but perhaps there is still some situation in which the MITM could just claim that everything succeeded?). I think we have to be careful that there is some proof of possesion of a key that involves an IdP validation step, in order to be able to say that *this mechanism* has authenticated the acceptor to the initiator. For the IdP-generated <GeneratedKey> this is somewhat straightforward, and we do require encryption of the assertion in this case. I'm not sure that we've placed enough restrictions on the "alternate key derivation mechanisms" in order to be able to say with confidence that they will do the same. However, it's not clear to me that the mechanisms discussed in Section 5.3 actually do key confirmation for the session key -- there doesn't seem to be any use of this key in the context establishment itself. Perhaps we need to fall back to the usual trick of MIC-ing some known string in order to validate the shared key and context? My comment on Section 4.7 about using the SASL name vs. an absolute URI as currently required by [SAMLECP20] is effectively a high-level comment, though I'm leaving it there for now to benefit from the additional context. Abstract [I note for pedantry's sake that both GSS-API and SASL in theory provide per-message services in addition to the authentication functionality that we mention, but acknowledge that these are not as widely used as the authentication functionality. We do mention the "security layer" part of SASL in the Introduction, but apparently not the message-protection functionality of GSS-API.] Section 1 identity provider (IdP). It includes a number of protocols, protocol bindings [OASIS.saml-bindings-2.0-os], and interoperability profiles [OASIS.saml-profiles-2.0-os] designed for different use cases. nit: "It" seems like it is referring to just the markup language, not the ecosystem around it, in the current wording. interactions. SASL is used by application protocols like IMAP, POP and XMPP [RFC6120]. The effect is to make authentication modular, so nit: While IMAP is listed as "well-known" at https://www.rfc-editor.org/materials/abbrev.expansion.txt, POP is not. And if we're going to expand it, we should give a reference as well, and if we're giving a reference for two of the three we ought to give a reference for all three. The Generic Security Service Application Program Interface (GSS-API) [RFC2743] provides a framework for applications to support multiple authentication mechanisms through a unified programming interface. (per above) so, maybe ", and additional optional cryptographic functionality". attribute information. Clients supporting this mechanism are termed "enhanced clients" in SAML terminology because they understand the Is there a good OASIS/SAML ref that discusses "ehnahced clients" in more detail that we could link to? I guess we do cite [SAMLECP20] at the end of the paragraph, and maybe that's enough. I'm not sure how effective Figure 1 is at conveying (what I understand to be) the way the setup works. It seems like the workflow is something like (1) "client wants to authenticate to RP, and starts the SASL negotiation", then (2) "RP needs to get some assertion from the IdP, and tells the client some details about what this assertion should contain", (3) "client makes a corresponding request to the IdP and gets a token back", before "(4) client encapsulates the IdP response within SASL for conveyance to the RP". Right now we are just showing the client doing (possibly independent) communication with IdP and with RP. Perhaps having two sets of arrows (e.g., single/double-lined or solid/dashed) for the SASL flow and the ("end to end") SAML flow would help show the linkage? Section 2 Note that RFC 8174 has an updated version of the BCP 14 boilerplate that we should use (to avoid literally every other reviewer telling us about it, if nothing else). The reader is also assumed to be familiar with the terms used in the SAML 2.0 specification, and an understanding of the Enhanced Client or Proxy (ECP) Profile (V2.0) [SAMLECP20] is necessary, as part of this mechanism explicitly reuses and references it. (side note: google found me http://docs.oasis-open.org/security/saml/Post2.0/saml-ecp/v2.0/saml-ecp-v2.0.html#:~:text=1%20Introduction-,The%20SAML%20V2.,the%20case%20of%20a%20browser. which talks about SSLv3 as included under the "TLS" umbrella. It may be worth updating that, and also excluding TLSv1.0 and TLSv1.1, which are on their way out in the IETF (that doc is next in my queue).) GSS-API mechanism, and then knowledge of GSS-API is essential. To faciliate these two variants, the references has been split into two parts, one part that provides normative references for all readers, and one part that adds additional normative references required for implementers that wish to implement the GSS-API portion. This mention of a split between GSS- and non-GSS references seems to be stale. Section 3 designed around HTTP [RFC7230] applications. They are not, however, limited to browsers, because it was recognized that browsers suffer from a variety of functional and security deficiencies that would be useful to avoid where possible. Specifically, the notion of an I feel like some browser vendors might take umbrage at this description :) Perhaps we should rephrase and attempt to be more precise about what makes generic browsers less applicable for SAML usage. 3. The client is then responsible for delivering the body of the SOAP message to the IdP it is instructed to use (often via configuration ahead of time). The user authenticates to the IdP (editorial) I guess "via out-of-band configuration" might be the more common RFC style. Also, it seems that in the general case there's no integrity protection on the SOAP message relayed from RP to IdP via the client, so the RP knows that it will have to carefully check the assertion(s) it receives from the IdP. I presume that we're just assuming the reader will already know this and don't feel a need to mention it again in the security considerations of this document. Note: The details of the SAML processing, which are consistent with the Enhanced Client or Proxy (ECP) Profile (V2.0) [SAMLECP20], are such that the client MUST interact with the IdP in order to complete any SASL exchange with the RP. The assertions issued by the IdP for the purposes of the profile, and by extension this SASL mechanism, are short lived, and therefore cannot be cached by the client for later use. (side note) I guess if we really wanted to enforce this the RP could generated a nonce and the IdP include it in the assertion, but that would be a bigger change from [SAMLECP20] that is arguably not warranted just for the needs of this mechanism. (That said, is there text in [SAMLECP20] that substantiates this claim about "short lived"? Some simple keyword searches aren't finding anything.) Note also that unlike an HTTP-based profile, the IdP cannot participate in the selection of, or evaluation of, the location to which the SASL Client Response will be delivered by the client. The Part of this seems inherent in our observation that the IdP is unchanged for implementing this mechanism. That, in turn, means that the IdP thinks it is giving us an HTTP location at the RP to which the client should deliver the response, and we are ignoring it, which would perhaps be worth noting explicitly. If the IdP was somehow SASL-aware, though, is there any discretion in where/how to convey the SAML response to the SASL server (to mimic the HTTP functionality where the IdP gives us the location to use)? It seems like there's only the one SASL channel to choose from... use of GSS-API Channel Binding is an important mitigation of the risk of a "Man in the Middle" attack between the client and RP, as is the use of a negotiated or derived session key in whatever protocol is secured by this mechanism. What about channel binding for the pure-SASL case? If the non-PLUS mechanism is susceptible to MITM, should we be defining it at all? (editorial) for the type of ladder diagram in Figure 2, a typical RFC style would only have the "target" arrowhead, e.g., "------------>", vs. the ">-------->" (etc.) that are used here. The double-headed arrow for (4) is, of course, quite important and should be retained. Section 4.2 The format of the initial client response ("initresp") is as follows: Is this an ad-hoc grammar or intended to match something like ABNF? I was initially confused by the "mut" symbol since it doesn't appear in the references, and only later figured out that it was a local shorthand used in constructing the initial response. The optional "gs2-authzid" field holds the authorization identity, as requested by the client. It seems like we should reference (e.g.) Section 3.4.1 of RFC 4422 to have something authoritative for the encoding of this field. digitally sign its SAML <AuthnRequest> message. The URN constant above is a single string; the linefeed is shown for RFC formatting reasons. (side note) I suppose we could reference RFC 8792 for this if we want, but since it's just the one line I don't see a huge need to do so. Section 4.4 The exact means of authentication to the IdP are also out of scope, but clients supporting this mechanism MUST support HTTP Basic Authentication as defined in [RFC7617] and TLS 1.3 client What's the motivation for picking Basic as MTI -- is there a large existing deployed base or something? I think I personally would rather say nothing about HTTP than say Basic (though it might be nice to promote SCRAM-SHA-256 if we could). Section 4.5 % The client MUST compare the AssertionConsumerServiceURL attribute from % the identity provider's <ecp:Response> SOAP header block to the % responseConsumerURL attribute found in the <paos:Request> SOAP header % block sent to the client by the service provider So the client still has to compare the (HTTP?) URLs even though we're not actually sending the response to that URL, okay. But, (1) does the SASL server need to be listening at that URL? (2) If so, why are we sending the response in-band in SASL instead of to that URL? Section 4.6 The SAML protocol exchange having completed, the SASL server will transmit the outcome to the client depending on local validation of the client responses. This outcome is transmitted in accordance with Perhaps it's worth a parenthetical "validation of the client responses (including the assertion conveyed from the chosen IdP)"? Validation of the assertion is pretty key to the security of the system, so might be worth reiterating even though it's a fairly fundamental SAML concept. Section 4.7 For compatibility with existing IdP and profile behavior, and to provide for mutual authentication, the SASL server MUST populate the responseConsumerURL and AssertionConsumerServiceURL attributes with its service name. As discussed in Section 5.6.2, most SASL profiles rely on a service name format of "service@host", but regardless of the form, the service name is used directly rather than transformed into an absolute URI if it is not already one, and MUST be percent- encoded per [RFC3986]. I think I want to see more justification for why we are diverging from the [SAMLECP20] requirement of an absolute URI here. It seems like in principle we could register a new URI scheme for this purpose and mavp the service name into the new scheme's structure. (Using "service@host" verbatim within the new scheme is probably not a great idea, as that doesn't really match up with the "userinfo" semantics as described in RFC 3986.) I do note with reassurance that [SAMLECP20] carefully does not require that the responseConsumerURL is an https: URI, which seems to allow this freedom. (Also, nit: [SAMLECP20] refers to it as an absolute URL, not URI, which is somewhat awkward for us.) The IdP MUST securely associate the service name with the SAML entityID claimed by the SASL server, such as through the use of SAML metadata [OASIS.saml-metadata-2.0-os]. If metadata is used, a SASL I'm having a hard time squaring this requirement on the IdP with the previous claims that "no changes to the SAML IdP are assumed" and "the IdP can remain unmodified". I'm not sure how this association could be considered "secure" if the IdP doesn't know the semantics that it's supposed to be validating. What am I missing here? At risk of repeating myself, I'll say explicitly that we should say what properties are required for this "securely associate the service name with the SAML entityID" and most likely give some (non-normative) examples of how it might be done. Section 5 The SAML Enhanced Client SASL mechanism is also a GSS-API mechanism. The messages are the same, but a) the GS2 [RFC5801] header on the client's first message is excluded when SAML EC is used as a GSS-API mechanism, and b) the [RFC2743] section 3.1 initial context token header is prefixed to the client's first authentication message (context token). nit(?): the "prefixed" perhaps not quite correct, since the initial context token header includes a length field that covers the mechanism-specific bits (i.e., our initial client response). Perhaps it's better to say that the initial context token header "is used for" the first message and say that the body is the same as for the SASL mechanism case. It's also a little weird to use "client's first message" and "client's first authentication message" as if to imply that they are different. The security context mutual_state flag is set to TRUE only if the server digitally signs its SAML <AuthnRequest> message and the signature and signing credential are appropriately verified by the identity provider. The identity provider signals this to the client in an <ecp:RequestAuthenticated> SOAP header block. (nit) It's probably worth a pass to try to be consistent about using "IdP" vs. spelling it out, etc. Section 5.1 We should probably mention the deleg_req_flag input to GSS_Init_sec_context() and how it relates to the setting of the "del" field in the initial client response. Upon receipt of an assertion satisfying this property, and containing a <SubjectConfirmation> element that the acceptor can satisfy, the security context may have its deleg_state flag (GSS_C_DELEG_FLAG) set to TRUE. I'm not sure when the deleg_state flag would not be set for a context that satisfies those conditions (and what logic would make that decision). Perhaps this should just be "will have"? Upon receipt of such a header block, the initiator MUST fail the establishment of the security context if it did not request delegation in its initial client response to the acceptor. It SHOULD signal this failure to the acceptor with a SOAP fault message in its final client response. We should probably also say that the GSS_Init_sec_context() output flag is set if it did request delegation (the previous discussion only covers the acceptor's output flag). Also, we might reference Section 1.2.9 of RFC 2743 from here, which has text essentially requiring this behavior: % However, the simple delegation control provided by GSS-API should % always be able to over-ride other mechanism-specific delegation % controls; if the application instructs GSS_Init_sec_context() that % delegation is not desired, then the implementation must not permit % delegation to occur. This is an exception to the general rule that a % mechanism may enable services even if they are not requested; % delegation may only be provided at the explicit request of the % application. Section 5.2 GSS-API channel binding [RFC5554] is a protected facility for exchanging a cryptographic name for an enclosing channel between the I think I'd prefer "identifier" over "name", though I don't insist on it. The acceptor SHOULD accept any channel binding provided by the initiator if null channel bindings are passed into gss_accept_sec_context. Protocols such as HTTP Negotiate [RFC4559] depend on this behavior of some Kerberos implementations. I'm a little reluctant to make this a SHOULD. Document that stuff already in the wild expects it, sure, but that's only grounds to recommend that this behavior continues under certain deployment conditions. We could also consider a reference to draft-ietf-kitten-channel-bound-flag. Section 5.3 Appendix A. This element is a SOAP header block. The content of the element further depends on the specific use in the mechanism. The Algorithm XML attribute identifies a mechanism for key derivation. It is omitted to identify the use of an Identity Provider-generated key (see following section) or will contain a URI value identifying a derivation mechanism defined outside this specification. [...] Are there any examples of such externally-defined key-derivation mechanisms that we could point to? It is helpful to have a worked example to know that the described procedure is workable in practice. All parties MUST support the "aes128-cts-hmac-sha1-96" encryption type, number 17, defined by [RFC3962]. We might get some pushback on the MTI SHA-1 here (even though HMAC is still fine). Are there existing deployments that would affect the decision, or might we consider a newer enctype? Section 5.3.1 inside a <samlec:GeneratedKey> element. The identity provider does not participate in the selection of the encryption type and simply generates enough pseudorandom bits to supply key material to the other parties. But the IdP has to know enough about encryption types to know how many bits is "enough"? Also, I note the earlier "no changes to the SAML IdP" bit, but since this mechanism is optional, maybe that's okay. If this mechanism is used by the initiator, then the <samlec:SessionKey> SOAP header block attached to the final client response message will identify this via the omission of the Algorithm attribute and will identify the chosen encryption type using the <samlec:EncType> element: I want to check that I'm reading this right: the actual GeneratedKey bits are conveyed to the acceptor in the (encrypted) <saml:Advice>, but the encryption type is conveyed outside the assertion, in the <samlec:EncType> element from the client? It seems like it would be possible, then, to get the acceptor to "misuse" the key material and thus enable potential cross-algorithm attacks. Having the enctype within the signed assertion seems like it would be the "safe path" here, though it would probably also be workable to prevent the attack by using the enctype as input to a key-derivation step between the random-to-key step and actually use as protocol/session key. Section 5.4 The replay_det_state (GSS_C_REPLAY_FLAG), sequence_state (GSS_C_SEQUENCE_FLAG), conf_avail (GSS_C_CONF_FLAG) and integ_avail (GSS_C_INTEG_FLAG) security context flags are always set to TRUE. We probably should say that the corresponding krb5 mechanism protocol machinery is in use, to actually provide those services. Section 5.5 Thank you for including the PRF specification; it's great to see new mechanisms picking that up! Section 5.6 SAML-based information associated with the initiator SHOULD be expressed to the acceptor using GSS-API naming extensions [RFC6680], in accordance with [RFC7056]. nit(?): to me, "in accordance with" suggests that RFC 7056 has some normative requirement that we are following, as opposed to what seems to be intended "we're just doing the same thing they are". So maybe "in a similar manner as [RFC7056]" or something? with the SAML exchange. It does not attempt to solve the problem of mapping between an initiator "username", the user's identity while authenticating to the identity provider, and the information supplied by the identity provider to the acceptor. These relationships must be managed through local policy at the initiator and acceptor. This bit leaves me fairly unhappy. One of the supposed features of the GSS-API is its robust naming abilities, so it seems like we ought to be able to teach it something useful about SAML names. Using naming extensions is nice, but perhaps shouldn't be the only useful way to do things. Section 5.6.1 The GSS_C_NT_USER_NAME form represents the name of an individual user. Clients often rely on this value to determine the appropriate credentials to use in authenticating to the identity provider, and supply it to the server for use by the acceptor. nit(?): I'm not sure which entity "the server" is supposed to be, here. The following paragraph suggests that it's the GSS acceptor... element in the assertion it successfully validated. The name is constructed as a UTF-8 string in the following form: name = element-value "!" Format "!" NameQualifier "!" SPNameQualifier "!" SPProvidedID Just to confirm: the "!" character is forbidden in all of the XML contexts that we're pulling these values from, right? Section 5.6.2 applications that use the Kerberos GSS-API mechanism. As described in in the SASL mechanism's Section 4.7, such a name is used directly by this mechanism as the effective AssertionConsumerService "location" associated with the service and applied in IdP verification of the request against the claimed SAML entityID. [If the Section 4.7 stuff changes, this will have to change, too.] Section 6 We could consider updating the timestamps in the examples to not be in 2007, though it's not required. <stream:features> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanism>DIGEST-MD5</mechanism> <mechanism>PLAIN</mechanism> <mechanism>SAML20EC</mechanism> </mechanisms> </stream:features> Oof, DIGEST-MD5 *and* PLAIN, really emphasizing how bad the alternatives are, I see. (Are these still representative examples, these days?) Step 4: Client selects an authentication mechanism and sends the initial client response (it is base64 encoded as specified by the XMPP SASL protocol profile): We should probably have an informative reference to the XMPP SASL profile somewhere (possibly earlier than here). <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SAML20EC'> biwsLCw= </auth> In particular, I didn't find the <auth> element in https://xmpp.org/extensions/xep-0388.html, which makes me suspect that I'm looking in the wrong place. Step 6: Client relays the request to IdP in a SOAP message transmitted over HTTP (over TLS). HTTP portion not shown, use of Basic Authentication is assumed. The body of the SOAP envelope is nit: comma splice. <saml:EncryptedAssertion> <!-- contents elided, copy of samlec:GeneratedKey in Advice --> </saml:EncryptedAssertion> nit: maybe "includes a copy of" (which will push us over the line limit, of course). (Occurs twice.) The base64 version of the Client->Server response in step 8 uses the string form of the enctype name, but Section 5.3 is pretty clear that the <EncType> element contains the *number* (as shown in the decoded version of the example). <paos:Response xmlns:paos="urn:liberty:paos:2003-08" S:actor="http://schemas.xmlsoap.org/soap/actor/next" S:mustUnderstand="1" refToMessageID="6c3a4f8b9c2d"/> The string "6c3a4f8b9c2d" only appears this once in the document; is that correct? (If I remove the '6' then it matches up nicely...) It's not entirely clear to me what steps 12 and 13 are intended to illustrate, as they don't seem to invoke any of the mechanisms defined by this document. Section 7 There are perhaps some standard considerations about credential delegation to repeat; the usual platitudes about "the entity being delegated to can take all actions the entity delegating access could take" and "only delegate if the receiving entity is fully trusted", etc. In a related vein, with SAML delegation, there's not a particular need to encrypt the assertion that allows for use as the client by the RP, right, since the RP needs to authenticate itself to the IdP to actually use it? This section will address only security considerations associated with the use of SAML with SASL applications. For considerations relating to SAML in general, the reader is referred to the SAML specification and to other literature. Similarly, for general SASL Security Considerations, the reader is referred to that specification. We may (more likely than not) be asked to be more specific about the references, if we try to go forward with this as-is. In particular, we should explicitly pull in the security considerations of [SAMLECP20], since we are literally pulling in large swathes of its procedures. subject confirmation. The former is strongly recommended for use with this mechanism to detect "Man in the Middle" attacks between the client and the RP without relying on flawed commercial TLS infrastructure. The latter may be impractical in many cases, but is (nit?) It might be more politic to refer to the commercial TLS infrastructure as something "that does not provide the level of assurance desired by sensitive SAML applications" or similar. Section 7.1 The adaptation of a web-based profile that is largely designed around security-oblivious clients and a bearer model for security token Is the "bearer model" referring to typical SAML token usage? When channel binding is not used, protection against "Man in the Middle" attacks is left to lower layer protocols such as TLS, and the development of user interfaces able to implement that has not been nit(?): perhaps "left solely to lower layer protocols"? Even when channel-binding is used, TLS is involved as an input. Section 8.1 I think I've lost track of why it's okay to use the same mechanism OID for both the -PLUS and non-PLUS SASL mechanisms. Can you refresh my memory? Section 9.1 It might be nice to put some URLs in for the OASIS refs (e.g., https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf) I had mentioned previously some (of my) confusion about the RFC 7056 usage -- if we are just giving it as an example (vs. reusing procedures from it), it need not be a normative reference. Thanks, Ben
- [kitten] AD review of draft-ietf-kitten-sasl-saml… Benjamin Kaduk
- Re: [kitten] AD review of draft-ietf-kitten-sasl-… Cantor, Scott
- Re: [kitten] AD review of draft-ietf-kitten-sasl-… Robbie Harwood
- Re: [kitten] AD review of draft-ietf-kitten-sasl-… Simon Josefsson