Re: [Emu] Review of Requirements for an Tunnel Based EAP Method
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Emu] Review of Requirements for an Tunnel Based EAP Method
Given this, the requirement could be rephrased to highlight the items
that need to be protected (type code, version numbers, etc.), while dropping
the
EAP Header protection requirement.
-----Original Message-----
From: Hao Zhou (hzhou) [mailto:hzhou at cisco.com]
Sent: Wednesday, July 09, 2008 7:24 AM
To: Joseph Salowey (jsalowey); Bernard Aboba; emu at ietf.org
Subject: RE: [Emu] Review of Requirements for an Tunnel Based EAP Method
The intent of this requirement is to protect any data sent outside the
TLS data. This would include the EAP header and any method specific
fields such as version number field. We know we cannot protect these
data before a TLS session is established, most likely we are talking
about validation afterwards.
The EAP header protection, as discussed below, might not brFrom emu-bounces at ietf.org Wed Jul 9 14:05:07 2008
Return-Path: <emu-bounces at ietf.org>
X-Original-To: emu-archive at megatron.ietf.org
Delivered-To: ietfarch-emu-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 4AC493A6B82;
Wed, 9 Jul 2008 14:05:07 -0700 (PDT)
X-Original-To: emu at core3.amsl.com
Delivered-To: emu at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 77A503A6B82
for <emu at core3.amsl.com>; Wed, 9 Jul 2008 14:05:06 -0700 (PDT)
X-Quarantine-ID: <QhTEBIB5wfKi>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID"
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5
tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_66=0.6]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id QhTEBIB5wfKi for <emu at core3.amsl.com>;
Wed, 9 Jul 2008 14:05:05 -0700 (PDT)
Received: from bay0-omc2-s34.bay0.hotmail.com (bay0-omc2-s34.bay0.hotmail.com
[65.54.246.170])
by core3.amsl.com (Postfix) with ESMTP id 337283A6B7E
for <emu at ietf.org>; Wed, 9 Jul 2008 14:05:05 -0700 (PDT)
Received: from hotmail.com ([10.4.31.15]) by bay0-omc2-s34.bay0.hotmail.com
with Microsoft SMTPSVC(6.0.3790.3959);
Wed, 9 Jul 2008 14:05:18 -0700
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
Wed, 9 Jul 2008 14:05:17 -0700
Message-ID: <BLU137-DAV59F105B53AACBB5E9396193960 at phx.gbl>
Received: from 131.107.0.102 by BLU137-DAV5.phx.gbl with DAV;
Wed, 09 Jul 2008 21:05:13 +0000
X-Originating-IP: [131.107.0.102]
X-Originating-Email: [bernard_aboba at hotmail.com]
X-Sender: bernard_aboba at hotmail.com
From: "Bernard Aboba" <Bernard_Aboba at hotmail.com>
To: "'Hao Zhou \(hzhou\)'" <hzhou at cisco.com>,
"'Joseph Salowey \(jsalowey\)'" <jsalowey at cisco.com>, <emu at ietf.org>
References: <BLU137-W37804D710254C2A819E5A993A30 at phx.gbl>
<AC1CFD94F59A264488DC2BEC3E890DE5061E19DD at xmb-sjc-225.amer.cisco.com>
<9958B444368E884DBB215F3FEF36F5B7075F17D7 at xmb-rtp-212.amer.cisco.com>
In-Reply-To: <9958B444368E884DBB215F3FEF36F5B7075F17D7 at xmb-rtp-212.amer.cisco.com>
Date: Wed, 9 Jul 2008 14:05:09 -0700
Message-ID: <000a01c8e207$78d2f9c0$6a78ed40$ at com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
thread-index: AcjXWHVrgj9hurUWQLu0PAxpdgh20gJCGr0QAFs8KgAADlN6MA==
Content-Language: en-us
X-OriginalArrivalTime: 09 Jul 2008 21:05:17.0967 (UTC)
FILETIME=[7D95B1F0:01C8E207]
Subject: Re: [Emu] Review of Requirements for an Tunnel Based EAP Method
X-BeenThere: emu at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/emu>,
<mailto:emu-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/emu>
List-Post: <mailto:emu at ietf.org>
List-Help: <mailto:emu-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>,
<mailto:emu-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: emu-bounces at ietf.org
Errors-To: emu-bounces at ietf.org
Given this, the requirement could be rephrased to highlight the items
that need to be protected (type code, version numbers, etc.), while dropping
the
EAP Header protection requirement.
-----Original Message-----
From: Hao Zhou (hzhou) [mailto:hzhou at cisco.com]
Sent: Wednesday, July 09, 2008 7:24 AM
To: Joseph Salowey (jsalowey); Bernard Aboba; emu at ietf.org
Subject: RE: [Emu] Review of Requirements for an Tunnel Based EAP Method
The intent of this requirement is to protect any data sent outside the
TLS data. This would include the EAP header and any method specific
fields such as version number field. We know we cannot protect these
data before a TLS session is established, most likely we are talking
about validation afterwards.
The EAP header protection, as discussed below, might not bring muching much
value. I am ok with removing it.
Another related problem is protection or validation of version
negotiation, which is usually happened outside the TLS protection. To
prevent downgrade attack, we should add some requirement to make sure
there is some validation of the advertised version number or any method
specific data sent outside TLS of both sides.
> -----Original Message-----
> From: emu-bounces at ietf.org [mailto:emu-bounces at ietf.org] On
> Behalf Of Joseph Salowey (jsalowey)
> Sent: Monday, July 07, 2008 2:48 PM
> To: Bernard Aboba; emu at ietf.org
> Subject: Re: [Emu] Review of Requirements for an Tunnel Based
> EAP Method
>
> I think this issues has been raised in the past, does anyone
> on the list have any specific scenarios where EAP header
> protections are important?
> If not the requirement can be downgraded or removed entirely.
>
> With respect to making one method look like another, some
> systems such as 802.1X-2004, do not make use of the MSK/EMSK.
> Does this introduce a problem? I can't really think an
> exploitable attack outside of denial of service at this
> point. In addition, more and more systems are moving towards
> some type of cryptographic verification in the lower layer so
> this might not being an ongoing problem.
>
> Joe
>
> > -----Original Message-----
> > From: emu-bounces at ietf.org [mailto:emu-bounces at ietf.org] On
> Behalf Of
> > Bernard Aboba
> > Sent: Wednesday, June 25, 2008 11:47 PM
> > To: emu at ietf.org
> > Subject: [Emu] Review of Requirements for an Tunnel Based EAP Method
> >
> > Overall, this document is in very good shape. Kudos to the
> authors.
> >
> > A comment on EAP header protection (Section 4.2.3) and Type code
> > modification (Section 6.3):
> >
> > 4.2.3. EAP Header Protection
> >
> >
> > A tunnel method SHOULD provide protection of the outer EAP header
> > information when possible to make sure the outer EAP
> header is not
> > modified by the intermediaries.
> >
> > 6.3. Outer EAP Method Header
> >
> > There are several existing EAP methods which use a similar packet
> > format to EAP-TLS. Often for the initial portions of
> the exchange
> > the execution of the method is identical except for the
> method ID.
> > Protection of the outer EAP header helps to avoid vulnerabilities
> > that may arise when an attacker attempts to modify
> packets to make
> > one EAP message look like one from a different method.
> >
> > [BA] The EAP header defined in RFC 3748 looks like this:
> >
> > 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
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | Code | Identifier | Length |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | Type ...
> > +-+-+-+-+
> >
> > Section 6.3 refers to modification of the Type field which can
> > potentially enable an attacker to make one TLS-based EAP
> method look
> > like another one. It's worth noting that such an attack can be
> > addressed without necessarily requiring EAP header protection, as
> > described in Section 4.2.3.
> >
> > For example, a Type field modification attack will only
> enable an EAP
> > peer to subsequently connect to an authenticator if the peer and
> > server were able to derive the same MSK/EMSK.
> >
> > To prevent such an attack, it is highly desirable for TLS-based EAP
> > methods to utilize key derivation formulas unique to the
> method. As
> > an example, EAP-TLS and EAP-TTLSv0 utilize different key derivation
> > formulas:
> >
> > EAP-TLS:
> > Key_Material = TLS-PRF-128(master_secret, "client EAP
> encryption",
> > client.random || server.random)
> > EAP-TTLSv0:
> > Keying Material = TLS-PRF-128(master_secret,
> > "ttls keying material", client_random ||
> > server_random)
> >
> > Assuming that this approach is taken, the Type modification threa
value. I am ok with removing it.
Another related problem is protection or validation of version
negotiation, which is usually happened outside the TLS protection. To
prevent downgrade attack, we should add some requirement to make sure
there is some validation of the advertised version number or any method
specific data sent outside TLS of both sides.
> -----Original Message-----
> From: emu-bounces at ietf.org [mailto:emu-bounces at ietf.org] On
> Behalf Of Joseph Salowey (jsalowey)
> Sent: Monday, July 07, 2008 2:48 PM
> To: Bernard Aboba; emu at ietf.org
> Subject: Re: [Emu] Review of Requirements for an Tunnel Based
> EAP Method
>
> I think this issues has been raised in the past, does anyone
> on the list have any specific scenarios where EAP header
> protections are important?
> If not the requirement can be downgraded or removed entirely.
>
> With respect to making one method look like another, some
> systems such as 802.1X-2004, do not make use of the MSK/EMSK.
> Does this introduce a problem? I can't really think an
> exploitable attack outside of denial of service at this
> point. In addition, more and more systems are moving towards
> some type of cryptographic verification in the lower layer so
> this might not being an ongoing problem.
>
> Joe
>
> > -----Original Message-----
> > From: emu-bounces at ietf.org [mailto:emu-bounces at ietf.org] On
> Behalf Of
> > Bernard Aboba
> > Sent: Wednesday, June 25, 2008 11:47 PM
> > To: emu at ietf.org
> > Subject: [Emu] Review of Requirements for an Tunnel Based EAP Method
> >
> > Overall, this document is in very good shape. Kudos to the
> authors.
> >
> > A comment on EAP header protection (Section 4.2.3) and Type code
> > modification (Section 6.3):
> >
> > 4.2.3. EAP Header Protection
> >
> >
> > A tunnel method SHOULD provide protection of the outer EAP header
> > information when possible to make sure the outer EAP
> header is not
> > modified by the intermediaries.
> >
> > 6.3. Outer EAP Method Header
> >
> > There are several existing EAP methods which use a similar packet
> > format to EAP-TLS. Often for the initial portions of
> the exchange
> > the execution of the method is identical except for the
> method ID.
> > Protection of the outer EAP header helps to avoid vulnerabilities
> > that may arise when an attacker attempts to modify
> packets to make
> > one EAP message look like one from a different method.
> >
> > [BA] The EAP header defined in RFC 3748 looks like this:
> >
> > 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
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | Code | Identifier | Length |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | Type ...
> > +-+-+-+-+
> >
> > Section 6.3 refers to modification of the Type field which can
> > potentially enable an attacker to make one TLS-based EAP
> method look
> > like another one. It's worth noting that such an attack can be
> > addressed without necessarily requiring EAP header protection, as
> > described in Section 4.2.3.
> >
> > For example, a Type field modification attack will only
> enable an EAP
> > peer to subsequently connect to an authenticator if the peer and
> > server were able to derive the same MSK/EMSK.
> >
> > To prevent such an attack, it is highly desirable for TLS-based EAP
> > methods to utilize key derivation formulas unique to the
> method. As
> > an example, EAP-TLS and EAP-TTLSv0 utilize different key derivation
> > formulas:
> >
> > EAP-TLS:
> > Key_Material = TLS-PRF-128(master_secret, "client EAP
> encryption",
> > client.random || server.random)
> > EAP-TTLSv0:
> > Keying Material = TLS-PRF-128(master_secret,
> > "ttls keying material", client_random ||
> > server_random)
> >
> > Assuming that this approach is taken, the Type modification threat
> > dt
> > described in Section 6.3 can be addressed without EAP header
> > protection.
> >
> > Given this, it seems to me that EAP header protection is
> really about
> > protection of the Code, Identifier
> > and Length fields of the EAP header. However, the behavior
> > of these fields is fairly rigidly specified in RFC 3748, so that a
> > well written implementation should only be vulnerable to
> DoS attack,
> > which would be the case even if EAP header protection were
> > implemented.
> >
> > For example, an attacker modifying the Code field might be able to
> > cause an EAP peer or server to drop the packet.
> > However, the same thing would happen if EAP header protection were
> > implemented, and the packet failed the MIC check.
> >
> >
> > Via modification of the Identifier field, it might be
> > possible to cause the peer or server to abort the EAP session
> > in progress. However, in TLS-based methods, failure of TLS
> > integrity check is also a terminal error, so that I'm not
> > sure if anything is gained here either.
> >
> >
> > Modification of the Length field might have as its objective
> > the inducement of a buffer overflow on either the peer or the
> > server, so it's aims are somewhat more nefarious than attacks
> > on the Code or Identifier fields. However, implementation of
> > EAP header protection would not be likely to address such an
> > implementation bug since the MIC could not be computed until
> > the EAP packet was fully received, by which time the buffer
> > overflow would have already occurred.
> >
> >
> > In summary, I am not clear that EAP header protection as
> > described in Section 4.2.3 really brings much value beyond
> > addressing the EAP Type Code attack described in Section 6.3.
> > I would therefore recommend that this section be deleted, or
> > at least justified in more depth.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> _______________________________________________
> Emu mailing list
> Emu at ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
_______________________________________________
Emu mailing list
Emu at ietf.org
https://www.ietf.org/mailman/listinfo/emu
escribed in Section 6.3 can be addressed without EAP header
> > protection.
> >
> > Given this, it seems to me that EAP header protection is
> really about
> > protection of the Code, Identifier
> > and Length fields of the EAP header. However, the behavior
> > of these fields is fairly rigidly specified in RFC 3748, so that a
> > well written implementation should only be vulnerable to
> DoS attack,
> > which would be the case even if EAP header protection were
> > implemented.
> >
> > For example, an attacker modifying the Code field might be able to
> > cause an EAP peer or server to drop the packet.
> > However, the same thing would happen if EAP header protection were
> > implemented, and the packet failed the MIC check.
> >
> >
> > Via modification of the Identifier field, it might be
> > possible to cause the peer or server to abort the EAP session
> > in progress. However, in TLS-based methods, failure of TLS
> > integrity check is also a terminal error, so that I'm not
> > sure if anything is gained here either.
> >
> >
> > Modification of the Length field might have as its objective
> > the inducement of a buffer overflow on either the peer or the
> > server, so it's aims are somewhat more nefarious than attacks
> > on the Code or Identifier fields. However, implementation of
> > EAP header protection would not be likely to address such an
> > implementation bug since the MIC could not be computed until
> > the EAP packet was fully received, by which time the buffer
> > overflow would have already occurred.
> >
> >
> > In summary, I am not clear that EAP header protection as
> > described in Section 4.2.3 really brings much value beyond
> > addressing the EAP Type Code attack described in Section 6.3.
> > I would therefore recommend that this section be deleted, or
> > at least justified in more depth.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> _______________________________________________
> Emu mailing list
> Emu at ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
_______________________________________________
Emu mailing list
Emu at ietf.org
https://www.ietf.org/mailman/listinfo/emu
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
