RE: Reminder: last call for PIC in the IPSRA WG

["Yaron Sheffer" <yaronf@xxxxxxx>]

Hi William,

thanks for your thorough response.

Regarding NAT traversal, PIC does not have the issues that full IKE needs to
solve. So PIC over NAT only requires that the server not check the source
port, and of course reply on that same port. See Sec. 4.1 in the draft.

Regarding DOS protection. As Hugo mentioned in his recent mail, it is a
simple matter to add 2 messages between messages (1) and (2), thus verifying
the routability of the client. However, it is obviously not a change to be
done at the last moment. Unless we can think of a better solution, the
Exchange Type (Sec. 3.1) can be treated as a PIC version number, and such
extensions can be added in the future. That is, if people are willing to pay
for DOS protection by an additional exchange. I would appreciate any
proposal of a more elegant, forward compatible mechanism.

Regarding fragmentation, I share your concern. It is an issue for PIC, just
as it is for IKE. As an anecdote, *TCP* port 500 is reserved for ISAKMP.
Maybe that's the way to go...

See more comments below, prefixed by YS.

Thanks,
	Yaron

-----Original Message-----
From: owner-ietf-ipsra@xxxxxxxxxxxxx
[mailto:owner-ietf-ipsra@xxxxxxxxxxxxx]On Behalf Of William Dixon
Sent: Wednesday, October 17, 2001 7:56 PM
To: Hugo Krawczyk; Markus Stenberg
Cc: working group ipsra; Bernard Aboba; Anton Krantz
Subject: RE: Reminder: last call for PIC in the IPSRA WG



Hugo, et. al.  I have a couple of clarifications to ask.  Also, I
provide a review of EAP-TLS inside  PIC which is my exercise to be sure
that it should work, but I haven't implemented this.  I think the 12
exchanges required provides a good example where revised hash makes
things _much_ easier.  While I don't see any hard reason stopping PIC
>from last call WG, I couldn't implement it without the operational
additions of NAT traversal and DOS prevention.  We do see solid customer
requirements for more than just a password hash response to a challenge
to authenticate users, even requiring additional organizational data,
such as office phone or manager's name before the certificate is issued.
This would be provided either as extensions to an EAP method or in the
opaque cert request, depending on which backend component validates the
information.  If it happens in EAP, then certainly the number of message
exchanges will extend possibly beyond your stated limit of 10  (repeats
of messages 3 & 4).  I assume VENDOR-ID payloads are allowed to
advertise extension capability as they become needed ala IKE.

YS: yes, ISAKMP notification, including VENDOR-ID are OK.

Reference
http://www.ietf.org/internet-drafts/draft-ietf-ipsra-pic-03.txt

Addition #1 - make sure nobody fails the use of private use Type values.

The text already does say:
"All other Type-Subtype combinations are undefined. They MUST NOT be
sent, and MUST be rejected if  received." which I think is meant "out of
the Types that are defined that are not in the private use  range."

I'd like a very clear statement in section 4.3.2 and 4.3.3 that payloads
containing private use Type  values MUST be ignored, not rejected in a
way that fails the negotiation.  The issue is that a PIC  client must
try to include all information in the (1) message that the responder
will accept, not  knowing the version or vendor of the responder.  If
anything in the initial message causes the  negotiation to fail (say a
rejected payload), then there is nothing staying the AS MUST reply.  Of
course we probably want to silently discard.  So I want to be sure that
AS's won't accidentally  reject extra private use payload types.

Most implementers of IKE have been pretty good about ignoring
vendor-specific attributes or  payloads.  But not all.

Also, I don't see a way to fail the client and notify him to use a
different request type.  How  would that be done ?  I assume that
VENDOR-ID payloads are allowed in (1) and (2) ?

