Archive for the ‘Uncategorized’ Category

Web Authentication Working Draft rev 6 (WD-06)

Thursday, August 17th, 2017

Web Authentication Working Draft rev 6 (WD-06) is officially published here: https://www.w3.org/TR/2017/WD-webauthn-20170811/

NOTE: the latest official WebAuthn spec release is always available here: https://www.w3.org/TR/webauthn/ (so this presently yields WD-06)

Please also note that this spec is a Working DRAFT and will change, possibly in “breaking” ways.

WebAuthn WD-06 features several subtle-but-important changes from the prior version:
* The specification of the WebAuthn Relying Party Identifier (RP ID), and its processing, is corrected.
* Refined handling of authenticator transports in the #getAssertion algorithm
* Support for discovery of available platform authenticators
* Use of COSE algorithm identifiers and the COSE_Key format [RFC8152] for conveyance of the attested Credential Public Key (aka User Public Key).
* Attestation clarifications.
* Refined authenticator selection at credential creation time, and signaling of successful user verification at either credential creation time or assertion generation time.

HTML “inline” Diff: http://kingsmountain.com/doc/diff/diff-webauthn-index-master-tr-598ac41-WD-06–from–dda3e24-WD-05.html

PDF side-by-side text-only Diff: http://kingsmountain.com/doc/diff/diff-webauthn-index-master-tr-598ac41-WD-06–from–dda3e24-WD-05.pdf

WD-06 Release Page at github: https://github.com/w3c/webauthn/releases/tag/WD-06-20170811

HTTP cookie processing algorithm in terms of Same Origin Policy and “effective Top Level Domains (eTLDs)

Thursday, April 30th, 2015

This is a community-service posting: The purpose is to unambiguously state the specification of “cookie processing wrt public suffixes”.

Why go thru the effort of doing this: It is somewhat difficult to tease this out of the requisite specification(s) and associated documents, e.g., [RFC6265] and the effective Top Level Domain List, and so here it is (corrections/comments welcome)..

HTTP cookie processing algorithm in terms of Same Origin Policy and “effective Top Level Domains (eTLDs)” aka “Public Suffixes”

=JeffH sez: it’s long — read it anyway :)

The Death of the Internet?

Tuesday, July 24th, 2012

The deliberately provocative title of this post is also the deliberately provocative title of a new book, conceived and edited by colleague Markus Jakobsson, that’s now available:

The Death of the Internet
http://onlinelibrary.wiley.com/book/10.1002/9781118312551

The book analyzes the overall problem of criminal activity on the Internet—namely fraud—and its ensuing damage. It then goes on to examine how criminals profit, how the Internet’s systems work and fail, and issues in the mobile and physical worlds. It concludes by outlining various solution proposals, examining the crucial role of user experience, and poses a set of guiding questions to ask ourselves as we go forward. The essential premise is that we collectively need to keep fraud under control or we risk losing the open freely generative Internet as we know it.

The book sections are authored by a broad cross-section of Web and Internet security researchers and engineers from across academia and industry. They collectively present a detailed multifaceted picture of the spectrum of issues and solutions.

I and Andy Steingruebl co-authored a chapter entitled “Web Security Remediation Efforts” describing aspects of overall web security issues and on-going efforts in, for example, the W3C and IETF to address them.

=JeffH sez check it out :)

HSTS implemented in Firefox 4 and Chrome

Thursday, October 28th, 2010

In terms of HSTS implementations, it’s now been implemented in the mainline Firefox code by Sid Stamm, and is supported in the Firefox 4 beta 6 and later. Note that HSTS is already a feature in Google Chrome as of version 4.

=JeffH sez check it out 😉

HTTP Strict Transport Security and the IETF WebSec Working Group

Thursday, October 28th, 2010

The HTTP Strict Transport Security (HSTS) spec is now an IETF Internet-Draft, and available here (for now; more about that below): http://tools.ietf.org/html/draft-hodges-strict-transport-sec

We had a successful “HASMAT” (for “HTTP Application Security Minus Authentication & Transport”) BoF at IETF-78 Maastricht last July, which has resulted in the formation of a new IETF Working Group: WebSec. Plus, the HSTS spec, and two others, were adopted as working group items.

Yea!

So this means I need to get off my butt and edit the HSTS spec such that it’s a proper “working group (internet-)draft” and get it published….

The Need for a Coherent Web Security Policy Framework

Thursday, October 28th, 2010

Back in May (apologies for latency, we’ve had a busy summer/fall), Andy Steingruebl and I presented our paper, “The Need for a Coherent Web Security Policy Framework” (slides), at the Web 2.0 Security and Privacy 2010 Workshop. It seemed to be relatively well received (the abstract is below). There were a number of interesting papers at the workshop, browsing the workshop pages is encouraged :)

