[TLS] Appendix B. Additional Use Cases for FXA-TLS: draft-santesson-tls-gssapi-03.txt

[Larry Zhu <lzhu at windows.microsoft.com>]

Pasi requested more use cases that are not HTTP and he asked why RFC4559
is not sufficient. 

In response, appendix B is added. Please see if this satisfies the
requirements. 

I would like thank Ryan for helping with the use cases.

http://www.secure-endpoints.com/tls-gss/draft-santesson-tls-gssapi-03.tx
t

Appendix B.  Additional Use Cases for FXA-TLS

   TLS runs on layers beneath a wide range of application protocols such
   as LDAP [RFC4510], SMTP [RFC2487], and XMPP [RFC3920] and above a
   reliable transport protocol.  TLS can add security to any protocol
   that uses reliable connections (such as TCP).  TLS is also
   increasingly being used as the standard method for protecting SIP
   [RFC3261] application signaling.  TLS can be used to provide
   authentication and encryption of the SIP signaling associated with
   VOIP (Voice over IP) and other SIP-based applications.

   Today these applications use public key certificates to verify the
   identity of endpoints.

   However, how to manage the issuance level of certificates when
   deploying PKI is overwhelmingly complex and such complexity has
   gradually eroded the confidence for the PKI-based systems in general.
   In addition, the perceived overhead of deploying and managing
   certificates is high.  As a consequence, the industry badly needs the
   ability to secure TLS connections by leveraging the existing
   credential infrastructure.  For many customers that means Kerberos.
   It is highly desirable to enable PKI-less deployments yet still offer
   strong authentication.

   Having Kerberos/GSS-API in the layer above TLS means all TLS
   applications need to be changed in the protocol level.  In many
   cases, such changes are not technically feasible.  For example,
   [RFC4559] provides integration with Kerberos in the HTTP level.  It
   suffers from a couple of drawbacks, most notably it only supports
   single-round-trip GSS-API mechanisms and it lacks of channel bindings
   to the underlying TLS connection which makes in unsuitable for
   deployment in situations where proxies exists.  Furthermore,
   [RFC4559] lacks of session-based re-authentication (comparing with
   TLS).  The root causes of these problems are inherent to the HTTP
   protocol and can't be fixed trivially.

   Consequently, It is a better solution to integrate Kerberos/GSS-API
   in the TLS layer.  Such integration allows the existing
   infrastructure work seamlessly with TLS for the products based on
   them in ways that were not practical to do before.  For instance, an
   increasing number of client and server products support TLS natively,
   but many still lack support.  As an alternative, users may wish to
   use standalone TLS products that rely on being able to obtain a TLS
   connection immediately, by simply connecting to a separate port
   reserved for the purpose.  For example, by default the TCP port for
   HTTPS is 443, to distinguish it from HTTP on port 80.  TLS can also
   be used to tunnel an entire network stack to create a VPN, as is the
   case with OpenVPN.  Many vendors now marry TLS's encryption and
   authentication capabilities with authorization.  There has also been
   substantial development since the late 1990s in creating client
   technology outside of the browser to enable support for client/server
   applications.  When compared against traditional IPSec VPN
   technologies, TLS has some inherent advantages in firewall and NAT
   traversal that make it easier to administer for large remote-access
   populations.

   PSK-TLS as defined in [RFC4279] is a good start but this document
   finishes the job by making it more deployable.  FKA-TLS also fixes
   the mutual-authentication problem in [RFC4279] in the cases where the
   PSK can be shared among services on the same host.


_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls