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

From: "abfab issue tracker" <[email-masked]>
Date: Sat, 10 Mar 2012 12:47:48 -0000

#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/>