revision of pk-init draft

[[e-mail]]

With the recent discussion of pk-init issues in mind, what follows is
a first cut revision of pk-init-03.txt.  Despite the label found in
this revision, this draft has *not* been resubmitted to the Internet
Drafts server as pk-init-04.txt, it is only a first step toward that
goal, itself an intermediate one.

I have tried to at least mention most if not all of the issues raised
at the working group meeting.  Many of the issues on the post I mailed
to the list were ones that the authors had already reached some sort of
rough consensus on; the resolutions have already been incorporated into
this revision.  Other issues were raised for the first time at the
meeting; I have either made reference to incipient changes in the main
Kerberos spec, or added sections explicitly soliticing discussion.

Here are the main changes to the PKINIT specification:

    1.  The rationale for the private key retrieval exchange
        defined in Section 3.4 has been clarified.  In addition,
        the exchange is now encrypted with the shared secret
        used to authenticate the user.

    2.  In the PA_PK_AS_REP and PA_PK_AS_SIGN preauthentication
        fields, the signed payload was previously encrypted
        using a public key.  This has been changed to a symmetric
        key, generated on the fly; this symmetric key is in turn
        encrypted using the public key.

    3.  Explicit mention of X.500 names and what to do with them
        has been added.  In particular, this draft leaves open
        the option of binding Kerberos principal names to the
        certificate through e.g. a v3 extension.  The KDC, in
        this *particular* case, can then insert the Kerberos
        principal name into the ticket, in place of the X.500
        name.  Otherwise, the KDC must place the X.500 name without
        modification into the ticket.

    4.  Since the Kerberos spec is apparently about to recommend
        TCP as a transport mechanism, I have put the propensity of
        PKINIT messages to become large and breakable in the
        proximity of UDP and long long certificates as a discussion
        item near the end of the draft.

    5.  Some ASN.1 changes have been introduced to make the names
        more mnemonic (hah!) and consistent; some structures have
        been changed to maximize reuse of encoding/decoding functions.

    6.  I have surreptitiously switched the order of my and Cliff's
        names in the author list.

And now, without further ado, the proto-pk-init-04.txt...

b

=====

INTERNET-DRAFT                                              Brian Tung
draft-ietf-cat-kerberos-pk-init-04.txt                 Clifford Neuman
Updates: RFC 1510                                                  ISI
expires October 31, 1997                                     John Wray
                                         Digital Equipment Corporation
                                                         Ari Medvinsky
                                                           Matthew Hur
                                                 CyberSafe Corporation
                                                      Jonathan Trostle
                                                                Novell


    Public Key Cryptography for Initial Authentication in Kerberos


0.  Status Of This Memo

    This document is an Internet-Draft.  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."

    To learn the current status of any Internet-Draft, please check
    the "1id-abstracts.txt" listing contained in the Internet-Drafts
    Shadow Directories on ds.internic.net (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-04.txt, and expires October 31,
    1997.  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 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.

    One of the guiding principles in the design of PKINIT is that
    changes should be as minimal as possible.  As a result, the basic
    mechanism of PKINIT is as follows:  The user sends a request to the
    KDC as before, except that if that user is to use public key
    cryptography in the initial authentication step, his certificate
    accompanies 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 instead
    of being encrypted in the user's long-term key (which is derived
    from a password), it is encrypted in a randomly-generated key.  This
    random key is in turn encrypted using the public key certificate
    that came with the request and signed using the KDC's private key,
    and accompanies the reply, in the preauthentication fields.

    PKINIT also allows for users with only digital signature keys to
    authenticate using those keys, and for users to store and retrieve
    private keys on the KDC.

    The PKINIT specification may also be used for direct peer to peer
    authentication without contacting a central KDC. This application
    of PKINIT is described in PKTAPP [4] and is based on concepts
    introduced in [5, 6]. 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 SSL [7] 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 [8]).


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 changes to RFC 1510 are 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.
        --> Users may store private keys on the KDC for retrieval during
            Kerberos initial authentication.

    This proposal addresses two ways that users may use public key
    cryptography for initial authentication.  Users may present public
    key certificates, or they may generate their own session key,
    signed by their digital signature key.  In either case, the end
    result is that the user 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 and 3.3 describe the extensions for the two initial
    authentication methods.  Section 3.3 describes a way for the user to
    store and retrieve his private key on the KDC.


