Subject: [abfab] #29: More explicity discussions of the communication channels with the end-points, cryptography and channel binding

From: "abfab issue tracker" <[email-masked]>
Date: Sun, 11 Dec 2011 03:31:22 -0000

#29: More explicity discussions of the communication channels with the end-
points, cryptography and channel binding

 On May 1 I wrote a message with the following text:

 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.

 **

 It was followed up by a couple of notes by sam, myself and nico.  I
 believe that the outcome was that we should get a clear discription of the
 different communication channels, the set of cryptographic operations/keys
 offered by each, and the channel binding opertions (type of binding and
 what it accomplishes) for each channel would be useful.

-- 
--------------------+-------------------------------------
 Reporter:  ietf@…  |      Owner:  draft-ietf-abfab-arch@…
     Type:  defect  |     Status:  new
 Priority:  major   |  Milestone:
Component:  arch    |    Version:
 Severity:  -       |   Keywords:
--------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/abfab/trac/ticket/29>
abfab <http://tools.ietf.org/abfab/>

---

From: Nico Williams <[email-masked]>
Date: Sun, 11 Dec 2011 19:21:48 -0600

On Sat, Dec 10, 2011 at 9:31 PM, abfab issue tracker
<[email-masked]> wrote:
>  exists between the client and the RP. [...]

>  2.  Client to RP GSS-API channel - This is slightly weird to think of as a

While the GSS-API "security context" (GSS term) is indeed a channel
just as much as TLS is a channel, it is best to think of GSS-API w/
channel binding as an extension to TLS.

Suppose we were to propose extensions to TLS that provide us with
federated mutual authentication and an attribute-based authorization
model.  It'd be hard enough to get consensus for such extensions to
TLS, but then to get those extensions implemented by all the major TLS
implementations would take a long time.

Then consider that a common design for channels that provide
authentication is to separate key exchange from authentication but
then bind them (e.g., SSHv2, client certs in TLS, ...).

By using GSS and channel binding we achieve almost exactly what could
have been a TLS extension, and we do it in much the same sort of way
that we might have done it as a TLS extension: separate authentication
from key exchange, then bind the two so that the exchanged keys "speak
for" the authenticated entities.

Also, the GSS channel is thrown away as soon as we're done with
setting it up and doing the channel binding operation.  Before channel
binding we had applications like IMAP and LDAP where there was the
option to use *two* channels (TLS and GSS, with GSS being a channel
proper when its per-message protection facilities were used).  Using
two channels, one inside the other, is quite wasteful, both in terms
of runtime resources (double the crypto) and software engineering
(since it complicates application architecture and requires more
code).  Worse, there may be no way for the application to securely
negotiate among authentication options when using the old SASL/GSSAPI
bridge without ending up with nested channels in some cases.  This is
one critical reason that we pursued SASL/GS2 to replace the old
SASL/GSSAPI bridge.

Long story short: better to think of GSS w/ CB to TLS as an extension to TLS.

>  entities.  (My understanding is that the client can derive this material

This depends on the mechanism.  Some GSS mechanisms involve a third
party and some don't.  Federated authentication involves third parties
by definition.  (Yes, this is a nit.)

>  the client/IdP authentication has completed.

I'm not sure what you're getting at with this.  A round-trip optimization issue?

>  channel #1 and channel #3 during this authentication process.

We should not care at all about reconciliation of the RP names from
channels #1 and #3.  Whenever the GSS mechanism provides acceptable
authentication of the RP to the client we can simply ignore the RP
name from TLS.  And if the GSS mechanism does not provide
authentication of the RP to the client then we have no real channel
binding, and no need to reconcile RP names anyways.

>  these channels and how important those services are.

Channel #1 (TLS) is always going to be providing cryptographic
protection (end-to-end) for client<->RP communications.  Channel #1
may not provide any authentication -- is that what you meant?

>  what it accomplishes) for each channel would be useful.

