Subject: SAML GSS-API name type

From: Simon Josefsson <[email-masked]>
Date: Fri, 13 Aug 2010 23:58:01 +0200

I posted this privately to Scott but I believe wider discussion would be
useful, so I'm posting my strawman specification on a SAML GSS-API name
type.  What do people think of it?

The open issues I can see are:

* It is not clear to me if it has to be restricted to SAML RPs.  It
  could be broadened by saying "SAML end-points" since the entityId is
  also used to identify IdPs (right?).

  I prefer to be conservative about broadening the scope until there is
  justification for it, though.  GSS-API normally only concerns clients
  and servers, and I don't believe an IdP could be regarded as either.

  The scope could be broadened even further by defining a GSS_C_NT_URI
  name type instead, which would hold a URI for arbitrary usage.  It
  could be used for both OpenID and SAML.  This seems a bit risky
  though, but reduces implementation costs.

* More details about SAML entityID canonicalization is required.

There may be more issues to consider...

/Simon

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

               GSS-API Name Type For a SAML Relying Party
                draft-josefsson-gssapi-saml-nametype-00

Abstract

   This document specify a new GSS-API name type and associated syntax
   intended for identifying a SAML Relying Party.

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 14, 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 14, 2011               [Page 1]

Internet-Draft          SAML RP GSS-API Name Type            August 2010

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  SAML Relying Party Name Form  . . . . . . . . . . . . . . . . . 3
   3.  Copying conditions  . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 3
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 3
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 4

Josefsson               Expires February 14, 2011               [Page 2]

Internet-Draft          SAML RP 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) Relying
   Partys which are identified by a entityID Uniform Resource Identifier
   (URI) [RFC3986].  This document specify a name type and associated
   syntax for use when identifying SAML Relying Party end-points.

2.  SAML Relying Party 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_RP".

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

        https://idp.example.org/SAML2

   XXX: How does canonicalization work?

3.  Copying conditions

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

4.  Security Considerations

   TBW.

   XXX: Canonicalization needs to be secure -- no insecure DNS.

5.  IANA Considerations

   None.

6.  Normative References

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

Josefsson               Expires February 14, 2011               [Page 3]

Internet-Draft          SAML RP GSS-API Name Type            August 2010

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

Author's Address

   Simon Josefsson
   SJD AB
   Hagagatan 24
   Stockholm  113 47
   SE

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

Josefsson               Expires February 14, 2011               [Page 4]

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 13 Aug 2010 17:05:47 -0500

>   and servers, and I don't believe an IdP could be regarded as either.

I don't agree.  See Sam's and my concerns about the naming extensions
draft.  One of them is that name attributes need to have an associated
"issuer name" meta-attribute.

Name of Kerberos realm, name of IdP, name of CA, ... -- these are all
"issuer names", and they are very much relevant.  As is "trust path",
which I'd envisioned as a name attribute -- trust paths are... sequences
of issuer names.

>   though, but reduces implementation costs.

For names to be useable by users there must be a user-friendly name
syntax and a realistic process for canonicalizing user-input names.

You can use anything you want for canonical names.  For example, OpenID
URLs would be fine.  But you can't expect users to type those in in any
UIs (heh; imagine users shortening OpenID URLs with URL shortening
services!)

> * More details about SAML entityID canonicalization is required.

Yep!

Nico
--

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 13 Aug 2010 18:22:07 -0400

> type.  What do people think of it?

Simon, I just sent you a response, you can forward that to the list if you
like.

>   also used to identify IdPs (right?).

It should be cast as "this is how to represent a SAML entityID", formally
referencing the definition of that concept in SAML core, 8.3. It isn't
necessary to define when that would be used, that's a SAML issue.

>   though, but reduces implementation costs.

It's important to communicate the semantics of names, not just the syntax.
OpenIDs and SAML entityIDs are not at all the same, so they shouldn't be
represented as such.

> * More details about SAML entityID canonicalization is required.

To give me a leg up, could you point a newbie at the relevant RFCs to help
me understand the underlying requirements?

-- Scott

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 14 Aug 2010 00:31:02 +0200

> Simon, I just sent you a response, you can forward that to the list if you

I'll quote one relevant part below.

> necessary to define when that would be used, that's a SAML issue.

I like this approach better.

> OpenIDs and SAML entityIDs are not at all the same, so they shouldn't be

