I do not have time to check this document now, as I do have some
working group documents that I need to check before getting to this.
Keith Welter writes:
> This may be a naive answer, but I'm not opposed to the idea of Individual
> Submission. I do have some comments/questions:
> 1. My draft depends on RFC 6023 and cites it as a normative reference.
> Since I'd like to get my draft on the standards track, does that mean that
> RFC 6023 needs to get on the standards track too?
I would thing experimental would be better status than standard track
document. As you point out the RFC 6023 is experimental, as is RFC
4478.
I myself would first like to see some real world implementations and
use for those (and this) before making them standard track.
As you can notice I do not belive that either one of those previous
experimental protocols is needed in general in IKEv2, and for example
our QuickSec OEM toolkit does not have support for them (and most
likely will not have support for them, unless some customer really
comes to us and says that they need them and are willing to pay for
them :-)
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...
> 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>.
> 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
