Channel Binding Signalling for the Generic Security Services Application Programming Interface
draft-ietf-kitten-channel-bound-flag-02
| Document | Type | Expired Internet-Draft (kitten WG) | |
|---|---|---|---|
| Authors | Robbie Harwood , Nicolás Williams | ||
| Last updated | 2018-04-19 (Latest revision 2017-10-05) | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats |
Expired & archived
plain text
xml
htmlized
pdfized
bibtex
|
||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Expired | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
https://www.ietf.org/archive/id/draft-ietf-kitten-channel-bound-flag-02.txt
Abstract
Channel binding is a technique that allows applications to use a secure channel at a lower layer without having to use authentication at that lower layer. The concept of channel binding comes from the Generic Security Services Application Programming Interface (GSS- API). It turns out that the semantics commonly implemented are different than those specified in the base GSS-API RFC (RFC2743), and that that specification has a serious bug. This document addresses both the inconsistency as-implemented and the specification bug. This Internet-Draft proposes the addition of a "channel bound" return flag for the GSS_Init_sec_context() and GSS_Accept_sec_context() functions. Two behaviors are specified: a default, safe behavior reflecting existing implementation deployments, and a behavior that is only safe when the application specifically tells the GSS-API that it (the application) supports the new behavior. Additional API elements related to this are also added, including a new security context establishment API.
Authors
Robbie Harwood
Nicolás Williams
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)