Subject: [Pana] I-D ACTION:draft-ietf-pana-ipsec-01.txt

From: [email-masked]
Date: Tue, 13 Jan 2004 15:51:58 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Protocol for carrying Authentication for Network Access Working Group of the IETF.

	Title		: PANA enabling IPsec based Access Control
	Author(s)	: M. Parthasarathy
	Filename	: draft-ietf-pana-ipsec-01.txt
	Pages		: 11
	Date		: 2004-1-13
	
The PANA (Protocol for carrying Authentication for Network Access)  
working group is developing protocol for authenticating clients to  
the access network using IP based protocols.  The PANA protocol  
authenticates the client and also establishes a PANA security  
association between the PANA client and PANA authentication agent at  
the end of a successful authentication. This document discusses the  
details for establishing an IPsec security association using the PANA  
security association for enabling IPsec based access control.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pana-ipsec-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pana-ipsec-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pana-ipsec-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Alper Yegin <[email-masked]>
Date: Wed, 14 Jan 2004 17:07:00 -0800

Hi Mohan,

Some comments and questions on the latest draft...

        In the case of DHCP and IKE, EP can trivially learn the address
        allocated to the client.

I presume you are referring to RFC3456 for DHCP, and configuring IP address
within IKEv2 for the latter. You might want to explicitly mention these.

        In the case of auto-configuration
        (which includes global address or addresses configured as in
        [PRIV]), EP may not know the address assigned to the PaC.

We should qualify which address we are talking about here. I think it is the
inner IP address. 

        Thus,  
        it may not be able to setup the SPD entries appropriately before
        IKE exchange starts. As most of the IKE implementations assume
        that the SPD can be consulted during the SA negotiation, it may
        require slightly a different behavior from IKE in the auto-
        configuration case. In the case of auto-configuration, IKE
        should be able to setup the SAs for the traffic selectors
        specified by the PaC without consulting the SPD entry. If there
        is already an SA for the same address, then the SA request MUST
        be rejected with INVALID-ID-INFORMATION [IKE]. If PaC
        authenticates itself successfully, EP should add the SPD entry
        for protecting the subsequent data packets.

Does this require any modifications to the IKE protocol, or simply
implementation modification is sufficient?

The other possibility (in addition to DHCP, IKE, autoconf-based
configuration) is the statis IP configuration. I guess its handling will be
same as autoconf one? [In that case, would we still use link-local IP
address during PANA, or simply use the pre-configured IP address?]

   As EP and PAA are assumed to be co-located,this might be just an API
   call.   

We don't assume that. We just assume EP is co-located with an AR in the
IPsec-based access control case. PAA might still be hosted on a separate
node. This shouldn't impact the PANA-IPsec design though.

    IKE Pre-shared Key = HMAC-SHA-1 (MSK, "IKE-preshared key" |
                           Session ID | MSK-ID)

I think we should be using PANA SA Key instead of MSK. (or, maybe even
another key driven from PANA SA Key??)

   If the PAA does not verify whether PaC is authorized to use an IP
   address, it is possible for the PaC to steal the traffic destined to
   some other PaC.

Are we talking about the inner IP address or the outer (or both)?

   This should not be a limitation as the link-
   local address is used only by link-local services e.g.
   neighbor/router discovery, which uses a different mechanism to
   protect their traffic.

I think we are referring to the SEND problem here. If so, let's give a
reference to the current spec.

Thanks.

Alper

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

---

From: Alper Yegin <[email-masked]>
Date: Wed, 14 Jan 2004 17:07:00 -0800

Hi Mohan,

        Thus,  

Thanks.

Alper

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 14 Jan 2004 18:32:20 -0800

> within IKEv2 for the latter. You might want to explicitly mention these.
It could be IKE or IKEv2. And the previous line should have mentioned this i thought..

> We should qualify which address we are talking about here. I think it is the
Okay. I will clarify this.

> implementation modification is sufficient?
Implementation should be sufficient. Racoon seems to have this knob.

> node. This shouldn't impact the PANA-IPsec design though.
Agreed.

> another key driven from PANA SA Key??)
I have to think more on this to understand the difference.

> Are we talking about the inner IP address or the outer (or both)?
This is about the inner address.

> reference to the current spec.
Okay.

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 14 Jan 2004 18:32:20 -0800

Agreed.

Okay.

-mohan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 14 Jan 2004 19:15:03 -0800

> It could be IKE or IKEv2. And the previous line should have mentioned this i thought..

