#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/>
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
