Subject: [eap] Issue 307: Rewrite of Section 7, Security Requirements

From: Bernard Aboba <[email-masked]>
Date: Sat, 30 Jul 2005 16:08:10 -0700 (PDT)

Issue 307: Rewrite of Section 7, Security Requirements
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: 3/31/2005
Reference:
Document: KEYING-07
Comment type: T
Priority: S
Section: 7
Rationale/Explanation of issue

Section 7 consists of requirements on EAP methods, AAA
protocols, Secure Association Protocols and Ciphersuites that is in no way
tied back to the security requirements and threat model.  One is left to
wonder whether these "requirements" were developed out of thin air, or
whether there is any basis/justification for them.

Here is a reprint of what is in Section 7 currently.  At this point, much
of it appears redundant, or seems to belong elsewhere in the document.
From what I can see, the document wouldn't suffer that much if the entire
section were deleted and the important parts found a home elsewhere. Am I
missing something?

7.  Security Requirements

   This section summarizes the security requirements that must be met by
   EAP methods, AAA protocols,  Secure Association Protocols and
   Ciphersuites in order to address the security threats described in
   this document. These requirements MUST be met by specifications
   requesting publication as an RFC.  Each requirement provides a
   pointer to the sections of this document describing the threat that
   it mitigates.

[BA] I think the intent is to describe the security properties that
EAP extensions and/or AAA key management schemes require.  But isn't
that what draft-housley-aaa-key-mgmt is attempting to do?  If so,
why duplicate that here?

7.1.  EAP Method Requirements

   It is possible for the peer and EAP server to mutually authenticate
   and derive keys.  In order to provide keying material for use in a
   subsequently negotiated ciphersuite, an EAP method supporting key
   derivation MUST export a Master Session Key (MSK) of at least 64
   octets, and an Extended Master Session Key (EMSK) of at least 64
   octets.  EAP Methods deriving keys MUST provide for mutual
   authentication between the EAP peer and the EAP Server.

[BA] Isn't this already in [RFC3748]?

   The MSK and EMSK MUST NOT be used directly to protect data; however,
   they are of sufficient size to enable derivation of a AAA-Key
   subsequently used to derive Transient Session Keys (TSKs) for use
   with the selected ciphersuite.  Each ciphersuite is responsible for
   specifying how to derive the TSKs from the AAA-Key.

   The AAA-Key is derived from the keying material exported by the EAP
   method (MSK and EMSK).  This derivation occurs on the AAA server.  In
   many existing protocols that use EAP, the AAA-Key and MSK are
   equivalent, but more complicated mechanisms are possible.

[BA] Some of this seems useful, but why does it belong in this section?

   EAP methods SHOULD ensure the freshness of the MSK and EMSK even in
   cases where one party may not have a high quality random number
   generator.  A RECOMMENDED method is for each party to provide a nonce
   of at least 128 bits, used in the derivation of the MSK and EMSK.

[BA] Isn't this in [RFC3748] too?

   EAP methods export the MSK and EMSK and not Transient Session Keys so
   as to allow EAP methods to be ciphersuite and media independent.
   Keying material exported by EAP methods MUST be independent of the
   ciphersuite negotiated to protect data.

   Depending on the lower layer, EAP methods may run before or after
   ciphersuite negotiation, so that the selected ciphersuite may not be
   known to the EAP method.  By providing keying material usable with
   any ciphersuite, EAP methods can used with a wide range of
   ciphersuites and media.

[BA] This seems to duplicate the "ciphersuite independence" discussion.
Recommend it be moved there or deleted.

   It is RECOMMENDED that methods providing integrity protection of EAP
   packets include coverage of all the EAP header fields, including the
   Code, Identifier, Length, Type and Type-Data fields.

[BA] [RFC3748] discusses this issue -- I think this can be deleted.

   In order to preserve algorithm independence, EAP methods deriving
   keys SHOULD support (and document) the protected negotiation of the
   ciphersuite used to protect the EAP conversation between the peer and
   server.  This is distinct from the ciphersuite negotiated between the
   peer and authenticator, used to protect data.

[BA] [RFC3748] discusses this issue -- I think this can be deleted.

   The strength of Transient Session Keys (TSKs) used to protect data is
   ultimately dependent on the strength of keys generated by the EAP
   method.  If an EAP method cannot produce keying material of
   sufficient strength, then the TSKs may be subject to brute force
   attack.  In order to enable deployments requiring strong keys, EAP
   methods supporting key derivation SHOULD be capable of generating an
   MSK and EMSK, each with an effective key strength of at least 128
   bits.

[BA] I don't think this adds much value either.

   Methods supporting key derivation MUST demonstrate cryptographic
   separation between the MSK and EMSK branches of the EAP key
   hierarchy.  Without violating a fundamental cryptographic assumption
   (such as the non-invertibility of a one-way function) an attacker
   recovering the MSK or EMSK MUST NOT be able to recover the other
   quantity with a level of effort less than brute force.

   Non-overlapping substrings of the MSK MUST be cryptographically
   separate from each other.  That is, knowledge of one substring MUST
   NOT help in recovering some other non-overlapping substring without
   breaking some hard cryptographic assumption.  This is required
   because some existing ciphersuites form TSKs by simply splitting the
   AAA-Key to pieces of appropriate length.  Likewise, non-overlapping
   substrings of the EMSK MUST be cryptographically separate from each
   other, and from substrings of the MSK.  The EMSK MUST NOT be
   transported to, or shared with, additional parties.

[BA] These paragraphs do seem useful.  But why do they belong here?

   Since EAP does not provide for explicit key lifetime negotiation, EAP
   peers, authenticators and authentication servers MUST be prepared for
   situations in which one of the parties discards key state which
   remains valid on another party.

[BA] This probably belongs in the key management section 4.

   The development and validation of key derivation algorithms is
   difficult, and as a result EAP methods SHOULD reuse well established
   and analyzed mechanisms for MSK and EMSK key derivation (such as
   those specified in IKE [RFC2409] or TLS [RFC2246]), rather than
   inventing new ones.

[BA] Isn't this in [RFC3748] as well?

7.1.1.  Requirements for EAP methods

   In order for an EAP method to meet the guidelines for EMSK usage it
   must meet the following requirements:

      o It MUST specify how to derive the EMSK

      o The key material used for the EMSK MUST be
        computationally independent of the MSK and TEKs.

      o The EMSK MUST NOT be used for any other purpose than the key
        derivation described in this document.

[BA] The key derivation has been removed, so this needs to be revised.

      o The EMSK MUST be secret and not known to someone observing
        the authentication mechanism protocol exchange.

      o The EMSK MUST NOT be exported from the EAP server.

      o The EMSK MUST be unique for each session.

      o The EAP mechanism SHOULD use a unique identifier suitable for
naming the EMSK.

[BA] I think the key naming section takes care of this.

7.1.2.  Requirements for EAP applications

   In order for an application to meet the guidelines for EMSK usage it
   must meet the following requirements:

      o New applications following this specification SHOULD NOT use the
        MSK.  If more than one application uses the MSK, then the
        cryptographic separation is not achieved.  Implementations SHOULD
        prevent such combinations.

[BA] Does this still belong here?

      o A peer MUST NOT use the EMSK directly for cryptographic
        protection of data.

[BA] This one does seem important.

7.2.  AAA Protocol Requirements

   AAA protocols suitable for use in transporting EAP MUST provide the
   following facilities:

Security services
     AAA protocols used for transport of EAP keying material MUST
     implement and SHOULD use per-packet integrity and authentication,
     replay protection and confidentiality.  These requirements are met
     by Diameter EAP [I-D.ietf-aaa-eap], as well as RADIUS over IPsec
     [RFC3579].

