>>>>> "Rafa" == Rafa Marin Lopez <[email protected]> writes:
Rafa> I was wondering what are the exact implications of not
Rafa> protecting the information until the EAP authentication ends
Rafa> up with a key. If certain particular flags are unset during
Rafa> the conversation because it is not protected, the negotiation
Rafa> should fail, right?. So some sort of denial-of-service problem
Rafa> will raise. Is that what you had in mind?.
If we have protection. then an attacker can cause a denial of service by
changing the negotiation.
However, in the case of the mutual authentication flag, if we don't have
protection, there is a more serious attack.
In that situation, an attacker can set the mutual authentication flag
when the mutual authentication did not happen.
The server may think the client confirmed the server's identity when
that did not happen.
We can protect this after the key is established by sending some
checksum or keyed hash that covers the flag in question.
Rafa> I say this because, as you may know, there are some EAP
Rafa> lower-layers which does not need to assume that there will be
Rafa> a pre-established protected channel to exchange EAP.
abfab is such a lower layer.
Rafa> Best regards.
Rafa> El 31/03/2011, a las 10:03, Sam Hartman escribió:
>>
>>
>> Folks, during today's meeting we discussed the need for
>> protecting information exchanged during the context exchange.
>>
>> An example of this need would be protecting context flags from
>> the client to the server. Some server implementations require
>> that certain context flags be set. As an example ssh servers
>> following RFC 4462 require the mutual flag be set. This needs to
>> be integrity protected.
>>
>> There are a number of possible options:
>>
>> 1) Integrity protect each token separately. Down side: more
>> complex especially if tokens need integrity protection that are
>> exchanged before a key is available.
>>
>> 2) Extend our mechanism to depend on a specific hash function.
>> Disadvantage: requires us dealing with crypto primitives directly
>> . Adds complexity to specificiation of the mechanisms.
>>
>> 3) Provide a gss_getmic or similar of the entire conversation.
>> The disadvantage here is that the client needs to maintain state
>> sufficient to hold a copy of the conversation. If there is a
>> stateless server, this ever-increasing state needs to be
>> transported back and forth for each message.
>>
>> --Sam _______________________________________________ abfab
>> mailing list [email protected]
>> https://www.ietf.org/mailman/listinfo/abfab
Rafa> ------------------------------------------------------- Rafael
Rafa> Marin Lopez, PhD Dept. Information and Communications
Rafa> Engineering (DIIC) Faculty of Computer Science-University of
Rafa> Murcia 30100 Murcia - Spain Telf: +34868888501 Fax:
Rafa> +34868884151 e-mail:
Rafa> [email protected] -------------------------------------------------------
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
