Categories
Building Trust Identity Privacy

Senegal First African Country to Implement Recommendations of ‘Personal Data Protection Guidelines for Africa’

Last week, we have had a busy two days (11-12 October 2018) in Dakar participating in a multistakeholder workshop on Privacy and Personal Data Protection in Senegal co-organized by the Personal Data Protection Commission (CDP), the Ministry in charge of Digital Economy (MCTPEN), the Internet Society Senegal Chapter, and supported by the African Regional Bureau of the Internet Society. This workshop was recommended in the Personal Data Protection Guidelines for Africa launched in May 2018 during #AISDakar by the African Union and the Internet Society.

Senegal stands out as the first African Union member to act on that recommendation and run such a workshop, bringing together policy makers, law enforcement, data protection authorities, lawyers, academics, entrepreneurs, and actors of the private sector, civil society, and technologists to debate the issues and build a shared vocabulary and shared understanding.

The discussion was wide-ranging, informed, and mature

Wide-ranging, because the organizers did a great job of attracting a diverse and engaged set of stakeholders and giving them the time and space to contribute.

Informed, because the participants were asking all the right questions (about privacy, innovation, cybercrime, threats to information, reputation and rights, and so on), backed up by real experience and practical concerns.

Mature, because three themes came out strongly through the discussion:

  • The Internet raises challenges, for example, of reconciling freedom of opportunity, freedom of expression, and freedom of access to information with the risk of criminal and malicious activity, and the impact of measures taken to counter such activity.
  • Those challenges are as much social, economic, educational, and legal as technical, and require a correspondingly multidisciplinary approach. There are no single stakeholder solutions, here.
  • Educating and mobilizing the public to make safe use of the Internet and maximize its opportunities is a huge and multifaceted task. It needs engagement at the level of families, schools, employers, and society at large. But it’s essential if we are to protect and enhance individuals’ rights while responding positively and sustainably to technical innovation.

The workshop ended with a strong recognition of the Internet a force for good in society and the importance of ensuring trust in online applications and services, as a key factor in sustaining a productive and beneficial digital economy for everyone.

Learn more about Personal Data Protection Guidelines for Africa, why your Digital Footprint matters, and how to manage and protect your Online Identity and Privacy.

Categories
Building Trust Encryption Events Identity IETF Improving Technical Security Open Internet Standards Privacy Technology Transport Layer Security (TLS)

Rough Guide to IETF 101: Privacy, Identity, and Encryption

It’s that time again! In this post of the Rough Guide to IETF 101, I’ll take a quick look at some of the identity, privacy, and encryption related activities at IETF this coming week. Below a few of the many relevant activities are highlighted, but there is much more going on so be sure to check out the full agenda online.

Encryption

Encryption continues to be a priority of the IETF as well as the security community at large. Related to encryption, there is the TLS working group developing the core specifications, several working groups addressing how to apply the work of the TLS working group to various applications, and the Crypto-Forum Research Group focusing on the details of the underlying cryptographic algorithms.

The Transport Layer Security (TLS) Working Group is a key IETF effort developing core security protocols for the Internet. The big news out of this working group is the IESG approval of the TLS 1.3 specification. There is still some way to go before final publication, but the end is in sight.

There will be two TLS sessions this week. The Monday session will focus primarily on the ongoing discussion of data center operator concerns for the use of DTLS in their environments. There is an updated proposal on a “TLS 1.3 Option for Negotiation of Visibility In the Datacenter”. This is sure to continue to be a contentious topic in the TLS working group as it struggles with whether or not to adopt this work.

The Wednesday session will address a number of ongoing drafts including:

The TLS working group is very active and, as with all things that are really important, there are many diverse opinions to fill the room.

The Using TLS in Applications (UTA) Working Group was chartered to look at updating the definitions for using TLS with various application protocols. It has finished a number of documents already including recommendations for the secure use of TLS and DTLS, use of TLS for XMPP, and the use of TLS server identity check procedures for email. The main portion of the meeting will discuss issues raised on a draft related to Strict Transport Security (STS) for mail (SMTP) transfer agents and mail user agents. Also on the agenda is a draft on an option to require TLS for SMTP. There is a new draft on TLS/DTLS 1.3 profiles for IoT that may get some discussion time, but isn’t currently listed on the agenda.

The next activity of potential interest to the encryption community is the Crypto Forum Research Group (cfrg). A key work item of this research group that is nearing completion is hash based signatures. I also see updated drafts on Verifiable Random Functions, Hashing to Elliptic Curves, and Verifiable Oblivious Pseudorandom Functions. The agenda isn’t posted yet so I’m not sure what else might appear, but I am sure it will be an interesting and engaging discussion.

There are two other sessions that will be of interest to folks generally interested in encryption in protocols.

The first is a BoF on Message Layer Security (mls). Many internet applications need group key-establishment and a message protection protocol with features like asynchronicity, forward secrecy, membership authentication and message authentication. The goal of this proposed working group is to develop a standard security protocol so that applications can share code and so that there can be shared validation of the protocol (as there has been with TLS 1.3), not the interoperability of messaging protocols. The Messaging Layer Security BoF is a working group-forming session exploring whether there is sufficient interest and scope to form a working group on the topic. The agenda includes a problem statement, architecture, draft protocol, a report on formal analysis, and a discussion of charter. Some key drafts include https://datatracker.ietf.org/doc/draft-omara-mls-architecture and https://datatracker.ietf.org/doc/draft-barnes-mls-protocol.

Finally, the QUIC Working Group is striving to provide a standards-track specification for a UDP-based, stream-multiplexing, encrypted transport protocol. This has been a very active working group in the IETF. While this is a Transport Area effort, the fact that encryption is a key aspect and being designed in from the beginning is of interest to encryption enthusiasts.

Certificates

Moving on from cryptography and encryption, the next set of IETF working groups are related to the certificate infrastructure for the Internet, acme and lamps.

The Automated Certificate Management Environment (acme) Working Group is specifying ways to automate certificate issuance, validation, revocation and renewal. The main order of business at this week’s meeting is to discuss the core specification Automatic Certificate Management Environment. This document has been submitted to the IESG for publication, and this meeting will focus on addressing the feedback received to date. The meeting will also discuss the TLS ALPN challenge, and some STIR topics.

The Limited Additional Mechanisms for PKIX and SMIME (lamps) Working Group is engaged in some maintenance activities around PKIX and SMIME. A number of working group documents have been submitted to the IESG, and this week’s agenda will discuss DNS Certification Authority Authorization (CAA) Resource Record, additional SHAKE algorithms and identifiers, and use of the SHAKE one-way has function in CMS.

Authentication and Authorization

From the certificate infrastructure, we move next to authentication and authorization and the set of related working groups tackling those issues for the IETF.

Anyone with an interest in the Internet of Things (IoT), will be interested in the Authentication and Authorization for Constrained Environments (ace) Working Group. This group is working to develop standardized solutions for authentication and authorization in constrained environments. They published a use cases document last year, and this week’s agenda includes discussion of existing working group documents on authentication and authorization for constrained environments.

The Web Authorization Protocol (oauth) Working Group has been working for years on mechanisms that allow users to grant access to web resources without necessarily compromising long term credentials or even identity. It has been a very prolific working group with around 15 RFCs published to date. IETF 101 will be another busy week for those interested in this area including sessions on both Tuesday and Wednesday. Agenda items for these two sessions include:

Additionally, the working group will discuss a potential new OAuth client assertion flow and distributed OAuth.

For those new to OAuth, there is an OAuth 2.0 tutorial planned for Sunday afternoon in the first tutorial slot. This is an excellent opportunity to get a detailed introduction to OAuth 2.0 from a key contributor to the work.

There are two additional working groups meeting this coming week that are related to the OAUTH work. The first is the Token Binding (TOKBIND) Working Group that is tasked with specifying a token binding protocol and specifying the use of that protocol with HTTPS. The second is Security Events (SECEVENT) Working Group working on an Event Token specification that includes a JWT extension for expressing security events and a syntax for communicating the event-specific data. Both of these have a strong relationship to the OAuth work.

General Security

The Network Time Protocol (NTP) Working Group addresses protocols for the accurate synchronization of clocks on a network. This may seem like a bit of a stretch for a blog post on identity, privacy, and encryption. However, accurate and secure time synchronization turns out to be vitally important for the proper operation of security protocols. The NTP WG has been working on Network Time Security (NTS) which is a significant update for NTP server authentication. This week the NTP NTS effort will focus on getting some implementation work done in the Hackathon in advance of the NTP meeting on Thursday.