That is my preference as well.

> me understand the underlying requirements?

Check RFC 2743 and search for "canonical".

But you said privately:

  I'll take a look. Can you give me a brief summary of what the goals of
  the c14n process here are? In general, SAML doesn't expect
  implementations to do any normalization of URIs when used as
  identifiers. They're compared as strings, so only the character
  encoding has to be addressed to compare them as binary data.

This suggests that there is no URI canonicalization process to speak of
in SAML.  Every URI is a canonical SAML entityID?  This is quite
different from OpenID which definitely specify how URIs are
canonicalized, see:

http://openid.net/specs/openid-authentication-2_0.html#normalization

This is another reason why the OpenID and SAML name types should be
specified separately for GSS-API.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 14 Aug 2010 00:35:05 +0200

> which I'd envisioned as a name attribute -- trust paths are... sequences

If the document uses Scott's suggestion to just encode a SAML entityID,
does that address your concern?  I'm not sure I understand what you are
getting at here.

> UIs (heh; imagine users shortening OpenID URLs with URL shortening

I'm not sure SAML has a concept of user-friendly names that we need to
care about?  It would certainly be simpler to just let the
canonicalization process for this name type do nothing.  If I understand
correctly, if the SAML entityIDs doesn't match completely,
authentication will not work.

>> * More details about SAML entityID canonicalization is required.

Right now I'm hoping it will be simple.

/Simon

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 13 Aug 2010 18:52:42 -0400

> in SAML.  Every URI is a canonical SAML entityID?

Yes, basically. The actual normative language explaining that is obscure and
a bit wrongly worded as it turns out, but the intent is that strings and
URIs are always compared byte for byte (assuming the same encoding) unless
something specifies differently in a profile or particular construct.

-- Scott

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 13 Aug 2010 19:00:34 -0400

> care about?

Not in scope of SAML, that's a higher order issue that would be captured in
the definition of the NameID Format or Attribute definition.

In the specific case of server names (loosely defining an entityID), they
aren't meant that way, and one doesn't tend to name entities with crazy URL
patterns that would be inclined to cause errors in matching to avoid
problems.

> It would certainly be simpler to just let the

If the scenario is that some kind of expected peer name is specified by the
client, then yes. The matching would be "make sure the encoding is in
common, then compare byte for byte".

-- Scott

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 13 Aug 2010 18:01:50 -0500

> does that address your concern?  I'm not sure I understand what you are

Yes, it does.

> authentication will not work.

But the GSS-API does have "a concept of user-friendly names that we need
to care about", at least for host-based service names (OK, that's
probably not an issue here).

> Right now I'm hoping it will be simple.

I think so: just deal with names much as Kerberos implementations do.

This should work:

	gss_canonicalize_name(saml_mech_oid,
	    gss_import_name(GSS_C_NO_OID, "<entityID>"))

so should:

	gss_canonicalize_name(saml_mech_oid,
	    gss_import_name(GSS_C_NT_SAML_ENTITYID, "<entityID>"))

Ideally there will be some user-friendly <entityID> syntax that will be
accepted and canonicalized.

This must work:

	gss_canonicalize_name(saml_mech_oid,
	    gss_import_name(GSS_C_NT_HOSTBASED_SERVICE,
	    "[email-masked]"))

gss_display_name() applied to an MN of this mechanism should produce a
raw SAML entityID.

Whether this works:

	gss_canonicalize_name(saml_mech_oid,
		gss_import_name(GSS_C_NT_USERNAME, "joe"))

is a local problem (since usernames are local).

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 14 Aug 2010 01:12:06 +0200

> something specifies differently in a profile or particular construct.

Sounds good.  Updated document below.

/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 will expire on February 15, 2011.

Copyright Notice

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

   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:

   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

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

   [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

Josefsson               Expires February 15, 2011               [Page 4]

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 13 Aug 2010 19:17:26 -0400

> probably not an issue here).

The point is that there is no way in SAML to go from something that's not an
entityID to an entityID. So if you want to specify a SAML entity, you have
to know the entityID, exactly. Anything else, DNS-based or otherwise, would
require new work to standardize somewhere.

> accepted and canonicalized.

There is no syntax other than the URI itself. Change the case, new ID. Add a
slash, new ID. Add a default port designation, new ID.

> gss_display_name() applied to an MN of this mechanism should produce a

