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

Versions: 00 draft-ietf-pana-framework

Internet Engineering Task Force                                     PANA
Internet Draft                                             H. Tschofenig
                                            Siemens Corporate Technology
draft-tschofenig-pana-framework-00.txt
9 January 2003
Expires: July 2003


                         PANA Framework Issues

STATUS OF THIS MEMO

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

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

To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.

Abstract

This document discusses framework assumptions relevant to activities in
the PANA working group. It is tentative in nature and raises issues
regarding some assumptions made in the group. The aim of this draft is
therefore not to propose solutions instead issues are highlighted which
might require further consideration.



1 Introduction

This document discusses framework assumptions relevant to activities in
the PANA working group. It is tentative in nature and raises issues
regarding some assumptions made in the group. The aim of this draft is
therefore not to propose solutions instead issues are highlighted which
might require further consideration.




H. Tschofenig                                                 [Page 1]


Internet Draft                                            9 January 2003


The document is organized as follows:

In Section 2 two basic scenarios are described which are differentiated
by their authorization procedure - which in this case is about charging.
The two scenarios are subscription-based access and alternative means of
access. Section 3 then considers a few possible results of a PANA
protocol execution. A few examples are listed with increasing order of
complexity. In Section 4 a few interesting requirements (in the view of
the author) are listed which might influence the outcome of a PANA
protocol. The author is aware of the fact that there should be a
separation between requirements, analysis and an actual protocol
development. However, requirements are not always (or not often)
orthogonal and a focus on some requirements (justified or not) might
heavily influence the shape of a later protocol design. Section 5
describes some building blocks which might be useful in a future
protocol. Some of the building blocks have already (individually) been
used in some protocol proposals. The building blocks are roughly aligned
in their order of execution - some of them can be omitted without
severely effecting the protocol (optional components). In Section 6 a
few thoughts on the relationship to mobility protocols (in particular
Mobile IP) are presented. Finally in Section 7 some conclusions derived
from the previous explanations are given.

2 Basic Scenarios

This section describes two scenarios for network access. The first
scenario is traditionally based on a relationship between the user and
his home network. The subscribed user uses his credentials in a AAA
scenario to dynamically establish a trust relationship between the home
network and the visited network.

Note that the term 'user' can also be replaced by some other entity for
which the authentication is performed (e.g. a device). The difference
between the two is (at the process of authentication and key exchange
itself) often marginal since it depends only on the used identifier
(e.g. NAI, Kerberos principal name, etc.). The usage of such an
identifier after authentication for authorization is often different.
Since an identity referring to a user provides some advantages compared
to a device, such as additional security, this term is used. The author
is, however, aware of the fact that some network access procedures used
today are based on device authentication.

2.1 Subscription-based access

Authentication of the user is typically provided to the home network
where the user is subscribed and credentials are available. It is
typically based on symmetric cryptography. The security relationships
are one-to-many, and asymmetric cryptography does not necessarily



H. Tschofenig                                                 [Page 2]


Internet Draft                                            9 January 2003


provide advantages in key management in such a situation (although it
may provide other advantages, of course). In a mobile environment, the
performance advantages of symmetric cryptography are also important. The
message flow may involve many different visited networks, but an
established business relationship (e.g. roaming agreements) between the
visited and the home network may be assumed, hence accounting and
charging are feasible.

Without roaming the visited network and the home network coincide and
the end host is attached to the home network. This procedure simplifies
avoiding inter-realm communication. Some ISP scenarios are based on this
simplification.

2.2 Alternative means of access

In this scenario the user has no home network and therefore cannot
assume such for the purpose of authentication and authorization. Hence
authentication, authorization and payment is provided by other means
such as pre-paid cards, credit cards and other mechanisms (micro- and
macro-payment methods). Which protocol is required for the alternative
means of access case depends on the chosen payment protocol. These types
of environments are typically found in hot spots.

Additional information about a detailed problem description and protocol
exchanges at an abstract level is provided at [1].

In the first scenario the visited network is given the assurance that
the indicated user is registered to a given home network and that the
home network provides a guarantee that the generated cost are covered.
In the second scenario the payment mechanism has to provide the
assurance that the end host is able to pay for the consumed resources.
Note that this does not necessarily require user authentication. But it
will typically require the transmission of payment-related confidential
data prior to completed authorization. This may imply that the
establishment of a security association is necessary to protect the
sending of this data before the user credential can be verified. This in
turn may necessitate the use of asymmetric cryptography to establish a
unilaterally authenticated tunnel.