For the security crowd, no IETF week is complete without the Security Area Advisory Group (SAAG) meeting. This meeting features a quick run through all the working groups doing security-related work in the IETF across all areas, a set of short talks, and an open session to bring issues and topics forward from the community. The agenda isn’t available yet, but it generally is an excellent session on security in general.

The experiment from IETF 100 on a session to quickly review and decide what to do with specific new work proposals that are being brought forward has resulted in a new working group specifically for this purpose, Security Dispatch (secdispatch). The new working group will meet for the first time this week, and it will address a method for web security policies, considerations For Using Short Term Certificates, use of the Hash-based Merkle Tree Signature (MTS) Algorithm in the Cryptographic Message Syntax (CMS), and pretty Easy privacy.

Also, don’t forget the IETF Hackathon is held this weekend, before the IETF. This IETF Hackathon has several projects of interest including work on Messaging Layer Security, TLS 1.3 testing and interoperability, EAP TLS with large certificates and long certificate chains, distributed denial of service threat signaling, and Network time security. All the potential projects of this rendition of the IETF Hackathon as listed on the IETF 101 Hackathon wiki site.

Finally, just a quick note to point out that DNS Privacy (DNSPRIV) and the Decentralized IoT Security and Standards (DISS) workshops were successfully held in conjunction with NDSS 2018. The agendas and some materials are online now, and the proceedings will be published in the coming months.

Join us for another full week for identity, and privacy, and encryption related topics here at IETF 101!

Relevant Working Groups at IETF 100:

ace (Authentication and Authorization for Constrained Environments) WG
Monday, 19 March, 09:30-12:00, Balmoral
Agenda: https://datatracker.ietf.org/doc/agenda-101-ace/
Charter: https://datatracker.ietf.org/wg/ace/about/

acme (Automated Certificate Management Environment) WG
Wednesday, 21 March, 15:20-16:50, Buckingham
Agenda: https://datatracker.ietf.org/doc/agenda-101-acme/
Charter: https://datatracker.ietf.org/wg/acme/about/

cfrg – Crypto Forum Research Group
Monday, 19 March, 15:50-17:20, Balmoral
Agenda: https://datatracker.ietf.org/meeting/101/agenda/cfrg/
Charter: https://irtf.org/cfrg

ntp (Network Time Protocol )WG
Thursday, 22 March, 15:50-17:50, Palace C
Agenda: https://datatracker.ietf.org/doc/agenda-101-ntp/
Charter: https://datatracker.ietf.org/wg/ntp/about/

oauth (Web Authorization Protocol) WG
Monday, 19 March, 15:50-17:20, Viscount
Agenda: https://datatracker.ietf.org/doc/agenda-101-oauth/
Charter: https://datatracker.ietf.org/wg/oauth/about/

quic (QUIC)
Thursday, 22 March, 09:30-12:00, Sandringham
Agenda: https://datatracker.ietf.org/meeting/101/materials/agenda-101-quic.html
Charter: https://datatracker.ietf.org/group/quic/about/

saag (Security Area open meeting)
Thursday, 22 March, 13:30-15:30, Sandringham
Agenda: https://datatracker.ietf.org/meeting/101/materials/agenda-101-saag/ (coming soon)

secdispatch (Security Dispatch)
Tuesday, 20 March, 09:30-12:00, Blenheim
Agenda: https://datatracker.ietf.org/doc/agenda-101-secdispatch/
Charter: https://datatracker.ietf.org/wg/secdispatch/about/

secevent (Security Events) WG
Friday, 23 March, 09:30-11:30, Park Suite
Agenda: https://datatracker.ietf.org/meeting/101/materials/agenda-101-secevent/
Charter: https://datatracker.ietf.org/wg/secevent/about/

tls – Transport Layer Security
Monday, 19 March, 17:40-18:40, Balmoral
Agenda: https://datatracker.ietf.org/doc/agenda-101-tls-sessa/, https://datatracker.ietf.org/doc/agenda-101-tls-sessb/
Charter: https://datatracker.ietf.org/wg/tls/about/

tokbind (Token Binding) WG
Wednesday, 21 March, 15:20-16:50, Viscount
Agenda: https://datatracker.ietf.org/meeting/101/materials/agenda-101-tokbind/
Charter: https://datatracker.ietf.org/wg/tokbind/about/

uta – Using TLS in Applications
Thursday, 22 March, 18:10-19:10, Blenheim
Agenda: https://datatracker.ietf.org/meeting/101/materials/agenda-101-uta/
Charter: https://datatracker.ietf.org/wg/uta/about/

Follow Us

It will be a busy week in London, and whether you plan to be there or join remotely, there’s much to monitor. Read the full series of Rough Guide to IETF 101 posts, and follow us on the Internet Society blog, Twitter, or Facebook using #IETF101 to keep up with the latest news.

Categories
Blockchain Identity

Blockchain and Digital Identity – A Good Fit?

Every time you see “Login with Facebook” or “Login with Twitter” etc. on a website or use login credentials issued by your employer or school, you’re using Identity and Access Management (IAM) technologies in the background. IAM has become central to our online interactions, but like a lot of infrastructure it’s largely invisible to users (at least when it’s well designed and implemented). IAM is evolving rapidly, the stakes are high, and enterprises face an increasingly complex and puzzling digital identity landscape. There is also growing concern that businesses know too much about us, and therefore end users should reclaim control over their own identities. IAM is a hot topic in the technology world, with new architectures, business models, and philosophies all in play.

Blockchain technology (sometimes also called distributed ledger technology – DLT) is also gaining attention. Proponents advocate it for a wide variety of use cases, including IAM. Blockchain is a broad class of relatively new data security methods, with certain properties of potential value in IAM. Many IAM companies have launched identity registration solutions “on the blockchain,” while others are developing new blockchain-inspired infrastructure for distributing information about users (called “attributes” and used to inform decisions about whether to grant access to resources), which is a key element of IAM.

We wrote a white paper, titled “Do Blockchains Have Anything to Offer Identity?”, to provide an in-depth analysis of blockchain and IAM, and to provide a lens through which to view and evaluate forthcoming developments. Faced with a growing amount of hype and scepticism, we seek to provide a balanced perspective, and to clarify the ways in which blockchain technologies may or may not serve the needs of IAM.

In answering whether these new and innovative technologies can help with IAM, the starting point should be to appreciate what the first blockchains were designed to do (cryptocurrency), and then to build carefully on that. This paper should help those devising new IAM solutions, and those acquiring solutions and needing to evaluate blockchain-based approaches. Perhaps most importantly, we hope to provide guidance in evaluating current and new blockchain-based IAM solutions as they come along.

After our analysis, it is clear that blockchain technologies are collectively a work in progress. Our conclusion is that despite early enthusiasm about their general security properties, on closer inspection we find that the original public blockchains are generally not a good fit for IAM. The objective of cryptocurrency – to exchange electronic cash without intermediaries and without trust – is fundamentally different from that of enterprise IAM, which typically requires much more rigorous key lifecycle management and access controls than public blockchains offer.

Several new blockchain technology developments show promise for improving particular aspects of IAM, such as the provenance of identity attributes and cryptographic keys. Our recommendation is that any ongoing examination of blockchain technologies for IAM begin with a clear problem statement, and an appreciation of the nuances in blockchain security.

We hope you will read the paper and let us know if you have any thoughts on the matter.

Steve Wilson is a researcher, analyst and adviser in digital identity and privacy. He is General Manager of the Lockstep Group headquartered in Sydney, Australia, and holds an adjunct position as Principal Analyst with Silicon Valley based Constellation Research.

Steve Olshansky is Internet Technology Program Manager for the Internet Society.

Categories
Building Trust Deploy360 Encryption Events Identity IETF Improving Technical Security Open Internet Standards Privacy Technology Transport Layer Security (TLS)

Rough Guide to IETF 100: Identity, Privacy, and Encryption

Identity, privacy, and encryption continue to be active topics for the Internet Society and the IETF community impacting a broad range of applications. In this Rough Guide to IETF 100 post, I highlight a few of the many relevant activities happening next week in Singapore, but there is much more going on so be sure to check out the full agenda online.

Encryption

Encryption continues to be a priority of the IETF as well as the security community at large. Related to encryption, there is the TLS working group developing the core specifications, several working groups addressing how to apply the work of the TLS working group to various applications, and the Crypto-Forum Research Group focusing on the details of the underlying cryptographic algorithms.

