From internet-drafts@ietf.org Sat Jan 5 01:05:05 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDBB021F8809; Sat, 5 Jan 2013 01:05:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.35 X-Spam-Level: X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxklMBaQ0R0u; Sat, 5 Jan 2013 01:05:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE8221F880E; Sat, 5 Jan 2013 01:04:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130105090456.24894.86296.idtracker@ietfa.amsl.com> Date: Sat, 05 Jan 2013 01:04:56 -0800 Cc: emu@ietf.org Subject: [Emu] I-D Action: draft-ietf-emu-crypto-bind-01.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 09:05:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the EAP Method Update Working Group of the IE= TF. Title : EAP Mutual Cryptographic Binding Author(s) : Sam Hartman Margaret Wasserman Dacheng Zhang Filename : draft-ietf-emu-crypto-bind-01.txt Pages : 24 Date : 2013-01-05 Abstract: As the Extensible Authentication Protocol (EAP) evolves, EAP peers rely increasingly on information received from the EAP server. EAP extensions such as channel binding or network posture information are often carried in tunnel methods; peers are likely to rely on this information. EAP has provided a facility that protects tunnel methods against man-in-the-middle attacks. However, cryptographic binding focuses on protecting the server rather than the peer. This memo explores attacks possible when the peer is not protected from man-in-the-middle attacks and recommends mutual cryptographic binding, a new form of cryptographic binding that protects both peer and server along with other mitigations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-emu-crypto-bind-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-emu-crypto-bind-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hzhou@cisco.com Mon Jan 28 12:55:06 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C3F21F88A9 for ; Mon, 28 Jan 2013 12:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V24cierK3Zw8 for ; Mon, 28 Jan 2013 12:55:05 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 52CBF21F886D for ; Mon, 28 Jan 2013 12:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34092; q=dns/txt; s=iport; t=1359406502; x=1360616102; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=+k1zKKI/YP7kBZh49zQ9PTfglaxaLP0b1B2m+VjMUFM=; b=OHrzYym9rbOEmIklxr1qbXmCqdnHRdauzf3upDQqF7gzbbqZrmB1G2r1 DO5TzXxh4TV+kKm74C3nZzIYIgELdlc92+8YeZ62WgtsXkVcBubc/ygmr pKiV28Hw+uzZ7ip0OcYcA2QmUpQt0UyQRY3/BD0hNcuSL3hzsdwgUPw3f A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAK7kBlGtJV2d/2dsb2JhbAA7CYJIvA4Wc4IeAQEBBC1MEgEIDgMDAQEBCw4IAQY5FAkIAgQOBQiICcAujH8SE1qCRmEDplWCd4Ik X-IronPort-AV: E=Sophos;i="4.84,554,1355097600"; d="scan'208,217";a="169468649" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 28 Jan 2013 20:55:01 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0SKt1Fj025599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jan 2013 20:55:01 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.10]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Mon, 28 Jan 2013 14:55:01 -0600 From: "Hao Zhou (hzhou)" To: Jim Schaad Thread-Topic: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00 Thread-Index: AQHNolcnsIvA7junTwesvqtA+uoKMpfq4a6AgHUd3gA= Date: Mon, 28 Jan 2013 20:55:00 +0000 Message-ID: <645B00545719594A88ADF4221831FD381FD551@xmb-rcd-x14.cisco.com> In-Reply-To: <035201cdc2e0$e8b19f30$ba14dd90$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.130.27.58] Content-Type: multipart/alternative; boundary="_000_645B00545719594A88ADF4221831FD381FD551xmbrcdx14ciscocom_" MIME-Version: 1.0 Cc: "emu@ietf.org" Subject: Re: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 20:55:06 -0000 --_000_645B00545719594A88ADF4221831FD381FD551xmbrcdx14ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Jim: Sorry for the late response. Will address all of them in the new draft. Ind= ividual comments inline below. Thanks. From: Jim Schaad > Date: Wednesday, November 14, 2012 10:25 PM To: Cisco Employee > Cc: "emu@ietf.org" > Subject: RE: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00 From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com] Sent: Thursday, October 04, 2012 10:39 AM To: Jim Schaad Cc: emu@ietf.org Subject: Re: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00 Jim: Thanks very much for your detailed review. Please see the comments below. W= e will respond to your other emails shortly. On 9/28/12 9:18 PM, "Jim Schaad" > wrote: 1. In section 3.2.3, it says that a new PAC can be requested after a full TLS handshake. Can one be requested following an abbreviated handshake? Or do you just re-use the existing PAC? [HZ] RFC5077 does not specify that client can request a new ticket after sending the TLS ticket, if the client is resuming a session using the session ticket, then it cannot request a new session ticket based on resumed session. We will add some language to clarify that it is not allowed. [JLS] I am not currently seeing this text. [HZ] Sorry, we missed that. Will add to Draft 05. 3. Section 3.4 - Is it possible to have multiple server ids after the authentication - one from the tunnel and others from the inner EAP methods. I realize that most EAP methods don't send a sender id, but some (IBAKE for example) currently do. Also, the client might have an idea of what the sender id is from configuration. If so, do these all need to get exported as server-id values? [HZ] Good catch. We will add a sentence similar to peer-ID, where multiple server IDs need to be exported. [JLS] The text for this is potentially confusing. Identity types are curre= ntly only defined for peer identities and not for server identities. [HZ] Good catch again, Will fix it. 5. In section 3.6.1 - Is the restart only an issue for fatal alerts, or is it a problem for all alerts? [HZ] Restart is only allowed for non-fatal alerts, per TLS RFC. "Upon transmission or receipt of a fatal alert message, both parties immediately = close the connection.", so restart is not desired in this case. We will clarify that restart is only allowed in non-fatal alert cases. [JLS] I don=92t currently see this text modification. [HZ] Will add that now. 8. In section 3.8 - I have the following questions a) In the text "The request MAY be issued", I don't understand the MAY at this point. Is it supposed to say that the request can be issued either before or after the authentication has finished, or is it saying that the peer has the option of issuing or not issuing the request, but must wait until the authentication level has been reached? [HZ] It's the later. How about add "only" in front "after the peer has determined that..."? [JLS] yes this deals with the main problem. I would suggest that the sente= nce this is included in be review for grammar. [HZ] Ok, will remove "if an inner EAP authentication occurs to ensure that = the TLS tunnel's integrity is Intact" from the sentence to make it parses b= etter and more accurate. 15. Section 4.2.3 - I assume that there should only be one Identity-Type TLV in a TEAP packet. Should a request for authentication be present in the packet as well? If multiple are allowed then information about how to treat this should be included. What should the peer respond with if it does have an identity of the type? This is not explicitly stated. [HZ] That's correct, only one Identity-Type TLV is allowed.The requested Id= entity type MUST comes with an EAP request or Basic-Password-Auth-Req. If the peer has the requested identity type, it should send back the same i= dentity type TLV in the response. We missed this and will add this clarific= ation. [JLS] I don=92t know that text exists to say that the MUST in the second s= entence is true. [HZ] Will add that sentence now. 18. Section 4.2.8 - Do we need to talk about the question of having some Vender TLVs be marked as mandatory and others not. Are we using the same TLV structure with the same rules for mandatoriness. If the mandatory bit is set, does that mean that I need to recognize the vendor-id or all combinations of vender-id/Vender-TLV type? [HZ] Yes. If the mandatory bit is set on the Vendor-Speific TLV, then the p= eer need to recognize the vendor ID and all combination of the vendor TLVs.= The Vendor TLV format is up to the vendor to define, as specified by the c= urrent draft. [JLS] After looking at this I think that I disagree. If a Venter TLV is ma= rked as mandatory, then the vender ID needs to be recognized and you need u= nderstand how to deal with it. The vender should specify it=92s own mandat= ory requirements internally. So top level bit would not cover all combinat= ions of the vendor TLVs. [HZ] Sounds reasonable. Will change. --_000_645B00545719594A88ADF4221831FD381FD551xmbrcdx14ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <516CDB53230DFF4582B75287C4ADDCEE@cisco.com> Content-Transfer-Encoding: quoted-printable
Jim:

