5. Limitations of TEAPv1

Cette section conserve le texte RFC pour TEAPv1, y compris TLS tunnel establishment, tunneled authentication, TLV formats, cryptographic calculations, IANA registries, security considerations et examples.

5.  Limitations of TEAPv1

   As noted in Section 1.1, TEAPv1 implementations are limited in
   functionality as compared to what the protocol is theoretically
   capable of.  These limitations mean that only a small number of inner
   methods are fully supported by existing TEAPv1 implementations.

   While Section 6 defines the cryptographic calculations used for key
   derivation and crypto-binding, this section documents which Inner
   Methods are known to work and why those methods work.  Other Inner
   Methods may work, but those results are likely to be implementation-
   specific.

   We discuss the issues here without naming particular implementations
   or making any negative inference about them.  The implementations
   work well enough together in limited situations.  Any
   interoperability issues are due to the complexity and incompleteness
   of the definitions given in [RFC7170] and are not due to issues with
   any particular implementation.

   The interoperability issues are limited to the use and derivation of
   the Compound MAC(s), which are derived from the inner MSK and EMSK.
   In short, implementations are known to derive different values for
   the Compound MAC(s) when more than one Inner Method provides an EMSK.

5.1.  Interoperable Inner Methods

   The following Inner Methods are known to work.  These methods work
   for both User and Machine credentials.

   *  EAP-MSCHAPv2

   *  EAP-TLS

   The following combinations of Inner Methods are known to work.  These
   methods work for any order of User and Machine credentials.

   *  EAP-MSCHAPv2 followed by EAP-MSCHAPv2

   *  EAP-TLS followed by EAP-MSCHAPv2

   The following combinations of Inner Methods are known to work when
   both the supplicant and authenticator ignore the EMSK Compound MAC
   field of the Crypto-Binding TLV.  These methods work for any order of
   User and Machine credentials.

   *  EAP-MSCHAPv2 followed by EAP-TLS

   *  EAP-TLS followed by EAP-TLS

5.2.  Explanation and Background

   The main reason for the limited set of Inner Methods is that the most
   well-known TEAP supplicant supports only EAP-MSCHAPv2 and EAP-TLS for
   the Inner Methods.  Further, this implementation does not encode the
   EMSK Compound MAC field in all of the Crypto-Binding TLVs that it
   sends and ignores that field in all of the Crypto-Binding TLVs that
   it receives.

   The known authenticator implementations support this client, but any
   other combination of Inner Methods was not tested.  As a result, each
   authenticator implemented entirely different derivations of the EMSK
   Compound MAC field of the Crypto-Binding TLV due to both the
   complexity of the cryptographic derivations and the lack of
   interoperability testing.  This difference was discovered only after
   multiple implementations had been shipping for years.

5.3.  Next Steps

   Any attempt to change TEAPv1 to address these issues would likely
   result in one or more implementations being non-compliant with the
   updated specification.  Even worse, updates to this specification
   would result in multiple incompatible versions of TEAPv1.

   That approach is not acceptable.

   In the interest of maintaining known interoperability, this
   specification simply documents these issues rather than trying to
   correct the problem.  Since the TEAP and the Crypto-Binding TLV both
   contain a Version field, the better path forward is to publish this
   specification while documenting the large caveats for TEAPv1.  Any
   changes to the TEAP can then be done in a future TEAPv2
   specification.