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