I agree.  The picture is relatively simple if viewed as follows: we
have a) TLS providing session services, b) GSS providing client<->RP
mutual authentication, and with channel binding to TLS it's almost as
if GSS were part of TLS, c) the specific GSS mechanism in our case
provides authentication by way of one or more third parties.  (a) is
really entirely optional for applications, except that we expect it to
be part of every application protocol that hews to this architecture,
thus (a) is not optional to the architecture, but because (a) and
everything we need for exists already, there's nothing to do to make
it feasible.

Nico
--

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 12 Dec 2011 14:12:39 -0800

As has been pointed out a couple of times.  I should not assuming that the channel I was describing in 1 (client to RP) is going to be TLS either.  It could be something w/o security.

Jim

> -----Original Message-----
> From: Nico Williams [mailto:[email-masked]]
> Sent: Sunday, December 11, 2011 5:22 PM
> To: abfab issue tracker
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [abfab] #29: More explicity discussions of the communication
> channels with the end-points, cryptography and channel binding
> 
> >  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. [...]
> 
> While the GSS-API "security context" (GSS term) is indeed a channel just as
> much as TLS is a channel, it is best to think of GSS-API w/ channel binding as
> an extension to TLS.
> 
> model.  It'd be hard enough to get consensus for such extensions to TLS, but
> then to get those extensions implemented by all the major TLS
> authentication is to separate key exchange from authentication but then
> bind them (e.g., SSHv2, client certs in TLS, ...).
> 
> By using GSS and channel binding we achieve almost exactly what could have
> been a TLS extension, and we do it in much the same sort of way that we
> might have done it as a TLS extension: separate authentication from key
> exchange, then bind the two so that the exchanged keys "speak for" the
> authenticated entities.
> 
> Also, the GSS channel is thrown away as soon as we're done with setting it up
> and doing the channel binding operation.  Before channel binding we had
> applications like IMAP and LDAP where there was the option to use *two*
> channels (TLS and GSS, with GSS being a channel proper when its per-
> message protection facilities were used).  Using two channels, one inside the
> other, is quite wasteful, both in terms of runtime resources (double the
> crypto) and software engineering (since it complicates application
> architecture and requires more code).  Worse, there may be no way for the
> application to securely negotiate among authentication options when using
> the old SASL/GSSAPI bridge without ending up with nested channels in some
> cases.  This is one critical reason that we pursued SASL/GS2 to replace the old
> SASL/GSSAPI bridge.
> 
> >  acceptor, but the keying material is provided by a "third party" to
> > both  entities.  (My understanding is that the client can derive this
> > material
> 
> party and some don't.  Federated authentication involves third parties by
> definition.  (Yes, this is a nit.)
> 
> >  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.
> 
> >  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.
> 
> We should not care at all about reconciliation of the RP names from channels
> #1 and #3.  Whenever the GSS mechanism provides acceptable
> authentication of the RP to the client we can simply ignore the RP name from
> TLS.  And if the GSS mechanism does not provide authentication of the RP to
> the client then we have no real channel binding, and no need to reconcile RP
> names anyways.
> 
> >  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.
> 
> Channel #1 (TLS) is always going to be providing cryptographic protection
> (end-to-end) for client<->RP communications.  Channel #1 may not provide
> any authentication -- is that what you meant?
> 
> >  **
> >
> >  believe that the outcome was that we should get a clear discription
> > of the  different communication channels, the set of cryptographic
> > operations/keys  offered by each, and the channel binding opertions
> > (type of binding and  what it accomplishes) for each channel would be
> useful.
> 
> I agree.  The picture is relatively simple if viewed as follows: we have a) TLS
> providing session services, b) GSS providing client<->RP mutual
> authentication, and with channel binding to TLS it's almost as if GSS were part
> of TLS, c) the specific GSS mechanism in our case provides authentication by
> way of one or more third parties.  (a) is really entirely optional for
> applications, except that we expect it to be part of every application protocol
> that hews to this architecture, thus (a) is not optional to the architecture, but
> because (a) and everything we need for exists already, there's nothing to do
> to make it feasible.
> 
> Nico
> --