3.1.  Definitions

    Hash and encryption types will be specified using ENCTYPE tags; we
    propose the addition of the following types:

        #define ENCTYPE_SIGN_DSA_GENERATE       0x0007
        #define ENCTYPE_SIGN_DSA_VERIFY         0x0008
        #define ENCTYPE_ENCRYPT_RSA_PRIV        0x0009
        #define ENCTYPE_ENCRYPT_RSA_PUB         0x000a

    The extensions involve new preauthentication fields; we propose the
    addition of the following types:

        #define PA_PK_AS_REQ                    17
        #define PA_PK_AS_REP                    18
        #define PA_PK_AS_SIGN                   19
        #define PA_PK_KEY_REQ                   20
        #define PA_PK_KEY_REP                   21

    The extensions also involve new error types; we propose the addition
    of the following types:

        #define KDC_ERROR_CLIENT_NOT_TRUSTED    227
        #define KDC_ERROR_KDC_NOT_TRUSTED       228
        #define KDC_ERROR_INVALID_SIG           229

    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.


3.2.  Standard Public Key Authentication

    Implementation of the changes in this section is REQUIRED for
    compliance with PKINIT.

    It is assumed that all public keys are signed by some certification
    authority (CA).  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 17
        signedAuthPack          [0] SignedAuthPack
        userCert                [1] SEQUENCE OF Certificate OPTIONAL,
                                    -- the user's certificate chain
        trustedCertifiers       [2] SEQUENCE OF PrincipalName OPTIONAL
                                    -- CAs that the client trusts
    }

    SignedAuthPack ::= SEQUENCE {
        authPack                [0] AuthPack,
        authPackSig             [1] Signature,
                                    -- of authPack
                                    -- using user's private key
    }

    AuthPack ::= SEQUENCE {
        pkAuthenticator         [0] PKAuthenticator,
        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
                                    -- if client is using Diffie-Hellman
    }

    PKAuthenticator ::= SEQUENCE {
        kdcName                 [0] PrincipalName,
        cusec                   [1] INTEGER,
                                    -- for replay prevention
        ctime                   [2] KerberosTime,
                                    -- for replay prevention
        nonce                   [3] INTEGER
    }

    Signature ::= SEQUENCE {
        signedHash              [0] EncryptedData
                                    -- of type Checksum
                                    -- encrypted using private key
    }

    Checksum ::= SEQUENCE {
        cksumtype               [0] INTEGER,
        checksum                [1] OCTET STRING
    }   -- as specified by RFC 1510

    SubjectPublicKeyInfo ::= SEQUENCE {
        algorithm               [0] algorithmIdentifier,
        subjectPublicKey        [1] BIT STRING
    }   -- as specified by the X.509 recommendation [9]

    Certificate ::= SEQUENCE {
        certType                [0] INTEGER,
                                    -- type of certificate
                                    -- 1 = X.509v3 (DER encoding)
                                    -- 2 = PGP (per PGP draft)
        certData                [1] OCTET STRING
                                    -- actual certificate
                                    -- type determined by certType
    }

    The PKAuthenticator carries information to foil replay attacks,
    to bind the request and response, and to optionally pass the
    client's Diffie-Hellman public value (i.e. for using DSA in
    combination with Diffie-Hellman).  The PKAuthenticator is signed
    with the private key corresponding to the public key in the
    certificate found in userCert (or cached by the KDC).

    In the PKAuthenticator, the client may specify the KDC name in one
    of two ways:

        * The Kerberos principal name K/M@<realm_name>, where
          <realm_name> is replaced by the applicable realm name.
        * The name in the KDC's certificate (e.g., an X.500 name, or a
          PGP name).

    Note that the first case requires that the certificate name and the
    Kerberos principal name be bound together (e.g., via an X.509v3
    extension).

    The userCert field is a sequence of certificates, the first of which
    must be the user's public key certificate. Any subsequent
    certificates will be certificates of the certifiers of the user's
    certificate.  These cerificates may be used by the KDC to verify the
    user's public key.  This field may be left empty if the KDC already
    has the user's certificate.

    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.

    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 certification path does not match one of
    the KDC's trusted certifiers, the KDC sends back an error message of
    type KDC_ERROR_CLIENT_NOT_TRUSTED, and it includes in the error data
    field a list of its own trusted certifiers, upon which the client
    resends the request.

    If  trustedCertifiers is provided in the PA_PK_AS_REQ, the KDC
    verifies that it has a certificate issued by one of the certifiers
    trusted by the client.  If it does not have a suitable certificate,
    the KDC returns an error message of type KDC_ERROR_KDC_NOT_TRUSTED
    to the client. 

    If a trust relationship exists, the KDC then verifies the client's
    signature on PKAuthenticator.  If that fails, the KDC returns an
    error message of type KDC_ERROR_INVALID_SIG.  Otherwise, the KDC
    uses the timestamp in the PKAuthenticator to assure that the request
    is not a replay.   The KDC also verifies that its name is specified
    in PKAuthenticator.

    Assuming no errors, the KDC replies as per RFC 1510, except as
    follows:  The user's name in the ticket is as represented in the
    certificate, unless a Kerberos principal name is bound to the name
    in the certificate (e.g., via an X.509v3 extension).  Moreover, the
    KDC encrypts the reply not with the user's long-term key, but with a
    random key generated only for this particular response.  This random
    key is sealed in the preauthentication field:

    PA_PK_AS_REP ::= SEQUENCE {
                               -- PA TYPE 18
        encSignedReplyKeyPack   [0] EncryptedData,
                                    -- of type SignedReplyKeyPack
                                    -- using the temporary key
                                    -- in encTmpKey
        encTmpKeyPack           [1] EncryptedData,
                                    -- of type TmpKeyPack
                                    -- using either the client public
                                    -- key or the Diffie-Hellman key
                                    -- specified by SignedDHPublicValue
        signedKDCPublicValue    [2] SignedKDCPublicValue OPTIONAL
                                    -- if one was passed in the request
        kdcCert                 [3] SEQUENCE OF Certificate OPTIONAL,
                                    -- the KDC's certificate chain
    }

    SignedReplyKeyPack ::= SEQUENCE {
        replyKeyPack            [0] ReplyKeyPack,
        replyKeyPackSig         [1] Signature,
                                    -- of replyEncKeyPack
                                    -- using KDC's private key
    }

    ReplyKeyPack ::= SEQUENCE {
        replyKey                [0] EncryptionKey,
                                    -- used to encrypt main reply
        nonce                   [1] INTEGER
                                    -- binds response to the request
                                    -- must be same as the nonce
                                    -- passed in the PKAuthenticator
    }

    TmpKeyPack ::= SEQUENCE {
        tmpKey                  [0] EncryptionKey,
                                    -- used to encrypt the
                                    -- SignedReplyKeyPack
    }
        
    SignedKDCPublicValue ::= SEQUENCE {
        kdcPublicValue          [0] SubjectPublicKeyInfo,
        kdcPublicValueSig       [1] Signature
                                    -- of kdcPublicValue
                                    -- using KDC's private key
    }

    The kdcCert field is a sequence of certificates, the first of which
    must have as its root certifier one of the certifiers sent to the
    KDC in the PA_PK_AS_REQ. Any subsequent certificates will be 
    certificates of the certifiers of the KDC's certificate.  These
    cerificates may be used by the client to verify the KDC's public
    key.  This field is empty if the client did not send to the KDC a
    list of trusted certifiers (the trustedCertifiers field was empty).
    
    Since each certifier in the certification path of a user's
    certificate is essentially a separate realm, the name of each
    certifier shall be added to the transited field of the ticket.  The
    format of these realm names shall follow the naming constraints set
    forth in RFC 1510 (sections 7.1 and 3.3.3.1).  Note that this will
    require new nametypes to be defined for PGP certifiers and other
    types of realms as they arise.  If applicable, the
    transit-policy-checked flag should be set in the issued ticket.

    The KDC's certificate must bind the public key to a name derivable
    from the name of the realm for that KDC.  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.


