> >
> > On 01.04.22 00:52, Alan DeKok wrote:
> >> On Mar 31, 2022, at 4:40 PM, Bernard Aboba
> >> wrote:
> >>> Alan suggested:
> >>> " EAP-Start is indicated by sending an EAP-Message attribute with a
> >>>
5-Challenge) which may not be appropriate."
On Thu, Mar 31, 2022 at 7:59 AM Alan DeKok
wrote:
> On Mar 31, 2022, at 10:29 AM, Bernard Aboba
> wrote:
> >
> > I am CC'ing the RADEXT WG mailing list, since the errata relates to a
> widely implemented RADIUS specificati
I am CC'ing the RADEXT WG mailing list, since the errata relates to a
widely implemented RADIUS specification.
Errata 6154:
While Alan is correct that a RADIUS attribute with no data is not permitted
by RFC 2865, and RFC 3579 is ambiguous about the length, I am concerned
about the potential
es. The EAP-TLS implementation needs
> to know which version of TLS that was negotiated.
>
>
>
> Cheers,
>
> John
>
>
>
>
>
> *From: *Emu on behalf of Joseph Salowey <
> j...@salowey.net>
> *Date: *Monday, 14 June 2021 at 01:54
> *To
draft-ietf-emu-eap-tls13-16 Section 2.1 contains the following text:
EAP-TLS 1.3 remains backwards compatible with EAP-TLS 1.2 [RFC5216]
. TLS version
negotiation is handled by the TLS layer, and thus outside of the
scope of EAP-TLS. Therefore so long as the underlying TLS
Alan --
Thanks for the very thorough review comments.
"Implementations should not make the same mistake with TLS 1.4 as was
done with TLS 1.3. Therefore, this document should explicitly call
out this issue, and suggest a path for implementations to follow."
[BA] Agree, particularly given that
hould be considered an
> alternative failure mechanism.
>
>
>
> 4. What is the purpose of the commitment message?
>
>
>
> The -01 to -13 purpose was to indicate in an authenticated way that the
> EAP-TLS method would not continue and that only success or failure could
>
;
>
> Cheers,
>
> John
>
>
>
> *From: *Mohit Sethi M
> *Date: *Monday, 8 February 2021 at 06:33
> *To: *John Mattsson , Bernard Aboba <
> bernard.ab...@gmail.com>, "emu@ietf.org" , "t...@ietf.org" <
> t...@ietf.org>
> *Subject:
; if (aaaEapKeyData != NONE)
>
> aaaEapKeyAvailable = TRUE
>
>
>
> I therefore only described when the "keying material becomes available"
> which is the words used by RFC 4137 for eapKeyData and aaaEapKeyData.
>
>
>
> Open question if Section 2.5 shoul
The discussion largely happened in 802.11 since that was where the
vulnerability vulnerability was discovered (by Bill Arbaugh at UMD).
Documentation of the required signals was in RFC 4137, tests on the fixed
implementations were done by UMD and subsequent analysis and security
proofs were done
Joe Salowey said:
"[Joe] Based on RFC 5216 the server could fail the finished message or as
section 2.1.3 shows it could send the finish and then it can send an
Alert and result in EAP-Failure. In this case it would be possible
for an attacker to remove the Alert and send a success. Whether
Alan DeKok said:
"The way forward is to resolve open issues. Publishing the current draft
would be premature.
IMHO we are still nowhere near agreement. There are many open questions
which have not been resolved."
[BA] Agreed. The recently published draft does not resolve the open issues
or
The EAP TLS 1.3 specification does not currently specify how EAP TLS 1.3
interacts with the EAP state machine as specified in RFC 4137. It appears
to me that this under-specification is at the root of the questions about
the commitment message.
Historically, under-specification of the EAP-TLS
In order to better validate existing implementations of EAP-TLS 1.3, we
will be organizing an EAP-TLS 1.3 Hackathon at IETF 110.
The goal of the hackathon is to test operating system client
implementations (Android, iOS, Mac OS X, Windows) with server
implementations over the Internet.
If you
The big question is "Why not create a new EAP method"?
The overall intent seems to be to create an pre-shared key EAP method
optimized for 5G, based on EAP-TLS v1.3.
Since the protocol described will not interoperate with any of the existing
2+ billion EAP-TLS devices, why reuse the EAP-TLS code
Alan said:
"That's good. But as Bernard points out, there's no need to change
EAP-TLS. You can just use TLS 1.3."
[BA] Existing implementations enable organizations to impose TLS version
and ciphersuite requirements on *their* devices. For example, I have
worked with organizations that
ne that should be ignored, as being out of touch with
real-world use-cases."
[BA] I fully agree.
On Thu, Oct 26, 2017 at 5:57 PM, Alan DeKok <al...@deployingradius.com>
wrote:
> On Oct 26, 2017, at 8:24 PM, Bernard Aboba <bernard.ab...@gmail.com>
> wrote:
> > To pr
With implementations shipping on virtually every major platform (e.g.
Android, iOS, Mac OS X, Windows, Linux ,etc.) EAP-TLS (RFC 5216) is now
supported on 2+ billion devices worldwide. This includes numerous open
source implementations for both the EAP client and server.
In particular, EAP-TLS,
Since the EAP Session-Id is utilized in EAP lower layers such as IEEE
802.1X-2010, the interoperability of an EAP method implementations can be
affected by the definition of the Session-Id. One important requirement for
the Session-Id is that it be unique for each EAP session. That is, a
Katrina Hoeper said:
Unfortunately, it seems to be too late to reference the analysis in the
tunnel requirement draft, but I hope that some people still might find it
interesting.
[BA] The paper represents the most comprehensive analysis of tunneled
authentication security to date, and brings
Of Kroeselberg,
Dirk (NSN - DE/Munich)
Sent: Monday, March 22, 2010 5:26 PM
To: ext Henning Schulzrinne; Bernard Aboba
Cc: ec...@ietf.org
Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of
serviceattacks on the emergency.com domain)
yes, fixing the NAI to a simple string is simple
.
--Richard
On Mar 22, 2010, at 6:28 PM, Bernard Aboba wrote:
Part of the confusion here may be that we're talking about
unauthenticated at multiple layers. There is unauthenticated
network access, and then there is unauthenticated VOIP signaling.
These are two orthogonal things. The VOIP
This is a review of ITU Study Group 17, TD 0495, which represents a revision
of ITU-T X.1034. For details, see:
https://datatracker.ietf.org/documents/LIAISON/file714.pdf
General Observations
Looking at this document, I don't see much evidence that the ITU-T has made
an effort to
Section 5.1
The local database is perhaps the most important part of this system.
In order for the EAP server or AAA server to know whether i1 and i2
are correct, they need access to trustworthy information, since an
authenticator could include false information in both i1 and i2.
Section 9.2
Additional network entities (such as proxies) might be on the
communication path between peer and server and may attempt to
manipulate the channel binding protocol. If these entities do not
possess the keying material used for integrity protection of the
channel
Section 6
signalling allows an IEEE 802.1X to occur without exchanging
cryptogrpahic keys
[BA] Not sure what this is saying. In IEEE 802.1X-2004, there is no
encryption supported. However, EAP is still run. This can include methods
that don't generate keys (e.g. EAP-MD5). But the
if they were in ASCII/UTE-8 format.
Does this make sense?
Thanks,
Joe
-Original Message-
From: Bernard Aboba [mailto:bernard_ab...@hotmail.com]
Sent: Tuesday, September 08, 2009 7:09 PM
To: Joseph Salowey (jsalowey); emu@ietf.org
Subject: RE: [Emu] #18
Steve Hanna said:
However, I agree that it would be better to get IESG clarification
that carrying authorization data in EAP is permissible. As Alan
suggested, the first step is probably to have a WG consensus
check to verify that we have rough consensus that this should
be permitted.
The discussion here is (a) if we can get *some* generic authorization
passed via methods used for Channel Bindings, and (b) is that a good idea.
I think that the answer to (a) is yes, and (b) is some say yes,
some say no.
Existing RFCs are clear that Channel Bindings have a specific
Qin said:
Based on this, impersonation issue seems to overlap with channel binding or
lying NAS issue.
RFC 3748 Section 7.15 describes the distinction between the two problems:
Section 4.3.7 of [RFC3579] describes how an EAP pass-through
authenticator acting as a AAA client can be
Dan Harkins stated:
I don't think what you're talking about falls into the definition
of channel binding, at least not the one I have, and I wouldn't be
surprised if others (like maybe people on the IESG) agree. And I
agree with Dave, and Glen, that this isn't authentication either.
Glen Zorn said:
Yes, it is, but it doesn't have to be. In IEEE 802.1X-2004, for example,
the transition from the Authenticating state to the Authenticated state
in the PAE machine is triggered by the reception of an Accept message from
the Back-end authentication server, not by EAP-Success.
Dan Harkins said:
When there are 3 parties involved in this 2 party protocol it is
justified by saying that the EAP server trusts the NAS so there is no
security issue when MSK is disclosed to it. But what NAS identity does
the EAP server trust? The peer and EAP server derive a shared key and
for
Joe Salowey said:
#18: Internationalization
Is the use of UTF-8 sufficient or is other tagging necessary. The
following cases need to be considered:
1. Usernames and passwords
2. Prompts and error associated with username and password
authentication
3. Other textual data
It's important
RFC 2759 Section 4 states:
The Name field is a string of 0 to (theoretically) 256 case-sensitive ASCII
characters which identifies the peer's user account name.
This text, if taken literally, would imply that the name field cannot natively
support international character sets.
Yet
RFC 5216 describes the relationship between the MSK and the receive
and send keys (which was how the MSK was originally defined
in RFC 2716):
Enc-RECV-Key = MSK(0,31) = Peer to Authenticator Encryption Key
(MS-MPPE-Recv-Key in [RFC2548]). Also known as the
PMK in [IEEE-802.11].
But Section 3.3 of RFC 3079 is not about EAP. It does specify how to
calculate a 128-bit MasterKey, a 128-bit MasterSendKey, a 128-bit
MasterReceiveKey, a 128-bit SendSessionKey, and a 128-bit
ReceiveSessionKey. But how to get an EAP MSK from those is not
specified.
RFC 5216 describes the
Tim --
This works for me.
Thanks (to you and other members of the IESG) for putting in the time to get
this right.
===
Folks,
As the AD that sponsored publication of the EAP-FAST documents under
discussion,
I have been trying to find the best way
Jouni Malinen said:
This looks like an appropriate text to add. However, I would request a
small clarification on the exact scope of the different EAP-MSCHAPv2 and
EAP-GTC behavior. As far as EAP-FAST-MSCHAPv2 vs. EAP-MSCHAPv2 is
concerned, I would expect that EAP-FAST-MSCHAPv2 is actually used
:29:34PM -0800, Bernard Aboba wrote:
Are you suggesting that the version of EAP-MSCHAPv2 described in the
document differs in terms
of the MSK/EMSK derivation? Or are you suggesting that further details are
needed on how padding
is accomplished with respect to ISK derivation?
Former
Dan Harkins said:
draft-cam-winget-eap-fast-provisioning claims a reference to RFC 5226
but nowhere in that RFC can I find description of the following label
for an initial assignment of repository values:
allocated for management by Cisco
yet the draft instructs IANA to set aside values
IESG Note: EAP-FAST has been implemented by many vendors and it is
used in the Internet. Publication of this is intended to promote
interoperability, even though the use of the EAP-MSCHAPv2 and
EAP-FAST-GTC EAP methods might be difficult in some software
environments. If
Dan Harkins said: draft-cam-winget-eap-fast-provisioning claims a reference
to RFC 5226 but nowhere in that RFC can I find description of the following
label for an initial assignment of repository values: allocated for
management by Cisco yet the draft instructs IANA to set aside values
The IETF emergency services architecture depends on the ability to determine
user location
so that it can be transmitted to the Public Service Access Point (PSAP).
In a number of situations, user location is determined based on information
provided by
network access infrastructure. For
to operators or cost to equipment providers?
--
t. charles clancy, ph.d. eng.umd.edu/~tcc
electrical computer engineering, university of maryland
Bernard Aboba wrote:
Overview: This version of the document still has some issues remaining.
Section 1
The so
Alan DeKok said:
Or, it was easier to say 'ASCII', and to avoid any unknowns that might
occur of 8-bit data is used.
Given Stefan's test of MS-CHAP ISO-8895-15 encodings, I think the
ASCII limitation in the spec is not matched by any similar limitations
in the code.
Unfortunately, in at
Alan DeKok said:
[BA] RFC 4282 actually proposes that the realm portion of the NAI be
encoded in punycode, not UTF-8.
That's just wrong.
[BA] I agree. I don't know of any EAP peers that encode the NAI this way
(although, based on Stefan's tests, they may not use UTF-8 either).
...it is
I think we’ve got a problem here :(
Stefan Winter said:
“I'm currently trying to figure out what would happen if a AAA roaming
consortium (802.1X based, using EAP and RADIUS) were to use IDNs in its NAIs,
i.e. a user name like lieschen at müller.de. I was kind of expecting to see
Section 4.1.1 of the Tunnel Method Requirements document includes the following
statement:
In addition, the tunnel method MUST support EAP channel bindings to
enable a system based on EAP to meet the additional requirements in
Section 3 of RFC 4962.
While I have no problem with
Overview I have read this document and have found several major issues with it.
As a result,I don't think it is currently suitable for adoption of an EMU WG
work item. Issues: a. Mistatement of the 'Lying NAS' problem. The 'Lying
NAS' problem does not just concern the issue of whether the
[Joe] Jari had asked to keep this open to TLS. I think he was
suggesting it could be done as a TLS extension and would not require
tunneling. I agree that we do not want to extend EAP-TLS to do
tunneling.
How about:
- Enable a TLS-based EAP method to support channel bindings. This item
will
In re-reading this charter, I still don't think we're quite there:
a. Why is there still a charter item for EAP-TLS? This work hasbeen
completed, no?
b. Attempting to extend EAP-TLS to support tunneling or channel bindings
is not appropriate. EAP-TLS already widely deployed, with large
I also do NOT approve of the current charter revision, for several reasons:
a. The Charter text contains statements that are no longer true. For example:
Most of these methods are proprietary methods and only a few methods
are documented in RFCs.
The following EAP methods are now documented
Chris Newman has filed an IETF DISCUSS comment on RFC 2716bis Section 2.4.
The text of this section reads as follows:
2.4. Ciphersuite and Compression Negotiation EAP-TLS implementations MUST
support TLS v1.0. EAP-TLS implementations need not necessarily support all
TLS
[Joe] It seems there is a lot of complexity here. It seems that being
able to validate the server's root would be sufficient in most cases.
At least there is some trust chain back a server, validating the SSID at
this point does not seem to add too much.
Assuming that the selected SSID
@ietf.org
CC: [EMAIL PROTECTED], Bernard Aboba
[EMAIL PROTECTED]
Subject: Draft liaison response for IEEE 802.11u EAP method for
emergency calls
Date: Sun, 16 Sep 2007 22:26:36 -0700
The EMU working group has a liaison request from IEEE 802.11u on EAP
methods for emergency calls. The liaison
Hao said:
Sorry, I mistyped. I meant to say why not keep the approach used in RFC2716?
What's the reason for the change in 2716Bis?
[BA] I would agree that the approach used in RFC 2716 is preferrable. As to
how the change got into RFC 2716bis, it appears to have been introduced in -01;
RFC 3280 Section 4.1.2.6 says:
Conforming implementations generating new certificates with
electronic mail addresses MUST use the rfc822Name in the subject
alternative name field (section 4.2.1.7) to describe such identities.
Simultaneous inclusion of the EmailAddress attribute in
- From:
Bernard Aboba [mailto:[EMAIL PROTECTED] Sent: Thursday, June 07, 2007 7:54
AM To: emu@ietf.org Subject: [Emu] Issue: Encoding of NAIs within EAP-TLS
certificates RFC 3280 Section 4.1.2.6 says:Conforming
implementations generating new certificates with electronic mail addresses
It has been pointed out by Paul Funk that the key generation formula specified
in RFC 2716bis could cause backward compatibility problems once TLS v1.2 is
introduced.
The formula in -09 is as follows:
MSK(0,63)= TLS-PRF-64(TMS, client EAP encryption,
client.random
: Bernard Aboba [mailto:[EMAIL PROTECTED] Sent: Thursday, June 07, 2007
3:05 PMTo: [EMAIL PROTECTED]: [Emu] Issue with RFC 2716bis key generation
It has been pointed out by Paul Funk that the key generation formula specified
in RFC 2716bis could cause backward compatibility problems once TLS v1.2
At the EMU WG meeting, we discussed the situation where more than one
altsubjectName or subject field are present in a certificate. Here is some
text which can be added to the end of Section 5.2 to address this issue:
It is possible for more than one subjectAltName field to be presentin a
The following question has come up in the WiMAX Forum with respect to
EAP-TLS peer certificate usage:
From RFC 3280:
When the subjectAltName extension contains an Internet mail address,
the address MUST be included as an rfc822Name. The format of an
rfc822Name is an addr-spec as
I agree with Lakshminath on this.
From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED]
Sent: Wed 4/11/2007 11:03 PM
To: Sam Hartman
Cc: [EMAIL PROTECTED]; Bernard Aboba; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [Emu] Last call comments:
draft-williams
I'm glad to hear from Steve here that there is support for publishing
TTLSv0. I would like to see that happen regardless of whether it is done
as an EMU work item or not.
My understanding is that a new version of the TTLSv0 document will be
forthcoming which will fill in some of the details
This is something that IEEE 802.11r/D5.0 is doing. R0KH-ID is set to the
identity of the NAS Client (e.g., NAS-Identifier if RADIUS is used as
the backend protocol) and this identifier is sent to the peer during
association (before EAP authentication). In addition, both the R0KH-ID
During the meeting the group said that they want to have a password-based
only approach (no tunneled EAP support). Even CHAP etc. was left for
future work, if ever done. For this purpose PAP over TLS + room for
extensibility is just good enough.
FWIW, EAP-TTLSv0 does support non-EAP
Also, Pascal asked about a patent application. I asked Paul about
that and he said it isn't about EAP-TTLS.
Searching the IETF IPR page, I found the following disclosure, which relates
to TLS-IA, and therefore is only relevant to EAP-TTLSv1:
The latest EAP-TTLSv0 draft is available here:
http://www.watersprings.org/pub/id/draft-funk-eap-ttls-v0-00.txt
In terms of publication interest, back in the fall Jari Arkko had announced
a program to encourage widely implemented EAP methods to publish their
specifications as RFCs. As I
After listening to the IETF 68 presentation on a password-based EAP method,
I would like to voice some concerns.
Today we already have an over abundance of such methods. These include
PEAPv0, PEAPv1, EAP-TTLSv0, EAP-TTLSv1, and EAP-FAST. In my discussions
with customers, I invariably hear
What sort of benefit does this provide. If a server fails to authenticate
due to a security reason, then its EAP failure would not matter, since it
cannot be trusted anyway.
This is an optional mechanism for enabling the server to log the reason for
the error. This might allow an
Hannes Tschofenig said:
We discussed this already several times and this lead me to work on a draft
together with Thomas Otto:
http://tools.ietf.org/id/draft-otto-emu-eap-tls-psk-02.txt
Which begs the question: what is the WG doing with this draft?
From where I sit, it seems quite likely
[Joe] The KDF needs to be looked at, but I do not think it is
necessarily a show stopper, it does provide KDF agility. Reports from
people who implemented EAP-GPSK indicate that it was simple to
implement. I have heard push back from embedded system implementers on
EAP-TLS stating that it is too
According to RFC 2716, a compliant EAP-TLS implementation must support
certificates. Since the resources required to support certificates is much
larger than the resources required for TLS-PSK, a combined method would not
be optimal for use within an embedded environment. There would also be
[rmh] As for the value, EAP is not 802.11 only therefore a
device id should not be a MAC, also a MAC has locally administered and
globally adminstered versions, you would probably want to restrict the
use to the globally issued ones, then there are the privacy issues since
the MAC is used
The subject field identifies the entity associated with the public
key stored in the subject public key field. The subject name MAY
be carried in the subject field and/or the subjectAltName
extension... If subject naming information is present only in the
If possible, I'd like to include text arising from this thread in the -08
version of the document, submitted by the IETF 68 deadline.
To make it easier for me to figure out what that text is, it would be
helpful for someone to post the suggested changes in their entirety, with
modifications
Review of draft-ietf-emu-eap-gpsk-03.txt
Section 1
At present, several pre-shared key EAP methods are specified, most
notably
o EAP-PAX [RFC4746]
o EAP-PSK [I-D.bersani-eap-psk]
o EAP-TLS-PSK [I-D.otto-emu-eap-tls-psk] and
o EAP-SAKE [I-D.vanderveen-eap-sake].
Each method
I don't care about client authorization -- there should be server-side ACLs
for this.
Right.
I guess for EAP-TLS, server authorization isn't a huge deal. If an
unauthorized server is giving you access to the network, what difference
does it make to a client? The only compromise is maybe
1. Use of TLS-WWW EKU
The question was raised that the TLS WWW EKU may not be appropriate for
EAP-TLS. The suggestion was made to remove the text on EKU. Are
members of the working group in favor of removing this text?
There are a number of EAP-TLS implementations that require TLS WWW EKUs
Comparing the Server-Id in the certificate to the expected server
name limits the damage that will result from an attacker compromising
a server private key. If the peer does not check the Server-Id, then
the peer would accept a compromised server certificate chaining to
any
How about rephrasing the text to something like this?
Since the identity presented in the Identity Response need not be
related to the identity presented in the peer certificate, EAP-TLS
implementations SHOULD NOT require that they be identical.
However, if they are not
Thanks for catching this. Yes, it is a typo.
From: Jouni Malinen [EMAIL PROTECTED]
To: emu@ietf.org
Subject: Re: [Emu] WG Last Call: draft-simon-emu-rfc2716bis-05
Date: Thu, 14 Dec 2006 19:52:06 -0800
On Thu, Nov 30, 2006 at 10:28:51AM -0800, Joseph Salowey (jsalowey) wrote:
This is a
Thank you for your detailed and thoughtful review comments.
Roughly in order of importance:
1) Section 2.7: An EAP-TLS server supporting privacy MUST NOT treat a
certificate list containing no entries as a terminal condition;
instead it MUST bring up the TLS session and then send a
However, this requires more cryptographic computations
since both entities will encrypt the second TLS session packets and it
augments significantly the number of rounds trips over the wireless link,
which is not always widely available.
As you point out, the approach described in the document
One question though. I couldn't find any mention of MSK or EMSK in RFC
2716. Can you tell us how to get those keys out of that spec?
RFC 2716bis explains how the send and receive keys map to the MSK/EMSK:
http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-05.txt
[Joe] It seems that the server ID is as authenticated as the client ID.
The server ID and client ID are associated with the shared key. If a
different identity is asserted a different key would be selected and the
protocol should fail.
Since more than one AAA server can have access to the
I remember someone in Hokey WG meeting mentioned that not all methods
generate EMSK (even though they generate MSK). Is that accurate?
The simple answer is we don't know because prior to RFC 3748, EAP Type
Codes could be allocated without a specification.
However, for methods published as
: Madjid Nakhjiri [EMAIL PROTECTED]
To: 'Bernard Aboba' [EMAIL PROTECTED],
[EMAIL PROTECTED],emu@ietf.org
Subject: RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt
Date: Thu, 02 Nov 2006 18:07:29 -0800
I have a question that is somewhat related (at least what I think:))
In the privacy
Here is a strawman responding to Pasi's comments:
http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-05.txt
From: Bernard Aboba [EMAIL PROTECTED]
To: [EMAIL PROTECTED], emu@ietf.org
Subject: RE: [Emu] Comment on 2716bis: Examples in Appendix B
Date: Mon, 06 Nov 2006 16:34:37 -0800
Hi David,
I have a problem with the suggested approach for a couple of reasons:
* There is no problem with the currently defined cipher suites. The
design team has just picked something; Different cipher suites got
proposed during the design team discussions and almost all of them got
removed
AES-CBC seems like a good choice.
This might also be a decent choice for the EAP-TLS mandatory-to-implement
ciphersuite (unless the issues with 3DES can be ironed out).
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
Does the EMU WG have an issues tracker?
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
Find enclosed below some review questions from Joe Salowey. I still am
researching the answers to questions 1A and 1B, so I have not included a
proposal for these yet.
--
C.
The EMU WG charter requires that RFC 2716bis remain backward compatible with
existing EAP-TLS implementations:
- An update to RFC 2716 to bring EAP-TLS into standards track, clarify
specification, interoperability, and implementation issues gathered
over the years, and update the document to
Just a random comment:
Server identity as an opaque blog.
Many blogs are in fact quite opaque, but do we really need to force the user
to read an opaque blog as part of the protocol? :)
___
Emu mailing list
Emu@ietf.org
Furthermore if the server ignores the TLS extension the client MAY send
its certificate encrypted with its preferred
encryption algorithm (the first in the TLS extension list)
This definitely breaks backward compatibility.
___
Emu mailing list
Clearly using this within eap-tls would require some specification
work, but I think would be preferable to your approach.
The EMU WG charter states:
Backwards compatibility with RFC 2716 is a requirement.
So I'd like to understand which approach (if any) is backward compatible
with existing
98 matches
Mail list logo
