Subject: Re: LIPKEY and SPKM-3 support

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Tue, 30 Apr 2002 15:15:00 -0400

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