On Sun, May 1, 2011 at 9:46 PM, Jim Schaad <[email protected]> wrote:
> The following is a list of the "channels" that I believe exist in the
> current abfab architecture (Please forgive the names that I am using as
> they are made up on the spot):
>
> 1. Client to RP transport channel - This would be the TLS channel that
> exists between the client and the RP. The channel binding material is
> provided by any certificates and the final message (i.e. a cryptographic
Final TLS Finished message, the exact details being in RFC5929 :)
> token for the channel). This will normally be either a one-way
> authentication of identity (i.e. the client knows who the RP is) or a
> zero-way authentication of identity (i.e. anonymous on both sides). It
> could be a mutual authentication, but in that case there would be no reason
> to involve the entire abfab architecture except potentially for assignment
> of privileges.
Correct: ABFAB should not concern itself at all with what
authentication, if any, takes place at this layer. RFC5056 channel
binding gives you this luxury of not having to require authentication
at the lower layer.
> 2. Client to RP GSS-API channel - This is slightly weird to think of as a
> channel as it is going to be a channel between the requestor and the
> acceptor, but the keying material is provided by a "third party" to both
> entities. (My understanding is that the client can derive this material on
> its own, but the RP gets the material from the IdP.) There is no
> cryptographic binding on this channel until the EAP processing has totally
> finished and the MSK is transferred from the IdP to the RP - i.e. after the
> client/IdP authentication has completed.
A GSS-API security context can represent a channel, yes. If its
per-message tokens are used at all to protect application data (as
opposed to, say, constructing a channel binding operation), then it is
a channel properly in the RFC5056 sense.
The GSS security context here is at the highest layer, and since we
want to use it only for authentication and channel binding to a lower
layer. There's nothing to bind to it. We could conceivably use GSS
security contexts in lower layers and have other higher layers bind to
a GSS channel, and we know how to define the channel bindings for GSS
channels too -- it just hasn't come up yet.
> 3. RP to IdP channel - This is the weakest of the communication channels in
> terms of authentication and security. Most of these hops are going to be
> point-to-point and anybody in the middle can play with the data that is
> being transferred in either direction. The base architecture is responsible
> for providing any authentication assurances between the RP and the IdP. All
> authentication is fully established prior to the EAP conversation between
> the client and the IdP.
These are channels, indeed. When we speak of channel binding we
generally refer to end-to-end channels between ends of interest (or
end-to-end channels between trusted proxies for the actual ends), so
that in the context of the "client" and "RP", these are not channels
of interest, whereas in the context of the "RP" and "IdP" they are.
Context is everything :) (This is not a correction though. You're
quite right that these are channels.)
> 4. Client to IdP - This is the EAP channel. It has the strongest mutual
> authentication between that exists. We have stated that the IdP is
> responsible during this processing to determine that the RP that is
> communication to the client over channel #3 (Rp to IdP) and the one talking
> between the client the RP (channel #1?) are going to be the same entity as
> the client provides the IdP it's version of the RP name during the EAP
> conversation. Thus it needs to reconcile the name forms between channel #1
> and channel #3 during this authentication process.
As Sam explains, it's channels #2 and #3 that channel #4 reconciles.
Channel #1, if it exists, is bound in via RFC5056 channel binding,
which means that we do not concern ourselves at all with what forms of
authentication take place in channel #1, if any -- we only concern
ourselves with the characteristics of channel #1 (resistant to MITMs
when bound into channel #2, provides the desired level of
cryptographic protection to application data, and so on).
Well, there is one way in which we might care about what
authentication channel #1 provides: we might use the channel binding
operation to decide that, there not being any MITMs in channel #1,
whatever RP authentication channel #1 provided can be trusted in the
future. I.e., we can use channel binding to learn the RP's TLS server
cert and treat it as pre-shared so that in the future we can trust
that cert much more than we might have if all we had was the TLS
"PKI". This is nice, but hardly necessary.
> At this point channel #2 and channel #4 are known to have cryptographic
> protections. Channel #1 and channel #3 may or may not have cryptographic
> protections. We need to specify what level of services are provided in
> these channels and how important those services are.
The application at the client and RP decide what characteristics
channel #1 must have (e.g., whether or not it must provide
confidentiality protection). The client has nothing to do with
channel #3 and cannot have any say in it. The {client, IdP} and {RP,
IdPs} get to decide what characteristics channels #3 and #4,
respectively, must have.
Applications might even involve multiple RPs (think of something like
SIP), in which case there may be many instances of each of these
channels that you've identified. In that case the analysis is
complicated by the number of instances of channels, but by and large
the analysis will take the same form: what are the end-points of the
channels, what characteristics must they have, who decides what those
must be, whether there's any channel binding, and from what channel to
what channel, finally leaving us with a set of channels that we agree
"speak for" specific end pairs.
One key idea is to neatly demarcate cryptographic analysis such that
we need only analyze: a) each channel standing alone, b) each
channel's channel bindings data definition, if we need it, c) each
channel's channel binding operation definition, if we need it. We
still need to analyze the whole, but we do not need to apply any
cryptographic protocol analysis to the whole from scratch -- instead
we build the analysis of the whole from the analysis of building
blocks. This is, ultimately, the most important feature of channel
binding: it is a channel composition tool that allows us to simplify
design _and_ *analysis*.
Coming back to ABFAB to wrap up the analysis. GSS applications using
the GSS-EAP mechanism will not need to concern themselves with any
details of channels #3 and #4 except for the authenticated client
(initiator) and RP (acceptor) names that are produced by the IdPs.
The IdPs need not concern themselves with any details of channel #1
(though the IdPs might be involved in the channel binding operation,
but since the channel bindings data are opaque...). The GSS-EAP
mechanism itself does need to concern itself intimately with the
details of channels #3 (on the initiator and IdP sides) and #4 (on the
acceptor and IdP sides), but not with channel #1 (again, channel #1's
channel bindings data are opaque to the GSS mechanism).
Nico
--
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
