>> >>>>>>>> "Alan" == Alan DeKok <[email protected]> writes: >>> >>> Alan> For PCP, it's reasonable that the application knows the EAP >>> Alan> session has timed out. It can re-establish it before sending >>> Alan> the next message. Or, if messages are rare, it can wait and >>> Alan> re-establish it later. >>> >>> Well, it's a bit tricky to re-establish the session if the next >>> message is coming from the server but only the client can start the >>> authentication. >>> I think you have two general options: >>> >>> 1) Decide it's OK not to re-establish the session until the client >>> wants to do so >>> >> >> This does not make sense. If we are talking about securing a protocol, > that >> better be a complete security, not a partial security that's > uncontrollably on >> and off. In this case, when the server wants to send a message, if it's > lucky >> it'll find a live security association and send the message securely. If > it's >> unlucky (there is no live SA), then bad luck -- packet is dropped w/o >> transmission. Because sending an unsecure packet does not make sense, it's >> at best useless, at worst harmful if we expect the clients to act on them. > > > I find this to be a completely appropriate behavior. Before I left the > e-mail group at Microsoft I had just come to the realization that I no > longer believe that all email messages needed to have S/MIME signatures > verified prior to showing the message to the recipient. The validation > process could be deferred until one of a number of different trigger events > occurred. I changed groups because the Outlook group was not interested in > doing another round of changes in behavior so I never had the long > discussions to get my ideas into the program. > > However this represents a similar behavior. As a client I get a message, > would I care about the content of the message? If so then I can find out if > the message is real. If I don't care about the content of the message then > why should I care if it is real or spam? > > The act that the client is expected to do is to ask the server if the > message is real (assuming it cares) before performing operations on the > message. That seems to be a totally reasonable behavior. >
Are there real and used examples of this approach you are describing? I think it's flawed. Following your email example, I can easily see people losing nerves clicking the "authenticate this message, now!" button when seeing emails like "your cat has died!" and "you are promoted to become VP!" :-) In terms of software processing, what kind of message would the receiver not care? If it does not care, why the other end is sending that message to it… Even for understanding if the receiver cares about the packet, it needs to "consume" the payload. And that payload may already be altered enroute, since the packet is not integrity-protected. That's a security hole. Alper > Jim > >> >> >>> 2) Change things and let the server start an EAP session. >>> >>> 3) Require the client to start an EAP session whenever the old session >>> goes away. >>> >> >> 2&3 make sense. >> >> I'd say the protocol shall support the capabilities needed for both 2 and > 3. >> And leave it to the deployment to decide when to use them. >> >>> The details as they apply to PCP are best discussed on that list. >> >> >> Alper >> >> _______________________________________________ >> abfab mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/abfab > _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
