Re: pam_pkcs11 and KRB5PrincipalName

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: pam_pkcs11 and KRB5PrincipalName

Jonsy (teleline)
El vie, 14-10-2005 a las 00:35 -0400, Jeffrey Hutzelman escribió:
> I was pleased to discover recently that your PAM module attempts to support
> certificates with the KRB5PrincipalName name type.  Unfortunately, the
> correct format of that name type is somewhat more complex than your current
> code assumes.

Thanks for the info. I was unable to find full doc on KPN format
for the kerberos mapper, and no way to test the module
(my Cert, has no kpn :-)

I'll revise the code.

> The correct format can be found on page 12 of
> draft-ietf-cat-kerberos-pk-init-28.txt, and is reproduced below:
>
>        KRB5PrincipalName ::= SEQUENCE {
>            realm                   [0] Realm,
>            principalName           [1] PrincipalName
>        }
>
> The Realm and PrincipalName types are as defined in RFC4120:
>
>         KerberosString  ::= GeneralString (IA5String)
>         Realm           ::= KerberosString
>         PrincipalName   ::= SEQUENCE {
>                 name-type       [0] Int32,
>                 name-string     [1] SEQUENCE OF KerberosString
>         }
>
>
> In practice, you can transform this into a string suitable for matching by
> concatenating each of the name-strings, separated by slashes (/), and then
> appending the realm, separated by at at-sign (@).  The name-type can be
> ignored completely; the spec REQUIRES that no two names differ only in
> type, and in practice no one uses name types in matching.  Whether and how
> to escape the / and @ characters is not standardized and thus up to you; I
> believe the common convention is to \-escape @, /, and \ in principal name
> components, and not to do any escaping in realm names.
>
> As far as character sets go, officially the strings are all GeneralString
> constrained to IA5String, which in practice is pretty close to "US ASCII".
> In practice most major implementations either use UTF-8 or send whatever
> the local character set is without checking; as a result you might see
> almost any 8-bit character set here.  I don't have a lot of experience with
> sites using non-ASCII principal names, but I suspect you can get away with
> assuming that whoever writes the mapfile will know what character set is in
> use.  The next rev of the Kerberos spec will likely REQUIRE the use of
> UTF-8, tagged as UTF8String rather than GeneralString.
>
>
> Finally, regarding authorization.  There is a widely-used convention in
> UNIX kerberos implementations which allows a user to have a ~/.k5login
> file, which contains a list of principals authorized to log in as that
> user.  Failing that, the principal "[hidden email]" is allowed to log in.
> It might be worthwhile providing equivalent functionality.  Of course,
> there are functions to do these checks in Kerberos libraries, but you
> probably don't want to develop a dependency on Kerberos just for that.

> -- Jeffrey T. Hutzelman (N3NHS) <[hidden email]>
>    Sr. Research Systems Programmer
>    School of Computer Science - Research Computing Facility
>    Carnegie Mellon University - Pittsburgh, PA

Cheers
Juan Antonio

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel

signature.asc (196 bytes) Download Attachment