Session Keys
     AAA protocols used for transport of EAP keying material MUST
     implement and SHOULD use dynamic key management in order to derive
     fresh session keys, as in Diameter EAP [I-D.ietf-aaa-eap] and
     RADIUS over IPsec [RFC3579], rather than using a static key, as
     originally defined in RADIUS [RFC2865].

[BA] This seems excessive.  RADIUS over IPsec is a SHOULD in [RFC3579].
Isn't that enough?

Mutual authentication
     AAA protocols used for transport of EAP keying material MUST
     provide for mutual authentication between the authenticator and
     backend authentication server.  These requirements are met by
     Diameter EAP [I-D.ietf-aaa-eap] as well as by RADIUS EAP [RFC3579].

Authorization
     AAA protocols used for transport of EAP keying material SHOULD
     provide protection against rogue authenticators masquerading as
     other authenticators.  This can be accomplished, for example, by
     requiring that AAA agents check the source address of packets
     against the origin attributes (Origin-Host AVP in Diameter, NAS-IP-
     Address, NAS-IPv6-Address, NAS-Identifier in RADIUS).  For details,
     see [RFC3579] Section 4.3.7.

Key transport
     Since EAP methods do not export Transient Session Keys (TSKs) in
     order to maintain media and ciphersuite independence, the AAA
     server MUST NOT transport TSKs from the backend authentication
     server to authenticator.

Key transport specification
     In order to enable backend authentication servers to provide keying
     material to the authenticator in a well defined format, AAA
     protocols suitable for use with EAP MUST define the format and
     wrapping of the AAA-Token.

[BA] This seems to be belaboring the obvious.  How can AAA protocols
transport keys without defining their format?

EMSK transport
     Since the EMSK is a secret known only to the backend authentication
     server and peer, the AAA-Token MUST NOT transport the EMSK from the
     backend authentication server to the authenticator.

[BA] This seems to belong in the earlier section relating to EMSK usage.

AAA-Token protection
     To ensure against compromise, the AAA-Token MUST be integrity
     protected, authenticated, replay protected and encrypted in
     transit, using well-established cryptographic algorithms.

[BA] This seems redundant with the "security services" requirement above.

Session Keys
     The AAA-Token SHOULD be protected with session keys as in Diameter
     [RFC3588] or RADIUS over IPsec [RFC3579] rather than static keys,
     as in [RFC2548].

[BA] I think this is redundant with the earlier session key paragraph.

Key naming
     In order to ensure against confusion between the appropriate keying
     material to be used in a given Secure Association Protocol
     exchange, the AAA-Token SHOULD include explicit key names and
     context appropriate for informing the authenticator how the keying
     material is to be used.

[BA] Jari questioned this one earlier.  Do we need this?

Key Compromise
     Where untrusted intermediaries are present, the AAA-Token SHOULD
     NOT be provided to the intermediaries.  In Diameter, handling of
     keys by intermediaries can be avoided using Redirect functionality
     [RFC3588].

[BA] This probably belongs in the security considerations section rather
than here.

7.3.  Secure Association Protocol Requirements

[BA] This section seems redundant with an earlier discussion of what the
Secure
Association Protocol does (Section 2).  I think it should either be
combined with
that, or deleted.

   The Secure Association Protocol supports the following:

Entity Naming
     The peer and authenticator SHOULD identify themselves in a manner
     that is independent of their attached ports.

Mutual proof of possession
     The peer and authenticator MUST each demonstrate possession of the
     keying material transported between the backend authentication
     server and authenticator (AAA-Key).

Key Naming
     The Secure Association Protocol MUST explicitly name the keys used
     in the proof of possession exchange, so as to prevent confusion
     when more than one set of keying material could potentially be used
     as the basis for the exchange.

[BA] This seems to overlap with the Housley document.

