From aland@deployingradius.com Thu Nov 1 06:08:24 2012 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 743F921F8988 for ; Thu, 1 Nov 2012 06:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 UvM5rCY04WTZ for ; Thu, 1 Nov 2012 06:08:23 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id EB03721F89D7 for ; Thu, 1 Nov 2012 06:07:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 3FCBE2240E34 for ; Thu, 1 Nov 2012 14:07:43 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtQLeVrAK3Hp for ; Thu, 1 Nov 2012 14:07:41 +0100 (CET) Received: from Thor.local (unknown [78.251.142.69]) by power.freeradius.org (Postfix) with ESMTPSA id CDDFA2240AAA for ; Thu, 1 Nov 2012 14:07:40 +0100 (CET) Message-ID: <5092741B.9080603@deployingradius.com> Date: Thu, 01 Nov 2012 14:07:39 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "emu@ietf.org" Content-Type: multipart/mixed; boundary="------------060400020601070402080408" Subject: [Emu] Help the NomCom 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: Thu, 01 Nov 2012 13:08:24 -0000 This is a multi-part message in MIME format. --------------060400020601070402080408 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Message forwarded from the WG-chairs list. --------------060400020601070402080408 Content-Type: message/rfc822; name="CORRECTION: Help the NomCom.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="CORRECTION: Help the NomCom.eml" Return-Path: Received: from power.freeradius.org ([unix socket]) by power.freeradius.org (Cyrus v2.4.12-Debian-2.4.12-2) with LMTPA; Thu, 01 Nov 2012 13:58:32 +0100 X-Sieve: CMU Sieve 2.4 Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id A9AED2240E34 for ; Thu, 1 Nov 2012 13:58:32 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Authentication-Results: power.freeradius.org (amavisd-new); dkim=pass header.i=@ietf.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucHZs0AmnfCl for ; Thu, 1 Nov 2012 13:58:28 +0100 (CET) Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=64.170.98.30; helo=mail.ietf.org; envelope-from=wgchairs-bounces@ietf.org; receiver=aland@deployingradius.com Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by power.freeradius.org (Postfix) with ESMTP id 8BF7022402B5 for ; Thu, 1 Nov 2012 13:58:27 +0100 (CET) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A640021F8FDE; Thu, 1 Nov 2012 05:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1351774687; bh=MSzgXSp0azdYwxH5Nl587xBhWauT04SHzaodq0qzLUs=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:From:To: Subject:Message-ID:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Sender; b=vodrbbhgbIHFmDCkALCFFh6NyJZLGhwvW21yxltPDuiaWx60IrdLq/toxd4RN2neH Y5Iv1jBNJSXvQ5YNxsFtDRTx2KBYpodd3cJJpEDr5GhgnnB+28F2D3MlNVofcKRLhU lrc69FCL3n2ADbpFVYtQmgpVLMf66bgmrgK+HbvI= X-Original-To: wgchairs@ietfa.amsl.com Delivered-To: wgchairs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404A321F8870 for ; Thu, 1 Nov 2012 05:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 tk8L6bxcJ8MY for ; Thu, 1 Nov 2012 05:17:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B3E21F8862 for ; Thu, 1 Nov 2012 05:17:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: NomCom Chair To: Working Group Chairs Subject: CORRECTION: Help the NomCom X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> Date: Thu, 01 Nov 2012 05:17:22 -0700 X-BeenThere: wgchairs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working Group Chairs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: wgchairs-bounces@ietf.org Errors-To: wgchairs-bounces@ietf.org I sent a message several hours ago requesting that you help and make = your working group aware that the NomCom is looking for input from the = community. This message had a minor error. The NomCom needs to = receive community input by November 11, 2012. = The full text of the corrected message is below --------------------------------------------------- The IETF Nominations Committee (NomCom) continues to seek input from the IETF Community. The NomCom would greatly appreciate any help you could provide in making members of your working group aware of ways in which they can provide valuable feedback to the NomCom. In order to ensure that your input is received in time to be useful, the = NomCom needs to receive community feedback on or before Sunday, November 11. The final list of candidates (as per RFC 5680) that the NomCom is = considering for open positions can be found at: = https://www.ietf.org/group/nomcom/2012/input/ The NomCom will be holding office hours during IETF 85, Monday- Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes = comments on specific individuals, as well as general feedback related to = any of the positions that NomCom is considering. Note: A list of leadership positions that the NomCom is considering can be = found at: https://www.ietf.org/group/nomcom/2012/ If the NomCom office hours are inconvenient for you or if you cannot = attend IETF 85, the NomCom is happy to take community input via email = to nomcom12 at ietf.org. Additionally, the NomCom is happy to arrange a = meeting outside of office hours, just send us email and we can set = something up. Comments on specific candidates can also be provided to the NomCom via the web feedback tool: = https://www.ietf.org/group/nomcom/2012/input/ Thank you for your help, - Matt Lepinski nomcom-chair at ietf.org --------------060400020601070402080408-- From ietf@augustcellars.com Wed Nov 7 16:48:24 2012 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 5181B21F8736 for ; Wed, 7 Nov 2012 16:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 eTCEVTIW6NUN for ; Wed, 7 Nov 2012 16:48:23 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id D9C6C21F872E for ; Wed, 7 Nov 2012 16:48:23 -0800 (PST) Received: from Philemon (dhcp-469b.meeting.ietf.org [130.129.70.155]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 5116338F0D for ; Wed, 7 Nov 2012 16:48:22 -0800 (PST) From: "Jim Schaad" To: Date: Wed, 7 Nov 2012 19:48:14 -0500 Message-ID: <006901cdbd4a$bd92da80$38b88f80$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac29SRXkskWVRKzMRPiPcKK8JJox9w== Content-Language: en-us Subject: [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: Thu, 08 Nov 2012 00:48:24 -0000 I just wanted to make sure that the mail list had at least the basics of what I mentioned in the f2f today 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 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 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. Jim From ietf@augustcellars.com Wed Nov 14 19:26:00 2012 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 E94B61F0C69 for ; Wed, 14 Nov 2012 19:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 OnR2MyjMG4yF for ; Wed, 14 Nov 2012 19:25:58 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D64021F8200 for ; Wed, 14 Nov 2012 19:25:58 -0800 (PST) Received: from Philemon (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id D94242C9FE; Wed, 14 Nov 2012 19:25:55 -0800 (PST) From: "Jim Schaad" To: "'Hao Zhou \(hzhou\)'" References: <645B00545719594A88ADF4221831FD3813D697@xmb-rcd-x14.cisco.com> In-Reply-To: <645B00545719594A88ADF4221831FD3813D697@xmb-rcd-x14.cisco.com> Date: Wed, 14 Nov 2012 19:25:41 -0800 Message-ID: <035201cdc2e0$e8b19f30$ba14dd90$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0353_01CDC29D.DA931A20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFffQCp54UCtsWCBlsjsXo3TochOpjFQLWQ Content-Language: en-us 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: Thu, 15 Nov 2012 03:26:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0353_01CDC29D.DA931A20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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. We 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. 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 currently only defined for peer identities and not for server identities. 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't currently see this text modification. 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 sentence this is included in be review for grammar. 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 Identity 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 identity type TLV in the response. We missed this and will add this clarification. [JLS] I don't know that text exists to say that the MUST in the second sentence is true. 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 peer 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 current draft. [JLS] After looking at this I think that I disagree. If a Venter TLV is marked as mandatory, then the vender ID needs to be recognized and you need understand how to deal with it. The vender should specify it's own mandatory requirements internally. So top level bit would not cover all combinations of the vendor TLVs. ------=_NextPart_000_0353_01CDC29D.DA931A20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

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. 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 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.

 

 