Since then, we’ve been waving our paper around and pursuing the action items outlined therein with some modest success, which I’ll outline in subsequent posts.

=JeffH sez check it out…

    Abstract

Web-based malware and attacks are proliferating rapidly on the Internet. New web security mechanisms are also rapidly growing in number, although in an incoherent fashion. In this position paper, we give a brief overview of the ravaged web security landscape, and the various seemingly piece-wise approaches being taken to mitigate the threats. We then propose that with some cooperation, we can likely architect approaches that are more easily wielded and provide extensibility for the future. We provide thoughts on where and how to begin coordinating the work.

Strict Transport Security specification

Saturday, September 19th, 2009

I can’t do a detailed post right now, pointing to announcement message and the spec itself will have to do. This is what I’ve been working on since joining PayPal…

fyi: Strict Transport Security specification
http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1148.html

draft-hodges-strict-transport-sec-05.plain.html
http://lists.w3.org/Archives/Public/www-archive/2009Sep/0051.html

This specification embodies and refines the approach proposed in..

ForceHTTPS: Protecting High-Security Web Sites from Network Attacks
https://crypto.stanford.edu/forcehttps/forcehttps.pdf

=JeffH sez check it out!

Change of Affiliation: =JeffH -> PayPal InfoSec Team

Saturday, September 19th, 2009

Ok, my apologies for latency, this is somewhat old news, but I haven’t as yet “announced” it: I landed at PayPal, in the Information Risk Management organization under Michael Barrett (“InfoSec Team” for short), back in March.

I’m very excited to be working at one of the premier web-based organizations and also directly in the security end of things. I now get to be involved in the adoption and deployment of the various online identity and security technologies I’ve been contributing to for many years, as well as contribute to carrying them forward, and also learn some new things.

The latter has been a fair bit of work and steep learning curve as it has involved “web (in)security”, which is a vast swamp involving XSS, CSRF, response-splitting, clickjacking, etc. (hence my crawling into a cave the last several months). And not least, I’ve been very much enjoying meeting and working with key folks involved in web security and browser implementation.

And so with the public announcement of the first web security specification that I’ve contributed to (see next post), it seemed I ought to really pop this frame to the top of the stack and get it out there 8^).

Towards Kerberizing Web Identity and Services

Wednesday, February 4th, 2009

Some colleagues (Josh Howlett, Leif Johansson, RL “Bob” Morgan) and I had the good fortune to help the MIT Kerberos Consortium (MITKC) with some analysis and strategy planning for the (broad) topic of “Kerberos and the Web”, during this last Fall 2008. The main deliverables of this project are this document..

Towards Kerberizing Web Identity and Services
http://kerberos.org/software/kerbweb.pdf

..and this presentation..

Kerberos for the Web: Current State and Leverage Points
http://kerberos.org/events/Board-11-3-08/4-KerberosandWeb.pdf

..given at the MITKC’s Financial Services Security Summit and MIT Kerberos Consortium Executive Advisory Board Meeting last Fall.

Of course, these documents may not make much sense if one doesn’t know what Kerberos is, so if that’s the case, this brief tutorial ought to be helpful, as well as the Kerberos entry on Wikipedia. Additionally, the MITKC has published a series of Kerberos whitepapers outlining Kerberos’ role(s) in the Big Picture of information systems in general, as well as various best practices.

That said, the MITKC’s announcement of the document provides overall rationale for their Kerberos-on-the-Web project. They have also established a new public mailing list for technical discussions on this topic.

Additionally, here’s the salient portions of the paper’s abstract..

Today authentication and authorization are addressed in an incoherent, and often site-specific, fashion on the Internet and the Web specifically. This situation stems from many factors including the evolution, design, implementation, and deployment history of HTTP and HTTP-based systems in particular, and Internet protocols in general.

Kerberos is a widely-implemented and widely-deployed authentication substrate with a long history in various communities and vendor products. Organizations that currently use Kerberos as a key element of their infrastructure wish to take advantage of its unique benefits while moving to Web-based systems, but have had limited success in doing so.     …

In this paper we outline the evolution of Web Identity and Services and describe the issues surrounding this complex landscape. These issues are captured within a set of more specific requirements that are deemed necessary to satisfy the relevant stakeholders; these requirements are then framed within the context of some general use cases. We then propose and describe a number of activities that leverage Kerberos to realize these improvements, and present an overall strategy and architectural model for working towards a more cohesive and widely deployed Kerberos-based Web authentication infrastructure.