Hmm, I was interpretting the previous sentence differently.

   4) PaC configures a link-local address before the PANA protocol
        begins. At the end of authentication, it either acquires a
        globally reachable address using [DHCP][DHCPV6] or using IKE or
        auto-configures an address using stateless auto-configuration
        [IPV6-ND] if IPv6 is being used.

I think "using [DHCP][DHCPV6]" means using DHCP or DHCPv6 before
running IKE or IKEv2.

"using IKE" (or "using IKE or IKEv2" according to Mohan's above
comment) means that running address configuration methods available
within IKE or IKEv2 (i.e., by using modecfg or Configuration Payload).

"auto-configures an address" means running stateless auto-configuration
before running IKE or IKEv2.

RFC 3456 talks about running DHCP over DHCP SA (i.e., an IPsec tunnel
mode SA).  This may be different from any of above three cases,
because DHCP SA is created by "using IKE" but DHCP messages are not
carried in IKE payloads.

> Implementation should be sufficient. Racoon seems to have this knob.

What is the probelm in the case of auto-configuration if IKE is not
able to setup the SAs for the traffic selectors specified by the PaC
without consulting the SPD entry?

> > node. This shouldn't impact the PANA-IPsec design though.

I agree, too.

> I have to think more on this to understand the difference.

The difference would be whether the IKE pre-shared key and PANA SA key
becomes cryptographycally separate or not.  By using the MSK, the IKE
pre-shared key and PANA SA key are cryptographycally indepenent.
Unless there is a specific reason for the two keys to be
cryptographycally dependent, I think using the MSK is stronger (and
better).

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 14 Jan 2004 19:15:03 -0800

I agree, too.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 14 Jan 2004 20:59:29 -0800

Please see my other comments below:

> >         for protecting the subsequent data packets.

The above text seems to prohibit establishing multiple IPsec SAs
between a given pair of PaC and EP.  I thought we have previously
agreed on allowing multiple IPsec SAs to avoid double IPsec encryption
in the corporate VPN case (i.e., creating a separate IPsec SA with
null encryption for traffic that carries IPsec'ed packets to the
corporate VPN gateway.)  Is there any issue for allowing the case?

   During EAP re-authentication, the MSK changes. Whenever the MSK
   changes, a new value of MSK-ID is established between the PaC and
   PAA/EP. If there is already an IKE SA established, it can continue to
   be used till it expires. A change in the value of MSK need not result
   in re-negotiating a new IKE SA or IPsec SA immediately. But any new
   negotiation of IKE SA should use the new pre-shared key derived from
   the latest MSK and is indicated by the MSK-ID in the above equation.
                                                                                
I think the above operation needs be specified by using strict
language in order to avoid possible non-interoperable implementations.

How about this? : 

   During EAP re-authentication, the MSK changes. Whenever the MSK
   changes, a new value of MSK-ID is established between the PaC and
   PAA/EP. If there is already an IKE SA established, it MUST continue to
   be used till it expires. A change in the value of MSK MUST NOT result
   in re-negotiating a new IKE SA or IPsec SA immediately. But any new
   negotiation of IKE SA MUST use the new pre-shared key derived from
   the latest MSK and is indicated by the MSK-ID in the above equation."

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 14 Jan 2004 20:59:29 -0800

How about this? : 

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Thu, 15 Jan 2004 14:10:34 -0800