YS: First, please note that only one CREDENTIAL-REQUEST and one CREDENTIAL
payload are allowed in a PIC exchange. We conciously avoided any negotiation
here. If you insist on negotiation, you can include a VENDOR-ID in message
(1), and have the server return a value of None for the Type field in the
CRED payload. The client can then try something else. But as you mentioned,
the server is not obligated to reply at all.

Addition #2 - Use Revised Hash

I really wish this was adopted from IKE as a lesson learned.  But also,
using the revised hash is  very practical when PIC is involved in long
exchanges, like the 12 round EAP-TLS example below.

YS: we simply didn't want to do it before it is adopted for IKE. But maybe
we shod have.

Clarification #1

So that I'm clear, please confirm the statement "Each of messages 3 and
4 MUST NOT be repeated more  than 10 times." is not violated by the
EAP-TLS example below, where message 3 is used 6 times.

YS: confirmed. 6 <= 10 :-)

Clarification #2

In section 4.5.2, it says "message (3) is always followed by message
(4)".  Should there be a  specification of when the AS can delete it's
SA ?  It may suffice to say that the PIC SA management  MUST NOT prevent
EAP MUST messages from being sent or received.  I haven't found a case
where it  does, and obviously reason prevails.

YS: I don't understand your point. Could you please explain?

Clarification #3 - add examples of EAP-MD5 and EAP-TLS if we do rev the
draft

For clarity, and thus for clear interop purposes, I would like to see
the actual EAP message  sequence for userid/password using MD5-Challenge
and an EAP-TLS using client cert authentication be  diagrammed.    I
have done this for EAP-TLS below, please feel free to use it, and
hopefully someone  will verify this.

First let me explain why EAP-TLS when we originally did EAP for legacy
authentication.  Because the  AS itself may not be able to fully
authenticate the user locally, rather the AS uses Radius to  remote the
authentication.  EAP-TLS may in fact use a legacy auth method after
Radius server  authentication.  Because I don't want to require legacy
authentication when I have a stronger method  available with a user
certificate.  Because PIC may be used by an administrator to request
credentials for others and I want to use the admin cert.  You might
think I as an end user could use  my user cert for IKE for the VPN in
the first place, but not so, as we have never formally clarified
exactly what credential MUST be used for IKE doing remote access VPN,
and what that certificate  contains.  The gateway defines what is
acceptable to it, therefore a generic credential (like my  USDOD
employee cert) may be needed to obtain a more specific credential for
VPN access.  Certainly  if I need a machine credential for IKE to
negotiate a security association for L2TP, then I should  be able to get
it with a user certificate if I have one.  And it would appear that PIC
may be used  in other more general contexts for cert retrieval, outside
of it's original purpose of credentialing  an IKE negotiation of an
IPsec tunnel.

YS: while I agree with your ideas, PIC only provides a partial solution, and
was certainly not conceived as a general credential provisioning protocol.
There is only so much you can do without negotiation of credential policy,
for example. The PIC protocol is ignorant of the actual credentials that it
transports.

As an exercise, I think this is the PIC message sequence for EAP-TLS
following RFC 2716, section 3.1  (* means encrypted, "" means I just
copied the text from the RFC):

(1)   no EAP message to avoid clear identification of client userid

YS: note that PIC does not allow an EAP payload in message (1). On the other
hand, there is an optional ID payload, which you're obviously not sending.

(2)                           <----  [EAP-Request/Identity]

(3*)  [EAP-Response/Identity (userid)] ----->

(4*)                          <----  [EAP-TLS/Start]
"this is an EAP-Request packet with EAP-Type=EAP-TLS, the Start (S) bit
set, and no data"

(5*)  [EAP-Response with EAP-Type=EAP-TLS] ----->
"the data field of that packet will encapsulate one or more TLS records
in TLS record layer format,  containing a TLS client_hello handshake
message"

