From secmech-bounces@lists.ietf.org Fri Jul 01 19:37:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoV4x-0006Qv-Vt; Fri, 01 Jul 2005 19:37:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoV4x-0006Qq-7R for secmech@megatron.ietf.org; Fri, 01 Jul 2005 19:37:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07213 for ; Fri, 1 Jul 2005 19:37:47 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoVV0-00044a-TG for secmech@ietf.org; Fri, 01 Jul 2005 20:04:47 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 01 Jul 2005 16:37:42 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j61NbdvM000613 for ; Fri, 1 Jul 2005 16:37:39 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jul 2005 16:41:59 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905781D71@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: Generally usable mechanism requirements Thread-Index: AcV+ld66rocWJwP6Tcmhot82Ay6fAg== From: "Salowey, Joe" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Cc: Subject: [SECMECH] Generally usable mechanism requirements X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org Here are some requirements for generally useful authentication mechanisms 1. MUST support GSS-API, EAP and SASL frameworks. This means that the mechanism MUST be identifiable in any of these framework and have an EAP ID, GSS-OID and SASL name. Note that any GSSAPI mechanism can be automatically mapped into the SASL mechanism namespace through the use of the GSS-* SASL mechanism family. 2. MUST support mutual authentication. We may have some discussion as to what this means, for example in systems it is not uncommon for an entity to be authenticated to a realm or domain instead of the exact peer it is communicating with. A mechanism MAY support the capability to authenticate only one side or provide anonymous authentication.=20 3. MAY support identity privacy of one of the peers. A mechanism should document if it supports identity privacy, which parties identity is protected and how it works.=20 4. MUST support key derivation based on the authentication. This is the way EAP establishes and a cryptographic context. GSS-API is working on a standard PRF API to expose this functionality in GSSAPI mechanisms.=20 5. MUST support a security layer. This is a requirement of SASL and GSS-API mechanisms. GSS-API wrap and mic style protection should be provided. Although this is not part of the definition of an EAP mechanism it should be difficult to add since EAP provides key material which can be used as a basis for cryptographic functions. A generic protection transform can be provided for mechanisms that don't provide their own. =20 6. MUST support the ability to provide cryptographic binding to an encapsulating channel. This is identified as channel bindings in GSS-API and cryptographic binding in EAP. This provides an interface into a mechanism that accepts external channel data and the mechanism implementations validate that both sides provided the same data. =20 7. MUST support the ability to communicate attributes that are authenticated as part of the authentication exchange and validated external to the mechanism. This is referred to in EAP as channel bindings. Channel Bindings (EAP) requires and interface into a mechanism that accepts data to be sent in an authenticated manner to the other party and a interface to obtain authenticated data from the other party to be validated outside the mechanism. It is possible that this could be added to GSS-API through naming extensions.=20 8. MUST provide messages to allow the authentications to be initiated from either side. This is necessary since EAP is always server initiated and GSSAPI is always 'client' initiated. This may just involve an extra message in the exchange.=20 9. MUST provide documentation to describe the mechanism properties defined in [RFC3748]. GUAM mechanisms MUST support the following: generation of keying material, mutual authentication, shared state equivalence, replay protection, integrity protection, cryptographic binding, session independence, and ciphersuite negotiation protection. GUAM mechanisms MAY support the following: It is also desirable for GUAM mechanisms to support the following: resistance to dictionary attacks, fragmentation, and confidentiality. 10. MUST provide an option for a peer to get required credentials in-band. This is to support network access use cases where the only access available to a network the authentication protocol executing between two peers. Kerberos GSS-API mechanism is an example of a mechanism that does not support this since credential acquisition from the KDC MUST happen out of band to the authentication mechanism. The expired draft of IAKERB did meet this requirement.=20 11. MUST expect than an arbitrary number of proxies between the authenticating parties may handle the messages. 12. SHOULD accept target names in host based service name format. If the mechanism makes use of a target name it should accept the name in host based service name format.=20 In general the issue of naming requires more discussion. EAP has NAI which is mainly for routing purposes and is in general external to a mechanism (although a mechanism can choose to use an NAI name format). SASL has an authorization ID which can be communicated by the mechanism. The mapping from authentication ID to authorization ID needs to be validated and authorized. I don't really think this mapping belongs in the mechanism, rather it should happen external to the mechanism (perhaps within another component), but this probably requires that name are exported form mechanisms in some agreed upon format.=20 _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Sat Jul 02 20:38:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DosV9-000396-S5; Sat, 02 Jul 2005 20:38:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DosV8-00037g-Ck for secmech@megatron.ietf.org; Sat, 02 Jul 2005 20:38:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15277 for ; Sat, 2 Jul 2005 20:38:24 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.203]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DosvP-0002E0-67 for secmech@ietf.org; Sat, 02 Jul 2005 21:05:35 -0400 Received: by wproxy.gmail.com with SMTP id 36so531652wra for ; Sat, 02 Jul 2005 17:38:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fmSz+Qvx5+RGETiDAuoJS1r2UDVefkIcjpShqEWjS7n4YfOiFsC93VWHXkYXEJx3UveWmQiNbjwO+rC6Vb8HW9S4j5NS9QtJuLymA4lXKSqehryrAoe4eezlQJOrHwI1AjeF41/GCaXfXP1A4kH42V5SpByNH9g4jRXDOhFITwY= Received: by 10.54.27.45 with SMTP id a45mr2627969wra; Sat, 02 Jul 2005 17:38:16 -0700 (PDT) Received: by 10.54.57.49 with HTTP; Sat, 2 Jul 2005 17:38:16 -0700 (PDT) Message-ID: Date: Sat, 2 Jul 2005 17:38:16 -0700 From: Clint Chaplin To: "Salowey, Joe" Subject: Re: [SECMECH] Generally usable mechanism requirements In-Reply-To: <7210B31550AC934A8637D6619739CE6905781D71@e2k-sea-xch2.sea-alpha.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <7210B31550AC934A8637D6619739CE6905781D71@e2k-sea-xch2.sea-alpha.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: quoted-printable Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Clint Chaplin List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org Comments inline; mostly typos... On 7/1/05, Salowey, Joe wrote: > Here are some requirements for generally useful authentication > mechanisms >=20 > 1. MUST support GSS-API, EAP and SASL frameworks. This means that the > mechanism MUST be identifiable in any of these framework and have an EAP > ID, GSS-OID and SASL name. Note that any GSSAPI mechanism can be > automatically mapped into the SASL mechanism namespace through the use > of the GSS-* SASL mechanism family. >=20 > 2. MUST support mutual authentication. We may have some discussion as to > what this means, for example in systems it is not uncommon for an entity > to be authenticated to a realm or domain instead of the exact peer it is > communicating with. A mechanism MAY support the capability to > authenticate only one side or provide anonymous authentication. >=20 > 3. MAY support identity privacy of one of the peers. A mechanism should > document if it supports identity privacy, which parties identity is > protected and how it works. >=20 > 4. MUST support key derivation based on the authentication. This is the > way EAP establishes and a cryptographic context. GSS-API is working on > a standard PRF API to expose this functionality in GSSAPI mechanisms. "EAP establishes and a cryptographic context." Either something is missing, or something is extra. I couldn't figure out which. >=20 > 5. MUST support a security layer. This is a requirement of SASL and > GSS-API mechanisms. GSS-API wrap and mic style protection should be > provided. Although this is not part of the definition of an EAP > mechanism it should be difficult to add since EAP provides key material > which can be used as a basis for cryptographic functions. A generic > protection transform can be provided for mechanisms that don't provide > their own. "it should be difficult to add since EAP" Surely this is "it shouldn't be difficult to add since EAP" (and don't call me Shirley) >=20 > 6. MUST support the ability to provide cryptographic binding to an > encapsulating channel. This is identified as channel bindings in > GSS-API and cryptographic binding in EAP. This provides an interface > into a mechanism that accepts external channel data and the mechanism > implementations validate that both sides provided the same data. >=20 > 7. MUST support the ability to communicate attributes that are > authenticated as part of the authentication exchange and validated > external to the mechanism. This is referred to in EAP as channel > bindings. Channel Bindings (EAP) requires and interface into a > mechanism that accepts data to be sent in an authenticated manner to the > other party and a interface to obtain authenticated data from the other > party to be validated outside the mechanism. It is possible that this > could be added to GSS-API through naming extensions. "Channel Bindings (EAP) requires and interface" and -> an. >=20 > 8. MUST provide messages to allow the authentications to be initiated > from either side. This is necessary since EAP is always server > initiated and GSSAPI is always 'client' initiated. This may just > involve an extra message in the exchange. >=20 > 9. MUST provide documentation to describe the mechanism properties > defined in [RFC3748]. GUAM mechanisms MUST support the following: > generation of keying material, mutual authentication, shared state > equivalence, replay protection, integrity protection, cryptographic > binding, session independence, and ciphersuite negotiation protection. > GUAM mechanisms MAY support the following: It is also desirable for GUAM > mechanisms to support the following: resistance to dictionary attacks, > fragmentation, and confidentiality. "GUAM mechanisms MAY support the following: It is also desirable for GUAM mechanisms to support the following: resistance to dictionary attacks, fragmentation, and confidentiality." I think perhaps two thought collided in the above sentence, and infortunately both won; either that or it's a cut and paste error. >=20 > 10. MUST provide an option for a peer to get required credentials > in-band. This is to support network access use cases where the only > access available to a network the authentication protocol executing > between two peers. Kerberos GSS-API mechanism is an example of a > mechanism that does not support this since credential acquisition from > the KDC MUST happen out of band to the authentication mechanism. The > expired draft of IAKERB did meet this requirement. >=20 "This is to support network access use cases where the only access available to a network _is_ the authentication protocol executing between two peers" > 11. MUST expect than an arbitrary number of proxies between the > authenticating parties may handle the messages. > "MUST expect _that_ an arbitrary number of proxies between the authenticating parties may handle the messages." =20 > 12. SHOULD accept target names in host based service name format. If > the mechanism makes use of a target name it should accept the name in > host based service name format. >=20 > In general the issue of naming requires more discussion. EAP has NAI > which is mainly for routing purposes and is in general external to a > mechanism (although a mechanism can choose to use an NAI name format). > SASL has an authorization ID which can be communicated by the mechanism. > The mapping from authentication ID to authorization ID needs to be > validated and authorized. I don't really think this mapping belongs in > the mechanism, rather it should happen external to the mechanism > (perhaps within another component), but this probably requires that name > are exported form mechanisms in some agreed upon format. >=20 >=20 > _______________________________________________ > SECMECH mailing list > SECMECH@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/secmech >=20 --=20 Clint (JOATMON) Chaplin Wireless Security Technologist Wireless Standards Manager _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Tue Jul 05 14:25:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dps6i-00088z-BT; Tue, 05 Jul 2005 14:25:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dps6f-00083p-WD for secmech@megatron.ietf.org; Tue, 05 Jul 2005 14:25:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03349 for ; Tue, 5 Jul 2005 14:25:16 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpsS3-0000fT-GF for secmech@ietf.org; Tue, 05 Jul 2005 14:47:24 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 05 Jul 2005 11:19:30 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j65IJRvM026534; Tue, 5 Jul 2005 11:19:28 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [SECMECH] Generally usable mechanism requirements Date: Tue, 5 Jul 2005 11:23:50 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905781EE9@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [SECMECH] Generally usable mechanism requirements Thread-Index: AcV/aDYfvDqfWfG/TvOxpZNM4sNJMgCJOLwg From: "Salowey, Joe" To: "Clint Chaplin" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org Thanks Clint,=20 > > 4. MUST support key derivation based on the authentication.=20 > This is=20 > > the way EAP establishes and a cryptographic context. GSS-API is=20 > > working on a standard PRF API to expose this functionality=20 > in GSSAPI mechanisms. >=20 > "EAP establishes and a cryptographic context." Either=20 > something is missing, or something is extra. I couldn't=20 > figure out which. >=20 [Joe] I originally intended it to read "EAP establishes and exports a cryptographic context." >=20 > >=20 > > 5. MUST support a security layer. This is a requirement of=20 > SASL and=20 > > GSS-API mechanisms. GSS-API wrap and mic style protection=20 > should be=20 > > provided. Although this is not part of the definition of an EAP=20 > > mechanism it should be difficult to add since EAP provides key=20 > > material which can be used as a basis for cryptographic=20 > functions. A=20 > > generic protection transform can be provided for mechanisms=20 > that don't=20 > > provide their own. >=20 > "it should be difficult to add since EAP" Surely this is "it=20 > shouldn't be difficult to add since EAP" (and don't call me Shirley) >=20 [Joe] Yes. > > 9. MUST provide documentation to describe the mechanism properties=20 > > defined in [RFC3748]. GUAM mechanisms MUST support the following: > > generation of keying material, mutual authentication, shared state=20 > > equivalence, replay protection, integrity protection, cryptographic=20 > > binding, session independence, and ciphersuite negotiation=20 > protection. > > GUAM mechanisms MAY support the following: It is also desirable for=20 > > GUAM mechanisms to support the following: resistance to dictionary=20 > > attacks, fragmentation, and confidentiality. >=20 >=20 > "GUAM mechanisms MAY support the following: It is also=20 > desirable for GUAM mechanisms to support the following:=20 > resistance to dictionary attacks, fragmentation, and=20 > confidentiality." I think perhaps two thought collided in=20 > the above sentence, and infortunately both won; either that=20 > or it's a cut and paste error. >=20 [Joe] It should read "GUAM mechanisms MAY support the following: resistance to dictionary attacks, fragmentation, and confidentiality. _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Wed Jul 13 17:38:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsovp-0002Eu-B2; Wed, 13 Jul 2005 17:38:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsovo-0002D6-Jn for secmech@megatron.ietf.org; Wed, 13 Jul 2005 17:38:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16096 for ; Wed, 13 Jul 2005 17:38:14 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DspOH-0003QN-PQ for secmech@ietf.org; Wed, 13 Jul 2005 18:07:43 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 13 Jul 2005 14:38:06 -0700 X-IronPort-AV: i="3.93,288,1115017200"; d="scan'208"; a="648395321:sNHT27039556" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6DLc2vM008451; Wed, 13 Jul 2005 14:38:02 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jul 2005 14:42:31 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905823019@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: EAP methods and Generally Usable Authentication Mechanisms Thread-Index: AcWH8yXXu3Tk062TTE6KqZjW0g+r0g== From: "Salowey, Joe" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: eap@frascone.com Subject: [SECMECH] EAP methods and Generally Usable Authentication Mechanisms X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org I think it is possible to define reasonable EAP methods as authentication mechanisms that can be used in SASL and GSS-API without much additional work. I think EAP mechanisms we standardize should be generally useable. From discussions on the secmech list and from the GUAM draft (draft-salowey-guam-00) I think the following list would need to be addressed to define an EAP mechanism that is generally useful: 1. Define a GSS-API OID and a SASL name, this could be done algorithmically. Some additional documentation would be required to meet the SASL registration requirements and the mapping to GSS-API calls.=20 2. The protocol may require slight modification to allow the option for the client to initiate the conversation. This shouldn't be too difficult since many protocols such as TLS is already client initiated.=20 3. Support for a security layer - A security layer would have to be defined to authenticate and encrypt data. The best approach would be to define a standard (or set of standard) encryption mechanism(s) that can consume the key material exported from EAP. It is probably necessary to have a way to negotiate a protection mechanism, but it may be possible to make this part of the GSS OID or SASL name so it can be negotiated through other means.=20 4. Cryptographic Binding/Channel Bindings(GSS)/Channel Bindings(EAP) - This type of functionality has already been identified as something that is useful for EAP methods. Many existing mechanism such as EAP-TLS do not provide a way to provide external data to be validated or exported in the authentication exchange. Most protocols could be extended to provide this functionality.=20 5. Naming may be an issue, but it probably doesn't affect the mechanism protocol itself, but rather how the mechanism represents names externally. This will probably require some specification in the mechanism as to how to deal with names. The issue of naming is somewhat tied to credentials and perhaps can be taken care in separate specifications that deal with specific credential types such as X.509 certificates and apply across mechanisms that utilize the same credential type.=20 _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Thu Jul 14 16:37:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtASn-0000fA-GV; Thu, 14 Jul 2005 16:37:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtASl-0000eU-OZ for secmech@megatron.ietf.org; Thu, 14 Jul 2005 16:37:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02672 for ; Thu, 14 Jul 2005 16:37:41 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtAvM-0006yR-A9 for secmech@ietf.org; Thu, 14 Jul 2005 17:07:21 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 997A0E004B; Thu, 14 Jul 2005 16:37:28 -0400 (EDT) To: secmech@ietf.org From: Sam Hartman Date: Thu, 14 Jul 2005 16:37:28 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [SECMECH] Desire to standardize some specific EAP mechanisms X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org Comments from the EAP chairs and the IESG suggest there is a strong desire to standardize some specific EAP mechanisms probably before the GUAM work is done. I think this might be doable particularly if the EAP mechanisms standardized are things like eap-tls where there are already alternatives for other frameworks. The issue is simply one of timing. The original proposal was to do that work in the EAP working group and to (depending on BOF results) spin up secmech to do the more general work. I'm uncomfortable with that work being done outside the security area. I'm also uncomfortable with two ongoing parallel efforts without strong coordination. I propose that if we want to take that approach we standardize the specific mechanisms in the secmech group along with doing the more general work. For timing reasons we might even need to prioritize some of the EAP work. I think there are many advantages to doing so: 1) We become more familiar with the requirements of EAP and the same group of people doing general work get specific practical experience. 2) Since the same group of people are doing both the general and specific work you are likely to get better sanity checking across the projects. 3) You make sure the efforts don't diverge. 4) You leverage security review experience from the GSS and SASL comnunities and practical deployment experience from the EAP community. If we take that approach, two things need to happen. First, we need to get a specific set of mechanisms to standardize early into the charter. Second, we would need at least one int-area chair--possibly one of the existing EAP chairs if willing to serve--by the time a WG is chartered. Thanks for your consideration, --Sam _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Jul 15 01:04:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtINV-0006Ha-Gx; Fri, 15 Jul 2005 01:04:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtINU-0006Fy-2e for secmech@megatron.ietf.org; Fri, 15 Jul 2005 01:04:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09529 for ; Fri, 15 Jul 2005 01:04:46 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtIqD-0008A7-Q8 for secmech@ietf.org; Fri, 15 Jul 2005 01:34:31 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 14 Jul 2005 22:04:37 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6F54ZVX009136; Thu, 14 Jul 2005 22:04:35 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [SECMECH] Desire to standardize some specific EAP mechanisms Date: Thu, 14 Jul 2005 22:09:01 -0700 Message-ID: <7210B31550AC934A8637D6619739CE69058234E4@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [SECMECH] Desire to standardize some specific EAP mechanisms Thread-Index: AcWIvs3YZxMeWxAtS5imR58m5Cv80wAOohcA From: "Salowey, Joe" To: "Sam Hartman" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org I think this could be a reasonable approach, although I would like to see the work of standardizing specific mechanisms and work to generalize methods start in parallel. =20 As far as mechanisms go I think it is relatively important to get a revision of EAP-TLS into the standards track. Through the use of TLS you can cover X.509 and pre-shared key credentials. I think there is also interest in the EAP community to standardize additional pre-shared key mechanisms (EAP-PSK, EAP-PAX) and tunneled methods (PEAP, TTLS, EAP-FAST). =20 Joe =20 _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Jul 15 01:13:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtIW2-0002eV-Ql; Fri, 15 Jul 2005 01:13:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtIW0-0002eK-IP for secmech@megatron.ietf.org; Fri, 15 Jul 2005 01:13:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09999 for ; Fri, 15 Jul 2005 01:13:34 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtIyj-0008Og-Ud for secmech@ietf.org; Fri, 15 Jul 2005 01:43:19 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 14 Jul 2005 22:13:33 -0700 X-IronPort-AV: i="3.93,291,1115017200"; d="scan'208"; a="648681139:sNHT29039232" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6F5DUvM018738 for ; Thu, 14 Jul 2005 22:13:30 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jul 2005 22:17:59 -0700 Message-ID: <7210B31550AC934A8637D6619739CE69058234E6@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: secmech BOF scheduled for Tuesday 8/2 1030-1230 Thread-Index: AcWI+/GG+JjsXXpQSVaMcOpv/+QdjQ== From: "Salowey, Joe" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Cc: Subject: [SECMECH] secmech BOF scheduled for Tuesday 8/2 1030-1230 X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org TUESDAY, August 2, 2005 1030-1230 Morning Session II SEC secmech Security Mechanisms BOF AGENDA: Agenda bashing : 05 mins EAP Method requirements : 20 min Kitten GSS-API Updates : 20 min Generally usable authentication methods : 20 min Charter discussion : 55 min _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Jul 15 03:32:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtKgd-00064T-7N; Fri, 15 Jul 2005 03:32:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtKgb-00064L-53 for secmech@megatron.ietf.org; Fri, 15 Jul 2005 03:32:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10369 for ; Fri, 15 Jul 2005 03:32:39 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtL9M-00046o-Un for secmech@ietf.org; Fri, 15 Jul 2005 04:02:25 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j6F7WQrj024941; Fri, 15 Jul 2005 09:32:27 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j6F7WQWh011119; Fri, 15 Jul 2005 09:32:26 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.146]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 15 Jul 2005 09:35:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [SECMECH] Desire to standardize some specific EAP mechanisms Date: Fri, 15 Jul 2005 09:32:23 +0200 Message-ID: Thread-Topic: [SECMECH] Desire to standardize some specific EAP mechanisms Thread-Index: AcWIviSj48xInkznSyCFC+G1ztZ6swAURcvQ From: "Tschofenig, Hannes" To: "Sam Hartman" , X-OriginalArrivalTime: 15 Jul 2005 07:35:49.0796 (UTC) FILETIME=[D26F6E40:01C5890F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org hi sam,=20 it seems that you already have some eap methods in mind that you would = like to standardize.=20 can you tell us more?=20 ciao hannes > -----Urspr=FCngliche Nachricht----- > Von: secmech-bounces@lists.ietf.org=20 > [mailto:secmech-bounces@lists.ietf.org] Im Auftrag von Sam Hartman > Gesendet: Donnerstag, 14. Juli 2005 22:37 > An: secmech@ietf.org > Betreff: [SECMECH] Desire to standardize some specific EAP mechanisms=20 >=20 >=20 >=20 >=20 > Comments from the EAP chairs and the IESG suggest there is a strong > desire to standardize some specific EAP mechanisms probably before the > GUAM work is done. >=20 > I think this might be doable particularly if the EAP mechanisms > standardized are things like eap-tls where there are already > alternatives for other frameworks. The issue is simply one of timing. >=20 > The original proposal was to do that work in the EAP working group and > to (depending on BOF results) spin up secmech to do the more general > work. >=20 > I'm uncomfortable with that work being done outside the security area. > I'm also uncomfortable with two ongoing parallel efforts without > strong coordination. >=20 > I propose that if we want to take that approach we standardize the > specific mechanisms in the secmech group along with doing the more > general work. For timing reasons we might even need to prioritize > some of the EAP work. I think there are many advantages to doing so: >=20 > 1) We become more familiar with the requirements of EAP and=20 > the same group of people doing general work get specific=20 > practical experience. >=20 > 2) Since the same group of people are doing both the general and > specific work you are likely to get better sanity checking across > the projects. >=20 > 3) You make sure the efforts don't diverge. >=20 > 4) You leverage security review experience from the GSS and SASL > comnunities and practical deployment experience from the=20 > EAP community. >=20 > If we take that approach, two things need to happen. First, we need > to get a specific set of mechanisms to standardize early into the > charter. Second, we would need at least one int-area chair--possibly > one of the existing EAP chairs if willing to serve--by the time a WG > is chartered. >=20 > Thanks for your consideration, >=20 > --Sam >=20 >=20 > _______________________________________________ > SECMECH mailing list > SECMECH@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/secmech >=20 _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Fri Jul 15 07:32:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtOR1-0002G2-4T; Fri, 15 Jul 2005 07:32:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtOQz-0002E3-NW for secmech@megatron.ietf.org; Fri, 15 Jul 2005 07:32:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26558 for ; Fri, 15 Jul 2005 07:32:48 -0400 (EDT) Received: from ringding.cs.umd.edu ([128.8.129.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtOtm-0004t0-Si for secmech@ietf.org; Fri, 15 Jul 2005 08:02:36 -0400 Received: from nerds.cs.umd.edu (nerds.cs.umd.edu [128.8.129.84]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j6FBWb1q022658; Fri, 15 Jul 2005 07:32:37 -0400 (EDT) Date: Fri, 15 Jul 2005 07:32:37 -0400 (EDT) From: "T. Charles Clancy" To: Sam Hartman Subject: Re: [SECMECH] Desire to standardize some specific EAP mechanisms In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: secmech@ietf.org X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org As an author of EAP-PAX, I've been frustrated with the standards track options available. Doing the work in the EAP WG is the fastest route to RFC. IMHO, there is sufficient security talent within the EAP WG to guarantee quality protocol development. I certainly understand the concerns about diverging or duplicate work; however, my biggest concern is the overhead time. I've been trying to get standards-track action for EAP-PAX for 8 months. I suppose the existince of this conversation indicates progress, but I'm not enthusiastic about waiting another year or so. If the proposed approach can be done in a timely manner, then I'm all for it. [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] On Thu, 14 Jul 2005, Sam Hartman wrote: > > > Comments from the EAP chairs and the IESG suggest there is a strong > desire to standardize some specific EAP mechanisms probably before the > GUAM work is done. > > I think this might be doable particularly if the EAP mechanisms > standardized are things like eap-tls where there are already > alternatives for other frameworks. The issue is simply one of timing. > > The original proposal was to do that work in the EAP working group and > to (depending on BOF results) spin up secmech to do the more general > work. > > I'm uncomfortable with that work being done outside the security area. > I'm also uncomfortable with two ongoing parallel efforts without > strong coordination. > > I propose that if we want to take that approach we standardize the > specific mechanisms in the secmech group along with doing the more > general work. For timing reasons we might even need to prioritize > some of the EAP work. I think there are many advantages to doing so: > > 1) We become more familiar with the requirements of EAP and the same > group of people doing general work get specific practical experience. > > 2) Since the same group of people are doing both the general and > specific work you are likely to get better sanity checking across > the projects. > > 3) You make sure the efforts don't diverge. > > 4) You leverage security review experience from the GSS and SASL > comnunities and practical deployment experience from the EAP community. > > If we take that approach, two things need to happen. First, we need > to get a specific set of mechanisms to standardize early into the > charter. Second, we would need at least one int-area chair--possibly > one of the existing EAP chairs if willing to serve--by the time a WG > is chartered. > > Thanks for your consideration, > > --Sam > > > _______________________________________________ > SECMECH mailing list > SECMECH@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/secmech > _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech From secmech-bounces@lists.ietf.org Thu Jul 28 00:41:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy0DQ-0002MZ-IC; Thu, 28 Jul 2005 00:41:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy0DO-0002Ks-FR for secmech@megatron.ietf.org; Thu, 28 Jul 2005 00:41:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03249 for ; Thu, 28 Jul 2005 00:41:46 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy0in-0006jS-3k for secmech@ietf.org; Thu, 28 Jul 2005 01:14:17 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 27 Jul 2005 21:41:41 -0700 X-IronPort-AV: i="3.95,147,1120460400"; d="scan'208"; a="326706921:sNHT30180100" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6S4fbul018670 for ; Wed, 27 Jul 2005 21:41:37 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jul 2005 21:46:15 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905944FFD@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: Draft Charter Thread-Index: AcWTLqbKDFYj1fjZRp+KhohI4GgE0A== From: "Salowey, Joe" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: Subject: [SECMECH] Draft Charter X-BeenThere: secmech@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security mechanisms BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secmech-bounces@lists.ietf.org Errors-To: secmech-bounces@lists.ietf.org Here is a draft of a possible sechmech working group charter: Security Mechanism BoF (secmech) Security Area Director: Sam Hartman Russ Housley Security Area Advisor: Sam Hartman Mailing Lists: General Discussion: secmech@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/secmech Archive: http://www.ietf.org/mail-archive/web/secmech/index.html Description of Proposed Working Group: There exists a disconnect between the IETF's security frameworks. Although these frameworks have very similar goals, the set of mechanisms available depends upon the choice of framework. There are a number of issues that make a compelling case for converging the way we develop mechanisms for these frameworks. =20 - There is a desire to standardized EAP mechanisms and there currently is no working group with this on its charter.=20 - The actual mechanisms in each of these frameworks have very similar goals of authentication and establishing a cryptographic context.=20 - There is pressure to adopt a particular framework because of the set of mechanisms available not because of the capabilities and upper-layer interface of the framework. =20 - There is a duplication of effort in the development of security mechanism that support similar credential types and infrastructures. - Often the cost of deploying a security mechanism is in the infrastructure and not the implementation of the mechanism itself. There limited set of mechanisms available to particular frameworks makes the coordination and administration of security between applications that use different frameworks more difficult.=20 At this time the working group is charter with the following tasks: - Identify a list of "fast track" EAP mechanism types for standardization. Possibly: TLS based mechanism, Pre shared key based mechanism (it is possible that a single mechanism may meet both requirements).=20 - Standardize fast-track EAP mechanisms - Document the basic requirements for a mechanism to be a GUAM mechanism - Document the process for creating a GUAM mechanism As this work progresses additional work items may be added to the charter of this group or other working groups such as - Definition of a common security layer (CFRG?) - Enhancements to the GSS-API to accommodate GUAM enhancements (Kitten) Goals and Milestones: September 2005: Charter to authorize work on a few fast track mechanisms and GUAM process October 2005: Submit initial draft of base GUAM requirements and standardization process October 2005: Select EAP mechanism approach to fast track requirements November 2005: Submit initial FAST-Track EAP method draft(s) December 2006: WG Last Call completes on base requirements and standardization process, begin working on method standardization=20 January 2006: WG Last Call completes on FAST-Track EAP method drafts February 2006: Submit GUAM standardization process as Proposed Standard=20 March 2006: Submit FAST-Track EAP as proposed standard, update charter with additional milestones _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech