Subject: [Ipsec] Last call comments about "Repeated Authentication in IKEv2"

From: [email-masked]
Date: Wed, 4 Jan 2006 11:25:10 +0200

1) Overall: Being able to reauthenticate the client (either
periodically or by some other trigger) is a common requirement in
remote access deployments. It's a good idea to have one documented
way to do this, instead of each vendor inventing its own proprietary
payloads. Thus, I think this document is a very useful extension to
IKEv2, and deserves to be published.

2) The document could be more precise about in describing what
messages can contain the AUTH_LIFETIME notification. The intent was
clearly "in the last IKE_AUTH response or in any INFORMATIONAL
request", but this is not exactly the same as saying "in a separate
Informational exchange" (which might be interpreted as including
both the request and response messages) or "MAY be sent by the
original Responder at any time".

3) Section 2: "It is recommended that an INITIAL-CONTACT
notification be included in the AUTH exchange." 

This is probably not correct. RFC4306 says that "This notification
MUST NOT be sent by an entity that may be replicated (e.g., a
roaming user's credentials where the user is allowed to connect to
the corporate firewall from two remote systems at the same time)."

Even if the corporate IT department has decided not to allow this,
the initiator probably does not know this, so it should not include
the notification. 

Furthermore, the INITIAL_CONTACT notification is not really needed 
for anything in this case, since the client has not crashed,
and it still has all the information it needs to properly close 
the old IKE_SA (once the new one has been established).

4) Section 7 (IANA Considerations): The text should say that the
number needs to be assigned from the "Status Types" range (and not
the "Error Types" part)

5) Typos etc.
Section 2: the Informational response should be "HDR, SK{}" 
Section 3, s/AUTH_LEFETIME/AUTH_LIFETIME/
Section 6, should explicitly say that both references are normative

Best regards,
Pasi

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: "Yoav Nir" <[email-masked]>
Date: Wed, 4 Jan 2006 12:03:33 +0200

Comments inline 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> 

You're right about the former, but I think the latter needs to stay. It
refers to the timing of sending the message.

> the old IKE_SA (once the new one has been established).

I thought INITIAL_CONTACT would be a shorter way to achieve the same goal,
but I forgot about the replication problem. I agree.  This line must go.

> number needs to be assigned from the "Status Types" range (and not

Well, if and when this is published, This would change to a specific,
allocated number.  I did write this in the IANA application.
 
> Section 6, should explicitly say that both references are normative

Agreed.