[Pana] FW: PANA IPsec review

["Alper Yegin" <[e-mail]>]

The attached e-mails are generated as part of the Security Directorate's
PANA-IPsec review.

There were few more that simply discussed whether "v2" should be the
mandatory version of IKE with PANA. Conclusion of that discussion, as Sam
summarizes:

"I would certainly recommend that you make it clear to the authors that Russ
and I are not going to require ikev2."

Alper

--- Begin Message ---

Hi Mark,

As promised, here is my review of the PANA-IPsec document, as part of 
a secdir assignment.  I plan to review the protocol and framework 
documents (on my own initiative) as well and will send those reviews 
in 1-2 days.

First a disclaimer:  Personally, I am *not* a big fan of PANA.  In 
fact, there is a discussion underway in 3GPP2 on whether to adopt 
EAPoHRPD or PANA and as it is done in 3GPP2, my personal opinion, 
which influenced my employer's proposal, is to use EAPoHRPD, similar 
to 802.11 and 802.16 have done.

There is also the debate on "who uses PANA" or "why does PANA make 
sense" and I for one think that as specified, the PANA suite of 
protocols are too complex to be of use anywhere.  But, it's up to the 
IESG to make that call and whether that influences the publication of 
the specifications.

I do appreciate and respect the fact that the PANA documents reflect 
the PANA WG consensus, and so my comments below are strictly 
technical and to produce a quality RFC.  Note further that the PANA 
proposal in 3GPP2 does not require the use of PANA-IPsec; instead 
3GPP2's native key exchange and encapsulation protocols are used.

With that background, below is a summary of my review followed by 
detailed comments inline:

The document needs a revision, followed by another WGLC process.  In 
general, I felt that the document is underspecified.  Here is a 
sample of  things to be clarified, revised, or specified anew:

1. The document should restrict itself to IKEv2 and IPsec as in 4301 
and 4303.  There is also a reference to MOBIKE in PANA protocol, but 
this document doesn't talk about that.  Perhaps that gap needs to be filled.
2. I have suggestions for revision of PSK derivation from the
PaC-EP-Master-Key
3. EAP Re-authentication, PSK switch over, new IKEv2 and IPsec 
establishment needs more detailed specification.
4. I have some comments about default crypto algorithms and algorithm
agility
5. The security considerations section says, "If the EP does not 
verify whether the PaC is authorized to use an IP address, it is 
possible for the PaC to steal the traffic destined to some other PaC."

This is at best not clear, or perhaps a serious security hole.  It 
appears that either address authorization (CGA?) is needed or a 
particular configuration of IP addresses is needed for IPsec to be
effective.

Details, some nits and editorial changes are inline below.

regards,
Lakshminath

At 09:28 PM 5/18/2006, Lakshminath Dondeti wrote:


>    PANA Working Group
>    Internet Draft                                      M. Parthasarathy
>    Document: draft-ietf-pana-ipsec-07.txt                         Nokia
>    Expires: January 2006                                      July 2005

Is this a guidance document?  Or a protocol specification in the 
standards track (I failed to lookup earlier and I don't have a 
network connection now)?  There are several instances of can be done 
this way or that way and I am not sure how that'll help interoperability.


><snip>

>1.0 Introduction
>
>    PANA (Protocol for carrying Authentication for Network Access) is a
>    protocol [PANA-PROT] 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 (PaC) and PANA authentication agent (PAA) at the end of
>    successful authentication. The PAA indicates the results of the
>    authentication using the PANA-Bind-Request message wherein it can
>    indicate the access control method enforced by the access network.
>    The PANA protocol [PANA-PROT] does not discuss any details of IPsec
>    [RFC2401] security association (SA) establishment, when IPsec is used

Should be 4301!

>    for access control. This document discusses the details of
>    establishing an IPsec security association between the PANA client
>    and the enforcement point. The IPsec SA is established using IKE
>    [RFC2409], which in turn uses the pre-shared key derived from the EAP

Should be IKEv2.  PANA protocol document makes a reference to MOBIKE 
and IKE, which of course are inconsistent.  Those references need to 
be fixed and this document should be updated accordingly.

>    authentication. The IPsec SA used to protect the packet provides the
>    assurance that the packet comes from the client that authenticated to
>    the network.  Thus, the IPsec SA can be used for access control and
>    specifically used to prevent the service theft mentioned in
>    [RFC4016]. The term "access control" in this document refers to the
>    per-packet authentication provided by IPsec. IPsec is used to protect
>    packets flowing between PaC and EP in both directions.
>
>    Please refer to [PANAREQ] for terminology and definitions of terms
>    used in this document. The PANA framework document [PANA-FRAME]
>
>
><Parthasarathy>          Expires January 2006                 [Page 2]
>
>                PANA enabling IPsec based Access Control      July 2005
>
>    describes the deployment scenarios for IPsec. The following picture
>    illustrates what is being protected with IPsec. The different
>    scenarios of PANA usage are described in the [PANAREQ]. When IPsec is
>    used, scenarios 3 and 5 are supported as shown below. As shown in
>    Figure 1, the Enforcement Point (EP), Access Router (AR) and the PANA

The first occurrence of EP, enforcement point, is earlier, so we can 
use the abbreviation here.  Same goes for PAA.

>    authentication agent are co-located which is described as scenario 3
>    in [PANAREQ].
>
>
>
>
>
>
>
>                       PaC ------------+
>                                       |
>                                       +---EP/AR/PAA----Intranet/Internet
>                                       |
>                       PaC ------------+
>
>                      <-------IPsec------>
>
>                           Figure 1: PAA/EP/AR are co-located

Relabel figure as PAA, EP, and AR are co-located, to be consistent 
with Figure 2's label below.


>    As show in Figure 2, only the AR and EP are co-located. The PAA is a
>    separate node though located on the same link as the AR and EP. All
>    of them are one IP hop away from the PaC. This is the same as
>    scenario 5 described in [PANAREQ].
>
>                       PaC -------------+
>                                        |
>                                        +---PAA
>                                        |
>                                        +---EP/AR-----Intranet/Internet
>                                        |
>                       PaC -------------+
>
>
>                     <------IPsec----->
>
>                           Figure 2: EP and AR are co-located
>
>
>    The IPsec security association protects the traffic between the PaC
>    and EP. In IPsec terms, the EP is a security gateway (therefore a
>    router) and forwards packets coming from the PaC to other nodes.
>
>    First, this document discusses some of the pre-requisites for IPsec
>    SA establishment. Next, it gives details on what should be
>
>
>
><Parthasarathy>          Expires January 2006                 [Page 3]
>
>                PANA enabling IPsec based Access Control      July 2005
>
>    communicated between the PAA and EP. Then, it gives the details of
>    IKE exchange with IPsec packet formats and SPD entries. Finally, it
>    discusses the dual stack operation.
>
>2.0 Keywords
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2118].

2118?  Should be 2119 :)

Note: Since there are no requirements specified so far, except the 
note in the Introduction referring to 4016 about protecting service 
theft, per-packet authentication seems necessary and sufficient.  So, 
I would presume ESP-NULL as the default!