Creation and Deletion
     In order to support the correct processing of phase 2 security
     associations, the Secure Association (phase 2) protocol MUST
     support the naming of phase 2 security associations and associated
     transient session keys, so that the correct set of transient
     session keys can be identified for processing a given packet.  The
     phase 2 Secure Association Protocol also MUST support transient
     session key activation and SHOULD support deletion, so that
     establishment and re-establishment of transient session keys can be
     synchronized between the parties

Integrity and Replay Protection
     The Secure Association Protocol MUST support integrity and replay
     protection of all messages.

[BA] Again, draft-housley already says this.

Direct operation
     Since the phase 2 Secure Association Protocol is concerned with the
     establishment of security associations between the EAP peer and
     authenticator, including the derivation of transient session keys,
     only those parties have "a need to know" the transient session
     keys. The Secure Association Protocol MUST operate directly between
     the peer and authenticator, and MUST NOT be passed-through to the
     backend authentication server, or include additional parties.

[BA] What is wrong with having the SAP "passed through" as long as the
conversation is cryptographically secure?

Derivation of transient session keys
     The Secure Association Protocol negotiation MUST support derivation
     of unicast and multicast transient session keys suitable for use
     with the negotiated ciphersuite.

[BA] I think Section 2 already says this.

TSK freshness
     The Secure Association (phase 2) Protocol MUST support the
     derivation of fresh unicast and multicast transient session keys,
     even when the keying material provided by the backend
     authentication server is not fresh.  This is typically supported by
     including an exchange of nonces within the Secure Association
     Protocol.

[BA] I think Section 2 already says this.

Bi-directional operation
     While some ciphersuites only require a single set of transient
     session keys to protect traffic in both directions, other
     ciphersuites require a unique set of transient session keys in each
     direction. The phase 2 Secure Association Protocol SHOULD provide
     for the derivation of unicast and multicast keys in each direction,
     so as not to require two separate phase 2 exchanges in order to
     create a bi-directional phase 2 security association.

Secure capabilities negotiation
     The Secure Association Protocol MUST support secure capabilities
     negotiation.  This includes security parameters such as the
     security association identifier (SAID) and ciphersuites, as well as
     negotiation of the lifetime of the TSKs, AAA-Key and exported EAP
     keys.  Secure capabilities negotiation also includes confirmation
     of the capabilities discovered during the discovery phase (phase
     0), so as to ensure that the announced capabilities have not been
     forged.

Key Scoping
     The Secure Association Protocol MUST ensure the synchronization of
     key scope between the peer and authenticator.  This includes
     negotiation of restrictions on key usage.

[BA] I think Section 2 already says this.

7.4.  Ciphersuite Requirements

   Ciphersuites suitable for keying by EAP methods MUST provide the
   following facilities:

TSK derivation
     In order to allow a ciphersuite to be usable within the EAP keying
     framework, a specification MUST be provided describing how
     transient session keys suitable for use with the ciphersuite are
     derived from the AAA-Key.

EAP method independence
     Algorithms for deriving transient session keys from the AAA-Key
     MUST NOT depend on the EAP method.  However, algorithms for
     deriving TEKs MAY be specific to the EAP method.

[BA] I think this is already discussed in the Method Independence section.

Cryptographic separation
     The TSKs derived from the AAA-Key MUST be cryptographically
     separate from each other.  Similarly, TEKs MUST be
     cryptographically separate from each other.  In addition, the TSKs
     MUST be cryptographically separate from the TEKs.

[BA] Why not put these cryptographic requirements in one section?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 30 Jul 2005 23:03:28 -0700 (PDT)

Here is a proposed resolution:

The overall recommendation is to delete Section 7.  Here are the details:

Section 7.1 appears to have been taken from [RFC3748] Section 7.10.  It is
therefore redundant and can be deleted.

Section 7.2 relates not to requirements but rather to the security
vulnerabilities inherent in RADIUS and Diameter usage.  It therefore
should be incorporated into Section 6, Security Considerations (See Issue
294).  One this is done, this section can be deleted.

Section 2.3, 4, 7.3 all include requirements relating to the Secure
Association Protocol.  The recommendation is to consolidate this material
into Section 4, while deleting Section 7.3, and replacing Section 2.3 with
the following:

"2.3.  Secure Association Phase

   The Secure Association phase (phase 2), if it occurs, begins after
   the completion of EAP authentication (phase 1a) and key transport
   (phase 1b).

   Secure Association Protocols typically include the following
   features:

[1]  Generation of fresh unicast and multicast transient session keys.

[2]  Integrity and replay protection.  This ensures that the Secure
     Association Protocol messages cannot be forged, modified or
     replayed.

[3]  Secure capabilities negotiation.  This enables security-relevant
     parameters such as cryptographic algorithms to be securely
     negotiated.

[3]  Key management and naming.  This enables security associations to
     be created and deleted, and for key state to be kept synchronized
     between the peer and authenticator.

[4]  Mutual proof of possession of EAP keying material between the peer
     and authenticator.  This enables the EAP peer and authenticator to
     confirm authorization.

   Aspects of the Secure Association Protocol are discussed in more
   detail in Section 4."

Replace Section 4 with the following:

"4.  Key Management

   EAP as defined in [RFC3748] supports key derivation, but not key
   management.  While EAP methods may derive keying material, EAP does
   provide for the management of exported or derived keys.  For example,
   EAP does not support negotiation of the key lifetime of exported or
   derived keys, nor does it support rekey.  Although EAP methods may
   support "fast reconnect" as defined in [RFC3748] Section 7.2.1, rekey
   of exported keys cannot occur without reauthentication.  In order to
   provide method independence, key management of exported or derived
   keys SHOULD NOT be provided within EAP methods.

   Since neither EAP nor EAP methods provide key management support, it
   is RECOMMENDED that key management facilities be provided within the
   Secure Association Protocol.  This includes:

[a]  Entity Naming.  A basic feature of a Secure Association Protocol is
     the explicit naming of the parties engaged in the exchange.
     Explicit identification of the parties is critical, since without
     this the parties engaged in the exchange are not identified and the
     scope of the EAP keying parameters negotiated during the EAP
     exchange is undefined.  As shown in Figure 3, both the peer and NAS
     may have more than one physical or virtual port.  As a result, the
     peer and authenticator SHOULD identify themselves in a manner that
     is independent of their attached ports.

[b]  Mutual proof of possession of EAP keying material.  The Secure
     Association Protocol MUST demonstrate possession of the keying
     material transported between the backend authentication server and
     authenticator (.e.g. AAA-Key), and show that both the peer and
     authenticator have been authenticated and authorized.  Since mutual
     proof of possession is not the same as mutual authentication, the
     peer cannot verify authenticator assertions (including the
     authenticator identity) as a result of this exchange.

[c]  Secure capabilities negotiation.  In order to protect against
     spoofing during the discovery phase, ensure selection of the "best"
     ciphersuite, and protect against forging of negotiated security
     parameters, the Secure Association Protocol MUST support secure
     capabilities negotiation.  This includes the secure negotiation of
     usage modes, session parameters (such as security association
     identifiers (SAIDs) and key lifetimes), ciphersuites and required
     filters, including confirmation of security-relevant capabilities
     discovered during phase 0.  As part of secure capabilities
     negotiation, the Secure Association Protocol MUST support integrity
     and replay protection of all messages.

[d]  Key naming and selection.  Where key caching is supported, it may
     be possible for the EAP peer and authenticator to share more than
     one key of a given type.  As a result, the Secure Association
     Protocol MUST explicitly name the keys used in the proof of
     possession exchange, so as to prevent confusion when more than one
     set of keying material could potentially be used as the basis for
     the exchange.  Use of the key naming mechanism described in this
     document is RECOMMENDED.

     synchronized between the parties.