Sorry for the late response. Will address all of them in the new draft. Ind= ividual comments inline below. Thanks.

From: Jim Schaad <ietf@augustcellars.com>
Date: Wednesday, November 14, 2012 = 10:25 PM
To: Cisco Employee <hzhou@cisco.com>
Cc: "emu@ietf.org" <emu@ietf.= org>
Subject: RE: [Emu] Review of draft-= ietf-emu-eap-tunnel-method-00

 

 

From: Hao Zhou (hzhou) [mailto:hzhou@cisco.com]
Sent: Thursday, October 04, 2012 10:39 AM
To: Jim Schaad
Cc: emu@ietf.org
Subject: Re: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00

 

Jim:

 

Thanks very much for your detailed review. Please see the com= ments below. We will respond to your other emails shortly. =

 

On 9/28/12 9:18 PM, "Jim Schaad" <ietf@augustcellars.com> wrote:

 

1.  In section 3.2.3, it says that a new PAC can be= requested after a full

TLS handshake.  Can one be requested following an a= bbreviated handshake?

Or

do you just re-use the existing PAC?

[HZ] RFC5077 does not specify that client can request a new t= icket after

sending the TLS ticket, if the client is resuming a session u= sing the

session ticket, then it cannot request a new session ticket b= ased on

resumed session. We will add some language to clarify that it= is not

