Subject: Re: [kitten] Status of SAML-EC draft and open issues

From: Simon Josefsson <[email-masked]>
Date: Mon, 26 Mar 2012 19:07:41 +0200

"Cantor, Scott" <[email-masked]> writes:

> An additional item identified by the work was the absence of proper
> guidance on mechanism name handling, which I had identified a while ago as
> something that needed attention. The acceptor side will be based on
> GSS_C_NT_HOSTBASED_SERVICE, but there needs to be language added on
> mapping that to and from SAML entityID format.
>
> The initiator name needs to be expressed in terms of the SAML NameID
> element, or in its absence, some convention for representing an anonymous
> initiator (which could be carrying GSS naming attributes to actually
> identify the subject of course). So I need to define a mechanism name type
> and import/export guidance.
>
> I'm curious how that can be left out of the non-EC SAML mechanism, which
> has the same problem, seems to me. (Same goes for OAuth and OpenID, IMHO,
> though not in terms of SAML obviously.)
>
> Anyway, I'm going to be doing some work to draft something on that
> shortly. If I'm right that this problem applies to the non-EC mechanism,
> I'm of course willing to discuss something in common with those authors.

I recall we drafted something related to this earlier, see draft below,
but maybe it was never posted or pursued.  Does it address the issue?
I'm not sure I see how this is essential for implementations though?
Does it have to be any normative part of the SASL-SAML specification?

/Simon

Network Working Group                                       S. Josefsson
Internet-Draft                                                    SJD AB
Intended status: Informational                           August 14, 2010
Expires: February 15, 2011

                SAML Entity Identifier GSS-API Name Type
                draft-josefsson-gssapi-saml-nametype-00

Abstract

   This document specify a new GSS-API name type and associated syntax
   to represent SAML Entity Identifiers.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 15, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Josefsson               Expires February 15, 2011               [Page 1]

Internet-Draft  SAML Entity Identifier GSS-API Name Type     August 2010

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  SAML Entity Identifier Name Form  . . . . . . . . . . . . . . . 3
   3.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Copying conditions  . . . . . . . . . . . . . . . . . . . . . . 3
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 3
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3
   7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 4

Josefsson               Expires February 15, 2011               [Page 2]

Internet-Draft  SAML Entity Identifier GSS-API Name Type     August 2010

1.  Introduction

   The Generic Security Service Application Program Interface (GSS-API)
   [RFC2743] specify name types for use in various situations, but none
   is applicable to Security Assertion Markup Language (SAML)
   [OASIS.saml-core-2.0-os] that uses Uniform Resource Identifier (URI)
   [RFC3986] syntax for Entity Identifier.  This document specify a new
   GSS-API name type and form to represent SAML Entity Identifier.

2.  SAML Entity Identifier Name Form

   This name form shall be represented by the Object Identifier
   1.3.6.1.4.1.11591.4.7.

   The recommended symbolic name for this type is
   "GSS_C_NT_SAML_ENTITYID".

   This name type is used to represent services associated with a SAML
   Entity Identifier.  The name form syntax is a URI.  For example:

        https://idp.example.org/SAML2

   There is no canonicalization process, every valid URI input is a
   valid mechanism name form.

3.  Acknowledgements

   The document was created as a result of discussions with Scott Cantor
   and Nicolas Williams.  TBA.

4.  Copying conditions

   This document should be considered a Code Component, and is thus
   effectively available under the BSD license.

5.  Security Considerations

   TBW.

6.  IANA Considerations

   None.

Josefsson               Expires February 15, 2011               [Page 3]

Internet-Draft  SAML Entity Identifier GSS-API Name Type     August 2010

7.  Normative References

   [RFC2743]  Linn, J., "Generic Security Service Application Program
              Interface Version 2, Update 1", RFC 2743, January 2000.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [OASIS.saml-core-2.0-os]
              Cantor, S., Kemp, J., Philpott, R., and E. Maler,
              "Assertions and Protocol for the OASIS Security Assertion
              Markup Language (SAML) V2.0", OASIS Standard saml-core-
              2.0-os, March 2005.

Author's Address

   Simon Josefsson
   SJD AB
   Hagagatan 24
   Stockholm  113 47
   SE

   Email: [email-masked]
   URI:   http://josefsson.org/

Josefsson               Expires February 15, 2011               [Page 4]

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 26 Mar 2012 17:14:38 +0000

>but maybe it was never posted or pursued.  Does it address the issue?

I don't think so. That might be something to incorporate/reuse for a small
bit of the territory, but it leaves out:

- converting between host type names and entity names, since everybody
expects to do host type names

- the initiator half

The latter is the larger concern at the moment. If nothing else, a host
type name for an acceptor can be finessed into an entityID by just relying
on the fact that pretty much all SAML implementations treat entityIDs as
strings anyway.

>I'm not sure I see how this is essential for implementations though?

Treatment of initiator names isn't essential?

>Does it have to be any normative part of the SASL-SAML specification?

I'm not presuming to speak for others on it yet, I'm not familiar enough
with GSS apps. If it is, I'm fine with doing a separate draft for reuse of
the language.

-- Scott

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 26 Mar 2012 21:44:31 +0000

I'd still welcome comment, but after a little more thinking about it, I
think I can convince myself that the other SAML mechanism avoids the
concern over initiator name handling because it's not part of the GSS
mechanism itself.

Rather it's part of the interplay between the SAML SP implementation doing
browser SSO and the server's mechanism, which AFAIK was left unspecified.
Something in that interconnection of state has to indicate an initiator
identity to apply to the GSS context it's accepting into the server, and
while it's undoubtedly based on something in the SAML assertion, it's
really implementation specific.

That's not the case with EC. There is no unspecified component because the
SP *is* the server mechanism, so there has to be a fully spec'd mapping
from the SAML token to the initiator name.

I think that also means that this is probably not an issue for the OpenID
mech, it being similarly browser based, and is probably a matter for
specific OAuth token types in the OAuth case, but I won't presume to speak
for those.

-- Scott