7;re not going to make it public until we have closure. But we can share it
privately for interoperability tests. We've been mostly working with Microsoft
and Jouni, but we're open to others.
So for this document, the text does (or will) represent int
eed to
> resolve this issue in 7170bis.
>
> Any objection to this errata resolution?
I think it's a good idea.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ent; such as the
> interaction with Intermediate-Result TLV. It is valid to have a mix sequence
> of EAP-Payload TLV followed by Vendor-Specific TLV or vice versa.
I'll add some similar text to the "Phase 2" section above the "EAP sequences"
section. Discuss
On Jan 10, 2023, at 9:17 AM, Alexander Clouter wrote:
> I am sure it is safe (and better/faster/...) to do Intermediate-Result-TLV
> first and then Crypto-Binding-TLV.
The other text says "validate crypto binding before checking results". So
we're stuck with that
On Jan 10, 2023, at 9:26 AM, Eliot Lear wrote:
> You've left out the other TLVs, but I think most fit in (5). We need to
> consider what happens in the case of a request-action TLV.
I'll update that, thanks.
I think it should be:
The order in which TLVs are encoded in a TEAP packet does n
knows the password, so it gains no information
by observing the MS-CHAP exchange.
Any client which knows the password gains no information by observing the
MS-CHAP exchange.
Attackers can only try MS-CHAP with random guess, and get rejected. Th
d EMSK, otherwise carry the MSK version". I could probably
> do better and instead having thought of it tried the second approach which
> probably would also work...probably...probably not..."needs more testing" :-/
I'll put some text together.
&
P-FAST-MSCHAPv2 is no longer
> allowed by TEAP with this mode.
I agree.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ssion during
> an initial handshake or renegotiation handshake.
I agree.
> Maybe something like this:
>
> 'abbreviated handshake' is based on TLS session ticket or TLS session id.
> That is, when TLS state kept on client or s
I've pushed all fixes to GitHub:
https://github.com/emu-wg/rfc7170bis
There are 3 new markdown files for errata which should be reviewed. The
files describe the problem and fixes at a high level.
There are also a few new open issues taken from comments on the mailing list.
These are al
t;u...@example.com
>
> This got rendered as a mailto: link, try to remove the link?
I think that's an artifact of the conversion to XML. I'll see if I can
address it.
>and tje
>
> "and the"
Fixed, thanks.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Jan 13, 2023, at 11:29 AM, Paul Wouters wrote:
> All the links in this sextion say "[RFC] Section N.M" but actually point
> to THIS document section N.M
I think that's an artifact of the conversion to XML. I'll
t.
2) leave the text around PAC in, but add a note saying it's not implemented,
and is untested.
Comments? What's the best direction to go?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
some minor wordsmithing to match 7170bis, but the content appears
largely good.
I think the draft will be reviewed by the IESG this week. Any further
changes can likely be done as part of the RFC editor process. The changes are
minor, and editorial.
. Perhaps it's worth
mentioning, and suggesting that TLS-PSK isn't a good idea?
> On Jan 15, 2023, at 10:40 AM, Alan DeKok
> wrote:
>
> One of the questions which came up at the interim call was about the PAC.
> The discussion there was that PAC support was in hostap, bu
thenticate users, whereas TEAP could use additional methods inside of the
TLS tunnel.
But it is a good reason to frown on TLS-PSK in TEAP, I think.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
TLS-PSK
with TEAP is NOT RECOMMENDED until a deeper analysis and use-cases have been
done.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
delete all text on PAC, and on related attributes. The
IANA registries can remain in place, but the TLVs related to PAC can point to
RFC 7170, and the other TLVs can point to this document.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://w
." and when looking at the
> existing registry, I didn't notice the space after the colon at first.
Does the space cause a problem? I don't recall seeing guidance on TLS
exporter labels which suggest that spaces should be avoided.
Alan DeKok.
't think there's much more to do.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
>
>Title : Tunnel Extensible Authentication Protocol (TEAP)
> Version 1
> Authors : Alan DeKok
> Hao Zhou
> Joseph Salowey
> Nancy Cam-Winget
> Ste
d less than 8 octets should be viewed with great suspicion.
I'll push some text, unless anyone has objections.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
;s
probably worth adding a reference to
https://datatracker.ietf.org/doc/html/draft-ietf-emu-tls-eap-types-10#section-3.1
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
t doesn't want to do password auth, it can just reject the
Basic-Password-Auth-Req TLV, and return a NAK TLV. It shouldn't send a
username && empty password.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
issues where the identities should agree... but perhaps we
can ignore that, and just hope for the best.
So in conclusion, it looks like your workflow is impossible without the
addition of an Identity-Hint TLV which is sent by the peer, as soon as the
tunnel is established.
Alan DeKok.
On Jan 25, 2023, at 9:06 AM, Eliot Lear wrote:
>
> First, I agree that this is a nit.
Except for the inability to get identities before choosing an authentication
method.
> On 25.01.23 14:54, Alan DeKok wrote:
> Sure, but 7170 doesn't say you can't have a null passw
know anything about the user until it's chosen the "wrong"
method.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Jan 24, 2023, at 1:35 PM, Thomas Fossati via Datatracker
wrote:
>
> Nits/editorial comments:
>
> OLD
> There remain some differences between EAP-TLS and other TLS-based EAP
> methods which necessitates this document.
> NEW
> There remain some differences between EAP-TLS and other TLS-b
, Bob may end
> up in authentication and other logs and any possible authorisation may
> be done as Bob.
Very true. I'll update the text.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
. I'll add text on
permitting use-cases like "password + OTP" as separate rounds.
It may be worth noting that multiple rounds of EAP are supported for
different Identity-Types, i.e. machine and then user. I don't think we want
;
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the EAP Method Update WG of the IETF.
>
>Title : TLS-based EAP types and TLS 1.3
>Author : Alan DeKok
> Filename
al problem, or (b)
it's fine and we can ignore it.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Feb 2, 2023, at 10:15 AM, Bob Halley via Datatracker
wrote:
> While I am not an EAP or TLS expert, I found the document to be very clearly
> written, in particular in its explanations of why various choices were made.
> I
> did not see anything worrisome in the document.
Thanks.
> The fo
kets, which is less than
optimal.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
s. Right now,
"select auth based on identity" is either impossible, or requires extra
"oopsie" packet exchanges. That doesn't seem right.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Feb 3, 2023, at 8:19 PM, Melinda Shore via Datatracker
wrote:
>
> Reviewer: Melinda Shore
> Review result: Ready
>
> This document updates TLS-based EAP methods to use key derivation mechanisms
> from TLS 1.3, along with other TLS 1.3-required updates. It's clearly written
> and I believe c
s an issue. The simplest thing is to perhaps note that it's an
issue, and leave it as that.
>> For me it's also partly about not forbidding certain work flows.
>> Right now, "select auth based on identity" is either impossible, or
>> requires extra "oo
t TLV means TEAP deployments will be limited to either password,
OR EAP authentication in phase 2, but not both in the same system.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
nts to renew its cert earlier than the server
> may want it to. The server will need to send another Result TLV eventually.
>
> I don't think that behavior should be proscribed.
OK.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
rall exchange still
> can fail.”
It's left over bits from multiple edits. Perhaps:
There MAY be
additional protocol exchanges which could still cause failure, so we
cannot mandate sending success on successful authentication.
> Feel free to use those words if they make sense, or not,
On Feb 14, 2023, at 5:51 PM, John Scudder wrote:
> The RFC 2119-style MAY seems a little out of place, it seems like it’s
> expressing an expectation rather than giving permission to an implementation
> that the inner protocol is allowed to do certain things (which seems beyond
> the scope of t
On Feb 15, 2023, at 9:53 PM, Roman Danyliw via Datatracker
wrote:
> ** Section 2.4
> It is therefore RECOMMENDED that EAP servers always send a TLS
> NewSessionTicket message, even if resumption is not configured. When
> the EAP peer attempts to use the ticket, the EAP server can instead
>
TLS 1.3 allows for client authentication at anytime, but EAP-TLS
> only allows it during the initial handshake change the first sentence to:
>
> This issue is not relevant for EAP-TLS, which only uses client certificates
> for authentication
> in the TLS handshake.
Sure.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ople do in their own private
environment.
It's really "If you want your systems to work on the Internet, here's what
you do. If you don't care about that, you're on your own. Go figure it out
yourself".
> Thanks for including Section 5.
>
> In Secti
ree to interoperate or
> not, so I'm not too worried about the (b) case.
Implementations have to support both use-cases. If we make this a MUST, then
implementors may see it as a requirement of the implementation, and forbid
practices which are currently in wide-spread use.
Alan DeKok.
___
ate WG of the IETF.
>
>Title : TLS-based EAP types and TLS 1.3
> Author : Alan DeKok
> Filename: draft-ietf-emu-tls-eap-types-13.txt
> Pages : 23
> Date: 2023-02-16
>
> Abstract:
> EAP-TLS (RFC 5216) has been upd
verifying that the user had first been authenticated,
> the malicious client can then obtain network access without ever
> being authenticated network access without ever being authenticated.
Fixed, thanks.
Alan DeKok.
___
Emu mailing list
7170bis. I think
we're pretty much done at this point.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
days, when I had time to read the other
> sections.
Thanks.
I've submitted a -04 based on your review. I can submit a -05 before the
deadline if you can finish your review this week.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
looks like I never got a copy of
it from the list. I've gone with your suggestions, unless later revisions
made them moot.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ere any other issues we need to address? The EMU minutes aren't up
yet, but I think that's it.
Alan DeKok,
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
esign, as AAA does not provide for end-to-end
security.
c) AAA systems not using PFS are vulnerable to an attacker who can snoop the
traffic, and crack it at their leisure.
TLS/IPSec makes this a bit harder against an attacker with few resources.
UDP/TCP transport is not recommended when A
ess interesting than
the practical attacks. And the defences against theoretical attacks are not
interesting if the defences are entirely impractical.
What solutions can be implemented here? What recommendations can we make
which are both practical, and secure?
Alan DeKok.
_
ere is the possibility that all EAP sessions
using a particular connection will simply fail.
So the increased security has the potential to also increase the number of
failed authentications. Which means in order to fully support small lifetime
for AAA connections, we need to first ensure that
fully support small lifetime for
>> AAA
>> connections, we need to first ensure that the AAA system is robust to such
>> small
>> lifetime connections.
>
> [K]: That seems to be a problem that needs to be taken into account.
Until that issue is fixed, solutions like re-keying are largely impractical.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
figs.
OK. I'll make that change, and issue a new document.
At this point there are only a few open issues:
https://github.com/emu-wg/rfc7170bis/issues
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
attacks.
EAP-MSCHAPv2 does generate keying material, so it shouldn't have this issue.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
r is some updated diagrams from
Eliot. I think with those, the document could be finished.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
r message to address this problem. Do people
> think this needs addressing?
I think it's worth addressing this, as it's an implementation pitfall.
> Once we resolve these issues we can move the draft forward.
I'll get the updates done this week.
Alan DeKok.
On Jun 29, 2023, at 10:48 AM, Eliot Lear wrote:
> RFC 2315 uses the term, and I take "degenerate" here to mean that the PKCS#7
> object is not itself signed. This is how we implemented.
OK. I will update doc document accordingl
tificate to
TEAP.
Do we want to say that the provisioned credentials MUST NOT be used for
anything other than TEAP?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
tion and
> renewal, and that other uses should be considered carefully by clients. This
> might also lead to an EKU discussion, and that might be something we want to
> address here.
OK.
I've already issued -07. I'll try to do some word-smithing around the
subject, an
rent from EAP-TLS
* use of client certificates in other EAP types.
This should be only a few paragraphs. I'll get that out shortly.
After that, the only thing left is a final review from the WG. (Last "last
call")
Alan DeKok.
__
t; IoT devices and networks.
I'm wary of such a suggestion. EAP is widely used outside of CoAP. Adding
new EAP methods also means that those EAP methods can be used in other
circumstances, which don't have the transport security / reliability provided
by CoAP.
O
hod Update (EMU)
> WG of the IETF.
>
> Title : Tunnel Extensible Authentication Protocol (TEAP) Version 1
> Author : Alan DeKok
> Filename: draft-ietf-emu-rfc7170bis-08.txt
> Pages : 103
> Date: 2023-07-10
>
&g
On Jul 10, 2023, at 4:44 PM, Michael Richardson wrote:
> Alan DeKok wrote:
>> * CAs should validate (somehow) any CSR they receive, to check that the
>> contents are reasonable
>
> I guess this is the new section 3.2.8.
Yes.
> There are quite a number of subtlies h
he system. I'm thinking @me.com, @live.com,
> ubuntu-1 account)
I agree.
> It's not written up, having been discussed in detail only last Wednesday.
> I'll get slides posted to LAMPS in the next week.
> But, the short of it: Here is an CSR, please fill in the b
Extensible Authentication Protocol with TLS 1.3".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7577
>
> --
> Type: Technical
> Reported by: Alan DeKok
>
&
t-dra...@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the EAP Method Update (EMU)
> WG of the IETF.
>
> Title : Tunnel Extensible Authentication Protocol (TEAP) Version 1
&
ssue a PKCS#10 request or the server will issue
> a request action TLV with PKCS#10, so that the client knows the server wants
> it to renew.
Sure.
Perhaps the text could just remove the last sentence about devolving to
EAP-TLS.
Alan DeKok.
On Aug 1, 2023, at 5:08 AM, Eliot Lear wrote:
> This just reverses the order of two paragraphs and visually separates outer /
> inner definitions. We could in theory do the same with phase 1/phase 2, but
> I think this is good enough.
That looks good, thanks.
A
useful. More are likely found when working on implementing the provisioning
> parts, which we haven't done yet.
We can only write down what we know now. :(
Given timing and implementation status, I believe it's worth publishing the
document quickly.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
e.
>
> But again, this is all server side policy. The only aspect for the client is
> that it should know when to re-authenticate if the server requires it.
Agreed.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Radius-Disconnect MAY be used as a
> signal to a client directly after such operations to disconnect and
> authenticate with the new updated credentials.
I would strongly prefer to avoid requiring RADIUS CoA / Disconnect. They're
good to have, but not always
Method Update (EMU)
> WG of the IETF.
>
> Title : Tunnel Extensible Authentication Protocol (TEAP) Version 1
> Author : Alan DeKok
> Filename: draft-ietf-emu-rfc7170bis-10.txt
> Pages : 104
> Date: 2023-08-03
&g
have no current
authorization, it can't be changed. Instead, they either get EAP Failure or
Success. So the only real question is which identity is used as the basis for
access policies. And that's simple, too: the new one.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
server must invalidate any
> possible TLS resumption which would put the device back to the
> (re)-provisioning VLAN.
>
> However, I think this is outside of scope of this draft/RFC and is something
> that the device/application and server software vendor
hed. Perhaps we could just make a recommendation to use the new method,
and leave it at that?
I would very much like to get this document done and gone. Delaying it more
is IMHO a bad idea.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
rences that probably could be informative:
Done.
> Informative references that probably need to be normative:
Done.
> MAYBE:
> [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
> "Randomness Requirements for Security", BCP 106, RFC 4086,
> DOI 10.17487/RFC4086, June 2005,
> <https://www.rfc-editor.org/info/rfc4086>.
> [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
> Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
> <https://www.rfc-editor.org/info/rfc4648>.
I think leaving those as informative is OK.
> I suggest when listing the contributors for 7170, that they be listed using
> the markdown contributors: method, as that results in XML that is machine
> parseable. There is also a {{{First Last}}} for kramdown that results in XML.
Sure. I can't find much in the way of actual examples...
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ument?
I'll update it to ban inner method resumption. I think that's the best
approach.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Aug 17, 2023, at 8:01 PM, Michael Richardson wrote:
> Alan DeKok wrote:
>>> section 2; paragraph 2, uses SHOULD several times without obvious
>>> exceptions. Could be it is MUST?
>
>> I don't think we can mandate that the outer EAP identity is an NAI.
&g
oning by not validating the certificate chain
or any of its contents.
The last sentence is suggested by the RFC8446 Section C.2
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
xtensible Authentication Protocol (TEAP) Version 1
> Author : Alan DeKok
> Filename: draft-ietf-emu-rfc7170bis-12.txt
> Pages : 108
> Date: 2023-08-18
>
> Abstract:
> This document defines the Tunnel Extensible Authentication Pro
On Aug 18, 2023, at 1:29 PM, Heikki Vatiainen wrote:
> Good find, looks good. Small fix, though. It's section C.5, not C.2.
Fixed, thanks.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
e attacks.
>> Implementations and
>> deployments SHOULD adopt various mitigation strategies
>> described in
>> [RFC7029] Section 3.2.
>
> Does this have an impact either with cert ops or the Phase 1 auth and close
> as discussed previously?
I don't think so.
> I may have a few more comments after the weekend.
It seems like TEAP will drag on forever :(
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
gs in 5216. I'm happy to remove it.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Aug 20, 2023, at 5:09 AM, Alexander Clouter wrote:
>
> On Thu, 17 Aug 2023, at 23:33, Alan DeKok wrote:
>>> If I did run EAP-TLS as an Inner method (whether once or twice), could I
>>> use resumption?
>>
>> Uh... why didn't anyone mention this befo
. TLS inside of TLS just seems bad.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
implicity…
> Moreover, I guess it is reasonable to assume most TEAP implementations will
> have TLS 1.3 in the stack anyway.
We don't need to bind the ticket to the result of the inner authentication.
The server simply refuses to allow tickets to be used until the inner
authen
ailure:
> Intermediate-Result TLV (success)
> Result-TLV (success)
> Cryptobinding-TLV
>
> To summarise. If the last paragraph of draft-12 section 7.4.1. "User Identity
> Protection and Verification" is updated, it would make the text more
> consiste
70 ciphersuite.
it's probably best to just remove the explicit cipher suite name from
Appendix A.4 and A.5
> Example flows C.11., C.12. and C.13. are not named.
Thanks. I'll add titles.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
s. This Internet-Draft is a work item of the EAP Method Update (EMU)
> WG of the IETF.
>
> Title : Tunnel Extensible Authentication Protocol (TEAP) Version 1
> Author : Alan DeKok
> Filename: draft-ietf-emu-rfc7170bis-13.txt
> Pages
will be easier.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
n the inner methods
are bypassed completely. But it's likely worth noting that the if outer
resumption is allowed, the inner methods should have resumption disabled.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
; provisioning?) that's not EAP but that can provide keying material, the text
> won't be too restrictive.
>
> https://github.com/emu-wg/rfc7170bis/pull/26
I think that's reasonable. Unless there are objections, I'll pull it in.
Alan DeKok.
_
But that work is now also generally available.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
er differences are minor.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
gt;
> In terminology section only 'Inner method' is defined and it seems to me that
> in many cases 'Inner method' would suffice when some of the term is used.
> There are of course cases when a specific term, such as 'EAP method', is
> needed.
I
ut
getting this text clear and correct is hard.
There are a few lessons here, I think:
* don't publish specs until at least one implementation exists.
* specs should have have only a few options, and it there should be a
straightforward pat
On Aug 27, 2023, at 10:42 AM, Heikki Vatiainen
wrote:
> Related to this, a closer look at the draft shows that at least the following
> terms are used in interchangeable manner:
Fixed thanks.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
601 - 700 of 800 matches
Mail list logo