3.3.  Digital Signature

    Implementation of the changes in this section are OPTIONAL for
    compliance with PKINIT.

    We offer this option with the warning that it requires the client to
    generate a random key; the client may not be able to guarantee the
    same level of randomness as the KDC.

    If the user registered a digital signature key with the KDC instead
    of an encryption key, then a separate exchange must be used.  The
    client sends a request for a TGT as usual, except that it (rather
    than the KDC) generates the random key that will be used to encrypt
    the KDC response.  This key is sent to the KDC along with the
    request in a preauthentication field:

    PA_PK_AS_SIGN ::= SEQUENCE {
                                -- PA TYPE 19
        encSignedRandomKeyPack  [0] EncryptedData,
                                    -- of type SignedRandomKeyPack
                                    -- using the key in encTmpKeyPack
        encTmpKeyPack           [1] EncryptedData,
                                    -- of type TmpKeyPack
                                    -- using the KDC's public key
        userCert                [2] SEQUENCE OF Certificate OPTIONAL
                                    -- the user's certificate chain
    }

    SignedRandomKeyPack ::= SEQUENCE {
        randomkeyPack           [0] RandomKeyPack,
        randomkeyPackSig        [1] Signature
                                    -- of keyPack
                                    -- using user's private key
    }

    RandomKeyPack ::= SEQUENCE {
        randomKey               [0] EncryptionKey,
                                    -- will be used to encrypt reply
        randomKeyAuth           [1] PKAuthenticator
                                    -- nonce copied from AS-REQ
    }

    Upon receipt of the PA_PK_AS_SIGN, the KDC decrypts then verifies
    the randomKey.  It then replies as per RFC 1510, except that the
    reply is encrypted not with a password-derived user key, but with
    the randomKey sent in the request.  Since the client already knows
    this key, there is no need to accompany the reply with an extra
    preauthentication field.  The transited field of the ticket should
    specify the certification path as described in Section 3.2.


