[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01

Dynamic Host Configuration WG                         Olafur Gudmundsson
INTERNET DRAFT                               Trusted Information Systems
<draft-ietf-dhc-security-arch-00.txt>                     March 26, 1997


                      Security Architecture for DHCP
                      <draft-ietf-dhc-security-arch-00.txt>


    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 ftp.is.co.za (Africa),
    nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
    ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

    Abstract

    This document addresses the general security requirements of
    both v4 and v6 versions of DHCP. This document lists security
    requirements and proposes as security model, which meets scaling
    requirements, security requirements and efficiency requirements.

    The proposed security model uses public key cryptography and a
    proposed trusted key distribution mechanism to authenticate
    clients and servers. The authentication protocol can also
    exchange keying material for more efficiently protecting
    successive communication between client and server.  The
    security model also addresses securing relay agents.


1.  DHCP security requirements

    One of the problems of designing a security model for DHCP[DHCP]
    is the wide variety in use and preconditions that different
    sites/clients have. The fact that sites deploy redundant servers
    and the lack of a server to server protocol further complicates
    things, proposed server to server protocol is an Internet
    draft[Server]. This document assumes fair knowledge of DHCP.

1.1. What is authentication?

    Authentication is the process of establishing the identity of
    some entity.  Once identity has been authenticated that identity

Expires September 26, 1997                                     [Page  1]
Internet Draft                                            March 26, 1997

    can be used for access control, accounting etc.. Public key
    cryptography is a powerful tool that relies on complex
    mathematical operations to provide information that only the
    holder of the private key could have generated. For more
    background information see RFC-1825[RFC1825].

1.1. Requirements

    Throughout this document, the words that are used to define the
    significance of particular requirements are capitalized.  These
    words are:

          o "MUST"

    This word or the adjective "REQUIRED" means that the item is an
    absolute requirement of this specification.

          o "MUST NOT"

    This phrase means that the item is an absolute prohibition of
    this specification.

          o "SHOULD"

    This word or the adjective "RECOMMENDED" means that there may
    exist valid reasons in particular circumstances to ignore this
    item, but the full implications should be understood and the
    case carefully weighed before choosing a different course.

          o "SHOULD NOT"

    This phrase means that there may exist valid reasons in
    particular circumstances when the listed behavior is acceptable
    or even useful, but the full implications should be understood
    and the case carefully weighed before implementing any behavior
    described with this label.

          o "MAY"

    This word or the adjective "OPTIONAL" means that this item is
    truly optional.  One vendor may choose to include the item
    because a particular marketplace requires it or because it
    enhances the product, for example; another vendor may omit the
    same item.











Expires September 26, 1997                                     [Page  2]
Internet Draft                                            March 26, 1997

2. Proposed DHCP security requirements

    The proposed requirements can be summarized in the following
    rules.
    Initial Client/Server Authentication

        1.  Server MUST authenticate client identity.
        2.  Client SHOULD authenticate the server identity as
            authorized server

    Initial Relay Agent/Server Authentication

        3.  Server MUST authenticate relay agent identity as authorized
            relay agent.
        4.  Relay Agent MUST authenticate server identity as authorized
            server.

    Successive Client to Server and Relay Agent to Server
    Communication

        5.  Client and Server MUST agree on security model for
            protecting future communication.

    Server/Relay agent advertisements

        6. Advertisements MUST be verifiable by all recipients.

    DHCP security cannot be accomplished in a vacuum; fortunately
    there are available (or soon will be) protocols that DHCP can
    take advantage of. First and foremost DNSSEC[DNSSEC] or some
    other KEY distribution mechanism must be available.
    IPSEC[RFC1825,IPSEC] will be able to handle requirement 5. It is
    not clear if IPSEC for IPv6, in some cases using local link
    addresses, can address requirement 1-4. In the case of IPv4 DHCP
    MUST perform authentication.

2.1. DHCP Identity

    In order to secure DHCP all clients MUST have an identity, this
    identity can possibly be one of the following: host name, user
    identity, account code. The "prime" identity MUST have a public
    KEY stored in the key distribution mechanism. The client MUST
    know its identity before contacting the server.  Each client
    MUST have access to the correct private key before contacting
    the DHCP server.

    For example if the identity selected for a host is its host name
    and the key distribution mechanism is DNS, then the public key
    used to authenticate the host is stored under the host name in
    its home zone. The private key needs to be stored in the
    computer at all times. If the identity selected is the user then
    the key is stored under the user name in DNS (e.g.: ogud.tis.com
    for me), and user needs to load the computer with the private
    key before the host can contact the server.  If the identity of

Expires September 26, 1997                                     [Page  3]
Internet Draft                                            March 26, 1997

    the host is just there to uniquely identify the host, the host
    still needs a private key.

2.2. Policy issues.

    This document does not address access control issues as that is
    a policy issue for each site, but effective access control
    depends on correct authentication, thus this work will make
    access control simpler.  This document does not address the
    issue of protecting the private key on either server, agent or
    client.

3. Client Authentication:

    One of the goals of this document is to convince the working
    group that achieving initial authentication is the most
    important step. Once server and client have established each
    other's identity the remaining problems can easily be solved.

    The problem of initial client authentication cannot be solved by
    IPSEC, as the client does not have an IP identity when it
    requests service for the first time from server.  Once client
    has been configured it can enter IPSEC security associations
    with other DHCP servers during the lifetime of the IP address
    lease.

3.1     Types of DHCP clients and their identification needs.

    To DHCP there are two kinds of clients. Clients that request
    some of their net identity, and clients that request ALL of
    their net identity from DHCP. From a security point of view, the
    second type of client is no different, because these clients
    must have some identity (for example MAC address) that can be
    used to uniquely identify them. Previous DHCP security
    proposals[DHCAUTH] have suggested the use of shared secrets and
    passwords to identify clients.  It is also possible to use some
    kind of challenge/response system to identify clients. These
    approaches have limited scaling ability and require a server to
    server protocol. But in many environments these weaker
    authentication mechanisms are adequate.

    The most general case is the identification of a computer that
    connects to a world wide ISP network and expects the same
    identity regardless of location. In this case it is unlikely
    that the same DHCP server serves both India and Iceland. A
    network of this kind can have a collaborative agreement between
    number of different ISPs, with multiple administrative domains.
    It is not reasonable/scalable that all DHCP servers in this
    network know shared secrets, or passwords for all computers that
    are allowed to connect.  From a security standpoint it is a bad
    practice to distribute shared secrets or passwords to many
    places.

3.2. Motivation for single strong authentication schema.

Expires September 26, 1997                                     [Page  4]
Internet Draft                                            March 26, 1997


    The author feels that it is better to mandate ONE strong
    authentication protocol for all DHCP interaction, rather than
    allow for multiple ones and allow sites to choose the wrong one.
    The protocol below is a strong authentication using public key
    signatures and encryption. The security of the protocol depends
    on the difficulty in breaking the private keys used. The site
    security depends on the sites protecting the private keys. By
    mandating one protocol at this point we also eliminate the need
    for negotiating what authentication protocol to use. At this
    point the public key algorithm has not been selected.  The two
    leading candidates are RSA and ECC (Elliptical Curve
    Cryptography).

4.      General DHCP Client authentication protocol.

    This protocol depends on a reliable certified public key
    distribution mechanism like DNSSEC[DNSSEC]. Each host and server
    supplies it's identity, this identity indicates where the
    associated public key is stored. For DNS the identity is FQDN
    (Fully Qualified Domain Name), accompanied by key algorithm
    number and public key footprint. For other key distribution
    mechanisms there must be enough information to retrieve the key
    from that source. To successfully validate a server public key,
    clients must be configured with root key(s) for the key
    distribution certification tree.

    This protocol never transmits public keys as it is easy to forge
    self signed keys.  Instead certified keys are distributed via
    trusted 3rd party (eg. DNSSEC).  One of the preconditions of
    this protocol is that client and server MUST roughly agree on
    current time.  The role of the current time information below is
    to prevent replay attacks. If client does not know the current
    time, it MUST request it before starting the authentication
    process. Servers and Relay agents MUST provide current time upon
    request without any security checks.

    If the client does not know the current time, it must be able to
    ask the local relay agent/server for the current time without
    authentication and get an answer.

4.1. DHCP authentication protocol overview.

    In the following discussion, DHCP fields not important to the
    overall security schema are omitted.  Following protocol outline
    assumes that the key distribution mechanism is DNS.









Expires September 26, 1997                                     [Page  5]
Internet Draft                                            March 26, 1997

        1. Client:
        Sends server discovery packet containing
                Identity (this can be one of host identity, claimed identity,
                    charging identity)
                client's own public key identity
                Optionally its host identity
                current time
                security options/transformations supported
                DHCP requests for at least address, DNS server and gateway
                    address.
                all preceding data is signed by client private key
                    corresponding to the public key specified above.

        2. Server:
        If current time is within accepted range
        Look up client public key in key distribution mechanism
        verify signature
        is this client allowed to connect?
        If all above checks are passed server sends back
                server Public KEY  identity
                Security model selected
                key identifier ( if needed by security Model)
                current time.
                information client requested for configuration (Address, DNS
                    server, gateway)
                all above signed by the Server private KEY.

        3. Client can now
        configure itself
        Look up server Public Key in DNS.
        if Server key is found, client SHOULD validate packet and
            Server KEY using DNS
        client should also verify that DNS server is actually a valid
            DNS server.
        Sends server
                key identifier requesting keying material
                current time
                signed by client public key

        4. Server:
        Server generates a random key to use and it sends to client
                key identifier
                Keying material
                Lifetime of the security association.
                Current time
                This data is encrypted using clients public key

    The client decrypts the packet with its private key. At this
    point the client can assume its normal processing and send
    further requests to server protected by the security model
    selected.  The protocol for a relay agent is similar but is
    omitted here.



Expires September 26, 1997                                     [Page  6]
Internet Draft                                            March 26, 1997

4.2. Additions to the protocol overview.

    The protocol outlined above does not spell out all the possible
    error states that can be entered. This needs to be specified in
    the full protocol. Some of the possible errors include the
    following cases:

    What does the server do if it is unable to retrieve/validate the
    client key?
    The Client in its verification phase must be able to determine
    what are the authorized DHCP servers. This may require a new DNS
    record, or use the SRV[SRV] record.
    What does a client do if it is not able to convince itself that
    it is talking to a good DHCP server?

    Due to the fact that some of the operations required by this
    protocol take longer than the time-out values in unsecured DHCP,
    these need to be changed for Security aware servers and clients.
    There may be a need for a server to send back an ACK to a client
    indicating that a request has been received and is being
    processed to stop client from retransmitting requests.

    In the case of security aware client trying to talk to security
    ignorant server the server must return an error code informing
    the client that it does not understand the request. Security
    aware servers similarly must treat security ignorant clients
    differently, but how must be determined.

4.3.  Justification for the authentication protocol

    There are number of reasons why the protocol does not attempt to
    create a security association in the first round. By explicitly
    requesting the security association, the client is notifying the
    server that it trusts the server and wants to establish a long
    term relationship with it.  There is no reason to establish a
    security association with a server the client does not trust.

    If a server selects a shared secret or encryption as a message
    protection mechanism then the key selected by the server is for
    use between one client and one server for a limited time. If
    there is a group of DHCP servers for this site, then the server
    to server protocol MAY be used to distribute the secret to all
    the servers. If redundant servers do not share secrets then a
    client MUST authenticate itself to each server.  If a security
    association outlives its lease time, it MUST be renewed or
    deleted.

    In this protocol, there is no need for shared secrets to leave
    an administrative domain. This protocol solves the distribution
    problem of shared secrets and eliminates the need for clients to
    remember shared secrets. The explicit expiration of shared
    secrets greatly simplifies server management of shared secrets.

    The only information that a client needs to know is its own

Expires September 26, 1997                                     [Page  7]
Internet Draft                                            March 26, 1997

    identity, its public/private key pair and the root public key
    for the key distribution mechanism. An added benefit of this
    protocol is that it does not require the DHCP server to store
    the authentication information for clients that may connect to
    it. The public keys used are retrieved from an external source.
    This means that there will be minimal change in how servers are
    run. This protocol does not address the access control issue;
    that is a separate problem.

4.4. What does the authentication protocol accomplish?

    This protocol accomplishes requirements 1 through 4. It carries
    enough information to enable requirement 5. For server and
    client to validate each other public keys they may want to walk
    the DNS tree to the root to create a chain of valid keys. The
    client cannot trust the DNS server supplied by the server but it
    can trust the signed verifiable data that the DNS server
    provides. This requires that the DHCP client be able to do
    DNSSEC verification locally.

    To determine that the Server is not an impostor there may be a
    need to store in DNS the list of authorized DHCP servers and
    agents in a zone.

    The "root keys" that client stores, can be the keys for "." or
    for the outermost domain that the client can talk to servers in.

    The main reason for having the server select the secret keying
    material for the security association, has to do with random
    number entropy.  Many computers do not have good sources of
    randomness available at boot time.  A server that has been
    running for a while, on the other hand, has access to better
    sources of randomness.  The protocol when specified should
    include guidelines on how to generate good random keys on
    servers.

5. Protecting ongoing client/server communication

    Rule 5 above states that client (or relay agent) and server must
    agree on a security model for securing all communication. The
    authentication protocol above  accomplishes the required dynamic
    setup for this. Once a security aware Server and security aware
    Client have authenticated each other they have entered a
    security association. This security association will determine
    how all successive communication is protected. Below is a list
    of available mechanisms that accomplish this task.
        A.  None  (Current state of affairs) NOT recommended
        B.  Message digest with shared secret. (Protects the contents
            of the packet).
        C.  Digital signature.  (Provides more assurance at higher
            cost).
        D.  Encrypted communication  (Provides confidentiality).
        E.  IPSEC.


Expires September 26, 1997                                     [Page  8]
Internet Draft                                            March 26, 1997

    The author feels that mechanisms B and D are the only ones
    practical for DHCP. Digital signatures are not worth the
    computational and bandwidth cost for one on one communication.
    IPSEC will become viable at some point in the future and can/
    should be used to protect the communication. The working group
    needs to decide whether to deploy a message protection mechanism
    in the DHCP protocol or wait for IPSEC. This document recommends
    that B be implemented using HMAC[HMAC] technique combined with
    one of the following message digest algorithms MD5, SHA-1 or
    RIPEMD-160.

    Digital signatures provide a stronger authentication mechanism
    than Message digests but are much more expensive to generate.
    Some Digital signatures are inexpensive to verify but not all.
    RSA is inexpensive to verify but DSA is not. Given the expensive
    computation of digital signatures it is hard to justify their
    use once identity has been established.

6. Impact of Agents on security model.

    Given that in many cases clients need Agents to connect them to
    DHCP servers, it is important that agents cannot modify the
    contents of the DHCP request. It is also important that Agents
    authenticate server advertisements. Agents should not be allowed
    to modify client requests in any way, other than that required
    to route the requests. There is no need for the client to enter
    a security association with its Relay Agent.


6.1. Server/Relay agent advertisements.

    This is a special case where one entity is talking to many.  In
    order to protect this form of communication from malicious
    attacks these advertisements MUST be digitally signed using the
    advertisers public key. It is possible to create a group shared
    secret or group encryption key. This is not a good arrangement
    for anything that lasts longer than a short time. Short time can
    be a few minutes to a few hours; longer than that it is not a
    secure arrangement. If one party leaks this key information,
    outsiders can forge traffic.

6.2. Security threats from relay agents.

    Relay agents can potentially conduct "man in the middle" attacks
    on a system that uses them. In the schema above relay agents can
    conduct denial of service attacks.  This is a simple fact of
    life and there is no way to overcome that.

    It is not clear that relay agents can conduct any other kind of
    attacks as they are not able to forge any of the contents of the
    packets.

    In the case where clients do not validate that the server
    contacted is a valid server, relay agents may conduct attacks as

Expires September 26, 1997                                     [Page  9]
Internet Draft                                            March 26, 1997

    fake server. In this attack the relay agent claims to be the
    server to the client and the client to the server.
    Careful design of the protocol should be able to prevent this.

7. Security considerations

    This document is about security.

8. References

    [DHCP]  R. Droms, "Dynamic Host Configuration Protocol", RFC
    1541, Bucknell University, October 1993.

    [DHCAUTH] R. Droms,  "Authentication for DHCP Messages",
    Internet Draft <draft-ietf-dhc-authentication-03.txt> November
    1996

    [DNSSEC] D. Eastlake, C. Kaufman, "Domain Name System Security
    Extensions", RFC 2065, January 1997.

    [HMAC]   H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-
    Hashing for Message Authentication", February 1997

    [IPSEC] R. Atkinson, "Security Architecture for the Internet
    Protocol",  Internet Draft <draft-ietf-ipsec-arch-sec-01.txt>,
    November 1996.

    [RFC1825] R. Atkinson, "Security Architecture for the Internet
    Protocol", RFC 1825, September 1995.

    [Server] R. Droms, R. Cole, "An Inter-server Protocol for DHCP"
    Internet Draft <draft-ietf-dhc-interserver-01.txt> March 1997.

    [SRV] A. Gulbrandsen, P. Vixie, "A DNS RR for specifying the
    location of services (DNS SRV)", RFC 2052, October 1996.

9. Author address

    Olafur Gudmundsson
    Trusted Information System
    3060 Washington Road
    Glenwood, MD 21738
    +1 301 854 5794
    <ogud@tis.com>











Expires September 25, 1997                                     [Page 10]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/