allowed.

 

[JLS] I am not currently seeing th= is text.

 [HZ] Sorry, we missed t= hat. Will add to Draft 05.

 

3.  Section 3.4 - Is it possible to have multiple s= erver ids after the

authentication - one from the tunnel and others from the inne= r EAP

methods.

I realize that most EAP methods don't send a sender id, but s= ome (IBAKE

for

example) currently do.  Also, the client might have= an idea of what the

sender id is from configuration.  If so, do these a= ll need to get exported

as server-id values?

[HZ] Good catch. We will add a sentence similar to peer-ID, w= here multiple

server ID= s need to be exported.

 

[JLS] The text for this is potentially confusing.  I= dentity types are currently only defined for peer identities and not for se= rver identities.

 [HZ] Good catch again, Will fix it.

 

5.  In section 3.6.1 - Is the restart only an issue= for fatal alerts, or

is

it a problem for all alerts?

[HZ] Restart is only allowed for non-fatal alerts, per TLS RF= C. "Upon

transmission or receipt of a fatal alert message, both p= arties immediately close the connection.", so restart is not desired

in this case. We will clarify that restart is only allowed in= non-fatal

alert cases.

 

[JLS] I don=92t currently see this= text modification.
[HZ] Will add that now.


 

8.  In section 3.8 - I have the following questions=

a) In the text "The request MAY be issued", I don't= understand the MAY at

this point.  Is it supposed to say that the request= can be issued either

before or after the authentication has finished, or is it say= ing that the

peer has the option of issuing or not issuing the request, bu= t must wait

until the authentication level has been reached?

[HZ] It's the later. How about add "only" in front = "after the peer has

determined that..."?

 

[JLS] yes this deals with the main= problem.  I would suggest that the sentence this is included in be re= view for grammar.
[HZ] Ok, will remove "if an inner EAP authentication occurs = to ensure that the TLS tunnel's integrity is Intact" from the sen= tence to make it parses better and more accurate.

 

 

15.  Section 4.2.3 - I assume that there should onl= y be one Identity-Type

