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)
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
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
[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.]
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
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
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
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
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
(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
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
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.
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
(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.
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).
% 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
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.
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.
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
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.
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
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
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
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
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?
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
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
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.
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.
Thank you for including the PRF specification; it's great to see new
mechanisms picking that up!
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
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?
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.]
We could consider updating the timestamps in the examples to not be in
2007, though it's not required.
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'>
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.
<!-- contents elided, copy of samlec:GeneratedKey in Advice -->
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).
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.
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
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
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.
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.
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
It might be nice to put some URLs in for the OASIS refs (e.g.,
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.
Kitten mailing list
While I appreciate the detailed review, mostly for my own educational purposes, I simply don't have anything close to the cycles it would take to redo the document to such a degree. Nobody is funding me to work on it, and events have long since overtaken it.
I was hoping that it was more or less close to workable, and it's a vast improvement over the clearly-broken SAML and OAuth mechanisms that got rubber-stamped a long while back. That mistake is frankly what really motivated me at the time to work on it, but that was many years ago now.
The Ohio State University
Kitten mailing list
"Cantor, Scott" <[hidden email]> writes:
Appreciate your frankness here. With my shepherd hat on:
> While I appreciate the detailed review, mostly for my own educational
> purposes, I simply don't have anything close to the cycles it would
> take to redo the document to such a degree. Nobody is funding me to
> work on it, and events have long since overtaken it.
> I was hoping that it was more or less close to workable, and it's a
> vast improvement over the clearly-broken SAML and OAuth mechanisms
> that got rubber-stamped a long while back. That mistake is frankly
> what really motivated me at the time to work on it, but that was many
> years ago now.
Simon, do you think you have cycles to take this on?
If not, I think we need to find another editor/co-author.
Kitten mailing list
signature.asc (847 bytes) Download Attachment
|Free forum by Nabble||Edit this page|