>3.0 Pre-requisites for IPsec SA establishment
>
>    This document assumes that the following have already happened before
>    the IKE exchange starts.
>
>      1) The PaC) and PAA mutually authenticate each other using an EAP
>         method that is able to derive a AAA-key [EAP-KEY].

s/PaC)/PaC

Referring to the term MSK instead of AAA-key seems to be the best way 
to refer to the result of EAP key generating methods, at least as per 
EAP Keying framework.  Perhaps a reference to the PANA protocol 
document is more appropriate here.  Or perhaps a key derived from the 
MSK is used?  Needs some checking into.

Ok, after looking at the PANA protocol document, it appears that a 
reference to the PaC-EP-Master-Key is more precise here.


>      2) The PaC learns the IP address of the Enforcement point (EP)
>         during the PANA exchange.
>
>      3) The PaC learns that the network uses IPsec [RFC2401] for
>         securing the link between the PaC and EP during the PANA
>         exchange.

Refer to 4301.  Perhaps it would be worthwhile to indicate how PANA 
protocol signals the use of IPsec.  A quick look at the PANA protocol 
document did not help!



>4.0 IP Address Configuration
>
>    The IP address configuration is explained in [PANA-FRAME]. Some of
>    the details relevant to IPsec are briefly repeated here for clarity.
>    The PaC configures an IP address before the PANA protocol exchange
>    begins. This address is called a pre-PANA address (PRPA). After a
>    successful authentication, the client may have to configure a post-
>    PANA address (POPA) for communication with other nodes, if PRPA is a
>    local-use (e.g., link-local or private address) or a temporarily
>    allocated IP address.
>
>    The PRPA of the PaC may be a link-local address [IPV4-LINK] or a
>    private address [RFC1918] or a routable address or an IPv6 link-local
>    address or global address [RFC2462]. Please refer to [PANA-FRAME] for

Just curious about PRPA being a global address.  If the PaC already 
has a globally routable address, why would it care to go through 
IKEv2 and access enforcement?  (I don't have a full picture of PANA 
operation, so wondering whether this is ok.  It might be worthwhile 
to elaborate on that in this document, since it is talking about 
access enforcement!)

>    more details on how these addresses may be configured. The PaC would
>    use the PRPA as the outer address of IPsec tunnel mode SA (IPsec-
>    TOA). The PaC also needs to configure an inner address (IPsec-TIA).

Nits: expand TOA and TIA.

>    There are different ways to configure IPsec-TIA.
>
>      1) Some IPv4 IPsec implementations are known to work properly when
>         the same address is configured as both the IPsec-TIA and IPsec-
>         TOA. When PRPA is a routable address, the PRPA may be used as
>         both the IPsec-TIA and IPsec-TOA and POPA may not be configured.

I am confused by the reference to IPv4 IPsec.



><Parthasarathy>          Expires January 2006                 [Page 4]
>
>                PANA enabling IPsec based Access Control      July 2005
>
>
>      2) In IPv4, an IPsec-TIA can be obtained via the configuration
>         method available using DHCP over IPsec tunnels [RFC3456]. The
>         minor difference from the original usage of [RFC3456] is that
>         the IPsec-TOA does not need to be a routable address when
>         [RFC3456] is used between the PaC and EP.
>
>      3) When IKEv2 [IKEV2] is used for security association negotiation,
>         the address configuration method available in [IKEV2] can be
>         used for configuring the IPsec-TIA for both IPv4 and IPv6.

I'd suggest making Option 3 mandatory and leave it at that!


>    There are other address configuration methods possible. They have
>    some implementation issues, which are described in the Appendix A.
>
>5.0 IKE Pre-shared key derivation

I'd suggest all references here be changed to IKEv2!

>    If the network chooses IPsec to secure the link between the PaC and
>    EP, the PAA should communicate the IKE pre-shared key (Pac-EP Master
>    Key), Key-Id, the device identifier of the PaC, and the session-Id to
>    the EP before the IKE exchange begins. Whenever the IKE pre-shared
>    key changes due to re-authentication as described below, the new
>    value is computed by the PAA and communicated to the EP with all the
>    other parameters.

When the Pac-EP Master Key changes, does it automatically trigger a 
new IKEv2 SA?  It should!  Need to specify the details of that.


>    The IKE exchange between the PaC and PAA is equivalent to the 4-way
>    handshake in [IEEE80211i] following the EAP exchange. The IKE
>    exchange establishes the IPsec SA similar to the pair-wise transient
>    key (PTK) established in [IEEE80211i].

I am not sure whether the mention of 4-way handshake is adding any 
value here: it comes at the expense of making a broad statement about 
the similarities between IKEv2 and the 4-way handshake.  They have 
many more differences than similarities!

>The IKE exchange provides both
>    key confirmation and protected cipher-suite negotiation.
>
>    The IKE pre-shared key is derived as follows (where "|" means
>    concactenation).
>
>    IKE Pre-shared Key = HMAC-SHA-1 (PaC-EP-Master-Key,
>                            "IKE-preshared key" |
>                            Session ID | Key-ID | EP-address)

The PaC-EP-Master-Key is specified in PANA protocol document as follows:
PaC-EP-Master-Key = The first 64 octets of
                        prf+(AAA-Key, "PaC-EP master key" |
                             Session ID | Key-ID | EP-Device-Id)

I have several questions/comments/suggestions:

1. Why can't the PaC-EP-Master-Key be used directly.  Are there other 
expected uses of that key?

2. Assuming that PaC-EP-Master-Key might be used for other purposes, 
it does make sense to use a derived key as the IKEv2 PSK.  However, 
it is worthwhile to explore the possible uses of the 
PaC-EP-Master-Key and figure out how best to derive the various child 
keys.  To that end, I am not sure mixing in the same parameters as 
those used in PaC-EP-Master-Key is good enough.

If another key is indeed derived from the PaC-EP-Master-Key following 
the procedure above, it is conceivable that the only difference in 
key derivation is a string.

3. Please use either EP-address or EP-Device-Id.  Or perhaps they are 
different?

4. Why is the pre-shared key restricted to 160 bits?  It can and 
should be larger.  Given that PaC-EP-Master-Key comes from a 64 octet 
root key, let's take advantage of that.

5. Algorithm agility might be useful here.  Let's use PRF+ as in 
IKEv2 and allow the same level of algorithm agility.  Or PRF 
negotiation of PANA might be used here.

6. Why is the PaC ID not mixed in here?


