Subject: PANA over TLS comments

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 22 Oct 2002 15:31:07 -0700

Here is few initial comments on draft-ohba-pana-potls-00.txt

- According to the Protocol Overview, reliable transmission
  is provided by the transport (TCP, SCTP). But EAP provides
  its own retransmission. Having two mechanisms for can create
  issues....

- At the Yokohama IETF we had decided not to require a heartbeat
  mechanism, instead rely on re-authentication only.

- I'm not sure if this protocol provides a disconnect
  indication (see requirement 4.2.2)

- As a device identifier, there should be a way to specify
  only link-layer address, imo.

- PANA without TLS: Aside from using EAP methods that can
  create a secure channel first (e.g., PEAP, TTLS), we should
  also think about scenarios where the media under PANA is 
  is secure (e.g., physical security in DSL, or encrypted link-layer
  in 3GPP2). Supporting a mode that utilizes this lower-layer
  security is desirable.

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 22 Oct 2002 20:01:44 -0400

Thanks Alper for your comments.

Please see my comments below.

>   its own retransmission. Having two mechanisms for can create

Yes, description about retransmission policy is missing in the draft.
On the other hand, it may be an issue of EAP, meaning that EAP
specification may need to be revised to consider its own
retransmission policy when it works over reliable transport.

>   mechanism, instead rely on re-authentication only.

I'm not sure whether we had decided that heartbeat MUST NOT be used
any time.  In fact, the following text in the requirement draft is not
clear to me:

   Several mechanisms can be used to provide disconnect indication,
   e.g., frequent re-authentication; but the use of a heartbeat
   function is not recommended. 

>   indication (see requirement 4.2.2)

Implicit disconnect detection is supported by either AHP or periodical
re-authentication based on Fast Authentication.  

Explicit disconnection is supported when AHP is used, by terminating
the TLS connection (either PaC or PAA can initiate termination).

Explicit disconnection in the case where AHP is not used is
not clearly described in the document.  There may be two options, one
is to keep the transport connection after successful
authentication. The other is to define some option for Fast
Authentication to indicate explicit disconnection.

>   only link-layer address, imo.

I once considered that but I did not include it in the 1st cut of the
draft, because some additional negotiation process would be needed for
determining which type of DI is used when it is supported.  We can
discuss this issue later.

>   in 3GPP2). Supporting a mode that utilizes this lower-layer

If the following thing described in the section 7 of PANA over TLS
draft is not a concern in a particular environment, I think PANA
without TLS is also possible:

   Note that whatever EAP-based protection mechanism is applied to EAP
   header and/or payload, AuthInfo messages that carry EAP messages
   should be at least integrity protected if the PAA acts as a pass-
   through EAP authenticator so that an attacker cannot propagate
   "integrity broken" EAP messages all the way to the authentication
   server.  If those messages are integrity protected by the PANA over
   TLS protocol, the PAA can immediately reject them before injecting
   into the backend authentication infrastructure.

I would like to mention that the basic design policy of this protocol
is starting from a design with a maximal level of security (I don't
say the current draft provides the maximum level of security, since we
have received some important comment on further security
consideration).  We could loosen the security level of this protocol
in specific environments to a degree at which the entire security
level is still maintained, with very careful investigation.  This is
similar to the firewall management strategy.

Anyway, starting from a compromised level is not a good idea.

> alper

Thanks again,

Yoshihiro Ohba

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 23 Oct 2002 19:38:14 -0700

> retransmission policy when it works over reliable transport.

Is this in the scope of EAP WG (yet)?

>    function is not recommended. 

Well, OK, inclusion of heartbeat in the protocol design is neither 
required nor recommended. It's not prohibited either though.

> Authentication to indicate explicit disconnection.

.. which can come from both sides, i.e., PaC and PAA.

> similar to the firewall management strategy.

Agreed.

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 24 Oct 2002 10:09:20 -0400

Alper,

> Is this in the scope of EAP WG (yet)?

I found the following text in draft-ietf-pppext-rfc2284bis-06.txt:

  When run over a reliable lower layer (e.g. EAP over ISAKMP/TCP, as
  within [PIC]), the EAP retransmission timer SHOULD be set to an
  infinite value, so that retransmissions do not occur at the EAP
  layer.

So I think it is in the scope of EAP WG.

> required nor recommended. It's not prohibited either though.

OK.  

> .. which can come from both sides, i.e., PaC and PAA.

OK.  We will revise the draft to support disconnect indication 
from both sides.

Yoshihiro Ohba