I can't think of any simple way offhand to make that work, so that's
probably new work somewhere. And I don't foresee any obvious way short of
brute force mapping. EntityIDs aren't locations, and they can't be assumed
to correspond to DNS information in a host or service address. They're
logical names that are associated with service endpoints using SAML metadata
in a one to many way.

-- Scott

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 14 Aug 2010 01:17:38 +0200

>> does that address your concern?  I'm not sure I understand what you are

Good.

> probably not an issue here).

Ah, I see.  Let's see if anything needs to be said about that.

> 	    gss_import_name(GSS_C_NT_SAML_ENTITYID, "<entityID>"))

This should work fine now.

> accepted and canonicalized.

This doesn't work because I don't know what a user-friendly syntax would
be here.

> 	    gss_import_name(GSS_C_NT_HOSTBASED_SERVICE,

What would gss_display_name on the output of that result in?
'ldap://foo.bar.example/'?

If we want that to work, some more text around this is necessary.  It
seems a simple string transformation is sufficient, right?

  service@hostname   =>  service://hostname/

> gss_display_name() applied to an MN of this mechanism should produce a

That should also work now, I believe.

> is a local problem (since usernames are local).

I'm not sure there is a use-case for making that work, so leaving it
undefined seems simplest.

Thanks,
/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 14 Aug 2010 01:19:17 +0200

> logical names that are associated with service endpoints using SAML metadata

Good point.  I believe there is no point in making the above work at
all.  Disregard my previous suggestions on string transformations.

/Simon

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 13 Aug 2010 19:22:58 -0400

>   service@hostname   =>  service://hostname/

My previous note is a long way of saying that won't work. There is no
guarantee at all what the entityID of a service using SAML that happens to
run at service@hostname is. If there were, they would be locations, and not
names. Big difference.

In particular, many services will share an entityID, including services that
run on many different systems with different hostnames. The whole purpose of
an entityID is to abstract out of those names into something persistent and
appropriately granular (or non-granular as the case may be).

If this kind of mapping is a requirement, a lot of very thorny issues are
raised that don't have great answers.

-- Scott

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 13 Aug 2010 18:24:12 -0500

> require new work to standardize somewhere.

OK.

> logical names that are associated with service endpoints using SAML metadata

I'd settle for this working:

    target = gss_import_name(GSS_C_NT_HOSTBASED_SERVICE,
	"[email-masked]");

    gss_init_sec_context(..., target, ...);

and then have gss_inquire_context() output an MN for the acceptor for
which gss_display_name() gets you the SAML entityID.

But if even that won't work then you're kinda stuck.

When a user says "ssh somehost" and the SSHv2 negotiation uses GSS-API
for authentication, then the client will import "host@somehost" as the
target name and will pass that to gss_init_sec_context().

You could pass GSS_C_NO_NAME as the target, but then all the channel
binding in the world won't help you make sure you're not talking to an
MITM since there's nothing you can do to make sure that the GSS acceptor
you're talking to is the one that the user wanted to talk to.

What does it mean to authenticate an entity whose name is meaningless to
and unrecognizable by users??  IMO: nothing.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 13 Aug 2010 18:34:22 -0500

> raised that don't have great answers.

Well, as I just stated, and will repeat here: there is no point to
authenticating entities whose names are meaningless to, and
unrecognizable by humans.

Yes, we could have an option for the ssh command that let's you specify
the acceptor's name separately from its hostname, and then you'd
cut-n-paste from somewhere.  Or maybe ssh could do leap-of-faith
learning of hostname->entityID mappings just for the SAML mechanism.
But I don't think that's terribly usable, it's rather complicated
for users, and, IMO, pointless.

The same applies to other GSS-API applications.

Let's backtrack.

How do current non-GSS implementations of this SAML mechanism interface
the user to entityIDs?

There must be some answer.  If that answer is that we trust the TLS
server cert PKI to authenticate the host, that the entityID is then
learned from the server, and that therefore it doesn't really matter
what the entityID is... then the current mechanism is weak.

But there is hope yet!

Can we impose naming conventions on these entityIDs so that the results
are meaningful to users?

If not, and if no one else has a better idea, then consider giving up.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 14 Aug 2010 01:41:55 +0200

> and unrecognizable by users??  IMO: nothing.

Reading section 8.3 of SAML-Core [1] makes me believe we have a problem.
None of the names defined there is a normal host based name.  It has
e-mail addresses, X.509 subject names, Kerberos Principals and some
other stuff, but no host based names.

I think "ssh somehost" is a good use-case to have in mind when we think
about how the SAML GSS-API mechanism will work.

/Simon

[1] http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 13 Aug 2010 19:43:26 -0400

> you're talking to is the one that the user wanted to talk to.

I take your point, but if the client needs to know that name, it will
probably have to be provisioned into the request process alongside the
location-based designation of the service, or there would have to be a
mapping process defined.

It's doable, but it would probably want to be an implementation detail of
the client, not something the GSS layer did for it.

Since the end result of the CB is to know that the TLS server is the entity
that the IdP issued the assertion to, I don't think it would be impossible
to rely on distributed discovery (host-meta/XRD/etc) to just ask it for its
entityID. If it lied, the IdP would catch it since it couldn't generate a
valid SAML request.

-- Scott

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 13 Aug 2010 18:48:28 -0500

> other stuff, but no host based names.

If it has Kerberos principal and X.509 subject names then in a pinch we
can use those, even when Kerberos or PKIX are not used under the covers,
to represent host-based service names.  That'd be by convention.

> about how the SAML GSS-API mechanism will work.

Yes.

> [1] http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

We might be able to impose naming conventions on Persistent Identifiers.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 13 Aug 2010 18:53:48 -0500

> the client, not something the GSS layer did for it.

Any canonicalization mechanism has to be implemented in the mechanism
itself, not in the application.

In other words: ssh should require no special knowledge of SAML service
name canonicalization in order to use this mechanism.

> entityID. If it lied, the IdP would catch it since it couldn't generate a

The RP's entityID clearly must be known to or resolvable by the IdP,
since otherwise the IdP won't be able to find a key in which to encrypt
the assertion.

The IdP can then be expected to resolve host-based service names, or at
least hostnames, to RP entityIDs.  And if you can impose suitable naming
conventions, then you should be able to avoid having to add a name
resolution service.  OTOH, imposing a naming convention would mean
having to rename or re-enrol existing services in order to make them
useable through this mechanism.

I strongly recommend exploring the naming convention approach.

Nico
--

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 13 Aug 2010 20:00:54 -0400

> for users, and, IMO, pointless.

I'm not sure I have a better suggestion for you. I would claim that
experience suggests that trying to map between hostnames to credentialed
identities doesn't actually have a very successful track record outside of
perhaps Kerberos. I would hope nobody would claim DN-based server matching
is anything but a total fiasco.

> How do current non-GSS implementations of this SAML mechanism interface

There are none, so it hasn't come up. The proposals on the table as is do
not perform CB, and they assume authentication of the server is basically
out of scope. That's what we were trying to add today.

> what the entityID is... then the current mechanism is weak.

The entityID is never even seen (or at least noted) by the client in
traditional practice, since the client is normally a browser.

So yes, it's all TLS today.

> Can we impose naming conventions on these entityIDs so that the results

They won't be very meaningful no matter what we do. That's the lesson of
OpenID...taking concepts that aren't URLs and making them URLs doesn't make
them understandable to users.

-- Scott

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 13 Aug 2010 20:10:53 -0400

> since otherwise the IdP won't be able to find a key in which to encrypt

Yes, it is.

> resolution service.

Metadata is already used for this purpose in a web context. I think what has
to happen is to define some additional conventions by which the client
supplies the "service name" that it's trying to access to the IdP in a way
that's normally used to specify web locations. The IdP could then use that
to verify that the service name and the entityID lineup.

There's actually some text in my draft that mentions the field in question,
but I chose not to think too hard about it in the first draft I did.

This aspect of the problem doesn't come up with the "use a browser"
mechanism, since the IdP is only dealing with Web SSO. But there's also no
binding of any kind to the service name on the SASL side, and of course no
CB in that mechanism anyway right now.

> I strongly recommend exploring the naming convention approach.

It isn't impossible, I need to think about it.

Some of this came up in the Moonshot conversation, and the issues of service
vs. entity granularity are very sticky.

-- Scott

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 13 Aug 2010 19:12:54 -0500

> is anything but a total fiasco.

Kerberos worked because Kerberos principal names were sufficiently
flexible to begin with.

PKIX didn't because TBSCertificate uses Name for the subject and Name
uses X.500 naming, with no good naming convention for hosts at the time
that that was needed.  If PKIX has used GeneralName for the subject name
from the get-go, then we'd be using dNSName and everyone would be happy.

> out of scope. That's what we were trying to add today.

Well, then that will have to change or you will have to give up on this.

> So yes, it's all TLS today.

:(

> They won't be very meaningful no matter what we do.

Why not?  The mechanism would reject name forms that don't match the
convention.  And hopefully you could make sure that the naming
convention doesn't result in collisions with entityIDs currently in use.

>                                                     That's the lesson of

I agree about OpenID, but I believe that you _can_ have URL naming
conventions that users can understand.  For example, users understand
mailto URLs.  And they understand the hostname part of HTTP URLs (well,
ignore confusion relating to port numbers and username/password parts).

The parts of such a naming convention that would be superfluous to users
need not be any more confusing than, say, the realm name part of
Kerberos principal names (or the use of '/' to separate principal name
components).

Nico
--

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 13 Aug 2010 20:36:42 -0400

> convention doesn't result in collisions with entityIDs currently in use.

We could, but the proliferation of entityIDs (and therefore the metadata to
go with them) would be rather large. The point of entityIDs was to *not*
assume a correspondence with service endpoints, not to impose it.

I think there's a way out of this by following the line of thought I had
earlier. I think it's a mistake in general to try and stick an entityID in
front of a user. Stick with service names.

The client wants to talk to server.example.org using ssh. The server returns
a signed AuthnRequest with its service name included in the material that
the client can pull off and read. It obviously should match what the client
thinks it is.
 
The IdP should be able to obtain that from the AuthnRequest and verify, much
as it does today with web locations, that the entity asking for the
assertion is in control of that service name. It also returns the service
name it's seeing in the headers it returns to the client.

The client can cross-check and verify they match and it knows that IdP
believed it was legit, since it returned the assertion, and you have the CB,
so you can bubble that service name up as the legitimate name.

The entityID never comes into play for the client, which is how it's
designed to work today.

None of this is very "off" from the existing uses of the fields in question
in SAML. It's new work, but the CB already make it new work, and it's not
"different work" from what is implemented today.

I think the only trick is that I'd probably want to turn the service names
into URLs for transport in the messages, but *that* can be a simple
transform.

-- Scott

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 13 Aug 2010 20:43:04 -0500

> The entityID never comes into play for the client, which is how it's

Yes, this works.

OK.

> into URLs for transport in the messages, but *that* can be a simple

:)

Have a good weekend,

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 14 Aug 2010 11:36:12 +0200

> into URLs for transport in the messages, but *that* can be a simple

This sounds more robust than what we have discussed earlier.  Thanks for
explaining.

Wrt GSS-API naming, perhaps the above mean there is no strong need for a
new name type?  GSS-API applications can continue to use
GSS_C_NT_HOSTBASED_SERVICE a'la user@hostname?  The SAML mechanism will
discover the right SAML endpoint internally.  If application for some
reason wants to learn the SAML entityId used, it could be retrievable as
a name attribute.

We could also have a GSS_C_NT_SAML_ENTITYID that is the "canonical" SAML
mechanism name, and a GSS_C_NT_HOSTBASED_SERVICE is canonicalized into a
GSS_C_NT_SAML_ENTITYID by the SAML mechanism.  However, I'm not sure
when that would be useful.

/Simon

---

From: "Scott Cantor" <[email-masked]>
Date: Sat, 14 Aug 2010 13:47:12 -0400

> new name type?

Well, we have different issues in play. I don't think there needs to be a
new name type to represent services to clients, no. I think we still have to
look at the name type problem for representing users to services.

> GSS-API applications can continue to use GSS_C_NT_HOSTBASED_SERVICE a'la
> user@hostname?

I think so (though is that really how it's done? The username as part of the
service name?). Is the service type or protocol (ssh? nfs?) represented in
any way?

> The SAML mechanism will

It's unlikely that the client would ever need it, and it's totally unlikely
that the service would need its own. The entityID of the IdP may well need
to be expressible that way, and it would be a name attribute in some sense,
and definitely not the "name" of the client, since it's not. But that's a
broader discussion, probably with Moonshot/abfab involved I think.

> when that would be useful.

If conversion was needed, it would be via the same mapping process that IdPs
will have to use, namely SAML metadata. I don't anticipate any strong need
for it in clients and servers. Particularly if the point of these canonical
names is for user consumption/comparison/recognition.

-- Scott

---

From: Martin Rex <[email-masked]>
Date: Mon, 16 Aug 2010 17:20:58 +0200 (MEST)

> unrecognizable by humans.

If the idea is about **authentication** then this is exactly
about how ist MUST work.

There are tons of applications out there that don't give a damn
about authenticating the server.  They're using a very cheap and
weak server endpoint identification scheme at best.  Basically
anything derives the pattern for matching server endpoints straight
from the network endpoint address does not perform authentication
of the server.

The only Kerberos-derivative protocol that I'm aware of that is
designed to perform secure server authentication is DCE when using
the secure directory service to resolve the network endpoint for
a server, *AND* an unrelated(!!) secure identity for the server
along with it.

The pupose of the name canonicalization is for creation and
maintenance of ACLs by application.  As an service, you usually
want to be sure the you have exact matches for you ACL, not just
some vague pattern matching, and you want efficient ACL lookups,
not linear searches matching against patterns.

A real secure mutual authentication will let you do this symmetrically
in both ways, i.e. the authentication of the server should be done
in the same quality, and servers should be able to use their
server accepting credentials (and the canonical identity of that
credential) to perform client requests and be authenticated similar
to how users are authenticated with their canonical name.

If you look at Kerberos 5 through GSS-API, the only thing that
a GSS-API based application sees is a Kerberos 5 principal name
(involving a Kerberos Realm).  Crossrealm trust and traversal
of KDCs is entirely irrelevant at the GSS-API level because it
is not visible there.

Aside from Kerberos, there are a number of (mostly proprietary)
variants of SPKM (The Simple Public Key mechanism) out there,
GSS-API mechanism based on X.509 certs and PKI.  Most of those
that I know emit exactly and only the subject DName of the certificate,
This means that they work only with a tightly controlled PKI with
a single CA, or of more than one CA is involved, then with a
set of CAs where the Naming of End Entities and Servers is
guaranteed to be non-colliding, either through administrative
procedures or a single RootCA with name constraints (and working
support for name constraints in all involved implementations).

Concerning the naming of servers:

I do consider the SSH leap-of-faith approach on first connect a
workable concept.  And it is defintely more secure than anything
in the area of "hostbased service names" or "TLS server endpoint matching".

Servers in SSH are identified by their public keys, and that's what
is being stored _and_ used in every client-side ACL for secure
(re-)authentication.  traditionally a file called "$HOME/.ssh/known_hosts".
End users don't have to memorize public keys, instead they normally
use a local secure lookup of the server identity, and for convenience,
they often use the hostname as the lookup key.  But there is a significant
difference between looking up a peer's canonical identity in a secure(!)
local directory (like your $HOME/.ssh/known_hosts) and performing
an extremely weak endpoint identification such as doing lazy pattern
matching as with TLS server certificates or doing the traditional
insecure canonicalization of the servername through DNS as done
by Kerberos 5 as documented in rfc-2743 for hostbased service names:

http://tools.ietf.org/html/rfc2743#page-86

> for users, and, IMO, pointless.

That would be very usable and very sensible.

Web Browsers are doing leap-of-faith on each and every connect
unless you flush all of their trust anchors and go through the
painful scary page for accepting a server's certificate for
each and every server.  And some browsers were broken in that
they didn't memorize for which server a user accepted the server
certificate and would trust it being served from any host
after accepting it.  I don't know which browsers suffered from
this and whether/when this was patched.  It definitely was a
serious bug.

-Martin

---

From: Greg Hudson <[email-masked]>
Date: Mon, 16 Aug 2010 12:17:29 -0400

> in the area of "hostbased service names" or "TLS server endpoint matching".

I've heard from a lot of people who find the SSH approach at least as
weak as the commercial TLS approach, and for the same reason: it asks
users to make a decision based on parameters they can't understand and
information they don't know.  In environments with a lot of hosts which
are frequently reinstalled, it's the same as no service authentication
at all.

> But there is a significant

There are certainly more secure approaches to service name
canonicalization than insecure DNS.  I believe Microsoft AD deployments
use one such.

---

From: Martin Rex <[email-masked]>
Date: Mon, 16 Aug 2010 19:49:51 +0200 (MEST)

> are frequently reinstalled, it's the same as no service authentication

There are many possible solutions to every key distribution problem.

Even when re-installing, carrying over the host key is quite possible.
For those admins that would like to replace the host key on each re-install,
a redistribution of the new key through a central known_hosts file to
end-users machines would be another alternative (e.g. /etc/ssh/known_hosts).
No admin is required to create the worst possible user experience.

The security model currently shipping with Web-Browsers is based
on faith, and the entire leap-of-faith is repeated for each and
every connect.  Which browser currently offers you to manually
verify the organization identified by the certficate for a
particular web site and mark this server cert as "trusted",
and gives you a visual clue about this whenever you visit that
site again?  I'm not currently aware of a browser that does this,
although this feature could obviously cut down the number of
leap-of-faiths of everyone's everyday usage considerably,
and limit the vulnerability to very few inital leap-of-faith
situations.

Afraid of weak md5-based signature algorithms?  no more.
Afraid of integer-overflow in AVA-OIDs of Subject DNames
because of poor vetting of DName contents?  no more.
Afraid of '\0' characters in CN= of server certs?  no more.

This list goes on and on, and there are likely going to be
new things added every year that would be much harder to exploit
if users were able to manually confirm server certificates and
browsers would memorize this and warn about changes.

But this might interfere with the business models of CAs, and
TLS server certificate and TLS in Web Browsers is first of all about
business models, rather than about end users and true security.

> canonicalization than insecure DNS.  I believe Microsoft AD deployments

Yes.  But Microsoft deployments have the other drawback that running
multiple instances of a distributed service with Microsoft Kerberos
authentication is a security problem (vulnerable to replay attacks).

Unless you use user2user authentication exclusively, which avoids
the necessity to share replay caches cross hosts -- but that option
may not be available (AFAIK, user2user does not work with rfc4559
HTTP Negotiate).  Although Microsoft has been shipping an implementation
of user2user authentication for use with SSPI since Windows 2000, it
has not yet been standardized for the Kerberos 5 GSS-API mechanism.

Hostbases service names are a hack to accomodate optimizations in the
Kerberos authentication exchange.  Sharing replay caches across multiple
backend machines is too difficult, so a necessity to distinguish
instances of a service on different hosts with different credentials
and therefore different hostbased service names.

You have much more freedom in the backend architecture of a distributed
service when it doesn't matter for the client to which particular
instance of a service it is talking, because they're all authenticating
with the exact same identity.  Doing NAT-style load-balancing or
giving out IP-Addresses round-robin through DNS both don't work
with traditional Kerberos.  

-Martin

---

From: Greg Hudson <[email-masked]>
Date: Mon, 16 Aug 2010 15:49:32 -0400

> No admin is required to create the worst possible user experience.

Authentication of services certainly gets easier if you assume the site
admin has provided each client out of band with a flat file containing
all of the service public keys.  I don't get the impression that many
admins are fond of that requirement, though.

> I'm not currently aware of a browser that does this,

What you describe would make it easier for knowledgeable users to detect
wholesale forgery of SSL certificates--such as if one of the several
hundred CAs started issuing bogus certs.

I don't think average users would be able to interpret any information
that you'd be able to convey, and would generally interpret warn-on-
certificate-change to be meaningless and frequent noise, just like they
do SSH's warn-on-host-key-change.  (Frequent if for no other reason than
certificates tend to get renewed once a year, and users visit lots of
web sites.)

