Re: [Emu] [abfab] GSS-EAP: do we ned an identity request
Hi Sam: El 19/10/2011, a las 00:23, Sam Hartman escribió: Rafa == Rafa Marin Lopez r...@um.es writes: Rafa Hi Sam: El 18/10/2011, a las 18:55, Sam Hartman escribió: Rafa == Rafa Marin Lopez r...@um.es writes: Rafa Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribió: I think I may have been unclear in what I was proposing. I'm proposing that the peer send its identity in the first message (*) and that the server gets to respond with type 4 or greater (a specific EAP method). Rafa Sending its identity does not mean that it must be carried in Rafa the EAP response/identity. In fact what I suggested is to Rafa carry the identity in the first message but not contained in Rafa the EAP response/identity. OK. Why not carry it in the EAP response/identity? It seems easier than developing new encoding. Rafa Basically EAP is a lock-step protocol where it is required to Rafa get a request to obtain a response (in the peer side)). So the Rafa EAP peer state machine implementing the EAP standard protocol Rafa will react after receiving an EAP request. So I see two Rafa options: either you hack the EAP peer state machine to return Rafa an EAP response/identity without receiving any EAP Rafa request/identity (this violates the standard and so we need Rafa to hack the EAP peer state machine) Or the initiator synthesizes a request and feeds it to the peer's state machine. Yes, this is another option, though I don't like either. The reason is simple. AFAIK, the standard EAP does not say anything about a EAP lower-layer synthesizing a request (which sounds like another type of hack). EAP requests are sent by the authenticator. This is what the standard says. IN our implementation, even if the IETF decides on an an alternate encoding for the identity, we'll end up synthesizing an identity request and doing something with the identity response. With a standard EAP library that is lock-step in the manner you describe, it's far easier to produce a synthetic identity request in the initiator than to hack the state machine or do anything else. As I said synthesizing an EAP request is another type of hack, because the EAP protocol does not work like that. We have a RFC 3748 and RFC 5247 where the EAP protocol is defined. I believe it would be good if we follow the standards. Think of it this way. In GSS-EAP, the identity request is generated by a party very close to the initiator. EAP already supports the identity request being generated by a different party than the actual EAP messages. Why does it matter whether the request comes from inside the peer or from a NAS? Regarding this, you need to think about the mode independence property of EAP where: As far as the EAP peer is concerned, its conversation with the EAP authenticator, and all consequences of that conversation, are identical, regardless of the authenticator mode of operation. In other words, under peer standpoint, all EAP requests are coming from the EAP authenticator (the peer does not know and do not care if there is a backend EAP server or it is integrated with the authenticator). Rafa or directly at GSS-API Rafa level you create a EAP response/identity and include the Rafa identity (which seems weird taking into account that we have Rafa an EAP stack in charge of creating EAP messages) But if you don't create an EAP response/identity on the initiator you probably do have to do it on the acceptor to trigger AAA to use EAP. I don't think you need to do that. As I explained in the previous e-mail, in RADIUS EAP (RFC 3579) you can find this text: Rather than sending an initial EAP-Request packet to the authenticating peer, on detecting the presence of the peer, the NAS MAY send an Access-Request packet to the RADIUS server containing an EAP-Message attribute signifying EAP-Start. The RADIUS server will typically respond with an Access-Challenge containing EAP-Message attribute(s) encapsulating an EAP-Request/Identity (Type 1). However, an EAP-Request for an authentication method (Type 4 or greater) can also be sent by the server. EAP-Start is indicated by sending an EAP-Message attribute with a length of 2 (no data). In other words, once the acceptor knows the peer's identity can send that EAP-start message in a RADIUS Access-Challenge. Moreover it should include the user-name in the request. With that, the RADIUS EAP server should start the EAP method selected for that peer. Rafa Personally, I do not like either (considering the standard RFC Rafa 3748). So, I would prefer to define a subtoken for this. We can do that. It means faking up an identity response on the acceptor. But that is certainly not a big deal. As explained, you do not need to fake up any identity response on the acceptor. Just follow what RFC 3579 says. --Sam
Re: [Emu] [abfab] GSS-EAP: do we ned an identity request
Hi again: I have been thinking again about the situation created with sending an EAP response/id without the authenticator sending EAP request/id and I realized that it may be even worse in the authenticator side. Basically, the authenticator will see an EAP response message which does not answer to any EAP request sent. Best regards. El 19/10/2011, a las 11:45, Rafa Marin Lopez escribió: Please replace RADIUS Access-Challenge by RADIUS Access-Request in the sentence of my previous e-mail In other words, once the acceptor knows the peer's identity can send that EAP-start message in a RADIUS Access-Challenge... Best regards. El 19/10/2011, a las 11:28, Rafa Marin Lopez escribió: Hi Sam: El 19/10/2011, a las 00:23, Sam Hartman escribió: Rafa == Rafa Marin Lopez r...@um.es writes: Rafa Hi Sam: El 18/10/2011, a las 18:55, Sam Hartman escribió: Rafa == Rafa Marin Lopez r...@um.es writes: Rafa Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribió: I think I may have been unclear in what I was proposing. I'm proposing that the peer send its identity in the first message (*) and that the server gets to respond with type 4 or greater (a specific EAP method). Rafa Sending its identity does not mean that it must be carried in Rafa the EAP response/identity. In fact what I suggested is to Rafa carry the identity in the first message but not contained in Rafa the EAP response/identity. OK. Why not carry it in the EAP response/identity? It seems easier than developing new encoding. Rafa Basically EAP is a lock-step protocol where it is required to Rafa get a request to obtain a response (in the peer side)). So the Rafa EAP peer state machine implementing the EAP standard protocol Rafa will react after receiving an EAP request. So I see two Rafa options: either you hack the EAP peer state machine to return Rafa an EAP response/identity without receiving any EAP Rafa request/identity (this violates the standard and so we need Rafa to hack the EAP peer state machine) Or the initiator synthesizes a request and feeds it to the peer's state machine. Yes, this is another option, though I don't like either. The reason is simple. AFAIK, the standard EAP does not say anything about a EAP lower-layer synthesizing a request (which sounds like another type of hack). EAP requests are sent by the authenticator. This is what the standard says. IN our implementation, even if the IETF decides on an an alternate encoding for the identity, we'll end up synthesizing an identity request and doing something with the identity response. With a standard EAP library that is lock-step in the manner you describe, it's far easier to produce a synthetic identity request in the initiator than to hack the state machine or do anything else. As I said synthesizing an EAP request is another type of hack, because the EAP protocol does not work like that. We have a RFC 3748 and RFC 5247 where the EAP protocol is defined. I believe it would be good if we follow the standards. Think of it this way. In GSS-EAP, the identity request is generated by a party very close to the initiator. EAP already supports the identity request being generated by a different party than the actual EAP messages. Why does it matter whether the request comes from inside the peer or from a NAS? Regarding this, you need to think about the mode independence property of EAP where: As far as the EAP peer is concerned, its conversation with the EAP authenticator, and all consequences of that conversation, are identical, regardless of the authenticator mode of operation. In other words, under peer standpoint, all EAP requests are coming from the EAP authenticator (the peer does not know and do not care if there is a backend EAP server or it is integrated with the authenticator). Rafa or directly at GSS-API Rafa level you create a EAP response/identity and include the Rafa identity (which seems weird taking into account that we have Rafa an EAP stack in charge of creating EAP messages) But if you don't create an EAP response/identity on the initiator you probably do have to do it on the acceptor to trigger AAA to use EAP. I don't think you need to do that. As I explained in the previous e-mail, in RADIUS EAP (RFC 3579) you can find this text: Rather than sending an initial EAP-Request packet to the authenticating peer, on detecting the presence of the peer, the NAS MAY send an Access-Request packet to the RADIUS server containing an EAP-Message attribute signifying EAP-Start. The RADIUS server will typically respond with an Access-Challenge containing EAP-Message attribute(s) encapsulating an EAP-Request/Identity (Type 1). However, an EAP-Request for an authentication method (Type 4 or greater) can also be sent by the server. EAP-Start is indicated by sending an EAP-Message attribute with a
Re: [Emu] [abfab] GSS-EAP: do we ned an identity request
Rafa == Rafa Marin Lopez r...@um.es writes: Rafa Hi Sam: El 18/10/2011, a las 18:55, Sam Hartman escribió: Rafa == Rafa Marin Lopez r...@um.es writes: Rafa Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribió: I think I may have been unclear in what I was proposing. I'm proposing that the peer send its identity in the first message (*) and that the server gets to respond with type 4 or greater (a specific EAP method). Rafa Sending its identity does not mean that it must be carried in Rafa the EAP response/identity. In fact what I suggested is to Rafa carry the identity in the first message but not contained in Rafa the EAP response/identity. OK. Why not carry it in the EAP response/identity? It seems easier than developing new encoding. Rafa Basically EAP is a lock-step protocol where it is required to Rafa get a request to obtain a response (in the peer side)). So the Rafa EAP peer state machine implementing the EAP standard protocol Rafa will react after receiving an EAP request. So I see two Rafa options: either you hack the EAP peer state machine to return Rafa an EAP response/identity without receiving any EAP Rafa request/identity (this violates the standard and so we need Rafa to hack the EAP peer state machine) Or the initiator synthesizes a request and feeds it to the peer's state machine. IN our implementation, even if the IETF decides on an an alternate encoding for the identity, we'll end up synthesizing an identity request and doing something with the identity response. With a standard EAP library that is lock-step in the manner you describe, it's far easier to produce a synthetic identity request in the initiator than to hack the state machine or do anything else. Think of it this way. In GSS-EAP, the identity request is generated by a party very close to the initiator. EAP already supports the identity request being generated by a different party than the actual EAP messages. Why does it matter whether the request comes from inside the peer or from a NAS? Rafa or directly at GSS-API Rafa level you create a EAP response/identity and include the Rafa identity (which seems weird taking into account that we have Rafa an EAP stack in charge of creating EAP messages) But if you don't create an EAP response/identity on the initiator you probably do have to do it on the acceptor to trigger AAA to use EAP. Rafa Personally, I do not like either (considering the standard RFC Rafa 3748). So, I would prefer to define a subtoken for this. We can do that. It means faking up an identity response on the acceptor. But that is certainly not a big deal. --Sam ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [abfab] GSS-EAP: do we ned an identity request
With a standard EAP library that is lock-step in the manner you describe, it's far easier to produce a synthetic identity request in the initiator than to hack the state machine or do anything else. Think of Right, I actually tried to hack the state machine as described in a very early iteration and, with the library we used, it just didn't work. -- Luke ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
Hi. I've added PANA (pre-authentication). I wonder about the whole lower layer table. Why is it important to distinguish PANA with pre-auth from pana without pre-auth? Why is it important to distinguish 802.11 wpa, wpa2 and wpa2 with pre-auth? I'd appreciate it if someone who cared about network access told me what to do here:-) ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] I-D Action: draft-ietf-emu-chbind-10.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update Working Group of the IETF. Title : Channel Binding Support for EAP Methods Author(s) : Sam Hartman T. Charles Clancy Katrin Hoeper Filename: draft-ietf-emu-chbind-10.txt Pages : 30 Date: 2011-10-19 This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the lying NAS as well as the lying provider problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-emu-chbind-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-emu-chbind-10.txt ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Submitted 10
I believe I've addressed all of Alan's comments with the exception of removing the RADIUS diagram from 5.3. Thanks Alan for the comments! --Sam ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
Hi Sam, On Wed, October 19, 2011 12:59 pm, Sam Hartman wrote: Hi. I've added PANA (pre-authentication). I wonder about the whole lower layer table. Why is it important to distinguish PANA with pre-auth from pana without pre-auth? Why is it important to distinguish 802.11 wpa, wpa2 and wpa2 with pre-auth? I'd appreciate it if someone who cared about network access told me what to do here:-) You can collapse wpa, wpa2 and wpa2 with preauth. wpa and wpa2 are both actually trademarked terms of the Wi-Fi Alliance so they should probably not be in an IANA registry anyway. Regardless, though, they all do the same thing by conveying the same type of information in the same way. 802.11s specifies a password-based authentication scheme that does not use EAP so there doesn't seem to be a reason to define an EAP lower layer for 802.11s. 802.11r does things a little differently-- a key hierarchy is built up and keys are distributed hither and yon-- so it might be good to channel bind that stuff but 802.11r has been rolled into the 802.11 standard (there is no stand-alone reference for 802.11r, by the way) and can be dealt with as just 802.11. All the information elements that specify that 11r-specific stuff is being communicated are defined by 802.11's Assigned Number Authority and their communication is done in the same fashion as plain-jane 802.11 (aka wpa and wpa2). If information elements for 802.11r are included in the 802.11 channel binding data then it means the session is going to be used for 802.11r-type stuff. Values 4-8 in the table in section 11.1 can all be combined into a single value named 802.11 with a reference to IEEE 802.11-2007. regards, Dan. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
Hi Sam, Please see my comments below. (2011/10/18 23:02), Sam Hartman wrote: Yoshihiro == Yoshihiro Ohbayoshihiro.o...@toshiba.co.jp writes: Yoshihiro [1] As far as I understand, the method-based channel Yoshihiro binding is not applicable to ERP. For completeness of Yoshihiro the specification it may be good to add some text to Yoshihiro clarify this. I'd welcome suggestions. I'm not really familiar with ERP. OK. My suggestion is to modify the following text in Section 4.2: For many deployments, changing all the NASes is expensive and adding channel binding support to enough EAP methods to meet the goals of the deployment will be cheaper. However for deployment of new equipment, or especially deployment of a new lower layer technology, changing the NASes may be cheaper than changing EAP methods. Especially if such a deployment needed to support a large number of EAP methods, sending channel bindings in the secure association protocol might make sense. to: For many deployments, changing all the NASes is expensive and adding channel binding support to enough EAP methods to meet the goals of the deployment will be cheaper. However for deployment of new equipment, or especially deployment of a new lower layer technology, changing the NASes may be cheaper than changing EAP methods. Especially if such a deployment needed to support a large number of EAP methods, sending channel bindings in the secure association protocol might make sense. Sending channel bindings in the secure association protocol can work even with ERP [RFC5296] in which previously established EAP key material is used for the secure association protocol without carrying out any EAP method during re-authentication. Yoshihiro [3] Probably this was discussed in the WG, but I want to Yoshihiro understand the motivation for the namespace in Channel Yoshihiro Binding Encoding because it seems to be a hard Yoshihiro requirement if the peer has to know what namespace (or Yoshihiro protocol) is being used between an EAP authenticator and Yoshihiro EAP server. Also, in some case, the channel binding Yoshihiro operation may be performed with a standalone Yoshihiro authenticator since, due to EAP's mode independence Yoshihiro property, the peer does not know whether the Yoshihiro authenticator it is talking to is a pass-through Yoshihiro authenticator or a stand-alone one. What namespace Yoshihiro should be used with a standalone authenticator? The namespace ID simply names where the attribute comes from. If you are describing some value that is available in a RADIUS ID, then you should use the RADIUS namespace. The EAP server (which as you point out may be the authenticator) is responsible for matching up that information in whatever form it has it. For attributes available both in the diameter and RADIUS namespaces I'd expect some lower layer document to describe which one to use regardless of whether an AAA protocol is in use or which one is in use. So it seems there is a requirement for lower-layer protocols or profiles to describe about the channel binding namespace. Shouldn't such a requirement be explicitly mentioned in this document? Yoshihiro Ohba ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Comments on the eap-tunnel-method-00 draft
-Original Message- From: Hao Zhou [mailto:hz...@cisco.com] Sent: Wednesday, October 19, 2011 12:31 PM To: Jim Schaad; draft-ietf-emu-eap-tunnel-met...@tools.ietf.org Cc: emu@ietf.org Subject: Re: [Emu] Comments on the eap-tunnel-method-00 draft Jim: Thanks for reviewing the draft in detail and comments provided. Please see my response inline below. On 10/17/11 6:08 PM, Jim Schaad i...@augustcellars.com wrote: I have gathered these comments over time and therefore some of them are not fully fleshed out. If you have any questions I will try and reconstruct my ideas at the time. Jim Version Negotiation - terminate the conversation - w or w/o a fail? Edge case - what if peer only supports a higher version than the server supports? NAK? [HZ] It depends. Server might want to proceed with other EAP type negotiation by proposing a different EAP type, or terminate the conversation with an EAP-Failure. I will clarify that in the next rev. Yes - but in this case I would expect a NAK from the client - possibly proposing other methods. Is this correct? EAP Server Name Checking - On what basis does the client accept or not accept the EAP server name?You are suggesting that it is signed by a CA controlling the intended domain, but what does this mean? Are you suggesting that the CA should have a DNS subject alt name in it for the domain in question? [HZ] It's up to client's policy, especially if the server cert is issued by a public CA. Client needs not only verify that the server cert presented is a valid cert signed by the trusted CA, but also the server name presented in the cert is matching the domain it tried to authenticate with. A FQDN in the CN or SAN would be a way to do it. If no embedded EAP methods run, then no crypto check and thus no version # checking is done. [HZ] That's true. Ok - this would be in violation of the last paragraph in section 3.1 which says that the version numbers MUST be done. Also no checking done if only one inner EAP method is used as this only sends the Result TLV and not the Crypto-Binding TLV [HZ] That's not true. Crypto-binding would still be exchanged with Result TLV. Actually using of the Result TLV in lieu of IM-Result TLV is for legacy reason in EAP-FAST, which could be removed in next rev since we are designing a new EAP method. Please tell me where it says this is done. All I can see is that one CAN send intermediate-result, result and crypto-binding TLVs in the same message. (Unless of course only one is sent in which case the Intermediate-Reuslt TLV MUST NOT be sent). However these is nothing that says that the Crypto-binding TLV would be sent after the first and only EAP method - or indeed after a sequence of EAP methods. 'serially in a sequence' is redundant - section 3.3.1 [HZ] Ok. The text is trying to distinguish from running multiple EAP methods in parallel. Not only does it not allow initiating multiple EAP methods in parallel, it requires that they not be running in parallel. This is a more strict condition [HZ] For simplicity, otherwise implementation would need to trace when the 1st method finishes and applies the key from the authentication to the crypto-binding. Supporting them in complete sequence makes it simpler and securer, as 2nd method might not be safe to run if the crypto-binging after 1st method fails. Do you ever expect a version to allow multiple EAP sequences to be run at the same time? If not then just the statement that they MUST be executed serially is probably sufficient. Para #3 - can the peer return an error and treat the failure of a specific EAP method as a total failure for the overall process - or at least recommend that it should be an overall failure? [HZ] Yes it can. It is actually described in Section 3.6.2, peer can send up some Fatal Error TLV and Result TLV to indicate the end. Ok - either I don't see the text or my comment is not sufficiently clear. Consider: Client is running EAP-BLAH and returns inside of the EAP-BLAH method a failure. If the client wants an overall failure rather than leaving it up to the server, does it send both the Result TLV failure and the EAP-Message w/ the failure - or just the result TLV failure or is this not reasonable for the client? Confused messages in 3.3.1 and 3.3.3 about sending intermediate results and final results at the same time. Specifically 3.3.1 says MUST NOT for one inner EAP method, but text is not reflected in section 3.3.3 [HZ] I think we can change to always send IM result after each inner EAP method, if only one inner method, then Result TLV could be sent as well. See explanation above. Conflict between 3.3.3 and security considerations (7.5) about sending a different value in the Result TLV and the clear result in the event of not doing a Request-Action TLV from the client. Is the server required to
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
Hi Sam, Since authorization and accounting with the use of the pre-authentication may be different from those with the use of normal authentication, it would be good to differentiate pre-auth and without pre-auth for network access authentication protocols that support pre-authentication, PANA and 802.11 are such protocols as far as I know. BTW, I also commented about adding IEEE 802.16m and IEEE 802.21a for EAP lower-layers. Here is the references for them: IEEE 802.16m: Standard for Local and Metropolitan Area Networks - Part 16: Air Interface for Broadband Wireless Access Systems - Advanced Air Interface, IEEE 802.16m-2011, 2011. IEEE 802.21a: Draft Standard for Local and metropolitan area networks-Part 21: Media Independent Handover Services Amendment 2: Security Extensions to Media Independent Handover Services and Protocol, IEEE P802.21a/D04, 2011. Regards, Yoshihiro Ohba (2011/10/20 4:59), Sam Hartman wrote: Hi. I've added PANA (pre-authentication). I wonder about the whole lower layer table. Why is it important to distinguish PANA with pre-auth from pana without pre-auth? Why is it important to distinguish 802.11 wpa, wpa2 and wpa2 with pre-auth? I'd appreciate it if someone who cared about network access told me what to do here:-) ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Comments on the eap-tunnel-method-00 draft
Jim == Jim Schaad i...@augustcellars.com writes: Section 4.2.10 - How can I know if the server does or does not process the channel binding TLV? This may be part of my policy as a peer depending on circumstances. [HZ] Currently, the Channel-binding TLV is an optional TLV, doesn't require acknowledgement, and is designed to be only one way, for client to send some channel binding data to the server for verification purpose. There is no feedback provided. The indication of whether the server supports channel- binding and/or validated the channel-binding could be conveyed in other TLVs to be added, if the WG agrees to be valuable. JimSam - do you see this as being an issue for abfab? It's an issue for EMU actually. See Section 5.3 of draft-ietf-emu-chbind. Channel binding must be two-way and must follow the semantics of that section. And yes, draft-ietf-abfab-gss-eap depends on those semantics. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Comments on the eap-tunnel-method-00 draft
Rereading the updated chbind draft, it has already defined the mechanism for two way communication and tunnel EAP draft just defined a TLV container to carry the Channel binding data defined in Section 5.3, so we should be ok. No change is needed on the tunnel EAP draft on this, other maybe called out Section 5.3. On 10/19/11 8:22 PM, Sam Hartman hartmans-i...@mit.edu wrote: Jim == Jim Schaad i...@augustcellars.com writes: Section 4.2.10 - How can I know if the server does or does not process the channel binding TLV? This may be part of my policy as a peer depending on circumstances. [HZ] Currently, the Channel-binding TLV is an optional TLV, doesn't require acknowledgement, and is designed to be only one way, for client to send some channel binding data to the server for verification purpose. There is no feedback provided. The indication of whether the server supports channel- binding and/or validated the channel-binding could be conveyed in other TLVs to be added, if the WG agrees to be valuable. JimSam - do you see this as being an issue for abfab? It's an issue for EMU actually. See Section 5.3 of draft-ietf-emu-chbind. Channel binding must be two-way and must follow the semantics of that section. And yes, draft-ietf-abfab-gss-eap depends on those semantics. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Submitted 10
On 10/20/2011 3:09 AM, Sam Hartman wrote: I believe I've addressed all of Alan's comments with the exception of removing the RADIUS diagram from 5.3. Great, so what are we supposed to do now? WGLC was issued on draft-ietf-emu-chbind-09. The last call is not complete. Shall we just start over? This creation of a moving target wouldn't be so annoying if you were a newbie but you are anything but that... Thanks Alan for the comments! --Sam ___ 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
