or example, IOT experts
> could say if they see use for TEAP/PEAP/EAP-TTLS used for tunnelling SIM
> based EAPs?
Sure. I'll update the document.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
plicit that
> this is data used by EAP?
The rest of the document discusses how the EAP server handles the inner
tunnel data, so I think it's already explicit that the data is handled by EAP.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
gt;
> The options are send one or the other, depending on the conditions or just
> send one regardless of the conditions, perhaps the answer is to just send
> Result TLV regardless?
The document already mandates sending a Result TLV to indicate the final
result of authentication, so I t
On May 20, 2024, at 8:12 PM, Orie Steele wrote:
>
> On Mon, May 20, 2024 at 6:24 PM Alan DeKok
> wrote:
>>
>> "It MUST only send a NAK TLV for a TLV which is marked mandatory."
>>
>
> It MUST send a NAK TLV for any TLV which is marked mandatory but
ng a PKCS#7 [RFC2315] degenerate (i.e.
> 1233 unsigned) "Certificates Only" message encoded into the body of a
> 1234 PKCS#7 TLV (see Section 4.2.16), only after an inner method has run
> 1235 and provided an identity proof on the peer prior to a certificat
n479
>
> Wikipedia has more info about its history and pointers to the first commits
> from 10+ years ago:
> https://en.wikipedia.org/wiki/Extensible_Authentication_Protocol#EAP-TLS
>
> I haven't seen any use of "WFA-UNAUTH-TLS"
of the IETF.
>
> Title: Tunnel Extensible Authentication Protocol (TEAP) Version 1
> Author: Alan DeKok
> Name:draft-ietf-emu-rfc7170bis-16.txt
> Pages: 111
> Dates: 2024-03-26
>
> Abstract:
>
> This document defines the Tunnel Extensible Au
@eap.arpa
instead of
provision...@teap.eap.arpa
I think the second looks clearer to me.
Alan DeKok,
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
issue that the current draft recommends Expert Review
> for assignment of new values but then also expects RFCs: "The intention is
> that any non-prefix allocation will be accompanied by a published RFC.". I
> think it will be beneficial to have "Specification Required". Note &
ticated mode since 2008 (RFC 5216 Section
2.1.1). But there's been no way to actually use it.
Hopefully this set of documents will address that issue.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
oo.
* define an eap.arpa domain for use with a number of proposed provisioning
methods.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
s sent in EAP-FIDO.
Is that fixed, or negotiated?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
says "MUST be of
> length one", some vendor will ignore it, on the sending or receiving side.
> How do we deal with two PKIDs? do we take the first one? The last one? Do we
> abort completely?
> I find it better to be explicit, this way we avoid such errors in
> implementa
An alternative would be to do the version negotiation inside of the TLS
tunnel. That's also imperfect, but at least gives EAP-FIDO complete control
over all aspects of the protocol.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
; sort of like
> GREASE...but to fix an insecurity instead.
I think that changes existing implementations. Unless the recommendation is
for each end to add a dummy Outer-TLV which implementations are *known* to
ignore.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
t
> send it by default to unauthenticated servers, but offer a way for the user
> to override that default?
I believe that Identity-Hint is not useful for server unauthenticated
provisioning, and therefore should not not be used in that situation
On Mar 1, 2024, at 10:21 PM, David Mandelberg via Datatracker
wrote:
>
> (nit) If I understand the TEAP version negotiation and Crypto-Binding
> correctly, the negotiated version is not cryptographically verified until
> either (1) after the first inner method is completed or (2) just before
t; Protection against Man-in-the-Middle Attacks
>
> Maybe rename to "on-path attacks" ?
Fixed.
> Appendix C.4 should clarify the TLS version used (1.2). Should it be
> changed to use a TLS 1.3 example?
I think so, yes. I'll have to dig into that. I don't think I can get that
updated today before the deadline.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
This update includes guidelines for DNS operators and implementors.
> Begin forwarded message:
>
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-dekok-emu-eap-arpa-01.txt
> Date: February 25, 2024 at 5:23:32 PM EST
> To: "Alan DeK
I support adoption.
I'll review it for any general EAP issues. I have less confidence in my
ability to review any cryptography.
> On Nov 29, 2023, at 12:13 PM, Peter Yee wrote:
>
> This is an adoption call for EAP-EDHOC (draft-ingles-eap-edhoc) [1].
> This draft was originally briefed in
b, email,
and pretty much every other TLS-based protocol. Why not EAP?
I would only add to that that any such method should be limited to just
sending a clear-text password. There's no reason to continue allowing MS-CHAP
and CHAP.
Alan DeKok.
_
s actually a
> great step, because the FIDO Passkey that is already provisioned for logging
> into the account in the web can now simply be used for network access as well.
That is my hope.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ssed
* provisioning of FIDO credentials
* de-provisioning of credentials.
The last one is hard, as how do you de-provision credentials if you've
deleted them, and you can't prove who you are?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
nfigure it manually. And
critically, cannot configure it *incorrectly*. It's either secure and it
works, or it's insecure and it doesn't work.
We've had ~20+ years of relying on end users to carry the burden of
supplicant configuration. That practice is a failure, and should be replaced
with some
ers
> to Chromebooks)
Oh my.
I can't publicly say what I would like, so I will leave it at that.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
.
The server certificate should be signed with a CA known to the supplicant.
And it doesn't matter which CA.
I think that the discussion here shows that pinning a server cert or CA cert
will create more problems than it solves.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
g tricky, but I think
> the idea also has merit.
Shades of TEAP!
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
e
can just say that the EAP certificate should be issues by the same (or
equivalent CA) to the one which was used to provision the initial FIDO
credentials.
In practice, this means WebPKI most of the time. :)
Alan DeKok.
___
Emu mailing li
led FIDO - for use in TTLS, PEAP, or other TLS-based EAP methods.
2) TLS-based method with tunnelled FIDO - it can make new / stronger
requirements on CA validation, server identity, etc.
We could just ban the use of tunnelled FIDO in TTLS / PEAP. But I'm not sure
that's practical. It's likely safer to just define TTLS + tunnelled FIDO.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
It looks good as a first draft. Some first draft comments:
I would suggest that the default should be to using the Web PKI for server
authentication, unless there's a client configuration which says to use a
different CA. This behavior means that configuring EAP-FIDO for a domain is
e server
* then use EST (RFC7030) to connect to a well-known URI for that network, and
do some more work.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Sep 10, 2023, at 6:56 PM, Alan DeKok wrote:
> There have been long discussions about not tying EAP to DHCP. I forget
> which RFC it is, but there's an IAB architectural document which says this is
> a bad idea.
https://www.rfc-editor.org/rfc/rfc5505.html
The use of
d know what kind of access it's getting. This is
also a signal to the RADIUS server as to what kind of authorization to send to
the NAS / switch.
In contrast, if there's only one kind of on-boarding access, authorization
has to be done through DHCP which has
ate (EMU) WG of the IETF.
>
> Title: Tunnel Extensible Authentication Protocol (TEAP) Version 1
> Author: Alan DeKok
> Name:draft-ietf-emu-rfc7170bis-14.txt
> Pages: 108
> Dates: 2023-09-04
>
> Abstract:
>
> This document defines the Tunnel Ex
an "eap.arpa" draft now.
It's still very rough, but the idea is "use someth...@eap.arp". And then
fill in some suggestions.
A new version of Internet-Draft draft-dekok-emu-eap-arpa-00.txt has been
successfully submitted by Alan DeKok and posted to the
IETF repository.
lable". So if
an implementation doesn't use EMSK, it's violating the spec.
Plus, all existing implementations use EMSK. So anyone who doesn't do that
won't interoperate.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
hod, something else). Because it appears
>> to be an inner method, also add text to section 3.11. where the use of the
>> two TLV types is required.
> Agree. It's an inner method, as indicated in Section 4.3.2.
I'll add PKCS to the defin
On Aug 26, 2023, at 3:47 PM, Alexander Clouter wrote:
> I have read through the document and think it is "good to go", post nit
> combing...
Fixed, thanks.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
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
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 path through the options.
Alan
> 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'll take a pass tomorrow to go through and clean
are minor.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
But that work is now also generally available.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
AP 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.
___
Emu mailing
tely. 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
be easier.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
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 : 109
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
(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
> consistent with the other parts
eover, 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
authentication has completed.
de of TLS just seems bad.
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 before
in 5216. I'm happy to remove it.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
tations 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
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
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
provisioning 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
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.
e 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
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
aps 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
S 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 must take care of. The
> new text in the
, 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
gt; 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
>
> Abstract:
>
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 possible. If the Access-Request packets are sent
across a TLS tunnel thr
ain, 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
ng 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
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
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.
_
ote:
>
>
> 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
> Author
sible 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
>
> S
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 blanks.
That seems like the best approach.
Al
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 subtlie
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
>
n. 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.
Other EAP methods which may be suitable for CoAP include EAP-PWD, which
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.
___
al, 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, and issue -08 later this week.
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
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
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.
_
ink with those, the document could be finished.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
HAPv2 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
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
t; 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
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 the AAA system is robust to
such small
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.
_
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 AAA traffic sent across insecure
networks.
ssues 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
e 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
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
is. 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
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
Emu@ietf.
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
eroperate 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.
__
uot;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 Section 6.1:
>
> There MAY be
> additional protocol exchanges which cou
lient 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
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
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
nge 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, but as the tex
s 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
1 - 100 of 650 matches
Mail list logo
