Skip to main content

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.