Subject: [IPsec] draft-welter-ipsecme-ikev2-reauth-02

From: Keith Welter <[email-masked]>
Date: Fri, 14 Jan 2011 11:54:07 -0800

I submitted draft-welter-ipsecme-ikev2-reauth-02 to address the comments 
from Yaron.  Thanks Yaron!

Keith Welter
IBM z/OS Communications Server Developer
1-415-545-2694 (T/L: 473-2694)

> A new version of I-D, draft-welter-ipsecme-ikev2-reauth-02.txt has 
> been successfully submitted by Keith Welter and posted to the IETF 
repository.
> 
> Filename:    draft-welter-ipsecme-ikev2-reauth
> Revision:    02
> Title:       Reauthentication Extension for IKEv2
> Creation_date:    2011-01-14
> WG ID:       Independent Submission
> Number_of_pages: 6
> 
> Abstract:
> This document describes an extension to the Internet Key Exchange
> version 2 (IKEv2) protocol that allows an IKEv2 Security Association
> (SA) to be reauthenticated without creating a new IKE SA or new Child
> SAs.
>  
> 
> 
> The IETF Secretariat.
> 
>

---

From: Keith Welter <[email-masked]>
Date: Fri, 14 Jan 2011 16:09:55 -0800

I noticed a minor problem in section 5:
  "When not using extensible authentication, the peers are authenticated
  by having each sign (or MAC using a padded shared secret as the key,
  as described later in this section) a block of data.

But the padding is not described later in the section. 

I will reword the section as follows:
"5. Authentication Data for Reauthenticating the IKE SA

When not using extensible authentication, the peers are authenticated by 
having each sign (or MAC using a padded shared secret as the key) a block 
of data as described in [IKEv2] Section 2.15 except for the following 
differences: 

   o For the modified IKE_AUTH request, the octets to be signed start with 
the first octet of the previous Authentication payload sent by the 
initiator and end with the last octet of that payload. 

   o For the modified IKE_AUTH response, the octets to be signed start 
with the first octet of the previous Authentication payload sent by the 
responder and end with the last octet of that payload."

Keith Welter

---

From: Keith Welter <[email-masked]>
Date: Wed, 19 Jan 2011 09:21:07 -0800

I submitted draft-welter-ipsecme-ikev2-reauth-03 with the rewording shown 
below.  I'd like to ask the working group to accept this as a work item 
but I am unfamiliar with the process.  What next?

Thanks,

Keith Welter

> When not using extensible authentication, the peers are 
> authenticated by having each sign (or MAC using a padded shared 
> secret as the key) a block of data as described in [IKEv2] Section 
> 2.15 except for the following differences: 
> 
>    o For the modified IKE_AUTH request, the octets to be signed 
> start with the first octet of the previous Authentication payload 
> sent by the initiator and end with the last octet of that payload. 
> 
>    o For the modified IKE_AUTH response, the octets to be signed 
> start with the first octet of the previous Authentication payload 
> sent by the responder and end with the last octet of that payload." 
> 
> 
> Keith Welter
> 1-415-545-2694 (T/L: 
473-2694)_______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Wed, 19 Jan 2011 21:38:27 +0200

Hi Keith.

Generally, the process goes something like this:
- You write a draft (done!)
- You present it on the mailing list (done!)
- Usually, you ask for a time slot to present at a face-to-face meeting (not mandatory, but helps). The best is if you present it yourself, but if you don't plan to attend, someone else could present it for you.
- Next the WG chairs ask the group if it wants to accept this. This involves:
  - A rough consensus that this is an idea worth pursuing
  - Enough people committing to read and review
  - Enough people willing to contribute text.
- Determination of the above is at the discretion of the WG chairs. The advantage of presenting at a face-to-face, is that at least the last two questions can be answered there and then.
- If there is enough willingness to take on the item, the WG chairs ask the ADs to add this to the charter.
- If the ADs determine that this is a good idea, and has a chance of getting done (a motivated author is one of the requirements), they IESG approves the recharter
- The WG chairs appoint one or more authors for the WG draft. It's not automatically you, but usually is, and they might add some more people, especially if they have different ideas.

A long process that can take anything from a month to 7 years. See "Wait before WG adoption" in http://www.arkko.com/tools/lifecycle/extremes.html

Yoav

On Jan 19, 2011, at 7:21 PM, Keith Welter wrote:

> 
> I submitted draft-welter-ipsecme-ikev2-reauth-03 with the rewording shown below.  I'd like to ask the working group to accept this as a work item but I am unfamiliar with the process.  What next? 
> 
> Thanks, 
> 
> Keith Welter
> > 1-415-545-2694 (T/L: 473-2694)_______________________________________________
> > IPsec mailing list
> > [email-masked]
> <ATT00001..txt>

---

From: Keith Welter <[email-masked]>
Date: Wed, 19 Jan 2011 14:10:56 -0800

Paul Hoffman <[email-masked]> wrote on 01/19/2011 01:28:30 PM:
> On 1/19/11 9:21 AM, Keith Welter wrote:
> >
> > I submitted draft-welter-ipsecme-ikev2-reauth-03 with the rewording
> > shown below. I'd like to ask the working group to accept this as a 
work
> > item but I am unfamiliar with the process. What next?
> 
> I have Cc'd Yaron on this because he is the co-chair. I have Cc'd Yoav 
> on this because he replied on-list but missed two very salient points in 

> his response (it's not in the charter, and there is almost no energy 
> left in the WG).
> 
> Instead of making this a WG document (which would require a recharter 
> *and* enough people to give responses), I propose that you simply make 
> this an Individual Submission to an AD. For that, you just need to 
> approach the appropriate AD (Sean Turner, in this case) and tell him the 

> history of the draft. You get extra points if you can say "and I already 

> have a proposed document shepherd who is credible"; that could be Yaron 
> or Yoav or me. FWIW, there is no difference between you going through 
> the WG and Individual Submission for the document being on standards 
track.
> 
> You could ask the WG if they want to re-charter; my personal preference 
> would be that you don't. I worry that people will say "yes" and then be 
> as dead as they are now for our current documents.
> 
> Let Yaron and I know what you think of this prospect.
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?
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.
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.

Thanks,

Keith Welter

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 19 Jan 2011 16:13:03 -0800

On 1/19/11 2:10 PM, Keith Welter wrote:
> This may be a naive answer, but I'm not opposed to the idea of
> Individual Submission. I do have some comments/questions:
> 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?

Maybe, but probably not. If you call this out during IETF LC, the IESG 
can decide whether or not it is allowed. My reading of your draft ("do 
6023 but with these changes") does require 6023 to be normative because 
the reader has to understand 6023, but the fact that 6023 is 
experimental should not affect your draft because you are giving your 
own protocol. Others may disagree, though.

> 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."

That's what the informal discussion on this list *and* what IETF Last 
Call are for.

> adopted than a document that is sponsored by a working group?

No. Notice that RFCs don't say how they got there.

> I realize

Adoption is much more based on customer demand and the problem that is 
solved than the origin of the document.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 20 Jan 2011 16:41:02 +0200

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.  

> 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... 

> as part of the signed data in the initial exchanges I don't feel qualified 

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>.

> 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-masked]

---

From: Keith Welter <[email-masked]>
Date: Thu, 20 Jan 2011 15:56:07 -0800

> 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. 

>               www.informatik.uni-trier.de/~ley/db/conf/crypto/
Thanks, I'll take a look at that.