> cryptographycally dependent, I think using the MSK is stronger (and

Passing the MSK to the EP runs the risk that, any other key derived off of
MSK can also be generated by the EP. This is why I was saying maybe we
shouldn't even use PANA SA key, but some other key generated from it.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 15 Jan 2004 14:10:34 -0800

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 15 Jan 2004 14:47:52 -0800

> shouldn't even use PANA SA key, but some other key generated from it.

I was thinking that the calculated IKE pre-shared key is passed to EP
(over secure SNMPv3 communication) and MSK itself is not passed.  
Is this danger?

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 15 Jan 2004 14:47:52 -0800

Yoshihiro Ohba

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 15 Jan 2004 16:05:27 -0800

> before running IKE or IKEv2.
Yes, this is what i had in mind.

> because DHCP SA is created by "using IKE" but DHCP messages are not
This is what we have discussed before in a different context. But i am not
going to discuss it in this draft.
                                                                      
> without consulting the SPD entry?
The one mentioned in the security consideration. EP is blindly trusting
what the PaC is saying about the inner addresses i.e clients can spoof.
But it is not the same as service theft that we discussed in the 
threats document. The PaC still needs to have the right keys.  And
the addresses assigned are temporary. So, i really don't see a big
issue with this.

> cryptographycally dependent, I think using the MSK is stronger (and
This is right. This is the same comment i received from another reviewer.
Cryptographic separattion is the only thing i can think of.

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 15 Jan 2004 16:05:27 -0800

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 15 Jan 2004 16:12:37 -0800

> (over secure SNMPv3 communication) and MSK itself is not passed.  
This is what is mentioned in the IPsec draft in section 4.0.

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 15 Jan 2004 16:12:37 -0800

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 15 Jan 2004 16:10:20 -0800

> corporate VPN gateway.)  Is there any issue for allowing the case?
I want to keep the draft simple. But we can make sure that it can support your
case also by mentioning that the same address is not used by a different
session i.e you reject if the same address is proposed by a different session-ID
present in the ID_KEY_ID payload. Would it suffice ?
Agreed.

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 15 Jan 2004 16:10:20 -0800

Agreed.

-mohan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 15 Jan 2004 16:34:09 -0800

> present in the ID_KEY_ID payload. Would it suffice ?

I believe double IPsec encryption avoidance is something we should
provide.  And I like your suggested scheme of using "inner IP address
+ session-ID" to reject IPsec SA for the same inner address, for
protection against the "inner address theft" attack.  That seems still
simple to me.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 15 Jan 2004 16:34:09 -0800

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 15 Jan 2004 16:54:13 -0800

Hi Mohan,

> going to discuss it in this draft.

Any specific reason for not discussing RFC 3456 in this draft?  Otherwise, 
I prefer mention it to cover possible cases as much as possible.

> the addresses assigned are temporary. So, i really don't see a big

I think "consulting the SPD entry" is too concise to understand that it is 
related to the inner address theft attack.  

How about this?

"consulting the SPD entry in order to make sure that the specified
inner address is not used by other PaC."

Also:

  "In the case of auto-configuration, IKE
  should be able to setup the SAs for the traffic selectors
  specified by the PaC without consulting the SPD entry. "
                       ^^^^^^^

Do you mean "with" here?  Because according to the discussion, SPD
entry check is something needs to be performed to protect from "inner address
theft" attack.  Or I may be misunderstanding something.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 15 Jan 2004 16:54:13 -0800

Hi Mohan,

How about this?

Also:

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Thu, 15 Jan 2004 21:31:10 -0800

> (over secure SNMPv3 communication) and MSK itself is not passed.

OK, I thought we were passing the MSK to EP. That's not the case, hence use
of MSK in the calculation should be fine.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 15 Jan 2004 21:31:10 -0800

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Jan 2004 09:04:32 -0800

Hi Mohan,

I have one more comment.

According to the current IKE pre-shared key derivation algorithm, when
the PAA controls multiple EPs, the same IKE pre-shared key for a
particular PANA session will be shared one or more EPs.  I think this
is not desirable from the viewpoint of key management philosophy.  So,
it might be better to include EP device identifier in the key
computation algorithm.

What do you think?

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Jan 2004 09:04:32 -0800

Hi Mohan,

I have one more comment.

What do you think?

Yoshihiro Ohba

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 16 Jan 2004 13:47:46 -0800

> I prefer mention it to cover possible cases as much as possible.
I thought a bit about this.  These are the two methods.

1st method.
---------------
1)  Authenticate using PANA (link-local address is used for communication)
2)  Client does DHCP to get an inner address. Create state about what address
     was assigned to the PaC i.e " IP address - SessionID" mapping so that it
     can ve verified later as explained below.
3)  IKE, IPsec using phase 2 IDs as addresses obtained in (2). IKE does verification
     as mentioned in step (2) before setting up the SAs.

2nd method (RFC 3456)
-----------------
1) Authenticate using PANA (link-local address is used for communication)
2) setup DHCP IPsec SA where phase 2 IDs are 0/0. Run DHCP using this
     SA to get an IP address.
3) Setup another IPsec SA for the IP address obtained in step (2) using DHCP.

If we have to mention both,  we need to specify more details like the above.
Is that what you are suggesting ?

Okay.

> theft" attack.  Or I may be misunderstanding something.
I think it is a bit confusing. At the beginning, there are really no SPD entries.
When the first client authenticates, you still consult the SPD table but it has
no entry. SPD entries are created dynamically for this client and subsequent ones.
So, the above is trying to say that there is no pre-configured entry for the client
in the SPD that is doing the IKE/IPsec negotiation. But you have to consult the
SPD so that there is no such entry already there. Perhaps it needs some more
wording. Makes sense ?

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 16 Jan 2004 13:47:46 -0800

1st method.
---------------

2nd method (RFC 3456)
-----------------

Okay.

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 16 Jan 2004 16:45:43 -0800

