#29: More explicity discussions of the communication channels with the end-
points, cryptography and channel binding
Changes (by hannes.tschofenig@…):
* cc: hannes.tschofenig@… (added)
* owner: draft-ietf-abfab-arch@… => hannes.tschofenig@…
Comment:
I think that this comment can be addressed in the security consideration
section.
Here is a proposal what I plan to put into the -01 version of the draft:
Security Considerations
This document describes the architecture for Application Bridging for
Federated Access Beyond Web (ABFAB) and security is therefore the
main focus. This section highlights the main communication channels
and their security properties:
Client-to-RP Channel:
This communication channel is secured by TLS executed 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). Authentication may be provided by the RP
to the client but a deployment without authentication at the TLS
layer is possible as well. In addition, there is a channel
between the GSS requestor and the GSS acceptor, but the keying
material is provided by a "third party" to both entities. The
client can derive keying material locally, but the RP gets the
material from the IdP. There is no cryptographic binding on this
channel until the EAP processing has finished and the MSK is
transferred from the IdP to the RP.
RP-to-IdP Channel:
The security of this communication channel is mainly provided by
the functionality offered via RADIUS and Diameter. At the time of
writing there are no end-to-end security mechanisms standardized
and thereby the architecture has to rely on hop-by-hop security
with trusted AAA entities or, as an alternative but possible
deployment variant, direct communication between the AAA client to
the AAA server. Note that the authorization result the IdP
provides to the RP in the form of a SAML assertion may, however,
be protected such that the SAML related components are secured
end-to-end.
Client-to-IdP Channel:
This communication interaction is accomplished with the help of
EAP and EAP methods. The offered security protection will depend
on the EAP method that is chosen but a minimum requirement fis to
offer mutual authentication, and key derivation. The IdP is
responsible during this process to determine that the RP that is
communication to the client over the RP-to-IdP channel is the same
one talking to the IdP. This is accomplished via the EAP channel
binding.
--
--------------------+----------------------------------
Reporter: ietf@… | Owner: hannes.tschofenig@…
Type: defect | Status: new
Priority: major | Milestone:
Component: arch | Version:
Severity: - | Resolution:
Keywords: |
--------------------+----------------------------------
Ticket URL: <http://trac.tools.ietf.org/wg/abfab/trac/ticket/29#comment:1>
abfab <http://tools.ietf.org/abfab/>
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
