It seems we might achieve this goal and the two other work group
items, TLS-based EAP method and existing password database support,
using a single EAP method, e.g., a TLS based EAP method supporting PSK.
One of the attractions of PSK is to implement it on an embedded device. So
while it is p
the specific characteristics of these environments elaborated. Second,
intended / future
application scenarios should be taken into account (mesh networks, p2p,
...).
Thomas is correct that RFC 4017 only expresses requirements for WLAN
authentication in IEEE 802.11 infrastructure networks. Ho
But could not EAP-TLS be modified/updated to also allow "pure" TLS-PSK,
without requiring use of server certificates? AFAICS this would still be
TLS, not "TLS-derived" or "based on TLS".
RFC 2716 requires support for certificate authentication. Making this
optional would break backward compa
>> But could not EAP-TLS be modified/updated to also allow "pure"
>> TLS-PSK, without requiring use of server certificates? AFAICS
>> this would still be TLS, not "TLS-derived" or "based on TLS".
Bernard, I think a simpler and more constructive way of saying what
you're trying to say
We've made an initial start on RFC 2716bis which should be showing up on the
archive soon:
http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-00.txt
This first draft mostly focusses on cleaning up "PPP"isms, updating
references and examples, etc.
Next step is to identify EAP TLS i
5. Security Considerations
This needs more work, to fill in the descriptions required by RFC 3748.
Right. Here are the claims that I think can be made:
Auth. mechanism: Certifications
Ciphersuite negotiation: Yes
Mutual authentication: Yes
Integrity protec
The ICV is computed as the MAC over the entire EAP packet, including
the EAP header, the EAP-PAX header, and the EAP-PAX payload. The MAC
is keyed using the 16-octet ICK, using the MAC type specified by the
MAC ID in the EAP-PAX header. For packets of type PAX_STD-1,
PAX_SEC-1, PA
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
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
Emu
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
https://www1.ietf.org/mai
Do we know what the client and server implementation problems with TLS
extensions are?
At IETF 65, Yngve Petterson gave a presentation relating to TLS
interoperability issues:
http://www3.ietf.org/proceedings/06mar/slides/tls-6.pdf
Slide 3 states:
Many SSL/TLS server implementations are brok
Yes, I just listed the first one. If PSK does not match, server will
find an incorrect MAC in GPSK-2. What should it do? Just send EAP-Failure?
I would recommend silent discard for packets with MAC failures, since that
is most resilient against forgery. Otherwise, an attacker only needs to
co
If the EAP Server silently drops EAP-Response/GPSK-2, then how would the
client know the PSK is incorrect? Would the conversation just time out?
Yes.
Perhaps we should add a "MAC Failed" message as Jouni suggested? Sending it
would leave the server state unchanged.
What is the peer supposed
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 me
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.
I will add some text on this vulnerablity, which is enabled because some
TLS-based methods share the same key-derivation formula.
How about this?
"4.6. Packet Modification Attacks
The integrity protection of EAP-TLS packets does not extend to the
EAP header fields (Code, Identifier, Lengt
[Joe] OK, I'm not sure we need to include text about the key derivation.
If it is the key derivation that is the only difference then change will
only be caught after the completion of the method if the keys are used.
The problem is that if the EAP-TLS key derivation formula is re-used in an
an
[Joe] OK I think this is good. How does 1.1 and 1.2 impact backwards
compatibility?
I don't think we know yet. To get clarity, we need to do some tests. It is
possible that only a subset of the problems that Y. Pettersen describes in
his draft afflict TLS-based EAP methods:
http://www.wate
No objection.
On 7/20/06, Joseph Salowey (jsalowey) <[EMAIL PROTECTED]> wrote:
At IETF 66 EMU working group meeting there was consensus to take on
draft-clancy-emu-eap-shared-secret-01.txt as a working group item.
Are there any objections to taking this on as a working group item?
Thanks,
Jo
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
let us for a moment assume that RFC 4307 makes some reasonable algorithm
choices (we are talking about IKEv2 here). If we take the text and apply it
to EAP-GPSK then we would produce something like:
Conservative Choice:
---
(Integrity)
AUTH_HMAC_SHA1_962
At IETF 66, we discussed a number of issues, including:
o Optional privacy support
o Ciphersuite support
o Changes from RFC 2716
I've updated RFC 2716bis to include a new section 2.7 on privacy, have
clarified the ciphersuite requirements, and have included an Appendix A on
changes from RFC 27
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 f
Can you be a bit more specific? Are you talking about mixing of client and
server nonces or something else?
From: "Joseph Salowey (jsalowey)" <[EMAIL PROTECTED]>
To:
Subject: [Emu] GPSK issue - KDF Data
Date: Tue, 3 Oct 2006 15:18:49 -0700
The current GPSK draft includes the capability for
this aspect refers to the ability to put arbitrary data exchanged between
the end points into the key derivation function.
It is therefore not about the nonces, identities etc. that is typically
incorporated into the key derivation function.
Why would someone want todo this? I don't think it
I have updated RFC 2716bis with a list of changes, added a section on
privacy, rewritten the key hierarchy section to utilize modern terminology
(MSK, EMSK), and updated the security considerations section.
The updated document is available here:
http://www.ietf.org/internet-drafts/draft-simon-
The document should also state in the security considerations section
that the identity in the identity response is not necessarily related to
the identity authenticated in EAP-TLS and should not be relied upon for
any access control or accounting purposes.
Here is some proposed new text for Sec
Joe Salowey said:
Currently the section states that the peer
identity is obtained from the subjectAltName in the certificate. Is
this text meant to be normative?
Currently there are implementations
that use elements of the subject distinguished name and do not provide a
subjectAltName.
Perhaps
During the EMU BOF we talked about the high cost that would be imposed on
customers by introducing new non-certificate ciphersuites during EAP-TLS.
EAP-TLS is now ten years old, and has a very large installed base.
Virtually all of these installations only support certificate-based
authentica
Should the split be EAP-TLS-v1 (PKI only) vs EAP-TLS-v2 (PKI and PSK)? Or
EAP-TLS-PKI and EAP-TLS-PSK? If we have both legacy issues AND footprint
issues, perhaps something like ...
So far, we've talked about handling PSK support by creating a new EAP method
with a distinct name: "EAP-TLS-PSK
By certificate-based ciphersuites, do you mean TLS_RSA_WITH_*
ciphersuites from RFC 2246 specifically, or any ciphersuite that
uses any kind of certificates?
Any ciphersuite supporting client certificate authentication would be ok.
(To me it looks like many of these arguments would also sugges
>A valid EAP-TLS client certificate SHOULD contain an
> extendedKeyUsage
>value indicating support for Client Authentication
>(1.3.6.1.5.5.7.3.2). A valid EAP-TLS server certificate SHOULD
>contain an extendedKeyUsage value indicating support for Server
>Authentication (1.3.6.
client sends change_cipher_spec/finished twice?
I think the client will send the Alert at that point, no?
I don't see how this message sequence could ever occur.
It is possible for a session resume attempt to fail, but if so, it will not
look like the example. A client could mistakenly att
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,
On re-reading Section 2.3 on Fragmentation, I realized that it still
contained some PPP-centric material (such as discussion of negotiation of
PPP Multilink MRRU).
Here is an updated section that hopefully addresses your comment:
"2.3. Fragmentation
A single TLS record may be up to 16384
: 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 w
Hi Yoshi,
As Alper pointed out in the text from RFC3748, it is not optional to
produce an EMSK. Its usage is undefined at the moment, but, a compliant
implementation should be producing the EMSK, nevertheless.
It's worth keeping in mind that there are very few existing RFC
3748-compliant EAP im
If we are going by existing implementations, there is probably
more than one flavor and then there is the question of when the MSK is
directly delivered to the authenticator and when it isn't and how the
peer knows that.
The Wifi Alliance (WFA) WPA2 certification includes EAP interoperability
t
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 R
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 crede
Sounds reasonable, but I'm not entirely sure I'd call the ID_Server
unauthenticated. It's authenticated in GPSK-3 when the server includes it
in the key derivation to compute SK. If the value was changed by an
attacker, the authentication would fail.
The client only confirms that the server
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 i
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 server_hell
Here are some of the changes to deal with the privacy comment. Let me know
if this resolves the issue.
In Section 2.6:
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
I think I have now incorporated most of these comments into a strawman -06
document:
http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-06.txt
Let me know if I've missed something.
From: <[EMAIL PROTECTED]>
To:
Subject: [Emu] WGLC comments for draft-simon-emu-rfc2716bis
Date: Mon,
ecify mandatory-to-implement TLS
version (which is required in addition to mandatory-to-implement
cipher suite to get interoperability).
About 11: The S bit was removed from the bit diagram, but the text
"The S bit (EAP-TLS start) is set in an EAP-TLS Start message" is
still there.
Best
> 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 ide
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 wor
>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
>
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 (o
On the EAP WG list, Lakshminath Dondeti has pointed out the problems with
including a copy of the RFC 3766 Key Strength table in another document:
"Section 3.7 has a copy of the attack resistance table from RFC 3766. It
is sufficient to provide a reference to that RFC. There is no need to
repr
How about including:
"Some deployments may require the presence of client and server
authentication extended key usage extensions in certificates. Client
implementations wishing to interoperate in these environments SHOULD
check the server's certificate for an Extended Key Usage field
implementa
What about RFC 4334?
As far as I know, no EAP-TLS implementation supports RFC 4334 and I don't
think we should be encouraging implementers to support it.
The OIDs defined in RFC 4334 do not correspond to values of the
NAS-Port-Type attribute, so the backend authentication server certificate
So your objection is that essentially different lower layers have been
hard-coded into 4334 (PPP and EAPoL), and consequently into the cert
handling code, such that new RFCs and new code would be required to
support EAP over different L2/L3 technologies?
The problem is that the RFC 4334 lower la
I don't see anything in RFC 3748 saying a peer CANNOT send an EAP-Failure,
but perhaps it would be better for GPSK to respond with another
GPSK-Failure message, and then have the sever send the EAP-Failure.
RFC 3748 Section 4.1 says:
The peer MUST send a Response packet in reply to a valid R
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 that
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 h
Question:
What about a device that has a MAC address as a name? Use of EAP-TLS with
MAC certificates is being discussed in WiMAX Forum and IEEE 802.1AR. Where
should the MAC address be placed (subject vs. subjectAltName) and what field
type should it have? Is there a reference that defines
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 ag
From the discussion it seems that if OCSP is a SHOULD implement, then we
need a MUST for revocation checking after authentication, since some servers
might not implement OCSP, right? I don't think we can add "MUST use" text
for something that is a "SHOULD implement".
In terms of usage, it is p
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
subjectAlt
[Joe] What is the issue?
I'm not sure. That's why I asked about text :)
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
[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
[Joe] I don't see any more confusion over having multiple serial numbers
than having multiples of any other attribute.
Placing multiple identities into a peer certificate represents an assertion
that the identities are equivalent. If they are not equivalent, then they
should be placed into se
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
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 t
[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
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 administrator
CBC mode is much more widely available in libraries than CTR mode. RFC 3723
specified CTR mode and this was probably a mistake.
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
Getting more details on this would be interesting for other reasons,
too, since there are new designs (e.g., IEEE 802.11r) which are using
HMAC-SHA256 -based KDF. Since the 802.11r KDF construction is also
claimed to be compliant to NIST recommendations, it is somewhat odd to
see EAP-GPSK take the
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
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 recal
Part of the problem with EAP methods is that people should have started to
standardize them within the IETF several years ago. Unfortunately, there
was no interest by some of the EAP method authors nor from the EAP WG
chairs to allow that.
In fact, the IETF was on track to standardize EAP meth
I'm not sure that adding yet another version to TTLS specifically for
supporting passwords will make things better for customers. Multiple
versions certainly has caused quite a confusion in PEAP.
I would agree that "versioning" is not a good idea. However, as I
understand it, EAP-TTLSv0 is th
For example, at least one server uses "client PEAP encryption" as the
label for PRF whereas most use "client EAP encryption". That is clearly
an interoperability issue (I've only seen this with PEAPv1 and one
RADIUS server, but anyway that is the label described in some of the
drafts).
Using the
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 authenti
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:
https://datatracker.ietf.org/public/ipr_detail_show.
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 tha
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
(NAS-Identifier
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 am ready to organize a meeting in Paris in June, if the working group
intends to debate about >these points
Paris in June (or any time, really) sounds wonderful. However, if the idea
is to focus people on work, without the distractions created by art, music,
good food and inspiring archit
The emu working agreed on the fact that a secure channel is needed
Item1.
- a) Is there a consensus for TTLS (what version ?)
- b) Is this possible to push TTLS as an RFC (from an IT point of
view)
Item2
-c) Do we need a new password based method ?
I agree with Bernard point
To refresh people's memories, here is what is in Section 5.2:
5.2. Peer and Server Identities
The EAP-TLS peer name (Peer-Id) represents the identity to be used
for access control and accounting purposes. The Server-Id represents
the identity of the EAP server.
In EAP-TLS, the Peer-Id
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 defin
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 p
A question has arisen about the reference to RFC 2818 section 3.1 within
Section 5.3:
When performing this comparison implementations MUST follow the validation
rules specified in [RFC2818] Section 3.1. In the case of the server this
involves ensuring the certificate presented by the
n a peer or server> certificate. In this case, EAP-TLS may export
> more than one Peer-Id> or more than one Server-Id; all of the exported
> Peer-Id(s) and> Server-Id(s) are considered > valid. "> > >
> > > From: Bernard Abob
ent with RFC 3280 if we report a> non-empty
> subject name as well as the subjectAltNames since they all> are valid
> identities within the certificate. > > > -Original Message-----> > From:
> Bernard Aboba [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, May 08
I was looking at Section 5.3 in RFC 2716bis, and I noticed that while RFC 3280
conformant path validation is recommended for EAP-TLS servers, there is no such
recommendation for EAP-TLS peers. This seems odd. For example, Section 5.3
states: Since the EAP-TLS server is typically connected to
It has been pointed out that an EAP-TLS certificate can contain multiple
subject or subjectAltName fields. To address this, I propose that we add the
following text to Section 5.2:It is possible for more than one subjectAltName
field to be presentin a peer or server certificate. Where more th
Also, it has been pointed out that the purpose of the Peer-Id/Server-Id may not
be fully explained, so that the following sentence may also need to be added to
Section 5.2:
"Together the Peer-Id and Server-Id name the entities involved in
deriving the MSK/EMSK. "
__
ed valid. "
>
> Thanks,
>
> Joe
>
> > -Original Message-----
> > From: Ryan Hurst [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, June 06, 2007 4:17 PM
> > To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org
> > Subject: RE: [Emu] Propose
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 the
ame elements.> > > -----Original Message-> > 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 S
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 is
a reason why we changed to TLS-PRF-128 for the
> MSK? > Is this a huge issue given that there are not likely any existing>
> implementations of EAP-TLS using TLS 1.2?> > Joe> > > > -Original
> Message-> > From: Bernard Aboba [mailto:[EMAIL P
entations based on TLS> 1.2 will use. These
implementations should interoperate with one> another. > > I'm not sure where
the problem is. > > Joe> > > -Original Message-> > From: Bernard Aboba
[mailto:[EMAIL PROTECTED] > > Sent: Thursday, Jun
1 - 100 of 208 matches
Mail list logo