> authentication is a security problem (vulnerable to replay attacks).

This is a valid criticism of Kerberos, but not a fundamental problem of
service authentication.  Replay attacks are best thwarted by requiring
both sides of an exchange to contribute fresh key information, not
through replay caches.  So I don't see how this is relevant to the
larger question.

> You have much more freedom in the backend architecture of a
> distributed service when it doesn't matter for the client to which
> particular instance of a service it is talking, because they're all
> authenticating with the exact same identity.

I'm a bit lost.  I thought you were arguing against human-recognizable
service names (looking back at
http://www.ietf.org/mail-archive/web/kitten/current/msg01996.html where
you responded to Nico).  I didn't think this argument was about
identical vs. separate identities for multiple instances of a service.

---

From: Martin Rex <[email-masked]>
Date: Tue, 17 Aug 2010 03:04:21 +0200 (MEST)

> admins are fond of that requirement, though.

There is nothing wrong with a preconfigured *secure* retrieval of
a mapping or new keys (no matter whether it is a push or pull/on-demand
update scheme).  It unlikey that admins are going to reinstall their
Kerberos KDC or Microsoft Windows Domain Controller on a monthly
basis without carrying over any users&keys.  Such activity usually affects
only application servers, and primarily for development and testing.

> certificates tend to get renewed once a year, and users visit lots of