3 Possible objectives of executing a PANA protocol

The execution of a PANA protocol is done for a particular purpose. We
try to list a few possible goals:

3.1 Transport of EAP messages

EAP is a container for a number of authentication and key exchange
protocol messages. In the past different transport mechanisms have been



H. Tschofenig                                                 [Page 3]


Internet Draft                                            9 January 2003


proposed to exchange the EAP payloads between the end host and the AAA
attendant. For several link layers (e.g. IEEE 802) a transport mechanism
for EAP payloads has been standardized. But no such link layer
independent transport mechanism for EAP payloads is available although
it would clearly be very desirable. As a minimum, this would enable EAP-
based entity authentication independent of the link layer. Since the
selection of a transport mechanism seems to be an almost religious issue
it seems to be hard to agree on a particular mechanism. Especially the
different usage scenarios (wired, wireless, mobility, etc.) add
constraints. Nevertheless, it is seen as necessary that PANA comes up
with at least link layer independent transport mechanism for EAP
payloads.

3.2 Installation of filter rules

Installations of filter rules provides packet filtering behavior in
addition to entity authentication. The controlled/uncontrolled packet
forwarding, which was already described in the expired draft [2],
provides this functionality. Depending on the location of the EP(s) and
the PAA a protocol might be required to communicate the filter rules
from the PAA to the EP(s). A number of protocols have been investigated
in the Midcom working group for exactly this purpose. Since these
protocols are outside the scope of PANA only their relationship to the
Midcom working group is of interest; namely how to provide the
information which filter rules to install at which device.

The Midcom protocols would enable the use of temporary filter rules. The
purpose of installing such temporary filter rules is to prevent a threat
where an end host looses connectivity (for various reasons such as
mobility) and an adversary is able to reuse the installed filter rules
to transmit data traffic. Additionally a threat exists whereby an
adversary uses IP spoofing to inject packets on behalf of someone else.
The soft-state principle (i.e. installing filter rules which
automatically time out after some time) is important to prevent stale
state and possibly denial of service attacks. A more detailed threat
description can be found in [3] and with a slightly different focus in
[4]. Some of the threats described in the latter document are also
applicable in this context.

The requirement for disconnect indication aims to address these threats.
Various mechanisms are possible such as limiting the lifetime of the
filter rules (and possibly requiring continuous refreshes to keep them
in place), requiring continuous re-authentication and at the other
extreme requiring each packet to be protected. A small comment about the
relationship to existing work in the Midcom wg is given in Section A.

3.3 Session key distribution




H. Tschofenig                                                 [Page 4]


Internet Draft                                            9 January 2003


Most EAP methods also provide the ability to establish a session key.
Session key derivation in EAP is still under discussion but it is worth
mentioning that the corresponding draft for carrying session keys via
the AAA infrastructure already exist. Protection for session keys
delivered in Diameter are provided by CMS [5]. The goal of session key
distribution is to provide the end host and the AAA attendant with a
unique and fresh session key after a successful AAA exchange (and in
this context based on a successful EAP authentication). The session key
for the AAA attendant is therefore most likely provided by the AAA
infrastructure whereas the end host obtains the session as a result of
the EAP authentication and key exchange procedure. As an alternative to
this procedure it is possible to establish a session key before client
authentication takes place. This approach is chosen by PANA over TLS [6]
and by the Secure Network Access Authentication proposal [7]. Care has
to be taken in these scenarios, however, to avoid man-in-the-middle
attacks.

Recent activities try to create a common framework for key derivation
which is described in [8] and might also be applicable for this context.
The key derivation and key transport procedure defined for EAP aims to
provide session keys for link layer devices (see Section 1 of [8] with
[9] and [10] as an example) but might also serve the purpose of creating
the pre-requisites for network layer protection (for example IPsec). One
building block, which is missing in this context, is a (generic)
mechanism for negotiation of algorithms and parameters, e.g. IPsec
security association parameters.