TLV in a TEAP packet.  Should a request for authent= ication be present in

the

packet as well?  If multiple are allowed then infor= mation about how to

treat

this should be included.  What should the peer resp= ond with if it does

have

an identity of the type?  This is not explicitly st= ated.

[HZ] That's correct, only one Identity-Type TLV is allowed.Th= e requested Identity type  MUST comes with an EAP request or Basi= c-Password-Auth-Req. 

If the peer has the requested identity type, it should send b= ack the same identity type TLV in the response. We missed this and will add= this clarification.

 

[JLS]  I don=92t know that te= xt exists to say that the MUST in the second sentence is true.  <= /o:p>

[HZ] Will add that sentence n= ow. 

 

 

18. Section 4.2.8 - Do we need to talk about the question of = having some

Vender TLVs be marked as mandatory and others not.  = ;Are we using the same

TLV structure with the same rules for mandatoriness. &nb= sp;If the mandatory bit

is set, does that mean that I need to recognize the vendor-id= or all

combinations of vender-id/Vender-TLV type?<= /p>

[HZ] Yes. If th= e mandatory bit is set on the Vendor-Speific TLV, then the peer need to rec= ognize the vendor ID and all combination of the vendor TLVs. The Vendor TLV= format is up to the vendor to define, as specified by the current draft.

 