> it might be better to include EP device identifier in the key
Agreed. The one that needs inclusion in the derivation is IP address of the EP that
 PaC learns before the IKE exchange starts. I guess it is the same as the device
identifier of EP that you mention. 

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 16 Jan 2004 16:45:43 -0800

-mohan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Jan 2004 16:53:22 -0800

> identifier of EP that you mention. 

Yes, that's what I meant.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Jan 2004 16:53:22 -0800

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Jan 2004 18:38:40 -0800

> I thought a bit about this.  These are the two methods.

I don't think we need more details like.  My suggestion is that
just mentioning all the four possible cases including RFC 3456 might
be sufficient.  I have some suggested text for it:

     "4) PaC configures a link-local address before the PANA protocol
        begins. At the end of authentication, it either acquires a
        globally reachable address using [DHCP][DHCPV6] before
        running IKE or IKEv2, running address configuration
        methods available within IKE or IKEv2 by using Configuration
        Payload or equivalent, running DHCP over a
        special IPsec tunnel mode SA [RFC3456], or auto-configures an
        address using stateless auto-configuration [IPV6-ND] before
        running IKE or IKEv2 if IPv6 is being used."

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Jan 2004 18:38:40 -0800

Yoshihiro Ohba

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 19 Jan 2004 14:37:49 -0800

>         running IKE or IKEv2 if IPv6 is being used."
Ok.  I am fine with this. 

-mohan

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 19 Jan 2004 14:37:49 -0800

Ok.  I am fine with this. 

-mohan

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 20 Jan 2004 14:01:20 -0800

> SPD so that there is no such entry already there. Perhaps it needs some more
 Here is the proposed text :

The old text :

      "Thus,  it may not be able to setup the SPD entries appropriately before
        for protecting the subsequent data packets."

New text:
         Thus, it may not be able to setup the SPD entries for the PaC appropriately
          before IKE exchange starts. As most of the IKE implementations assume
          that the SPD can be consulted during the SA negotiation, it may 
          require a different behavior from IKE in the auto-configuration case.
          In the case of auto-configuration, IKE should be able to setup the SAs
          for the traffic selectors (which contain the PaC auto-configured address)
          specified by the PaC without requiring a corresponding entry in the SPD.
          If there is already an SA for the same address with a different identity
          (specified in the ID_KEY_ID payload),  then the SA MUST
          be rejected with INVALID-ID-INFORMATION [IKE]. If PaC
          authenticates itself successfully, EP should add the SPD entry
          corresponding to the traffic selectors specified by PaC
          for protecting the subsequent data packets."

Comments ?

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 20 Jan 2004 14:01:20 -0800

The old text :

New text:

Comments ?

-mohan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 21 Jan 2004 11:27:23 -0800

Hi Mohan,

Looks better.

I think that relying solely on the SPD consulting might not prevent a
DoS attack where a malicous client performs IKE with spoofing an inner
address *before* the legitimate client does IKE with the inner
address.

If this is true, we might want to mention it somewhere in the draft.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 21 Jan 2004 11:27:23 -0800

Hi Mohan,

Looks better.

Yoshihiro Ohba

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 21 Jan 2004 13:03:37 -0800

> address *before* the legitimate client does IKE with the inner
Malicious client who successfully authenticated using PANA can launch
this attack. But it is the same as the DoS attack that could happen with
DAD.

> If this is true, we might want to mention it somewhere in the draft.
It is mentioned in the security considerations section. Please see whether it
is enough.

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 21 Jan 2004 13:03:37 -0800

-mohan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 21 Jan 2004 19:54:57 -0800

> this attack. But it is the same as the DoS attack that could happen with

Yes.

> It is mentioned in the security considerations section. Please see whether it

For more clarification, I'd suggest updating the following paragraph
of the security considerations section

from:

   "If the PAA does not verify whether PaC is authorized to use an IP
   address, it is possible for the PaC to steal the traffic destined to
   some other PaC. The use of IPsec does not prevent this attack. PAA
   may use other mechanisms to prevent this attack."

to:

   "If the PAA does not verify whether PaC is authorized to use an IP
   address, it is possible for the PaC to steal the traffic destined to
   some other PaC. Although Section 3 describes an inner address
   verification method based on SPD consulting, it is still possible
   for an authenticated PaC to launch this attack.  PAA may use other
   mechanisms to prevent this attack."

Regards,

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 21 Jan 2004 19:54:57 -0800

Yes.

from:

to:

Regards,

Yoshihiro Ohba

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 22 Jan 2004 09:24:55 -0800

>    mechanisms to prevent this attack."

Ok.

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 22 Jan 2004 09:24:55 -0800

Ok.

-mohan