|
List Info Thread: Issue 412: Evaluation of EAP Lower Layers?
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
Issue 412: Evaluation of EAP Lower Layers? |
|
List Info Thread: Issue 412: Evaluation of EAP Lower Layers?
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
microsoft.com
Date first submitted: October 18, 2007
Reference:
Document: draft-ietf-eap-keying-18.txt
Comment type: Technical
Priority: S
Section: Section 1.3.1, 3.1, 5
Rationale/Explanation of Issue:
Section 3.1 describes SAP properties, but it doesn't
evaluate existing EAP
lower layers (such as PPP, IKEv2, IEEE 802.11, IEEE 802.16)
against these
properties. Also Section 5 is somewhat inconsistent in
evaluating the RFC
4962 criteria against existing examples; some sections do
this, others do
not.
[BA] Sections 1.3.1 and 2.1 discuss existing EAP lower
layers. Perhaps it
would be helpful to add more detail to these Sectoins? Here
is some
suggested text:
Section 1.3.1:
"1.3.1. Examples
Existing EAP lower layers implement phase 0, 2a and 2b in
different
ways:
PPP The Point-to-Point Protocol (PPP), defined in [RFC1661]
does not
support discovery, nor does it include a Secure
Association
Protocol.
PPPoE
PPP over Ethernet (PPPoE), defined in [RFC2516],
includes support
for a Discovery stage (phase 0). In this step, the EAP
peer sends
a PPPoE Active Discovery Initiation (PADI) packet to
the broadcast
address, indicating the service it is requesting. The
Access
Concentrator replies with a PPPoE Active Discovery
Offer (PADO)
packet containing its name, the service name and an
indication of
the services offered by the concentrator. The
discovery phase is
not secured. PPPoE, like PPP, does not include a
Secure
Association Protocol.
IKEv2
Internet Key Exchange v2 (IKEv2), defined in [RFC4306],
includes
support for EAP and handles the establishment of
unicast security
associations (phase 2a). However, the establishment of
multicast
security associations (phase 2b) typically does not
involve EAP and
needs to be handled by a group key management protocol
such as GDOI
[RFC3547], GSAKMP [RFC4535], MIKEY [RFC3830], or GKDP
[GKDP].
Several mechanisms have been proposed for discovery of
IPsec
security gateways. [RFC2230] discusses the use of Key
eXchange
(KX) Resource Records (RRs) for IPsec gateway
discovery; while KX
RRs are supported by many Domain Name Service (DNS)
server
implementations, they have not yet been widely
deployed.
Alternatively, DNS SRV RRs [RFC2782] can be used for
this purpose.
Where DNS is used for gateway location, DNS security
mechanisms
such as DNSSEC ([RFC4033], [RFC4035]), TSIG [RFC2845],
and Simple
Secure Dynamic Update [RFC3007] are available.
IEEE 802.11
IEEE 802.11, defined in [IEEE-802.11], handles
discovery via the
Beacon and Probe Request/Response mechanisms. IEEE
802.11 access
points periodically announce their Service Set
Identifiers (SSIDs)
as well as capabilities using Beacon frames. Stations
can query
for access points by sending a Probe Request to the
broadcast
address. Neither Beacon nor Probe Request/Response
frames are
secured. The 4-way handshake defined in [IEEE-802.11]
enables the
derivation of unicast (phase 2a) and
multicast/broadcast (phase 2b)
secure associations. Since the group key exchange
transports a
group key from the access point to the station, two
4-way
handshakes can be needed in order to support
peer-to-peer
communications. A proof of the security of the IEEE
802.11 4-way
handshake when used with EAP-TLS is provided in [He].
IEEE 802.1X
IEEE 802.1X-2004, defined in [IEEE-802.1X] does not
support
discovery (phase 0), nor does it provide for derivation
of unicast
or multicast secure associations.
"
Section 2.1:
"2.1. Transient Session Keys
Where explicitly supported by the lower layer, lower
layers MAY cache
keying material, including exported EAP keying material
and/or TSKs;
the structure of this key cache is defined by the lower
layer. So as
to enable interoperability, new lower layer
specifications MUST
describe key caching behavior. Unless explicitly
specified by the
lower layer, the EAP peer, server and authenticator MUST
assume that
peers and authenticators do not cache keying material.
Existing EAP
lower layers and AAA layers handle the generation of
transient
session keys and caching of EAP keying material in
different ways:
IEEE 802.1X-2004
When used with wired networks, IEEE 802.1X-2004
[IEEE-802.1X] does
not support link layer ciphersuites and a result, it
does not
provide for generation of TSKs, or caching of EAP
keying material
and parameters. Once EAP authentication completes, it
is assumed
that EAP keying material and parameters are discarded;
on IEEE 802
wired networks there is no subsequent Secure
Association Protocol
exchange. Perfect Forward Secrecy (PFS) is only
possible if the
negotiated EAP method supports this.
PPP PPP, defined in [RFC1661] does not include support for
a Secure
Association Protocol; nor does it support caching of
EAP keying
material or parameters. PPP ciphersuites derive their
TSKs
directly from the MSK, as described in [RFC2716]. This
is NOT
RECOMMENDED, since if PPP were to support caching of
EAP keying
material, this could result in TSK reuse. As a result,
once the
PPP session is terminated, EAP keying material and
parameters MUST
be discarded. Since caching of EAP keying material is
not
permitted within PPP, there is no way to handle TSK
re-key without
EAP re-authentication. Perfect Forward Secrecy (PFS)
is only
possible if the negotiated EAP method supports this.
IKEv2
IKEv2, defined in [RFC4306] only uses the MSK for
authentication
purposes and not key derivation. The EMSK, IV,
Peer-Id, Server-Id
or Session-Id are not used. As a result, the TSKs
derived by IKEv2
are cryptographically independent of the EAP keying
material and
re-key of IPsec SAs can be handled without requiring
EAP re-
authentication. Within IKEv2 it is possible to
negotiate PFS,
regardless of which EAP method is negotiated. IKEv2 as
specified
in [RFC4306] does not cache EAP keying material or
parameters; once
IKEv2 authentication completes it is assumed that EAP
keying
material and parameters are discarded. The
Session-Timeout
attribute is therefore interpreted as a limit on the
VPN session
time, rather than an indication of the MSK key
lifetime.
IEEE 802.11
IEEE 802.11 enables caching of the MSK, but not the
EMSK, IV, Peer-
Id, Server-Id, or Session-Id. More details about the
structure of
the cache are available in [IEEE-802.11]. In IEEE
802.11, TSKs are
derived from the MSK using a Secure Association
Protocol known as
the 4-way handshake, which includes a nonce exchange.
This
guarantees TSK freshness even if the MSK is reused.
The 4-way
handshake also enables TSK re-key without EAP
re-authentication.
PFS is only possible within IEEE 802.11 if caching is
not enabled
and the negotiated EAP method supports PFS.
IEEE 802.16e
IEEE 802.16e, defined in [IEEE-802.16e] supports
caching of the
MSK, but not the EMSK, IV, Peer-Id, Server-Id or
Session-Id. IEEE
802.16e support a Secure Association Protocol in which
TSKs are
chosen by the authenticator without any contribution by
the peer.
The TSKs are encrypted, authenticated and integrity
protected using
the MSK and are transported from the authenticator to
the peer.
TSK re-key is possible without EAP re-authentication.
PFS is not
possible even if the negotiated EAP method supports
it.
"
Also, I have added a bit more detail to Section 5 on how
various existing
protocols conform to the RFC 4962 criteria.
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit: