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

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sun, 18 Dec 2011 11:48:57 +0200

Hi Jim

in issue #29 http://trac.tools.ietf.org/wg/abfab/trac/ticket/29 you
wrote:

" 
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
<http://trac.tools.ietf.org/wg/abfab/trac/ticket/3>  (Rp to IdP) and the
one talking between the client the RP (channel #1
<http://trac.tools.ietf.org/wg/abfab/trac/ticket/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
<http://trac.tools.ietf.org/wg/abfab/trac/ticket/1>  and channel #3
<http://trac.tools.ietf.org/wg/abfab/trac/ticket/3>  during this
authentication process. 
At this point channel #2
<http://trac.tools.ietf.org/wg/abfab/trac/ticket/2>  and channel #4
<http://trac.tools.ietf.org/wg/abfab/trac/ticket/4>  are known to have
cryptographic protections. Channel #1
<http://trac.tools.ietf.org/wg/abfab/trac/ticket/1>  and channel #3
<http://trac.tools.ietf.org/wg/abfab/trac/ticket/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.
"
A few thoughts come to my mind:

1.	The security requirements laid out in
http://tools.ietf.org/html/rfc4962 are relevant to this discussion and
we should probably be referenced. 
2.	I would be talking about three "channels" rather than four.
Channel 1+2 are essentially one component that relates to each other. 
3.	Regarding the cryptographic protection of the individual
channels and the overall system your mail exchange regarding Levels of
Assurance is of relevance here. Also the debate about trust framework
matters, see my notes on this topic in an ENISA publication (page 45ff
of http://www.enisa.europa.eu/act/it/library/deliverables/pat-study).
>From a write-up point of view there are two aspects to differentiate,
namely (a) what are the IETF standardized tools available to those who
deploy and (b) what do people really deploy. The ABFAB work is not a
Greenfield design and so there is a deployed base to learn from. 
Regarding the requirements for the different channels let me go through
those one by one:
1.)	Client-to-RP: Here we obviously have a lot of variation
depending on the specific application but we may again be able to point
out some basic requirements. I believe there will be some disagreement
between the assumptions we are working on. First, there is the question
whether we want to assume that TLS will always be the underlying
security mechanisms. It would be nice to make that assumption but this
rules out scenarios like SSH or NFS. The next question is whether we
assume RP-side authentication towards the client takes place. We could
also rely purely on an anonymous DH exchange and then use the MSK
provided by AAA to do the binding to the EAP exchange. (This will bring
along the EAP Channel Binding aspects, see
http://tools.ietf.org/html/draft-ietf-emu-chbind-11). Finally, there is
the question of how many options we want to offer.
2.)	RP-to-IdP: This is the AAA protocol environment where we indeed
do not have e2e security, i.e. AAA client to AAA server security
protection (neither confidentiality nor integrity). For me the question
is whether we should be doing something about this (since it had been
attempted in the past already and there was little to no interest) or
stick with the work we had been envisioning so far, such as the ability
to convey SAML assertions and messages, which may experience a different
degree of protection. This does, of course, not lead to any protection
of the AAA messages itself. Maybe this is something we should be
re-visiting again; potentially in combination with the TrustRouter
protocol.
3.)	Client-to-IdP: Here we can ask ourselves how well the
requirements published in http://www.ietf.org/rfc/rfc4017.txt fit for
our purpose. Without having re-read RFC 4017 I believe that our
requirements are the same.  
Ciao
Hannes