Given this functionality, which cannot be used by all EAP methods, the
question remains for what purpose these keys should be used (key
derivation) and where these keys have to be delivered (i.e. key
transport). Additionally the corresponding security association has to
be created which might either require third-party or two-party algorithm
and parameter negotiation. The difference between them has influence on
the performance similar to in-band vs. out-of-band protocols discussed
in other areas.

Additionally it should be mentioned that local re-authentication can be
provided when a session key is distributed and known to the local AAA
server. This local re-authentication might even use a different
authentication mechanism. In some scenarios such a procedure might
provide some performance advantages. Draft [11] describes some issues in
this context.

3.4 Providing secure network access

To grant access only for authenticated hosts/users can also be
accomplished by per-packet authentication. This prevents threats caused
by IP spoofing or threats which are caused due to mobility and a missing



H. Tschofenig                                                 [Page 5]


Internet Draft                                            9 January 2003


disconnect indication. Such a per-packet authentication behavior
(including integrity protection) might also be of interest in a QoS
based environment with different QoS treated flows. The ability of
EAP/AAA to distribute session keys to establish an IPsec security
association between the end host and the first IP hop comes is an
example for this. In comparison to installed filter rules per-packet
authentication provides a more secure ability to associate each
individual IP packet with an authenticated user or host (which is
especially interesting for accounting but also of interest for
preventing unauthorized traffic to enter the network).

Another good reason for establishing such a security association is to
provide security for the first hop independently of the underlying link
layer technologies against various attacks on the wireless link.
Although there are good reasons for additionally providing link-layer
protection (at least for link layer signaling messages) there are many
reasons for providing the protection (possibly in addition) at the
network layer. The different arguments have already been extensively
discussed in various communities and will not be repeated in this
document.

A number of dead peer detection mechanisms have been proposed for
detecting 'disconnected' hosts which might be of interest for
performance reasons. The interested reader might want to take a look at
[12] as one promising proposal. There are, however, a number of other
proposals.

It is worth mentioning that an IPsec security association might be
useful for a number of other reasons such as micro-mobility, QoS
signaling, context transfer and other protocols.

3.5 Providing secure address configuration

There was often the discussion with what pre-requisites a PANA protocol
should start. Currently it is assumed that PANA is invoked after IP
address assignment (see [13]). There are, however, some threats which
address unprotected configuration messages in both stateful and
stateless address autoconfiguration. It is worth to mention that this
issue is still in discussion.

In addition to the discussion of how to protect the address
configuration procedure it might be necessary to consider how to obtain
some other configuration information like DNS servers etc. Since the
relationship to work done in the IPsec remote access working group is
apparent it might also be of interest to investigate secure address
bootstrapping mechanisms in this area. For securing address
configuration procedures [14] and [15] have been proposed.




H. Tschofenig                                                 [Page 6]


Internet Draft                                            9 January 2003


It has to be clarified whether secure address configuration is
considered by the working group.

4 Discussion of PANA assumptions