3.4.  Retrieving the Private Key from the KDC

    Implementation of the changes described in this section are OPTIONAL
    for compliance with PKINIT.

    When the user's private key is not stored local to the user, he may
    choose to store the private key (normally encrypted using a
    password-derived key) on the KDC.  In this case, the client makes a
    request as described above, except that instead of preauthenticating
    with his private key, he uses a symmetric key shared with the KDC.

    For simplicity's sake, this shared key is derived from the password-
    derived key used to encrypt the private key, in such a way that the
    KDC can authenticate the user with the shared key without being able
    to extract the private key.

    We provide this option to present the user with an alternative to
    storing the private key on local disk at each machine where he
    expects to authenticate himself using PKINIT.  It should be noted
    that it replaces the added risk of long-term storage of the private
    key on possibly many workstations with the added risk of storing the
    private key on the KDC in a form vulnerable to brute-force attack.

    Denote by K1 the symmetric key used to encrypt the private key.
    Then construct symmetric key K2 as follows:

        * Perform a hash on K1.
        * Truncate the digest to L(K1) bytes.
        * Rectify parity in each byte (if necessary) to obtain K2.

    The KDC stores K2, the public key, and the encrypted private key.
    (The user may also store on the KDC additional public key pairs,
    which can be returned along with the "principal" key pair.)  When
    the client requests initial authentication using public key
    cryptography, it must then include in its request, instead of a
    PA_PK_AS_REQ, the following preauthentication sequence:

    PA_PK_KEY_REQ ::= SEQUENCE {
        signedPKAuth            [0] SignedPKAuth,
        trustedCertifiers       [1] SEQUENCE OF PrincipalName OPTIONAL,
                                    -- CAs that the client trusts
        keyIDList               [2] SEQUENCE OF KeyID OPTIONAL
                                    -- if absent, KDC will return all
                                    -- stored private keys
    }

    SignedPKAuth ::= SEQUENCE {
        pkAuth                  [0] PKAuthenticator,
        pkAuthSig               [1] Signature
                                    -- of pkAuth
                                    -- using the symmetric key K2
    }

    KeyID ::= SEQUENCE {
        hashType                [0] INTEGER,
                                    -- type of hash used for privKeyID
        privkeyID               [1] OCTET STRING
                                    -- hash of the public key
                                    -- corresponding to desired
                                    -- private key
    }

    No public key certificate is required, since the KDC stores the
    public key along with the private key.

    Upon receipt, the KDC verifies the signature using K2.  If all
    checks out, the KDC responds as described in Section 3.2, except
    that in addition, the KDC appends the following preauthentication
    sequence:

    PA_PK_KEY_REP ::= SEQUENCE {
        kdcCert                 [0] SEQUENCE OF Certificate OPTIONAL,
        encKeyRep               [1] EncryptedData
                                    -- of type EncKeyReply
                                    -- using the symmetric key K2
    }

    EncKeyReply ::= SEQUENCE {
        keyPackList             [0] SEQUENCE OF KeyPack,
                                    -- the first KeyPair is
                                    -- the primary key pair
        nonce                   [1] INTEGER
                                    -- binds reply to request
                                    -- must be identical to the nonce
                                    -- sent in the SignedAuthPack
    }

    KeyPack ::= SEQUENCE {
        keyID                   [0] KeyID,
        encPrivKey              [1] OCTET STRING
    }

    Upon receipt of the reply, the client extracts the encrypted private
    keys (and may store them, at the client's option).  The first
    private key in the keyPack SEQUENCE is used to decrypt the random
    key in the PA_PK_AS_REP; this key in turn is used to decrypt the
    main reply as described in Section 3.2.


4.  Logistics and Policy Issues

    We solicit discussion on how clients and KDCs should be configured
    in order to determine which of the options described above (if any)
    should be used.  One possibility is to set the user's database
    record to indicate that authentication is to use public key
    cryptography; this will not work, however, in the event that the
    client needs to choose an option before making the initial request.


5.  Dependence on Transport Mechanisms

    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
    recommend TCP as a transport mechanism, we solicit discussion on a
    similar statement with regard to PKINIT.


6.  Compatibility with One-Time Passcodes

    We solicit discussion on how the protocol changes proposed in this
    draft will interact with the proposed use of one-time passcodes
    discussed in draft-ietf-cat-kerberos-passwords-00.txt.


7.  Strength of Cryptographic Schemes

    In light of recent findings on the strength of MD5 and DES,
    we solicit discussion on which encryption types to incorporate
    into the protocol changes.


8.  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] A. Medvinsky, M. Hur.  Addition of Kerberos Cipher Suites to
    Transport Layer Security (TLS).
    draft-ietf-tls-kerb-cipher-suites-00.txt

    [4] A. Medvinsky, M. Hur, B. Clifford Neuman.  Public Key Utilizing
    Tickets for Application Servers (PKTAPP).
    draft-ietf-cat-pktapp-00.txt

    [5] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos Using 
    Public Key Cryptography.  Symposium On Network and Distributed System 
    Security, 1997.

    [6] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction 
    Protocol.  In Proceedings of the USENIX Workshop on Electronic Commerce,
    July 1995.

    [7] Alan O. Freier, Philip Karlton and Paul C. Kocher.
    The SSL Protocol, Version 3.0 - IETF Draft. 

    [8] B.C. Neuman, Proxy-Based Authorization and Accounting for 
    Distributed Systems.  In Proceedings of the 13th International 
    Conference on Distributed Computing Systems, May 1993

    [9] ITU-T (formerly CCITT)
    Information technology - Open Systems Interconnection -
    The Directory: Authentication Framework Recommendation X.509
    ISO/IEC 9594-8


9.  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.


10.  Expiration Date

    This draft expires October 31, 1997.


11.  Authors

    Brian Tung
    Clifford Neuman
    USC Information Sciences Institute
    4676 Admiralty Way Suite 1001
    Marina del Rey CA 90292-6695
    Phone: [phone]
    E-mail: {brian, bcn}@isi.edu

    John Wray
    Digital Equipment Corporation
    550 King Street, LKG2-2/Z7
    Littleton, MA 01460
    Phone: [phone]
    E-mail: [e-mail]

    Ari Medvinsky
    Matthew Hur
    CyberSafe Corporation
    1605 NW Sammamish Road Suite 310
    Issaquah WA 98027-5378
    Phone: [phone]
    E-mail: {ari.medvinsky, matt.hur}@cybersafe.com

    Jonathan Trostle
    Novell Corporation
    [insert address]
    E-mail: [e-mail]