The Transport Layer Security (TLS) working group is a key IETF effort developing core security protocols for the Internet. This week’s agenda includes both TLS 1.3 and Datagram Transport Layer Security. Additionally, the TLS working group will be discussing connection ID, exported authenticators, protecting against denial of service attacks, and application layer TLS. The TLS working group is very active and, as with all things that are really important, there are many diverse opinions to fill the room.

For those new to TLS, there is a TLS 1.3 tutorial planned for Sunday afternoon in the first tutorial slot. This is an excellent opportunity to get a detailed introduction to the TLS 1.3 protocol from the experts.

Two of the working groups focused on updating crypto algorithms and the use of TLS in IETF protocols are also meeting at IETF 100. The DKIM Crypto Update (dcrup) working group, which is focused on updating the cryptographic aspects of RFC 6376, will have a short. Their first document, Cryptographic Algorithm and Key Usage Update to DKIM, has just been approved and has been moved to the RFC Editor for publication. On the agenda for this meeting will be new cryptographic signature methods for DKIM and defining elliptic curve cryptography algorithms for use with DKIM.

The Using TLS in Applications (UTA) working group has finished a number of documents already, including recommendations for the secure use of TLS and DTLS, use of TLS for XMPP, and the use of TLS server identity check procedures for email. The first part of the meeting will focus on resolving the final IESG comments on the use of TLS for email submission and access. This draft outlines current recommendations for the use of TLS to provide confidentiality of email traffic between a mail user agent and a mail access server. The meeting will also cover open issues on a draft related to Strict Transport Security (STS) for mail (SMTP) transfer agents and mail user agents. Finally, the meeting will address a draft on an option to require TLS for SMTP.

The Network Time Protocol (NTP) working group addresses protocols for the accurate synchronization of clocks on a network. This may seem like a bit of a stretch for a blog post on identity, privacy, and encryption. However, accurate and secure time synchronization turns out to be vitally important for the proper operation of security protocols. The NTP WG has been working on Network Time Security (NTS) which is a significant update for NTP server authentication. In order to make progress, the latest version of this draft reduces the scope of the solution to the client server mode of NTP only. There is a recent IETF Journal article that provides a detailed discussion of the current state of the NTS effort.

The next activity of potential interest to the encryption community is the Crypto Forum Research Group (cfrg). Always a popular session at IETF, this week the CFRG will discuss four drafts, including Re-keying Mechanisms for Symmetric Keys, The Transition from Classical to Post-Quantum Cryptography, a draft SPAKE2, a secure, efficient password based key exchange protocol, and Public Key Exchange.

Certificate Infrastructure

Moving on from cryptography and encryption, the next set of IETF working groups are related to the certificate infrastructure for the Internet, acme and trans.