>    The values have the following meaning:
>
>    PaC-EP-Master-Key: A key derived from the AAA-key for each EP as
>    defined in [PANA-PROT].
>
>    Session ID: The value as defined in the PANA protocol [PANA-PROT],
>    identifies a particular session of a client.
>
>    Key-ID: This identifies the PaC-EP-Master-Key within a given session
>    [PANA-PROT]. During the lifetime of the PANA session, there could be
>    multiple runs of EAP re-authentications. As EAP re-authentication
>    changes the AAA-key which in turn affects Pac-EP-Master-Key, Key-ID
>
>
><Parthasarathy>          Expires January 2006                 [Page 5]
>
>                PANA enabling IPsec based Access Control      July 2005
>
>    is used to identify the right PaC-EP-Master-Key. This is contained in
>    the Key-ID AVP [PANA-PROT].
>
>    EP-address: This is the address of the enforcement point with which
>    the IKE exchange is being performed. When the PAA is controlling
>    multiple EPs, this provides a different pre-shared key for each of
>    the EPs.
>
>    During EAP re-authentication, the AAA-Key changes. Whenever the AAA-
>    Key changes, a new PaC-EP-Master-Key is derived and a new value for
>    Key-ID is established between the PaC and PAA/EP as defined in [PANA-
>    PROT]. The [EAP-KEY] document requires that all keys derived from
>    AAA-key be deleted when the AAA-key expires. Hence, a new IKE PSK
>    should be derived upon AAA-key expiry.   As it also affects the IKE
>    and IPsec SAs derived from it, new security associations for IKE and
>    IPsec are established with the new IKE PSK. In case where two runs of
>    EAP authentication (NAP/ISP) are performed during a single PANA
>    authentication phase, a new PaC-EP-Master-Key is derived from the
>    AAA-key obtained from both authentications as specified in the [PANA-
>    PROT].

Ok, it looks like if re-authentication occurs the PSK changes and a 
new IKEv2 run is required.  How does the switchover happen?  Do the 
PaC and EP tear down IKEv2 and IPsec SAs at the beginning of 
re-authentication or at the end or is it a matter of local 
policy.  If it's based on local policy, do we assume that either the 
EP or the PaC will tear down the SAs at will (IKEv2 of course allows 
that, so it's easy to write a few lines on it).

I think others raised this question as well, indicating the strong 
need for additional details.


>6.0 IKE and IPsec details
>
>    IKE [RFC2409] MUST be used for establishing the IPsec SA. The details
>    specified in this document works with IKEv2 [IKEV2] as well as IKE.

This is inconsistent with the mention of MOBIKE in the PANA protocol 
document.  I suggest restricting the use to IKEv2 alone.  Address 
assignment and SA management are simpler.  Note that in IKE, there is 
a notion of lifetime negotiation and this specification doesn't seem 
to address those aspects anyway.

>    Any difference between them would be explicitly noted. PANA
>    authenticates the client and network, and derives the keys to protect
>    the traffic. Hence, manual keying cannot be used. If IKE is used,
>    aggressive mode with pre-shared key MUST be supported. The PaC and EP
>    SHOULD use the following value in the payload of the ID_KEY_ID to
>    identify the pre-shared key.
>
>            ID_KEY_ID data = (Session-Id | Key-Id)
>
>    The Session-Id and Key-Id are the values contained in the data
>    portion of the Session-Id and Key-Id AVP respectively [PANA-PROT].
>    They are concatenated to form the content of ID_KEY_ID data. IP
>    addresses cannot be used as identifier as the same PaC or different
>    PaC may use the same IP address across a PANA session.

I can't say I understand this.  Are you saying that two PaCs may use 
the same IP address?  Please clarify!

>For the same
>    reason, main mode of IKE cannot be used, as it requires addresses to
>    be used as identifiers.
>
>    If IKE is used, a quick mode exchange is performed to establish an
>    ESP tunnel mode IPsec SA for protecting the traffic between the PaC
>    and EP. In IKEv2, the initial exchange (IKE_SA_INIT and IKE_AUTH)
>    creates the IPsec SA also. The identities (a.k.a. traffic selectors
>    in IKEv2) used during Phase 2 are explained later along with the SPD
>    entries. As mentioned in section 4.0, an address (POPA) may also have
>
>
><Parthasarathy>          Expires January 2006                 [Page 6]
>
>                PANA enabling IPsec based Access Control      July 2005
>
>    to be configured. The address configuration method to be used by the
>    PaC is indicated in the PANA-Bind-Request message at the end of the
>    successful PANA authentication. The PaC chooses the appropriate
>    method and replies back in PANA-Bind-Answer message.

I'd add a sentence saying if PPAC's 'I' flag is ON, then the client 
MUST initiate address configuration through IKEv2.


>7.0 Packet Formats
>
>    Following acronyms are used throughout this document.
>
>    PAC-TIA denotes the IPsec-TIA used by the PaC. PAC-TIA may be set to
>    a PRPA when the same PRPA is used as the IPsec-TIA and IPsec-TOA on
>    the PaC. Otherwise, PAC-TIA is set to the POPA.
>
>    PAC-TOA denotes the IPsec-TOA used by the PaC.
>
>    EP-ADDR denotes the address of the EP.

IP address?

Suggest moving the acronyms and definitions to Section 2.1.


>    The node with which the PaC is communicating is denoted by END-ADDR.
>
>    Following is the IPv4 packet format on the wire for packets sent from
>    the PaC to the EP:
>
>          IPv4 header      (source = PAC-TOA,
>                            destination = EP-ADDR)
>          ESP  header
>          IPv4 header      (source = PAC-TIA,
>                            destination = END-ADDR)
>
>    Following is the IPv6 packet format on the wire for packets sent from
>    the PaC to the EP:
>
>          IPv6 header      (source = PAC-TOA,
>                            destination = EP-ADDR)
>          ESP  header
>          IPv6 header      (source = PAC-TIA,
>                            destination = END-ADDR)

IPv6 and IPv4 headers seem to be the same, so, why not specify 
once.  OTOH, if there are special consideration for IPv6 with the 
extension headers, that should be specified.


>    Following is the IPv4 packet format on the wire for packets sent from
>    the EP to the PaC:
>
>          IPv4 header      (source = EP-ADDR,
>                            destination = PAC-TOA)
>          ESP  header
>          IPv4 header      (source = END-ADDR,
>                            destination = PAC-TIA)
>
>    Following is the IPv6 packet format on the wire for packets sent from
>    the EP to the PaC:
>
>
>
><Parthasarathy>          Expires January 2006                 [Page 7]
>
>                PANA enabling IPsec based Access Control      July 2005
>
>          IPv6 header      (source = EP-ADDR,
>                            destination = PAC-TOA)
>          ESP  header
>          IPv6 header      (source = END-ADDR,
>                            destination = PAC-TIA)

Seems symmetric and duplicate!  See the earlier suggestion.


>8.0 IPsec SPD entries
>
>    The SPD entries for IPv4 and IPv6 are specified separately as they
>    are different. When the same address is used as IPsec-TIA and IPsec-
>    TOA, the EP can add the entry to the SPD before the IKE exchange
>    starts, as it knows the address a priori. When IKEv2 [IKEV2] or
>    [RFC3456] is used for address configuration, the SPD entry cannot be
>    created until the IPsec SA is successfully negotiated as the address
>    is not known a priori. This is very similar to the road warrior case
>    described in [IPSEC-BIS]. In this case, an SPD entry with a name
>    selector is used and when the IPsec SA is successfully negotiated, a
>    new SPD entry is created with the appropriate addresses. The name
>    would be the contents of ID_KEY_ID payload.
>
>    In environments where the PaC is a router, the IPsec-TIA can be a
>    range of addresses (prefix) instead of a single host address. The PaC
>    acts like a security gateway in this case establishing the IPsec SA
>    with another security gateway (EP). This scenario is supported by
>    [RFC2401] and [IPSEC-BIS]. It is assumed that the PaC obtains the
>    prefix through other mechanisms not defined in this document.

Where is this fully specified?  If this is an idea for future use, 
perhaps a future document might specify it fully.  Or, perhaps I am 
missing something.

>When
>    the IPsec SA is negotiated, the prefix is carried in the traffic
>    selectors.
>
>    Each SPD entry specifies packet disposition as BYPASS, DISCARD or
>    PROTECT. The entry that causes the traffic to be protected with IPsec
>    uses IPsec-TIA as the selector. This has the side effect of
>    protecting all the traffic, which could be a problem. Some of the
>    traffic that is not protected with IPsec is discussed below.
>
>      . The neighbor discovery messages specified in [RFC2461] are
>         protected using [RFC3971]. The Multicast listener Discovery
>         messages specified in [RFC2710] are also bypassed as IKE can
>         negotiate keys only for unicast traffic. The SPD contains entry
>         based on ICMPv6 type (130 to 137) to bypass such traffic.
>
>      . When IPsec-TIA and IPsec-TOA are the same (as discussed in
>         section 4.0), the PANA traffic also gets protected with IPsec.
>         As the IPsec protection adds extra overhead without any benefit,

Open-ended statement about IPsec! :) Do you mean that there is no 
benefit to IPsec protection of PANA traffic, since that protocol 
presumably protects whatever needs to be protected.

>         we need explicit entries to bypass IPsec protection for PANA
>         traffic on PaC. This may not be needed always for traffic going
>         from PAA to PaC. If PAA and EP are not co-located, PAA would
>         send traffic directly to PaC without going through EP. Hence, EP
>         does not need to have SPD entries to bypass IPsec in this case.
>
>
><Parthasarathy>          Expires January 2006                 [Page 8]
>
>                PANA enabling IPsec based Access Control      July 2005
>
>         If PAA and EP are co-located, the PANA packets will be protected
>         with IPsec only if the IPsec-TIA and IPsec-TOA are same. Hence,
>         we need explicit entries to bypass IPsec protection when PAA and
>         EP are co-located. The SPD entry is specified using PANA_PORT.
>         PANA_PORT is the IANA assigned (TBD) PANA protocol number [PANA-
>         PROT].
>
>    There may be protocols that expect the TTL to be 255, which may not
>    be preserved as a result of IP forwarding by the EP. If the protocol
>    termination is in a different place than EP, then we may need
>    additional bypass entries for those protocols, which are not shown
>    here. Also, when the PaC is using IPsec for remote access, there may
>    be additional SPD entries and IPsec security associations, which are
>    not discussed in this document.
>
>    The format chosen to represent the SPD rules is similar to the one
>    used in [IPSEC-BIS] document (See Appendix E). Following acronyms are
>    used.
>
>    Rule - SPD rule and this column has ordered rules.
>    LADDR - Local address
>    RADDR - Remote address
>    LPORT - Local Port
>    RPORT - Remote Port
>    ITYPE - Specifies ICMPv6 type
>    Action - Specifies the IPsec actions (BYPASS, DROP, PROTECT)
>
>
>8.1 IPv4 SPD entries
>
>    PaC's SPD:
>
>
>             Rule     LADDR     RADDR    LPORT    RPORT      Action
>             ----     -----     -----    -----    -----      ------
>             Rule 1    ANY    PAA-ADDR    ANY    PANA_PORT   BYPASS
>
>             Rule 2  PAC-TIA    ANY       ANY      ANY       PROTECT
>                                                           (ESP, tunnel)
>
>             Rule 3    ANY      ANY       ANY      ANY        DISCARD
>
>
>    The ESP tunnel's outer source address is PAC-TOA and outer
>    destination address is EP-ADDR.
>
>
>
>
>
>
><Parthasarathy>          Expires January 2006                 [Page 9]
>
>                PANA enabling IPsec based Access Control      July 2005
>
>
>
>    EP's SPD:
>
>
>             Rule     LADDR    RADDR     LPORT    RPORT     Action
>             ----     -----    -----     -----    -----     ------
>             Rule 1  PAA-ADDR   ANY     PANA_PORT  ANY      BYPASS
>
>             Rule 2    ANY     PAC-TIA    ANY      ANY      PROTECT
>                                                          (ESP, tunnel)
>
>             Rule 3    ANY      ANY       ANY      ANY       DISCARD
>
>    The ESP tunnel's outer source address is EP-ADDR and outer
>    destination address is PAC-TOA.
>
>    The phase 2 identities (a.k.a. traffic selectors in IKEv2) differ
>    depending on how the PaC acquires the PAC-TIA.

I am not sure IKE Phase2 and TS in IKEv2 are the same thing!


>      . If the client uses PAC-TOA as the PAC-TIA, then it uses PAC-TOA
>         as the client identity (IDci). The responder identity (IDcr)
>         would contain the ID_IPV4_ADDR_RANGE with starting address as
>         zero address (0.0.0.0) and end address as (255.255.255.255).
>
>      . If the client uses [RFC3456] for acquiring the PAC-TIA, it needs
>         to establish the DHCP SA first. This requires additional SPD
>         entries. Once the PAC-TIA is acquired using DHCP, the DHCP SA is
>         deleted and a new IPsec tunnel mode SA is established as
>         specified in this document. When establishing such an SA, PAC-
>         TIA will be used as the IDci. The responder identity (IDcr)would
>         contain the ID_IPV4_ADDR_RANGE with starting address as zero
>         address (0.0.0.0) and end address as (255.255.255.255).
>
>      . If IKEv2 is used to obtain the PAC-TIA, the client uses the
>         configuration request (CFG_REQUEST) along with the traffic
>         selectors as given in IKEv2. PaC uses IPV4_ADDR_RANGE with
>         starting address as zero address (0.0.0.0) and end address as
>         (255.255.255.255) for both TSi and TSr. The EP assigns the
>         address (PAC-TIA) and returns it in both the configuration
>         payload (CFG_REPLY) and TSi. The TSr is left to contain the
>         IPV4_ADDR_RANGE.

What about the case of prefixes mentioned earlier?


>8.2 IPv6 SPD entries
>
>
>
>
>
>
>
><Parthasarathy>          Expires January 2006                [Page 10]
>
>                PANA enabling IPsec based Access Control      July 2005
>
>
>
>    Pac's SPD:
>
>             Rule    LADDR  RADDR   LPORT     RPORT  ITYPE   Action
>             ----    -----  -----   -----     -----  -----   ------
>             Rule 1   ANY    ANY     ANY       ANY   130-137  BYPASS
>
>             Rule 2   ANY    ANY   PANA_PORT   ANY    ANY     BYPASS
>
>             Rule 3  PAC-TIA ANY     ANY       ANY    ANY     PROTECT
>                                                            (ESP, tunnel)
>
>             Rule 4   ANY    ANY     ANY       ANY    ANY      DISCARD
>
>
>    The ESP tunnel's outer source address is PAC-TOA and outer
>    destination address is EP-ADDR.
>
>    EP's SPD:
>
>             Rule    LADDR  RADDR   LPORT   RPORT    ITYPE   Action
>             ----    -----  -----   -----   -----    -----   ------
>             Rule 1   ANY    ANY     ANY     ANY     130-137  BYPASS
>
>             Rule 2   ANY    ANY     ANY   PANA_PORT   ANY    BYPASS
>
>             Rule 3   ANY   PAC-TIA  ANY     ANY       ANY    PROTECT
>                                                            (ESP, tunnel)
>
>             Rule 4   ANY    ANY     ANY     ANY       ANY     DISCARD
>
>
>    The ESP tunnel's outer source address is EP-ADDR and outer
>    destination address is PAC-TOA.
>
>    IKEv2 [IKEV2] is used to configure the PAC-TIA address. The usage of
>    traffic selectors is very similar to the IPv4 usage as explained in
>    the previous section. The client may use the interface identifier in
>    the lower bits of the TSi so that the responder can assign an IPv6
>    address honoring the interface identifier also.
>
>9.0 Dual Stack Operation
>
>    IKEv2 [IKEV2] can enable configuration of IPsec-TIA for both IPv4 and
>    IPv6 TIAs by sending both IPv4 and IPv6 configuration attributes in
>    the configuration request (CFG_REQUEST). This enables use of single
>    IPsec tunnel mode SA for sending both IPv4 and IPv6 traffic.
>
>
>
><Parthasarathy>          Expires January 2006                [Page 11]
>
>                PANA enabling IPsec based Access Control      July 2005
>
>    Therefore, IKEv2 is recommended for handling dual-stack PaCs where
>    single execution of IKE is desired.

Perhaps this needs a bit more explanation.  As written, it reads like 
IKEv2 can do something, so let's do it using IKEv2.  Please motivate 
the need for dual-stack operation and RECOMMEND IKEv2 to do it.

If it is only a recommendation, when is it ok to use something 
else?  And what might be those alternatives.

Note:  I made it to the end of the document without seeing a 
recommendation or requirement for the type of IPsec protection 
required.  Based on the requirement (enforcing network access 
control) mentioned early on, it appears that ESP-NULL is 
sufficient.  A mandatory (MUST) and a recommended (SHOULD+ or SHOULD) 
crypto suite should be specified.


>10.0 IANA Considerations
>
>    This document does not make no request to IANA.

Double negative! :)




>10.0 Security considerations
>
>    This document discusses the use of IPsec for access control when PANA
>    is used for authenticating the clients to the access network.
>
>    The aggressive mode in IKE [RFC2409] is considered bad due to its DoS
>    properties i.e.,

nit: DoS is not a property!

>any attacker can bombard IKE aggressive mode packets
>    making the EP perform heavy diffie-hellman calculations. As the
>    ID_KEY_ID can be verified by the EP before doing the diffie-hellman
>    calculation, it prevents random attacks. The attacker now needs to
>    listen on the traffic between PaC and PAA to originate IKE requests
>    with valid ID_KEY_ID.

I have already suggested the use of IKEv2 alone and delete text related to
IKE.


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

So, this says that the entire IKEv2+IPsec based scheme is useless 
unless the EP verifies address authorization!  This points to a 
serious hole in the specification.  Perhaps I am misreading the text.

>When IKEv2 [IKEV2] and [RFC3456] are used for address
>    configuration, the address is assigned by the EP and hence this
>    attack is not present in such cases. When the same address is used as
>    both IPsec-TIA and IPsec-TOA, the EP creates the SPD entry with the
>    appropriate address for the PaC and hence the address is verified
>    implicitly by the virtue of successful IPsec SA negotiation.

Right, so are we saying that if TIA and TOA are not the same, IPsec 
is useless?  Please clarify!


>11.0 Normative References
>
>    Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9,
>       RFC 2026, October 1996.
>
>    [RFC2401] S. Kent et al., "Security Architecture for the Internet
>       Protocol", RFC 2401, November 1998
>
>    [PANA-PROT] D. Fosberg et al., "Protocol for Carrying Authentication
>       for Network Access", draft-ietf-pana-06.txt
>
>    [RFC4016] M. Parthasarathy, "Protocol for carrying Authentication for
>       Network Access (PANA) Threat analysis and security requirements",
>       RFC 4016, March 2005
>
>12.0 Informative References
>
>
>
>
>
><Parthasarathy>          Expires January 2006                [Page 12]
>
>                PANA enabling IPsec based Access Control      July 2005
>
>    [PANAREQ] A. Yegin et al., "Protocol for Carrying Authentication for
>       Network Access (PANA) Requirements and Terminology", draft-ietf-
>       pana-requirements-09.txt
>
>    [PANA-FRAME] P. Jayaraman et al., "PANA Framework", draft-ietf-pana-
>       framework-01.txt
>
>    [RFC2119] S. Bradner, "Key words for use in RFCS to indicate
>       requirement levels", RFC 2119, March 1997
>
>    [RFC2409] D. Harkins et al., "Internet Key Exchange", RFC 2409,
>       November 1998
>
>    [IKEV2] C. Kauffman et al., "Internet Key Exchange(IKEv2) Protocol",
>       draft-ietf-ipsec-ikev2-15.txt
>
>    [IPSEC-BIS] S. Kent, "Security Architecture for the Internet
>       Protocol", draft-ietf-ipsec-rfc2401bis-06.txt
>
>    [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131,
>       March 1997
>
>    [RFC3456] B. Patel et al., "Dynamic Host Configuration Protocol
>       (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January
>       2003
>
>    [RFC3315] R. Droms et. al, "Dynamic Host Configuration Protocol for
>       IPv6", RFC 3315, July 2003
>
>    [RFC2461] T. Narten et al., "Neighbor Discovery for IP version 6
>       (IPv6) ", RFC 2461, December 1998
>
>    [RFC2462] S. Thomson et. al, "IPv6 Stateless Address
>       Autoconfiguration", RFC 2462, December 1998
>
>    [RFC3041] T. Narten et al., "Privacy Extensions for Stateless Address
>       Autoconfiguration in IPv6", RFC 3041, January 2001
>
>    [EAP-KEY] B. Aboba et al., "EAP Key Management Framework", draft-
>       ietf-eap-keying-06.txt
>
>    [RFC3971] J. Arkko et al., "SEcure Neighbor Discovery (SEND)", RFC
>       3971, March 2005
>
>    [IPV4-LINK] B. Aboba et al., "Dynamic configuration of Link-local
>       IPv4 addresses", draft-ietf-zeroconf-ipv4-linklocal-12.txt
>
>    [RFC1918] Y. Rekhter et al., "Address Allocation for Private
>       Internets", BCP 5, RFC 1918, February 1996
>
>
><Parthasarathy>          Expires January 2006                [Page 13]
>
>                PANA enabling IPsec based Access Control      July 2005
>
>
>    [RFC2710] S.Deering et al., "Multicast Listener Discovery (MLD)for
>       IPv6", RFC 2710, October 1999
>
>    [IEEE80211i] IEEE Draft 802.11I/D5.0, "Draft Supplement to STANDARD
>       FOR Telecommunications and Information Exchange between Systems
>       LAN/MAN Specific Requirements - Part 11: Wireless Medium Access
>       Control (MAC) and physical layer specifications: Specification for
>       Enhanced Security", August 2003.
>
>13.0 Acknowledgments
>
>    The author would like to thank Francis Dupont, Pasi Eronen, Yoshihiro
>    Ohba, Jari Arkko, Hannes Tschofenig, Alper Yegin, Erik Nordmark,
>    Giaretta Gerardo, Rafa Marin Lopez, Tero Kivinen and other PANA WG
>    members for their valuable comments and discussions.
>
>14.0 Revision log
>
>    Changes between revision 06 and 07
>
>    -Changed the format of the SPD to use a table
>    -Changed the IPv6 SPD entries to use ICMPv6 types
>
>    Changes between revision 05 and 06
>
>    -Clarified that PRPA can be a global address also in IPv6.
>
>    Changes between revision 04 and 05
>
>    -working group last call comments (mostly editorial)
>
>    Changes between revision 03 and 04
>
>    -Comments from Erik Nordmark (mostly editorial)
>
>    Changes between revision 02 and 03
>
>    -Clarified the use of key-Id in ID_KEY_ID payload
>    -Clarified the address configuration issues.
>    -Added an Appendix to clarify implementation issues.
>
>    Changes between revision 01 and 02
>
>    -Updated the draft with the fixes for all open issues
>    -Added the IP configuration section
>    -Modified the IKE pre-shared key derivation to handle PAA controlling
>    multiple EPs
>    -Clarification regarding DHCP usage and RFC3456 usage.
>
>
><Parthasarathy>          Expires January 2006                [Page 14]
>
>                PANA enabling IPsec based Access Control      July 2005
>
>    -Only aggressive mode to be supported. Main mode not needed anymore.
>
>    Changes between revision 00 and 01
>
>    -Specified the use of ESP tunnel mode SA instead of IP-IP transport
>    mode SA after working group discussion.
>    -Specified the IKE pre-shared key derivation.
>
>15.0 Appendix A

I didn't review this.  Might do it in a future review.


>   <snip>

--- End Message ---

--- Begin Message ---

> There is also the debate on "who uses PANA" or "why does PANA make 
> sense" and I for one think that as specified, the PANA suite of 
> protocols are too complex to be of use anywhere.  But, it's up to the 
> IESG to make that call and whether that influences the publication of 
> the specifications.
> 
> I do appreciate and respect the fact that the PANA documents reflect 
> the PANA WG consensus, and so my comments below are strictly 
> technical and to produce a quality RFC.  

To be clear, this is an IETF Last Call, so that it is ok to express 
opinions on whether this protocol is suitable for publication as an 
IETF Proposed Standard. 

> 1. The document should restrict itself to IKEv2 and IPsec as in 4301 
> and 4303.  There is also a reference to MOBIKE in PANA protocol, but 
> this document doesn't talk about that.  Perhaps that gap needs to be
filled.

As far as I can tell, one of the motivations for this document is the need 
to support EAP authentication with IKEv1.  If use of PANA/IPsec were 
to be restricted to IKEv2, it seems like it would be less useful 
since IKEv2 already supports EAP authentication. 

> 5. The security considerations section says, "If the EP does not 
> verify whether the PaC is authorized to use an IP address, it is 
> possible for the PaC to steal the traffic destined to some other PaC."

This issue does not exist with IKEv2/EAP because the EAP exchange 
is cryptographically bound to the IKEv2 exchange. 

> >      2) The PaC learns the IP address of the Enforcement point (EP)
> >         during the PANA exchange.
> >
> >      3) The PaC learns that the network uses IPsec [RFC2401] for
> >         securing the link between the PaC and EP during the PANA
> >         exchange.

Note that if the EP and PAA are identified distinctly then they 
cannot be thought of as a "distributed authenticator".  That in turn 
implies that EAP keying material is transported outside the boundary of 
the EAP authenticator.  I believe that this creates an issue with the AAA 
Key Management guidelines, because now the EP can impersonate the 
Authenticator. 

> Just curious about PRPA being a global address.  If the PaC already 
> has a globally routable address, why would it care to go through 
> IKEv2 and access enforcement?  

Think of the EP acting as a VPN server for access control, in the same 
manner as this is deployed in 802.11 networks that choose not to use link 
layer authentication. 

> >    The IKE exchange between the PaC and PAA is equivalent to the 4-way
> >    handshake in [IEEE80211i] following the EAP exchange. The IKE
> >    exchange establishes the IPsec SA similar to the pair-wise transient
> >    key (PTK) established in [IEEE80211i].
> 
> I am not sure whether the mention of 4-way handshake is adding any 
> value here: it comes at the expense of making a broad statement about 
> the similarities between IKEv2 and the 4-way handshake.  They have 
> many more differences than similarities!

In this case the IKE exchange does not handle binding of the EAP exchange 
to the IKE exchange; this is handled in the PANA BIND exchange. So 
the analogy isn't quite right. 


> >    IKE Pre-shared Key = HMAC-SHA-1 (PaC-EP-Master-Key,
> >                            "IKE-preshared key" |
> >                            Session ID | Key-ID | EP-address)

Here "Session Id" does not appear to refer to the Session-Id defined in 
the EAP Key Management framework.  This is confusing. 

> 6. Why is the PaC ID not mixed in here?

I'd suggest that both the EP and Pac IDs need to be mixed in here, if the 
IKE pre-shared key is to be properly bound. 

> Ok, it looks like if re-authentication occurs the PSK changes and a 
> new IKEv2 run is required.  How does the switchover happen?  Do the 
> PaC and EP tear down IKEv2 and IPsec SAs at the beginning of 
> re-authentication or at the end or is it a matter of local 
> policy.  If it's based on local policy, do we assume that either the 
> EP or the PaC will tear down the SAs at will (IKEv2 of course allows 
> that, so it's easy to write a few lines on it).
> 
> I think others raised this question as well, indicating the strong 
> need for additional details.

The situation is particularly tricky when the PAA and EP exist on separate 
entities.  When the PANA BIND exchange completes between the PaC and PAA, 
do we really expect the PaC - EP re-key to occur simultaneously?  This 
seems unlikely.  In the period until re-key propagation completes, I am 
not sure how the PaC or EP know what the key state is.  For example, is 
the PaC/EP supposed to maintain two sets of PSKs? 

> >    Following is the IPv4 packet format on the wire for packets sent from
> >    the PaC to the EP:

I'm not sure why this needs to be specified here.  Isn't this negotiated 
within IKE?  Or is there some implication that PANA is configuring IKE so 
that only this configuration can be used? 

> >8.0 IPsec SPD entries

Again, since IKE appears to be mandatory I'm not sure why the SPDs need to 
be specified here -- they are just negotiated in IKE, no?  Or is there 
some implication that PANA is modifying the IKE configuration so that 
*only* these SPDs can be negotiated? 

> Open-ended statement about IPsec! :) Do you mean that there is no 
> benefit to IPsec protection of PANA traffic, since that protocol 
> presumably protects whatever needs to be protected.

