> A tunnel method draft has been submitted:
>
> http://tools.ietf.org/id/draft-salowey-emu-eaptunnel-req-01.txt
>
> A separate call for consensus will be issued for this document.
RFC3748 (section 2.1) states:
However, the peer
and authenticator MUST utilize only one authentication me
Me too.
josh.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Pascal Urien
> Sent: 20 June 2008 18:03
> To: emu@ietf.org
> Subject: Re: [Emu]   EMU WG Consensus call on Â
> acceptanceofthetunnelrequirements draft as  a work item
>
> I
Hi Stefan,
> 3.1 Password Auth
> --
>
> "support for minimal management tasks including password
> change". I fail to see why a management mechanism to *change*
> the password is needed
> *during* the authentication... ?
This is a desirable property IMHO. It's not unusu
> > The alternative is for supplicants to simply start using UTF-8.
> > It's likely a good idea, in any case.
> >
>
> Yes, I'd be very happy if supplicants did that. Obviously
> some refrained from doing it so far, and I don't think there
> is a lot of incentive to make them change their
FWIW, Kerberos has a similar problem (with different but similarly
obscure origins); see Section 5.2.1 of RFC4120 for some background. The
Kerberos WG is currently chartered to fix this, but there's not been
much movement yet AFAIK.
It occurred that to me that EAP & Kerberos implementors might app
Chris,
> 2. EAP-FAST modifies the documented behavior of both MS-CHAPv2 and
> GTC. For MS-CHAPv2 again it is unclear why the changes are needed.
> What is the advantage of seeding MS-CHAPv2 with data from the
> outer tunnel?
I'm not at all familiar with EAP-FAST but I expect this is intend
> A sets up an EAP server with "EAP-Fraud" method which merely
> tunnels IP in EAP, installs supplicant with EAP-Fraud support
> on his clients.
This approach has some precedent, albeit in a slightly different
context.
http://thomer.com/howtos/nstx.html
josh.
JANET(UK) is a trading name of Th
> With non-web devices, it's becoming more common to have
> 802.1x as a second authentication option, beyond the splash
> page. (indeed, just yesterday I got word that my employer is
> transitioning to this, and this is how many, if not most,
> European universities work).
Speaking for my own
(Apologies for cross-posting)
I am pleased to announce the release of the Moonshot GSS EAP mechanism
implementation under the BSD licence, and the relicensing of PADL Software's
Cyrus SASL GS2 implementation to the BSD licence. These implement
draft-ietf-abfab-gss-eap-00 and RFC5801 respectivel
Apologies for the delayed response.
>>>The question IMHO is: there are many inner EAP methods specified
>>> already, and they don't typically specify or signal most of the error
>>> conditions below to the EAP peer. The TEAP document can't impose change
>>> on all those inner methods; they are wha
Joe,
Thanks for this. This looks good, but I am missing:
- User account credentials incorrect
- User account credentials change required
And also (using "Inner method" to disambiguate inner method CB from TEAP's
own CB):
- Inner method's channel binding data required but not supplied
- Inner m
>>
>>- User account credentials incorrect
>> - User account credentials change required
>
>[Joe] I am concerned that these error messages reveal too much
>information to an attacker.
I agree there are risks if used inappropriately, but nonetheless there are
reasonable uses for these (for example,
Internal CA Error
>
> 1027 General PKI Error
>
> 1028 Inner method's channel binding data required but
> not supplied
>
> 1029 Inner method's channel binding data did not
> include
Sam,
I agree with your conclusion. There are example of lower layers using
EAP-based ephemeral keying, and ABFAB could perhaps look to those for
inspiration and perhaps reuse.
Josh.
On 16/11/2013 02:25, "Sam Hartman" wrote:
>
>Hi.
>At the most recent ABFAB meeting I brought up the idea of addi
>
>> Interesting thought, and a bit complex. I suggest we discuss this when
>> the draft gets adopted in ... "some" working group. Suggestions welcome
>>:-)
>
> I'd support a "roaming inter-operations" WG. Some of the documents
>now in RADEXT could move there, and maybe DIME. This document could
This may be a stupid question, but I can’t find an explanation in the draft or
figure it out myself... If the intended application for this TLS extension is
network access, might it be simpler to define a new EAP method that used a
similar key exchange? That would avoid touching implementations
is able to authenticate and
enrol devices. Is this your understanding?
Josh
From: Dan Harkins
Sent: 25 July 2020 18:49
To: Josh Howlett; emu
Subject: Re: [Emu] TLS-pok for EAP
Hi Josh,
TLS-pok is a one-off. It's not for network access, it's to use a
trusted public key bootstrap
17 matches
Mail list logo
