Bernard Aboba wrote:
> In addition adding new non-certificate modes would impose large
> costs on customers. Today there are interoperability and conformance
> test suites for EAP-TLS that assume that only certificate-based
> authentication is supported.
>
> In addition, EAP-TLS has been approved f
Section 2.1 contains a lot of text like "encapsulate one or more TLS
records in TLS record layer format, containing a TLS client_hello
handshake message."
RFC 2246 also says that "multiple client messages of the same
ContentType may be coalesced into a single TLSPlaintext record,
or a single mes
First of all, I'd suggest numbering the examples in Appendix B, or
dividing Appendix B to subsections (this would make reading and
commenting them easier).
1) 2nd example ("In the case where the peer and server support privacy
and mutual authentication, the conversation will appear as follows"):
i
Bernard Aboba wrote:
>
>> client sends change_cipher_spec/finished twice?
>
> I think the client will send the Alert at that point, no?
TLS doesn't really specify when the alerts should be sent. For
example, if the client doesn't accept the server's certificate, IMHO
the most logical sequence w
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_hello
followed by a certificate_request."
Not quite correct... Th
Bernard Aboba wrote:
> >4) Section 2.4, "SHOULD NOT use the identity presented in the
> >Identity Response for access control or accounting purposes": is
> >using unauthenticated information for access control or accounting
> >purposes really something where we think "there may exist valid
> >reas
Thanks for handling my comments so quickly! (If every author had this
fast turnaround times, IETF would get documents to RFCs in a fraction
of current time... :-)
About 1: the figure in 2.6 is not quite right yet. There should be
a finished message after the first change_cipher_spec sent by the
s
I'm fine with this text.
Best regards,
Pasi
-Original Message-
From: Bernard Aboba [mailto:[EMAIL PROTECTED]
Sent: Monday, April 16, 2007 11:25 AM
To: Joseph Salowey (jsalowey); emu@ietf.org
Subject: RE: [Emu] RFC 2716bis Section 5.2. Peer and Server Identities
To refresh people's memor
Joseph Salowey wrote:
> RFC4383 is a superset of RFC822. If a name does not conform to
> RFC822 then it will not be compliant with RFC3280. Within a
> specific community where everyone has a common understanding of how
> the extension will be used then this is probably OK. If you plan on
> usin
Bernard Aboba wrote:
> The problem is that RFC 2716 specifies the use of TLS-PRF-128. If
> TLS v1.2 negotiates a PRF where PRF-64 is not the same as the first
> 64 octets of PRF-128 (the IKEv2 PRF is an example of such a PRF),
> then RFC 2716bis implementations will not interoperate with RFC 2716
Charles Clancy wrote:
> See comments inline. An updated draft will be released shortly.
> Also note that the new draft addresses Dan's comments about
> resistance to dictionary attack.
Thanks for the update! I have some additional comments (see below),
but they should be easy to address.
> >
Hannes Tschofenig wrote:
> > As Dan Harkins already pointed out, NIST 800-38B does define CMAC
> > for 256-bit AES, with 256-bit key and 128-bit output.
> >
> > So hardcoding this assumption in EAP-GPSK seems to limit the future
> > algorithm agility somewhat -- is the WG sure this is an acceptab
Charles,
Thanks for the update! There's one change I'm slightly worried
about:
Version -10:
For GPSK-3, a peer MUST silently discard messages where the
RAND_Peer, the RAND_Server, or the CSuite_Sel fields do match
those transmitted in GPSK-2.
Version -11:
For GPSK-3, a peer MUST si
The liaison statement from ITU-T SG 17 on X.1034 ("Guideline on
extensible authentication protocol based authentication and key
management in a data communication network"), which was briefly
discussed in SAAG and EMU meetings, is now available here:
https://datatracker.ietf.org/liaison/466/
Joe
Klaas Wierenga wrote:
> 4.5.1.3 server credential revocation checking
>
> Perhaps with the exception of the Grid community there is no use of
> OCSP (let alone SCVP) as far as I know, and popular implementations
> of SSL don't implement it. I understand the requirement but I am
> afraid this is t
It's not really the "key derivation approach" as is, because the key
derivation is happening outside EAP -- it's part of the revised AKA'
algorithms that are used for other things than EAP. (This is why the
"information exchange" approach was not possible.)
Also note this text in Section 5:
Chris Hessing wrote:
> 1. EAP-FAST feeds the client and server random in to the TLS PRF in
> the opposite order that TTLS and PEAP do. I can't think of a good
> reason to do this. Is there some security advantage to doing this?
> If not, why require implementations to handle this case for no rea
Chris Hessing wrote:
> For anonymous provisioning, it also seems there is a pretty large
> security hole. It is smaller than the security issues with LEAP,
> but is still rather large.
>
> With anonymous provisioning the supplicant has to implicitly trust
> the authentication server it is talking
I would like to remind everyone that these documents did go through
IETF Last Call, and have already been approved by IESG.
If folks are opposed to publishing descriptions of deployed EAP method
when they're less than perfect (or even ugly hacks with bad architecture),
and may not offer perfect se
Dan Harkins wrote:
> If the IESG doesn't want to hear opinions then maybe it shouldn't
> ask. Since it did (this thread started with a post from "the IESG")
> then it should listen to the opinions it solicited. With all due
> respect, don't shut off this discussion with a "reminder" that these
Glen Zorn wrote:
> > I would like to remind everyone that these documents did go
> > through IETF Last Call, and have already been approved by IESG.
>
> Given the quality of the documents in question, perhaps that's not
> something that you should be bragging about...
>
> > If folks are opposed to
Glen Zorn wrote:
> Ok, so now I'm totally confused. None of the examples you cite are
> IANA registries & I would have no problem w/Cisco handing out
> numbers for their proprietary protocol, but that's not what they're
> doing. What they're doing is establishing an _IANA registry_ but
> retaini
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?
Hmm.. it seems the EAP-MSCHA
Bernard Aboba wrote:
> > 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
> > s
> -Original Message-
> From: ext Georges Sebek(ITU-T SG 17) [mailto:tsbs...@itu.int]
> Sent: 16 October, 2009 20:14
> To: al...@freeradius.org; al...@deployingradius.com; jsalo...@cisco.com
> Cc: Eronen Pasi (Nokia-NRC/Helsinki); tim.p...@nist.gov; p...@cisco.com;
> tsbs...@itu.int; pmwesi
25 matches
Mail list logo