In fact, if IPsec is being used to protect other data, I'm not clear why 
it wouldn't protect PANA as well.  If EP and PAA are co-located, you'd 
think that would be relatively trivial for EAP re-auth.  Since EAP 
exchanges are protected within IKEv2/EAP mode, it seems like PANA/IPsec is 
less secure in this respect. 

> So, this says that the entire IKEv2+IPsec based scheme is useless 
> unless the EP verifies address authorization!  This points to a 
> serious hole in the specification.  Perhaps I am misreading the text.

There does seem to be a binding issue here.  

--- End Message ---

--- Begin Message ---

Hi Bernard,

Thanks for your notes.  Some thoughts inline:

At 10:28 AM 5/21/2006, Bernard Aboba wrote:
> > There is also the debate on "who uses PANA" or "why does PANA make
> > sense" and I for one think that as specified, the PANA suite of
> > protocols are too complex to be of use anywhere.  But, it's up to the
> > IESG to make that call and whether that influences the publication of
> > the specifications.
> >
> > I do appreciate and respect the fact that the PANA documents reflect
> > the PANA WG consensus, and so my comments below are strictly
> > technical and to produce a quality RFC.
>
>To be clear, this is an IETF Last Call, so that it is ok to express
>opinions on whether this protocol is suitable for publication as an
>IETF Proposed Standard.

Thank you.


> > 1. The document should restrict itself to IKEv2 and IPsec as in 4301
> > and 4303.  There is also a reference to MOBIKE in PANA protocol, but
> > this document doesn't talk about that.  Perhaps that gap needs to 
> be filled.
>
>As far as I can tell, one of the motivations for this document is the need
>to support EAP authentication with IKEv1.  If use of PANA/IPsec were
>to be restricted to IKEv2, it seems like it would be less useful
>since IKEv2 already supports EAP authentication.

I think new IETF protocols should specify the use of IKEv2 and not 
IKEv1.  If PANA is less useful in the world with IKEv2, well, I guess 
it's less useful than when the work was chartered!


> > 5. The security considerations section says, "If the EP does not
> > verify whether the PaC is authorized to use an IP address, it is
> > possible for the PaC to steal the traffic destined to some other PaC."
>
>This issue does not exist with IKEv2/EAP because the EAP exchange
>is cryptographically bound to the IKEv2 exchange.

Right, authentication via IKEv2 AUTH payloads wouldn't succeed if EAP 
didn't succeed.


> > >      2) The PaC learns the IP address of the Enforcement point (EP)
> > >         during the PANA exchange.
> > >
> > >      3) The PaC learns that the network uses IPsec [RFC2401] for
> > >         securing the link between the PaC and EP during the PANA
> > >         exchange.
>
>Note that if the EP and PAA are identified distinctly then they
>cannot be thought of as a "distributed authenticator".  That in turn
>implies that EAP keying material is transported outside the boundary of
>the EAP authenticator.  I believe that this creates an issue with the AAA
>Key Management guidelines, because now the EP can impersonate the
>Authenticator.

Yep, this would not be inline with the guidance of
draft-housley-aaa-key-mgmt.


> > Just curious about PRPA being a global address.  If the PaC already
> > has a globally routable address, why would it care to go through
> > IKEv2 and access enforcement?
>
>Think of the EP acting as a VPN server for access control, in the same
>manner as this is deployed in 802.11 networks that choose not to use link
>layer authentication.

My limited understanding here has been that VPNs controlling dot11 
access don't provide *global* addresses.  This is probably ok, if we 
can ensure that the IPsec GW enforces appropriate access control.


> > >    The IKE exchange between the PaC and PAA is equivalent to the 4-way
> > >    handshake in [IEEE80211i] following the EAP exchange. The IKE
> > >    exchange establishes the IPsec SA similar to the pair-wise
transient
> > >    key (PTK) established in [IEEE80211i].
> >
> > I am not sure whether the mention of 4-way handshake is adding any
> > value here: it comes at the expense of making a broad statement about
> > the similarities between IKEv2 and the 4-way handshake.  They have
> > many more differences than similarities!
>
>In this case the IKE exchange does not handle binding of the EAP exchange
>to the IKE exchange; this is handled in the PANA BIND exchange. So
>the analogy isn't quite right.
>
>
> > >    IKE Pre-shared Key = HMAC-SHA-1 (PaC-EP-Master-Key,
> > >                            "IKE-preshared key" |
> > >                            Session ID | Key-ID | EP-address)
>
>Here "Session Id" does not appear to refer to the Session-Id defined in
>the EAP Key Management framework.  This is confusing.

Probably the PANA session ID!

> > 6. Why is the PaC ID not mixed in here?
>
>I'd suggest that both the EP and Pac IDs need to be mixed in here, if the
>IKE pre-shared key is to be properly bound.
>
> > Ok, it looks like if re-authentication occurs the PSK changes and a
> > new IKEv2 run is required.  How does the switchover happen?  Do the
> > PaC and EP tear down IKEv2 and IPsec SAs at the beginning of
> > re-authentication or at the end or is it a matter of local
> > policy.  If it's based on local policy, do we assume that either the
> > EP or the PaC will tear down the SAs at will (IKEv2 of course allows
> > that, so it's easy to write a few lines on it).
> >
> > I think others raised this question as well, indicating the strong
> > need for additional details.
>
>The situation is particularly tricky when the PAA and EP exist on separate
>entities.  When the PANA BIND exchange completes between the PaC and PAA,
>do we really expect the PaC - EP re-key to occur simultaneously?  This
>seems unlikely.  In the period until re-key propagation completes, I am
>not sure how the PaC or EP know what the key state is.  For example, is
>the PaC/EP supposed to maintain two sets of PSKs?

This definitely needs clarification from the author and the PANA WG.


> > >    Following is the IPv4 packet format on the wire for packets sent
from
> > >    the PaC to the EP:
>
>I'm not sure why this needs to be specified here.  Isn't this negotiated
>within IKE?  Or is there some implication that PANA is configuring IKE so
>that only this configuration can be used?
>
> > >8.0 IPsec SPD entries
>
>Again, since IKE appears to be mandatory I'm not sure why the SPDs need to
>be specified here -- they are just negotiated in IKE, no?  Or is there
>some implication that PANA is modifying the IKE configuration so that
>*only* these SPDs can be negotiated?
>
> > Open-ended statement about IPsec! :) Do you mean that there is no
> > benefit to IPsec protection of PANA traffic, since that protocol
> > presumably protects whatever needs to be protected.
>
>In fact, if IPsec is being used to protect other data, I'm not clear why
>it wouldn't protect PANA as well.  If EP and PAA are co-located, you'd
>think that would be relatively trivial for EAP re-auth.  Since EAP
>exchanges are protected within IKEv2/EAP mode, it seems like PANA/IPsec is
>less secure in this respect.
>
> > So, this says that the entire IKEv2+IPsec based scheme is useless
> > unless the EP verifies address authorization!  This points to a
> > serious hole in the specification.  Perhaps I am misreading the text.
>
>There does seem to be a binding issue here.

Yep.  I don't see any disagreements in our analyses Bernard.

regards,
Lakshminath 

--- End Message ---

--- Begin Message ---

