1081 lines
49 KiB
Plaintext
1081 lines
49 KiB
Plaintext
INTERNET-DRAFT Brian Tung
|
|
draft-ietf-cat-kerberos-pk-init-12.txt Clifford Neuman
|
|
Updates: RFC 1510 USC/ISI
|
|
expires January 15, 2001 Matthew Hur
|
|
CyberSafe Corporation
|
|
Ari Medvinsky
|
|
Keen.com, Inc.
|
|
Sasha Medvinsky
|
|
Motorola
|
|
John Wray
|
|
Iris Associates, Inc.
|
|
Jonathan Trostle
|
|
Cisco
|
|
|
|
Public Key Cryptography for Initial Authentication in Kerberos
|
|
|
|
0. Status Of This Memo
|
|
|
|
This document is an Internet-Draft and is in full conformance with
|
|
all provisions of Section 10 of RFC 2026. Internet-Drafts are
|
|
working documents of the Internet Engineering Task Force (IETF),
|
|
its areas, and its working groups. Note that other groups may also
|
|
distribute working documents as Internet-Drafts.
|
|
|
|
Internet-Drafts are draft documents valid for a maximum of six
|
|
months and may be updated, replaced, or obsoleted by other
|
|
documents at any time. It is inappropriate to use Internet-Drafts
|
|
as reference material or to cite them other than as "work in
|
|
progress."
|
|
|
|
The list of current Internet-Drafts can be accessed at
|
|
http://www.ietf.org/ietf/1id-abstracts.txt
|
|
|
|
The list of Internet-Draft Shadow Directories can be accessed at
|
|
http://www.ietf.org/shadow.html.
|
|
|
|
To learn the current status of any Internet-Draft, please check
|
|
the "1id-abstracts.txt" listing contained in the Internet-Drafts
|
|
Shadow Directories on ftp.ietf.org (US East Coast),
|
|
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
|
|
munnari.oz.au (Pacific Rim).
|
|
|
|
The distribution of this memo is unlimited. It is filed as
|
|
draft-ietf-cat-kerberos-pk-init-11.txt, and expires January 15,
|
|
2001. Please send comments to the authors.
|
|
|
|
1. Abstract
|
|
|
|
This document defines extensions (PKINIT) to the Kerberos protocol
|
|
specification (RFC 1510 [1]) to provide a method for using public
|
|
key cryptography during initial authentication. The methods
|
|
defined specify the ways in which preauthentication data fields and
|
|
error data fields in Kerberos messages are to be used to transport
|
|
public key data.
|
|
|
|
2. Introduction
|
|
|
|
The popularity of public key cryptography has produced a desire for
|
|
its support in Kerberos [2]. The advantages provided by public key
|
|
cryptography include simplified key management (from the Kerberos
|
|
perspective) and the ability to leverage existing and developing
|
|
public key certification infrastructures.
|
|
|
|
Public key cryptography can be integrated into Kerberos in a number
|
|
of ways. One is to associate a key pair with each realm, which can
|
|
then be used to facilitate cross-realm authentication; this is the
|
|
topic of another draft proposal. Another way is to allow users with
|
|
public key certificates to use them in initial authentication. This
|
|
is the concern of the current document.
|
|
|
|
PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in
|
|
combination with digital signature keys as the primary, required
|
|
mechanism. It also allows for the use of RSA keys and/or (static)
|
|
Diffie-Hellman certificates. Note in particular that PKINIT supports
|
|
the use of separate signature and encryption keys.
|
|
|
|
PKINIT enables access to Kerberos-secured services based on initial
|
|
authentication utilizing public key cryptography. PKINIT utilizes
|
|
standard public key signature and encryption data formats within the
|
|
standard Kerberos messages. The basic mechanism is as follows: The
|
|
user sends an AS-REQ message to the KDC as before, except that if that
|
|
user is to use public key cryptography in the initial authentication
|
|
step, his certificate and a signature accompany the initial request
|
|
in the preauthentication fields. Upon receipt of this request, the
|
|
KDC verifies the certificate and issues a ticket granting ticket
|
|
(TGT) as before, except that the encPart from the AS-REP message
|
|
carrying the TGT is now encrypted utilizing either a Diffie-Hellman
|
|
derived key or the user's public key. This message is authenticated
|
|
utilizing the public key signature of the KDC.
|
|
|
|
Note that PKINIT does not require the use of certificates. A KDC
|
|
may store the public key of a principal as part of that principal's
|
|
record. In this scenario, the KDC is the trusted party that vouches
|
|
for the principal (as in a standard, non-cross realm, Kerberos
|
|
environment). Thus, for any principal, the KDC may maintain a
|
|
secret key, a public key, or both.
|
|
|
|
The PKINIT specification may also be used as a building block for
|
|
other specifications. PKCROSS [3] utilizes PKINIT for establishing
|
|
the inter-realm key and associated inter-realm policy to be applied
|
|
in issuing cross realm service tickets. As specified in [4],
|
|
anonymous Kerberos tickets can be issued by applying a NULL
|
|
signature in combination with Diffie-Hellman in the PKINIT exchange.
|
|
Additionally, the PKINIT specification may be used for direct peer
|
|
to peer authentication without contacting a central KDC. This
|
|
application of PKINIT is described in PKTAPP [5] and is based on
|
|
concepts introduced in [6, 7]. For direct client-to-server
|
|
authentication, the client uses PKINIT to authenticate to the end
|
|
server (instead of a central KDC), which then issues a ticket for
|
|
itself. This approach has an advantage over TLS [8] in that the
|
|
server does not need to save state (cache session keys).
|
|
Furthermore, an additional benefit is that Kerberos tickets can
|
|
facilitate delegation (see [9]).
|
|
|
|
3. Proposed Extensions
|
|
|
|
This section describes extensions to RFC 1510 for supporting the
|
|
use of public key cryptography in the initial request for a ticket
|
|
granting ticket (TGT).
|
|
|
|
In summary, the following change to RFC 1510 is proposed:
|
|
|
|
* Users may authenticate using either a public key pair or a
|
|
conventional (symmetric) key. If public key cryptography is
|
|
used, public key data is transported in preauthentication
|
|
data fields to help establish identity. The user presents
|
|
a public key certificate and obtains an ordinary TGT that may
|
|
be used for subsequent authentication, with such
|
|
authentication using only conventional cryptography.
|
|
|
|
Section 3.1 provides definitions to help specify message formats.
|
|
Section 3.2 describes the extensions for the initial authentication
|
|
method.
|
|
|
|
3.1. Definitions
|
|
|
|
The extensions involve new preauthentication fields; we introduce
|
|
the following preauthentication types:
|
|
|
|
PA-PK-AS-REQ 14
|
|
PA-PK-AS-REP 15
|
|
|
|
The extensions also involve new error types; we introduce the
|
|
following types:
|
|
|
|
KDC_ERR_CLIENT_NOT_TRUSTED 62
|
|
KDC_ERR_KDC_NOT_TRUSTED 63
|
|
KDC_ERR_INVALID_SIG 64
|
|
KDC_ERR_KEY_TOO_WEAK 65
|
|
KDC_ERR_CERTIFICATE_MISMATCH 66
|
|
KDC_ERR_CANT_VERIFY_CERTIFICATE 70
|
|
KDC_ERR_INVALID_CERTIFICATE 71
|
|
KDC_ERR_REVOKED_CERTIFICATE 72
|
|
KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
|
|
KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74
|
|
KDC_ERR_CLIENT_NAME_MISMATCH 75
|
|
KDC_ERR_KDC_NAME_MISMATCH 76
|
|
|
|
We utilize the following typed data for errors:
|
|
|
|
TD-PKINIT-CMS-CERTIFICATES 101
|
|
TD-KRB-PRINCIPAL 102
|
|
TD-KRB-REALM 103
|
|
TD-TRUSTED-CERTIFIERS 104
|
|
TD-CERTIFICATE-INDEX 105
|
|
|
|
We utilize the following encryption types (which map directly to
|
|
OIDs):
|
|
|
|
dsaWithSHA1-CmsOID 9
|
|
md5WithRSAEncryption-CmsOID 10
|
|
sha1WithRSAEncryption-CmsOID 11
|
|
rc2CBC-EnvOID 12
|
|
rsaEncryption-EnvOID (PKCS#1 v1.5) 13
|
|
rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14
|
|
des-ede3-cbc-Env-OID 15
|
|
|
|
These mappings are provided so that a client may send the
|
|
appropriate enctypes in the AS-REQ message in order to indicate
|
|
support for the corresponding OIDs (for performing PKINIT).
|
|
|
|
In many cases, PKINIT requires the encoding of the X.500 name of a
|
|
certificate authority as a Realm. When such a name appears as
|
|
a realm it will be represented using the "other" form of the realm
|
|
name as specified in the naming constraints section of RFC1510.
|
|
For a realm derived from an X.500 name, NAMETYPE will have the value
|
|
X500-RFC2253. The full realm name will appear as follows:
|
|
|
|
<nametype> + ":" + <string>
|
|
|
|
where nametype is "X500-RFC2253" and string is the result of doing
|
|
an RFC2253 encoding of the distinguished name, i.e.
|
|
|
|
"X500-RFC2253:" + RFC2253Encode(DistinguishedName)
|
|
|
|
where DistinguishedName is an X.500 name, and RFC2253Encode is a
|
|
function returing a readable UTF encoding of an X.500 name, as
|
|
defined by RFC 2253 [14] (part of LDAPv3 [18]).
|
|
|
|
To ensure that this encoding is unique, we add the following rule
|
|
to those specified by RFC 2253:
|
|
|
|
The order in which the attributes appear in the RFC 2253
|
|
encoding must be the reverse of the order in the ASN.1
|
|
encoding of the X.500 name that appears in the public key
|
|
certificate. The order of the relative distinguished names
|
|
(RDNs), as well as the order of the AttributeTypeAndValues
|
|
within each RDN, will be reversed. (This is despite the fact
|
|
that an RDN is defined as a SET of AttributeTypeAndValues, where
|
|
an order is normally not important.)
|
|
|
|
Similarly, in cases where the KDC does not provide a specific
|
|
policy based mapping from the X.500 name or X.509 Version 3
|
|
SubjectAltName extension in the user's certificate to a Kerberos
|
|
principal name, PKINIT requires the direct encoding of the X.500
|
|
name as a PrincipalName. In this case, the name-type of the
|
|
principal name shall be set to KRB_NT-X500-PRINCIPAL. This new
|
|
name type is defined in RFC 1510 as:
|
|
|
|
KRB_NT_X500_PRINCIPAL 6
|
|
|
|
The name-string shall be set as follows:
|
|
|
|
RFC2253Encode(DistinguishedName)
|
|
|
|
as described above. When this name type is used, the principal's
|
|
realm shall be set to the certificate authority's distinguished
|
|
name using the X500-RFC2253 realm name format described earlier in
|
|
this section
|
|
|
|
RFC 1510 specifies the ASN.1 structure for PrincipalName as follows:
|
|
|
|
PrincipalName ::= SEQUENCE {
|
|
name-type[0] INTEGER,
|
|
name-string[1] SEQUENCE OF GeneralString
|
|
}
|
|
|
|
For the purposes of encoding an X.500 name as a Kerberos name for
|
|
use in Kerberos structures, the name-string shall be encoded as a
|
|
single GeneralString. The name-type should be KRB_NT_X500_PRINCIPAL,
|
|
as noted above. All Kerberos names must conform to validity
|
|
requirements as given in RFC 1510. Note that name mapping may be
|
|
required or optional, based on policy.
|
|
|
|
We also define the following similar ASN.1 structure:
|
|
|
|
CertPrincipalName ::= SEQUENCE {
|
|
name-type[0] INTEGER,
|
|
name-string[1] SEQUENCE OF UTF8String
|
|
}
|
|
|
|
When a Kerberos PrincipalName is to be placed within an X.509 data
|
|
structure, the CertPrincipalName structure is to be used, with the
|
|
name-string encoded as a single UTF8String. The name-type should be
|
|
as identified in the original PrincipalName structure. The mapping
|
|
between the GeneralString and UTF8String formats can be found in
|
|
[19].
|
|
|
|
The following rules relate to the the matching of PrincipalNames (or
|
|
corresponding CertPrincipalNames) with regard to the PKI name
|
|
constraints for CAs as laid out in RFC 2459 [15]. In order to be
|
|
regarded as a match (for permitted and excluded name trees), the
|
|
following must be satisfied.
|
|
|
|
1. If the constraint is given as a user plus realm name, or
|
|
as a user plus instance plus realm name (as specified in
|
|
RFC 1510), the realm name must be valid (see 2.a-d below)
|
|
and the match must be exact, byte for byte.
|
|
|
|
2. If the constraint is given only as a realm name, matching
|
|
depends on the type of the realm:
|
|
|
|
a. If the realm contains a colon (':') before any equal
|
|
sign ('='), it is treated as a realm of type Other,
|
|
and must match exactly, byte for byte.
|
|
|
|
b. Otherwise, if the realm contains an equal sign, it
|
|
is treated as an X.500 name. In order to match, every
|
|
component in the constraint MUST be in the principal
|
|
name, and have the same value. For example, 'C=US'
|
|
matches 'C=US/O=ISI' but not 'C=UK'.
|
|
|
|
c. Otherwise, if the realm name conforms to rules regarding
|
|
the format of DNS names, it is considered a realm name of
|
|
type Domain. The constraint may be given as a realm
|
|
name 'FOO.BAR', which matches any PrincipalName within
|
|
the realm 'FOO.BAR' but not those in subrealms such as
|
|
'CAR.FOO.BAR'. A constraint of the form '.FOO.BAR'
|
|
matches PrincipalNames in subrealms of the form
|
|
'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself.
|
|
|
|
d. Otherwise, the realm name is invalid and does not match
|
|
under any conditions.
|
|
|
|
3.1.1. Encryption and Key Formats
|
|
|
|
In the exposition below, we use the terms public key and private
|
|
key generically. It should be understood that the term "public
|
|
key" may be used to refer to either a public encryption key or a
|
|
signature verification key, and that the term "private key" may be
|
|
used to refer to either a private decryption key or a signature
|
|
generation key. The fact that these are logically distinct does
|
|
not preclude the assignment of bitwise identical keys for RSA
|
|
keys.
|
|
|
|
In the case of Diffie-Hellman, the key shall be produced from the
|
|
agreed bit string as follows:
|
|
|
|
* Truncate the bit string to the appropriate length.
|
|
* Rectify parity in each byte (if necessary) to obtain the key.
|
|
|
|
For instance, in the case of a DES key, we take the first eight
|
|
bytes of the bit stream, and then adjust the least significant bit
|
|
of each byte to ensure that each byte has odd parity.
|
|
|
|
3.1.2. Algorithm Identifiers
|
|
|
|
PKINIT does not define, but does permit, the algorithm identifiers
|
|
listed below.
|
|
|
|
3.1.2.1. Signature Algorithm Identifiers
|
|
|
|
The following signature algorithm identifiers specified in [11] and
|
|
in [15] shall be used with PKINIT:
|
|
|
|
id-dsa-with-sha1 (DSA with SHA1)
|
|
md5WithRSAEncryption (RSA with MD5)
|
|
sha-1WithRSAEncryption (RSA with SHA1)
|
|
|
|
3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
|
|
|
|
The following algorithm identifier shall be used within the
|
|
SubjectPublicKeyInfo data structure: dhpublicnumber
|
|
|
|
This identifier and the associated algorithm parameters are
|
|
specified in RFC 2459 [15].
|
|
|
|
3.1.2.3. Algorithm Identifiers for RSA Encryption
|
|
|
|
These algorithm identifiers are used inside the EnvelopedData data
|
|
structure, for encrypting the temporary key with a public key:
|
|
|
|
rsaEncryption (RSA encryption, PKCS#1 v1.5)
|
|
id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0)
|
|
|
|
Both of the above RSA encryption schemes are specified in [16].
|
|
Currently, only PKCS#1 v1.5 is specified by CMS [11], although the
|
|
CMS specification says that it will likely include PKCS#1 v2.0 in
|
|
the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext
|
|
vulnerability discovered in PKCS#1 v1.5.)
|
|
|
|
3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
|
|
|
|
These algorithm identifiers are used inside the EnvelopedData data
|
|
structure in the PKINIT Reply, for encrypting the reply key with the
|
|
temporary key:
|
|
des-ede3-cbc (3-key 3-DES, CBC mode)
|
|
rc2-cbc (RC2, CBC mode)
|
|
|
|
The full definition of the above algorithm identifiers and their
|
|
corresponding parameters (an IV for block chaining) is provided in
|
|
the CMS specification [11].
|
|
|
|
3.2. Public Key Authentication
|
|
|
|
Implementation of the changes in this section is REQUIRED for
|
|
compliance with PKINIT.
|
|
|
|
3.2.1. Client Request
|
|
|
|
Public keys may be signed by some certification authority (CA), or
|
|
they may be maintained by the KDC in which case the KDC is the
|
|
trusted authority. Note that the latter mode does not require the
|
|
use of certificates.
|
|
|
|
The initial authentication request is sent as per RFC 1510, except
|
|
that a preauthentication field containing data signed by the user's
|
|
private key accompanies the request:
|
|
|
|
PA-PK-AS-REQ ::= SEQUENCE {
|
|
-- PA TYPE 14
|
|
signedAuthPack [0] SignedData
|
|
-- Defined in CMS [11];
|
|
-- AuthPack (below) defines the
|
|
-- data that is signed.
|
|
trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL,
|
|
-- This is a list of CAs that the
|
|
-- client trusts and that certify
|
|
-- KDCs.
|
|
kdcCert [2] IssuerAndSerialNumber OPTIONAL
|
|
-- As defined in CMS [11];
|
|
-- specifies a particular KDC
|
|
-- certificate if the client
|
|
-- already has it.
|
|
encryptionCert [3] IssuerAndSerialNumber OPTIONAL
|
|
-- For example, this may be the
|
|
-- client's Diffie-Hellman
|
|
-- certificate, or it may be the
|
|
-- client's RSA encryption
|
|
-- certificate.
|
|
}
|
|
|
|
TrustedCas ::= CHOICE {
|
|
principalName [0] KerberosName,
|
|
-- as defined below
|
|
caName [1] Name
|
|
-- fully qualified X.500 name
|
|
-- as defined by X.509
|
|
issuerAndSerial [2] IssuerAndSerialNumber
|
|
-- Since a CA may have a number of
|
|
-- certificates, only one of which
|
|
-- a client trusts
|
|
}
|
|
|
|
Usage of SignedData:
|
|
|
|
The SignedData data type is specified in the Cryptographic
|
|
Message Syntax, a product of the S/MIME working group of the
|
|
IETF. The following describes how to fill in the fields of
|
|
this data:
|
|
|
|
1. The encapContentInfo field must contain the PKAuthenticator
|
|
and, optionally, the client's Diffie Hellman public value.
|
|
|
|
a. The eContentType field shall contain the OID value for
|
|
pkauthdata: iso (1) org (3) dod (6) internet (1)
|
|
security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)
|
|
|
|
b. The eContent field is data of the type AuthPack (below).
|
|
|
|
2. The signerInfos field contains the signature of AuthPack.
|
|
|
|
3. The Certificates field, when non-empty, contains the client's
|
|
certificate chain. If present, the KDC uses the public key
|
|
from the client's certificate to verify the signature in the
|
|
request. Note that the client may pass different certificate
|
|
chains that are used for signing or for encrypting. Thus,
|
|
the KDC may utilize a different client certificate for
|
|
signature verification than the one it uses to encrypt the
|
|
reply to the client. For example, the client may place a
|
|
Diffie-Hellman certificate in this field in order to convey
|
|
its static Diffie Hellman certificate to the KDC to enable
|
|
static-ephemeral Diffie-Hellman mode for the reply; in this
|
|
case, the client does NOT place its public value in the
|
|
AuthPack (defined below). As another example, the client may
|
|
place an RSA encryption certificate in this field. However,
|
|
there must always be (at least) a signature certificate.
|
|
|
|
AuthPack ::= SEQUENCE {
|
|
pkAuthenticator [0] PKAuthenticator,
|
|
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
|
|
-- if client is using Diffie-Hellman
|
|
-- (ephemeral-ephemeral only)
|
|
}
|
|
|
|
PKAuthenticator ::= SEQUENCE {
|
|
cusec [0] INTEGER,
|
|
-- for replay prevention as in RFC1510
|
|
ctime [1] KerberosTime,
|
|
-- for replay prevention as in RFC1510
|
|
nonce [2] INTEGER,
|
|
pachecksum [3] Checksum
|
|
-- Checksum over KDC-REQ-BODY
|
|
-- Defined by Kerberos spec
|
|
}
|
|
|
|
SubjectPublicKeyInfo ::= SEQUENCE {
|
|
algorithm AlgorithmIdentifier,
|
|
-- dhKeyAgreement
|
|
subjectPublicKey BIT STRING
|
|
-- for DH, equals
|
|
-- public exponent (INTEGER encoded
|
|
-- as payload of BIT STRING)
|
|
} -- as specified by the X.509 recommendation [10]
|
|
|
|
AlgorithmIdentifier ::= SEQUENCE {
|
|
algorithm OBJECT IDENTIFIER,
|
|
-- for dhKeyAgreement, this is
|
|
-- { iso (1) member-body (2) US (840)
|
|
-- rsadsi (113459) pkcs (1) 3 1 }
|
|
-- from PKCS #3 [20]
|
|
parameters ANY DEFINED by algorithm OPTIONAL
|
|
-- for dhKeyAgreement, this is
|
|
-- DHParameter
|
|
} -- as specified by the X.509 recommendation [10]
|
|
|
|
DHParameter ::= SEQUENCE {
|
|
prime INTEGER,
|
|
-- p
|
|
base INTEGER,
|
|
-- g
|
|
privateValueLength INTEGER OPTIONAL
|
|
-- l
|
|
} -- as defined in PKCS #3 [20]
|
|
|
|
If the client passes an issuer and serial number in the request,
|
|
the KDC is requested to use the referred-to certificate. If none
|
|
exists, then the KDC returns an error of type
|
|
KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the
|
|
other hand, the client does not pass any trustedCertifiers,
|
|
believing that it has the KDC's certificate, but the KDC has more
|
|
than one certificate. The KDC should include information in the
|
|
KRB-ERROR message that indicates the KDC certificate(s) that a
|
|
client may utilize. This data is specified in the e-data, which
|
|
is defined in RFC 1510 revisions as a SEQUENCE of TypedData:
|
|
|
|
TypedData ::= SEQUENCE {
|
|
data-type [0] INTEGER,
|
|
data-value [1] OCTET STRING,
|
|
} -- per Kerberos RFC 1510 revisions
|
|
|
|
where:
|
|
data-type = TD-PKINIT-CMS-CERTIFICATES = 101
|
|
data-value = CertificateSet // as specified by CMS [11]
|
|
|
|
The PKAuthenticator carries information to foil replay attacks, to
|
|
bind the pre-authentication data to the KDC-REQ-BODY, and to bind the
|
|
request and response. The PKAuthenticator is signed with the client's
|
|
signature key.
|
|
|
|
3.2.2. KDC Response
|
|
|
|
Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
|
|
type, the KDC attempts to verify the user's certificate chain
|
|
(userCert), if one is provided in the request. This is done by
|
|
verifying the certification path against the KDC's policy of
|
|
legitimate certifiers. This may be based on a certification
|
|
hierarchy, or it may be simply a list of recognized certifiers in a
|
|
system like PGP.
|
|
|
|
If the client's certificate chain contains no certificate signed by
|
|
a CA trusted by the KDC, then the KDC sends back an error message
|
|
of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data
|
|
is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104)
|
|
whose data-value is an OCTET STRING which is the DER encoding of
|
|
|
|
TrustedCertifiers ::= SEQUENCE OF PrincipalName
|
|
-- X.500 name encoded as a principal name
|
|
-- see Section 3.1
|
|
|
|
If while verifying a certificate chain the KDC determines that the
|
|
signature on one of the certificates in the CertificateSet from
|
|
the signedAuthPack fails verification, then the KDC returns an
|
|
error of type KDC_ERR_INVALID_CERTIFICATE. The accompanying
|
|
e-data is a SEQUENCE of one TypedData (with type
|
|
TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING
|
|
which is the DER encoding of the index into the CertificateSet
|
|
ordered as sent by the client.
|
|
|
|
CertificateIndex ::= INTEGER
|
|
-- 0 = 1st certificate,
|
|
-- (in order of encoding)
|
|
-- 1 = 2nd certificate, etc
|
|
|
|
The KDC may also check whether any of the certificates in the
|
|
client's chain has been revoked. If one of the certificates has
|
|
been revoked, then the KDC returns an error of type
|
|
KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that
|
|
the certificate's revocation status is unknown or not
|
|
available, then if required by policy, the KDC returns the
|
|
appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or
|
|
KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three
|
|
cases, the affected certificate is identified by the accompanying
|
|
e-data, which contains a CertificateIndex as described for
|
|
KDC_ERR_INVALID_CERTIFICATE.
|
|
|
|
If the certificate chain can be verified, but the name of the
|
|
client in the certificate does not match the client's name in the
|
|
request, then the KDC returns an error of type
|
|
KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data
|
|
field in this case.
|
|
|
|
Finally, if the certificate chain is verified, but the KDC's name
|
|
or realm as given in the PKAuthenticator does not match the KDC's
|
|
actual principal name, then the KDC returns an error of type
|
|
KDC_ERR_KDC_NAME_MISMATCH. The accompanying e-data field is again
|
|
a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or
|
|
TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET
|
|
STRING whose data-value is the DER encoding of a PrincipalName or
|
|
Realm as defined in RFC 1510 revisions.
|
|
|
|
Even if all succeeds, the KDC may--for policy reasons--decide not
|
|
to trust the client. In this case, the KDC returns an error message
|
|
of type KDC_ERR_CLIENT_NOT_TRUSTED. One specific case of this is
|
|
the presence or absence of an Enhanced Key Usage (EKU) OID within
|
|
the certificate extensions. The rules regarding acceptability of
|
|
an EKU sequence (or the absence of any sequence) are a matter of
|
|
local policy. For the benefit of implementers, we define a PKINIT
|
|
EKU OID as the following: iso (1) org (3) dod (6) internet (1)
|
|
security (5) kerberosv5 (2) pkinit (3) pkekuoid (2).
|
|
|
|
If a trust relationship exists, the KDC then verifies the client's
|
|
signature on AuthPack. If that fails, the KDC returns an error
|
|
message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the
|
|
timestamp (ctime and cusec) in the PKAuthenticator to assure that
|
|
the request is not a replay. The KDC also verifies that its name
|
|
is specified in the PKAuthenticator.
|
|
|
|
If the clientPublicValue field is filled in, indicating that the
|
|
client wishes to use Diffie-Hellman key agreement, then the KDC
|
|
checks to see that the parameters satisfy its policy. If they do
|
|
not (e.g., the prime size is insufficient for the expected
|
|
encryption type), then the KDC sends back an error message of type
|
|
KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and
|
|
private values for the response.
|
|
|
|
The KDC also checks that the timestamp in the PKAuthenticator is
|
|
within the allowable window and that the principal name and realm
|
|
are correct. If the local (server) time and the client time in the
|
|
authenticator differ by more than the allowable clock skew, then the
|
|
KDC returns an error message of type KRB_AP_ERR_SKEW as defined in 1510.
|
|
|
|
Assuming no errors, the KDC replies as per RFC 1510, except as
|
|
follows. The user's name in the ticket is determined by the
|
|
following decision algorithm:
|
|
|
|
1. If the KDC has a mapping from the name in the certificate
|
|
to a Kerberos name, then use that name.
|
|
Else
|
|
2. If the certificate contains the SubjectAltName extention
|
|
and the local KDC policy defines a mapping from the
|
|
SubjectAltName to a Kerberos name, then use that name.
|
|
Else
|
|
3. Use the name as represented in the certificate, mapping
|
|
mapping as necessary (e.g., as per RFC 2253 for X.500
|
|
names). In this case the realm in the ticket shall be the
|
|
name of the certifier that issued the user's certificate.
|
|
|
|
Note that a principal name may be carried in the subject alt name
|
|
field of a certificate. This name may be mapped to a principal
|
|
record in a security database based on local policy, for example
|
|
the subject alt name may be kerberos/principal@realm format. In
|
|
this case the realm name is not that of the CA but that of the
|
|
local realm doing the mapping (or some realm name chosen by that
|
|
realm).
|
|
|
|
If a non-KDC X.509 certificate contains the principal name within
|
|
the subjectAltName version 3 extension , that name may utilize
|
|
KerberosName as defined below, or, in the case of an S/MIME
|
|
certificate [17], may utilize the email address. If the KDC
|
|
is presented with an S/MIME certificate, then the email address
|
|
within subjectAltName will be interpreted as a principal and realm
|
|
separated by the "@" sign, or as a name that needs to be
|
|
canonicalized. If the resulting name does not correspond to a
|
|
registered principal name, then the principal name is formed as
|
|
defined in section 3.1.
|
|
|
|
The trustedCertifiers field contains a list of certification
|
|
authorities trusted by the client, in the case that the client does
|
|
not possess the KDC's public key certificate. If the KDC has no
|
|
certificate signed by any of the trustedCertifiers, then it returns
|
|
an error of type KDC_ERR_KDC_NOT_TRUSTED.
|
|
|
|
KDCs should try to (in order of preference):
|
|
1. Use the KDC certificate identified by the serialNumber included
|
|
in the client's request.
|
|
2. Use a certificate issued to the KDC by the client's CA (if in the
|
|
middle of a CA key roll-over, use the KDC cert issued under same
|
|
CA key as user cert used to verify request).
|
|
3. Use a certificate issued to the KDC by one of the client's
|
|
trustedCertifier(s);
|
|
If the KDC is unable to comply with any of these options, then the
|
|
KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
|
|
client.
|
|
|
|
The KDC encrypts the reply not with the user's long-term key, but
|
|
with the Diffie Hellman derived key or a random key generated
|
|
for this particular response which is carried in the padata field of
|
|
the TGS-REP message.
|
|
|
|
PA-PK-AS-REP ::= CHOICE {
|
|
-- PA TYPE 15
|
|
dhSignedData [0] SignedData,
|
|
-- Defined in CMS and used only with
|
|
-- Diffie-Hellman key exchange (if the
|
|
-- client public value was present in the
|
|
-- request).
|
|
-- This choice MUST be supported
|
|
-- by compliant implementations.
|
|
encKeyPack [1] EnvelopedData,
|
|
-- Defined in CMS
|
|
-- The temporary key is encrypted
|
|
-- using the client public key
|
|
-- key
|
|
-- SignedReplyKeyPack, encrypted
|
|
-- with the temporary key, is also
|
|
-- included.
|
|
}
|
|
|
|
Usage of SignedData:
|
|
|
|
When the Diffie-Hellman option is used, dhSignedData in
|
|
PA-PK-AS-REP provides authenticated Diffie-Hellman parameters
|
|
of the KDC. The reply key used to encrypt part of the KDC reply
|
|
message is derived from the Diffie-Hellman exchange:
|
|
|
|
1. Both the KDC and the client calculate a secret value
|
|
(g^ab mod p), where a is the client's private exponent and
|
|
b is the KDC's private exponent.
|
|
|
|
2. Both the KDC and the client take the first N bits of this
|
|
secret value and convert it into a reply key. N depends on
|
|
the reply key type.
|
|
|
|
3. If the reply key is DES, N=64 bits, where some of the bits
|
|
are replaced with parity bits, according to FIPS PUB 74.
|
|
|
|
4. If the reply key is (3-key) 3-DES, N=192 bits, where some
|
|
of the bits are replaced with parity bits, according to
|
|
FIPS PUB 74.
|
|
|
|
5. The encapContentInfo field must contain the KdcDHKeyInfo as
|
|
defined below.
|
|
|
|
a. The eContentType field shall contain the OID value for
|
|
pkdhkeydata: iso (1) org (3) dod (6) internet (1)
|
|
security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2)
|
|
|
|
b. The eContent field is data of the type KdcDHKeyInfo
|
|
(below).
|
|
|
|
6. The certificates field must contain the certificates
|
|
necessary for the client to establish trust in the KDC's
|
|
certificate based on the list of trusted certifiers sent by
|
|
the client in the PA-PK-AS-REQ. This field may be empty if
|
|
the client did not send to the KDC a list of trusted
|
|
certifiers (the trustedCertifiers field was empty, meaning
|
|
that the client already possesses the KDC's certificate).
|
|
|
|
7. The signerInfos field is a SET that must contain at least
|
|
one member, since it contains the actual signature.
|
|
|
|
KdcDHKeyInfo ::= SEQUENCE {
|
|
-- used only when utilizing Diffie-Hellman
|
|
nonce [0] INTEGER,
|
|
-- binds responce to the request
|
|
subjectPublicKey [2] BIT STRING
|
|
-- Equals public exponent (g^a mod p)
|
|
-- INTEGER encoded as payload of
|
|
-- BIT STRING
|
|
}
|
|
|
|
Usage of EnvelopedData:
|
|
|
|
The EnvelopedData data type is specified in the Cryptographic
|
|
Message Syntax, a product of the S/MIME working group of the
|
|
IETF. It contains a temporary key encrypted with the PKINIT
|
|
client's public key. It also contains a signed and encrypted
|
|
reply key.
|
|
|
|
1. The originatorInfo field is not required, since that
|
|
information may be presented in the signedData structure
|
|
that is encrypted within the encryptedContentInfo field.
|
|
|
|
2. The optional unprotectedAttrs field is not required for
|
|
PKINIT.
|
|
|
|
3. The recipientInfos field is a SET which must contain exactly
|
|
one member of the KeyTransRecipientInfo type for encryption
|
|
with an RSA public key.
|
|
|
|
a. The encryptedKey field (in KeyTransRecipientInfo)
|
|
contains the temporary key which is encrypted with the
|
|
PKINIT client's public key.
|
|
|
|
4. The encryptedContentInfo field contains the signed and
|
|
encrypted reply key.
|
|
|
|
a. The contentType field shall contain the OID value for
|
|
id-signedData: iso (1) member-body (2) us (840)
|
|
rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2)
|
|
|
|
b. The encryptedContent field is encrypted data of the CMS
|
|
type signedData as specified below.
|
|
|
|
i. The encapContentInfo field must contains the
|
|
ReplyKeyPack.
|
|
|
|
* The eContentType field shall contain the OID value
|
|
for pkrkeydata: iso (1) org (3) dod (6) internet (1)
|
|
security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3)
|
|
|
|
* The eContent field is data of the type ReplyKeyPack
|
|
(below).
|
|
|
|
ii. The certificates field must contain the certificates
|
|
necessary for the client to establish trust in the
|
|
KDC's certificate based on the list of trusted
|
|
certifiers sent by the client in the PA-PK-AS-REQ.
|
|
This field may be empty if the client did not send
|
|
to the KDC a list of trusted certifiers (the
|
|
trustedCertifiers field was empty, meaning that the
|
|
client already possesses the KDC's certificate).
|
|
|
|
iii. The signerInfos field is a SET that must contain at
|
|
least one member, since it contains the actual
|
|
signature.
|
|
|
|
ReplyKeyPack ::= SEQUENCE {
|
|
-- not used for Diffie-Hellman
|
|
replyKey [0] EncryptionKey,
|
|
-- used to encrypt main reply
|
|
-- ENCTYPE is at least as strong as
|
|
-- ENCTYPE of session key
|
|
nonce [1] INTEGER,
|
|
-- binds response to the request
|
|
-- must be same as the nonce
|
|
-- passed in the PKAuthenticator
|
|
}
|
|
|
|
Since each certifier in the certification path of a user's
|
|
certificate is equivalent to a separate Kerberos realm, the name
|
|
of each certifier in the certificate chain must be added to the
|
|
transited field of the ticket. The format of these realm names is
|
|
defined in Section 3.1 of this document. If applicable, the
|
|
transit-policy-checked flag should be set in the issued ticket.
|
|
|
|
The KDC's certificate(s) must bind the public key(s) of the KDC to
|
|
a name derivable from the name of the realm for that KDC. X.509
|
|
certificates shall contain the principal name of the KDC
|
|
(defined in section 8.2 of RFC 1510) as the SubjectAltName version
|
|
3 extension. Below is the definition of this version 3 extension,
|
|
as specified by the X.509 standard:
|
|
|
|
subjectAltName EXTENSION ::= {
|
|
SYNTAX GeneralNames
|
|
IDENTIFIED BY id-ce-subjectAltName
|
|
}
|
|
|
|
GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
|
|
|
|
GeneralName ::= CHOICE {
|
|
otherName [0] OtherName,
|
|
...
|
|
}
|
|
|
|
OtherName ::= SEQUENCE {
|
|
type-id OBJECT IDENTIFIER,
|
|
value [0] EXPLICIT ANY DEFINED BY type-id
|
|
}
|
|
|
|
For the purpose of specifying a Kerberos principal name, the value
|
|
in OtherName shall be a KerberosName as defined in RFC 1510, but with
|
|
the PrincipalName replaced by CertPrincipalName as mentioned in
|
|
Section 3.1:
|
|
|
|
KerberosName ::= SEQUENCE {
|
|
realm [0] Realm,
|
|
principalName [1] CertPrincipalName -- defined above
|
|
}
|
|
|
|
This specific syntax is identified within subjectAltName by setting
|
|
the type-id in OtherName to krb5PrincipalName, where (from the
|
|
Kerberos specification) we have
|
|
|
|
krb5 OBJECT IDENTIFIER ::= { iso (1)
|
|
org (3)
|
|
dod (6)
|
|
internet (1)
|
|
security (5)
|
|
kerberosv5 (2) }
|
|
|
|
krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
|
|
|
|
(This specification may also be used to specify a Kerberos name
|
|
within the user's certificate.) The KDC's certificate may be signed
|
|
directly by a CA, or there may be intermediaries if the server resides
|
|
within a large organization, or it may be unsigned if the client
|
|
indicates possession (and trust) of the KDC's certificate.
|
|
|
|
The client then extracts the random key used to encrypt the main
|
|
reply. This random key (in encPaReply) is encrypted with either the
|
|
client's public key or with a key derived from the DH values
|
|
exchanged between the client and the KDC. The client uses this
|
|
random key to decrypt the main reply, and subsequently proceeds as
|
|
described in RFC 1510.
|
|
|
|
3.2.3. Required Algorithms
|
|
|
|
Not all of the algorithms in the PKINIT protocol specification have
|
|
to be implemented in order to comply with the proposed standard.
|
|
Below is a list of the required algorithms:
|
|
|
|
* Diffie-Hellman public/private key pairs
|
|
* utilizing Diffie-Hellman ephemeral-ephemeral mode
|
|
* SHA1 digest and DSA for signatures
|
|
* SHA1 digest also for the Checksum in the PKAuthenticator
|
|
* 3-key triple DES keys derived from the Diffie-Hellman Exchange
|
|
* 3-key triple DES Temporary and Reply keys
|
|
|
|
4. Logistics and Policy
|
|
|
|
This section describes a way to define the policy on the use of
|
|
PKINIT for each principal and request.
|
|
|
|
The KDC is not required to contain a database record for users
|
|
who use public key authentication. However, if these users are
|
|
registered with the KDC, it is recommended that the database record
|
|
for these users be modified to an additional flag in the attributes
|
|
field to indicate that the user should authenticate using PKINIT.
|
|
If this flag is set and a request message does not contain the
|
|
PKINIT preauthentication field, then the KDC sends back as error of
|
|
type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication
|
|
field of type PA-PK-AS-REQ must be included in the request.
|
|
|
|
5. Security Considerations
|
|
|
|
PKINIT raises a few security considerations, which we will address
|
|
in this section.
|
|
|
|
First of all, PKINIT introduces a new trust model, where KDCs do not
|
|
(necessarily) certify the identity of those for whom they issue
|
|
tickets. PKINIT does allow KDCs to act as their own CAs, in the
|
|
limited capacity of self-signing their certificates, but one of the
|
|
additional benefits is to align Kerberos authentication with a global
|
|
public key infrastructure. Anyone using PKINIT in this way must be
|
|
aware of how the certification infrastructure they are linking to
|
|
works.
|
|
|
|
Secondly, PKINIT also introduces the possibility of interactions
|
|
between different cryptosystems, which may be of widely varying
|
|
strengths. Many systems, for instance, allow the use of 512-bit
|
|
public keys. Using such keys to wrap data encrypted under strong
|
|
conventional cryptosystems, such as triple-DES, is inappropriate;
|
|
it adds a weak link to a strong one at extra cost. Implementors
|
|
and administrators should take care to avoid such wasteful and
|
|
deceptive interactions.
|
|
|
|
Lastly, PKINIT calls for randomly generated keys for conventional
|
|
cryptosystems. Many such systems contain systematically "weak"
|
|
keys. PKINIT implementations MUST avoid use of these keys, either
|
|
by discarding those keys when they are generated, or by fixing them
|
|
in some way (e.g., by XORing them with a given mask). These
|
|
precautions vary from system to system; it is not our intention to
|
|
give an explicit recipe for them here.
|
|
|
|
6. Transport Issues
|
|
|
|
Certificate chains can potentially grow quite large and span several
|
|
UDP packets; this in turn increases the probability that a Kerberos
|
|
message involving PKINIT extensions will be broken in transit. In
|
|
light of the possibility that the Kerberos specification will
|
|
require KDCs to accept requests using TCP as a transport mechanism,
|
|
we make the same recommendation with respect to the PKINIT
|
|
extensions as well.
|
|
|
|
7. Bibliography
|
|
|
|
[1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service
|
|
(V5). Request for Comments 1510.
|
|
|
|
[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
|
|
for Computer Networks, IEEE Communications, 32(9):33-38. September
|
|
1994.
|
|
|
|
[3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,
|
|
A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm
|
|
Authentication in Kerberos. draft-ietf-cat-kerberos-pk-cross-04.txt
|
|
|
|
[4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in
|
|
Kerberos. draft-ietf-cat-kerberos-anoncred-00.txt
|
|
|
|
[5] Ari Medvinsky, M. Hur, Alexander Medvinsky, B. Clifford Neuman.
|
|
Public Key Utilizing Tickets for Application Servers (PKTAPP).
|
|
draft-ietf-cat-pktapp-02.txt
|
|
|
|
[6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos
|
|
Using Public Key Cryptography. Symposium On Network and Distributed
|
|
System Security, 1997.
|
|
|
|
[7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
|
|
Protocol. In Proceedings of the USENIX Workshop on Electronic
|
|
Commerce, July 1995.
|
|
|
|
[8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0
|
|
Request for Comments 2246, January 1999.
|
|
|
|
[9] B.C. Neuman, Proxy-Based Authorization and Accounting for
|
|
Distributed Systems. In Proceedings of the 13th International
|
|
Conference on Distributed Computing Systems, May 1993.
|
|
|
|
[10] ITU-T (formerly CCITT) Information technology - Open Systems
|
|
Interconnection - The Directory: Authentication Framework
|
|
Recommendation X.509 ISO/IEC 9594-8
|
|
|
|
[11] R. Housley. Cryptographic Message Syntax.
|
|
draft-ietf-smime-cms-13.txt, April 1999, approved for publication
|
|
as RFC.
|
|
|
|
[12] PKCS #7: Cryptographic Message Syntax Standard,
|
|
An RSA Laboratories Technical Note Version 1.5
|
|
Revised November 1, 1993
|
|
|
|
[13] R. Rivest, MIT Laboratory for Computer Science and RSA Data
|
|
Security, Inc. A Description of the RC2(r) Encryption Algorithm
|
|
March 1998.
|
|
Request for Comments 2268.
|
|
|
|
[14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
|
|
Protocol (v3): UTF-8 String Representation of Distinguished Names.
|
|
Request for Comments 2253.
|
|
|
|
[15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
|
|
Key Infrastructure, Certificate and CRL Profile, January 1999.
|
|
Request for Comments 2459.
|
|
|
|
[16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
|
|
Specifications, October 1998. Request for Comments 2437.
|
|
|
|
[17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. S/MIME
|
|
Version 2 Certificate Handling, March 1998. Request for
|
|
Comments 2312.
|
|
|
|
[18] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access
|
|
Protocol (v3), December 1997. Request for Comments 2251.
|
|
|
|
[19] ITU-T (formerly CCITT) Information Processing Systems - Open
|
|
Systems Interconnection - Specification of Abstract Syntax Notation
|
|
One (ASN.1) Rec. X.680 ISO/IEC 8824-1
|
|
|
|
[20] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
|
|
Laboratories Technical Note, Version 1.4, Revised November 1, 1993.
|
|
|
|
8. Acknowledgements
|
|
|
|
Some of the ideas on which this proposal is based arose during
|
|
discussions over several years between members of the SAAG, the IETF
|
|
CAT working group, and the PSRG, regarding integration of Kerberos
|
|
and SPX. Some ideas have also been drawn from the DASS system.
|
|
These changes are by no means endorsed by these groups. This is an
|
|
attempt to revive some of the goals of those groups, and this
|
|
proposal approaches those goals primarily from the Kerberos
|
|
perspective. Lastly, comments from groups working on similar ideas
|
|
in DCE have been invaluable.
|
|
|
|
9. Expiration Date
|
|
|
|
This draft expires January 15, 2001.
|
|
|
|
10. Authors
|
|
|
|
Brian Tung
|
|
Clifford Neuman
|
|
USC Information Sciences Institute
|
|
4676 Admiralty Way Suite 1001
|
|
Marina del Rey CA 90292-6695
|
|
Phone: +1 310 822 1511
|
|
E-mail: {brian, bcn}@isi.edu
|
|
|
|
Matthew Hur
|
|
CyberSafe Corporation
|
|
1605 NW Sammamish Road
|
|
Issaquah WA 98027-5378
|
|
Phone: +1 425 391 6000
|
|
E-mail: matt.hur@cybersafe.com
|
|
|
|
Ari Medvinsky
|
|
Keen.com, Inc.
|
|
150 Independence Drive
|
|
Menlo Park CA 94025
|
|
Phone: +1 650 289 3134
|
|
E-mail: ari@keen.com
|
|
|
|
Sasha Medvinsky
|
|
Motorola
|
|
6450 Sequence Drive
|
|
San Diego, CA 92121
|
|
+1 858 404 2367
|
|
E-mail: smedvinsky@gi.com
|
|
|
|
John Wray
|
|
Iris Associates, Inc.
|
|
5 Technology Park Dr.
|
|
Westford, MA 01886
|
|
E-mail: John_Wray@iris.com
|
|
|
|
Jonathan Trostle
|
|
170 W. Tasman Dr.
|
|
San Jose, CA 95134
|
|
E-mail: jtrostle@cisco.com
|