[e]  Generation of fresh transient session keys (TSKs).  Where the lower
     layer supports caching of exported EAP keying material, the EAP
     peer lower layer may initiate a new session using keying material
     that was derived in a previous session.  Were the TSKs to be
     derived from a portion of the exported EAP keying material, this
     would result in reuse of the session keys which could expose the
     underlying ciphersuite to attack.

     As a result, in lower layers where caching of EAP keying material
     is supported, the Secure Association Protocol phase is REQUIRED,
     and MUST support the derivation of fresh unicast and multicast
     TSKs, even when the keying material provided by the backend
     authentication server is not fresh.  This is typically supported
     via the exchange of nonces or counters, which are then mixed with
     the exported keying material in order to generate  fresh unicast
     (phase 2a) and possibly multicast (phase 2b) session keys.  By not
     using EAP keying material directly to protect data, the Secure
     Association Protocol protects it against compromise.

[f]  Key lifetime management.  This includes explicit key lifetime
     negotiation or seamless rekey.  EAP does not support negotiation of
     key lifetimes, nor does it support rekey without reauthentication.
     As a result, the Secure Association Protocol may handle rekey and
     determination of the key lifetime.  Where key caching is supported,
     secure negotiation of key lifetimes is RECOMMENDED.  Lower layers
     that support rekey, but not key caching, may not require key
     lifetime negotiation.  To take an example from IKE, the difference
     between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were
     negotiated. In IKEv2, each end of the SA is responsible for
     enforcing its own lifetime policy on the SA and rekeying the SA
     when necessary.

[g]  Key resynchronization.  It is possible for the peer or
     authenticator to reboot or reclaim resources, clearing portions or
     all of the key cache.  Therefore, key lifetime negotiation cannot
     guarantee that the key cache will remain synchronized, and the peer
     may not be able to determine before attempting to use a key whether
     it exists within the authenticator cache.  It is therefore
     RECOMMENDED for the Secure Association Protocol to provide a
     mechanism for key state resynchronization.  Since in this situation
     one or more of the parties initially do not possess a key with
     which to protect the resynchronization exchange, securing this
     mechanism may be difficult.

[h]  Key scope synchronization.  Since the Discovery phase is handled
     out-of-band, EAP does not provide a mechanism by which the peer can
     determine the authenticator identity.  As a result, where the
     authenticator has multiple ports and key caching is supported, the
     EAP peer may not be able to determine the scope of validity of the
     exported EAP keying material.  Similarly, where the EAP peer has
     multiple ports, the authenticator may not be able to determine
     whether a peer has authorization to use a particular key.  To allow
     key scope determination, the Secure Association Protocol SHOULD
     provide a mechanism by which the peer can determine the scope of
     the key cache on each authenticator, and by which the authenticator
     can determine the scope of the key cache on a peer.  This includes
     negotiation of restrictions on key usage.

[i]  Direct operation.  Since the phase 2 Secure Association Protocol is
     concerned with the establishment of security associations between
     the EAP peer and authenticator, including the derivation of
     transient session keys, only those parties have "a need to know"
     the transient session keys. The Secure Association Protocol MUST
     operate directly between the peer and authenticator, and MUST NOT
     be passed-through to the backend authentication server, or include
     additional parties.

[j]  Bi-directional operation While some ciphersuites only require a
     single set of transient session keys to protect traffic in both
     directions, other ciphersuites require a unique set of transient
     session keys in each direction. The phase 2 Secure Association
     Protocol SHOULD provide for the derivation of unicast and multicast
     keys in each direction, so as not to require two separate phase 2
     exchanges in order to create a bi-directional phase 2 security
     association."

After deleting Sections 7.1, 7.2 and 7.3, all that remains of Section 7 is
Section 7.4 (Ciphersuite Requirements).  This section can be incorporated into
Section 1.4.4 (Ciphersuite Independence):