CA's and companies doing business on the web are much more sensitive
to negative user experiences caused by flawed administrative procedures
of their IT maintenance staff.

This is more about educating the IT admins to do cut down on negligence
rather than on educating end-users about doing less of the dangerous stuff.

Given how many Web-Sites require active content in Browsers to be enabled
these days and the neverending flood of critical bugs in the feature-bloated
WebBrowsers that are fixed every month, Security on the Internet
is a lost cause for Joe Average User anyway.

Compare the situation of 1996 with today,
  - back then you had no problem surfing the internet with
    active content disabled, today lots of sites are completely 
    unusable without active content enabled
  - the number of independent pre-trusted rootCA certs in browsers
    is *MUCH* larger
  - at least 10 critical bugs are fixed EVERY month that
    can be used for remote code execution with an active content
    enabled browser

Bottom line, if you honestly compare effective security when using
a Browser with HTTPS for electronic commerce on the internet,
it has become so much worse today that it brings tears to my eyes.

Only security geeks that go through the effort of using one or more
virtual sandboxes for connecting a Browser in a disposable installation
with enabled active content to the internet.  For them, a warn on key
change would be a security benefit, and would help them to more easily
detect attacks and to cut down on the number of distinct sandboxes
necessary to get sensitive stuff done over the internet.