[JLS] After looking at this I thin= k that I disagree.  If a Venter TLV is marked as mandatory, then the v= ender ID needs to be recognized and you need understand how to deal with it.  The vender should specify it=92s own= mandatory requirements internally.  So top level bit would not cover = all combinations of the vendor TLVs.
[HZ] Sounds reasonable. Will change.

 

 

 --_000_645B00545719594A88ADF4221831FD381FD551xmbrcdx14ciscocom_-- From hzhou@cisco.com Tue Jan 29 08:57:20 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732AA21F85C0 for ; Tue, 29 Jan 2013 08:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFuoVtiVk6B8 for ; Tue, 29 Jan 2013 08:57:19 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6D11821F8573 for ; Tue, 29 Jan 2013 08:57:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4566; q=dns/txt; s=iport; t=1359478639; x=1360688239; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=SFHo54I40Q5YS2atjpHueRTqFdE0RyHFMBX1S7v0Ggg=; b=dsJYE98/4Y7kox7LaHrL8w0XjWT6bBya14GZ7ZJVcOAyqKTuD/xH1Waj C+OZvJ8gU0dbA3yq+P88QjL6QwFoo8jZBtOB3mrP94z5gxXUDgQFM9zIg vJMjaxNU+4ucJWJ8/9GGuztdv9Ka8+3MXuZQK5PztXjaNn4ONfbznSsG/ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMn+B1GtJV2b/2dsb2JhbABEvl4Wc4IeAQEBBAEBATc0FwYBCA4DBAEBAQoUCS4LFAkIAQEEARIIiAkMsH6QKgSNAxuDCmEDpliCd4FoBxcGGA X-IronPort-AV: E=Sophos;i="4.84,561,1355097600"; d="scan'208";a="169927226" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 29 Jan 2013 16:57:18 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0TGvIgo025446 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jan 2013 16:57:18 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.10]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 10:57:18 -0600 From: "Hao Zhou (hzhou)" To: Jim Schaad , "emu@ietf.org" Thread-Topic: [Emu] TEAP Comments Thread-Index: Ac29SRXkskWVRKzMRPiPcKK8JJox9wGWF0aADn89BwAAKusTgA== Date: Tue, 29 Jan 2013 16:57:18 +0000 Message-ID: <645B00545719594A88ADF4221831FD381FD9A7@xmb-rcd-x14.cisco.com> In-Reply-To: <645B00545719594A88ADF4221831FD381FD524@xmb-rcd-x14.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.130.27.58] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Emu] TEAP Comments X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 16:57:20 -0000 Jim: Thanks for the detailed review comments. Response inline below. Will try to submit a new rev with these changes soon. > >On 11/15/12 3:24 PM, "Jim Schaad" wrote: > >>Expanding on the issues so that you have full descriptions of the problem >>from the last message >> >>1. When either an EMSK or MSK is not present in the Crypto-Binding TLV, >>there is no way to indicate this. At the f2f it was said that this was >>going to be by setting it to all zeros. If this is the case, then it >>does >>need to be noted that there is a 1 in 2^n chance that it will signal the >>wrong thing leading to an error in binding being generated. It might be >>better to steal bits from the Sub-Type octet instead. >[HZ] We will add a flag bit in sub-type to indicate presence of EMSK >and/or MSK MAC. >> >>2. I find that I have probably not correctly understood when the S bit >>is >>set. I have been setting the S bit on all fragments (but not fragment >>responses) of the original Start request and Start response. I have >>since >>found text that says it is only sent from the server to the peer. It >>would >>be nice to have the one direction comment in the description of the flags >>as >>well (section 4.1) >[HZ] Will add a sentence to clarify. > >> >>3. I would like to have the description of the L bit in section 4.1 >>expanded to state the following: >> - It MUST be present for the first fragment of a fragmented message >> - It MUST NOT be present for any other message >> >>The first can be found in section 3.7 (if you hunt) but the second is not >>stated anywhere >[HZ] Will add that. > >> >>4. I would like to have the description of the O bit in section 4.1 >>expanded to state the following: >> - It MUST be present only in the initial request and response messages. >> - If the initial message is fragmented, then it MUST be present only on >>the >>first fragment. >[HZ] Looks ok. Will add. > >> >>5. I don't think point 3 below needs expansion, but I may be too close >>to >>it. If you disagree please let me know. [HZ] Sounds reasonable. Will add an error TLV with new error code for the signaling mechanism. >> >>Jim >> >> >>> -----Original Message----- >>> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of >>> Jim Schaad >>> Sent: Wednesday, November 07, 2012 4:48 PM >>> To: emu@ietf.org >>> Subject: [Emu] TEAP Comments >>>=20 >>> I just wanted to make sure that the mail list had at least the basics >>>of >>what I >>> mentioned in the f2f today >>>=20 >>> 1. The document does not appear to have an indicator that the EMSK was >>>or >>> was not used to generate a confirmation value. I have not done a final >>check >>> that this is true but I did try and find it a couple of times >>>=20 >>> 2. The flags on the outer packet need to be defined a bit better. >>> a) is the S bit set only on the first fragment of the first message >>>or >>on all >>> fragments of the first message >>> b) are the two length bits set only on the first message in a >>fragment >>> sequence or can they be on any of the messages in a fragment sequence >>> (but the values must then be the same in all fragment messages) >>> c) Can the O bit be set only in the first piece of a fragment, or >>could it be in >>> the last one without being in any previous one >>> d) Should the L bit never be set on a non-fragmented message since >>>it >>is >>> redundant >>>=20 >>> 3. There needs to be a signaling mechanism when running inner EAP >>> messages to say that >>> a) that this is a reliable transport and therefore there should be >>no-retries >>> b) If a packet is dropped on the floor by somebody, then some type of >>> signaling mechanism needs to be created to signal this to the other >>>party. >>> Also there should be text saying that re-sending the message does not >>> necessarily make sense as the packet would probably just be re-dropped >>> again >>> c) There needs to be some type of policy on the server for what to do >>for >>> either failing or continuing a validation - for example should a new >>>EAP >>> method be tried in this case. > > >>>=20 >>> Jim >>>=20 >>>=20 >>> _______________________________________________ >>> Emu mailing list >>> Emu@ietf.org >>> https://www.ietf.org/mailman/listinfo/emu >> >>_______________________________________________ >>Emu mailing list >>Emu@ietf.org >>https://www.ietf.org/mailman/listinfo/emu >