3.  = ;Section 3.4 - Is it possible to have multiple server ids after = the

authenticatio= n - 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 currently only defined for peer identities and not for server = identities.

 

 

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’t currently see this text = modification.

 

 

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 sentence this is included in be review for = grammar.

 

 

15. &nbs= p;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 Identity = type  MUST comes with an EAP request = or Basic-Password-Auth-Req. 

<= p class=3DMsoNormal>If the peer = has the requested identity type, it should send back the same identity = type TLV in the response. We missed this and will add this = clarification.

 

[JLS]  I don’t know that text exists to say that the MUST = in the second sentence is true.  

 

 

 

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 peer 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 current draft.

 

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

 =

 

------=_NextPart_000_0353_01CDC29D.DA931A20-- From ietf@augustcellars.com Thu Nov 15 12:24:16 2012 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 C5BA221F8604 for ; Thu, 15 Nov 2012 12:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 55YtFejnKcTc for ; Thu, 15 Nov 2012 12:24:14 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9531121F85FA for ; Thu, 15 Nov 2012 12:24:13 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 5499B2CA17 for ; Thu, 15 Nov 2012 12:24:13 -0800 (PST) From: "Jim Schaad" To: References: <006901cdbd4a$bd92da80$38b88f80$@augustcellars.com> In-Reply-To: <006901cdbd4a$bd92da80$38b88f80$@augustcellars.com> Date: Thu, 15 Nov 2012 12:24:05 -0800 Message-ID: <004401cdc36f$28ed7810$7ac86830$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHfbp648C1tTo9Is6z3KY0OK3gHLZfH2dzg Content-Language: en-us 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: Thu, 15 Nov 2012 20:24:16 -0000 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. 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) 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 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. 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. 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 > > I just wanted to make sure that the mail list had at least the basics of what I > mentioned in the f2f today > > 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 > > 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 > > 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. > > Jim > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu