From owner-ietf-sasl Wed Jul 12 08:01:07 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA20237 for ietf-sasl-bks; Wed, 12 Jul 2000 08:01:07 -0700 (PDT) Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA20233 for ; Wed, 12 Jul 2000 08:01:06 -0700 (PDT) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <34W5HA2N>; Wed, 12 Jul 2000 11:02:32 -0400 Message-ID: From: Robert Zuccherato To: ietf-sasl@imc.org Subject: FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01.txt Date: Wed, 12 Jul 2000 11:01:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, I just thought I would let the list know that Magnus and I have resubmitted our draft describing a public-key based SASL mechanism. We have addressed some of the specific comments that people had and attempted to provide a little bit more motivation. As was discussed on this list earlier, the main motivation of this draft is to provide authentication in environments where, for various architectural reasons, the endpoint of the TLS session is not the same as the application endpoint. However, it was mentioned to us recently that our draft also supports the situation where a user initially establishes a server-side authenticated connection, browses around, and then requests a certain URL which requires client authentication. This mechanism allows this "upgrade" in authentication without requiring a re-negotiation of the TLS session. Robert Zuccherato. > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, July 11, 2000 6:31 AM > Subject: I-D ACTION:draft-zuccherato-9798-3-sasl-01.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : ISO/IEC 9798-3 Authentication SASL Mechanism > Author(s) : R. Zuccherato, M. Nystrom > Filename : draft-zuccherato-9798-3-sasl-01.txt > Pages : 15 > Date : 10-Jul-00 > > This document defines a SASL [RFC2222] authentication mechanism based > on ISO/IEC 9798-3 [ISO3] and FIPS PUB 196 [FIPS] entity > authentication. This mechanism only provides authentication using > X.509 certificates [X509]. It has no effect on the protocol > encodings and does not provide integrity or confidentiality services. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zuccherato-9798-3-sasl-01.txt 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-zuccherato-9798-3-sasl-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zuccherato-9798-3-sasl-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 owner-ietf-sasl Wed Jul 12 10:58:02 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA00392 for ietf-sasl-bks; Wed, 12 Jul 2000 10:58:02 -0700 (PDT) Received: from mail.ca.certicom.com ([209.121.99.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA00387 for ; Wed, 12 Jul 2000 10:58:01 -0700 (PDT) Received: from smtpmail.certicom.com (domino2.certicom.com [10.0.1.25]) by mail.ca.certicom.com (8.9.3/8.9.3) with SMTP id NAA21489; Wed, 12 Jul 2000 13:54:40 -0400 (EDT) Received: by smtpmail.certicom.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 8525691A.0062371F ; Wed, 12 Jul 2000 13:52:46 -0400 X-Lotus-FromDomain: CERTICOM From: "John Kennedy" To: Robert Zuccherato cc: ietf-sasl@imc.org, ietf-tls@lists.consensus.com Message-ID: <8525691A.0062356C.00@smtpmail.certicom.com> Date: Wed, 12 Jul 2000 10:52:09 -0700 Subject: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01 .txt] Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, Another advantage of this scheme (and SASL, in general) is that the client authentication mechanism need not have any relationship to the cipher suite used in the TLS protocol. For example, after an RSA-based, server-authenticated TLS session is established, the ECDSA version of this SASL mechanism could be used by a client to authenticate to the server. In this way, existing server side TLS and RSA-based PKI components can be retained while still permitting strong authentication from clients for which ECDSA signing is a more computationally-friendly authentication operation. The ability to accomodate such "hybrid" client-server authentication schemes without throwing out existing server-authentication infrastructure (e.g.,code/certs) has a number of obvious practical advantages. On the other hand, the disadvantage of hybrid TLS+SASL approaches is that the server's TLS layer alone is not able to provide on-going binding of client identity to the server simply because it was not involved in client authentication and the client's credentials are not incorporated into the TLS authenticated key exchange. Care must be taken on both sides of the link to insure that relying party access control and other policy enforcement mechanisms can "see" and correctly characterize channel security characteristics that are implemented at different layers in the stack. Hybrid, "cross-layer" schemes may be practical, but can also be a double-edged sword. This, of course, is only a warning to implementors, not a criticism of the protocols themselves. Regards, -John Kennedy Robert Zuccherato on 07/12/2000 08:01:18 AM To: ietf-sasl@imc.org cc: (bcc: John Kennedy/Certicom) Subject: FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01.txt Hi, I just thought I would let the list know that Magnus and I have resubmitted our draft describing a public-key based SASL mechanism. We have addressed some of the specific comments that people had and attempted to provide a little bit more motivation. As was discussed on this list earlier, the main motivation of this draft is to provide authentication in environments where, for various architectural reasons, the endpoint of the TLS session is not the same as the application endpoint. However, it was mentioned to us recently that our draft also supports the situation where a user initially establishes a server-side authenticated connection, browses around, and then requests a certain URL which requires client authentication. This mechanism allows this "upgrade" in authentication without requiring a re-negotiation of the TLS session. Robert Zuccherato. From owner-ietf-sasl Wed Jul 12 19:48:07 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA19516 for ietf-sasl-bks; Wed, 12 Jul 2000 19:48:07 -0700 (PDT) Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA19512 for ; Wed, 12 Jul 2000 19:48:04 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id <3X7A01YC>; Thu, 13 Jul 2000 12:49:29 +1000 Message-ID: <11981F9F5649D411BC92009027D0D18C57689F@aspams01.cai.com> From: "Ramsay, Ron" To: John Kennedy , Robert Zuccherato Cc: ietf-sasl@imc.org, ietf-tls@lists.consensus.com Subject: RE: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-0 1 .txt] Date: Thu, 13 Jul 2000 12:49:30 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If the TLS endpoint is the server, I don't see what you mean about TLS not being able to "provide on-going binding of client identity"? TLS itself should be capable of preventing attacks on the communication. In the case where the TLS enpoint is not the server, surely a man-in-the-middle attack is feasible? Ron. -----Original Message----- From: John Kennedy [mailto:jkennedy@certicom.com] Sent: Thursday, 13 July 2000 3:52 To: Robert Zuccherato Cc: ietf-sasl@imc.org; ietf-tls@lists.consensus.com Subject: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01 .txt] Hi, Another advantage of this scheme (and SASL, in general) is that the client authentication mechanism need not have any relationship to the cipher suite used in the TLS protocol. For example, after an RSA-based, server-authenticated TLS session is established, the ECDSA version of this SASL mechanism could be used by a client to authenticate to the server. In this way, existing server side TLS and RSA-based PKI components can be retained while still permitting strong authentication from clients for which ECDSA signing is a more computationally-friendly authentication operation. The ability to accomodate such "hybrid" client-server authentication schemes without throwing out existing server-authentication infrastructure (e.g.,code/certs) has a number of obvious practical advantages. On the other hand, the disadvantage of hybrid TLS+SASL approaches is that the server's TLS layer alone is not able to provide on-going binding of client identity to the server simply because it was not involved in client authentication and the client's credentials are not incorporated into the TLS authenticated key exchange. Care must be taken on both sides of the link to insure that relying party access control and other policy enforcement mechanisms can "see" and correctly characterize channel security characteristics that are implemented at different layers in the stack. Hybrid, "cross-layer" schemes may be practical, but can also be a double-edged sword. This, of course, is only a warning to implementors, not a criticism of the protocols themselves. Regards, -John Kennedy Robert Zuccherato on 07/12/2000 08:01:18 AM To: ietf-sasl@imc.org cc: (bcc: John Kennedy/Certicom) Subject: FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01.txt Hi, I just thought I would let the list know that Magnus and I have resubmitted our draft describing a public-key based SASL mechanism. We have addressed some of the specific comments that people had and attempted to provide a little bit more motivation. As was discussed on this list earlier, the main motivation of this draft is to provide authentication in environments where, for various architectural reasons, the endpoint of the TLS session is not the same as the application endpoint. However, it was mentioned to us recently that our draft also supports the situation where a user initially establishes a server-side authenticated connection, browses around, and then requests a certain URL which requires client authentication. This mechanism allows this "upgrade" in authentication without requiring a re-negotiation of the TLS session. Robert Zuccherato. From owner-ietf-sasl Thu Jul 13 10:52:59 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA05230 for ietf-sasl-bks; Thu, 13 Jul 2000 10:52:59 -0700 (PDT) Received: from mail.ca.certicom.com ([209.121.99.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05224 for ; Thu, 13 Jul 2000 10:52:55 -0700 (PDT) Received: from smtpmail.certicom.com (domino2.certicom.com [10.0.1.25]) by mail.ca.certicom.com (8.9.3/8.9.3) with SMTP id NAA02621; Thu, 13 Jul 2000 13:48:31 -0400 (EDT) Received: by smtpmail.certicom.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 8525691B.0061AC08 ; Thu, 13 Jul 2000 13:46:50 -0400 X-Lotus-FromDomain: CERTICOM From: "John Kennedy" To: "Ramsay, Ron" cc: ietf-sasl@imc.org Message-ID: <8525691B.0061AACF.00@smtpmail.certicom.com> Date: Thu, 13 Jul 2000 10:48:31 -0700 Subject: RE: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-0 1 .txt] Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If client authentication is not part of the TLS protocol then all the TLS layer *by itself* provides is an encrypted channel to an unauthenticated client. What you have is a unilaterally authenticated key exchange. The SASL client authentication has value but it does not get bound into the TLS session in a cryptographic (or any other) sense. Message authentication on packets from the client is not included in the TLS session. TLS may be protecting you against snooping, but in this instance it is not providing any data source authentication services to the server. When you start stitching together cryptographic protocol services in a piecemeal fashion the ability to inspect and prove the correctness of the system and the properties of the "composed" secure channel becomes more difficult. Instead of looking at the TLS implementation or the SASL implementation independently, we must now look at how they are combined within the endpoints. It can be done (in fact it is done all the time), I'm just pointing out that it has the inherent *potential* of being less secure if implemented poorly or if the security properties incorrectly assessed. As for the MITM attack question, it is certainly a possibility anytime security services are not "end-to-end". YMMV. -John "Ramsay, Ron" on 07/12/2000 07:49:30 PM To: John Kennedy/Certicom@Certicom, Robert Zuccherato cc: ietf-sasl@imc.org, ietf-tls@lists.consensus.com Subject: RE: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-0 1 .txt] If the TLS endpoint is the server, I don't see what you mean about TLS not being able to "provide on-going binding of client identity"? TLS itself should be capable of preventing attacks on the communication. In the case where the TLS enpoint is not the server, surely a man-in-the-middle attack is feasible? Ron. -----Original Message----- From: John Kennedy [mailto:jkennedy@certicom.com] Sent: Thursday, 13 July 2000 3:52 To: Robert Zuccherato Cc: ietf-sasl@imc.org; ietf-tls@lists.consensus.com Subject: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01 .txt] Hi, Another advantage of this scheme (and SASL, in general) is that the client authentication mechanism need not have any relationship to the cipher suite used in the TLS protocol. For example, after an RSA-based, server-authenticated TLS session is established, the ECDSA version of this SASL mechanism could be used by a client to authenticate to the server. In this way, existing server side TLS and RSA-based PKI components can be retained while still permitting strong authentication from clients for which ECDSA signing is a more computationally-friendly authentication operation. The ability to accomodate such "hybrid" client-server authentication schemes without throwing out existing server-authentication infrastructure (e.g.,code/certs) has a number of obvious practical advantages. On the other hand, the disadvantage of hybrid TLS+SASL approaches is that the server's TLS layer alone is not able to provide on-going binding of client identity to the server simply because it was not involved in client authentication and the client's credentials are not incorporated into the TLS authenticated key exchange. Care must be taken on both sides of the link to insure that relying party access control and other policy enforcement mechanisms can "see" and correctly characterize channel security characteristics that are implemented at different layers in the stack. Hybrid, "cross-layer" schemes may be practical, but can also be a double-edged sword. This, of course, is only a warning to implementors, not a criticism of the protocols themselves. Regards, -John Kennedy Robert Zuccherato on 07/12/2000 08:01:18 AM To: ietf-sasl@imc.org cc: (bcc: John Kennedy/Certicom) Subject: FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01.txt Hi, I just thought I would let the list know that Magnus and I have resubmitted our draft describing a public-key based SASL mechanism. We have addressed some of the specific comments that people had and attempted to provide a little bit more motivation. As was discussed on this list earlier, the main motivation of this draft is to provide authentication in environments where, for various architectural reasons, the endpoint of the TLS session is not the same as the application endpoint. However, it was mentioned to us recently that our draft also supports the situation where a user initially establishes a server-side authenticated connection, browses around, and then requests a certain URL which requires client authentication. This mechanism allows this "upgrade" in authentication without requiring a re-negotiation of the TLS session. Robert Zuccherato. From owner-ietf-sasl Thu Jul 13 19:39:51 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA24413 for ietf-sasl-bks; Thu, 13 Jul 2000 19:39:51 -0700 (PDT) Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA24408 for ; Thu, 13 Jul 2000 19:39:48 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id <3X7A0KB6>; Fri, 14 Jul 2000 12:41:24 +1000 Message-ID: <11981F9F5649D411BC92009027D0D18C5B74B0@aspams01.cai.com> From: "Ramsay, Ron" To: John Kennedy Cc: ietf-sasl@imc.org Subject: RE: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-0 1 .txt] Date: Fri, 14 Jul 2000 12:41:24 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Accepted, thanks. Ron. -----Original Message----- From: John Kennedy [mailto:jkennedy@certicom.com] Sent: Friday, 14 July 2000 3:49 To: Ramsay, Ron Cc: ietf-sasl@imc.org Subject: RE: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-0 1 .txt] If client authentication is not part of the TLS protocol then all the TLS layer *by itself* provides is an encrypted channel to an unauthenticated client. What you have is a unilaterally authenticated key exchange. The SASL client authentication has value but it does not get bound into the TLS session in a cryptographic (or any other) sense. Message authentication on packets from the client is not included in the TLS session. TLS may be protecting you against snooping, but in this instance it is not providing any data source authentication services to the server. When you start stitching together cryptographic protocol services in a piecemeal fashion the ability to inspect and prove the correctness of the system and the properties of the "composed" secure channel becomes more difficult. Instead of looking at the TLS implementation or the SASL implementation independently, we must now look at how they are combined within the endpoints. It can be done (in fact it is done all the time), I'm just pointing out that it has the inherent *potential* of being less secure if implemented poorly or if the security properties incorrectly assessed. As for the MITM attack question, it is certainly a possibility anytime security services are not "end-to-end". YMMV. -John "Ramsay, Ron" on 07/12/2000 07:49:30 PM To: John Kennedy/Certicom@Certicom, Robert Zuccherato cc: ietf-sasl@imc.org, ietf-tls@lists.consensus.com Subject: RE: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-0 1 .txt] If the TLS endpoint is the server, I don't see what you mean about TLS not being able to "provide on-going binding of client identity"? TLS itself should be capable of preventing attacks on the communication. In the case where the TLS enpoint is not the server, surely a man-in-the-middle attack is feasible? Ron. -----Original Message----- From: John Kennedy [mailto:jkennedy@certicom.com] Sent: Thursday, 13 July 2000 3:52 To: Robert Zuccherato Cc: ietf-sasl@imc.org; ietf-tls@lists.consensus.com Subject: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01 .txt] Hi, Another advantage of this scheme (and SASL, in general) is that the client authentication mechanism need not have any relationship to the cipher suite used in the TLS protocol. For example, after an RSA-based, server-authenticated TLS session is established, the ECDSA version of this SASL mechanism could be used by a client to authenticate to the server. In this way, existing server side TLS and RSA-based PKI components can be retained while still permitting strong authentication from clients for which ECDSA signing is a more computationally-friendly authentication operation. The ability to accomodate such "hybrid" client-server authentication schemes without throwing out existing server-authentication infrastructure (e.g.,code/certs) has a number of obvious practical advantages. On the other hand, the disadvantage of hybrid TLS+SASL approaches is that the server's TLS layer alone is not able to provide on-going binding of client identity to the server simply because it was not involved in client authentication and the client's credentials are not incorporated into the TLS authenticated key exchange. Care must be taken on both sides of the link to insure that relying party access control and other policy enforcement mechanisms can "see" and correctly characterize channel security characteristics that are implemented at different layers in the stack. Hybrid, "cross-layer" schemes may be practical, but can also be a double-edged sword. This, of course, is only a warning to implementors, not a criticism of the protocols themselves. Regards, -John Kennedy Robert Zuccherato on 07/12/2000 08:01:18 AM To: ietf-sasl@imc.org cc: (bcc: John Kennedy/Certicom) Subject: FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01.txt Hi, I just thought I would let the list know that Magnus and I have resubmitted our draft describing a public-key based SASL mechanism. We have addressed some of the specific comments that people had and attempted to provide a little bit more motivation. As was discussed on this list earlier, the main motivation of this draft is to provide authentication in environments where, for various architectural reasons, the endpoint of the TLS session is not the same as the application endpoint. However, it was mentioned to us recently that our draft also supports the situation where a user initially establishes a server-side authenticated connection, browses around, and then requests a certain URL which requires client authentication. This mechanism allows this "upgrade" in authentication without requiring a re-negotiation of the TLS session. Robert Zuccherato. From owner-ietf-sasl Wed Jul 12 08:01:07 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA20237 for ietf-sasl-bks; Wed, 12 Jul 2000 08:01:07 -0700 (PDT) Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA20233 for ; Wed, 12 Jul 2000 08:01:06 -0700 (PDT) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <34W5HA2N>; Wed, 12 Jul 2000 11:02:32 -0400 Message-ID: From: Robert Zuccherato To: ietf-sasl@imc.org Subject: FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01.txt Date: Wed, 12 Jul 2000 11:01:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, I just thought I would let the list know that Magnus and I have resubmitted our draft describing a public-key based SASL mechanism. We have addressed some of the specific comments that people had and attempted to provide a little bit more motivation. As was discussed on this list earlier, the main motivation of this draft is to provide authentication in environments where, for various architectural reasons, the endpoint of the TLS session is not the same as the application endpoint. However, it was mentioned to us recently that our draft also supports the situation where a user initially establishes a server-side authenticated connection, browses around, and then requests a certain URL which requires client authentication. This mechanism allows this "upgrade" in authentication without requiring a re-negotiation of the TLS session. Robert Zuccherato. > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, July 11, 2000 6:31 AM > Subject: I-D ACTION:draft-zuccherato-9798-3-sasl-01.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : ISO/IEC 9798-3 Authentication SASL Mechanism > Author(s) : R. Zuccherato, M. Nystrom > Filename : draft-zuccherato-9798-3-sasl-01.txt > Pages : 15 > Date : 10-Jul-00 > > This document defines a SASL [RFC2222] authentication mechanism based > on ISO/IEC 9798-3 [ISO3] and FIPS PUB 196 [FIPS] entity > authentication. This mechanism only provides authentication using > X.509 certificates [X509]. It has no effect on the protocol > encodings and does not provide integrity or confidentiality services. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zuccherato-9798-3-sasl-01.txt 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-zuccherato-9798-3-sasl-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zuccherato-9798-3-sasl-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 owner-ietf-sasl Wed Jul 12 10:58:02 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA00392 for ietf-sasl-bks; Wed, 12 Jul 2000 10:58:02 -0700 (PDT) Received: from mail.ca.certicom.com ([209.121.99.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA00387 for ; Wed, 12 Jul 2000 10:58:01 -0700 (PDT) Received: from smtpmail.certicom.com (domino2.certicom.com [10.0.1.25]) by mail.ca.certicom.com (8.9.3/8.9.3) with SMTP id NAA21489; Wed, 12 Jul 2000 13:54:40 -0400 (EDT) Received: by smtpmail.certicom.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 8525691A.0062371F ; Wed, 12 Jul 2000 13:52:46 -0400 X-Lotus-FromDomain: CERTICOM From: "John Kennedy" To: Robert Zuccherato cc: ietf-sasl@imc.org, ietf-tls@lists.consensus.com Message-ID: <8525691A.0062356C.00@smtpmail.certicom.com> Date: Wed, 12 Jul 2000 10:52:09 -0700 Subject: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01 .txt] Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, Another advantage of this scheme (and SASL, in general) is that the client authentication mechanism need not have any relationship to the cipher suite used in the TLS protocol. For example, after an RSA-based, server-authenticated TLS session is established, the ECDSA version of this SASL mechanism could be used by a client to authenticate to the server. In this way, existing server side TLS and RSA-based PKI components can be retained while still permitting strong authentication from clients for which ECDSA signing is a more computationally-friendly authentication operation. The ability to accomodate such "hybrid" client-server authentication schemes without throwing out existing server-authentication infrastructure (e.g.,code/certs) has a number of obvious practical advantages. On the other hand, the disadvantage of hybrid TLS+SASL approaches is that the server's TLS layer alone is not able to provide on-going binding of client identity to the server simply because it was not involved in client authentication and the client's credentials are not incorporated into the TLS authenticated key exchange. Care must be taken on both sides of the link to insure that relying party access control and other policy enforcement mechanisms can "see" and correctly characterize channel security characteristics that are implemented at different layers in the stack. Hybrid, "cross-layer" schemes may be practical, but can also be a double-edged sword. This, of course, is only a warning to implementors, not a criticism of the protocols themselves. Regards, -John Kennedy Robert Zuccherato on 07/12/2000 08:01:18 AM To: ietf-sasl@imc.org cc: (bcc: John Kennedy/Certicom) Subject: FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01.txt Hi, I just thought I would let the list know that Magnus and I have resubmitted our draft describing a public-key based SASL mechanism. We have addressed some of the specific comments that people had and attempted to provide a little bit more motivation. As was discussed on this list earlier, the main motivation of this draft is to provide authentication in environments where, for various architectural reasons, the endpoint of the TLS session is not the same as the application endpoint. However, it was mentioned to us recently that our draft also supports the situation where a user initially establishes a server-side authenticated connection, browses around, and then requests a certain URL which requires client authentication. This mechanism allows this "upgrade" in authentication without requiring a re-negotiation of the TLS session. Robert Zuccherato. From owner-ietf-sasl Wed Jul 12 19:48:07 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA19516 for ietf-sasl-bks; Wed, 12 Jul 2000 19:48:07 -0700 (PDT) Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA19512 for ; Wed, 12 Jul 2000 19:48:04 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id <3X7A01YC>; Thu, 13 Jul 2000 12:49:29 +1000 Message-ID: <11981F9F5649D411BC92009027D0D18C57689F@aspams01.cai.com> From: "Ramsay, Ron" To: John Kennedy , Robert Zuccherato Cc: ietf-sasl@imc.org, ietf-tls@lists.consensus.com Subject: RE: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-0 1 .txt] Date: Thu, 13 Jul 2000 12:49:30 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If the TLS endpoint is the server, I don't see what you mean about TLS not being able to "provide on-going binding of client identity"? TLS itself should be capable of preventing attacks on the communication. In the case where the TLS enpoint is not the server, surely a man-in-the-middle attack is feasible? Ron. -----Original Message----- From: John Kennedy [mailto:jkennedy@certicom.com] Sent: Thursday, 13 July 2000 3:52 To: Robert Zuccherato Cc: ietf-sasl@imc.org; ietf-tls@lists.consensus.com Subject: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01 .txt] Hi, Another advantage of this scheme (and SASL, in general) is that the client authentication mechanism need not have any relationship to the cipher suite used in the TLS protocol. For example, after an RSA-based, server-authenticated TLS session is established, the ECDSA version of this SASL mechanism could be used by a client to authenticate to the server. In this way, existing server side TLS and RSA-based PKI components can be retained while still permitting strong authentication from clients for which ECDSA signing is a more computationally-friendly authentication operation. The ability to accomodate such "hybrid" client-server authentication schemes without throwing out existing server-authentication infrastructure (e.g.,code/certs) has a number of obvious practical advantages. On the other hand, the disadvantage of hybrid TLS+SASL approaches is that the server's TLS layer alone is not able to provide on-going binding of client identity to the server simply because it was not involved in client authentication and the client's credentials are not incorporated into the TLS authenticated key exchange. Care must be taken on both sides of the link to insure that relying party access control and other policy enforcement mechanisms can "see" and correctly characterize channel security characteristics that are implemented at different layers in the stack. Hybrid, "cross-layer" schemes may be practical, but can also be a double-edged sword. This, of course, is only a warning to implementors, not a criticism of the protocols themselves. Regards, -John Kennedy Robert Zuccherato on 07/12/2000 08:01:18 AM To: ietf-sasl@imc.org cc: (bcc: John Kennedy/Certicom) Subject: FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01.txt Hi, I just thought I would let the list know that Magnus and I have resubmitted our draft describing a public-key based SASL mechanism. We have addressed some of the specific comments that people had and attempted to provide a little bit more motivation. As was discussed on this list earlier, the main motivation of this draft is to provide authentication in environments where, for various architectural reasons, the endpoint of the TLS session is not the same as the application endpoint. However, it was mentioned to us recently that our draft also supports the situation where a user initially establishes a server-side authenticated connection, browses around, and then requests a certain URL which requires client authentication. This mechanism allows this "upgrade" in authentication without requiring a re-negotiation of the TLS session. Robert Zuccherato. From owner-ietf-sasl Thu Jul 13 10:52:59 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA05230 for ietf-sasl-bks; Thu, 13 Jul 2000 10:52:59 -0700 (PDT) Received: from mail.ca.certicom.com ([209.121.99.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05224 for ; Thu, 13 Jul 2000 10:52:55 -0700 (PDT) Received: from smtpmail.certicom.com (domino2.certicom.com [10.0.1.25]) by mail.ca.certicom.com (8.9.3/8.9.3) with SMTP id NAA02621; Thu, 13 Jul 2000 13:48:31 -0400 (EDT) Received: by smtpmail.certicom.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 8525691B.0061AC08 ; Thu, 13 Jul 2000 13:46:50 -0400 X-Lotus-FromDomain: CERTICOM From: "John Kennedy" To: "Ramsay, Ron" cc: ietf-sasl@imc.org Message-ID: <8525691B.0061AACF.00@smtpmail.certicom.com> Date: Thu, 13 Jul 2000 10:48:31 -0700 Subject: RE: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-0 1 .txt] Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If client authentication is not part of the TLS protocol then all the TLS layer *by itself* provides is an encrypted channel to an unauthenticated client. What you have is a unilaterally authenticated key exchange. The SASL client authentication has value but it does not get bound into the TLS session in a cryptographic (or any other) sense. Message authentication on packets from the client is not included in the TLS session. TLS may be protecting you against snooping, but in this instance it is not providing any data source authentication services to the server. When you start stitching together cryptographic protocol services in a piecemeal fashion the ability to inspect and prove the correctness of the system and the properties of the "composed" secure channel becomes more difficult. Instead of looking at the TLS implementation or the SASL implementation independently, we must now look at how they are combined within the endpoints. It can be done (in fact it is done all the time), I'm just pointing out that it has the inherent *potential* of being less secure if implemented poorly or if the security properties incorrectly assessed. As for the MITM attack question, it is certainly a possibility anytime security services are not "end-to-end". YMMV. -John "Ramsay, Ron" on 07/12/2000 07:49:30 PM To: John Kennedy/Certicom@Certicom, Robert Zuccherato cc: ietf-sasl@imc.org, ietf-tls@lists.consensus.com Subject: RE: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-0 1 .txt] If the TLS endpoint is the server, I don't see what you mean about TLS not being able to "provide on-going binding of client identity"? TLS itself should be capable of preventing attacks on the communication. In the case where the TLS enpoint is not the server, surely a man-in-the-middle attack is feasible? Ron. -----Original Message----- From: John Kennedy [mailto:jkennedy@certicom.com] Sent: Thursday, 13 July 2000 3:52 To: Robert Zuccherato Cc: ietf-sasl@imc.org; ietf-tls@lists.consensus.com Subject: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01 .txt] Hi, Another advantage of this scheme (and SASL, in general) is that the client authentication mechanism need not have any relationship to the cipher suite used in the TLS protocol. For example, after an RSA-based, server-authenticated TLS session is established, the ECDSA version of this SASL mechanism could be used by a client to authenticate to the server. In this way, existing server side TLS and RSA-based PKI components can be retained while still permitting strong authentication from clients for which ECDSA signing is a more computationally-friendly authentication operation. The ability to accomodate such "hybrid" client-server authentication schemes without throwing out existing server-authentication infrastructure (e.g.,code/certs) has a number of obvious practical advantages. On the other hand, the disadvantage of hybrid TLS+SASL approaches is that the server's TLS layer alone is not able to provide on-going binding of client identity to the server simply because it was not involved in client authentication and the client's credentials are not incorporated into the TLS authenticated key exchange. Care must be taken on both sides of the link to insure that relying party access control and other policy enforcement mechanisms can "see" and correctly characterize channel security characteristics that are implemented at different layers in the stack. Hybrid, "cross-layer" schemes may be practical, but can also be a double-edged sword. This, of course, is only a warning to implementors, not a criticism of the protocols themselves. Regards, -John Kennedy Robert Zuccherato on 07/12/2000 08:01:18 AM To: ietf-sasl@imc.org cc: (bcc: John Kennedy/Certicom) Subject: FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01.txt Hi, I just thought I would let the list know that Magnus and I have resubmitted our draft describing a public-key based SASL mechanism. We have addressed some of the specific comments that people had and attempted to provide a little bit more motivation. As was discussed on this list earlier, the main motivation of this draft is to provide authentication in environments where, for various architectural reasons, the endpoint of the TLS session is not the same as the application endpoint. However, it was mentioned to us recently that our draft also supports the situation where a user initially establishes a server-side authenticated connection, browses around, and then requests a certain URL which requires client authentication. This mechanism allows this "upgrade" in authentication without requiring a re-negotiation of the TLS session. Robert Zuccherato. From owner-ietf-sasl Thu Jul 13 19:39:51 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA24413 for ietf-sasl-bks; Thu, 13 Jul 2000 19:39:51 -0700 (PDT) Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA24408 for ; Thu, 13 Jul 2000 19:39:48 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id <3X7A0KB6>; Fri, 14 Jul 2000 12:41:24 +1000 Message-ID: <11981F9F5649D411BC92009027D0D18C5B74B0@aspams01.cai.com> From: "Ramsay, Ron" To: John Kennedy Cc: ietf-sasl@imc.org Subject: RE: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-0 1 .txt] Date: Fri, 14 Jul 2000 12:41:24 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Accepted, thanks. Ron. -----Original Message----- From: John Kennedy [mailto:jkennedy@certicom.com] Sent: Friday, 14 July 2000 3:49 To: Ramsay, Ron Cc: ietf-sasl@imc.org Subject: RE: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-0 1 .txt] If client authentication is not part of the TLS protocol then all the TLS layer *by itself* provides is an encrypted channel to an unauthenticated client. What you have is a unilaterally authenticated key exchange. The SASL client authentication has value but it does not get bound into the TLS session in a cryptographic (or any other) sense. Message authentication on packets from the client is not included in the TLS session. TLS may be protecting you against snooping, but in this instance it is not providing any data source authentication services to the server. When you start stitching together cryptographic protocol services in a piecemeal fashion the ability to inspect and prove the correctness of the system and the properties of the "composed" secure channel becomes more difficult. Instead of looking at the TLS implementation or the SASL implementation independently, we must now look at how they are combined within the endpoints. It can be done (in fact it is done all the time), I'm just pointing out that it has the inherent *potential* of being less secure if implemented poorly or if the security properties incorrectly assessed. As for the MITM attack question, it is certainly a possibility anytime security services are not "end-to-end". YMMV. -John "Ramsay, Ron" on 07/12/2000 07:49:30 PM To: John Kennedy/Certicom@Certicom, Robert Zuccherato cc: ietf-sasl@imc.org, ietf-tls@lists.consensus.com Subject: RE: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-0 1 .txt] If the TLS endpoint is the server, I don't see what you mean about TLS not being able to "provide on-going binding of client identity"? TLS itself should be capable of preventing attacks on the communication. In the case where the TLS enpoint is not the server, surely a man-in-the-middle attack is feasible? Ron. -----Original Message----- From: John Kennedy [mailto:jkennedy@certicom.com] Sent: Thursday, 13 July 2000 3:52 To: Robert Zuccherato Cc: ietf-sasl@imc.org; ietf-tls@lists.consensus.com Subject: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01 .txt] Hi, Another advantage of this scheme (and SASL, in general) is that the client authentication mechanism need not have any relationship to the cipher suite used in the TLS protocol. For example, after an RSA-based, server-authenticated TLS session is established, the ECDSA version of this SASL mechanism could be used by a client to authenticate to the server. In this way, existing server side TLS and RSA-based PKI components can be retained while still permitting strong authentication from clients for which ECDSA signing is a more computationally-friendly authentication operation. The ability to accomodate such "hybrid" client-server authentication schemes without throwing out existing server-authentication infrastructure (e.g.,code/certs) has a number of obvious practical advantages. On the other hand, the disadvantage of hybrid TLS+SASL approaches is that the server's TLS layer alone is not able to provide on-going binding of client identity to the server simply because it was not involved in client authentication and the client's credentials are not incorporated into the TLS authenticated key exchange. Care must be taken on both sides of the link to insure that relying party access control and other policy enforcement mechanisms can "see" and correctly characterize channel security characteristics that are implemented at different layers in the stack. Hybrid, "cross-layer" schemes may be practical, but can also be a double-edged sword. This, of course, is only a warning to implementors, not a criticism of the protocols themselves. Regards, -John Kennedy Robert Zuccherato on 07/12/2000 08:01:18 AM To: ietf-sasl@imc.org cc: (bcc: John Kennedy/Certicom) Subject: FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01.txt Hi, I just thought I would let the list know that Magnus and I have resubmitted our draft describing a public-key based SASL mechanism. We have addressed some of the specific comments that people had and attempted to provide a little bit more motivation. As was discussed on this list earlier, the main motivation of this draft is to provide authentication in environments where, for various architectural reasons, the endpoint of the TLS session is not the same as the application endpoint. However, it was mentioned to us recently that our draft also supports the situation where a user initially establishes a server-side authenticated connection, browses around, and then requests a certain URL which requires client authentication. This mechanism allows this "upgrade" in authentication without requiring a re-negotiation of the TLS session. Robert Zuccherato. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA24413 for ietf-sasl-bks; Thu, 13 Jul 2000 19:39:51 -0700 (PDT) Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA24408 for ; Thu, 13 Jul 2000 19:39:48 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id <3X7A0KB6>; Fri, 14 Jul 2000 12:41:24 +1000 Message-ID: <11981F9F5649D411BC92009027D0D18C5B74B0@aspams01.cai.com> From: "Ramsay, Ron" To: John Kennedy Cc: ietf-sasl@imc.org Subject: RE: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-0 1 .txt] Date: Fri, 14 Jul 2000 12:41:24 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Accepted, thanks. Ron. -----Original Message----- From: John Kennedy [mailto:jkennedy@certicom.com] Sent: Friday, 14 July 2000 3:49 To: Ramsay, Ron Cc: ietf-sasl@imc.org Subject: RE: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-0 1 .txt] If client authentication is not part of the TLS protocol then all the TLS layer *by itself* provides is an encrypted channel to an unauthenticated client. What you have is a unilaterally authenticated key exchange. The SASL client authentication has value but it does not get bound into the TLS session in a cryptographic (or any other) sense. Message authentication on packets from the client is not included in the TLS session. TLS may be protecting you against snooping, but in this instance it is not providing any data source authentication services to the server. When you start stitching together cryptographic protocol services in a piecemeal fashion the ability to inspect and prove the correctness of the system and the properties of the "composed" secure channel becomes more difficult. Instead of looking at the TLS implementation or the SASL implementation independently, we must now look at how they are combined within the endpoints. It can be done (in fact it is done all the time), I'm just pointing out that it has the inherent *potential* of being less secure if implemented poorly or if the security properties incorrectly assessed. As for the MITM attack question, it is certainly a possibility anytime security services are not "end-to-end". YMMV. -John "Ramsay, Ron" on 07/12/2000 07:49:30 PM To: John Kennedy/Certicom@Certicom, Robert Zuccherato cc: ietf-sasl@imc.org, ietf-tls@lists.consensus.com Subject: RE: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-0 1 .txt] If the TLS endpoint is the server, I don't see what you mean about TLS not being able to "provide on-going binding of client identity"? TLS itself should be capable of preventing attacks on the communication. In the case where the TLS enpoint is not the server, surely a man-in-the-middle attack is feasible? Ron. -----Original Message----- From: John Kennedy [mailto:jkennedy@certicom.com] Sent: Thursday, 13 July 2000 3:52 To: Robert Zuccherato Cc: ietf-sasl@imc.org; ietf-tls@lists.consensus.com Subject: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01 .txt] Hi, Another advantage of this scheme (and SASL, in general) is that the client authentication mechanism need not have any relationship to the cipher suite used in the TLS protocol. For example, after an RSA-based, server-authenticated TLS session is established, the ECDSA version of this SASL mechanism could be used by a client to authenticate to the server. In this way, existing server side TLS and RSA-based PKI components can be retained while still permitting strong authentication from clients for which ECDSA signing is a more computationally-friendly authentication operation. The ability to accomodate such "hybrid" client-server authentication schemes without throwing out existing server-authentication infrastructure (e.g.,code/certs) has a number of obvious practical advantages. On the other hand, the disadvantage of hybrid TLS+SASL approaches is that the server's TLS layer alone is not able to provide on-going binding of client identity to the server simply because it was not involved in client authentication and the client's credentials are not incorporated into the TLS authenticated key exchange. Care must be taken on both sides of the link to insure that relying party access control and other policy enforcement mechanisms can "see" and correctly characterize channel security characteristics that are implemented at different layers in the stack. Hybrid, "cross-layer" schemes may be practical, but can also be a double-edged sword. This, of course, is only a warning to implementors, not a criticism of the protocols themselves. Regards, -John Kennedy Robert Zuccherato on 07/12/2000 08:01:18 AM To: ietf-sasl@imc.org cc: (bcc: John Kennedy/Certicom) Subject: FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01.txt Hi, I just thought I would let the list know that Magnus and I have resubmitted our draft describing a public-key based SASL mechanism. We have addressed some of the specific comments that people had and attempted to provide a little bit more motivation. As was discussed on this list earlier, the main motivation of this draft is to provide authentication in environments where, for various architectural reasons, the endpoint of the TLS session is not the same as the application endpoint. However, it was mentioned to us recently that our draft also supports the situation where a user initially establishes a server-side authenticated connection, browses around, and then requests a certain URL which requires client authentication. This mechanism allows this "upgrade" in authentication without requiring a re-negotiation of the TLS session. Robert Zuccherato. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA05230 for ietf-sasl-bks; Thu, 13 Jul 2000 10:52:59 -0700 (PDT) Received: from mail.ca.certicom.com ([209.121.99.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05224 for ; Thu, 13 Jul 2000 10:52:55 -0700 (PDT) Received: from smtpmail.certicom.com (domino2.certicom.com [10.0.1.25]) by mail.ca.certicom.com (8.9.3/8.9.3) with SMTP id NAA02621; Thu, 13 Jul 2000 13:48:31 -0400 (EDT) Received: by smtpmail.certicom.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 8525691B.0061AC08 ; Thu, 13 Jul 2000 13:46:50 -0400 X-Lotus-FromDomain: CERTICOM From: "John Kennedy" To: "Ramsay, Ron" cc: ietf-sasl@imc.org Message-ID: <8525691B.0061AACF.00@smtpmail.certicom.com> Date: Thu, 13 Jul 2000 10:48:31 -0700 Subject: RE: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-0 1 .txt] Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If client authentication is not part of the TLS protocol then all the TLS layer *by itself* provides is an encrypted channel to an unauthenticated client. What you have is a unilaterally authenticated key exchange. The SASL client authentication has value but it does not get bound into the TLS session in a cryptographic (or any other) sense. Message authentication on packets from the client is not included in the TLS session. TLS may be protecting you against snooping, but in this instance it is not providing any data source authentication services to the server. When you start stitching together cryptographic protocol services in a piecemeal fashion the ability to inspect and prove the correctness of the system and the properties of the "composed" secure channel becomes more difficult. Instead of looking at the TLS implementation or the SASL implementation independently, we must now look at how they are combined within the endpoints. It can be done (in fact it is done all the time), I'm just pointing out that it has the inherent *potential* of being less secure if implemented poorly or if the security properties incorrectly assessed. As for the MITM attack question, it is certainly a possibility anytime security services are not "end-to-end". YMMV. -John "Ramsay, Ron" on 07/12/2000 07:49:30 PM To: John Kennedy/Certicom@Certicom, Robert Zuccherato cc: ietf-sasl@imc.org, ietf-tls@lists.consensus.com Subject: RE: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-0 1 .txt] If the TLS endpoint is the server, I don't see what you mean about TLS not being able to "provide on-going binding of client identity"? TLS itself should be capable of preventing attacks on the communication. In the case where the TLS enpoint is not the server, surely a man-in-the-middle attack is feasible? Ron. -----Original Message----- From: John Kennedy [mailto:jkennedy@certicom.com] Sent: Thursday, 13 July 2000 3:52 To: Robert Zuccherato Cc: ietf-sasl@imc.org; ietf-tls@lists.consensus.com Subject: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01 .txt] Hi, Another advantage of this scheme (and SASL, in general) is that the client authentication mechanism need not have any relationship to the cipher suite used in the TLS protocol. For example, after an RSA-based, server-authenticated TLS session is established, the ECDSA version of this SASL mechanism could be used by a client to authenticate to the server. In this way, existing server side TLS and RSA-based PKI components can be retained while still permitting strong authentication from clients for which ECDSA signing is a more computationally-friendly authentication operation. The ability to accomodate such "hybrid" client-server authentication schemes without throwing out existing server-authentication infrastructure (e.g.,code/certs) has a number of obvious practical advantages. On the other hand, the disadvantage of hybrid TLS+SASL approaches is that the server's TLS layer alone is not able to provide on-going binding of client identity to the server simply because it was not involved in client authentication and the client's credentials are not incorporated into the TLS authenticated key exchange. Care must be taken on both sides of the link to insure that relying party access control and other policy enforcement mechanisms can "see" and correctly characterize channel security characteristics that are implemented at different layers in the stack. Hybrid, "cross-layer" schemes may be practical, but can also be a double-edged sword. This, of course, is only a warning to implementors, not a criticism of the protocols themselves. Regards, -John Kennedy Robert Zuccherato on 07/12/2000 08:01:18 AM To: ietf-sasl@imc.org cc: (bcc: John Kennedy/Certicom) Subject: FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01.txt Hi, I just thought I would let the list know that Magnus and I have resubmitted our draft describing a public-key based SASL mechanism. We have addressed some of the specific comments that people had and attempted to provide a little bit more motivation. As was discussed on this list earlier, the main motivation of this draft is to provide authentication in environments where, for various architectural reasons, the endpoint of the TLS session is not the same as the application endpoint. However, it was mentioned to us recently that our draft also supports the situation where a user initially establishes a server-side authenticated connection, browses around, and then requests a certain URL which requires client authentication. This mechanism allows this "upgrade" in authentication without requiring a re-negotiation of the TLS session. Robert Zuccherato. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA19516 for ietf-sasl-bks; Wed, 12 Jul 2000 19:48:07 -0700 (PDT) Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA19512 for ; Wed, 12 Jul 2000 19:48:04 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id <3X7A01YC>; Thu, 13 Jul 2000 12:49:29 +1000 Message-ID: <11981F9F5649D411BC92009027D0D18C57689F@aspams01.cai.com> From: "Ramsay, Ron" To: John Kennedy , Robert Zuccherato Cc: ietf-sasl@imc.org, ietf-tls@lists.consensus.com Subject: RE: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-0 1 .txt] Date: Thu, 13 Jul 2000 12:49:30 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If the TLS endpoint is the server, I don't see what you mean about TLS not being able to "provide on-going binding of client identity"? TLS itself should be capable of preventing attacks on the communication. In the case where the TLS enpoint is not the server, surely a man-in-the-middle attack is feasible? Ron. -----Original Message----- From: John Kennedy [mailto:jkennedy@certicom.com] Sent: Thursday, 13 July 2000 3:52 To: Robert Zuccherato Cc: ietf-sasl@imc.org; ietf-tls@lists.consensus.com Subject: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01 .txt] Hi, Another advantage of this scheme (and SASL, in general) is that the client authentication mechanism need not have any relationship to the cipher suite used in the TLS protocol. For example, after an RSA-based, server-authenticated TLS session is established, the ECDSA version of this SASL mechanism could be used by a client to authenticate to the server. In this way, existing server side TLS and RSA-based PKI components can be retained while still permitting strong authentication from clients for which ECDSA signing is a more computationally-friendly authentication operation. The ability to accomodate such "hybrid" client-server authentication schemes without throwing out existing server-authentication infrastructure (e.g.,code/certs) has a number of obvious practical advantages. On the other hand, the disadvantage of hybrid TLS+SASL approaches is that the server's TLS layer alone is not able to provide on-going binding of client identity to the server simply because it was not involved in client authentication and the client's credentials are not incorporated into the TLS authenticated key exchange. Care must be taken on both sides of the link to insure that relying party access control and other policy enforcement mechanisms can "see" and correctly characterize channel security characteristics that are implemented at different layers in the stack. Hybrid, "cross-layer" schemes may be practical, but can also be a double-edged sword. This, of course, is only a warning to implementors, not a criticism of the protocols themselves. Regards, -John Kennedy Robert Zuccherato on 07/12/2000 08:01:18 AM To: ietf-sasl@imc.org cc: (bcc: John Kennedy/Certicom) Subject: FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01.txt Hi, I just thought I would let the list know that Magnus and I have resubmitted our draft describing a public-key based SASL mechanism. We have addressed some of the specific comments that people had and attempted to provide a little bit more motivation. As was discussed on this list earlier, the main motivation of this draft is to provide authentication in environments where, for various architectural reasons, the endpoint of the TLS session is not the same as the application endpoint. However, it was mentioned to us recently that our draft also supports the situation where a user initially establishes a server-side authenticated connection, browses around, and then requests a certain URL which requires client authentication. This mechanism allows this "upgrade" in authentication without requiring a re-negotiation of the TLS session. Robert Zuccherato. Received: by ns.secondary.com (8.9.3/8.9.3) id KAA00392 for ietf-sasl-bks; Wed, 12 Jul 2000 10:58:02 -0700 (PDT) Received: from mail.ca.certicom.com ([209.121.99.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA00387 for ; Wed, 12 Jul 2000 10:58:01 -0700 (PDT) Received: from smtpmail.certicom.com (domino2.certicom.com [10.0.1.25]) by mail.ca.certicom.com (8.9.3/8.9.3) with SMTP id NAA21489; Wed, 12 Jul 2000 13:54:40 -0400 (EDT) Received: by smtpmail.certicom.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 8525691A.0062371F ; Wed, 12 Jul 2000 13:52:46 -0400 X-Lotus-FromDomain: CERTICOM From: "John Kennedy" To: Robert Zuccherato cc: ietf-sasl@imc.org, ietf-tls@lists.consensus.com Message-ID: <8525691A.0062356C.00@smtpmail.certicom.com> Date: Wed, 12 Jul 2000 10:52:09 -0700 Subject: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01 .txt] Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, Another advantage of this scheme (and SASL, in general) is that the client authentication mechanism need not have any relationship to the cipher suite used in the TLS protocol. For example, after an RSA-based, server-authenticated TLS session is established, the ECDSA version of this SASL mechanism could be used by a client to authenticate to the server. In this way, existing server side TLS and RSA-based PKI components can be retained while still permitting strong authentication from clients for which ECDSA signing is a more computationally-friendly authentication operation. The ability to accomodate such "hybrid" client-server authentication schemes without throwing out existing server-authentication infrastructure (e.g.,code/certs) has a number of obvious practical advantages. On the other hand, the disadvantage of hybrid TLS+SASL approaches is that the server's TLS layer alone is not able to provide on-going binding of client identity to the server simply because it was not involved in client authentication and the client's credentials are not incorporated into the TLS authenticated key exchange. Care must be taken on both sides of the link to insure that relying party access control and other policy enforcement mechanisms can "see" and correctly characterize channel security characteristics that are implemented at different layers in the stack. Hybrid, "cross-layer" schemes may be practical, but can also be a double-edged sword. This, of course, is only a warning to implementors, not a criticism of the protocols themselves. Regards, -John Kennedy Robert Zuccherato on 07/12/2000 08:01:18 AM To: ietf-sasl@imc.org cc: (bcc: John Kennedy/Certicom) Subject: FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01.txt Hi, I just thought I would let the list know that Magnus and I have resubmitted our draft describing a public-key based SASL mechanism. We have addressed some of the specific comments that people had and attempted to provide a little bit more motivation. As was discussed on this list earlier, the main motivation of this draft is to provide authentication in environments where, for various architectural reasons, the endpoint of the TLS session is not the same as the application endpoint. However, it was mentioned to us recently that our draft also supports the situation where a user initially establishes a server-side authenticated connection, browses around, and then requests a certain URL which requires client authentication. This mechanism allows this "upgrade" in authentication without requiring a re-negotiation of the TLS session. Robert Zuccherato. Received: by ns.secondary.com (8.9.3/8.9.3) id IAA20237 for ietf-sasl-bks; Wed, 12 Jul 2000 08:01:07 -0700 (PDT) Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA20233 for ; Wed, 12 Jul 2000 08:01:06 -0700 (PDT) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <34W5HA2N>; Wed, 12 Jul 2000 11:02:32 -0400 Message-ID: From: Robert Zuccherato To: ietf-sasl@imc.org Subject: FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01.txt Date: Wed, 12 Jul 2000 11:01:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, I just thought I would let the list know that Magnus and I have resubmitted our draft describing a public-key based SASL mechanism. We have addressed some of the specific comments that people had and attempted to provide a little bit more motivation. As was discussed on this list earlier, the main motivation of this draft is to provide authentication in environments where, for various architectural reasons, the endpoint of the TLS session is not the same as the application endpoint. However, it was mentioned to us recently that our draft also supports the situation where a user initially establishes a server-side authenticated connection, browses around, and then requests a certain URL which requires client authentication. This mechanism allows this "upgrade" in authentication without requiring a re-negotiation of the TLS session. Robert Zuccherato. > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, July 11, 2000 6:31 AM > Subject: I-D ACTION:draft-zuccherato-9798-3-sasl-01.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : ISO/IEC 9798-3 Authentication SASL Mechanism > Author(s) : R. Zuccherato, M. Nystrom > Filename : draft-zuccherato-9798-3-sasl-01.txt > Pages : 15 > Date : 10-Jul-00 > > This document defines a SASL [RFC2222] authentication mechanism based > on ISO/IEC 9798-3 [ISO3] and FIPS PUB 196 [FIPS] entity > authentication. This mechanism only provides authentication using > X.509 certificates [X509]. It has no effect on the protocol > encodings and does not provide integrity or confidentiality services. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zuccherato-9798-3-sasl-01.txt 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-zuccherato-9798-3-sasl-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zuccherato-9798-3-sasl-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.