Subject: Fw: LIPKEY and SPKM-3 support

From: "Ron Hoffman" <[email-masked]>
Date: Wed, 1 May 2002 12:54:34 -0400

Hi Andy,

If there is a separate database containing the mapping for
service/host -> fully-qualified server distinguished name, then we don't
need to make any assumptions about how to construct the server DN.
However, we are now starting to build our own infrastructure which will
be needed in addition to the SSL/TLS infrastructure.  This is something
that would need to be present on each client machine.

You are correct for encoding the DH algorithm identifier.  My question
was about encoding the public value Y, which is not part of the
algorithm identifier.  I would prefer to just encode it as a BIT STRING,
although I don't have any real objection to encoding it as an INTEGER
and then encoding that as a BIT STRING (just more overhead).

I would also prefer to encode the random value as a BIT STRING, although
we could encode it first as an INTEGER which is then encoded as a BIT
STRING.  Again, just more overhead.  The SPKM-1 example that I looked at
just encoded the random value as a BIT STRING.

Whatever method is selected, I think the RFC should be updated to
explicitly spell out the encoding.  That will avoid problems in the
future when somebody new claims the encodings are incorrect.

Ron

----- Original Message -----
From: "William A.(Andy) Adamson" <[email-masked]>
To: "Ron Hoffman" <[email-masked]>
Cc: <[email-masked]>; "William A.(Andy) Adamson" <[email-masked]>;
<[email-masked]>
Sent: Tuesday, April 30, 2002 3:15 PM
Subject: Re: LIPKEY and SPKM-3 support

