 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
Jeffrey Hutzelman writes...It is a design feature of ISMS that we delegate to SSH the entire problem of mapping names coming from potentially disparate authentication namespaces into a common namespace which is provided to us. This is a feature because SSH has to (and does) solve it anyway. If we extend this approach to every future secure transport mapping, such that all such mappings can be expected to deal with any differences or false similarities between names used by their authentication mechanisms, then we are left only with the problem of dealing with differences and/or false similarities between names provided us by different possible secure transports.Well, that's very nice and convenient. I'm unaware of the document that specifies this "identity disambiguation" behavior of SSH authentication and that of other secure transports. Would you please give me a pointer?
I think perhaps you misinterpreted what I said. I said that SSH solves the problem, and it does. This is a basic part of the way SSH user authentication works. Particularly, SSH does not try to map names used by a particular authentication mechanism onto SSH usernames. Instead, a client which is trying to authenticate must indicate what SSH username it wants, and the SSH server makes an authorization decision as to whether the client is allowed to use that username. The details of how that decision is made are mostly up to the particular userauth method used (and, to a large extent, up to the implementation and to local policy).
So, the only way you can have two different clients with the same username is if two sets of credentials are authorized to use the same username. Those could be different credentials for the same userauth method, or for different methods.
-- Jeff _______________________________________________ Isms mailing list Isms at ietf.org https://www.ietf.org/mailman/listinfo/isms