"1.4.4.  Ciphersuite Independence

   Ciphersuite Independence is a consequence of the principles of Mode
   Independence and Media Independence.

   While EAP methods may negotiate the ciphersuite used in protection of
   the EAP conversation, the ciphersuite used for the protection of the
   data exchanged after EAP authentication has completed is negotiated
   between the peer and authenticator within the lower layer, outside of
   EAP.

   For example, within PPP, the ciphersuite is negotiated within the
   Encryption Control Protocol (ECP) defined in [RFC1968], after EAP
   authentication is completed.  Within [IEEE-802.11i], the AP
   ciphersuites are advertised in the Beacon and Probe Responses prior
   to EAP authentication, and are securely verified during a 4-way
   handshake exchange.

   Since the ciphersuites used to protect data depend on the lower
   layer, requiring EAP methods have knowledge of lower layer
   ciphersuites would compromise the principle of Media Independence.
   Since ciphersuite negotiation occurs in the lower layer, there is no
   need for ciphersuite negotiation within EAP, and EAP methods generate
   keying material that is ciphersuite-independent.

   Algorithms for deriving TSKs MUST NOT depend on the EAP
   method, although algorithms for TEK derivation MAY be specific
   to the EAP method.

   In order to allow a ciphersuite to be usable within the EAP keying
   framework, a specification MUST be provided describing how TSKs
   suitable for use with the ciphersuite are
   derived from exported EAP keying parameters.

   Advantages of ciphersuite-independence include:

Reduced update requirements
     If EAP methods were to specify how to derive transient session keys
     for each ciphersuite, they would need to be updated each time a new
     ciphersuite is developed.  In addition, backend authentication
     servers might not be usable with all EAP-capable authenticators,
     since the backend authentication server would also need to be
     updated each time support for a new ciphersuite is added to the
     authenticator.

Reduced EAP method complexity
     Requiring each EAP method to include ciphersuite-specific code for
     transient session key derivation would increase method complexity
     and result in duplicated effort.

Simplified configuration
     The ciphersuite is negotiated between the peer and authenticator
     outside of EAP.  Where the authenticator operates in "pass-through"
     mode, the EAP server is not a party to this negotiation, nor is it
     involved in the data flow between the EAP peer and authenticator.
     As a result, the EAP server may not have knowledge of the
     ciphersuites and negotiation policies implemented by the peer and
     authenticator, or be aware of the ciphersuite negotiated between
     them.  For example, since ECP negotiation occurs after
     authentication, when run over PPP, the EAP peer and server may not
     anticipate the negotiated ciphersuite and therefore this
     information cannot be provided to the EAP method."

The only remaining paragraph from Section 7.4 can be added to Section
2.5.1:

"  TSKs MUST be cryptographically separate from each other.  Similarly,
   TEKs MUST be cryptographically separate from each other.  In
   addition, the TSKs MUST be cryptographically separate from the TEKs."

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 30 Jul 2005 23:27:34 -0700 (PDT)

In addition, consolidate Section 7.1.1 and 7.1.2 into Section 1.5, as
follows:

1.5  EMSK Usage

The MSK and EMSK MUST be unique for each session.
The EMSK must be cryptographically independent of the MSK and TEKs, and
the EMSK MUST be secret and not known to someone observing the
EAP authentication exchange.

The EMSK MUST NOT be transported from the EAP server to another
party, and as a result the EMSK is not replicated between
the backend server and authenticator via the AAA protocol.  Although the
EMSK is not replicated, it is possible to derive keys from the EMSK via a
one-way function, and for these derived keys to be replicated from the
backend server to the authenticator.

Where a backend server is present the EMSK will not be available on
the authenticator, and therefore in order for the principle of Mode
Independence to be satisfied, TSKs derived within the lower layer
MUST NOT depend directly on the EMSK.  The EMSK MUST NOT be used
directly for cryptographic protection of data.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap