From: Ron Hoffman (rhoffman@stny.rr.com)
Date: 03/15/02-02:09:48 PM Z
Message-ID: <000401c1cc5d$5ca003e0$6501a8c0@STNY.RR.COM>
From: "Ron Hoffman" <rhoffman@stny.rr.com>
Subject: Re: LIPKEY and SPKM-3 support
Date: Fri, 15 Mar 2002 15:09:48 -0500
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.
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. 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). 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().
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'.
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.
Ron
----- Original Message -----
From: "William A.(Andy) Adamson" <andros@umich.edu>
To: <mike@eisler.com>
Cc: "Ron Hoffman" <rhoffman@stny.rr.com>;
<nfsv4-wg@sunroof.eng.sun.com>; <andros@umich.edu>
Sent: Friday, March 15, 2002 1:13 PM
Subject: Re: LIPKEY and SPKM-3 support
> Hi Ron
>
> Have you seen the SPKM3 open source work that i've done? It's
currently not
> available off our web site - i'll get an updated version asap. I would
like to
> test against each other...
>
>
> > Ron Hoffman wrote:
> > >
> > > I'm working on implementing LIPKEY and SPKM-3 as extensions to an
> > > existing GSS-API implementation of the Kerberos mechanism. The
> > > code base started with MIT Kerberos 1.0 back in 1997 but has
> > > evolved since then (new MIT Kerberos function has been added to
> > > the existing code base instead of re-porting the MIT code). As a
> > > result, the code base differs significantly from the current MIT
code.
> >
> > Hello Ron,
> >
> > I'm the author, but unfortunately, not an implementor. I'll
> > provide my two cents, and let the other known implementor,
> > Andy Adamson of UMICH/CITI, contradict me.
> >
> > A lot of the issues you raised were brought up within the CAT
> > working group when the LIPKEY internet draft was going through
> > working group last call. I argued then that issues of
> > underspecification would be resolved when LIPKEY and
> > NFSv4 were implemented. So it looks like that time has
> > arrived. Excellent.
> >
> > >
> > > I've finished the ASN.1 support and the first gss_init_sec_context
for
> > > SPKM-3. I'm currently working on the first
gss_accept_sec_context.
> > > I've run into some implementation questions which I would like to
> > > discuss with other implementors.
> > >
> > > The questions so far:
> > >
> > > 1) How does gss_import_name() construct the target name since the
> > > initiator does not have access to the target certificate?
> >
> > What name type are you passing in? NFSv4 cares only
> > about GSS_C_NT_HOSTBASED_SERVICE when using SPKM-3.
>
> My SPKM-3 implementation requires the GSS_C_NT_HOSTBASED_SERVICE
names.
>
> >
> > Also you mentioned that you are done with _init_sec_context
> > and moving on to _accept_sec_context. However,
> > wouldn't the client side (initiator) need to do an
> > _import_name() before _init_sec_context?
> >
> > >
> > > I'm allowing the target name to be a simple name ("John Doe"),
> > > a service name ("nfs@server.sun.com") or a distinguished name
> > > ("CN=John Doe,O=Sun,C=US").
> > >
> > > If a simple name is specified, it is encoded as a common name
in a
> > > single RDN sequence. For example, "John Doe" is encoded as
> > > "CN=John Doe".
> >
> > What name type does your code use for this case?
> >
> > >
> > > If a service name (service@host) is specified, it is converted
to
> > > "service/host" and encoded as a common name in a single RDN
sequence.
> > > For example, "nfs@server.sun.com" is encoded as
> > > "CN=nfs/server.sun.com".
> >
> > Presumably your code uses a GSS_C_NT_HOSTBASED_SERVICE
> > name type for this case.
> >
> > I'm not sure it makes sense to convert nfs@server.sun.com to
> > CN=nfs/server.sun.com.
> > RFC 3010 suggest the uses of nfs/hostname for Kerberos V5 and LIPKEY
> > service
> > names (and then goes on to suggests that LIPKEY not be used when
> > ever the NFS server is identfying itself to the client during a
> > callback.
> > Instead, it suggests to uses SPKM-3. The model I had in mind for
> > LIPKEY/SPKM-3 was that it would work in much the same way that
> > SSL is deployed today, and would try to leverage as
> > much of the existing SSL infrastructure as possible. As far as I can
> > tell, SSL
> > server certificates use a CN="server.sun.com". So,
> > the simplest would be to assume the use of the SSL-style
> > certificate ... I don't know if Verisign, Thawte, et. al.
> > will sell server certificates with arbitrary CN= values.
> >
> > There may be implementation/deployment situations where one
> > may not be able to use the SSL certificate for NFS. E.g.
> > there might be both SSL and NFSv4 services running on the
> > same host, and for rationale security purposes, the
> > private key is not shared between the two.
> >
> > So I suggest that NFSv4 follow this convention (and
> > the follow on to RFC 3010 be suitably revised)
> >
> > - try host@server first. A service name of
> > "host" has a special meaning in GSS-API
> > (see section 4.1 of RFC 2743 - GSS-API)
> > For SPKM-3, that will always mean
> > CN=server
> > - if that fails, then fall back to nfs@server.
> > For SPKM-3, that will mean CN=nfs/server.
> >
> > The notion of trying host@server, and then nfs@server
> > is one that RFC 2743 (againt in section 4.1) suggests is reasonable.
> >
> > > A distinguished name is used as-is.
> >
> > What name type does your code use here?
> >
> > >
> > > 2) How does the acceptor validate the target name?
> > >
> > > Since the initiator may not know the distinguished name
corresponding
> > > to
> > > the target certificate, the acceptor needs to map the target
name in
> > > the
> > > SPKM request token. I'm doing the following:
> > >
> > > 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 target
> > > certificate.
> > >
> > > 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.
> >
> > This case doesn't seem to apply to NFSv4, since targets are
> > the service@server form.
> >
> > >
> > > 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.
> >
> > Right, but I suggest modifying to have allow target names
> > of "CN=server" per my answer to your first question.
> >
> > >
> > > 3) How does the initiator validate the target name?
> > >
> > > To avoid a man-in-the-middle attack, the initiator needs to
validate
> > > the
> > > fully-qualified target name. So the initiator needs to perform
the
> > > same
> > > checking as described above to make sure the target name is
> > > acceptable.
> >
> > Right. For NFSv4's use case, "CN=server" is simplest.
> >
> > >
> > > 4) What character string should be returned by gss_display_name()
for an
> > > anonymous name?
> > >
> > > GSS-API leaves this up to the security mechanism. I'm
returning the
> > > string "<anonymous>" although that is also a valid simple name.
> >
> > I think that's fine, but I'll let you and Andy reach an agreement.
:-)
> > In practice, I don't think it impacts interoperability if two
different
> > implementations use different strings, but I could be wrong.
> >
>
> At the University of Michigan, we hand out x509 certificate names in
the
> following form:
>
> a preamble,
>
> { "countryName", "US" } ,
> { "stateOrProvinceName", "Michigan" } ,
> { "localityName", "Ann Arbor" } ,
> { "organizationName", "University of Michigan" } ,
> { "organizationalUnitName", "TEST -- CITI Client CA v1"}
>
> with a common name appended
>
> CN=nfs/hostname.
>
> These certificate names are used in our SSL communications - between
browsers
> and web servers as well as for globus grid communicaitons.
>
> i currently match all portions of the name. i feel the preamble is
important
> in that it provides futher identity of the target.
>
>
>
>
>
> > >
> > > 5) How are certificates validated?
> > >
> > > I'm following the SSL model where the source provides its
certificate
> > > and the certification chain up to the root certificate. The
target
> > > then
> > > provides its certificate and the certification chain up to the
root
> > > certificate. Thus, the certification data consists of the
forward
> > > root
> > > certificate followed by any reverse certificates required to
reach
> > > the user certificate.
> > >
> > > This requires each side to have a database of root
certificates.
> > > This
> > > database should already exist if SSL is being used. Each side
is
> > > then
> > > responsible for validating the certificate supplied by the
other
> > > side.
> >
> > Right. That was precisely my intent. ~user/.netscape/cert7.db
> > would be one useful source of root certificates.
> >
>
> if the client has a certificate, then the source name is known, not
anonymous.
> What key exchange algorithm do you use?
> i've implemented SPKM3 using diffie-hellman key exchange where the
source has
> no certificate, and the target certificate is passed back to the
source who
> verifies it via it's data base of root certificates.
>
> > >
> > > 6) How are the channel bindings encoded?
> > >
> > > RFC 2025 defines the channelId field as an octet string but
doesn't
> > > indicate how the channel bindings specified by the application
are
> > > converted to an octet string. Since SPKM is attempting to
follow
> > > Kerberos, I'm encoding the channel bindings in the same way as
the
> > > Kerberos mechanism (MD5 digest of a flattened structure using
> > > little-endian length values).
> >
> > Seems reasonable. I admit to never understanding the channel
bindings
> > stuff.
> > This
> > >
> > > 7) How is the protocol version encoded?
> > >
> > > RFC 2025 doesn't specify whether the bits are numbered from
> > > left-to-right or from right-to-left. Using the ASN.1
definition for
> > > a
> > > bit string, bit 0 would be the most-significant bit, bit 1
would be
> > > next,
> > > and so forth. However, GSS-API numbers bits from right-to-left
and
> >
> > What are you referring to when you says that "GSS-API numbers bits
..."
> >
> > > thus bit 0 would be the least-significant bit. I think the
ASN.1
> > > definition
> > > should be used (thus bit 0 would be x'80') but I've found an
SPKM-1
> > > implementation from Systinet which does it the other way.
> >
> > It seems to me the ASN.1 definition ought to be used.
> >
> > >
> > > 8) How are the context options encoded?
> > >
> > > Same problem as above. Again, I think the ASN.1 definition
should be
> > > used but the Systinet implementation encodes the options
starting
> > > with the least-significant bit. The Kerberos mechanism also
encodes
> > > the
> > > options starting with the least-significant bit (it actually
encodes
> > > them as
> > > a 4-byte integer in little-endian format).
> >
> > ditto.
> >
> > >
> > > 9) How are integrity signatures encoded?
> > >
> > > PKCS #1 and RFC 2459 define the encodings for RSA and DSA
> > > signatures. For RSA, the signature bit string is the encrypted
> > > DigestInfo
> > > structure. For DSA, the signature bit string is composed of
two
> > > ASN.1-encoded integers. However, this doesn't match the
description
> > > in
> > > RFC 2025. I am using the PKCS #1/RFC 2459 encodings in my
> > > implementation.
> >
> > Could you elaborate by pointing the respective sections in
> > RFC 2025 and RFC 2459 that disagree?
> >
> > >
> > > 10) How are the Diffie-Hellman parameters encoded?
> > >
> > > RFC 2025 uses the PKCS #3 OID instead of the RFC 2459 OID. So
I'm
> > > using the ASN.1-encoding defined in PKCS #3 instead of the
> > > ASN.1-encoding defined in RFC 2459.
> >
> > It seems to me theDH parameters RFC 2459 specifies are far
> > DH certificates, whereas the purpose RFC 2025 has in mind is
> > for secure key exchange ... the target could be using an RSA-based
> > certificate. So I think your choice is correct.
> >
> > >
> > > 11) How is the Diffie-Hellman public value encoded?
> > >
> > > RFC 2025 doesn't say whether it is the raw public value, the
public
> > > value as an ASN.1-encoded integer, or an ASN.1-encoded sequence
> > > containing the public value as an ASN.1-encoded integer. PKCS
#3
> > > doesn't specify an encoding for the public value, so I am using
the
> > > raw
> > > public value as the value of the bit string.
> >
> > I think this relates to question Andy raised with me at
Connectathon.
> > RFC 2025 discusses this field in the Req-contents token.
> >
> > key-estb-req BIT STRING OPTIONAL,
> > -- key estb. parameter corresponding to first K-ALG in
set
> > -- (not used if initiator is unable or unwilling to
> > -- generate and securely transmit key material to
target).
> > -- Established key must satisfy the key length
constraints
> > -- specified in Section 2.4.
> >
> > Andy pointed out that RFC 2025 and RFC 2847 are unclear
> > about what to use for key-estb-req and key-estb-rep
> > when using the dhKeyAgreement key K-ALG. The comment
> > about "unable or unwilling to generate and *securely*"
> > concerned him. My reading of the PKCS-3 standard
> > is that the public value (PV) doesn't have to be encrypted,
> > and moreover, the whole point of dhKeyAgreement is
> > boot strap the problem of generating a common
> > symmetric key. Furthere, the only
> > possible interpretation I can make from this text in RFC 2025,
> >
> > dhKeyAgreement OBJECT IDENTIFIER ::= {
> > iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
> > pkcs-3(3) 1
> > }
> >
> > In this algorithm, the context key is generated jointly
by
> > the initiator and the target using the Diffie-Hellman
key
> > establishment algorithm. The target must therefore
respond
> > to the initiator for the key to be established (so this
> > K-ALG cannot be used with unilateral authentication in
> > SPKM-2 (see Section 3.1)).
> >
> > is that initiator sends its PV in the key-est-req, and
> > the target responds with its own PV in the key-est-str,
> > each in the clear.
> >
> > As to how the PVs are encoded, RFC 2025 specifies:
> >
> > key-estb-req BIT STRING OPTIONAL
> > ...
> > key-estb-str BIT STRING OPTIONAL
> >
> > So, my interpretation is an ASN BIT STRING.
> >
>
>
> Yep. BIT_STRING is what I use.
>
> > >
> > > Any thoughts on these choices or alternatives is welcome. I've
tried to
> > > find a LIPKEY or SPKM-3 implementation to use for interopability
> > > testing but have not been successful.
> >
> > I suspect Andy might be willing to help there. :-)
> >
>
>
>
> yes! i've been talking to myself far too long....
>
> -->Andy
>
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:36 AM Z CST