> If PANA is less useful in the world with IKEv2, well, I guess it's less 
> useful than when the work was chartered!

One of the principles of RFC 1958 is:

  3.2 If there are several ways of doing the same thing, choose one.

If there is substantial overlap in the needs addressed by RFC 4306 
(IKEv2/EAP) and PANA/IPsec, then I'm not clear why we would need both of 
them. 

> My limited understanding here has been that VPNs controlling dot11 access
> don't provide *global* addresses.  This is probably ok, if we can ensure
that
> the IPsec GW enforces appropriate access control.

Assigning an IPv4 link-local address is illegal in RFC 3927, but it is 
possible to assign a private or global address. 

> Probably the PANA session ID!

I'm not sure why two session identifiers are necessary to identify the 
same exchange.  The EAP Session-Id uniquely identifies the EAP 
conversation, and since PANA is an EAP transport, it would seem that it 
would also uniquely represent the PANA conversation too.  Having two 
Session-Ids to uniquely identify a conversation seems like it could result 
in confusion, particularly if both Session-Ids were sent to an 
authenticator.  It seems like this could result in multiple names for the 
same keys. 

This problem does not occur in IKEv2/EAP because the EAP keys are used 
immediately for authentication and are discarded once the IKEv2 exchange 
completes. 

> > When the PANA BIND exchange completes between the PaC and PAA,
> > do we really expect the PaC - EP re-key to occur simultaneously?  This
> > seems unlikely.  In the period until re-key propagation completes, I am
> > not sure how the PaC or EP know what the key state is.  For example, is
> > the PaC/EP supposed to maintain two sets of PSKs?
> 
> This definitely needs clarification from the author and the PANA WG.

I agree.  In practice, I don't think that the PANA architecture provides 
the tight consistency required to handle a 3 party re-key.  This could 
even become a problem in a 2 party scenario where the PANA exchange might 
itself be secured via IPsec.  In this case, if it is not clear exactly 
when the new keys are installed, then there might not be an easy way to 
get back in sync if the PaC and PAA installed incompatible key state.  

This problem also does not occur in IKEv2/EAP. 

> > > So, this says that the entire IKEv2+IPsec based scheme is useless
> > > unless the EP verifies address authorization!  This points to a
> > > serious hole in the specification.  Perhaps I am misreading the
> > > text.
> > 
> > There does seem to be a binding issue here.
> 
> Yep.  I don't see any disagreements in our analyses Bernard.

Yes, I think we're in agreement. 

--- End Message ---

--- Begin Message ---

I'm having some high-level questions about the document and the proposed
protocol:

* In general, I was missing a clear discussion of the percieved security
threats that this protocol is supposed to protect against.

* Specifically, is the purpose to provide *secrecy* for the communication
between the endpoint (PaC) and the access router (AR), or only authenticity?
It is not clear to me why one would want to provide secrecy at this level.
Presumably, if the PaC wants to keep its communication secret it would do
end-to-end encryption with whomever it is interacting, which is unlikely
to be the AR. So I assume it is only authenticity. (In either case, this
point should probably be discussed in the security considerations
section.)

* The protocol seems to go to great lengths to fit the information
generated by the underlying AAA mechanism in a format that IKE likes,
with variants for v1 and v2. But I didnt understand why IKE needs to be
used in the first place. The PaC and the authentication agent already have
a shared key from the AAA authentication. So why go throught the extra
complexity of IKE, with its additional round trips, Diffie-Hellman
exponentiations, DoS volunerabilities, etc.,  rather than use the AAA
shared keys manually to generate an IPsec SA for authenticating packets?

Best,

Ran




On Sat, 13 May 2006, Sam Weiler wrote:

> Would you both do a review of the below draft, perferably within a
> week?  Please let me know either way.
>
> For this one, please send your review to Mark Townsley as well as the
> usual suspects (Russ, Sam, and [e-mail]).  More
> substantive comments should go to the security directorate
> (<[e-mail]>), the document editors, and the PANA WG chairs,
> also.
>
> Again, please let me know if you'll be able to do this one.
>
> -- Sam
>
>
> ---------- Forwarded message ----------
> Date: Thu, 11 May 2006 18:24:30 +0200
> From: Mark Townsley <[e-mail]>
> To: Sam Hartman <[e-mail]>, Russ Housley
<[e-mail]>
> Subject: pana ipsec review
>
> I have in the tracker that I requested a security area review of
> draft-ietf-pana-ipsec-07.txt
> <http://www.ietf.org/internet-drafts/draft-ietf-pana-ipsec-07.txt> on or
> around 03/17. I don't have my email from that time due to my disk crash,
> but I do remember taking action here, and possibly even hearing back
> from one of you that it was going to happen - I think it was Russ, but
> am not sure.
>
> - Mark
>
>
>

--- End Message ---

--- Begin Message ---

Sam,

On Wed, 17 May 2006, Sam Hartman wrote:

> >>>>> "canetti" == canetti  <[e-mail]> writes:
>
>     canetti> I'm having some high-level questions about the document
>     canetti> and the proposed protocol:
>
>     canetti> * In general, I was missing a clear discussion of the
>     canetti> percieved security threats that this protocol is supposed
>     canetti> to protect against.
> RFC 4016 claims to fill this role.

Indeed. it's even referenced. thx.

>
>     canetti> * Specifically, is the purpose to provide *secrecy* for
>     canetti> the communication between the endpoint (PaC) and the
>     canetti> access router (AR), or only authenticity?  It is not
>     canetti> clear to me why one would want to provide secrecy at this
>     canetti> level.  Presumably, if the PaC wants to keep its
>     canetti> communication secret it would do end-to-end encryption
>     canetti> with whomever it is interacting, which is unlikely to be
>     canetti> the AR. So I assume it is only authenticity. (In either
>     canetti> case, this point should probably be discussed in the
>     canetti> security considerations section.)
>
> Note that for links like 802.11 people have felt that confidentiality
> is important.

But is it confidentiality between the PaC and the access point, or
end-to-end secrecy?  In 4016 there is no mentioning of confidentiality as
a concern.

>
>     canetti> * The protocol seems to go to great lengths to fit the
>     canetti> information generated by the underlying AAA mechanism in
>     canetti> a format that IKE likes, with variants for v1 and v2. But
>     canetti> I didnt understand why IKE needs to be used in the first
>     canetti> place. The PaC and the authentication agent already have
>     canetti> a shared key from the AAA authentication. So why go
>     canetti> throught the extra complexity of IKE, with its additional
>     canetti> round trips, Diffie-Hellman exponentiations, DoS
>     canetti> volunerabilities, etc., rather than use the AAA shared
>     canetti> keys manually to generate an IPsec SA for authenticating
>     canetti> packets?
>
> In your opinion does the current text go so far as to describe a key
> management protocol?  Put more usefully, does this document do things
> that would require the same degree of review I would expect from a new
> key management protocol?
>

I woundn't say so. The text only specifies how to setup the parameters for
IKE in pre-shared key mode. This is indeed a delicate enough tesk in
itself, but I didnt find any glaring holes there.

Still, as I said, I dont see why they need IKE in the first place...

Ran

--- End Message ---

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