Issuer of issuer, user of user@issuer fails

[Sam Hartman]

Adam reported an issue where issuer of issuer and user of user@issuer (resulting in nai of user@issuer@issuer) failed to even send a token and falls back to gss_eap_id.

[Dan Breslau (dbreslau)]

I asked Mark for guidance on this issue; here's his response:
-------------------------

You can find the basic discussion at

https://www.jiscmail.ac.uk/cgi-bin/webadmin?A1=ind1509&L=moonshot-community#3 ,

and the best problem descriptions at

https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1509&L=moonshot-community&F=&S=&P=2897

  - and -

https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1509&L=moonshot-community&F=&S=&P=12757

So, with that in mind, my reproduction steps are:
-------------------------------------------------------------------
1. Set up an identity in the manager to be something like this:
     Display Name: Messed Up Identity
           Issuer: <email address hidden>
         Username: mark
         Password: <whatever>
2. Connect to a new service using ABFAB, so that the identity selector
    is shown.
3. Select "Messed Up Identity"

Expected results:
-------------------------------------------------------------------
The identity selector should send the identity "<email address hidden>@mark", which should fail all authentications.

Actual results:
-------------------------------------------------------------------
The identity is not sent to the server. The moonshot libraries look for a file named .gss_eap_id (which was used before the identity selector existed), which suggests that the identity selector did not return an identity to the moonshot libraries.

Were I to debug this, I'd start looking towards the end of the lifecycle of a request for an identity, where the user has already made a selection. Somewhere along the line, the user selection is transformed into a GSS credential, and that's where this is likely failing. What I don't know is whether that's happening in the selector code, or in the library code.

If the selector hands back strings for the library to transform into the GSS credential, then I don't know that there's a lot else for the library to do at that point. It is dealing with some unusable data, and tries to fall back, and fails when it can't.

If the selector hands back the GSS credential, then there's probably a call in there to gss_import_name that is failing, because the name string (<email address hidden>@mark) does not meet the expected format. I would guess that the selector code assumes that call will always succeed.

Were I to fix this, I'd work this along two axes. First, I'd look to constrain the input field to disallow the presence of "@" or "/", which are used as delimiters that we aren't looking to have. Second, I'd look to make sure that the selector never tries to put together an identifier that has two "@" in it, even if such an identifier already got into its database somehow.

[Sam Hartman (hartmans)]

I doubt that the import_name call is expected to always succeed, it's
probably just that if that fails it falls back to .gss_eap_id.
That fallback could be changed; take a look at acquire_cred.c and
util_moonshot.c in the mech_eap code.

For debugging this, mech_eap has gained a trace facility that could
potentially be used by libmoonshot.
To avoid introducing a dependency, you'd probably want to add a
function pointer for a trace callback to libmoonshot, and pass in a
trace function when mech_eap initializes libmoonshot.

Note that / should be permitted in username.

Also, take a look at the name escaping rules in section 3.1 of RFC 7055.
An alternate argument one could make is that the bug is in libmoonshot
for not backslash escaping the @ in the issuer.
I think handling things that way would be correct but not improve
usability.
It is important though that escaped @ and / be possible to enter in a
name. That is, any legal name under 3.1 of RFC 7055 should be possible
to enter as an identity.

[Dan Breslau (dbreslau)]

I fully agree that escaping would be preferable. But I am a little concerned about this snippet from RFC 7055:

"This escaping mechanism is a property of the string representation; if the components of a name are transported in some mechanism that will keep them separate without backslash escaping, then backslash SHOULD have no special meaning."

As I read it, this means that backslash escaping would probably be a bug when it's not absolutely required. Can we be sure that it will ALWAYS be absolutely required -- i.e., that we will ALWAYS be using a transport mechanism that will NOT isolate the components of the name?

[Sam Hartman (hartmans)]

>>>>> "Dan" == Dan Breslau <email address hidden> writes:

gss_import_name requires escaped names.

So, the most rfc-correct thing to do would be to:

* Not treat @ as a separator when entered in issuer or username, but
  instead to escape it when libmoonshot hands off a name to mech_eap

* treat \/ as an escaped slash in username

* turn \@ in username to \\\@ is username and realm

However that probably would confuse your users. I think a defensible
behavior that is more usable would be to:

* Forbid unescaped @ in username and issuer

* Forbid unescaped / in issuer

* Permit escaped /, @ and \ everywhere

[Mark Donnelly (meadmaker)]

If the solution is to sanity-check the username field, this could be a low priority bug.

If the solution involves working through everything in RFC 7055 that Sam suggested, this probably involves more work and is considered a wishlist item.