Liaison statement
Response to "Liaison statement on the need for a roadmap for IdM activities within ITU-T and other organizations"
Additional information about IETF liaison relationships is available on the
IETF webpage
and the
Internet Architecture Board liaison webpage.
State | Posted |
---|---|
Submitted Date | 2009-09-03 |
From Group | SEC |
From Contact | Pasi Eronen |
To Group | ITU-T-JCA-IDM |
To Contacts | Dick Brackney <rcbrack@verizon.net> Olivier Dubuisson <olivier.dubuisson@orange-ftgroup.com> Takashi Egawa <t-egawa@ct.jp.nec.com> |
Cc | Patrik Faltstrom <paf@cisco.com> The IETF Chair <chair@ietf.org> |
Purpose | In response |
Attachments | (None) |
Body |
The Internet Engineering Task Force (IETF) Security Area would like to thank ITU-T Joint Coordination Activity for Identity Management for the opportunity to provide information about IETF's identity management activities. The IETF has developed or is currently developing a number of standards dealing with how entities (including humans, hosts, routers, and so on) are identified, how those identities are authenticated, and how they're used for, e.g., access control and other purposes. These standards may be used to establish, authenticate, and leverage identity information at various network layers in Internet protocols and applications. The IETF does not maintain roadmaps covering past and future work for identity management specifically, but we believe at least the following work may be of interest to ITU-T JCA-IdM: * Transport Layer Security (TLS), HTTP authentication mechanisms, and HTTP cookies provide a foundation for authenticating servers and users on the web. * DNS Security (DNSSEC) provides data origin authentication and data integrity for DNS names, which are often used as host identities, and included in typical user identities such as email addresses and SIP URIs. * DomainKeys Identified Mail (DKIM) provides an authenticated identity who claims responsibility for a message, assisting in control of spam and phishing. * S/MIME and OpenPGP provide end-to-end authentication of email sender identities. * Internet X.509 Public Key Infrastructure (PKIX) certificate profiles and protocols provide basis for managing identities and authorizations with a public key infrastructure. * Lightweight Directory Access Protocol (LDAP), Remote Authentication Dial In User Service (RADIUS), and Diameter are used to access directories and authentication/authorization/accounting (AAA) servers, facilitating single sign-on and centralized management of identity and authorization information. * Simple Authentication and Security Layer (SASL) framework and mechanisms, Kerberos, and Generic Security Service Application Program Interface (GSS-API) framework and mechanisms are used to authenticate users in number of protocols, ranging from IMAP and XMPP/Jabber to NFS and SMB/CIFS. Kerberos is also used to facilitate single sign-on especially in enterprise environments. * Extensible Authentication Protocol (EAP) framework and authentication methods are used to authenticate users in, for example, wireless networks such as Wi-Fi and WiMAX. * Session Identity Protocol (SIP) authentication and identity mechanisms can be applied to a broad variety of applications, including voice, conferencing, and messaging. * Open Authentication Protocol (OAUTH) leverages identity information to permit a user to grant a third-party access to their resources, without sharing or revealing their credentials. * Dynamic Symmetric Key Provisioning Protocol (DSKPP) deals with how symmetric key based authentication credentials are provisioned (and connected with an existing identity), especially in the context of one-time password tokens. The IETF also leverages identity credentials across network layers using channel bindings, as described in RFC 5056. With channel bindings, authentication results in the application layer are cryptographically bound to the security mechanisms provided at the session or transport layer. Several IETF protocols include support for channel bindings. Together, these technologies add up to several hundred RFCs, developed in several dozen IETF working group (many still active, some already concluded), and in some cases, outside IETF working groups. A full document list is therefore omitted here. |