Casual readers may find the section entitled A Short History of Web Identity and Services interesting, while those desiring the gory details as well as the identified opportunities will benefit from reading the entire paper. Here’s the overall summary illustration..

Summary of opportunities for Kerberos and the Web Architecture

Summary of opportunities for Kerberos and the Web Architecture

In concluding, we recommend that in conjunction with developing an overall strategy and architecture with stakeholders, that the MITKC ought to initiate at least these activities..

  • Specify the use of Kerberos with TLS
  • SAML-in-Kerberos: Extend Kerberos to permit the inclusion of a SAML assertion in KDC issued authorization data
  • Kerberos-in-SAML: SAML profile supporting the generation of SAML assertions containing Kerberos tickets
  • Update WS-Security Kerberos Token Profile specification
  • Leverage SAML metadata to enable large-scale Kerberos cross-realm communities”), and
  • Investigate, document and promote existing methods of using Kerberos to authenticate against a SAML identity provider

Discussion of this paper and the MITKC’s overall Kerberos-and-the-Web project occurs on the (new) mitkc-web@mit.edu mailing list. Feel free to subscribe and join in.

OAuth Protocol Flow Diagrams

Wednesday, October 22nd, 2008

I found the existing protocol flow diagram in the current OAuth spec..

OAuth Core 1.0
http://oauth.net/core/1.0/

..somewhat hard to follow. So I concocted three separate new ones using the so-called “swimlane” technique that I’m used to.

I posted these to the OAuth list a while back, and a few folks reposted them to their blogs, but no one has yet piped up to say I got anything wrong. But YMMV, there might be bugs in here.

FWIW, I’ve posted them below in case others find them useful. Also, I have them in a single file..

http://identitymeme.org/doc/draft-hodges-oauth-05-figures.txt

..also featuring OpenID and SAML Web Browser SSO Profile diagrams for comparison purposes. Note that in all things protocol, definitions of terms are essential in order to be able to effectively communicate and reason about protocols, so I’ve included key definitions from the OAuth spec in the file.

NOTE: fixed-pitch font required for viewing. Also, wordpress is obviously messing up the diagrams below, and they consequently look sorta lame, here on the blog. This site presently uses an old wordpress install, maybe this will help motivate me to upgrade it. In the meantime, check out the file linked-to above for the best viewing experience 😉

Fig 1: out-of-band consumer setup/config

                                           photos.example.net
                                             +----------+
                                             |          |
                                             | OAuth    |
                                             | service  |
                  printer.example.com        | provider |
                      +---------+            |          |
                      |developer|            |  Sys     |
                      |   of    |            |  Admin   |
                      | OAuth   |            |          |
                      |consumer |            |          |
                      |         |            |   [SP]   |
                      +----+----+            +----+-----+
                           |                      | 
                           | obtain Consumer Key  |
                           | and Consumer Secret  |
                           | [details unspec'd,   |
                           |  performed out-of-   |
                           |  band.]              |
                           |--------------------->| 
                           |< ---------------------|
                           |                      | 
                           |                      |

Fig 2: "Web-based consumer"

The "consumer" is a website or other application that accesses 
the Service Provider on behalf of the wielder (user) of the user agent 
(UA is typically a browser, but could be some other app). 

