Tero Kivinen <[email protected]> wrote on 01/20/2011 06:41:02 AM: > I do not really think reauthentication offers anything as in most > setups the IKEv2 authentication information is stored in the machine > itself and does not require any user interaction (i.e. shared keys in > the configuration file, or the private key on the disk). > > The reauthentication only does mean something in case you are using > EAP or private key authentication based on some kind of removable > token (smart card etc). If the client is able to store authentication > information and replay that when server requires reauthentication then > reauthentication does not provide anything. You could simply just ask > from the other end "is the user still there", and the other end can > say "yes", or "no" without providing any proof. > > If you are using external token based system like private keys on > smartcards then reauthentication gives server a proof that user really > did leave the card inserted to the machine. It still does not provide > proof that user is still sitting in front of the machine (as most > smartcards do keep pin codes etc stored as long as you do not remove > the card). > > If you use EAP with one time passwords or similars where it actually > do require user to type in new code every time then user have much > harder time to fake the system especially if user cannot get future > one time passwords before their time (otherwise he could just type in > next n passwords the system might be asking). > > So the draft should have good rationale explaining in which kind of > situations this is actually useful. I do assume that the security > model is something that the user is not be trusted, and most likely > the user's machine isn't to be trusted either. > > At least if you plan to go to standard track you better explain why > this is needed. > > As I said I have not read the draft, so it might be you have the text > there, so if so very good... The draft does list some problems with reauthentication as defined in RFC 5996 but it doesn't say why one might do reauthentication in the first place. RFC 5996 says, "Although rekeying the IKE SA may be important in some environments, reauthentication (the verification that the parties still have access to the long-term credentials) is often more important." One use case that occurs to me is detecting that the peer's certificate has been revoked. If you just rekey the IKE SA forever you would not detect that.
> > > 2. There is one point I'd still like technical input on, namely the > > security considerations of signing the previous AUTH payload sent by the > > host in the modified IKE_AUTH exchange (section 5 of the draft). Yoav > > suggested this approach, it sounded fine to me, I ran it by a couple of my > > colleagues (Scott Moonen and David Wierbowski) who thought it sound fine > > too so I used it in the new draft. I'd feel better if another subject > > matter expert said, "yes, that is fine." Bonus points if the SME can > > offer a sentence or two justifying why this mechanism is as secure as the > > authentication operation that takes place during the initial exchanges. It > > would be nice to include that information in the security considerations > > section of my draft. More specifically, RFC 5996 section 2.15 > > "Authentication of the IKE SA" says, "It is critical to the security of > > the exchange that each side sign the other side's nonce." Is it necessary > > to include nonces in the signed data in the proposed modified IKE_AUTH > > exchange? I don't think so, but since I don't know why it was necessary > > as part of the signed data in the initial exchanges I don't feel qualified > > to assert that formally. > > In the initial authentication the signing of the IKE_SA message proofs > that nobody has modified those packets. Note, that it does not sign > the IKE_AUTH message, as it is protected by the Integrity Checksum > Data field. So the signing of the message data is there just to > provide MAC for the first packets which are not MACed normally. > > The real authentication happens when node signs the other ends nonce > and his own MACed ID. > > Read the SIGMA documentation for more details: > > [SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to > Authenticated Diffie-Hellman and its Use in the IKE > Protocols", Advances in Cryptography - CRYPTO 2003 > Proceedings LNCS 2729, 2003, <http:// > www.informatik.uni-trier.de/~ley/db/conf/crypto/ > crypto2003.html>. Thanks, I'll take a look at that. > > > 3. In practice, is an Individual Submission less likely to be widely > > adopted than a document that is sponsored by a working group? I realize > > that is probably a moot point, given the lack of energy in the WG that > > Paul noted, but I thought I'd ask anyway. > > Protocols get adopted if there is real use for them. Whether it is > standard track, informational, experimental, WG document or individual > submission does not really matter. > > Hopefully the standard track documents get bit more widely implemented > than experimental documents, but that is not because of their status, > but because protocols which seem to have real use are more often > pushed to be on standard track. > -- > [email protected]
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