> through replay caches.  So I don't see how this is relevant to the

That is not quite how message protection was defined for the original
rfc1964 Kerberos 5 GSS-API mechanism.  And for a very long time there
were authentication-only usage scenarios for Kerberos, where the
Kerberos authentication exchange was (ab)used as an OTP-style
authentication. That includes the original design of
rfc-4559 HTTP Negotiate before the addition of TLS channel bindings
(are the channel bindings available on WindowsXP as well, which
 is still at > 50% of the Microsoft Windows Market share and still
 sold on some new Netbooks even today).

> identical vs. separate identities for multiple instances of a service.

That is a misunderstanding.  I am against insecure transformations of
human-recognizable service names into real server identites.  And
even more so against repeated insecure transformations for every connet.

When there is no secure transformation is available, an insecure
translation involving a counscious leap-of-faith or out-of-band
authentication by the end user ought to be performed, and the users
decision ought to be memorized, just like SSH has been doing it 
the last 15 years.

In traditional SSH, the identities of peers are raw public keys.
These are admittedly hard to memorize and hard to recognize.
Even the public key fingerprints are hard to memorize and hard to
recognize.  Which is why *secure* translation facilities from a
server name into the servers public key, such as $HOME/.ssh/known_hosts
and /etc/ssh/known_hosts are sensible and improve usability.

Replacing the existing, fairly secure authentication of peers with
a scheme based on X.509 certs, a zoo of ~40 completely unrelated
rootCA certs from largely unknown commercial CAs around the globe
and doing an pretty weak matching of the network address to small
parts of the server's certificate does not even come close to
authentication.  (Which might be one reason why rfc-2818 "HTTP over TLS"
does not use the word authentication at all).

If you would permit root/adminstrative access over the internet
to one of your own machines that stores sensitive and valuable
information, how would you enable that access if you were using
public key credentials?

- Would you create an X.509v3 cert and get it signed under one
  of the ~40 distinct rootCAs preconfigured in common browsers and
  then configure your host to match only on parts of the Subject DName
  and allow arbitrary certification pathes to any of those ~40 CAs

- Or would you rather configure only your public key (naked or
  embedded in an X.509 cert) for access, a key that you created all
  by yourself pretty much what traditional SSH has been successfully
  doing for both, servers and clients, since it was invented.

Configuring the public key or cert directly has the big advantage that it
cuts a huge amount of questionable code, a very complex technology (PKIX)
and the entire faith in ~40 liability-free trustanchors and
an unknown amounts of intermedaites from the risk management equation
for remote administrative access to my host.

-Martin