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

Versions: 00

     Internet Draft                                       P. Engelstad
                                                           Telenor R&D
     Expires July 2002                                    January 2002
     
     
             A mechanism for Discovery of PANA Authentication Agents
                                 (PAA-discovery)
     
                   <draft-engelstad-pana-paa-discovery-00.txt>
     
     
     
     Status of this Memo
     
        This document is an Internet-Draft and is in full conformance with
        all provisions of Section 10 of RFC2026.
     
        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."
     
        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.
     
        This document is an individual submission for the PANA Working Group
        of the Internet Engineering Task Force (IETF). Comments should be
        submitted to the mailing list pana@research.telcordia.com.
     
     
     Abstract
     
        A PANA authentication protocol is under development in the PANA
        Working Group. It will allow hosts to authenticate with PANA
        Authentication Agents (PAAs). The protocol is expected to run over
        some IP-based transport protocol, such as ICMP, UDP, TCP or SCTP.
        Before a host can authenticate with a PAA, it must obtain an IP-
        address of the PAA. This document specifies such a "discovery"
        mechanism by defining extensions (or options) to Router
        Advertisements and DHCP messages for both IPv4 and IPv6. Hosts MAY
        also obtain an identity of a PAA and other information during the
        discovery process. The proposed discovery mechanism makes no
        assumptions about the location of a PAA, and more than one PAA may
        be discovered.
     
     
     
     P. Engelstad              Expires July 2002                  [Page 1]


                                  EAP over IP                 January 2002
     
     
     Table of Contents
     
        1 Introduction.....................................................2
        2 Terminology......................................................3
        3 Extensions for PAA Discovery.....................................3
          3.1 ICMPv4 Router Advertisement Extension for PAA Discovery......4
          3.2 DHCPv4 Extension for PAA Discovery...........................4
          3.3 ICMPv6 Router Advertisement Option for PAA Discovery.........5
          3.4 DHCPv6 Option for PAA Discovery..............................5
          3.5 Sub-options for PAA Discovery................................6
              3.5.1 PAA IPv4 Address Sub-option............................6
              3.5.2 PAA IPv6 Address Sub-option............................6
              3.5.3 PAA Identity Sub-option................................7
              3.5.4 PANA Initiation Sub-option.............................8
              3.5.5 Other Sub-option.......................................8
        4 Security Considerations..........................................9
        IANA Considerations................................................9
        Acknowledgements..................................................10
        References........................................................10
        Authors' Addresses................................................11
     
     
     
     1 Introduction
     
        A PANA authentication protocol is under development in the PANA
        Working Group. It will allow hosts to authenticate with PANA
        Authentication Agents (PAAs). The protocol is expected to run over
        some IP-based transport protocol, such as ICMP, UDP, TCP or SCTP.
     
        Before a host can authenticate with a PAA, it must obtain an IP-
        address of the PAA. This document specifies such a "discovery"
        mechanism by defining extensions (or options) to Router
        Advertisements and DHCP messages for both IPv4 and IPv6. These
        extensions (or options) are specified in Section 3 of this document.
     
        In situations where DHCP is not implemented, PAA-discovery relies on
        extensions to IPv4 and IPv6 Router Advertisements. However, such
        extensions MAY consume substantial bandwidth on the access subnet.
        Therefore, it is assumed that PAA-discovery should use DHCP
        extensions instead in situations where DHCP is implemented. (In this
        case the 'M'-bit or 'O' bit will be set in an IPv6 Router
        Advertisement [5], and the Router Advertisement will not contain any
        extensions for PAA-discovery.)
     
        In addition to discovering IP-addresses of PAAs, hosts MAY also
        obtain PAA Identifiers (e.g. in terms of Network Access Identifiers
        [9]) and other relevant information during the discovery process.
        Additional information MAY facilitate the subsequent authentication
        process. However, the benefits of these enhancements to the
        discovery mechanism may be ruled out by the bandwidth penalty that
        extra information imposes on the access subnet.
     
     P. Engelstad              Expires July 2002                  [Page 2]


                                  EAP over IP                 January 2002
     
     
        The proposed discovery mechanism makes no assumption about the
        location of a PAA; it may be located on the Access Router or
        somewhere else in the access domain. Moreover, more than one PAA may
        be discovered. This flexibility assures that the discovery mechanism
        probably will be able to support the final PANA authentication
        protocol, when that specification is completed. Examples of PANA
        protocol proposals can be found in [1], [11] and [12].
     
        A host SHOULD acquire an IP-address for itself, prior to
        authenticating with PAA. A good argument for this requirement is
        that the access network cannot enforce IP-address assignment anyway:
        A malicious host can easily configure any IP-address for itself,
        although it may encounter problems if the access network implements
        IP-address filtering (e.g. on the access router).
     
        The mechanism proposed in this document allows the host to discover
        IP-addresses of PAAs while acquiring an IP-address for itself, using
        either stateless address auto-configuration or DHCP. A PAA discovery
        mechanism for hosts that intend to authenticate without an IP-
        address, is outside the scope of this document.
     
        The host can actively initiate the discovery process by sending an
        ICMP Router Solicitation or a DHCP request. The discovery mechanism
        allows a host to discover IP-addresses of more than one PAA. If the
        host cannot reach one PAA, it may try to get in contact with another
        PAA of which it also has acquired an IP-address.
     
        There are a number of reasons why a host may not be able to get in
        contact with one of the PAAs of which it has acquired an IP-address:
        The PAA or the host could, for example, be subject to a security
        attack or an extension may have carried obsolate information about a
        PAA that is no longer present in the access domain.
     
     
     2 Terminology
     
        In this document, several words are used to signify the requirements
        of the specification. These words are often capitalized. The key
        words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
        this document are to be interpreted as described in RFC 2119 [2].
     
     
     3 Extensions for PAA Discovery
     
        Router Advertisement Extensions and DHCP Extensions (or "Options")
        are defined for both IPv4 and IPv6. Any of these extensions will
        inform a host that acquires an IPv4 or IPv6 address on how to
        initiate authentication with PAA. The extensions are intended to
        simplify PAA discovery, but they are not mandatory.
     
     
     P. Engelstad              Expires July 2002                  [Page 3]


                                  EAP over IP                 January 2002
     
        Each extension conveys information about one particular PAA. If
        information about several PAAs needs to be conveyed to the host, the
        Router Advertisement or DHCP reply message MAY include multiple
        extensions, one for each PAA.
     
     
     3.1 ICMPv4 Router Advertisement Extension for PAA Discovery
     
        The following extension is suggested for use with ICMPv4 [3]:
     
         0                   1                   2
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Type      |    Length     |   Sub-options...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        Type
     
           PANA-RAv4-EXTENSION (TBD)
     
        Length
     
           This value equals the number of octets of this extension,
           excluding the Type and Length fields, i.e. only the length of the
           sub-option field.
     
        Sub-options
     
           Sub-options are specified in section 3.5.
     
     
     3.2 DHCPv4 Extension for PAA Discovery
     
        The following extension is suggested for use with DHCPv4 [4]:
     
        0                   1                   2
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Code      |     Len       |   Sub-options...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        Code
     
           PANA-DHCPv4-EXTENSION (TBD)
     
        Len
     
           This value equals the number of octets of this extension,
           excluding the Code and Len fields, i.e. only the length of the
           sub-option field.
     
        Sub-options
     
     
     P. Engelstad              Expires July 2002                  [Page 4]


                                  EAP over IP                 January 2002
     
           Sub-options are specified in section 3.5.
     
     
     3.3 ICMPv6 Router Advertisement Option for PAA Discovery
     
        The following option is suggested for use with ICMPv6 [5]:
     
         0                   1                   2
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Type      |    Length     |   Sub-options...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        Type
     
           PANA-RAv6-OPTION (TBD)
     
        Length
     
           This value equals the number of octets of this option, excluding
           the Type and Length fields, i.e. only the length of the sub-
           option field.
     
        Sub-options
     
           Sub-options are specified in section 3.5.
     
     
     3.4 DHCPv6 Option for PAA Discovery
     
        The following option is suggested for use with DHCPv6 [6]:
     
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |       option code           |          option-length          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   Sub-Option ...
        +-+-+-+-+-+-+-+
     
        option code
     
           PANA-DHCPv6-OPTION (TBD)
     
        option length
     
           This value equals the number of octets of this option, excluding
           the option code and option-length fields, i.e. only the length of
           the sub-option field.
     
     
        Sub-options
     
     
     P. Engelstad              Expires July 2002                  [Page 5]


                                  EAP over IP                 January 2002
     
           Sub-options are specified in section 3.5.
     
     
     3.5 Sub-options for PAA Discovery
     
     
     3.5.1 PAA IPv4 Address Sub-option
     
        This sub-option provides the host with the IPv4 address of a PAA. It
        is typically appended to a DHCPv4 Extension or an IPv4 Router
        Advertisement Extension for PAA Discovery.
     
         0                   1                   2
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Sub-opt. Type |    Length     | IPv4 Address (4 octets)...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        Sub-Option Type
     
           TBD
     
        Length
     
           4
     
        IPv4 Address
     
           An IPv4 address of the PAA referred to in this extension.
     
     
     3.5.2 PAA IPv6 Address Sub-option
     
        This sub-option provides the host with the IPv6 address of a PAA. It
        is typically appended to a DHCPv6 Option or an IPv6 Router
        Advertisement Option for PAA Discovery.
     
        0                   1                   2
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Sub-opt. Type |    Length     | IPv6 Address (16 octets)...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        Sub-option Type
     
           TBD
     
        Length
     
           16
     
        IPv6 Address
     
     
     P. Engelstad              Expires July 2002                  [Page 6]


                                  EAP over IP                 January 2002
     
           An IPv6 address of the PAA referred to in this extension.
     
           For the time being, there are unsolved problems associated with
           using shared addresses for stateful communication (as described
           in RFC 1546 [7]). Since the PANA protocol will be required to
           accommodate re-authentication, PAA will be a stateful agent.
           Thus, an IPv6 anycast (or multicast) address SHOULD NOT be used
           in this sub-option, before resolution of these problems.
     
        In the future, one may pre-assign to PAA site-scoped IPv6 addresses
        that can be hard-coded into the host. (E.g. the range of five site-
        scoped addresses fec0:0:0:ffff::4 - fec0:0:0:ffff::8 from the
        address space with SLA value of 'ffff' could be assigned to PAAs in
        access domains. It is similar to what is proposed for stateless IPv6
        DNS discovery in [8]). This may facilitate the authentication
        process, reduce the fate sharing, and save the additional bandwidth
        of conveying PAA addresses to the host.
     
     
     3.5.3 PAA Identity Sub-option
     
        This sub-option may facilitate the authentication process by
        allowing a roaming host to discover an identity of a PAA.
     
        Thus, the host can easily determine the (re-) authentication
        procedure due to the type of handover - e.g. if it has:
     
           (1) roamed to a new access domain;
     
           (2) roamed to a subnet of the same access domain, but under a
           different PAA; or
     
           (3) roamed to a subnet under the same PAA.
     
        Furthermore, if the PANA protocol incorporates EAP the host MAY also
        authenticate the PAA directly without sending an initial EAP
        Identity request first.
     
        Note, however, that the additional bandwidth consumption on the
        access link MAY rule out the benefits of this sub-option.
     
        0                   1                   2
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Sub-opt. Type |    Length     | PAA Identity ...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        Sub-option Type
     
           TBD
     
        Length
     
     
     P. Engelstad              Expires July 2002                  [Page 7]


                                  EAP over IP                 January 2002
     
           Length of the PAA Identity field.
     
        PAA Identity
     
           The identity of the PAA. This identity SHOULD be represented in
           terms of a Network Access Identifier (NAI), as specified in [9].
     
     
     3.5.4 PANA Initiation Sub-option
     
        This sub-option informs the host on how to proceed with the PANA
        authentication process, after the PAA discovery process.
     
        It is likely that the roaming host is the one that should take the
        initial step in the PANA protocol after having completed PAA-
        discovery. If this is the case, the PANA Initiation Code in this
        sub-option gives the host directions on how to go on.
     
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Sub-opt. Type |    Length     |     PANA Initiation Code      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        Sub-option Type
     
           TBD
     
        Length
     
           2
     
        PANA Initiation Code
     
           A code which informs hosts on how to proceed with the PANA
           protocol, after having discovered a PAA.
     
        It is likely that the PANA protocol be carried by messages with EAP
        format, and that the host will initiate the communication using a
        specific Request/Response Type. The PANA Initiation Code values in
        the range of 0 - 255 may therefore be reserved for EAP
        Request/Response Types.
     
     
     3.5.5 Other Sub-option
     
        Other sub-options may be specified in follow-on documents.
     
        The final PANA protocol MAY for example find it useful to define a
        sub-option that allows hosts to obtain temporary MD-5 challenges
        from the access network during the discovery process.
     
     
     
     P. Engelstad              Expires July 2002                  [Page 8]


                                  EAP over IP                 January 2002
     
     4 Security Considerations
     
        A malicious node MAY send to a host a Router Advertisement
        containing a valid PAA-discovery sub-option, although other
        information in the advertisement MAY be spoofed. Thus, a malicious
        node can easily become an intruder-in-the-middle that gets access to
        the domain by using the host as an oracle when authenticating with
        PAA. This is particularly easy when access control is based only on
        address filtering of userÆs data traffic without employing security
        gateways in the access domain.
     
        To allow for packet filtering as a means to enforce access control,
        the PANA protocol MUST let a PAA confirm to hosts that information
        related to the access domain (including Access Router addresses) are
        correct. Furthermore, the PANA protocol MUST let a host confirm to
        PAAs that the hostÆs IP-addresses and other information related to
        the host (e.g. L2-addresses, port numbers etc.) are correct.
     
        Although an Authentication Sub-Option MAY be able to address this
        issue during the PAA-discovery phase of the PANA protocol, it is
        assumed that it will be better addressed by other parts of the PANA
        protocol:
     
           a) Hosts and PAAs MAY validate each otherÆs network access
           information during the session key establishment phase of the
           PANA protocol. (Then, the session key MUST be re-established
           every time a host changes address or roams to a new access
           router.)
     
           b) Alternatively, the PANA protocol MAY allow an authenticator to
           validate network access information of peers during the (re-)
           authentication phase of the PANA protocol. (In this case, the
           session key establishment phase MUST be followed up by (re-)
           authentication.)
     
           c) Both a) and b)
     
        There are other unresolved security issues related to Neighbor
        Discovery. An overview is provided in [10]. Since such threats are
        not only specific to the PANA protocol, they are outside the scope
        of the PANA Working Group. They are also outside the scope of this
        document.
     
     
     IANA Considerations
     
        An ICMPv4 Router Advertisement Extension Type value need be assigned
        for PAA Discovery. (Please refer to the PANA-RAv4-EXTENSION value in
        sub-section 3.1.)
     
        A DHCPv4 Extension Code value need be assigned for PAA Discovery.
        (Please refer to the PANA-DHCPv4-EXTENSION value in sub-section
        3.2.)
     
     P. Engelstad              Expires July 2002                  [Page 9]


                                  EAP over IP                 January 2002
     
     
        AN ICMPv6 Router Advertisement Option Type value need be assigned
        for PAA Discovery. (Please refer to the PANA-ICMPv6-EXTENSION value
        in sub-section 3.3.)
     
        A DHCPv6 Option Code value need be assigned for PAA Discovery.
        (Please refer to the PANA-DHCPv6-OPTION value in sub-section 3.4.)
     
        Sub-option type values need be assigned to sub-options presented in
        sub-section 3.5.
     
     
     Acknowledgements
     
        ...
     
     
     References
     
        [1]  Tsirtis, G., "EAP over ICMP", <draft-tsirtsis-eap-over-icmp-
        00.txt>, Work in progress, January 2002.
     
        [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, March 1997.
     
        [3]  Deering, S. "ICMP Router Discovery Messages", RFC 1256,
        September 1991.
     
        [4]  Droms, R. "Dynamic Host Configuration Protocol", RFC 2131,
        March 1997.
     
        [5]  Narten, T., Nordmark, E., Simpson, W. "Neighbor Discovery for
        IP Version 6", RFC 2461, December 1998.
     
        [6]  Droms, R. (ed.), "Dynamic Host Configuration Protocol for IPv6
        (DHCPv6)", Work in progress, November 2001.
     
        [7]  Partridge, C., Mendez, T. and Milliken, W., "Host Anycasting
        Service", RFC 1546, November 1993.
     
        [8]  Thaler, D., Hagino, J.I., "IPv6 Stateless DNS Discovery", Work
        in progress, November 2001.
     
        [9]  Aboba, B., Beadles, M. "The Network Access Identifier", RFC
        2486, January 1999.
     
        [10]  Kempf, J., Nordmark, E. "Threat Analysis for IPv6 Public
        Multi-Access Links", <draft-kempf-ipng-netaccess-threats-00.txt>,
        Work in progress.
     
        [11]  Engelstad, P. "Extensible Authentication Protocol over IP
        (EAPoIP)", <draft-engelstad-pana-eap-over-ip-01.txt>, Work in
        progress.
     
     P. Engelstad              Expires July 2002                 [Page 10]


                                  EAP over IP                 January 2002
     
     
        [12]  Yegin et al., "Secure Network Access Using Router Discovery
        and AAA", <draft-yegin-unap-snard-00.txt>, Work in progress.
     
     
     Authors' Addresses
     
        Paal E. Engelstad
        Telenor R&D (California)
        399 Sherman Ave. Suite #12
        Palo Alto, CA 94306, USA
     
        Tel.: + 1-650- 714 7537
        e-mail: paal@telenorisv.com
     
     
     P. Engelstad              Expires July 2002                 [Page 11]
     

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