Subject: Re: [abfab] Comments on draft-lear-abfab-arch-02

From: "Jim Schaad" <[email-masked]>
Date: Sun, 1 May 2011 19:46:00 -0700

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Friday, April 29, 2011 4:04 AM
> To: Jim Schaad
> Cc: [email-masked]; 'Eliot Lear'
> Subject: Re: [abfab] Comments on draft-lear-abfab-arch-02
> 
> >>>>> "Jim" == Jim Schaad <[email-masked]> writes:
> 
> 
> It's absolutely critical for mutual authentication that we have EAP
channel
> binding. That goes between  the peer/initiator/subject and the IDP/EAP
> server.
> That is independent of GSS channel binding which goes between the
> initiator/subject/peer and the RP/acceptor.
> 
> 
> 
>     Jim>     Jim> Since we don't have the channel binding data for the IdP
to
>     Jim> compare unless the channel is going to produce it.  There is no
>     Jim> channel binding data from the GSS-EAP mechanism until the MSK
>     Jim> is created.  This would not be an issue if we were comparing
>     Jim> text names, but then we have the issue of the difference
>     Jim> between the DNS name used by the client and the AAAA realm name
>     Jim> used by the RP.
> 
> 
> OK, so we also have confusion about channels.  EAP channel binding
> describes properties of the EAP lower layer--in our case the GSS exchange.
> The attributes we care about with regard to this channel are (at least so
far)
> the acceptor name.
> 
> The other channel, over which we apply GSS channel binding, is between the
> subject and RP. That's the channel that might be TLS.  There', the
attributes
> we care about are things like the server certificate or the hash of the
finish
> messages.
> 
> GSS and EAP channel binding are even more different than is implied so
far.
> It's not just that the channel is different and the attributes we're
talking
> about are different.  GSS channel binding is intended to detect a
man-in-the-
> middle attack.  EAP channel binding does make sure that both ends of a
> connection have a consistent idea of naming.
> However it's not really about detecting man in the middle attacks, but
more
> about maintaining consistency in a complex multi-party system.
> 
> Continual apologies for the terminology confusion. The EAP and GSS
> communities independently came up with the term channel binding and
> didn't realize the conflict until it was well established in both
communities.
> --Sam

I think that I am getting some of the terms straight.  What I think I have
problems with is the requirements and points at which things occur.

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
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.

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.  

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.

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.

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.

Jim

---

From: Sam Hartman <[email-masked]>
Date: Mon, 02 May 2011 08:46:19 -0400

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> 3.  RP to IdP channel - This is the weakest of the
    Jim> communication channels in terms of authentication and security.
    Jim> Most of these hops are going to be point-to-point and anybody
    Jim> in the middle can play with the data that is being transferred
    Jim> in either direction.  The base architecture is responsible for
    Jim> providing any authentication assurances between the RP and the
    Jim> IdP.  All authentication is fully established prior to the EAP
    Jim> conversation between the client and the IdP.

Note that with RADSEC this may be much stronger than you describe.
In particular you can have a one-hop mutually authenticated channel
between the RP and IDP if your deployment architecture has a suitable
PKI and you do not require intermediate nodes.

Going quite that far is not something Moonshot is focusing on: we expect
that at least one intermediate within the RP organization will be
required for our deployments.
However I believe ABFAB should support this deployment.

    Jim> 4. Client to IdP - This is the EAP channel.  It has the
    Jim> strongest mutual authentication between that exists.  We have
    Jim> stated that the IdP is responsible during this processing to
    Jim> determine that the RP that is communication to the client over
    Jim> channel #3 (Rp to IdP) and the one talking between the client
    Jim> the RP (channel #1?) are going to be the same entity as the
    Jim> client provides the IdP it's version of the RP name during the
    Jim> EAP conversation.  Thus it needs to reconcile the name forms
    Jim> between channel #1 and channel #3 during this authentication
    Jim> process.

No it reconciles names from channel #2 (GSS) with channel #3 (RP to
IDP).

Channel #1 may not exist. If channel #1 exists channel #2 is responsible
for reconciling channel #1 and channel #2.
The IDP never knows about channel #1.

    Jim> At this point channel #2 and channel #4 are known to have
    Jim> cryptographic protections.  Channel #1 and channel #3 may or
    Jim> may not have cryptographic protections.  We need to specify
    Jim> what level of services are provided in these channels and how
    Jim> important those services are.

we assume that channel #3 provides integrity and while this assumption
is unrealistic in some deployments we assume that channel #3 provides
confidentiality of the MSK.

---

From: Nico Williams <[email-masked]>
Date: Mon, 2 May 2011 10:35:24 -0500

> provided by any certificates and the final message (i.e. a cryptographic

Final TLS Finished message, the exact details being in RFC5929 :)

> to involve the entire abfab  architecture except potentially for assignment

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.

> 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.

> authentication is fully established prior to the EAP conversation between

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.)

> 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.

> 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
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 02 May 2011 11:59:54 -0400

This conversation is starting to yield a lot of useful information.
Does someone want to take an action item to write this up for the
architecture document?