(6*)                   <---- [EAP-Request]
"contains a TLS server_hello handshake message, possibly followed by TLS
certificate,  server_key_exchange, certificate_request,
server_hello_done and/or finished handshake messages,  and/or a TLS
change_cipher_spec message. If the EAP server is resuming a previously
established  session, then
it MUST include only a TLS change_cipher_spec message and a TLS finished
handshake message after the  server_hello message. The finished message
contains the EAP server's authentication response to the  peer."

(7*)  [EAP-Response] ------>
"data field of this packet will encapsulate one or more TLS records
containing a TLS  change_cipher_spec message and finished handshake
message, and possibly certificate,  certificate_verify and/or
client_key_exchange handshake messages. If the preceding server_hello
message sent by the EAP server in the preceding EAP-Request packet
indicated the resumption of a  previous session, then the peer MUST send
only the change_cipher_spec and finished handshake  messages.  The
finished message contains the peer's authentication response to the EAP
server."

(8*)                     <----- [EAP-Request]
If the peer's authentication is unsuccessful, the EAP server SHOULD
   send an EAP-Request packet with EAP-Type=EAP-TLS, encapsulating a TLS
   record containing the appropriate TLS alert message.  The EAP server
   SHOULD send a TLS alert message rather immediately terminating the
   conversation so as to allow the peer to inform the user of the cause
   of the failure and possibly allow for a restart of the conversation.

   To ensure that the peer receives the TLS alert message, the EAP
   server MUST wait for the peer to reply with an EAP-Response packet.

(9*)  [EAP-Response]  ----->
"The EAP-Response packet sent by the peer MAY encapsulate a TLS
client_hello handshake message"

(10*)                 <----- [EAP-Response] [EAP-Failure]
"or it MAY contain an EAP-Response packet with EAP-Type=EAP-TLS and no
data, in which case the  EAP-Server MUST send an EAP-Failure packet, and
terminate the conversation. It is up to the EAP  server whether to allow
restarts, and if so, how many times the conversation can be restarted.

YS: the above would necessarily terminate the PIC exchange, so it MUST
include an empty CREDENTIAL payload. Actually, we shouldn't require this
payload in the case of authentication failure. I will change the text
accordingly.

(10*)                 <----- [EAP-Request]
"in which case the EAP server MAY allow the EAP-TLS conversation to be
restarted,... An EAP Server  implementing restart capability SHOULD
impose a limit on the number of restarts, so as to protect  against
denial of service attacks.

If the peers authenticates successfully, the EAP server MUST respond
with an EAP-Request packet with  EAP-Type=EAP-TLS, which includes, in
the case of a new TLS session one or more TLS records  containing TLS
change_cipher_spec and finished handshke messages."


(11*) [EAP-Response, TLS Alert] ----->
If the EAP server authenticates unsuccessfully, the peer MAY send an
   EAP-Response packet of EAP-Type=EAP-TLS containing a TLS Alert
   message identifying the reason for the failed authentication. The
   peer MAY send a TLS alert message rather than immediately terminating
   the conversation so as to allow the EAP server to log the cause of
   the error for examination by the system administrator.

   To ensure that the EAP Server receives the TLS alert message, the
   peer MUST wait for the EAP-Server to reply before terminating the
   conversation

(12*)                  <----- [EAP-Failure]
The EAP Server MUST reply with an EAP-Failure packet
   since server authentication failure is a terminal condition

or

(11*) [EAP-Response]  ---------->
If the EAP server authenticates successfully, the peer MUST send an
   EAP-Response packet of EAP-Type=EAP-TLS, and no data.

(12*)                  <----- [EAP-Success]
 The EAP-Server then MUST respond with an EAP-Success message


Other general comments:

I was at least one at the IPSRA meeting who voiced concern about the DOS
potential of PIC,  particularly given that it is obviously intended for
Internet deployment.  I was also concerned  about NAT transparency for
clients behind NATs.  And I was concerned about the required
fragmentation when passing cert payloads.  But our beloved IKE has the
same issues.  And issues that  we have had to implement solutions to for
realistic deployment.