The Automated Certificate Management Environment (acme) working group is specifying ways to automate certificate issuance, validation, revocation and renewal. The main order of business at this week’s meeting is to discuss the core specification Automatic Certificate Management Environment. This document has been submitted to the IESG for publication, and this meeting will focus on the feedback received to date. The meeting will also discuss automatic certificate management for telephony (https://datatracker.ietf.org/doc/draft-ietf-acme-telephone/, https://datatracker.ietf.org/doc/draft-ietf-acme-service-provider/) and email (draft-ietf-acme-email-tls-01 and draft-ietf-acme-email-smime-01 ) along with Short-Term, Automatically-Renewed (STAR) Certificates.

The second certificate related working group is the Public Notary Transparency (trans) working group. It has been working since 2014 to improve the confidence of users in the Web PKI. The underlying premise of this work is to create transparent logs of certificates so that improperly issued certificates can be detected. That which is transparent can be observed and monitored for unexpected behavior. The core document has been submitted to the IESG, and this meeting will discuss resolution of open issues from the AD review. The threat analysis needs some minor enhancements before restarting the WGLC. The Gossiping in CT document has been submitted to the IESG, and the working group needs to address initial AD feedback. Finally, the working group will discuss name redaction (https://datatracker.ietf.org/doc/draft-strad-trans-redaction/, https://www.ietf.org/internet-drafts/draft-ito-yet-another-name-redaction-00.txt ) to improve privacy.

Authentication and Authorization

From the certificate infrastructure, we move next to authentication and authorization and the set of related working groups tackling those issues for the IETF.

Anyone with an interest in the Internet of Things (IoT), will be interested in the Authentication and Authorization for Constrained Environments (ace) working group. This working group is working to develop standardized solutions for authentication and authorization in constrained environments. They published a use cases document last year, and this week’s agenda includes discussion of existing working group documents on authentication and authorization for constrained environments, a DTLS profile for ACE, a CBOR Web Token (CWT), and an architecture for authorization in constrained environments. In addition, there will be discussion of a number of new drafts for working group consideration. You might also want to check out the Internet of Things Rough Guide post for more on IoT.

The Web Authorization Protocol (oauth) working group has been working for years on mechanisms that allow users to grant access to web resources without necessarily compromising long term credentials or even identity. It has been a very prolific working group with around 15 RFCs published to date. IETF 100 will be another busy week for those interested in this area including sessions on both Tuesday and Wednesday. Agenda items for these two sessions include a mutual TLS profile, token binding, JWT best practices, device flow, discovery, token exchange, and incremental authorization.

There are two additional working groups meeting this coming week that are related to the OAUTH work. The first is the Token Binding (TOKBIND) working group that is tasked with specifying a token binding protocol and specifying the use of that protocol with HTTPS. A number of the group’s core documents have been submitted to the IESG (https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/, https://datatracker.ietf.org/doc/draft-ietf-tokbind-negotiation/, and https://datatracker.ietf.org/doc/draft-ietf-tokbind-protocol/). Preliminary feedback from the Area Director (AD) will be discussed. This working group works in collaboration with the TLS, HTTPbis and OAUTH WGs and with the W3C webappsec WG.

Also related to OAUTH, the Security Events (SECEVENT) working group is working on an Event Token specification that includes a JWT extension for expressing security events and a syntax for communicating the event-specific data. This is a fairly new WG, formally chartered in January 2017. The meeting this week will discuss the token specification, token delivery, stream management and provisioning, and a management API.

More Activities

For the security crowd, no IETF week is complete without the Security Area Advisory Group (SAAG) meeting. This meeting features a quick run through all the working groups doing security related work in the IETF across all areas, a set of short talks, and an open session to bring issues and topics forward from the community. This week will have one invited talk on Inter-domain DDoS mitigations: potentials, challenges, and solutions. The remaining time will be spent on an experiment, called secdispatch, where proposals for new work will be discussed.

Also, don’t forget the IETF Hackathon which is held the weekend before the IETF. This IETF Hackathon has several projects of interest including continuing work on TLS 1.3 testing and interoperability, the HTTP status code 451, generating certificate requests for short-term automatically-renewed certificates, and distributed denial of service threat signaling. All the potential projects of this rendition of the IETF Hackathon as listed on the IETF 100 Hackathon wiki site.

Finally, in a continuing effort to connect security researchers and the Internet security standardization community, two topics with active working groups at IETF 100, IoT Security and DNS Privacy, are planning for workshops to be held in conjunction with NDSS 2018. Both the Decentralized IoT Security and Standards (DISS) workshop and DNS Privacy: Increasing Usability and Decreasing Traceability (DNSPRIV) workshop are currently accepting submissions and planning for productive workshops in February 2018. Perhaps something overheard in the halls of IETF 100 would make a good submission.

Join us for another full week for identity, and privacy, and encryption related topics here at IETF 100!

Relevant Working Groups at IETF 100

ace (Authentication and Authorization for Constrained Environments) WG
Tuesday, 14 November 2017, 930 – 1200, Collyer
Agenda: https://datatracker.ietf.org/doc/agenda-100-ace/
Charter: https://datatracker.ietf.org/wg/ace/about/

acme (Automated Certificate Management Environment) WG
Thursday 16 November 2017, 1550 – 1750, Sophia
Agenda: https://datatracker.ietf.org/doc/agenda-100-acme/
Charter: https://datatracker.ietf.org/wg/acme/about/

cfrg (Crypto Forum Research Group)
Wednesday, 15 November 2017, 15:20-16:50, VIP A
Agenda: https://datatracker.ietf.org/meeting/100/agenda/cfrg/
Charter: https://irtf.org/cfrg

dcrup (DKIM Crypto Update)
Wednesday, 15 November 2017, 930-1100, Bras Basah
Agenda: https://datatracker.ietf.org/meeting/100/agenda/dcrup/
Charter: https://datatracker.ietf.org/wg/dcrup/about/

ntp (Network Time Protocol) WG
Monday, 13 November 2017, 1330 – 1530, VIP A
Agenda: https://datatracker.ietf.org/doc/agenda-100-ntp/
Charter: https://datatracker.ietf.org/wg/ntp/about/

oauth (Web Authorization Protocol) WG
Tuesday, 14 November 2017, 1550 – 1750, Sophia
Wednesday, 15 November 2017, 1520 – 1650, Orcard
Agenda: https://datatracker.ietf.org/doc/agenda-100-oauth/
Charter: https://datatracker.ietf.org/wg/oauth/about/

saag (Security Area open meeting)
Thursday, 16 November 2017, 1330-1530, Padang
Agenda: https://datatracker.ietf.org/meeting/100/materials/agenda-100-saag/

secevent (Security Events) WG
Monday, 13 November 2017, 1330 – 1530, Bras Basah
Agenda: https://datatracker.ietf.org/meeting/100/materials/agenda-100-secevent/
Charter: https://datatracker.ietf.org/wg/secevent/about/

tls (Transport Layer Security) WG
Thursday, 16 November 2017, 930 – 1200, Canning
Agenda: https://datatracker.ietf.org/doc/agenda-100-tls-sessa/
Charter: https://datatracker.ietf.org/wg/tls/about/

tokbind (Token Binding) WG
Tuesday, 14 November 2017, 1330 – 1530, VIP A
Agenda:  https://datatracker.ietf.org/meeting/100/materials/agenda-100-tokbind/
Charter: https://datatracker.ietf.org/wg/tokbind/about/

trans (Public Notary Transparency) WG
Monday, 13 November 2017, 1550 – 1720, Orchard
Agenda: https://datatracker.ietf.org/meeting/100/materials/agenda-100-trans/
Charter: https://datatracker.ietf.org/wg/trans/about/

uta (Using TLS in Applications) WG
Wednesday, 15 November 2017, 1330 – 1500, Bras Basah
Agenda: https://datatracker.ietf.org/meeting/100/materials/agenda-100-uta/
Charter: https://datatracker.ietf.org/wg/uta/about/

Follow Us

A lot is going on in Singapore, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Society blog, Twitter, Facebook, or see https://dev.internetsociety.org/events/ietf/ietf-100/.

Categories
Building Trust Identity IETF Privacy

Rough Guide to IETF 99: Trust, Identity, and Privacy

Trust, Identity, and Privacy continue to be topics of interest for the IETF community. Below I will highlight a few of the many activities. There is something for everyone interested in these areas here at IETF 99 in Prague this week!

The work privacy started before the IETF meeting itself actually began with the IETF 99 Hackathon. As you are reading this, the Hackathon will have already been completed. This Hackathon had the largest attendance ever and reached full capacity. It was an energetic event highlighting a number of emerging technologies. An overview of all the Hackaton projects is available on the Hackathon wiki (https://www.ietf.org/registration/MeetingWiki/wiki/99hackathon).

There are two especially relevant efforts in the Hackathon that I’d like to bring to your attention. The first one is a large collaboration of people working on DNS, DNSSEC, and DNS privacy. This is a well-established project that has been active in several recent IETF Hackathon events. The second was a team of people working on HTTP error code 451 (RFC7725). This is an error code to report legal obstacles for serving a webpage. During the hackathon they focused on implementing and measuring this status code to make censorship more transparent.

Moving onto the extensive work on trust, and identity, and privacy in the IETF, I will remind folks that the excellent work of the DNS Privacy working group (dprive) was covered in an earlier rough guide post (https://dev.internetsociety.org/blog/tech-matters/2017/07/rough-guide-ietf-99-dns-privacy-and-security-including-dnssec).

The first two working groups I’m going to highlight in this post are working on topics related to the certificate infrastructure for the Internet. The Automated Certificate Management Environment (acme) working group is specifying ways to automate certificate issuance, validation, revocation and renewal. The main order of business is to discuss the working group last call comments on the core specification Automatic Certificate Management Environment (https://datatracker.ietf.org/doc/draft-ietf-acme-acme). The working group will also be discussing working group last call comments on the CAA Record Extensions for Account URI and ACME Method Binding (https://datatracker.ietf.org/doc/draft-ietf-acme-caa) document. New drafts to be discussed include ACME Identifiers and Challenges for Telephone Numbers (https://datatracker.ietf.org/doc/draft-ietf-acme-telephone) and ACME Identifiers and Challenges for VoIP Service Providers (https://datatracker.ietf.org/doc/draft-ietf-acme-service-provider).

The second certificate related working group is the Public Notary Transparency (trans) working group. It has been working since 2014 to improve the confidence of users in the Web PKI. The underlying premise of this work is to create transparent logs of certificates so that mis-issuance can be detected. That which is transparent can be observed and monitored for unexpected behavior. The core document (https://datatracker.ietf.org/doc/html/draft-ietf-trans-rfc6962-bis) is in working group last call.

Anyone with an interest in the Internet of Things (IoT), will be interested in the Authentication and Authorization for Constrained Environments (ace) working group. This working group is working to develop standardized solutions for authentication and authorization in constrained environments. They published a use cases document last year, and this week’s agenda includes discussion of existing working group documents on authentication and authorization for constrained environments, a DTLS profile for ACE, a CBOR Web Token (CWT), and an architecture for authorization in constrained environments. In addition, there will be discussion of a number of new drafts for working group consideration.

The Web Authorization Protocol (oauth) working group has been working for years on mechanisms that allow users to grant access to web resources without necessarily compromising long term credentials or even identity. It has been a very prolific working group with around 15 RFCs published to date. IETF 99 will be another busy week for those interested in this area including sessions on both Tuesday and Friday. Agenda items for these two sessions include a mutual TLS profile, security, incremental authorization, JWT best practices, device flow, token exchange, and token binding.

There are two additional working groups meeting this coming week that are related to the OAUTH work. The first is the Token Binding (TOKBIND) working group that is tasked with specifying a token binding protocol and specifying the use of that protocol with HTTPS. This working group will be discussing two key drafts: Token Binding for 0-RTT TLS 1.3 Connections (draft-ietf-tokbind-tls13-0rtt), and HTTPS Token Binding with TLS Terminating Reverse Proxies (draft-campbell-tokbind-ttrp-00). This working group works in collaboration with the TLS, HTTPbis and Oauth WGs and with the W3C webappsec WG.

Also related to oauth, the Security Events (SECEVENT) working group is working on an Event Token specification that includes a JWT extension for expressing security events and a syntax for communicating the event-specific data. This is a fairly new WG, formally chartered in January 2017. The meeting this week will discuss several topics including the token specification, token delivery, a management API, and use cases for RISC and SCIM.

More related to the identity of devices than the identity of individuals but included here for completeness, the Identity Enable Networks (ideas) BoF proposes to examine how existing protocols that separate identifiers from their location may benefit from the concept of identity. The two drafts that form the structure of the meeting are Problem Statement for Identity Enabled Networks (draft-padma-ideas-problem-statement) and Gap Analysis for Identity Enabled Networks (draft-xyz-ideas-gap-analysis). Also under discussion is Identities and Identifiers for ION and the IETF. Come along to this session if you are interested in seeing whether or not the IETF might charter work in this space.

For the security crowd, no IETF week is complete without the Security Area Advisory Group (SAAG) meeting. This meeting features a quick run through all the working groups doing security related work in the IETF across all areas, a set of short talks, and an open session to bring issues and topics forward from the community. This week the talks include Post-quantum Crypto, Pretty Easy Privacy (pEp), and a Certificate Limitation Profile.

Finally, for those with a keen interest in privacy, the W3C Privacy Interest Group (PING) will again be meeting for their regular PING and friends get-together during the lunch break on Thursday, 20 July 2017 in Rokoska. Anyone with an interest in privacy is invited to join the meeting (but it is bring your own lunch).

All in all, an action packed week for trust, identity, and privacy related topics here at IETF 99!

Relevant Working Groups at IETF 99

acme (Automated Certificate Management Environment) WG
Friday, 21 July 2017, 0930-1130, Athens/Barcelona
Agenda: https://datatracker.ietf.org/meeting/99/agenda/acme/
Charter: https://datatracker.ietf.org/wg/acme/about/

trans (Public Notary Transparency) WG
Wednesday, 19 July 2017, 1520-1650, Berlin/Brussels
Charter: https://datatracker.ietf.org/wg/trans/about/

ace (Authentication and Authorization for Constrained Environments) WG
Monday, 17 July 2017, 09:30-1200, Congress Hall I
Agenda: https://datatracker.ietf.org/meeting/99/agenda/ace/
Charter: https://datatracker.ietf.org/wg/ace/about/

oauth (Web Authorization Protocol) WG
Tuesday, 18 July 2017, 1330-1530, Berlin/Brussels
Friday, 21 July 2017, 0930-1130), Karlin III
Agenda: https://datatracker.ietf.org/meeting/99/agenda/oauth/
Charter: https://datatracker.ietf.org/wg/oauth/about/

tokbind (Token Binding) WG
Monday, 17 July 2017, 1550-1720, Berlin/Brussels
Agenda: https://datatracker.ietf.org/meeting/99/agenda/tokbind/
Charter: https://datatracker.ietf.org/wg/tokbind/about/

secevent (Security Events) WG
Tuesday, 18 July 2017, 0930-1200, Karlin I/II
Agenda: https://datatracker.ietf.org/meeting/99/agenda/secevent/
Charter: https://datatracker.ietf.org/wg/secevent/about/

ideas (Identity Enable Networks) BOF
Wednesday, 19 July 2017, 1330-1500, Congress Hall II
Agenda: https://datatracker.ietf.org/meeting/99/agenda/ideas/
Documents: https://datatracker.ietf.org/wg/ideas/documents/

saag (Security Area open meeting)
Thursday, 20 July 2017, 1330-1530, Congress Hall III
Agenda: https://datatracker.ietf.org/meeting/99/agenda/saag/

Follow Us

There’s a lot going on in Prague, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see http://dev.internetsociety.org/rough-guide-ietf99.

Categories
Identity Privacy

TIIME to Pay Attention to Identity

My colleague Robin Wilton and I participated in the recent Trust and Internet Identity Meeting Europe (TIIME) in Vienna, Austria, co-sponsored by the Internet Society and organized by long-time notable identeratus Rainer Hörbe.

This meeting brought together approximately 100 people who are engaged in advancing the state of the art and strengthening trust around online identity. Structured as an “unconference,” it was up to the attendees to set the agenda and lead the sessions. As you can see from the session list the meeting covered a lot of ground.

I led sessions on IoT Security and Privacy and Blockchain and Identity, two topics of particular interest to me and to the Internet Society. My colleagues and I have written in the past about IoT Security and Privacy, and we plan to write more on both topics.

One of the key themes of the meeting was Federated Identity and Access Management (IAM). This is something that many are not familiar with, at least not by that name, although it plays a significant role in the lives of many, and will widen its reach as time goes on. One of the paradoxes of this technology, like many others, is that when it is working well it “gets out of the way” and is not very visible to people using it. It is only when things break down that it becomes noticeable.

Essentially, it’s when you log on at one organization (e.g., a book publisher’s site) using an ID and password that was issued to you by another (for instance, the university at which you are a student).

For anyone who would like to learn more about Federated IAM, there are many good resources. Some to get you started include:

The global Research and Education (R&E) community has led the way in developing and fine-tuning the technologies and associated policies that enable Federated IAM to work well, and the technology has become core infrastructure for R&E worldwide. Industries and governments around the world have adopted various aspects of Federated IAM around the world, with more certain to follow. Federations tend to be set up around logical constituencies, such as a local or federal government offering services to its constituents, or vertical industries such as automotive or pharmaceuticals. In the R&E sector federations tend to be national or built around particular fields of study, and in many cases they are run by or at least closely associated with National Research and Education Networks (NRENs).

Federated IAM simplifies things for users, because it reduces the number of IDs and passwords they need to manage, while still securing their access to multiple services. At this point in its evolution, though, having solved many of the easier “low-hanging fruit” problems, it has exposed more challenging ones.

Developing and refining the policies and processes regarding what attributes about its users an Identity Provider (IdP) releases to a Service Provider (SP) has been and continues to be a challenge. An SP relies on user attributes conveyed in a trustworthy manner from the IdP to make access control decisions. The required attributes will vary along a spectrum from those that are not at all revealing about the user’s identity to those that very explicitly and uniquely identify the person, based upon the risk profile of the resource being accessed. E.g. for a digital library resource licensed to an educational institution, all that might be required is an assertion that the user is currently affiliated with the institution, or perhaps also enrolled in a particular class for the current session. For access to your health or financial records, enough identifying information will need to be conveyed to fully convince the resource holder that you are in fact you. And of course this is what we want. I tend to think of privacy controls in this context as a virtual knob that can be turned from 0-10, depending on what is actually needed in a particular context. Unfortunately there is a tendency among some SPs to require much more than they legitimately need, in some cases because they want to use the additional information for financial gain (monetization) either currently or reserving for some possible future use. A common monetization strategy is using profile information for marketing, including packaging and selling to third parties.

The specific set of attributes required by the SP is something that it can negotiate with the IdP on a bilateral basis, often in association with a contract for services. Or a particular bundle of attributes may be released by IdPs to particular classes of SPs. However, users cannot always rely upon IdPs to protect their privacy. It is up to the manager(s) of the IdP to represent the interests of their users and negotiate the release of only those attributes for which the SP can make a legitimate case for being necessary for its purposes in making access decisions. This is essentially the trade-off – users get simplicity because they are relying upon the IdP to negotiate on their behalf.

In this age of data monetization, it is more important than ever for us all to be conscious of what information about us is being sent, where, for what purposes, and how it is being protected. As Federated IAM continues to advance and become more ubiquitous, it is incumbent upon us all to ask the questions of those entrusted with shepherding and protecting our data. This starts with looking at how your IdPs use your data, and why. In some cases this is easy to learn from publicly available information, such as privacy policies or terms of service, but in other cases it will require some digging. Ultimately it is up to us as the stewards of our information and to be on the lookout for possible misuse, and to take steps to protect ourselves.

Although I have used examples from the higher education sector, you have probably encountered federated authentication in another form: the growing trend to invite you to log in to sites using your social media identity.

Using social networking or similar IdPs to login to other sites is very convenient, which is the fundamental value proposition, but in the process of doing so users may be revealing much more about themselves and their activities to that IdP than they intend to, to their detriment. The things you trust an IdP to do are not necessarily the things you trust your social media provider to do. There is a saying: if you are not paying for the service then you are the product. This is true for “free” services such as social networks and email, which use data collected about users to market and sell to others.

An encouraging trend is that of non-commercial IdPs that explicitly promise not to use or abuse your data, and in particular not to sell it. A good example of this is UnitedID.org, which can be used broadly in the R&E sector as well as with select broadly available commercial services, and which will be the subject of a separate blogpost.

For more information about choosing IdPs, see Robin Wilton’s excellent white paper: Have you chosen an Identity Provider Lately?

Categories
Building Trust Growing the Internet Identity Privacy

Digital Identity: Evolving, or just cloning itself?

I’m grateful to Christian de Larrinaga, from the Internet Society’s UK Chapter, for pointing me to a recent publication by the World Bank: “Principles on identification for sustainable development: toward the digital age“.

The premise of the report is this: full participation in today’s societies and achievement of one’s desired potential are increasingly likely to depend on the ability to identify oneself; however, some 1.5 billion people are reckoned to lack “legal identification”, and action should be taken to remedy this.

The report acknowledges that private companies and other non-governmental organisations are stakeholders in such an identity infrastructure, and further notes that identity, in the desired sense, does not necessarily imply nationality or citizenship. Off-hand, two examples where “legal identification” systems already conform to this model are:

  • Estonia, where the government issues an “e-citizen” credential which, although legally recognised, does not imply citizenship, and is independent of nationality;
  • The Scandinavian Bank-ID system, in which credentials issued by banks (and therefore independent of nationality or citizenship) are legally recognised by public sector bodies.

So, as a principle, this is clearly viable based on existing practice. However, in two areas the report seems to me to miss opportunities that are relevant to the modern concept of digital identity.

First, the report is written entirely from the perspective of the “historical”, credential-based model of identity, in which you go through a trusted enrolment process in order to be issued with a trustworthy credential (for example, the passport issuing process). Understandably, that’s how nation-level eID systems are designed, because that’s the model of identity that state actors are familiar with.

But that’s not how identity works in the data-driven Internet context. I have never been through any kind of trusted enrolment with Google, they have never issued me with a trustworthy credential, and yet they could paint a unique and extremely intimate portrait of my identity. When, in Principle 2, the report talks about reducing information asymmetries, I fear that it is not talking about the real, relevant information asymmetries between individuals and those entities that can intimately identify (and track, and profile, and monetise) them without any need for the kind of “historical” identity described above.

The mindset behind the “historical” model of identity is one in which identity is something conferred upon the individual by an authoritative body (generally the state). That mindset is understandable, from the state actor’s perspective, but it tends to understate or even omit the notion of user control. For instance, you cannot typically choose or limit the information disclosed about you via your passport or driving licence.

Under Principle 8, the report may come close to addressing this concern, in that it talks about the requirement for attribute-level disclosures. That is, if the criterion for access to a particular service is that I must be over 18, then the appropriate design is that I should be able to present a trustworthy assertion that I am over 18, without having to provide further identifying information.

But, and this is my second concern, the ability of the user to disclose attributes selectively, and in a trustworthy way, is not an end in itself. It is an illustration of two principles:

  • the principle of user control,
  • the principle of anonymous or pseudonymous access to services.

Again, the report goes some way towards addressing these requirements, but stops short of doing so fully. Where it describes user control over data disclosure, it does so in terms of constraints:

“Authentication protocols should only disclose the minimal data necessary to ensure appropriate levels of assurance” – Principle 6

Users should have “the ability to selectively disclose only those attributes required for a given transaction” – Principle 8

Under the circumstances, I find it strange that the report doesn’t describe functional requirements of anonymity or pseudonymity. In fact, it doesn’t mention anonymity or pseudonymity at all. In my view, an eID system that doesn’t explicitly address these in its statement of requirements is incomplete.

In the context of this report, which is aimed at supporting the UN’s sustainable development goals (SDGs) by defining electronic ID for the next 1.5 billion people, that incompleteness gives rise to a serious risk. Those of us who are not among the 1.5 billion people lacking legal digital identification have already experienced ways in which our digital identities are dysfunctional: over collection of personal data, lack of transparency in its use and sharing, data breaches that expose millions of records of personal information, and a data monetisation economy that reduces individuals’ ability to control the use of data about them. All the risks identified above have emerged under regulatory regimes that contain exactly the kind of recommendations made in this report, but which, like this report, fall short of mandating the provision of anonymous and pseudonymous means of access where these are appropriate.

We also see a trend, in various countries, towards insisting that there should be no online access without authentication – in other words, that all online access should be identifiable – with corresponding risks to freedom of expression and freedom of access to information. While these factors affect all of us, they are likely to have a far greater proportional effect on the next 1.5 billion people to go online, given the economic and political context in which they do so.

I would like to see the UN SDGs supported by statements of requirements that do include anonymity and pseudonymity, so that we do not simply pass on, to the next 1.5 billion people to come online, an approach to digital identity that replicates flaws with which we are already dealing. There is an opportunity, here, for our approach to identity not simply to clone itself, but to evolve.

Categories
Building Trust Identity IETF Open Internet Standards Privacy Technology

Rough Guide to IETF 98: Trust, Identity, and Privacy

It should come as no surprise that there are numerous activities related to Trust, Identity, and Privacy on the agenda for IETF 98. Below I will highlight a few of the many activities and provide pointers to a number of additional ones. There is something for everyone interested in these areas in Chicago in the coming week!

The fun starts before the meeting even begins with the IETF 98 Hackathon. There are two relevant efforts in the hackathon that I’d like to bring to your attention. The first one is a large collaboration of people working on DNS, DNSSEC, and DNS privacy. This is a well-established project that has been active in several recent IETF Hackathon events. Many of the regular contributors to this project recently met with a number of academic researchers in San Diego at the Network and Distributed System Security (NDSS) Symposium 2017 for a full day workshop on DNS Privacy. This work is actively driving improvements in the DNS privacy space. (See also our Rough Guide on DNS Privacy and Security.)

The second hackathon project related to our overarching topic of trust is the one on COSE/JOSE. Javascript Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) are two related standards for the definition of objects for signing and encryption for JSON and CBOR environments respectively. These efforts are foundational to some continuing work in the IETF around tokens in the web and IoT spaces.

After a few days of diving deep into the details, it might be time to broaden the perspective again. The next session I’d like to suggest, especially to those new to the development of IETF protocol standards, is the Sunday tutorial on Security Considerations. This tutorial explores some of the many aspects of security that might get overlooked during the development of a protocol. The IETF security community is in the process of updating the current guidelines represented in RFC 3552 “Guidelines for Writing RFC Text on Security Considerations.” Additional volunteers are being sought to help finish this effort.

For those with a keen interest in privacy, the W3C Privacy Interest Group (PING) will again be meeting for its regular PING and friends get-together during the lunch break on Thursday, 30 March in Montreux2. Anyone with an interest in privacy is invited to join the meeting (but it is bring your own lunch).

Unfortunately, in a slot directly conflicting with the W3C PING meeting is a session that is also of potential interest. It is a lunch talk by John Mattsson, a Senior Specialist at Ericsson Security Research with a focus on Security Protocols, Cryptography, and IoT. This talk will look at the evolution of cellular security from cryptographic beginnings in 2G to a vision for 5G with improved security and privacy. Grab a quick sandwich and head to what is sure to be an interesting and informative session. The good news is that this session will be streamed live and archived on the IETF YouTube channel.

With the hackathons, tutorials, side meetings, and guest lectures covered, we have now arrived at the detailed work of the IETF. The first step to adopting work in the IETF is a Birds of a Feather (BoF) session, and there is one relevant BoF in our space this time. The Protocol for Dynamic Trusted Execution Environment Enablement (TEEP) BoF is considering an effort to define a standardized version of an application layer security protocol for the configuration of security credentials and software running on a Trusted Execution Environment (TEE). There is a proposal available (https://tools.ietf.org/html/draft-pei-opentrustprotocol-03) to help jump start the activity.

The Network Time Protocol (NTP) working group has been working for some time to define a replacement for the NTP Autokey protocol. Autokey was developed many years ago, has been identified with numerous flaws, was published as an Informational RFC because of those flaws, and has never been broadly deployed and used. The Network Time Security (NTS) for NTP effort (https://datatracker.ietf.org/doc/html/draft-ietf-ntp-using-nts-for-ntp) specifies a mechanism to provide cryptographic security for NTP for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD). Accurate, reliable, and precise time synchronization is key to a number of underlying security protocols, and this improvement to NTP is long overdue and needed. The NTP working group will also be discussing the publication of a BCP for NTP addressing some of the key misconfiguration issues that lead to DDoS attacks on NTP and some minor updates to NTPv4 to fix some outstanding issues.

The Public Notary Transparency (TRANS) working group has been working since 2014 to improve the confidence of users in the Web PKI. The underlying premise of this work is to create transparent logs of certificates so that mis-issuance can be detected. That which is transparent can be observed and monitored for unexpected behavior. The core document (https://datatracker.ietf.org/doc/html/draft-ietf-trans-rfc6962-bis) has been through Working Group Last Call and 24 revisions. A number of recent issues have been raised and will be discussed this coming week. Additionally, the working group will be discussing redaction, the threat analysis document, and using transparency to improve trust of binaries.

The Web Authorization Protocol (OAUTH) working group has been working for years on mechanisms that allow users to grant access to web resources without necessarily compromising long-term credentials or even identity. It has been a very prolific working group with around 14 RFCs published to date. IETF 98 will be another busy week for those interested in this area including sessions on both Monday and Friday. Agenda items for these sessions include token exchange, device flow for and input constrained devices without browsers, authorization server metadata, token binding, proof of possession, authorization server to client key distribution, the OAuth 2.0 authorization framework, and additional security topics. This is a full agenda indeed! There is also some related work in the Hackathon and rumors of an OpenID working group hands-on session on building mobile apps with AppAuth (Native Applications Best Practices) to be held on Sunday, 26 March.

There are two additional working groups meeting this coming week that are related to the OAUTH work. The first is the Token Binding (TOKBIND) working group that is tasked with specifying a token binding protocol and specifying the use of that protocol with HTTPS. Additionally, the Security Events (SECEVENT) working group is working on an Event Token specification that includes a JWT extension for expressing security events and a syntax for communicating the event-specific data.

Wrapping up our tour through the trust-related working group activity this week, we have the ACE and LAMPS working groups. The Authentication and Authorization for Constrained Environments (ACE) working group is working to develop standardized solutions for authentication and authorization in constrained environments (think IoT). They published a use cases document last year, and this week’s agenda includes architecture, actors, and the CBOR Web Token (CWT) with multiple drafts to support the conversations. And the Limited Additional Mechanisms for PKIX and SMIME (LAMPS) is (as the name implies) making some specific updates to PKIX and SMIME. The agenda for the week includes drafts to update both RFC 5750 and RFC 5751.

Finally, no IETF week is complete without the Security Area Advisory Group (SAAG) meeting. This meeting features a quick run through all the working groups doing security related work in the IETF across all areas, a set of short talks, and an open session to bring issues and topics forward from the community.

All in all, an action packed week for trust, identity, and privacy related topics here at IETF 98!

Relevant Working Groups at IETF 98:

TEEP BoF (A Protocol for Dynamic Trusted Execution Environment Enablement)
Tuesday, 28 March, 14:50-16:20, Zurich E/F
About: https://datatracker.ietf.org/wg/teep/about/

NTP (Network Time Protocol)
Monday, 27 March, 13:00-15:00, Montreaux 3
Documents: https://datatracker.ietf.org/group/ntp/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-ntp/

TRANS (Public Notary Transparency)
Tuesday, 28 March, 13:00-14:30, Montreaux 3
Agenda: https://datatracker.ietf.org/meeting/98/agenda/trans/
Documents: https://datatracker.ietf.org/group/trans/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-trans/

OAUTH (Web Authorization Protocol)
Monday, 27 March, 17:10-18:10, Zurich C
Friday, 31 March, 09:00-11:30, Zurich C
Agenda: https://datatracker.ietf.org/meeting/98/agenda/oauth/
Documents: https://datatracker.ietf.org/group/oauth/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-oauth/

TOKBIND (Token Binding)
Monday, 27 March, 15:20-16:50, Zurich A
Agenda: https://datatracker.ietf.org/meeting/98/agenda/tokbind/
Documents: https://datatracker.ietf.org/group/tokbind/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-tokbind/

SECEVENT (Security Events)
Wednesday, 29 March, 09:00-11:30, Zurich C
Agenda: https://datatracker.ietf.org/meeting/98/agenda/secevent/
Documents: https://datatracker.ietf.org/group/secevent/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-secevent/

ACE (Authentication and Authorization for Constrained Environments)
Monday, 27 March, 09:00-11:30, Zurich C
Agenda: https://datatracker.ietf.org/meeting/98/agenda/ace/
Documents: https://datatracker.ietf.org/group/ace/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-ace/

LAMPS (Limited Additional Mechanisms for PKIX and SMIME)
Thursday, 30 March, 17:40-18:40, Vevey 1/2
Agenda: https://datatracker.ietf.org/meeting/98/agenda/lamps/
Documents: https://datatracker.ietf.org/group/lamps/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-lamps/

SAAG (Security Area Open Meeting)
Thursday, 30 March, 15:20-17:20, Zurich D
Agenda: https://datatracker.ietf.org/meeting/98/agenda/saag/

Follow Us

There’s a lot going on in Chicago, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see http://dev.internetsociety.org/rough-guide-ietf98.

Categories
Human Rights Identity Improving Technical Security

My Data. Your Business.

In times like these, it’s easy to be paranoid.

Almost every day there is a new story about an app, a TV or a child’s toy that is collecting too much data, or a massive data breach, or the latest kind of ransomware doing the rounds of the Internet.

We may not know the specifics, but we do know that somewhere out there someone is tracking us online: in fact, most of the data monetization machine is invisible to consumers — the individuals whose data fuels it.

All this has, understandably, left many people wary. Why WOULD you trust someone or something that is gathering information on you with no real insight into how it will be used?

The consequences of this could be devasting to the economy. If do not understand how their data will be handled and used and therefore don’t trust online transactions, online business will wither and die. The economy that the Internet supports could disappear.

Today is a day when world leaders will be listening. Not only is it World Consumer Rights Day, but it is also the G20 Consumer Rights Summit in Berlin. Robin Wilton, who helps lead Technical Outreach for Identity and Privacy for Internet Society, is on a panel to send a clear message that consumers, companies, and governments must take up the cause of data protection to help create an Internet we all can trust.

The global economy depends on it.

Here’s why your data is collected

For companies, your data means money for them.

Take Snapchat, a mobile messaging service where messages “disappear” after a few moments. In 2014, Snapchat turned down a $3 billion offer from Facebook to buy it.

And just a few weeks ago, Snapchat just filed for a $3 billion IPO and debuted at $17 a piece on 1 March and popped up to as high as $26.05 on day two.

Why is a service that prides itself on “disappearing” messages be so valuable? The answer depends on what Snapchat represents to you. If you’re part of a younger market that is less interested in leaving indelible footprints on Facebook, and is more interested in spur-of-the-moment mobile messaging, then the idea of a service where your messages automatically disappear is an attractive one.

If you’re looking to acquire the company, its value lies in the personal data consumers can’t avoid disclosing – their names, their phone numbers and most importantly, their network (the people they are connected to).

Different people see different values in the same company, and that can mean tensions when it comes to consumer protection. How can the company monetize its consumers’ data, while still delivering the privacy they signed up for?

Why is it a big deal for us?

With companies willing to pay millions, even billions, for information on what we do online, there is a strong motive for companies to collect all they can, keep it forever and use it for as many purposes as they can dream up. That sends a strong signal that we need to be in control of our personal information.

And while some companies are open and clear about what they do with our data, we – as consumers – are mostly kept in the dark. And, let’s face it, innovation is happening faster than our individual ability to keep up. Sometimes it seems like there is an “act now, ask for forgiveness later” culture.

And, then there’s the issue of data breaches. Large-scale data breaches continue to plague both the commercial and the public sector and to affect millions of consumers and citizens, as noted in the Internet Society’s 2016 Global Internet Report.

So if data collection and data breaches are showing no sign of stopping, what can be done?

Encryption is a key

We typically think of encryption just as a way of keeping information secret, and therefore as a way of mitigating the risk of a data breach — but in the digital world, it is much more than that.

  • It ensures that Internet traffic goes to the right destination.
  • It helps establish that you are talking to the person (or service) you meant to talk to.
  • It protects you against fraud when you pay online or in person.
  • It secures your mobile phone, your satnav, your home wireless connection.

Encryption underpins trust in almost every aspect of online activity, and as the Internet of Things expands, that list will only grow.

The Internet Society believes that encryption should be the norm. It’s the basis for fueling what the Internet brings to our economy, it’s a tool that helps us to trust our online transactions, and it helps all of us – from consumers to businesses to governments – boost our online security. It is not a threat, but a tool to help us know we’re doing our part to secure ourselves and the Internet.

Organizations Must Act.

Organizations must also play a role.

Together, with businesses and other organizations, the Internet Society believes that we need standards to handle consumer data ethically.

We propose a set of simple, but effective, principles any organization can implement, to create a culture of ethical use of personal data.

  • Publish ethical data commitments and stand by them.
  • Be honest and fair about consent and re-use.
  • Be transparent about your business model.
  • Embody ethics in product/service design.

We believe this will result in more sustainable business models for personal data, and lead to more trust between consumers and service providers.

These principles are a starting point. They should also be reinforced by practical measures, such as the Privacy by Design approach set out by Canadian and Dutch data protection commissioners in the mid-90s. For example, it recommends the practice of data minimisation: collect only what you need, keep it only for as long as you need it, destroy it safely and make sure it is secure. Restrict access – remember you are holding someone’s very personal and private data – and encrypt!

If you would like to take part in the development of these principles, please get in touch.

Consumers need policy on their side

Policy makers must step up to the plate as well.

One of the most important places to start is to create a way to reward organizations and companies for ethical data handling practices and to encourage ways for those entities to credibly signal to consumers what standards they are applying. Ethical data handling is not only a solution for consumers: it is also a foundation for trust and sustainable economic growth.

Policymakers must work to create the conditions in which ethical data handling can have a positive effect on the market.

We all have a role to play

But, above all, we, as consumers, can take steps now. Inform yourself, demand better privacy and protect the data on your devices and in your communications, by using encryption.

Categories
Human Rights Identity Privacy Public Policy

Shield & Sword – 10 tips to protect yourself online

Last weekend, millions joined the Women’s March in the US and across the world. They stood up for their rights, and the rights of everyone. We need to do the same on the Internet.

The Internet gives everyone a voice, but we need people to protect those voices.

Online harassment and cyber bullying are real. And, some groups are targeted more than others.

Last year, the Guardian exposed the stark reality in the field of journalism. An analysis of written comments posted in response to articles on the Guardian website revealed that of the ten journalists who received the most abusive comments, eight were women, and the two men were black.

They concluded this “provides the first quantitative evidence for what female journalists have long suspected: that articles written by women attract more abuse and dismissive trolling than those written by men”.

Sadly, who you are affects how you are treated by others online, as well as offline.

However, a powerful way to counter online abuse, threats and violence is to share our knowledge with each other so that we can become stronger champions of privacy and security, and to stand up for others when they need it.

So, to mark this year’s International Data Privacy Day, the Internet Society would like to share with you 10 tips to protect yourself online.

1. Know the terrain.

The Internet is a powerful tool for communication. Learn how to use the Internet, keep your eyes open for good and bad actors, and make the most of what the Internet offers.

2. Keep your private life private.

Keep your personal information separate from your professional role. Use different personas for different roles.

3. Protect communications.

Use end-to-end encryption and two-factor authentication for confidential communications.

4. Obscure your location.

Remove location data from images and videos before posting. Turn off application access to location. Don’t disclose your location in public posts.

5. Guard your devices.

They’re more precious than any jewels. Protect them from both physical and digital tampering. Use encryption and strong access credentials.

6. Prepare for an attack.

Find allies and prepare a plan for dealing with online harassment, doxing and other forms of abuse. Don’t feed the trolls! They don’t deserve your attention.

7. Stand firm.

Don’t let cyber bullies undermine what you are doing. Show them you are not afraid. Others will stand with you. Be willing to ask for help.

8. Beware of Trojan horses.

Look out for spear-phishers. Check before connecting with someone new. If something seems too good to be true, don’t trust it!

9. Lead.

Share your experience with others. Let people know that you are there to help.

10. Protect others.

If you host user-generated content, prevent users from posting derogatory or other abusive messages. Help remove personal information that has been exposed to hurt someone. Report offenders.

Please share your tips! This year, don’t sit by when you see abuse on social media. Offer a helping hand.

Categories
Blockchain Building Trust Identity Privacy

Is Your Reputation Safe on the Blockchain?

Over on the Consult Hyperion blog, Dave Birch has written a characteristically lucid and engaging piece about hyperbole around the idea of the mutable blockchain.

One of the use cases Dave cites (not his, I hasten to add) is the use of mutable blockchains to implement the so-called “right to be forgotten” (RTBF) – or “droit à l’oubli”, as I should perhaps call it while I am still allowed to. That prompted two thoughts which I felt deserved a blog post.

First, a quick swipe at RTBF, a label which has caused more trouble than it deserves, given the merits of the underlying principle. The Google v Spain ruling interpreted RTBF as a requirement for search engines to “de-list” search results that linked Mr Consteja Gonzales, by name, to data about one aspect of his past. The ruling also does not affect search results outside the EU.

That’s a very qualified constraint on people’s ability to find out about what happened. If you search for “Spanish guy bankrupt Google”, you should get the details faster than you can say Streisand Effect. So, as a “right to be forgotten”, this seems somewhat flimsy. And yet, it is the basis of a robust legal judgment – so what did the judges and lawmakers really intend?

One thing the Google v Spain ruling definitely doesn’t try and do is stamp out all the original instances of the data in question: one of the characteristics of the Internet is the ease and speed with which new copies of data can be published and disseminated globally. In that sense, the Internet has made such publication and dissemination almost entirely frictionless. However, readers still need to get to the information in order to read it — and, of course, it follows from the above that there is an ever-increasing mass of information out there to search through.

Seen from that perspective, the Spanish court’s qualified constraints on access to data are best explained as a re-introduction of just some of the friction which the Internet as a whole, and search engines in particular, have removed. RTBF is really “the right to have some information made slightly more inconvenient to retrieve”. Which is so catchy, I can’t really understand why “the right to be forgotten” ever caught on in the first place.

All that said, what I think this shows is that the technical “fix” (redacting the results of some online searches) is a rather clumsy and only partially effective way to achieve the desired social result, which is that the individual’s reputation should not be inappropriately sullied by inaccurate or irrelevant data which happens to be easy to retrieve.

Clumsy or not, I can’t see any sensible way of applying blockchain technology to this problem that makes it any better. In fact, the idea that your Internet search results are based on a cumulatively-signed consensus among, say, the major search engines and the libel courts is mind-boggling, to put it mildly.

Now, on to my second thought.

When I’ve talked about identity and privacy over the past decade or so, I have noted that they are a function of social interaction. Almost exactly three years ago, Vint Cerf observed that he thought privacy was probably an anomaly. I disagreed, and set out some of the reasons why in a blog post which, I think, remains relevant. I don’t think an expectation of privacy is an anomaly, because I don’t think social interaction is an anomaly.

However, to recap briefly from that post: social interaction has some characteristics which it is proving hard to replicate in our technically mediated online lives. If you live and work in a small village, you might have less expectation of privacy, but since people have to get along with each other in the long term, past indiscretions might be forgiven and forgotten, especially if the individual concerned demonstrates remorse and better behaviour.

Over time, in other words, people develop a reputation, based on one’s past experience of them, the narratives constructed by others, information in the public domain, and so on. And this, I think, is where we come to the point of intersection with the example that Dave Birch cited (and rightly dismissed), about using a mutable blockchain to implement the “right to be forgotten”.

First, I absolutely agree with Dave’s argument that, in the ledger use-case, the way to deal with an incorrect ledger entry is to leave it exactly as it is, and append a corresponding correcting entry when the error is discovered. That way, you balance the books.

But what does “balancing the books” mean, if the blockchain is being used, not for an ledger of accounts, but to record information that contributes (positively or negatively) to an individual’s reputation? What is the right way to correct an entry that is recognised as being wrong? Let’s make it a bit less abstract.

Suppose that the blockchain in question is a record of someone’s ratings as a Seller on an auction site. Most of them are 100% positive, but then there’s one which is dreadful: “Terrible service; goods arrived late, I was wrongly charged, and the product fell apart. I will never buy from this seller again, and neither should you. 0/5” Then it turns out that this review was actually meant for another seller.

What’s the right way to make a correction? Is it to go back and delete the entry, or to leave it in place but ensure that it can only be viewed in conjunction with a full retraction and an explanation that it was a review of someone else?

Either way, what do you do about the Seller’s cumulative reputation score? In the ledger example, a correcting entry balances the books – but in this case, a simple correcting entry of 5/5 can’t restore the Seller’s perfect record of 100% satisfaction scores, and 10/5 isn’t a realistic option.

So, the accounting ledger isn’t a useful design template in this case. We’re not looking for a technical solution that balances the books, we’re trying to manage the effect on someone’s reputation of the data that is recorded about them.

Like trust, reputation is something which is hard to accrue and easy to forfeit. There’s an asymmetry there, which explains why the “balancing” entry to a reputation-damaging assertion cannot simply be a statement of the opposite.

Is the answer, then, to delete the original entry? Well, that might work in the hypothetical I’ve constructed (where the original entry was simply mistaken); but suppose the original entry was true, and the seller not only rectified the error, but did it so graciously that the customer was delighted. Deleting the truthful original entry, in that case, seems wrong – but neither do we want to leave the possibility that it might be seen and taken as definitive. Is the correct action to ensure that the original review can only be viewed in tandem with updates that explain the subsequent outcome? Here, a “balancing” entry might be part of the answer, but doesn’t seem to be enough on its own.

In other words, just as in the RTBF case, we are trying to replicate several nuanced features of social interaction (reputation, forgiveness, restitution…) using clumsy technical tools which simply don’t fit.

Blockchain might be the best possible technology for implementing crypto-currencies, but be a lousy way to try and build a reputation management system. Blockchain may be a perfectly good hammer, but I wish its fans would stop trying to re-cast every online trust problem as a nail.

Categories
Encryption Identity Improving Technical Security Privacy

Two New Policy Briefs Available Now: Encryption and Identity

We are pleased to announce the publication of our latest two policy briefs on Encryption and Identity. This is part of our commitment from last year to produce content on various policy issues relating to the Internet. Our policy briefs series aims to assist policy makers (and anyone else interested) to understand current trends and discussions as they take place.

In the Encryption brief, we provide some key considerations and guiding principles for discussions around encryption. Our position is that while the concerns of law enforcement agencies are valid, we are still firm in our conviction that encryption is an important technical solution that all Internet users should use to protect their communication and data.

Similar, in the Identity brief, we take the view that governments should:

  1. continue to encourage the open development and use of new technologies to express identity on the Internet, whether they are identified, pseudonyms, or anonymous; and
  2. refrain from activities that might stifle innovation or economic and social progress. An example would be mandating the level of identification required to access the Internet or social media.

French and Spanish translations of these two briefs will follow shortly. All of our Policy Briefs are available at:  dev.internetsociety.org/policybriefs

These documents are licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. You are welcome to share and re-use these documents as long as you link back to our site and abide by the other terms of the license.