Subject: OpenID+GSS-API and naming: GSS_C_NT_OPENID?

From: Simon Josefsson <[email-masked]>
Date: Tue, 06 Jul 2010 15:55:39 +0200

I'm working on text for a OpenID GSS-API mechanism, and I'm thinking
about how OpenID naming should work in GSS-API calls.

Normally OpenID users present an OpenID URL like (hopefully)
'https://josefsson.org/' (string A) but sometimes
'http://josefsson.org/' (string B) or even 'josefsson.org' (string C),
and the final version leaves the protocol unspecified.

When doing the GSS_Init_sec_context call, we could use the
GSS_C_NT_USER_NAME name type to hold the strings A, B and C.  The
mechanism would then need to figure out how to translate string C into
the fully qualified URL string B or A which is used for the OpenID
process.

However, it strikes me as unaesthetic for the GSS-API implementation to
assume some semantic of the name string supplied and do processing of it
(i.e., if it is not a proper URL, prepend 'https://' or 'http://' to
it).  Do others share this concern?  How strongly?  One problem is that
GSS-API applications is left uncertain what the normalized OpenID URL
actually was after successful (or failed) authentication.

I see two solutions:

1) If people are happy with GSS_C_NT_USER_NAME for OpenID URLs, then
   just say that in the document, and make sure that it is well
   specified how unqualified URLs (like string C above) is handled by
   pointing at OpenID 2.0 specification section 7.2:
   http://openid.net/specs/openid-authentication-2_0.html#normalization

2) Specify a GSS_C_NT_OPENID name type to make sure the application and
   OpenID mechanism agree on the semantic meaning of the name string.

I have read the GSS-API name attribute draft, but I don't see
immediately how it applies here.  Possibly there could be one name
attribute to hold the normalized OpenID URL used by the mechanism?

Right now I am leaning towards 1) and re-using GSS_C_NT_USER_NAME for
OpenID URLs.  My main reason is just practical issues in deploying a new
name type in GSS-API.

If GSS-API people think a new name type is required for OpenID, it would
be useful to start work on this approach soon.

/Simon

---

From: Klaas Wierenga <[email-masked]>
Date: Tue, 06 Jul 2010 16:12:05 +0200

> and the final version leaves the protocol unspecified.

or =Klaas etc. if I am not mistaken

> be useful to start work on this approach soon.

I agree with your leaning to 1), also because in addition to 
GSS_C_NT_OPENID there may be GSS_C_NT_SAML, GSS_C_NT_OAUTH etc. etc.

Klaas

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 06 Jul 2010 17:02:58 +0200

Klaas Wierenga <[email-masked]> writes:

> I agree with your leaning to 1)

Great! :)

I currently have the following text, is there any feedback from GSS-API
people on it?

It seems useful to specify a GSS-API name attribute for the normalized
OpenID identifier, if that is an appropriate use of name attributes.
Thoughts?

/Simon

4.1.  GSS-API Principal Name Types for OpenID

   OpenID supports standard generic name syntaxes for acceptors such as
   GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1).

   OpenID supports only a single name type for initiators:
   GSS_C_NT_USER_NAME.  GSS_C_NT_USER_NAME is the default name type for
   OpenID.

   OpenID name normalization is covered by the OpenID specification, see
   [OpenID] section 7.2.

   The query, display, and exported name syntaxes for OpenID principal
   names are all the same.  There are no OpenID-specific name syntaxes
   -- applications should use generic GSS-API name types such as
   GSS_C_NT_USER_NAME and GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743],
   Section 4).  The exported name token does, of course, conform to
   [RFC2743], Section 3.2, but the "NAME" part of the token should be
   treated as a potential input string to the OpenID name normalization
   rules.

   GSS-API name attributes may be defined in the future to hold the
   normalized OpenID Identifier.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 6 Jul 2010 10:44:07 -0500

> actually was after successful (or failed) authentication.

This is exactly how the GSS-API handles naming.  You feed in a string
and a name-type to GSS_Import_name(), which is later canonicalized,
either by GSS_Canonicalize_name() or by the mechanism when you pass the
non-MN to a function that needs an MN.

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

The convention is that if you pass GSS_C_NO_OID as name-type OID then
the name syntax will be mechanism-specific.

I'd be fine with GSS_C_NT_USER_NAME being interpreted similarly
liberally.

>    OpenID mechanism agree on the semantic meaning of the name string.

Kerberos has GSS_KRB5_NT_PRINCIPAL_NAME.  This is fine.

> be useful to start work on this approach soon.

You definitely need a new OID.  See also the mech-default syntax thing.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 14 Jul 2010 12:10:16 -0400

My preference would be to define a nem type specific to the OpenID
mechanism to use as a MN, but to also support nt_user_name, which would
be canonicalized as best as the mechanism is able to the MN.

--Sam