I think NAT traversal is the most significant real deployment blocker,
followed by fragmentation,  followed by DOS.  Getting the cert and it's
chain of course is limited to maximum UDP packet size.   But
practically, I've seen problems in various network components if packets
extend past 4  fragments, sometimes 3.  This comes from what I assume
are bugs in these components, but also  (improperly engineered ?)
network connections where a faster link dumps onto slower links, the
packet train that the fragments represent causes a fragment to be lost.
Retransmissions sometimes  work around the problem.  And port filtering
may or may not track fragments.  And the simple NAT  devices may have
more problems with fragments.  I haven't tried to size the packets in
the PIC  EAP-TLS exchange yet.

Certainly the cert payloads can be made small by putting the CA Root or
it's 1-level issuing CA as  the "CA" in section 1.1.  I don't know how
many people wanted to use public PKI providers.  From my  very pitiful
adhoc quick check on SSL server cert chains, they chain only to the
root.  But I know  many corporations using at least 3 tier PKI
hierarchies.  Maybe for VPN, they don't use these.  Or  in PIC one could
just retrieve the CERT package itself, and use other mechanisms to
distribute the  chain, like downloading it separately from an SSL
protected web page link, or installation of  client, etc.

Wm

-----Original Message-----
From: Hugo Krawczyk [mailto:hugo@xxxxxxxxxxxxxxxxx]
Sent: Tuesday, October 16, 2001 3:24 PM
To: Markus Stenberg
Cc: working group ipsra
Subject: Re: Reminder: last call for PIC in the IPSRA WG



Dear Markus,

Better later than never...

One can add to PIC some DOS protection via two extra initial messages
(this is what I said during the London ietf meeting when asked about
it). Adding these messages is quite straightorward from the point of
view of specification (the messages would carry a cookie from client to
server and one from server to client -- the last one being a stateless
cookie a la Karn) but it certainly adds performance and protocol
complexity. Having lacked explicit requirements for such measures we
settled for simplicity nd less performance penalty.

If you obtain consensus to add this stuff, then it is doable.

As for your suggestion to use base mode: this solution would be
inappropriate here. It requires a responder's state anyway and its main
advantage in the context of IKE is lost here. This advantage is that the
responder can do a (rleatively cheap) RSA sig verification before it
performs its own signature and the g^xy DH exponentiation. However, in
PIC there is no signature from the client at all, so this mechanism of
base mode does not aply here.

Thanks for the feedback.

Hugo


On 17 Sep 2001, Markus Stenberg wrote:

>
> paul.hoffman@xxxxxxxx (Paul Hoffman / VPNC) writes:
> > Hi again. Just a reminder that we are in the middle of the PIC last
> > call in the IPSRA WG. The last call ends at the end of September
> > unless significant changes are needed to the spec.
> >
> > It has been pretty quiet here, and maybe that is good.
>
> I was also on vacation (four weeks :>), which delayed somewhat this
> mail. I didn't want to start discussion while people were still in
> Finland in the VPN workshop, and I regrettably had to leave workshop's

> summary session before I could poll it locally.
>
> I still personally feel that with the discussion about s-o-IKE, and
> _especially_ the discussions regarding aggressive/main(/base) mode in
> IPsec WG, it might be bad idea to select aggressive-like approach for
> PIC.
>
> Why do we want to perform significant work on basis of a packet from a
> source which we haven't even verified exists and really wants to talk
> to us?
>
> This could be circumvented (at least) by changing the exchange from 3
> to 4 messages and styling it after base mode instead of aggressive
> mode.
>
> If someone else agrees, feel free to point it out; if it's just me,
> I'll go back to my corner :>
>
> > --Paul Hoffman, Director
> > --VPN Consortium
>
> -Markus
>
> --
> Markus Stenberg (stenberg@xxxxxxx) of SSH Communications Security
> (www.ssh.com)
>