This section aims to review some of the assumptions which appeared in
the PANA environment, and their implications. It is important to note
that certain assumption (e.g. the necessity of user identity
confidentiality) has far-reaching implications on the mechanisms
available to satisfy these assumptions.

     User identity confidentiality:

          Recently there has been an increased interest to keep the
          identity used during the authentication process confidential.
          It is important to make this requirement more precise. The
          distinction between protection of the user identity against
          passive attacks, i.e. eavesdropping, and active attacks, i.e.
          modification or insertion of data, is crucial. For short, we
          call the two different requirements active or passive user
          identity confidentiality. Passive user identity
          confidentiality can be provided by both, symmetric and
          asymmetric cryptographic methods, whereas active user identity
          confidentiality typically requires the use of asymmetric
          cryptographic methods. Furthermore, it must be decided for
          which peer (initiator or responder) active or passive user
          identity confidentiality is required. Providing active user
          identity protection for the initiator and the responder is not
          possible (see e.g. the discussion around IKEv2.

          Because of the involved entities in an EAP/AAA message
          exchange it furthermore has to be investigated against which
          entities this protection has to be provided (outsiders or
          network nodes) and whether one should mandate identity
          protection for a protocol in all environments. It should be
          considered that pseudonyms or temporal identities, which are
          also used to provide user identity confidentiality, might
          require a different protection. Additionally there are
          scenarios (for example described in [16] and in [3]) where the
          connection between the end host and the access network is a
          point-to-point link which makes eavesdropping quite difficult.
          It should also be noted that elaborate user identity
          protection schemes at higher layers are quite useless when the
          user identity can be inferred from lower layer identities,
          e.g. IP addresses or MAC addresses (like in IEEE 802.11). We
          conclude that the cost of implementing a particular form of
          user identity protection in the intended environment should be
          carefully considered.



H. Tschofenig                                                 [Page 7]


Internet Draft                                            9 January 2003


          Ideally as a user it might be desirable to provide some form
          of identity protection which only allows the home network to
          learn the identity during authentication. In case of
          alternative means of access described in Section 2 a pre-paid
          service might not require user identity confidentiality since
          the identity is temporary.

     Tunneling Approach:

          Support for legacy authentication mechanisms is often
          mentioned as a justification for proposing TLS-based tunneling
          approaches (in addition to user identity confidentiality).
          Apart from the question what to call a legacy authentication
          protocol it should be considered whether replacing the legacy
          mechanisms which may not satisfy all desired security
          requirements with a better mechanisms is preferable, given the
          time horizon of the PANA working group.

          Although this property is not a requirement it has some
          implications for a PANA protocol. The following issues might
          be of interest:

          - At which entity should the tunnel be terminated?

          - How should the end host decide where to terminate the
            tunnel?

          - Which protocol should be used to provide the tunnel?

          - What are the performance implications caused by the tunnel?

          - Why is it necessary to provide protection for all EAP
            methods although only a few would benefit from the
            established tunnel?

          - Is the chosen tunnel approach secure against man-in-the-
            middle attacks (see also below)?

          On the other hand some protection of information exchanged
          between the PaC and the PAA might be desirable such as EAP
          messages other than those carrying authentication and key
          exchange protocol payloads and content outside these EAP
          messages (e.g. device identifier or filter rules, Mobile IP
          related information, etc.).

          If the tunnel is terminated in the access network then in a
          global roaming case a public key infrastructure is introduced
          since the end host must be able to authenticate the access



H. Tschofenig                                                 [Page 8]


Internet Draft                                            9 January 2003


          network based on the certificate received during the access
          network to end host authentication. Additionally the end host
          must be able to authorize the certificate of the access
          network as one of a 'valid' access network provider. If the
          certificate validation is not possible then an adversary could
          impersonate an access network to act as a man-in-the-middle
          adversary. As an alternative to a tunnel approach, one could
          use mutual public key-based authentication executed between
          the end host and the attached access network (e.g. TLS with
          mutual authentication), but this would require the
          distribution of certificates to clients, which would be much
          more costly than simply having certificates for servers.

     Disconnect indication:

          Disconnect indication allows the to detect whenever an end
          host has lost connectivity. As discussed in Section 3 the
          properties of the useful mechanisms might show considerable
          differences. Hence it might be interesting to determine
          whether this property is really required and whether a
          timer/lifetime negotiation is required. Periodic re-
          authentication, dead peer detection mechanisms, secure
          heartbeat (i.e. a challenge/response) protocol and others
          might require a negotiation of timers/lifetime is required to
          avoid an inappropriate large number (or low number) of
          protocol exchanges.

5 Building Blocks

This section tries to list some of the possible building blocks which
might be required for a more advanced protocol. Which of these are
relevant for PANA is subject for further study. The individual parts
have been discussed at various sections.

     Discovery of the PAA: In order to exchange the EAP payloads between
          the PaC and the PAA it is necessary to discover the entity by
          some mechanism. Using the first IP hop (default router) as the
          PAA might simplify this discovery procedure.

     Negotiation of authentication mechanisms: EAP supports a number of
          different EAP methods and therefore it might be required to
          agree on a specific mechanism. An unprotected negotiation
          mechanism is supported in EAP. A secure negotiation procedure
          for the GSS-API methods, which is also supported in EAP, is
          described in [17].

     EAP message transport: Finally EAP messages have to be exchanged
          between the various nodes using an agreed transport mechanism.



H. Tschofenig                                                 [Page 9]


Internet Draft                                            9 January 2003


          Several mechanisms have been proposed but further
          investigation for the suitability might be required. Some
          issues to consider are at least reliable message delivery with
          fragmentation support. Fragmentation might for example be
          required for some public key based authentication mechanisms.
          In Section 4.5 of [13] congestion control is also mentioned as
          a feature which must be supported.

     Session key distribution and transport: As described in Section 3
          it might be desirable to distribute a session key for
          subsequent link layer or network layer protection. Session key
          distribution within the Diameter protocol is already described
          in [18]. Please note that Jesse Walker et. al. have recently
          raised some concerns regarding the current description of the
          key distribution in [19]. Various drafts mention the
          possibility to provide key distribution to link layer devices.

     Session key derivation:

          EAP methods sometimes provide their own key derivation
          procedure whereas others provide no key derivation at all.
          Since the key derivation procedure heavily depends on the
          protocol for which the session keys are used. Since the key
          derivation procedure heavily depends on the protocol for which
          the session keys are used it is beneficial to have a generic
          session key derivation. Such a framework and many issues
          associated with it are explained in [8]. If session key
          derivation is only relevant for EAP methods then no further
          actions need to be taken. If PANA defines additional
          mechanisms or specific session key transport mechanisms then
          further thoughts are required. In case of the tunneling
          approach the man-in-the-middle attack problems discovered by
          V. Niemi, K. Nyberg and N. Asokan, which are described in
          [20], might require that the session keys of the two phases
          are cryptographically combined as a possible solution to the
          problem. Note, however, that EAP methods that do not
          distribute a session key, which is particularly true for some
          legacy authentication mechanisms, cannot be fixed by this
          mechanism. From the problem description we can conclude that
          the tunneling approaches introduced insecurity even for
          previously secure authentication protocols (when used in this
          environment). In Appendix B a small discussion of the
          implications of the tunneling approaches is given. In a
          recently published IETF draft [21] J. Puthenkulam et. al. also
          describe the man-iin-the-middle attack in detail.

          A few members in the CFGR working group are currently
          investigating approaches for creating a unified session key



H. Tschofenig                                                [Page 10]


Internet Draft                                            9 January 2003


          derivation framework. A previously published proposal by
          Blumenthal [22] serves as one interesting input document.

     SA establishment/negotiation: Distributing a session key is
          unfortunately not sufficient for providing link layer or
          network layer protection. Instead a security association is
          required with information about algorithms and corresponding
          parameters. These parameters need to be negotiated.

     Filter rule installation: To allow network access after a
          successful authentication and authorization step filter rules
          might either be installed locally (via an API call, CLI, etc.)
          or first need to be send to the corresponding device(s).

6 Mobility Implications

Mobility places some constraints on signaling protocols executed
(roundtrips, latency, etc.) and on how to combine different protocols
(in-band signaling) to be even more efficient. Mobile IP ([23] and [24])
is an example of such a protocol where signaling messages are
transmitted immediately after roaming. Hence it was logical step to
combine the network access procedures using AAA (which are also executed
immediately after roaming) with mobility signaling. [25] explains such a
procedure for Mobile IP (IPv4) and [26]/[27] envision a similar approach
for IPv6.

Although these proposals use a custom security mechanisms for
authentication, key exchange and for protection of protecting of the
mobility payloads [27] mentions the use of EAP. Replacing the custom
security mechanism with EAP would allow different authentication and key
exchange protocols to be used. Since the payloads used by Mobile IP,
which are ideally carried with the same messages (i.e. in-band), must be
protected, the following issues require further thoughts:

     · How are Mobile IP payloads protected? Using the custom security
       protection defined in ([2] or [27]) the MIP payloads are simply
       included by the keyed message digest calculation among other
       fields. If EAP is used instead of this custom security mechanism,
       which key is used for the protection of the payloads?

     · Is the above scheme of payload protecting extensible to all EAP
       methods? For the author it seems that this is not fully the case
       if we consider secure password based protocols. These protocols
       require that the message payloads where the password is
       cryptographically applied is not vulnerable to dictionary
       attacks. This is mainly achieved by either encrypting the
       password with a random component or vice versa. If known
       plaintext (e.g. Mobile IP parameter) is encrypted with the



H. Tschofenig                                                [Page 11]


Internet Draft                                            9 January 2003


       password then this property is destroyed.

     · Which other payloads (apart from Mobile IP) would benefit from
       in-band signaling in AAA (and also require protection)?

It is therefore up to the working group to decide whether PANA should be
designed in such an extensible way to include these (and possibly other)
parameters. Mobility (especially seamless mobility) clearly places some
performance restrictions to a PANA protocol. Hence it might not be able
to run an 'arbitrary' number of roundtrip between the end host and a
possibly far distant home network before transmitting mobility related
signaling messages.

7 Conclusion

This draft aims to show the relationship to other protocols which are
relevant for PANA. It therefore tries to address the question what the
result of a PANA protocol exchange should be. In the past there has been
some confusion about the working direction of the group. In Section 3
possible outcomes of a PANA protocol execution are presented with
various degrees of complexity. Depending on the focus of the group the
working group may try to achieve (the given list might ):

     · Pure EAP message transport

     · EAP message transport with installation of filter rules

     · Full secure network access protocol

The working group seems to focus on EAP as a container for
authentication and key exchange protocols. Hence similar protocols such
as SASL are not considered in this document.

It is possible that a single protocol (without optional components)
might not completely fit in all environments.

8 Security Considerations

This document addresses a number of security issues but no protocol is
proposed. Hence as such no separate security considerations are
presented.

9 Acknowledgements

I would like to thank (in alphabetical order) Wolfgang Buecker, Jorge
Cuellar, Guenther Horn, Dirk Kroeselberg, Yoshihiro Ohba and Basavaraj
Patil for their comments to this document. Additionally I would like to
thank all members of the EU funded project Shaman for their fruitful



H. Tschofenig                                                [Page 12]


Internet Draft                                            9 January 2003


discussions. I would like to particularly thank the following WP1 Shaman
members: Krister Boman, Fredrik Lindholm, Valtteri Niemi, Kaisa Nyberg,
Chris Mitchell, Scarlet Schwiderski-Grosche, Heiko Knospe, Tobias
Martin, Joachim Schaaf, Peter Windirsch and Peter Howard.

Finally, I would like to thank Alper Yegin for encouraging me to write
this document and for his comments.

A Relationship to filter rule installation

The goal of establishing filter rules at some devices seems to be
similar to the activities in the Midcom working group. Hence it might be
of interest to look at some of the proposals and additionally at drafts
published in this context such as TIST [28], which is based on RSVP, or
a more recent approach CASP-Midcom [29], which reuses the same ideas
based on the CASP protocol [30]. These two proposals allow an end host
to communicate filter rules to devices (more or less) along the data
path. A mechanism for discovering these devices is also provided by
these proposals. There are, however, differences between the work done
in the Midcom and the NSIS group and the considerations made for PANA.
First, filter rules are installed for particular message flows only
(typically described by a 5-tuple) and not to grant entire network
access. Additionally at least [28] has no means to transport EAP
messages and in [29] only the basic idea is mentioned without
elaborating the details.  Second, for these two protocols there must be
a mechanism to restrict the filter rule installation only at the edge
devices or within the local network only. Without such a mechanism the
messages travel towards the given destination address. Ideas for such a
scoped/localized signaling message exchange are already considered but
not fully investigated. Additionally it must be mentioned that the
signaling procedure in these two protocols is heavily based on the
assumption of topology insensitivity. This also causes filter rules to
be uni-directional.

B Tunneling Implications

In Section 5 the man-in-the-middle attack is described in context of the
session key derivation and tunneling approaches. As a solution of the
problem the documents [20] and [21] suggest to cryptographically bind
the session keys of the two phases, the TLS session key and the session
key deriving from the EAP method, to each other.  Afterwards the
knowledge of this derived session key has to be proven either implicitly
or explicitly. In case of an implicit binding the combined session key
is used to protect the communication between the two end points. This
approach obviously requires that the derived session key is used
afterwards for data protection. In order to provide the knowledge of a
combined session key for an explicit binding an additional message
exchange is required. In Section 4 of [20] an example of such a



H. Tschofenig                                                [Page 13]


Internet Draft                                            9 January 2003


cryptographic explicit binding is described which is based on a keyed
message digest. Since these tunneling approaches have been introduced to
protect legacy authentication mechanisms, which in some cases do not
derive a session key as part of the authentication process, the question
remains how such a cryptographic binding can be established in these
cases. In [20] a 'binding agent' is introduced which combines the
session of the tunnel (for example the TLS established session key) and
the long-term secret used for the EAP method in case that no session key
is created.

Existing tunneling proposals use two different types of tunnels:

     Tunnel endpoint identical with EAP end point: With this tunnel the
          EAP endpoint and the tunnel endpoint are co-located. This type
          of tunnel is used with EAP-TTLS [31], PEAP [32] and in PIC
          [33]. If the client authentication mechanism does not create a
          session key then the long-term secret between the user and the
          authentication server (e.g. AAAH) can be used by the binding
          agent to derive a new session key. To securely deliver the
          user's long-term secret to the binding agent might not be a
          serious problem since the endpoints are likely to be in the
          same administrative domain.

     Tunnel endpoint not identical with EAP end point: With this tunnel
          the EAP endpoint is not the same as the tunnel end point of
          the tunnel. This type of tunnel is used by the PANA over TLS
          proposal [6] and by the Secure Network Access Authentication
          proposal [7]. In these proposals the tunnel end point is
          established between the PaC and the PAA to protect the EAP
          message exchange between these two nodes. The EAP messages
          exchanged by the protected tunnel are then possibly forwarded
          to a backend server (e.g. to a AAAH server) using a AAA
          infrastructure. If a mobile node roams to a new network then
          the tunnel (i.e. TLS tunnel) is terminated at the PAA and the
          EAP messages travel all the way back to the home AAA server.
          In order to use the same procedure as above the binding agent
          needs to have both keys (the session key established with the
          TLS tunnel and the user's long term secret). It would be
          problematic to transfer the user's long-term secret to the
          visited network where the TLS tunnel terminates. Hence one
          possibility is to transfer the TLS established session key to
          the end point of the EAP method. After the binding agent at
          the AAAH server derives the combined session key it is
          transferred back to the tunnel end point in the visited
          network (i.e. to the PAA) since it might be used to secure the
          data traffic between the PaC and some node in the visited
          network.




H. Tschofenig                                                [Page 14]


Internet Draft                                            9 January 2003


C Authors' Address

Hannes Tschofenig
Siemens Corporate Technology
Otto-Hahn-Ring 6
81739 Munich
Germany
EMail: Hannes.Tschofenig@siemens.com


D Bibliography

[1] H. Knospe and S. Schwiderski-Grosche, "Online payment for access to
heterogeneous mobile networks," in IST Mobile and Wireless
Telecommunications Summit 2002 , 2002.

[2] P. Flykt, C. Perkins, and T. Eklund, "AAA for IPv6 network access,"
Internet Draft, Internet Engineering Task Force, Mar. 2002.  Work in
progress.

[3] M. Parthasarathy, "Pana threat analysis and security requirements,"
internet draft, Internet Engineering Task Force, 2002.  Work in
progress.

[4] H. Tschofenig, "Nsis threats," internet draft, Internet Engineering
Task Force, 2002.  Work in progress.

[5] P. Calhoun, S. Farrell, and W. Bulley, "Diameter CMS security
application," Internet Draft, Internet Engineering Task Force, Mar.
2002.  Work in progress.

[6] Y. Ohba, S. Baba, and S. Das, "Pana over tls," Internet Draft,
Internet Engineering Task Force, 2002.  Work in progress.

[7] D. Forsberg and J. Rajahalme, "Secure network access authentication
(senaa)," Internet Draft, Internet Engineering Task Force, 2002.  Work
in progress.

[8] B. Aboba, "The EAP session key problem," Internet Draft, Internet
Engineering Task Force, Feb. 2002.  Work in progress.

[9] I. D. 802.11i/D2, "Draft supplement to standard for
telecommunications and information exchange between systems - lan/man
specific requirements - part 11: Wireless medium access control (mac)
and physical layer (phy) specifications: Specification for enhanced
security," tech. rep., 2001.





H. Tschofenig                                                [Page 15]


Internet Draft                                            9 January 2003


[10] I. S. 802.11-1997, "Information technology - telecommunications and
information exchange between systems - local and metropolitan area
networks - specific requirements part 11: Wireless lan medium access
control (mac) and physical layer (phy) specifications," tech. rep.,
1997.

[11] S. Faccin and F. Le, "AAA local security association (LSA): The
temporary shared key (TSK)," Internet Draft, Internet Engineering Task
Force, July 2001.  Work in progress.

[12] G. Huang, S. Beaulieu, and D. Rochefort, "A traffic-based method of
detecting dead ike peers," internet draft, Internet Engineering Task
Force, 2002.  Work in progress.

[13] A. Yegin, R. Penno, et al.  , "Protocol for carrying authentication
for network access (PANA)requirements and terminology," Internet Draft,
Internet Engineering Task Force, July 2002.  Work in progress.

[14] B. Patel, B. Aboba, S. Kelly, and V. Gupta, "DHCPv4 configuration
of IPSEC tunnel mode," Internet Draft, Internet Engineering Task Force,
May 2001.  Work in progress.

[15] D. Dukes and R. Pereira, "The ISAKMP configuration method,"
Internet Draft, Internet Engineering Task Force, Oct. 2001.  Work in
progress.

[16] Y. Ohba et al.  , "Problem space and usage scenarios for PANA,"
Internet Draft, Internet Engineering Task Force, June 2002.  Work in
progress.

[17] E. Baize and D. Pinkas, "The simple and protected GSS-API
negotiation mechanism," RFC 2478, Internet Engineering Task Force, Dec.
1998.

[18] E. Gustafsson, W. Bulley, A. Rubens, J. Haag, G. Zorn, and D.
Spence, "Diameter NASREQ application," Internet Draft, Internet
Engineering Task Force, Mar. 2002.  Work in progress.

[19] J. Walker, R. Housley, and N. Cam-Winget, "AAA key distribution,"
Internet Draft, Internet Engineering Task Force, Apr. 2002.  Work in
progress.

[20] N. Asokan, V. Niemi, and K. Nyberg, "Man-in-the-middle in tunnelled
authentication," in http://eprint.iacr.org/2002/163/ , 2002.

[21] J. Puthenkulam, V. Lortz, A. Palekar, D. Simon, and B. Aboba, "The
compound authentication binding problem," internet draft, Internet
Engineering Task Force, 2002.  Work in progress.



H. Tschofenig                                                [Page 16]


Internet Draft                                            9 January 2003


[22] U. Blumenthal, "Secure session key generation. creating PRF from
MAC function," Internet Draft, Internet Engineering Task Force, July
2002.  Work in progress.

[23] C. Perkins and Ed, "IP mobility support for IPv4," RFC 3220,
Internet Engineering Task Force, Jan. 2002.

[24] D. Johnson, C. Perkins, and J. Arkko, "Mobility support in IPv6,"
Internet Draft, Internet Engineering Task Force, July 2002.  Work in
progress.

[25] C. Perkins and E. Gustafsson, "AAA registration keys for mobile
IP," Internet Draft, Internet Engineering Task Force, Mar. 2002.  Work
in progress.

[26] F. Dupont et al.  , "AAA for mobile IPv6," Internet Draft, Internet
Engineering Task Force, Nov. 2001.  Work in progress.

[27] S. Faccin et al.  , "Diameter mobile IPv6 application," Internet
Draft, Internet Engineering Task Force, Nov. 2001.  Work in progress.

[28] M. Shore, "The TIST (topology-insensitive service traversal)
protocol," Internet Draft, Internet Engineering Task Force, May 2002.
Work in progress.

[29] H. Tschofenig and H. Schulzrinne, "A firewall/nat traversal client
for casp," internet draft, Internet Engineering Task Force, 2002.  Work
in progress.

[30] H. Schulzrinne, H. Tschofenig, X. Fu, J. Eisl, and R. Hancock,
"Casp - cross-application signaling protocol," internet draft, Internet
Engineering Task Force, 2002.  Work in progress.

[31] P. Funk and S. Blake-Wilson, "EAP tunneled TLS authentication
protocol (EAP-TTLS)," Internet Draft, Internet Engineering Task Force,
Mar.  2002.  Work in progress.

[32] H. Andersson, S. Josefsson, G. Zorn, et al.  , "Protected
extensible authentication protocol (PEAP)," Internet Draft, Internet
Engineering Task Force, Feb. 2002.  Work in progress.

[33] Y. Sheffer, H. Krawczyk, and B. Aboba, "PIC, a pre-IKE credential
provisioning protocol," Internet Draft, Internet Engineering Task Force,
Feb. 2002.  Work in progress.







H. Tschofenig                                                [Page 17]


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