Steps 1.n.  "Obtain Unauthorized Request Token"
      2.n.  "User Authorizes Request Token"
      3.n.  "Exchange Request Token for Access token"
      4.n.  UA accessing protected resources at SP
      
      

                                           photos.example.net
                                             +----------+
                                             |          |
                                             | OAuth    |
                   printer.example.com       | Service  |
                       +--------+            | Provider |
                       |        |            |          |
                       | OAuth  |            |[protected|
                       |Consumer|            |resources]|
 +----+                |        |            |          |
 | UA |                |  [RP]  |            |   [SP]   |
 +-+--+                +---+----+            +----+-----+
   |                       |                      |
   | 1.0. User Agent inter-|                      |
   | acts with Consumer    |                      |
   | site [optional]       |                      |
   |< --------------------->|                      |
   |                       |                      |
   |                       |                      |
   |                       |                      |
   | 1.1. UA informs/directs                      |
   | Consumer to do something                     |
   | with a resource (e.g. |                      |
   | a photo) at SP        |                      |
   |---------------------->|                      |
   |                       |                      |
   |                       |                      |
   |                       |                      |
   |                       | 1.2. Consumer attempts
   |                       | accessing photo at SP|
   |                       |--------------------->|
   |                       |                      |
   |                       |                      |
   |                       | 1.3. SP replies with |
   |                       | a HTTP 401 containing|
   |                       | a "OAuth" www-authn  |
   |                       | header field         |
   |                       |< ---------------------|
   |                       |                      |
   |                       |                      |
   |                       | 1.4. Consumer replies|
   |                       | with a request for   |
   |                       | "unauthorized Request|
   |                       | Token" (uRT) via POST|
   |                       | to SP's "request token
   |                       | URL"                 |
   |                       |--------------------->|
   |                       |                      |
   |                       |                      |
   |                       | 1.5. SP issues uRT & |
   |                       | token secret to      |
   |                       | Consumer.            |
   |                       |< ---------------------|
   |                       |                      |
   |                       |                      |
   |                       |                      |
   | 2.0. Consumer redirects                      |
   | UA to SP "User Author-|                      |
   | ization URL" including|                      |
   | the uRT.              |                      |
 +<- - - - - - - - - - - - |                      |
 . | (indirected via UA)   |                      |
 . |                       |                      |
 +-------------------------+--------------------->|
   |                       |                      |
   |                       |                      |
   |                       |                      |
   |                       |                      |
   | 2.2. User authenticates with the Service     |
   | Provider (optional, methods vary, realization|
   | is out of scope)                             |
   |< ============================================>|
   | 2.3. User grants or declines permission      |
   | for the Service Provider allow Consumer      |
   | access to the resource (e.g. photo).         |
   |                       |                      |
   |                       |                      |
   |                       |                      |
   |                       |                      |
   | 2.4. If permision granted, UA redirected back|
   | to Consumer's "Callback URL", conveying the  |
   | uRT.                  |                      |
 +< - - - - - - - - - - - - - - - - - - - - - - - -|
 . | (indirected via UA)   |                      |
 . |                       |                      |
 . |                       |                      |
 +------------------------>|                      |
   |                       |                      |
   |                       |                      |
   |                       |3.0. Consumer requests|
   |                       |Access token, supplies|
   |                       |uRT.                  |
   |                       |--------------------->|
   |                       |                      |
   |                       |                      |
   |                       |                      |
   |                       |3.1. SP grants Access |
   |                       | Token.               |
   |                       |< ---------------------|
   |                       |                      |
   |                       |                      |
   |                       |4.x. Consumer uses the|
   |                       |Access Token, Access  |
   |                       |Token Secret, Consumer|
   |                       |Key, and Consumer Secret
   |                       |to make authenticated |
   |                       |request(s) to the Service
   |                       |Provider.             |
   |                       |=====================>|
   |                       |           .          |
   |                       |           .          |
   |                       |           .          |
   |                       |                      |



Fig 3: “desktop-based consumer”


this is case where user is wielding some app that is both a UA and a Consumer.


                                             +----------+
                                             |          |
                                             | OAuth    |
                                             | service  |
 +--------+                                  | provider |
 |        |                                  |          |
 |Desktop-|                                  |[protected|
 |based   |                                  |resources]|
 |Consumer|                                  |          |
 |        |                                  |          |
 | UA     |                                  |   [SP]   |
 +-+------+                                  +----+-----+
   |                                              |
   | 1. Consumer requests "unauthorized Request   |
   | Token (uRT)" with POST to SP's "request token"
   | URL.                                         |
   |--------------------------------------------->|
   |                                              |
   |                                              |
   | 1.1. SP issues uRT and Token Secret to       |
   | consumer.                                    |
   |< ---------------------------------------------|
   |                                              |
   |                                              |
   |                                              |
   | 1.2. User authenticates with the Service     |
   | Provider (optional, methods vary, realization|
   | is out of scope)                             |
   |<============================================>|
   | 3. User grants or declines permission        |
   | for the Service Provider to issue Access     |
   | Token.                                       |
   |                                              |
   |                                              |
   |                                              |
   |                                              |
   | 4. Service Provider authorizes the uRT to be |
   | exchanged for an Access Token and secret.    |
   |< ---------------------------------------------|
   |                                              |
   |                                              |
   |                                              |
   | 5. Consumer exchanges the uRT and secret     |
   | for an Access Token and Secret.              |
   |--------------------------------------------->|
   |< ---------------------------------------------|
   |                                              |
   |                                              |
   |                                              |
   | 6. Consumer uses the Access Token, Access    |
   | Secret, Consumer Key, and Consumer Secret    |
   | to make authenticated request(s) to the Service
   | Provider                                     |
   |<============================================>|
   |                      .                       |
   |                      .                       |
   |                      .                       |
   |                      .                       |
   |                      .                       |
   |                      .                       |
   |                                              |