Hi Sam, El 31/03/2011, a las 14:01, Sam Hartman escribió:
>>>>>> "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. That is precisely what I had in mind. Moreover I agree with Alper about the use of EAP methods that only requires one-way authentication are not convenient at all. Even more I cannot remember now if there is any EAP method with one-way authentication which export keys and can be considered as a secure solution. > > 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. I know abfab is the lower-layer, but I thought the discussion was related with the possible need to protect the abfab lower-layer BEFORE the EAP authentication. > > 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] ------------------------------------------------------- > > > > > ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: [email protected] ------------------------------------------------------- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