>
> hi ron
>
> well, i'm back at it, and i am going through your email... ;0
>
>
> > Hi Andy,
> >
> > I have your SPKM3 source code from last July and would be interested
in
> > your current source code.  I'm afraid there won't be much in common
> > since my code has diverged significantly since the first MIT
Kerberos V5
> > release in 1997.  I've also rewritten a lot of the original MIT code
for
> > performance, reliability, and serviceability improvements (my code
is
> > part of z/OS which is one of the IBM mainframe operating systems).
In
> > addition, I'm using my own X.509 certificate and crypto routines
instead
> > of the OpenSSL code (large portions of my crypto and math routines
are
> > written in S/390 assembler for performance reasons).
> >
> > I would be interested in getting the binary tokens generated by
calls to
> > the various GSS-API routines.  I could then break them down to see
if
> > your encodings match my own (I've gotten pretty good at ASN.1 over
the
> > past couple years after writing ASN.1 encoders/decoders without
using an
> > ASN.1 compiler).  I also have an AIX (Unix) system running MIT
Kerberos
> > and OpenSSL which I use for interoperability testing.  I could apply
> > your updates to MIT Kerberos and do some interoperability testing
that
> > way.
>
> ok - let me code for ~1 week to get back into it, and i'll email you
the
> binary tokens and a code drop.
>
> >
> > I expect NFS to use GSS_C_NT_HOSTBASED_SERVICE.  However, the RFC
> > specifies both GSS_C_NT_USER_NAME and GSS_C_NT_HOSTBASED_SERVICE.
Since
> > our GSS-API support is separate from the NFS support, I'm going to
try
> > to provide a full implementation of RFC 2743 and 2744.
>
> that is an eventual goal of mine as well, although time is precious
and NFSv4
> is my focus.
>
> > It would be nice
> > if we had a third name type for an X.509 distinguished name.  That
way,
> > I wouldn't need the kludge of checking for an '=' in the name to
decide
> > if it was a simple name or a distinguished name when
GSS_C_NT_USER_NAME
> > is specified.  gss_display_name() could then return this new name
type
> > for an SPKM mechanism name (since those names will be obtained from
> > X.509 certificates and will be distinguished name).
> >
> > In your code from last July, you are hard-coding the suffix for the
> > target name.  I ended up sending the target name as just
> > 'CN=service-name/host-name' in the SPKM request token.  No suffix is
> > added at this point.  The target then checks the name against its
X.509
> > certificate (following the rules I described in my previous post).
>
> here is your previous post.
>
>    a) A match occurs if the target name is the same as the subject
name
>       or a DN entry for the subject alternate name in the
targetcertificate.
>
>    b) A match occurs if the target name is just a common name and the
>       common name matches the CN portion of the subject name or the CN
>       portion of a DN entry for the subject alternate name in the
target
>       certificate.
>
>    c) A match occurs if the target name is a service name
>       ("CN=service/host") and the host matches the CN portion of the
>       subject name or a DNS entry for the subject alternate name in
the
>       target certificate.
>
> this is problematic for the University of Michigan, and for several
other
> institutions we do PKI with.  here is an example of a target name.
>
> Subject: C=US, ST=Michigan, L=Ann Arbor, O=University of Michigan,
OU=TEST --
> CITI Client CA  v1,
CN=itcom-qos.citi.umich.edu/Email=web_server/itcom-qos.citi
> [email-masked]
>
> note that the CN is NOT simply service-name/host-name (!) but has a
lot of
> other information.  trying to guess the target name knowing the
service-name
> and which host will fail in our case. i suspect that this will be the
case at
> many institutions. so, i anticipate that along with the root
certificate
> database that is needed for certificate validation, there will be an
> accompanying database of how to construct a target name from a
service-name
> and host-name. thus the whole subject name could be constructed by the
> initator and used in validating the target name.
>
>
> > If
> > the name is acceptable, context establishment proceeds.  On the
second
> > call to gss_init_sec_context(), the target name is updated in the
> > context using the subject name from the supplied certificate (I
always
> > request the target certificate).  The application can obtain this
name
> > if desired by calling gss_inquire_context().
>
> what i described above => no need for updating the context target
name.
>
> >
> > If a distinguished name is provided for the target name, then it
must
> > match either the subject name or one of the subject alternate names
in
> > the target certificate.  So applications that want an exact match on
the
> > target name can be accomodated as well as applications that just
want a
> > match on the host name.  I could also provide an environment
variable
> > for specifying the name suffix (I already have environment variables
for
> > specifying the key database and the default certificate).  This
suffix
> > would be added to any simple name.  The trouble is making it
flexible
> > enough to handle the case where you are accessing servers in
different
> > enterprises.  If we assume the certification authorities will be
strict
> > about the assignment of host names in certificates, we probably
don't
> > need a suffix on the target name.
> >
>
>
>
> > I always use Diffie-Hellman key exchange since I don't have the
target
> > certificate when generating the request token.  The source
certificate
> > and certification chain are included in the request token unless the
> > GSS_C_ANON_FLAG is specified.
> >
> > I agree that the DH public value is encoded as a BIT STRING in the
> > request and reply tokens.  My question relates to how the bit string
is
> > constructed.  Say you have a 128-byte public value (Y) as output
from
> > the DH key agreement algorithm.  Does the bit string consist of just
> > this 128-byte value?  Or is the public value encoded somehow and the
> > encoded result becomes the bit string value?
> >
> > If the BIT STRING consists of just the 128-byte Y, then the encoded
> > result would be: x'03818100yyyyyyyy.....yyyy'
> >
> > However, in your July code, it looks like you take Y and encode it
as an
> > ASN.1 INTEGER and then wrap that in an ASN.1 SEQUENCE.  The encoded
> > result is then: x'03818700308183028180yyyy......yyyyy'.
>
> first off, a disclaimer! i am very slowly becoming asn1 literate,
resisting
> heavily at every step.
>
> i placed the public parameters into the
REQ_TOKEN/Req-contents/key-estb-set
> field which is defined as as a SEQUENCE of AlgorithmIdentifiers
(called
> X509_ALGOR by the valicert asn1parser). The AlgorithmIdentifier itself
is
> defined as a SEQUENCE of algorithm (OID) and parameter (ANY). The
DHParameter
> has INTEGERS to hold the prime and base public dh parameters.
>
> so, i call the openssl i2d_DHparams() routine which encodes the prime
and base
> as INTEGERS int the AlgorithmIdentifier parameter field, stuff the
> AlgorithmIdentifier algorithm field with the DH OID, and then encode
the
> AlgorithmIdentifier (which is  SEQUENCE) thus getting the result you
noted.
>
>
> >
> > A similar question relates to other bit strings.  For example, if I
> > generate an 8-byte random number R, I'm assuming the encoded result
> > would be: x'030900rrrrrrrrrrrrrrrr'.  That is, the random number is
not
> > first encoded as an ASN.1 INTEGER and the encoded result then used
as
> > the bit string value.
>
> yes, this case was not clear to me. i found examples of encoding
integers as
> BIT_STRING in the openssl code, and followed suit.
>
> -->Andy
>
>

---

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Thu, 02 May 2002 09:52:12 -0400

> that would need to be present on each client machine.

yeah, it's an open issue.

> just encoded the random value as a BIT STRING.

oh, i see what you mean. i wrote the i2d_DHPublicKey() and the 
d2i_DHPublicKey() routines and modeled them directly after the openssl 
i2d_DSAPublicKey-d2i_DSAPublicKey and RSAPublicKey routines. just like the DSA 
and RSA public keys, the DH->pub_key is declared as an integer. so, i'm just 
following suit.

> future when somebody new claims the encodings are incorrect.

yes, i agree. 

-->Andy