Hi! I have not been following the EMU WG closely, but I noticed that
you are working on password-based authentication. I'm gauging
interest in an effort to do a password-based protocol that supports
both GSS-API and SASL, see:
http://www.ietf.org/internet-drafts/draft-josefsson-password-auth-00.
"Joseph Salowey (jsalowey)" writes:
> "4.3.6. Internationalization of Display Strings
>
>
> The payload MAY provide a standard attribute format that supports
> international strings. This attribute format MUST support encoding
> strings in UTF-8 [RFC3629] format. Any strings sent by the server
Alan DeKok writes:
> Simon Josefsson wrote:
>> Perhaps you want to consider an approach where passwords are normalized
>> using Net-UTF-8 and usernames are sent as-is but mandate that
>> username-to-username comparisons use Net-UTF-8 on both strings before
>> compari
Alan DeKok writes:
> Simon Josefsson wrote:
>> Should we suggest that passwords are sent over the wire at all? In good
>> systems that should be the exception.
>
> It is widely deployed today with TTLS. I think that allowing this
> practice to continue is a require
Alan DeKok writes:
> Simon Josefsson wrote:
>>> It is widely deployed today with TTLS. I think that allowing this
>>> practice to continue is a requirement.
>>
>> I agree, but that does not necessarily mean that
>> passwords-sent-over-the-wire and pass
Alan DeKok writes:
> Simon Josefsson wrote:
>> Right. My point is that the one needs to weight this approach to a
>> system which does not use normalization but instead use
>> internationalized comparison rules.
>
> How do you do internationalized comparisons on
"Joseph Salowey (jsalowey)" writes:
> I'd like to see if we can close on this issue soon. The main use case
> we are targeting is one where the password is sent to the server. We do
> not know how the server will do the comparison. Given that this is a
> requirement document I don't think we
Alan DeKok writes:
> Simon Josefsson wrote:
>> I think the text proposed is mostly fine. I would say "normalization
>> and/or comparison" instead of just "normalization" to allow for
>> mechanisms that just specify comparison-based rules rather than
>
Jouni Malinen writes:
> On Fri, May 13, 2011 at 6:29 PM, Alan DeKok wrote:
>> The reason for the name change is that there have been questions
>> raised about whether this document should be left as EAP-FASTv2, or
>> whether it should request allocation of a new EAP type.
>>
>> Since the docum
Alan DeKok writes:
> https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/
Section 5.3:
The Compound MAC computation is as follows:
CMK = CMK[j]
Compound-MAC = HMAC-HASH( CMK, BUFFER )
where j is the number of the last successfully executed inner EAP
method, H
10 matches
Mail list logo
