From nico@cryptonector.com Mon Apr 2 21:56:44 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EB321F8577 for ; Mon, 2 Apr 2012 21:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.437 X-Spam-Level: X-Spam-Status: No, score=0.437 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PPpd3LnM2fX for ; Mon, 2 Apr 2012 21:56:43 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD9F21F842F for ; Mon, 2 Apr 2012 21:56:43 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 3ED3494064 for ; Mon, 2 Apr 2012 21:56:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=mq9Ibm8QQ1bXudGkP2BawsQWk6cZNEye0b0qvdzqd2Qu mHJoc9XIioqTfhSaP9xXakvR6Jm6xgqL//imAv9aTYZG8rTM/ReMVXFnZeNrynO7 PULE4PHp1lW9RVBoMvpifVDbUXxqqmvJhM3Osc/Ec3zxLmlAK+woGLq0j/8rhU8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type:content-transfer-encoding; s=cryptonector.com; bh=pFktajoVsfhBOWhCGhBiz4CdwlI=; b=i7y24ksnLEJYFSIekiyOMcFvmoyt ZZHfrjXKw/LY3XDJB1GSnRZBo8psCRNtnD0mseBXwj/tbZ6n+O5/a6DzJU1iBhQI M+toBLGBznZb7FWaWKS0XaRjB6qP0jippD4s3FVONfmSeyRi4ze6gYFc+/fQU6hH nxvjsBvvHVkTNyI= Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 288729405C for ; Mon, 2 Apr 2012 21:56:43 -0700 (PDT) Received: by dady13 with SMTP id y13so4225514dad.27 for ; Mon, 02 Apr 2012 21:56:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.132.99 with SMTP id ot3mr25637783pbb.160.1333429002556; Mon, 02 Apr 2012 21:56:42 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Mon, 2 Apr 2012 21:56:42 -0700 (PDT) In-Reply-To: References: Date: Mon, 2 Apr 2012 23:56:42 -0500 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [kitten] Proposed GSS extension for explicit credential stores X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 04:56:44 -0000 Simo and I have a need for extensions for acquiring credentials from, and storing credentials into, an explicit credential store as opposed to the one implied by process credentials/context/environment. For some use cases it is possible to get by without this extension by just forking/spawning processes that can change their process credentials and/or environment variables to change their implicit credential store. =C2=A0I understand that this argument will come up. =C2= =A0But this is not a great solution for us. =C2=A0Particularly since it is not a portable and generic solution. The solution we propose will still involve some elements that are not entirely generic or portable, but these elements are abstracted into key/value pairs that are easily configured, thus the resulting applications themselves should be generic and portable. The new functions are: =C2=A0- GSS_Acquire_cred_from() =C2=A0- GSS_Add_cred_from() =C2=A0- GSS_Store_cred_into() These are just like the existing functions that they are based on, but with one additional argument: a credential store. The credential store is just an ordered set of key/value pairs where the keys are URNs (as opposed to OIDs) and the values are octet strings with formats given by the keys. =C2=A0In the C bindings the credential store looks like this: typedef struct gss_cred_store_element_struct { =C2=A0 =C2=A0const char *urn; =C2=A0 =C2=A0const char *value; } gss_cred_store_element, *gss_cred_store_element_t; typedef const struct gss_cred_store_element *gss_const_cred_store_element_t= ; typedef struct gss_cred_store_struct { =C2=A0 =C2=A0OM_uint32 count; =C2=A0 =C2=A0gss_const_cred_store_element_t *elements; } gss_cred_store, *gss_cred_store_t; typedef const struct gss_cred_store_struct *gss_const_cred_store_t; Note the use of the C const keyword. The abstract API representation of this would probably be SET OF SEQUENCE { element_type_urn OCTET STRING, element OCTET STRING } or perhaps just "CREDENTIAL STORE". =C2=A0Note that RFC2743 has types with that much structure, namely: OID sets, or at least the C bindings of OID SET have that much structure. URNs will be provided for at least the following: =C2=A0- ccache values =C2=A0 Values will be of the form [:], such as the familiar "FILE:/tmp/somecc" but also "LSA:" and "CCAPI:...". =C2=A0- keytab values =C2=A0 Same as with ccache values, but naming a keytab. We'll probably provide URNs for other store element types, such as: =C2=A0- PKCS#11 URI See http://tools.ietf.org/html/draft-pechanec-pkcs11uri-06 We have debated, but not reached a conclusion, other possible element types such as: =C2=A0- User-ID, username =C2=A0- AFS PAG The complete C bindings would be: +/* Extension for credential stores */ +typedef struct gss_cred_store_element_struct { + const char *urn; + const char *value; +} gss_cred_store_element, *gss_cred_store_element_t; +typedef const struct gss_cred_store_element *gss_const_cred_store_element_= t; + +typedef struct gss_cred_store_struct { + OM_uint32 count; + gss_const_cred_store_element_t *elements; +} gss_cred_store, *gss_cred_store_t; +typedef const struct gss_cred_store_struct *gss_const_cred_store_t; +#define GSS_C_NO_CRED_STORE ((gss_const_cred_store_t) 0) +OM_uint32 gss_acquire_cred_from( + OM_uint32 *minor_status*, + const gss_name_t desired_name, + OM_uint32 time_req, + const gss_OID_set desired_mechs, + gss_cred_usage_t cred_usage, + gss_const_cred_store_t cred_store, + gss_cred_id_t *output_cred_handle, + gss_OID_set *actual_mechs, + OM_uint32 *time_rec); +OM_uint32 gss_add_cred_from ( + OM_uint32 *minor_status, + const gss_cred_id_t input_cred_handle, + const gss_name_t desired_name, + const gss_OID desired_mech, + gss_cred_usage_t cred_usage, + OM_uint32 initiator_time_req, + OM_uint32 acceptor_time_req, + gss_const_cred_store_t cred_store, + gss_cred_id_t *output_cred_handle, + gss_OID_set *actual_mechs, + OM_uint32 *initiator_time_rec, + OM_uint32 *acceptor_time_rec); +OM_uint32 gss_store_cred_into( + OM_uint32 *minor_status, + gss_cred_id_t input_cred_handle, + gss_cred_usage_t cred_usage, + const gss_OID desired_mech, + OM_uint32 overwrite_cred, + OM_uint32 default_cred, + gss_const_cred_store_t cred_store, + gss_OID_set *elements_stored, + gss_cred_usage_t *cred_usage_stored); Comments? Nico -- From simon@josefsson.org Tue Apr 3 05:29:06 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DE721F8795 for ; Tue, 3 Apr 2012 05:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04kAWPom68io for ; Tue, 3 Apr 2012 05:29:06 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id AE35421F878A for ; Tue, 3 Apr 2012 05:29:05 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q33CSqZZ020953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 3 Apr 2012 14:28:53 +0200 From: Simon Josefsson To: Nico Williams References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120403:nico@cryptonector.com::Z9RfwWzHm1O8PGQv:8w2a X-Hashcash: 1:22:120403:kitten@ietf.org::saY4uXYZvhHXbsfP:bq1w Date: Tue, 03 Apr 2012 14:28:52 +0200 In-Reply-To: (Nico Williams's message of "Mon, 2 Apr 2012 23:56:42 -0500") Message-ID: <87y5qdrocb.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] Proposed GSS extension for explicit credential stores X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 12:29:06 -0000 Nico Williams writes: > Simo and I have a need for extensions for acquiring credentials from, > and storing credentials into, an explicit credential store as opposed > to the one implied by process credentials/context/environment. I have often needed this too. > The abstract API representation of this would probably be > > SET OF SEQUENCE { > element_type_urn OCTET STRING, > element OCTET STRING > } It seems nice, but I haven't digested it fully yet. > URNs will be provided for at least the following: > >  - ccache values >   Values will be of the form [:], such as > the familiar "FILE:/tmp/somecc" but also "LSA:" and "CCAPI:...". > >  - keytab values >   Same as with ccache values, but naming a keytab. > > We'll probably provide URNs for other store element types, such as: > >  - PKCS#11 URI > See http://tools.ietf.org/html/draft-pechanec-pkcs11uri-06 > > We have debated, but not reached a conclusion, other possible element > types such as: > >  - User-ID, username > >  - AFS PAG I'd really like to see SAML SP metadata included here initially, and would be willing to help with writing. For simplicity, you could have multiple URns here, right? I'm thinking something like this: urn.ietf.kitten.saml.sp.metadata-file => "/etc/myapp/sp-metadata.xml" urn.ietf.kitten.saml.sp.key-file => "/etc/myapp/sp-key.pem" urn.ietf.kitten.saml.sp.cert-file => "/etc/myapp/sp-cert.pem" urn.ietf.kitten.saml.sp.metadata => " "-----BEGIN CERTIFICATE -----\nMII..." Alternatively, there could be a "struct" approach for SAML SP credentials if you wanted to use only one URN for each credential, however it gets a bit more ugly: urn.ietf.kitten.saml.sp => "metadata_file=/etc/myapp/sp-metadata.xml, key_file=/etc/myapp/sp-key.pem, ..." Thoughts? /Simon From simon@josefsson.org Tue Apr 3 05:41:38 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28FC21F84BD for ; Tue, 3 Apr 2012 05:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.165 X-Spam-Level: X-Spam-Status: No, score=-99.165 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNTL6HNISTGx for ; Tue, 3 Apr 2012 05:41:38 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4696621F84A7 for ; Tue, 3 Apr 2012 05:41:37 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q33CfPue021672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 3 Apr 2012 14:41:27 +0200 X-Hashcash: 1:22:120403:kitten@ietf.org::dKr4z7kiqkNCKHgP:uls From: Simon Josefsson To: kitten@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Tue, 03 Apr 2012 14:41:25 +0200 Message-ID: <87pqbprnre.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Subject: [kitten] SAML20 interop server available X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 12:41:39 -0000 Hello, I have set up a SMTP server with SAML20 support on "interop.josefsson.org" port 2001, for interop purposes. Currently it only knows about Feide's OpenIdP and ProtectNetwork's IdP, but send me metadata for your IdP and I'll add it. For details on how the server works, see: https://lists.gnu.org/archive/html/help-gsasl/2012-04/msg00001.html In the post you can see a step-by-step example of a succesful SAML20 authenticated login to the SMTP server. The server software is GNU SASL 1.7.3 and the SAML implementation is Lasso. The spec is still a bit unclear on whether the final client response is empty or '='. I believe we discussed this before, and came to the resolution that it should be '='. The document still says 'empty' in a few places, to be fixed in AUTH48 hopefully. /Simon From simo@redhat.com Tue Apr 3 06:46:51 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4753421F84B3 for ; Tue, 3 Apr 2012 06:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id om97FkJjcwbB for ; Tue, 3 Apr 2012 06:46:50 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2F95921F847C for ; Tue, 3 Apr 2012 06:46:48 -0700 (PDT) Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q33Dkk20021045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Apr 2012 09:46:46 -0400 Received: from [10.3.113.104] (ovpn-113-104.phx2.redhat.com [10.3.113.104]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q33DkjBf003754; Tue, 3 Apr 2012 09:46:45 -0400 From: Simo Sorce To: Simon Josefsson In-Reply-To: <87y5qdrocb.fsf@latte.josefsson.org> References: <87y5qdrocb.fsf@latte.josefsson.org> Content-Type: text/plain; charset="UTF-8" Organization: Red Hat, Inc. Date: Tue, 03 Apr 2012 09:46:45 -0400 Message-ID: <1333460805.22628.262.camel@willson.li.ssimo.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Cc: kitten@ietf.org Subject: Re: [kitten] Proposed GSS extension for explicit credential stores X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 13:46:51 -0000 On Tue, 2012-04-03 at 14:28 +0200, Simon Josefsson wrote: > Nico Williams writes: > > > Simo and I have a need for extensions for acquiring credentials from, > > and storing credentials into, an explicit credential store as opposed > > to the one implied by process credentials/context/environment. > > I have often needed this too. > > > The abstract API representation of this would probably be > > > > SET OF SEQUENCE { > > element_type_urn OCTET STRING, > > element OCTET STRING > > } > > It seems nice, but I haven't digested it fully yet. > > > URNs will be provided for at least the following: > > > > - ccache values > > Values will be of the form [:], such as > > the familiar "FILE:/tmp/somecc" but also "LSA:" and "CCAPI:...". > > > > - keytab values > > Same as with ccache values, but naming a keytab. > > > > We'll probably provide URNs for other store element types, such as: > > > > - PKCS#11 URI > > See http://tools.ietf.org/html/draft-pechanec-pkcs11uri-06 > > > > We have debated, but not reached a conclusion, other possible element > > types such as: > > > > - User-ID, username > > > > - AFS PAG > > I'd really like to see SAML SP metadata included here initially, and > would be willing to help with writing. For simplicity, you could have > multiple URns here, right? I'm thinking something like this: > > urn.ietf.kitten.saml.sp.metadata-file => > "/etc/myapp/sp-metadata.xml" > > urn.ietf.kitten.saml.sp.key-file => > "/etc/myapp/sp-key.pem" > > urn.ietf.kitten.saml.sp.cert-file => > "/etc/myapp/sp-cert.pem" > > urn.ietf.kitten.saml.sp.metadata => > " > urn.ietf.kitten.saml.sp.cert => > "-----BEGIN CERTIFICATE -----\nMII..." > > Alternatively, there could be a "struct" approach for SAML SP > credentials if you wanted to use only one URN for each credential, > however it gets a bit more ugly: > > urn.ietf.kitten.saml.sp => > "metadata_file=/etc/myapp/sp-metadata.xml, key_file=/etc/myapp/sp-key.pem, ..." > > Thoughts? Although values are opaque a rule we try to follow is to not put credentials directly in there, but always use files and paths for anything that is longer that a few hundred characters or unprintable. These strings are supposed to be stored in configuration files, and we do not want to force admins in a corner by requiring to set credentials in a config file that also needs to be readable to users that shouldn't have access to some of the credentials. This should be the guiding principle in defining the values. Simo. -- Simo Sorce * Red Hat, Inc * New York From nico@cryptonector.com Tue Apr 3 07:35:14 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A1521F8793 for ; Tue, 3 Apr 2012 07:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X64WYX7XSW6Q for ; Tue, 3 Apr 2012 07:35:11 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id B874E21F879E for ; Tue, 3 Apr 2012 07:35:04 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 7B77854073 for ; Tue, 3 Apr 2012 07:35:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=XPx3Ivjl04DEnkBFVD15D8pAGATc5a26BjxQJ/XtTaVi aAKNQojYAXQIF/qptEgpF2RTFU2mgT/1Wy6K7PQ114q7ujB2u6wXn4v5/HIPNXUH hpsXuTypoysO3XkRRF6vLIW+bbrBFmxJZYHmGBBDXKC8KzPTe194lyuuZc2g3Uw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=XBmRO7d813GaR5ZcVqHrvoS7VJI=; b=NsjFLrsWWDk fPbJab0Td61jWZIQZwtuECGz2e9xurB+blrbOZG2mILWby7QgHp7421kjFwcHS5l CPddyJifQJsVIhINDYigwSjoNHZ4RZ8mbMndTUDO7KJHUPKlRyBlzC9FQretLiNV H0eK/KsvMWAomVLJzpilBPHn7UiHI6s0= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 381DE5405B for ; Tue, 3 Apr 2012 07:35:03 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so5498130pbb.31 for ; Tue, 03 Apr 2012 07:35:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.219.3 with SMTP id pk3mr14254541pbc.34.1333463701098; Tue, 03 Apr 2012 07:35:01 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Tue, 3 Apr 2012 07:35:00 -0700 (PDT) In-Reply-To: <87y5qdrocb.fsf@latte.josefsson.org> References: <87y5qdrocb.fsf@latte.josefsson.org> Date: Tue, 3 Apr 2012 09:35:00 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] Proposed GSS extension for explicit credential stores X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 14:35:14 -0000 On Tue, Apr 3, 2012 at 7:28 AM, Simon Josefsson wrote= : >> URNs will be provided for at least the following: > I'd really like to see SAML SP metadata included here initially, and > would be willing to help with writing. =C2=A0For simplicity, you could ha= ve > multiple URns here, right? =C2=A0I'm thinking something like this: Yes, you can have multiple key/value pairs, and the keys are URNs. And you can have multiple key/value pairs with the same key, so I think we need to make the abstract type be SEQUENCE OF SEQUENCE { ... }. > =C2=A0urn.ietf.kitten.saml.sp.metadata-file =3D> > =C2=A0"/etc/myapp/sp-metadata.xml" Sure. > =C2=A0urn.ietf.kitten.saml.sp.key-file =3D> > =C2=A0"/etc/myapp/sp-key.pem" Sure. > =C2=A0urn.ietf.kitten.saml.sp.cert-file =3D> > =C2=A0"/etc/myapp/sp-cert.pem" Sure. > =C2=A0urn.ietf.kitten.saml.sp.metadata =3D> > =C2=A0" =C2=A0urn.ietf.kitten.saml.sp.cert =3D> > =C2=A0"-----BEGIN CERTIFICATE -----\nMII..." To repeat what Simo said, we shouldn't put secrets (and I know, a cert is not a secret, but the private key to go with it is) in configuration files. Secrets should go in separate files or HSMs. > Alternatively, there could be a "struct" approach for SAML SP > credentials if you wanted to use only one URN for each credential, > however it gets a bit more ugly: We want multiple key/value pairs, not just one. For example, it'd make sense to specify both, a keytab and a ccache, but we want separate key/value pairs for keytab and ccache. It also makes sense to specify multiple keytabs. > =C2=A0urn.ietf.kitten.saml.sp =3D> > =C2=A0"metadata_file=3D/etc/myapp/sp-metadata.xml, key_file=3D/etc/myapp/= sp-key.pem, ..." Sure. Nico -- From wmills@yahoo-inc.com Tue Apr 3 17:10:42 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036D011E8074 for ; Tue, 3 Apr 2012 17:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.999 X-Spam-Level: X-Spam-Status: No, score=-14.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlW9CuqCLn27 for ; Tue, 3 Apr 2012 17:10:41 -0700 (PDT) Received: from nm39-vm6.bullet.mail.bf1.yahoo.com (nm39-vm6.bullet.mail.bf1.yahoo.com [72.30.239.150]) by ietfa.amsl.com (Postfix) with SMTP id 1803B11E8103 for ; Tue, 3 Apr 2012 17:10:40 -0700 (PDT) Received: from [98.139.212.146] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 04 Apr 2012 00:10:40 -0000 Received: from [98.139.212.245] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 04 Apr 2012 00:10:40 -0000 Received: from [127.0.0.1] by omp1054.mail.bf1.yahoo.com with NNFMP; 04 Apr 2012 00:10:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 566687.20862.bm@omp1054.mail.bf1.yahoo.com Received: (qmail 96631 invoked by uid 60001); 4 Apr 2012 00:10:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1333498239; bh=TDO5f7SacwiSPwXe4GcBqElFo7VVheJDD+jSdFgRAwM=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=f0gdFwiB9be9p2knchqgA96SeUpBCH3QWcFJ8S4Os6tMeuhkpwMiyQ0Y2JCs5TFFBgb+ybDVbUZkfUsZ3CKhqeRxICI8UBVLoPgATRy8ROOwUIW/PBA0DSTBOPewa9QqgYIA69EJC+6iXfgNYofRhkvtUGr6N0K+EjhmLJ/A83U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DnlnsHcBgcs3PpSaSMj0yoN/YthONqAa5SCig+zmtQcLjhE2jjCEXatH3bmbib4MdsAyHcyVgZfMXLGGVLL04qG2ZSj+IpDT4je3DfUCwVLWMUG0SHlGZbk4Os5/O+p/veDOmf0yHzwaH5jAjwqsJgoznqUSwkXZQMd94+FfX9M=; X-YMail-OSG: pRtVWLIVM1nsk3wjRThsk16MYHi6fh3F7SYHy5R8U3gwnde 99aKdTDt0ptSzU5J5KhyuTLAB.GaS64c7y9bOzTqP_OtAsb48RlVAs7TFA8Y uyGHyaMq2QiZKjXqezhQPQIQ.J4a5rTtJeFA5ECT4wugQasoLar6uQyzCKzv xuULKAmdBAcjQvL3w2Y5IgGtvqkhuMhhlFnbOmkNgUI6zFANGZ9C7KML8iOQ BtjDViHEgQdfZ9qK2iO2OdNqGcQ5vjJtrKSnbALbms.Bbd7mqdOTsu5InfyN lsuBLRkJl3_7IrwpV_X8yg3X0jY7JZUtZCTyN0w5EsRTuReM0.UmTxoHYxzv EHxS_qDZQaw5hxx8.EykAyDw0uJMjLOzNNQWl1QJLhGyca8IUMJo4fz32uwj fbAAyWWLR4wlTZAM_ejg6AdAJePFwnOl8z5.A1.9OBjMHzYypkQ1n.58GRkL ocVcyO7qlfsUsbmxzKnvEVO5MJhZDV9tt91PNV6G98DqmPxjEBv_32IVyC3x qpmOyT8Kkd9pOrHmtEBDsIwLvyIRO692BqbA3lmHYyoXc2tT4kFK6jdmg8x5 C7aiyY31eVsnRIrGfDresWJqOGpr4f_9DWv7zNtQEeN1Oo.g.T51vMtx26rk UI.iajDQQ2o1LMPyo40J1.WbJRaGSowXzTkPSaejnlHMqMmjjv3p44olvo1H CKxQCgjE2YMxPqrKxVKX51.usXH4wsjuI_Wm_sJ.Npg-- Received: from [209.131.62.115] by web31804.mail.mud.yahoo.com via HTTP; Tue, 03 Apr 2012 17:10:39 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340979 Message-ID: <1333498239.81695.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Tue, 3 Apr 2012 17:10:39 -0700 (PDT) From: William Mills To: "kitten@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [kitten] Feedback from IETF #83 on the OAUTH/SASL-KRB draft X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 00:10:42 -0000 =0A=0AI went to IETF #83 specifically to get feedback (and I though a tenta= tive decision) on the question of whether the SASL message format currently= there which uses HTTP was a good idea or not.=A0 I did get a ton of good f= eedback in individual conversations, the conversation in the working group = itself was a little less lively.=0A=0AFrom the WG meeting:=0A-=A0=A0=A0 sev= eral folks promised to read deeper and bring comments back to the list.=0A-= =A0=A0=A0 Hannes' comment at the mic (my summary) was that given the many s= uccessful integrations against Google's XOAUTH that staying close to those = has great value for getting successful uptake, and that adapting the code t= hose clients use to new endpoints=A0=0A=0AFrom general feedback from random= folks:=0A-=A0=A0=A0 Many folks said HTTP is in fact very hard to parse cor= rectly if you have to parse it fully.=0A-=A0=A0=A0 Some folks felt existing= implementations close to a proposed spec are likely to add to successful a= doption.=0A-=A0=A0=A0 a few folks felt that it's reasonable to limit the st= uff that actually has to be parsed.=0A=0AThere are real difference between = the complextity needed for XOAUTH and for the proposed OAUTH mechanism.=A0 = XOAUTH does everything in the URL, where the OAUTH proposal=A0 I'll post he= re the Google XOAUTH SASL message format, and an example form the draft spe= c:=0A=0AFrom http://sites.google.com/site/oauthgoog/Home/oauthimap for XOAU= TH:=0A=0AFor example, before base64-encoding, the initial client request mi= ght look like this (with linebreaks added for clarity):=0A=0A(2-legged OAut= h)=0AGET https://mail.google.com/mail/b/someuser@example.com/imap/?xoauth_r= equestor_id=3Dsomeuser%40example.com=0A=A0=A0=A0 oauth_consumer_key=3D"exam= ple.com",=0A=A0=A0=A0 oauth_nonce=3D"4710307327925439451",=0A=A0=A0=A0 oaut= h_signature=3D"75%2BB63NbW2GdDMaOCEd%2Fy%2Fb%2B0Qk%3D",=0A=A0=A0=A0 oauth_s= ignature_method=3D"HMAC-SHA1",=0A=A0=A0=A0 oauth_timestamp=3D"1260933683",= =0A=A0=A0=A0 oauth_version=3D"1.0"=0A=0A=0A=0AFor the OAUTH mechanism a sim= ilar style signed request example is:=0AGET / HTTP/1.1=0AHost: server.examp= le.com=0AUser: user@example.com=0AAuthorization: MAC token=3D"h480djs93hd8"= ,timestamp=3D"137131200", nonce=3D"dj83hs9s",signature=3D"YTVjyNSujYs1WsDur= FnvFi4JK6o=3D"=0A=0A=0AThe OAUTH mechanism will require (as currently speci= fied) parsing of a Host, User, and Authorization header. The path and quer= y is actually ignored at present. Based on this message I'll be posing que= stions to the list.=0A=0ARegards,=0A=0A-bill=A0 From wmills@yahoo-inc.com Tue Apr 3 17:59:05 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E43221F85E1 for ; Tue, 3 Apr 2012 17:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8Cya5G4KJ-t for ; Tue, 3 Apr 2012 17:59:04 -0700 (PDT) Received: from nm29-vm3.bullet.mail.ne1.yahoo.com (nm29-vm3.bullet.mail.ne1.yahoo.com [98.138.91.159]) by ietfa.amsl.com (Postfix) with SMTP id 543A721F85DF for ; Tue, 3 Apr 2012 17:59:04 -0700 (PDT) Received: from [98.138.90.53] by nm29.bullet.mail.ne1.yahoo.com with NNFMP; 04 Apr 2012 00:59:00 -0000 Received: from [98.138.87.1] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 04 Apr 2012 00:59:00 -0000 Received: from [127.0.0.1] by omp1001.mail.ne1.yahoo.com with NNFMP; 04 Apr 2012 00:59:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 463054.49933.bm@omp1001.mail.ne1.yahoo.com Received: (qmail 72208 invoked by uid 60001); 4 Apr 2012 00:59:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1333501140; bh=/xzW32p9lF3EsXkt9QkFVB72fFsDRwM6VSF28trWiLM=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=VoKUy0veBmNGJGwC2aY2wqhoY9JriU5Qeh1OdQPSZRB6YEd6vHgeanyjaPUxljpGAPgGc9PuuY+aSH/HGy5dOdWN0kO1dC+3eCXptdjneD+SCypaaGgpZwkIYHWbO42+TOl3Bphp11pQb4G2CR0htY0rDdOy3mB2wpwmjWP21SM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=s6tIBk4SrheJNi9uZgsS1lTUDUdDfTbguhm0VgEW+rwAD2+2Spvbv2AgTv6BFb3xXrbwatrVwxsCYDp1AsTdOXY9ux0D+YoMFOu23BtAprs3DOrIIdBjngj0/676Ni/VtTRzXxGl1zMPL+0fkukIqXe+6E8KgxCvpFwnW5YFSxQ=; X-YMail-OSG: kYhG8KAVM1n2l7P_YNylPctfmPp6P9ZDHV3w4FWAQg7NE8Q VZIqVLjP6PeJ.1XNIszaY5EAn1uR8mT4qDf_7zyg.yrINUimJ3_VoLuE4siq vY0jnWcFaKa6.rNMNRnDge_HlJE.P.d.JUsteoh8xPKj3mvQLXEmyvjQv2oz HXMoFh3Pg6cjaohIMloKEBx.242.JO_sWcPyJXmH5fkestaWIYGcHA4Ux16X S7WBLBumT8N1D4A.FB4VqzxSL6ZcJcCKCo5CsCjfmpcuXGM2Lkv7T4d.6sUX dA7ROcjeme8YeJtLugSvdlfXp6JeaxnXEUq9pVDVCnQYFoQahVVuQbTlTpyf uvvzHvHmH6UXs9HP8IZgBTN_Klo_Sy8d2Vyi9v7T1_xq1ouAaiCxvMkLTUEt idVfDs3dFxpqQVStZAcRTSRazxK5weXb_jX_15_AQTfXZhS6piDQMIcYS.JO ncz.dAyRMjYjnVpfd5I9vm36Ay4v3SHQRrOQgHD1cdEIHs8kCVVL5lxK8bSI Moy33aruAO4WELQdUwbNGauLmVsvQL7Wkdwhz1KoWQhHt3WwbRVK6hbciK1z 8anLni_i3sD5m0T8CHeMui2FRGAYRbKk8QJVispYEGeMqynE9rOMKn_H2Yk9 3cX06k9KyMp8S0ey0AZX0rYZMPer8UUzXiHte7B21uzsF0ryuQ8DAmtCvHMy OV2Prk2pIvlVk3UP5WlMam4pYAS7Qbpo6HLQexcHlHQ-- Received: from [99.31.212.42] by web31807.mail.mud.yahoo.com via HTTP; Tue, 03 Apr 2012 17:58:59 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340979 References: <1333498239.81695.YahooMailNeo@web31804.mail.mud.yahoo.com> Message-ID: <1333501139.69852.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Tue, 3 Apr 2012 17:58:59 -0700 (PDT) From: William Mills To: "kitten@ietf.org" In-Reply-To: <1333498239.81695.YahooMailNeo@web31804.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-125733401-2107690963-1333501139=:69852" Subject: [kitten] OAUTH/SASL... to HTTP or not to HTTP, that is the question... X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 00:59:05 -0000 ---125733401-2107690963-1333501139=:69852 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The major question remaining for my draft is HTTP(like) or not for the SASL= message format?=A0 Please select one of the following:=0A=0A=0AA)=A0=A0=A0= The current message format is fine.=0AB)=A0=A0=A0 HTTP-like is OK as long = as we limit the insanity.=0AC)=A0=A0=A0 HTTP in any form is a deal breaker = for me.=A0 Give me something simple.=0AD)=A0=A0=A0 None of the above, and I= have a possible solution of my own to propose.=0A=0AFor B above it's likel= y that we'd say something like "The server MUST parse the Host, User, and A= uthorization headers and the server MAY discard anything else.=A0 The clien= t MUST NOT use any HTTP extensions such as compression and pipelining, and = SHOULD NOT use line continuations."=0A=0AThanks in advance for the input,= =0A=0A-bill=0A=0A=0A=0A=0A>________________________________=0A> From: Willi= am Mills =0A>To: "kitten@ietf.org" = =0A>Sent: Tuesday, April 3, 2012 5:10 PM=0A>Subject: [kitten] Feedback from= IETF #83 on the OAUTH/SASL-KRB draft=0A> =0A>=0A>=0A>I went to IETF #83 sp= ecifically to get feedback (and I though a tentative decision) on the quest= ion of whether the SASL message format currently there which uses HTTP was = a good idea or not.=A0 I did get a ton of good feedback in individual conve= rsations, the conversation in the working group itself was a little less li= vely.=0A>=0A>From the WG meeting:=0A>-=A0=A0=A0 several folks promised to r= ead deeper and bring comments back to the list.=0A>-=A0=A0=A0 Hannes' comme= nt at the mic (my summary) was that given the many successful integrations = against Google's XOAUTH that staying close to those has great value for get= ting successful uptake, and that adapting the code those clients use to new= endpoints=A0=0A>=0A>From general feedback from random folks:=0A>-=A0=A0=A0= Many folks said HTTP is in fact very hard to parse correctly if you have t= o parse it fully.=0A>-=A0=A0=A0 Some folks felt existing implementations cl= ose to a proposed spec are likely to add to successful adoption.=0A>-=A0=A0= =A0 a few folks felt that it's reasonable to limit the stuff that actually = has to be parsed.=0A>=0A>There are real difference between the complextity = needed for XOAUTH and for the proposed OAUTH mechanism.=A0 XOAUTH does ever= ything in the URL, where the OAUTH proposal=A0 I'll post here the Google XO= AUTH SASL message format, and an example form the draft spec:=0A>=0A>From h= ttp://sites.google.com/site/oauthgoog/Home/oauthimap for XOAUTH:=0A>=0A>For= example, before base64-encoding, the initial client request might look lik= e this (with linebreaks added for clarity):=0A>=0A>(2-legged OAuth)=0A>GET = https://mail.google.com/mail/b/someuser@example.com/imap/?xoauth_requestor_= id=3Dsomeuser%40example.com=0A>=A0=A0=A0 oauth_consumer_key=3D"example.com"= ,=0A>=A0=A0=A0 oauth_nonce=3D"4710307327925439451",=0A>=A0=A0=A0 oauth_sign= ature=3D"75%2BB63NbW2GdDMaOCEd%2Fy%2Fb%2B0Qk%3D",=0A>=A0=A0=A0 oauth_signat= ure_method=3D"HMAC-SHA1",=0A>=A0=A0=A0 oauth_timestamp=3D"1260933683",=0A>= =A0=A0=A0 oauth_version=3D"1.0"=0A>=0A>=0A>=0A>For the OAUTH mechanism a si= milar style signed request example is:=0A>GET / HTTP/1.1=0A>Host: server.ex= ample.com=0A>User: user@example.com=0A>Authorization: MAC token=3D"h480djs9= 3hd8",timestamp=3D"137131200", nonce=3D"dj83hs9s",signature=3D"YTVjyNSujYs1= WsDurFnvFi4JK6o=3D"=0A>=0A>=0A>The OAUTH mechanism will require (as current= ly specified) parsing of a Host, User, and Authorization header.=A0 The pat= h and query is actually ignored at present.=A0 Based on this message I'll b= e posing questions to the list.=0A>=0A>Regards,=0A>=0A>-bill=A0 =0A>_______= ________________________________________=0A>Kitten mailing list=0A>Kitten@i= etf.org=0A>https://www.ietf.org/mailman/listinfo/kitten=0A>=0A>=0A> ---125733401-2107690963-1333501139=:69852 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
The major question remaining for my draft is HTTP(like) or not for the SA= SL message format?  Please select one of the following:

A) = ;   The current message format is fine.
B)    HTTP-like is OK as long as we limit the in= sanity.
C)&= nbsp;   HTTP in any form is a deal breaker for me.  G= ive me something simple.
D)   = None of the above, and I have a possible solution of my own to propose.

For B above it's likely that we'd say something like "The server M= UST parse the Host, User, and Authorization headers and the server MAY discard anyth= ing else.  The client MUST NOT use any HTTP extensions such as compres= sion and pipelining, and SHOULD NOT use line continuations."

=
Thanks in advance for the input,

-bill<= br>

From: William Mills <wmills@yahoo-inc.com>
To: "kitten@ietf.org" <kitten= @ietf.org>
Sent: T= uesday, April 3, 2012 5:10 PM
Subject:<= /b> [kitten] Feedback from IETF #83 on the OAUTH/SASL-KRB draft
=

=0A

I went to IETF #83 specifically to get feedback (and= I though a tentative decision) on the question of whether the SASL message= format currently there which uses HTTP was a good idea or not.  I did= get a ton of good feedback in individual conversations, the conversation i= n the working group itself was a little less lively.

From the WG mee= ting:
-    several folks promised to read deeper and brin= g comments back to the list.
-    Hannes' comment at the = mic (my summary) was that given the many successful integrations against Go= ogle's XOAUTH that staying close to those has great value for getting succe= ssful uptake, and that adapting the code those clients use to new endpoints=  

From general feedback from random folks:
-  &nbs= p; Many folks said HTTP is in fact very hard to parse correctly if you have= to parse it fully.
-    Some folks felt existing impleme= ntations close to a proposed spec are likely to add to successful adoption.
-&nb= sp;   a few folks felt that it's reasonable to limit the stuff th= at actually has to be parsed.

There are real difference between the = complextity needed for XOAUTH and for the proposed OAUTH mechanism.  X= OAUTH does everything in the URL, where the OAUTH proposal  I'll post = here the Google XOAUTH SASL message format, and an example form the draft s= pec:

From http://sites.google.com/site/oauthgoog/Home/oauthimap for = XOAUTH:

For example, before base64-encoding, the initial client requ= est might look like this (with linebreaks added for clarity):

(2-leg= ged OAuth)
GET https://mail.google.com/mail/b/someuser@example.com/imap/?xoauth_requestor= _id=3Dsomeuser%40example.com
    oauth_consumer_key=3D"example.com",
    oauth_nonce=3D"4= 710307327925439451",
    oauth_signature=3D"75%2BB63NbW2G= dDMaOCEd%2Fy%2Fb%2B0Qk%3D",
    oauth_signature_method=3D= "HMAC-SHA1",
    oauth_timestamp=3D"1260933683",
 = ;   oauth_version=3D"1.0"



For the OAUTH mechanism = a similar style signed request example is:
GET / HTTP/1.1
Host: server.example.comUser: user@example.com
Authorization: MAC token=3D"h480djs93hd8",time= stamp=3D"137131200", nonce=3D"dj83hs9s",signature=3D"YTVjyNSujYs1WsDurFnvFi= 4JK6o=3D"


The OAUTH mechanism will require (as currently specifi= ed) parsing of a Host, User, and Authorization header.  The path and q= uery is actually ignored at present.  Based on this message I'll be po= sing questions to the list.

Regards,

-bill 
_____________________________= __________________
Kitten mailing list
Kitten@ietf.org
https://www.= ietf.org/mailman/listinfo/kitten


---125733401-2107690963-1333501139=:69852-- From nico@cryptonector.com Tue Apr 3 18:22:52 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1306111E810A for ; Tue, 3 Apr 2012 18:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIgr1j9H+ksu for ; Tue, 3 Apr 2012 18:22:48 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id E795E11E8072 for ; Tue, 3 Apr 2012 18:22:48 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 7726E1F0083 for ; Tue, 3 Apr 2012 18:22:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=D+P0pu0c6oD8z7iHStYgnAoeIdbcx5Ty+/Fi0igBXt5l s2XgwaBzwrm9hraK16+KiW/OzqUFBgenNdX10U33VlboUFfL9lH3m+kJfHKbmjD4 eo+rvF4MdCoRSPo1hzzXeukpwtECuDIIMMWPp6Os+gs/dgZ8hAsrGrn4+JKftsg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=otxRZuhR6iVyDtAyC4RcXbzH/AA=; b=WMk57zVLwQc 6IHnK01hzkTuyWCt87UzYNek4v5n/0uQx/crEhwchbc24Q8EmmtHRF9i2LCBoEBZ MpDgZOJVgQjvfHnPs3WM4jj5bJrL32dUe5ipDHOtQS1TaNo3UkpqwStXNe2EYUlV S5qjse8JUSEgkAyapmABGf8x3/r6xcrg= Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 4ACE31F001E for ; Tue, 3 Apr 2012 18:22:48 -0700 (PDT) Received: by dady13 with SMTP id y13so401681dad.27 for ; Tue, 03 Apr 2012 18:22:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.132.99 with SMTP id ot3mr32623820pbb.160.1333502567859; Tue, 03 Apr 2012 18:22:47 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Tue, 3 Apr 2012 18:22:47 -0700 (PDT) In-Reply-To: <1333501139.69852.YahooMailNeo@web31807.mail.mud.yahoo.com> References: <1333498239.81695.YahooMailNeo@web31804.mail.mud.yahoo.com> <1333501139.69852.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Tue, 3 Apr 2012 20:22:47 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] OAUTH/SASL... to HTTP or not to HTTP, that is the question... X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 01:22:52 -0000 On Tue, Apr 3, 2012 at 7:58 PM, William Mills wrote: > The major question remaining for my draft is HTTP(like) or not for the SA= SL > message format?=C2=A0 Please select one of the following: > > A)=C2=A0=C2=A0=C2=A0 The current message format is fine. > B)=C2=A0=C2=A0=C2=A0 HTTP-like is OK as long as we limit the insanity. > C)=C2=A0=C2=A0=C2=A0 HTTP in any form is a deal breaker for me.=C2=A0 Giv= e me something simple. > D)=C2=A0=C2=A0=C2=A0 None of the above, and I have a possible solution of= my own to > propose. I'm not an implementor of this protocol. Some day I might be. I'm OK with (B), but I'd prefer something saner than HTTP. JSON is almost perfectly sane (missing only a self-describing encoding of binary data). I want it to be simple, and I think HTTP-like-but-lite would be OK, but there's so much off-the-shelf code and experience with JSON... If there's running code that has been deployed then I think (B) is the best option. HTTP-like with HTTP insanity is a deal breaker though. So count me as in favor of (B) if there's not enough support for (C). Nico -- From simon@josefsson.org Wed Apr 4 00:47:55 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E1321F85B1 for ; Wed, 4 Apr 2012 00:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.661 X-Spam-Level: X-Spam-Status: No, score=-99.661 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTe6l0rL9oGf for ; Wed, 4 Apr 2012 00:47:54 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4C57C21F85AE for ; Wed, 4 Apr 2012 00:47:53 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q347ldg3009031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Apr 2012 09:47:41 +0200 From: Simon Josefsson To: William Mills References: <1333498239.81695.YahooMailNeo@web31804.mail.mud.yahoo.com> <1333501139.69852.YahooMailNeo__42841.0879838795$1333501152$gmane$org@web31807.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120404:kitten@ietf.org::iNgWwDyOUyoXaWvj:Ls4h X-Hashcash: 1:22:120404:wmills@yahoo-inc.com::Uxv9lfh7wRvylGhi:0bcrJ Date: Wed, 04 Apr 2012 09:47:38 +0200 In-Reply-To: <1333501139.69852.YahooMailNeo__42841.0879838795$1333501152$gmane$org@web31807.mail.mud.yahoo.com> (William Mills's message of "Tue, 3 Apr 2012 17:58:59 -0700 (PDT)") Message-ID: <87wr5wq6p1.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] OAUTH/SASL... to HTTP or not to HTTP, that is the question... X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 07:47:55 -0000 William Mills writes: > The major question remaining for my draft is HTTP(like) or not for the > SASL message format?  Please select one of the following: > > > A)    The current message format is fine. > B)    HTTP-like is OK as long as we limit the insanity. > C)    HTTP in any form is a deal breaker for me.  Give me something simple. > D)    None of the above, and I have a possible solution of my own to propose. > > For B above it's likely that we'd say something like "The server MUST > parse the Host, User, and Authorization headers and the server MAY > discard anything else.  The client MUST NOT use any HTTP extensions > such as compression and pipelining, and SHOULD NOT use line > continuations." > > Thanks in advance for the input, To get informed answers, I think we need to understand the implications of each answer. Let's say we invent a new format for SASL OAUTH. How much of a problem would that really be? Where would the complexity related to HTTP have to be implemented? Is it the server that would need to parse HTTP and transform it to something simpler? Is the client completely shielded? Looking at history, I believe one of the main reasons DIGEST-MD5 didn't quickly replace CRAM-MD5 was that DIGEST-MD5 was so complicated to implement interoperable, and that was primarily because it re-used HTTP syntax. So I don't think this is just a pet issue, it seems that if SASL wire syntax is too complicated, things won't get implemented. If I were to express a preference now I would lean towards B). However, if the implications of C) are not severe, I think it would make sense to use a simpler format. Then it becomes much easier to implement and analyse what goes on over the SASL wire. Without a good rationale, I would be strongly opposed to free-form HTTP as the SASL syntax. /Simon From simon@josefsson.org Wed Apr 4 00:53:52 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD9121F865C for ; Wed, 4 Apr 2012 00:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.723 X-Spam-Level: X-Spam-Status: No, score=-99.723 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ul8dJhUADezC for ; Wed, 4 Apr 2012 00:53:52 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id C25D421F8681 for ; Wed, 4 Apr 2012 00:53:51 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q347rehY009278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Apr 2012 09:53:41 +0200 From: Simon Josefsson To: William Mills References: <1333498239.81695.YahooMailNeo__7415.59771490774$1333498249$gmane$org@web31804.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120404:wmills@yahoo-inc.com::CfaU7aEXzDtGOGgG:8S68 X-Hashcash: 1:22:120404:kitten@ietf.org::c5ZfAP5hwdfbXCyR:NRIv Date: Wed, 04 Apr 2012 09:53:40 +0200 In-Reply-To: <1333498239.81695.YahooMailNeo__7415.59771490774$1333498249$gmane$org@web31804.mail.mud.yahoo.com> (William Mills's message of "Tue, 3 Apr 2012 17:10:39 -0700 (PDT)") Message-ID: <87sjgkq6ez.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] Feedback from IETF #83 on the OAUTH/SASL-KRB draft X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 07:53:52 -0000 William Mills writes: > For the OAUTH mechanism a similar style signed request example is: > GET / HTTP/1.1 > Host: server.example.com > User: user@example.com > Authorization: MAC token="h480djs93hd8",timestamp="137131200", > nonce="dj83hs9s",signature="YTVjyNSujYs1WsDurFnvFi4JK6o=" > > > The OAUTH mechanism will require (as currently specified) parsing of a > Host, User, and Authorization header. Why can't this be parsed before it is sent it over the SASL wire, and the necessary HTTP headers reconstructed on the other side? Is it because you want to offer compatibility with future OAuth extensions that would send additional HTTP headers? So by sending HTTP headers over SASL, you will automatically support those future extensions as well? I can understand that reason. Are there other reasons? /Simon From wmills@yahoo-inc.com Wed Apr 4 07:29:29 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8416721F871C for ; Wed, 4 Apr 2012 07:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4XHjdCiXHqF for ; Wed, 4 Apr 2012 07:29:28 -0700 (PDT) Received: from nm8.bullet.mail.bf1.yahoo.com (nm8.bullet.mail.bf1.yahoo.com [98.139.212.167]) by ietfa.amsl.com (Postfix) with SMTP id 8753B21F8711 for ; Wed, 4 Apr 2012 07:29:28 -0700 (PDT) Received: from [98.139.215.141] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 04 Apr 2012 14:29:27 -0000 Received: from [98.139.212.208] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 04 Apr 2012 14:29:27 -0000 Received: from [127.0.0.1] by omp1017.mail.bf1.yahoo.com with NNFMP; 04 Apr 2012 14:29:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 827047.21806.bm@omp1017.mail.bf1.yahoo.com Received: (qmail 24028 invoked by uid 60001); 4 Apr 2012 14:29:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1333549767; bh=v3rn+Jc50mf/JvlO2juv8vnYcuZO3t2lz7ZwoxDVwDs=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QLaTvUu9eKwMVl/uBwL6l5MS/le1BdKTfHNHwhmQbCLDcy1Xb1MhYSqP1l+cKlTIAthrwlK2v23VjdTtNSWOoIGoraOVW79PK954XdyLxOQtnmCMcerDwQGgf6dGLu1pKAlpwLPH2avlePgwibhmQsaGhxbKU4a8XQGDE5XSjME= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=OAqUWftT3n0eHL9JymcTOcEnBHOK9B/6VFEP5P72NLezkPdtvPUMaONFqDlvsEQInreceOcfgNgu3UZxsxYllRmm4GPFiWru2PNuKmTSOWCToiut84gscbAGbUMJf2CtjtTEwstD7HHagSZ/7tTOFzz2AzNaX31FqGBHRHxS7IA=; X-YMail-OSG: LJh2OIUVM1knIkZY6vqz3ITgiYlXWHp.EbeMfo9dNpiOhHV CwBkq5gY7JizCW3.Sym4lbvI3G_qtrgixx.ZOxOmZtn9cjFTXy3ozLHOvHdg .BUtl7CI2FCFGdIQm9GcffiV9JwLejFFWmR6xTiMXYDazolk3C68UWEPklEt 2YaZ2Ey8Qb4VErzt8TTcLn1wG.EZoeATSg4SH.y.WTR_0S3gG7g_GEMtaEnN eRckBDM4517dmbnKMkKRJ8Z0H.7uCBcLLVmJYLAHlfzNdlTYhUJv9JXS37Bk 4VuZswsHHOiGMj8JXE1ZrACpNlMKoNd6iSqwuBxWbbC6hk1JFOSU7cfmTjeY AwdwLX9hGF8YYVUvvUJ4eILS0rbtRA6bz5sukKeS7vlnkH8lgiog4QHWGzW. JbxMm6OF9A6.o43XS6A6Ed.A_KmC68PA- Received: from [99.31.212.42] by web31803.mail.mud.yahoo.com via HTTP; Wed, 04 Apr 2012 07:29:27 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340979 References: <1333498239.81695.YahooMailNeo__7415.59771490774$1333498249$gmane$org@web31804.mail.mud.yahoo.com> <87sjgkq6ez.fsf@latte.josefsson.org> Message-ID: <1333549767.22665.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Wed, 4 Apr 2012 07:29:27 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <87sjgkq6ez.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1502656925-1803440991-1333549767=:22665" Cc: "kitten@ietf.org" Subject: Re: [kitten] Feedback from IETF #83 on the OAUTH/SASL-KRB draft X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 14:29:29 -0000 --1502656925-1803440991-1333549767=:22665 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Simon,=0A=0AEasy extensibility for new auth profiles is the major/only reas= on for this.=A0 We can achieve this another way as well, we'd have to defin= e an extensible name/value pair mapping from HTTP data elements.=A0 Somewha= t simpler parsing, but adds a different layer of complexity.=0A=0A-bill=0A= =0A=0A=0A=0A>________________________________=0A> From: Simon Josefsson =0A>To: William Mills =0A>Cc: "kit= ten@ietf.org" =0A>Sent: Wednesday, April 4, 2012 12:53 AM= =0A>Subject: Re: Feedback from IETF #83 on the OAUTH/SASL-KRB draft=0A> =0A= >William Mills writes:=0A>=0A>> For the OAUTH mechan= ism a similar style signed request example is:=0A>> GET / HTTP/1.1=0A>> Hos= t: server.example.com=0A>> User: user@example.com=0A>> Authorization: MAC t= oken=3D"h480djs93hd8",timestamp=3D"137131200",=0A>> nonce=3D"dj83hs9s",sign= ature=3D"YTVjyNSujYs1WsDurFnvFi4JK6o=3D"=0A>>=0A>>=0A>> The OAUTH mechanism= will require (as currently specified) parsing of a=0A>> Host, User, and Au= thorization header.=0A>=0A>Why can't this be parsed before it is sent it ov= er the SASL wire, and=0A>the necessary HTTP headers reconstructed on the ot= her side?=0A>=0A>Is it because you want to offer compatibility with future = OAuth=0A>extensions that would send additional HTTP headers?=A0 So by sendi= ng HTTP=0A>headers over SASL, you will automatically support those future= =0A>extensions as well?=0A>=0A>I can understand that reason.=A0 Are there o= ther reasons?=0A>=0A>/Simon=0A>=0A>=0A> --1502656925-1803440991-1333549767=:22665 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Simon,

Easy extensibil= ity for new auth profiles is the major/only reason for this.  We can a= chieve this another way as well, we'd have to define an extensible name/val= ue pair mapping from HTTP data elements.  Somewhat simpler parsing, bu= t adds a different layer of complexity.

<= /div>
-bill

From: Simon Josefsson <simon@jos= efsson.org>
To: Wil= liam Mills <wmills@yahoo-inc.com>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Sent: Wednesday, April 4, 2012 1= 2:53 AM
Subject: Re: F= eedback from IETF #83 on the OAUTH/SASL-KRB draft

= =0AWilliam Mills <wmills@yahoo-inc.com> writes:

> = For the OAUTH mechanism a similar style signed request example is:
> = GET / HTTP/1.1
> Host: server.example.com
> User: user@example.com
> Au= thorization: MAC token=3D"h480djs93hd8",timestamp=3D"137131200",
> no= nce=3D"dj83hs9s",signature=3D"YTVjyNSujYs1WsDurFnvFi4JK6o=3D"
>
&g= t;
> The OAUTH mechanism will require (as currently specified) parsin= g of a
> Host, User, and Authorization header.

Why can't this = be parsed before it is sent it over the SASL wire, and
the necessary HTT= P headers reconstructed on the other side?

Is it because you want to= offer compatibility with future OAuth
extensions that would send additi= onal HTTP headers?  So by sending HTTP
headers over SASL, you will automatic= ally support those future
extensions as well?

I can understand th= at reason.  Are there other reasons?

/Simon


=
--1502656925-1803440991-1333549767=:22665-- From simon@josefsson.org Wed Apr 4 07:43:48 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABD321F87CD for ; Wed, 4 Apr 2012 07:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.785 X-Spam-Level: X-Spam-Status: No, score=-99.785 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzmCzVmRgOSW for ; Wed, 4 Apr 2012 07:43:48 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id A263321F8762 for ; Wed, 4 Apr 2012 07:43:47 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q34EhdtF028127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 4 Apr 2012 16:43:41 +0200 X-Hashcash: 1:22:120404:kitten@ietf.org::ZgEAJKNThgriaMZz:S0fh From: Simon Josefsson To: kitten@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Wed, 04 Apr 2012 16:43:39 +0200 Message-ID: <87obr7lfqc.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Subject: [kitten] GSS-API and timeouts X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 14:43:48 -0000 When implementing the GSS-API part of OPENID20/SAML20 I noticed that the processes can hang waiting for a long time. Server may want to wait one minute or more to allow a user to finish the IdP authentication. I think Nico discussed asynchronous GSS-API before. However it is a significant amount of work to specify and implement. I think it is simpler for applications to create a separate process or thread for the GSS-API part, and to enforce its own timeouts. Sometimes there are other reasons for having separate processes/threads anyway. Still, even an asynchronous interface may want to use some timeouts where authentication is no longer expected to ever finish. So it is not clear that an asynchronous interface is the solution to this problem. Does anyone have any thoughts on what a reasonable timeout should be? Or should GSS-API initiators and acceptors never timeout, but just hang indefinitely in case the authentication eventually completes? Of course, we could have a new GSS-API interface to enforce a timeout. For example: OM_uint32 gss_sec_context_timeout (OM_uint32 *minor_status, OM_uint32 timeout); or something more general, in case there are similar concerns for other functions: OM_uint32 gss_set_timeouts (OM_uint32 *minor_status, OM_uint32 sec_context_timeout, OM_uint32 micwrap_timeout); FWIW, in my implementation I'll probably use a 5 minute timeout or something like that. /Simon From wmills@yahoo-inc.com Wed Apr 4 07:44:37 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9287721F87CD for ; Wed, 4 Apr 2012 07:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.998 X-Spam-Level: X-Spam-Status: No, score=-16.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Lz2Bfs42zgy for ; Wed, 4 Apr 2012 07:44:36 -0700 (PDT) Received: from nm4.bullet.mail.bf1.yahoo.com (nm4.bullet.mail.bf1.yahoo.com [98.139.212.163]) by ietfa.amsl.com (Postfix) with SMTP id 6F7F721F8659 for ; Wed, 4 Apr 2012 07:44:36 -0700 (PDT) Received: from [98.139.215.140] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 04 Apr 2012 14:44:36 -0000 Received: from [98.139.212.209] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 04 Apr 2012 14:44:35 -0000 Received: from [127.0.0.1] by omp1018.mail.bf1.yahoo.com with NNFMP; 04 Apr 2012 14:44:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 975703.71792.bm@omp1018.mail.bf1.yahoo.com Received: (qmail 70044 invoked by uid 60001); 4 Apr 2012 14:44:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1333550675; bh=CjCJ+lPew1GPgxwZtq8WioxhKiWb0VFXIQ0bZ75kgpU=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=YzXatyCxICHnp2gq72h37EwqruqyId3H4w+5jfoE+NY15BDoNNCHvUMxXGg6iNJd3otmoc25nmp7YJXoLRMyeYujysss8sKQ9bu84yjprEFQ+4PjQOkVFGqrvbvQMNkBA1+25A7nm28lpjv21yMcQtsvwctRaYJ7xtTHDAXciiU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=jAht3yXYXWUDrf8xALOvdRsXvOak/b0dS8X5+FRNn2pM+hl4cvSCSMSSLKJVu1wme5nzA4sWpPZibPrvoyGTd0/S7mNuwuJaJ0OYFxJNQgmynhKwZVO/gt2CNcvpqnTePvQmkKa1k4Q5aYj8gVmZVvF3+ZvMgW3bjcz81qRdQS8=; X-YMail-OSG: tMnFt1UVM1muHWUYbJhwjFzzkSmkzzox3kbTwTHl7D_R_y2 YTnpo1_TvE0IZyrbpY4fvDEuw.quDH33G9dDxGVh9JLRhIMLgkLYXcLngQNW 2gVXcUq19nN__Bd64z4JKMLHIpxU9_phF1GrZcTUWu.E.32HVYrGSSonIP30 LOrnHDQMu1n_dv0W2T24SBcFjoKY.F5zgFm39vNYA2igKJpmfwMIxBbWx22d 7KxWNypxh5qb8J3ZcL9RVOrrK42vhmvePrqMebzwNMSjZZDQuIITOzTAn2cB 51LSs7nWx_I1Dw4Ykvgh94m1ipBYcFv0ZtCg2i2W8vrQzooDpuvpIyAmGUn5 ZC6ZGRGJcDJZokTdRMOBtTXNGshGbnIDdGmzLH79Wc_C07btlspB0YhjBJ2f Z.jI1_gJiLVewM2Fa1WJDzt8clyo- Received: from [99.31.212.42] by web31811.mail.mud.yahoo.com via HTTP; Wed, 04 Apr 2012 07:44:35 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340979 References: <1333498239.81695.YahooMailNeo@web31804.mail.mud.yahoo.com> <1333501139.69852.YahooMailNeo__42841.0879838795$1333501152$gmane$org@web31807.mail.mud.yahoo.com> <87wr5wq6p1.fsf@latte.josefsson.org> Message-ID: <1333550675.70008.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Wed, 4 Apr 2012 07:44:35 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <87wr5wq6p1.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="764183289-1723244725-1333550675=:70008" Cc: "kitten@ietf.org" Subject: Re: [kitten] OAUTH/SASL... to HTTP or not to HTTP, that is the question... X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 14:44:37 -0000 --764183289-1723244725-1333550675=:70008 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable One of the real takeaways for me from the IETF is that parsing HTTP is deep= deep water with sharks in it.=A0 Of the things we have to parse right now = the hairiest would be the authorization header because it may have multiple= authorization elements.=A0 Everything else is comparatively simple.=0A=0AT= he data elements we need are:=0A-=A0=A0=A0 Host=0A-=A0=A0=A0 port=0A-=A0=A0= =A0 Authorization header payload for the oauth profile=0A-=A0=A0=A0 usernam= e -- used for auth(zn) endpoint discovery only=0A-=A0=A0=A0 path+query stri= ng -- currently a stub of extensibility=0A-=A0=A0=A0 HTTP body-- currently = a stub of extensibility=0A=0AThe auth header payload is still going to have= to be parsed by the server as is I think.=A0 It's too complex to try to pr= ovide an arbitrary structured mapping for all cases and it's just an opport= unity for error.=0A=0AExtensibility can be done with an IANA registry of n/= v fields for the purpose.=A0 After that I'd probably choose a format like'N= ame ":" value CRLF' over JSON.=0A=0A=0A=0A=0A>_____________________________= ___=0A> From: Simon Josefsson =0A>To: William Mills =0A>Cc: "kitten@ietf.org" =0A>Sent: = Wednesday, April 4, 2012 12:47 AM=0A>Subject: Re: OAUTH/SASL... to HTTP or= not to HTTP, that is the question...=0A> =0A>William Mills writes:=0A>=0A>> The major question remaining for my draft is HTTP(= like) or not for the=0A>> SASL message format?=A0 Please select one of the = following:=0A>>=0A>>=0A>> A)=A0=A0=A0 The current message format is fine.= =0A>> B)=A0=A0=A0 HTTP-like is OK as long as we limit the insanity.=0A>> C)= =A0=A0=A0 HTTP in any form is a deal breaker for me.=A0 Give me something s= imple.=0A>> D)=A0=A0=A0 None of the above, and I have a possible solution o= f my own to propose.=0A>>=0A>> For B above it's likely that we'd say someth= ing like "The server MUST=0A>> parse the Host, User, and Authorization head= ers and the server MAY=0A>> discard anything else.=A0 The client MUST NOT u= se any HTTP extensions=0A>> such as compression and pipelining, and SHOULD = NOT use line=0A>> continuations."=0A>>=0A>> Thanks in advance for the input= ,=0A>=0A>To get informed answers, I think we need to understand the implica= tions=0A>of each answer.=A0 Let's say we invent a new format for SASL OAUTH= .=A0 How=0A>much of a problem would that really be?=A0 Where would the comp= lexity=0A>related to HTTP have to be implemented?=A0 Is it the server that = would=0A>need to parse HTTP and transform it to something simpler?=A0 Is th= e client=0A>completely shielded?=0A>=0A>Looking at history, I believe one o= f the main reasons DIGEST-MD5 didn't=0A>quickly replace CRAM-MD5 was that D= IGEST-MD5 was so complicated to=0A>implement interoperable, and that was pr= imarily because it re-used HTTP=0A>syntax.=A0 So I don't think this is just= a pet issue, it seems that if=0A>SASL wire syntax is too complicated, thin= gs won't get implemented.=0A>=0A>If I were to express a preference now I wo= uld lean towards B).=A0 However,=0A>if the implications of C) are not sever= e, I think it would make sense to=0A>use a simpler format.=A0 Then it becom= es much easier to implement and=0A>analyse what goes on over the SASL wire.= =A0 Without a good rationale, I=0A>would be strongly opposed to free-form H= TTP as the SASL syntax.=0A>=0A>/Simon=0A>=0A>=0A> --764183289-1723244725-1333550675=:70008 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
One of the real takeaways for me from the IETF is that parsing HTTP is de= ep deep water with sharks in it.  Of the things we have to parse right= now the hairiest would be the authorization header because it may have mul= tiple authorization elements.  Everything else is comparatively simple= .

The data elements we n= eed are:
-  &nb= sp; Host
-&= nbsp;   port
-    Authorization header payload for the oauth = profile
-&n= bsp;   username -- used for auth(zn) endpoint discovery only
-&nbs= p;   path+query string -- currently a stub of extensibility
-  &nb= sp; HTTP body -- currently a stub of extensibil= ity

The auth header payload is still going to have to be parsed by the= server as is I think.  It's too complex to try to provide an arbitrar= y structured mapping for all cases and it's just an opportunity for error.<= /span>

Extensibility can be done with an IANA registry of n/v fields for the p= urpose.  After that I'd probably choose a format like 'Name ":" value CRLF' over JSON.

From: Simon Josefsson <simon@josefsson.org><= br> To: William Mills <= wmills@yahoo-inc.com>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Sent: Wednesday, April 4, 2012 12:47 AM
= Subject: Re: OAUTH/SASL... t= o HTTP or not to HTTP, that is the question...

=0AWi= lliam Mills <wmills@yahoo-inc.com> writes:

> The m= ajor question remaining for my draft is HTTP(like) or not for the
> S= ASL message format?  Please select one of the following:
>
&g= t;
> A)    The current message format is fine.
>= B)    HTTP-like is OK as long as we limit the insanity.
= > C)    HTTP in any form is a deal breaker for me.  = Give me something simple.
> D)    None of the above, a= nd I have a possible solution of my own to propose.
>
> For B a= bove it's likely that we'd say something like "The server MUST
> pars= e the Host, User, and Authorization headers and the server MAY
> disc= ard anything else.  The client MUST NOT use any HTTP extensions
>= ; such as compression and pipelining, and SHOULD NOT use line
> continuations."
>
> Thanks in advance for the input,

To= get informed answers, I think we need to understand the implications
of= each answer.  Let's say we invent a new format for SASL OAUTH.  = How
much of a problem would that really be?  Where would the comple= xity
related to HTTP have to be implemented?  Is it the server that= would
need to parse HTTP and transform it to something simpler?  I= s the client
completely shielded?

Looking at history, I believe o= ne of the main reasons DIGEST-MD5 didn't
quickly replace CRAM-MD5 was th= at DIGEST-MD5 was so complicated to
implement interoperable, and that wa= s primarily because it re-used HTTP
syntax.  So I don't think this = is just a pet issue, it seems that if
SASL wire syntax is too complicate= d, things won't get implemented.

If I were to express a preference n= ow I would lean towards B).  However,
if the implications of C) are not severe, I think it would make sense to
use a simpler format.=   Then it becomes much easier to implement and
analyse what goes on= over the SASL wire.  Without a good rationale, I
would be strongly= opposed to free-form HTTP as the SASL syntax.

/Simon


--764183289-1723244725-1333550675=:70008-- From simon@josefsson.org Wed Apr 4 07:49:54 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935C921F852C for ; Wed, 4 Apr 2012 07:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.803 X-Spam-Level: X-Spam-Status: No, score=-99.803 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMeyBmc-HKNx for ; Wed, 4 Apr 2012 07:49:54 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id CA98621F851A for ; Wed, 4 Apr 2012 07:49:53 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q34Enjjv028361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 4 Apr 2012 16:49:47 +0200 X-Hashcash: 1:22:120404:kitten@ietf.org::PDEUZSY/bOGvQntU:GTmZ From: Simon Josefsson To: kitten@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Wed, 04 Apr 2012 16:49:45 +0200 Message-ID: <87k41vlfg6.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Subject: [kitten] OID DER for OPENID20/SAML20 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 14:49:54 -0000 Maybe this ought to have been in the specs since most people appear to compute them by hand, but it isn't. So the DER encoding of the OPENID20 OID that I'm using is: gss_OID_desc GSS_OPENID20_static = { 6, (void *) "\x2b\x06\x01\x05\x05\x10" }; and for SAML20 it is: gss_OID_desc GSS_SAML20_static = { 6, (void *) "\x2b\x06\x01\x05\x05\x11" }; If I prepend \x06 (tag for OID) and \x06 (length 06) I can DER decode the OIDs using e.g. 'dumpasn1' and it looks right. However, it would be good if someone else confirmed this independently (or at least as independently as can be hoped for since I have now posted my guess). /Simon From simon@josefsson.org Wed Apr 4 07:54:30 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7659B21F8693 for ; Wed, 4 Apr 2012 07:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.886 X-Spam-Level: X-Spam-Status: No, score=-98.886 tagged_above=-999 required=5 tests=[AWL=-0.836, BAYES_20=-0.74, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1zPqTs9a1Ng for ; Wed, 4 Apr 2012 07:54:30 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id AEEE321F8686 for ; Wed, 4 Apr 2012 07:54:29 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q34EsBTU028567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Apr 2012 16:54:13 +0200 From: Simon Josefsson To: "Cantor\, Scott" References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120404:kitten@ietf.org::b4/D8040x59AdO5/:CN9 X-Hashcash: 1:22:120404:cantor.2@osu.edu::s/IJp+6TSN3FRt6b:WGH X-Hashcash: 1:22:120404:jbasney@illinois.edu::hbwN6uFZ220jBBvW:1EHL X-Hashcash: 1:22:120404:nico@cryptonector.com::lOJ+5uhYTV74wOq9:8iyQ Date: Wed, 04 Apr 2012 16:54:11 +0200 In-Reply-To: (Scott Cantor's message of "Wed, 29 Feb 2012 00:41:34 +0000") Message-ID: <87fwcjlf8s.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 14:54:30 -0000 "Cantor, Scott" writes: > On 2/28/12 7:31 PM, "Nico Williams" wrote: >> >>The GSS-API does not permit empty tokens. I'm not sure if an initial >>context token that is empty but for the pseudo-ASN.1 header is OK. >>However, I think the right thing to do is to add one constant byte to >>this one token. > > I copied that text from the other SAML mechanism (though I don't see it > there literally anymore), and Simon ok'd it, so I would assume that it is > ok to omit the constant byte. If not, I'll specify something in the next > draft. I think leaving out it should work. Adding a dummy character is fine too. It doesn't matter. > Also, I'm not sure that OID is "official". In fact, I would guess it's > not. The SAML mech currently says in draft-09 that the mech OID is TBD, so > I would imagine this one is too. I can't honestly even say where it came > from. The OID is from my tree. We probably should use IANA's SMI OID number tree instead. /Simon From cantor.2@osu.edu Wed Apr 4 07:57:33 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFD121F86AA for ; Wed, 4 Apr 2012 07:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKEqVjH+Rx54 for ; Wed, 4 Apr 2012 07:57:32 -0700 (PDT) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7676021F86A6 for ; Wed, 4 Apr 2012 07:57:32 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q34EvKKv029543; Wed, 4 Apr 2012 10:57:29 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi id 14.01.0355.002; Wed, 4 Apr 2012 10:57:23 -0400 From: "Cantor, Scott" To: Simon Josefsson Thread-Topic: I-D Action: draft-ietf-kitten-sasl-saml-ec-01.txt Thread-Index: AQHNEnLg78TB1TdoGkqMbWexYen/QpaKwSqQ Date: Wed, 4 Apr 2012 14:57:22 +0000 Message-ID: References: <87fwcjlf8s.fsf@latte.josefsson.org> In-Reply-To: <87fwcjlf8s.fsf@latte.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.160.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 14:57:33 -0000 > > Also, I'm not sure that OID is "official". In fact, I would guess it's > > not. The SAML mech currently says in draft-09 that the mech OID is TBD,= so > > I would imagine this one is too. I can't honestly even say where it cam= e > > from. >=20 > The OID is from my tree. We probably should use IANA's SMI OID number > tree instead. Thanks, I was about to follow up and ask what I should do. Do I need to app= ly for an OID in some way? I should have a proposal hopefully soon on a SAML name type and I can updat= e the draft with the correct OID at that point. -- Scott From wmills@yahoo-inc.com Wed Apr 4 08:41:26 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B22F21F8581 for ; Wed, 4 Apr 2012 08:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.369 X-Spam-Level: X-Spam-Status: No, score=-15.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpCfRmsMg-CA for ; Wed, 4 Apr 2012 08:41:25 -0700 (PDT) Received: from nm13.bullet.mail.bf1.yahoo.com (nm13.bullet.mail.bf1.yahoo.com [98.139.212.172]) by ietfa.amsl.com (Postfix) with SMTP id C452A21F857D for ; Wed, 4 Apr 2012 08:41:24 -0700 (PDT) Received: from [98.139.215.140] by nm13.bullet.mail.bf1.yahoo.com with NNFMP; 04 Apr 2012 15:41:24 -0000 Received: from [98.139.212.201] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 04 Apr 2012 15:41:24 -0000 Received: from [127.0.0.1] by omp1010.mail.bf1.yahoo.com with NNFMP; 04 Apr 2012 15:41:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 210649.44218.bm@omp1010.mail.bf1.yahoo.com Received: (qmail 83859 invoked by uid 60001); 4 Apr 2012 15:41:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1333554083; bh=Uyixb41kkHhcrxI0V1O1EbK3Teg91P8PQxKlXDAF3r8=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=LsG+PdQLW/m+TSptIKZ//nEh6xQjhwDaVpnOp3C4TyD+2pFmO77g2bidO+Te2uc8W1ofWGSypSC50G/jXqzzLpnrm+/cEK0Ap2dq7OwqOuMmI9tqJPbtl4Ct/5d2Y85o5PcuAMUWmWi0F0Hwh2c7DKqDxj8bkC/eaWtXUQFCSVs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=PAuJmCfo1hY7WZtIOqRcjzidZwM5rY2w6xgt53zEQm0g8v6vdt0NdIwwXmFtdpUwmP0DdIOlLkdS+DyBVjaKTjsPRM2mLqrdF2rLIL0fiZe7tTofPerRJoEBipuiWH33C76ofrMj0eRuhhiPOD6YtJ/Dfdjn2aPYT/+s9i/0x7A=; X-YMail-OSG: HR97fskVM1m8zuO2OU3ggALXiT3SCR0CbQ.ZDNw6.RiTpKO agDWwbmSSB9f5OoN1P7PfnWj_3M._cX16SzYGNTlzY7LyqE606dkc9c.V6Le XKABzKBW4yoz8GH2hcJah.gSnfaIJdMp1iN07XxDTm.AnMauYDdIKm1h_qU1 EeRYBUa81t4J3jWx3jY0XYX8rvyR8HeT37XGUhm75LmT6ooAoa_CHliscLmK yfzDRt0cjG4YNSfbh90k6bMLwsQfa5kCdKAVcXuQaIbdcZq9JYRV7rQULFQ3 DUTuvg6p4096v9ziVtFZulJs1xLZi_w5NsJvRQ1Ty_qqSvBoTVvOoqX9Wo8z a5RSiIlebIAadgiEwOqhS1bZTE9fAZb52rolYmTX4h8ys_SOzNJAJMNlVrov atJ2z3evVWiqDKHe.wIEemQr3A8q_zmNfm3ocxP3Bp6OIEJSAFg-- Received: from [209.131.62.115] by web31804.mail.mud.yahoo.com via HTTP; Wed, 04 Apr 2012 08:41:23 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340979 References: <87obr7lfqc.fsf@latte.josefsson.org> Message-ID: <1333554083.71760.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Wed, 4 Apr 2012 08:41:23 -0700 (PDT) From: William Mills To: Simon Josefsson , "kitten@ietf.org" In-Reply-To: <87obr7lfqc.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="835683298-493646663-1333554083=:71760" Subject: Re: [kitten] GSS-API and timeouts X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 15:41:26 -0000 --835683298-493646663-1333554083=:71760 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0AAs a result of the OpenID flow/redirect don't you get a complete cred= ential that can be used to finish the process?=A0 Can't you connect again, = get a challenge perhaps, submit that completed credential and be done?=A0 T= hat's very similar to what I did in the OAUTH/SASL thing, so I'm replaying = my one trick :)=0A=0A=0A=0A=0A=0A=0A>________________________________=0A> F= rom: Simon Josefsson =0A>To: kitten@ietf.org =0A>Sent:= Wednesday, April 4, 2012 7:43 AM=0A>Subject: [kitten] GSS-API and timeouts= =0A> =0A>When implementing the GSS-API part of OPENID20/SAML20 I noticed th= at the=0A>processes can hang waiting for a long time.=A0 Server may want to= wait one=0A>minute or more to allow a user to finish the IdP authenticatio= n.=0A>=0A>I think Nico discussed asynchronous GSS-API before.=A0 However it= is a=0A>significant amount of work to specify and implement.=A0 I think it= is=0A>simpler for applications to create a separate process or thread for = the=0A>GSS-API part, and to enforce its own timeouts.=A0 Sometimes there ar= e=0A>other reasons for having separate processes/threads anyway.=0A>=0A>Sti= ll, even an asynchronous interface may want to use some timeouts=0A>where a= uthentication is no longer expected to ever finish.=A0 So it is not=0A>clea= r that an asynchronous interface is the solution to this problem.=0A>=0A>Do= es anyone have any thoughts on what a reasonable timeout should be?=0A>=0A>= Or should GSS-API initiators and acceptors never timeout, but just hang=0A>= indefinitely in case the authentication eventually completes?=0A>=0A>Of cou= rse, we could have a new GSS-API interface to enforce a timeout.=0A>For exa= mple:=0A>=0A>=A0 =A0 OM_uint32=0A>=A0 =A0 gss_sec_context_timeout (OM_uin= t32 *minor_status,=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 OM_uint32 timeout);=0A>=0A>or something more general, in case there= are similar concerns for other=0A>functions:=0A>=0A>=0A>=A0 =A0 OM_uint32= =0A>=A0 =A0 gss_set_timeouts (OM_uint32 *minor_status,=0A>=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 OM_uint32 sec_context_timeout,=0A>=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 OM_uint32 micwrap_timeout);=0A>=0A>FWIW, i= n my implementation I'll probably use a 5 minute timeout or=0A>something li= ke that.=0A>=0A>/Simon=0A>_______________________________________________= =0A>Kitten mailing list=0A>Kitten@ietf.org=0A>https://www.ietf.org/mailman/= listinfo/kitten=0A>=0A>=0A> --835683298-493646663-1333554083=:71760 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

=
As a result of the OpenID flow/redirect don't= you get a complete credential that can be used to finish the process? = ; Can't you connect again, get a challenge perhaps, submit that completed c= redential and be done?  That's very similar to what I did in the OAUTH= /SASL thing, so I'm replaying my one trick :)



From:<= /b> Simon Josefsson <simon@josefsson.org>
To: kitten@ietf.org
Sent: Wednesday, April 4, 2012 7:43 AM
Subject: [kitten] GSS-API and timeouts

=0AWhen implementing the GSS-API part of OPENID20/SAM= L20 I noticed that the
processes can hang waiting for a long time. = Server may want to wait one
minute or more to allow a user to finish th= e IdP authentication.

I think Nico discussed asynchronous GSS-API be= fore.  However it is a
significant amount of work to specify and im= plement.  I think it is
simpler for applications to create a separa= te process or thread for the
GSS-API part, and to enforce its own timeou= ts.  Sometimes there are
other reasons for having separate processe= s/threads anyway.

Still, even an asynchronous interface may want to = use some timeouts
where authentication is no longer expected to ever fin= ish.  So it is not
clear that an asynchronous interface is the solu= tion to this problem.

Does anyone have any thoughts on what a reason= able timeout should be?

Or should GSS-API initiators and acceptors n= ever timeout, but just hang
indefinitely in case the authentication eventually completes?=

Of course, we could have a new GSS-API interface to enforce a timeo= ut.
For example:

    OM_uint32
    gss_s= ec_context_timeout (OM_uint32 *minor_status,
       =                     &nbs= p; OM_uint32 timeout);

or something more general, in case there are = similar concerns for other
functions:


    OM_uint3= 2
    gss_set_timeouts (OM_uint32 *minor_status,
  &n= bsp;                   OM_uin= t32 sec_context_timeout,
             = ;         OM_uint32 micwrap_timeout);

FWIW, in = my implementation I'll probably use a 5 minute timeout or
something like that.

/Simon
_______________________________________________
= Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listi= nfo/kitten


--835683298-493646663-1333554083=:71760-- From simo@redhat.com Wed Apr 4 08:49:01 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A3721F8779 for ; Wed, 4 Apr 2012 08:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUDpktFret7e for ; Wed, 4 Apr 2012 08:49:01 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id EDB9F21F8772 for ; Wed, 4 Apr 2012 08:49:00 -0700 (PDT) Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q34Fn0CA011045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Apr 2012 11:49:00 -0400 Received: from [10.3.113.104] (ovpn-113-104.phx2.redhat.com [10.3.113.104]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q34Fmw3C028574; Wed, 4 Apr 2012 11:48:59 -0400 From: Simo Sorce To: Simon Josefsson In-Reply-To: <87obr7lfqc.fsf@latte.josefsson.org> References: <87obr7lfqc.fsf@latte.josefsson.org> Content-Type: text/plain; charset="UTF-8" Organization: Red Hat, Inc. Date: Wed, 04 Apr 2012 11:48:58 -0400 Message-ID: <1333554538.22628.292.camel@willson.li.ssimo.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Cc: kitten@ietf.org Subject: Re: [kitten] GSS-API and timeouts X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 15:49:01 -0000 On Wed, 2012-04-04 at 16:43 +0200, Simon Josefsson wrote: > When implementing the GSS-API part of OPENID20/SAML20 I noticed that the > processes can hang waiting for a long time. Server may want to wait one > minute or more to allow a user to finish the IdP authentication. > > I think Nico discussed asynchronous GSS-API before. However it is a > significant amount of work to specify and implement. I think it is > simpler for applications to create a separate process or thread for the > GSS-API part, and to enforce its own timeouts. Sometimes there are > other reasons for having separate processes/threads anyway. > > Still, even an asynchronous interface may want to use some timeouts > where authentication is no longer expected to ever finish. So it is not > clear that an asynchronous interface is the solution to this problem. > > Does anyone have any thoughts on what a reasonable timeout should be? > > Or should GSS-API initiators and acceptors never timeout, but just hang > indefinitely in case the authentication eventually completes? > > Of course, we could have a new GSS-API interface to enforce a timeout. > For example: > > OM_uint32 > gss_sec_context_timeout (OM_uint32 *minor_status, > OM_uint32 timeout); > > or something more general, in case there are similar concerns for other > functions: > > > OM_uint32 > gss_set_timeouts (OM_uint32 *minor_status, > OM_uint32 sec_context_timeout, > OM_uint32 micwrap_timeout); > > FWIW, in my implementation I'll probably use a 5 minute timeout or > something like that. The problem I see with this kind of calls is that they affect the whole process. What if you have 2 libraries with conflicting needs and both use gssapi ? Simo. -- Simo Sorce * Red Hat, Inc * New York From nico@cryptonector.com Wed Apr 4 09:31:27 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0789D21F845A for ; Wed, 4 Apr 2012 09:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.575 X-Spam-Level: X-Spam-Status: No, score=-1.575 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maMcGjOVv7d0 for ; Wed, 4 Apr 2012 09:31:26 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2A821F8417 for ; Wed, 4 Apr 2012 09:31:26 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 5BD2E1E07C for ; Wed, 4 Apr 2012 09:31:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=mRH9fYM9T5t7lta/9nmnc w67RphHtoylTaNU7Fkakhi+Pva2yYSGQAo0gJTImq8Ac4Y2JtsY8v7jIbea50BJ1 5+3ghwaLK/hT632LWTUyMt6uXl2BrBwla7p17ncOKipMw7uBM78KCl4Yidauqy5x NW71pHMuaUriof7oKuM4o8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=GNlVVdKPrgzyGPosNcXA uzOq1L0=; b=QfZTm+pi/tSJONBlPfxwDSoMPy1Ps1HrOGttGQ1ur4h0bDAcVMEs eBmNbd+BP+86yE4WTMvOFyzFhjjCkEqAaSPu944Nr0QWp1LVz8bUuBj6WBwgGBHc kSWg0vdbHEhWB7vhJFjsG4oegc5ATZdVgYtlaZ7gJ/qekxKtlghIjCE= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 23EA41E078 for ; Wed, 4 Apr 2012 09:31:18 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so452922pbb.31 for ; Wed, 04 Apr 2012 09:31:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.135.40 with SMTP id pp8mr38949905pbb.13.1333557077371; Wed, 04 Apr 2012 09:31:17 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Wed, 4 Apr 2012 09:31:17 -0700 (PDT) In-Reply-To: <87obr7lfqc.fsf@latte.josefsson.org> References: <87obr7lfqc.fsf@latte.josefsson.org> Date: Wed, 4 Apr 2012 11:31:17 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] GSS-API and timeouts X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 16:31:27 -0000 If you don't want to tackle async init/accept_sec_context now then I suggest that you use threads and thread cancellation. Nico -- From alexey.melnikov@isode.com Wed Apr 4 09:55:22 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BC521F876F for ; Wed, 4 Apr 2012 09:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.103 X-Spam-Level: X-Spam-Status: No, score=-102.103 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGaiC38tvrHq for ; Wed, 4 Apr 2012 09:55:21 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 77E7821F876C for ; Wed, 4 Apr 2012 09:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1333558520; d=isode.com; s=selector; i=@isode.com; bh=oVJWDscgXBkcCSZGIFqkNkygfWKezu4PEhdHrita9+U=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=bbzZk/UAE4fjJh7uMmhCl5LUHlpZE6srAOM12pjFd04G58OpxyPZXLVAu4dLhCBaJcTJ3b zZs5t5aVpX4+Hi0VM6BSedbS+q6/lUw06v5I1O0CmjS4h1s7QoV5m6lGiuyOjh545A8jvp 2iWlG01JPaDUxJZ/X8N5xOCQxiHxlKk=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 4 Apr 2012 17:55:20 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F7C7CF4.9070502@isode.com> Date: Wed, 04 Apr 2012 17:55:16 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Simon Josefsson References: <87k41vlfg6.fsf@latte.josefsson.org> In-Reply-To: <87k41vlfg6.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] OID DER for OPENID20/SAML20 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 16:55:22 -0000 On 04/04/2012 15:49, Simon Josefsson wrote: > Maybe this ought to have been in the specs since most people appear to > compute them by hand, but it isn't. IMHO, this would be a fine addition to the specs. > So the DER encoding of the OPENID20 > OID that I'm using is: > > gss_OID_desc GSS_OPENID20_static = { > 6, (void *) "\x2b\x06\x01\x05\x05\x10" > }; > > and for SAML20 it is: > > gss_OID_desc GSS_SAML20_static = { > 6, (void *) "\x2b\x06\x01\x05\x05\x11" > }; > > If I prepend \x06 (tag for OID) and \x06 (length 06) I can DER decode > the OIDs using e.g. 'dumpasn1' and it looks right. > > However, it would be good if someone else confirmed this independently > (or at least as independently as can be hoped for since I have now > posted my guess). From simon@josefsson.org Wed Apr 4 10:12:23 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2356E21F87E8 for ; Wed, 4 Apr 2012 10:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.723 X-Spam-Level: X-Spam-Status: No, score=-99.723 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTzT6I5Fn0Jx for ; Wed, 4 Apr 2012 10:12:22 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8633821F87E6 for ; Wed, 4 Apr 2012 10:12:21 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q34HCBTR002566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Apr 2012 19:12:13 +0200 From: Simon Josefsson To: "Cantor\, Scott" References: <87fwcjlf8s.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120404:cantor.2@osu.edu::+B3XnQ+1JIiB2oLp:1KQN X-Hashcash: 1:22:120404:kitten@ietf.org::nMEW2rZNyOvci5C+:qbtY Date: Wed, 04 Apr 2012 19:12:11 +0200 In-Reply-To: (Scott Cantor's message of "Wed, 4 Apr 2012 14:57:22 +0000") Message-ID: <87pqbnjuac.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 17:12:23 -0000 "Cantor, Scott" writes: >> > Also, I'm not sure that OID is "official". In fact, I would guess it's >> > not. The SAML mech currently says in draft-09 that the mech OID is TBD, so >> > I would imagine this one is too. I can't honestly even say where it came >> > from. >> >> The OID is from my tree. We probably should use IANA's SMI OID number >> tree instead. > > Thanks, I was about to follow up and ask what I should do. Do I need > to apply for an OID in some way? IANA will allocate it for us, I have updated the document with new instructions: https://gitorious.org/ietf-saml20ec/ietf-saml20ec/commit/1c5ae6c41098e29f7749800a2c08f85e4afa1731/diffs/c22af59c283f50a1a2c5ef8df6eff65f4b309b82 For test purposes, it is fine to use 1.3.6.1.4.1.11591.4.6 meanwhile. The registry is here (search for "SMI Security for Mechanism Codes"): https://www.iana.org/assignments/smi-numbers /Simon From simon@josefsson.org Wed Apr 4 10:16:06 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F2121F87EB for ; Wed, 4 Apr 2012 10:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.742 X-Spam-Level: X-Spam-Status: No, score=-99.742 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+xx8qLEbiHb for ; Wed, 4 Apr 2012 10:16:05 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 32BFB21F87E8 for ; Wed, 4 Apr 2012 10:16:04 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q34HFtkJ002776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Apr 2012 19:15:56 +0200 From: Simon Josefsson To: William Mills References: <87obr7lfqc.fsf@latte.josefsson.org> <1333554083.71760.YahooMailNeo__8959.87156914107$1333554099$gmane$org@web31804.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120404:wmills@yahoo-inc.com::IBedanPU6gEvqkIz:BmMs X-Hashcash: 1:22:120404:kitten@ietf.org::vFl76FlzTXTCRauX:XfHs Date: Wed, 04 Apr 2012 19:15:54 +0200 In-Reply-To: <1333554083.71760.YahooMailNeo__8959.87156914107$1333554099$gmane$org@web31804.mail.mud.yahoo.com> (William Mills's message of "Wed, 4 Apr 2012 08:41:23 -0700 (PDT)") Message-ID: <87limbju45.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] GSS-API and timeouts X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 17:16:06 -0000 William Mills writes: > As a result of the OpenID flow/redirect don't you get a complete > credential that can be used to finish the process?  Can't you connect > again, get a challenge perhaps, submit that completed credential and > be done?  That's very similar to what I did in the OAUTH/SASL thing, > so I'm replaying my one trick :) The problem is that the browser interaction in OPENID20/SAML20 can take a long time because it is interactive, and the server doesn't know when to stop waiting. /Simon > > > > > > >>________________________________ >> From: Simon Josefsson >>To: kitten@ietf.org >>Sent: Wednesday, April 4, 2012 7:43 AM >>Subject: [kitten] GSS-API and timeouts >> >>When implementing the GSS-API part of OPENID20/SAML20 I noticed that the >>processes can hang waiting for a long time.  Server may want to wait one >>minute or more to allow a user to finish the IdP authentication. >> >>I think Nico discussed asynchronous GSS-API before.  However it is a >>significant amount of work to specify and implement.  I think it is >>simpler for applications to create a separate process or thread for the >>GSS-API part, and to enforce its own timeouts.  Sometimes there are >>other reasons for having separate processes/threads anyway. >> >>Still, even an asynchronous interface may want to use some timeouts >>where authentication is no longer expected to ever finish.  So it is not >>clear that an asynchronous interface is the solution to this problem. >> >>Does anyone have any thoughts on what a reasonable timeout should be? >> >>Or should GSS-API initiators and acceptors never timeout, but just hang >>indefinitely in case the authentication eventually completes? >> >>Of course, we could have a new GSS-API interface to enforce a timeout. >>For example: >> >>    OM_uint32 >>    gss_sec_context_timeout (OM_uint32 *minor_status, >>                              OM_uint32 timeout); >> >>or something more general, in case there are similar concerns for other >>functions: >> >> >>    OM_uint32 >>    gss_set_timeouts (OM_uint32 *minor_status, >>                      OM_uint32 sec_context_timeout, >>                      OM_uint32 micwrap_timeout); >> >>FWIW, in my implementation I'll probably use a 5 minute timeout or >>something like that. >> >>/Simon >>_______________________________________________ >>Kitten mailing list >>Kitten@ietf.org >>https://www.ietf.org/mailman/listinfo/kitten >> >> >> > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From simon@josefsson.org Wed Apr 4 10:19:44 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88EC21F8750 for ; Wed, 4 Apr 2012 10:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.757 X-Spam-Level: X-Spam-Status: No, score=-99.757 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TuxABj+W4T9 for ; Wed, 4 Apr 2012 10:19:44 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id B08EF21F8595 for ; Wed, 4 Apr 2012 10:19:43 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q34HJRf0002821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Apr 2012 19:19:29 +0200 From: Simon Josefsson To: Simo Sorce References: <87obr7lfqc.fsf@latte.josefsson.org> <1333554538.22628.292.camel__5672.95260630107$1333554546$gmane$org@willson.li.ssimo.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120404:simo@redhat.com::Zc+/8p5kNY8qg9Hk:46Ri X-Hashcash: 1:22:120404:kitten@ietf.org::KdokMlsHcGvgLgOy:+Rbf Date: Wed, 04 Apr 2012 19:19:27 +0200 In-Reply-To: <1333554538.22628.292.camel__5672.95260630107$1333554546$gmane$org@willson.li.ssimo.org> (Simo Sorce's message of "Wed, 04 Apr 2012 11:48:58 -0400") Message-ID: <87hawzjty8.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] GSS-API and timeouts X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 17:19:44 -0000 Simo Sorce writes: >> Of course, we could have a new GSS-API interface to enforce a timeout. >> For example: >> >> OM_uint32 >> gss_sec_context_timeout (OM_uint32 *minor_status, >> OM_uint32 timeout); >> >> or something more general, in case there are similar concerns for other >> functions: >> >> >> OM_uint32 >> gss_set_timeouts (OM_uint32 *minor_status, >> OM_uint32 sec_context_timeout, >> OM_uint32 micwrap_timeout); >> >> FWIW, in my implementation I'll probably use a 5 minute timeout or >> something like that. > > The problem I see with this kind of calls is that they affect the whole > process. What if you have 2 libraries with conflicting needs and both > use gssapi ? Yeah, it is not optimal. We could make it take a 'gss_ctx_id_t' parameter so the timeout is just for a particular context, but then there is no way to specify a timeout for the initial call that generate the gss_ctx_id_t. Maybe this is a non-issue. We'll see how it works in practice. /Simon From simon@josefsson.org Wed Apr 4 10:21:16 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E4621F8750 for ; Wed, 4 Apr 2012 10:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.77 X-Spam-Level: X-Spam-Status: No, score=-99.77 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84vbqhAvgYDq for ; Wed, 4 Apr 2012 10:21:15 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 45B6921F8595 for ; Wed, 4 Apr 2012 10:21:15 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q34HKrD0003055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Apr 2012 19:20:54 +0200 From: Simon Josefsson To: Nico Williams References: <87obr7lfqc.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120404:kitten@ietf.org::+VfsRs7iUblulVAi:4zJG X-Hashcash: 1:22:120404:nico@cryptonector.com::/iRHilY+TQjYDgXR:3wPL Date: Wed, 04 Apr 2012 19:20:52 +0200 In-Reply-To: (Nico Williams's message of "Wed, 4 Apr 2012 11:31:17 -0500") Message-ID: <87d37njtvv.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] GSS-API and timeouts X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 17:21:16 -0000 Nico Williams writes: > If you don't want to tackle async init/accept_sec_context now then I > suggest that you use threads and thread cancellation. And not have any timeout in the implementation of the mechanism itself? /Simon From simon@josefsson.org Wed Apr 4 10:26:25 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F8F21F855B for ; Wed, 4 Apr 2012 10:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.78 X-Spam-Level: X-Spam-Status: No, score=-99.78 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-QUgLhNEkrp for ; Wed, 4 Apr 2012 10:26:24 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4B53321F855A for ; Wed, 4 Apr 2012 10:26:24 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q34HQC55003263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Apr 2012 19:26:14 +0200 From: Simon Josefsson To: Alexey Melnikov References: <87k41vlfg6.fsf@latte.josefsson.org> <4F7C7CF4.9070502__14269.8731193834$1333558527$gmane$org@isode.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120404:kitten@ietf.org::5nVscVDfbqb20lkF:EPX X-Hashcash: 1:22:120404:alexey.melnikov@isode.com::Mra8uM84QU1Qrcc5:4u49 Date: Wed, 04 Apr 2012 19:26:12 +0200 In-Reply-To: <4F7C7CF4.9070502__14269.8731193834$1333558527$gmane$org@isode.com> (Alexey Melnikov's message of "Wed, 04 Apr 2012 17:55:16 +0100") Message-ID: <878vibjtmz.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] OID DER for OPENID20/SAML20 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 17:26:25 -0000 Alexey Melnikov writes: > On 04/04/2012 15:49, Simon Josefsson wrote: >> Maybe this ought to have been in the specs since most people appear to >> compute them by hand, but it isn't. > IMHO, this would be a fine addition to the specs. I agree. We still have an opportunity to add it in AUTH48, how about this for SAML20: OLD: The GSS-API mechanism OID for SAML is 1.3.6.1.5.5.17 (see Section 7.2 for more information). NEW: The GSS-API mechanism OID for SAML is 1.3.6.1.5.5.17 (see Section 7.2 for more information). The DER encoding of the OID is 0x2b 0x06 0x01 0x05 0x05 0x11. I'd feel more comfortable about this if someone could confirm the DER encoding though. /Simon >> So the DER encoding of the OPENID20 >> OID that I'm using is: >> >> gss_OID_desc GSS_OPENID20_static = { >> 6, (void *) "\x2b\x06\x01\x05\x05\x10" >> }; >> >> and for SAML20 it is: >> >> gss_OID_desc GSS_SAML20_static = { >> 6, (void *) "\x2b\x06\x01\x05\x05\x11" >> }; >> >> If I prepend \x06 (tag for OID) and \x06 (length 06) I can DER decode >> the OIDs using e.g. 'dumpasn1' and it looks right. >> >> However, it would be good if someone else confirmed this independently >> (or at least as independently as can be hoped for since I have now >> posted my guess). From mrex@sap.com Wed Apr 4 10:28:01 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1256921F861B for ; Wed, 4 Apr 2012 10:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.042 X-Spam-Level: X-Spam-Status: No, score=-9.042 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFOq3Zd0GpuE for ; Wed, 4 Apr 2012 10:28:00 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1044421F8562 for ; Wed, 4 Apr 2012 10:27:59 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q34HRsgo016428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Apr 2012 19:27:54 +0200 (MEST) From: Martin Rex Message-Id: <201204041727.q34HRs1a005247@fs4113.wdf.sap.corp> To: nico@cryptonector.com (Nico Williams) Date: Wed, 4 Apr 2012 19:27:54 +0200 (MEST) In-Reply-To: from "Nico Williams" at Apr 4, 12 11:31:17 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org, simon@josefsson.org Subject: Re: [kitten] GSS-API and timeouts X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 17:28:01 -0000 Nico Williams wrote: > > If you don't want to tackle async init/accept_sec_context now then I > suggest that you use threads and thread cancellation. Without looking at the particular environment underlying this discussion, I've seen problems with termination of blocking/synchronous network communication. While doing a shutdown() on a socket across threads will normally wake blocking threads on Unix system (without invalidating the socket handle that the thread was blocked on), this does not work on Microsoft Windows and on some older versions of SunOS. On Windows, the shutdown will cause network I/O, and if the peer processes the close event and closes the socket, the blocking thread will wake up almost instantly. But if the peer does not process events on the socket, then it will take 4 minutes 2*MSL (TCP retransmit timeout) before the thread that is blocking on read will be woken up with a timeout error on the socket. While closesocket() does have an immediate effect, it also invalidates the socket handle, which will require additional synchronization, so that (a) the socket handle is not used after closesocket() has been called and closesocket() is only called once. (The problem is that on a busy multi-threaded server the socket handle may get reused by an accept() between the time when a watchdog thread forces a closesocket() and the originally blocking thread wakes up.) -Martin From mrex@sap.com Wed Apr 4 10:30:58 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3681B21F8732 for ; Wed, 4 Apr 2012 10:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1io882Xa5L4 for ; Wed, 4 Apr 2012 10:30:57 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4B62621F868C for ; Wed, 4 Apr 2012 10:30:57 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q34HUt6Y028129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Apr 2012 19:30:55 +0200 (MEST) From: Martin Rex Message-Id: <201204041730.q34HUtU1005681@fs4113.wdf.sap.corp> To: simon@josefsson.org (Simon Josefsson) Date: Wed, 4 Apr 2012 19:30:55 +0200 (MEST) In-Reply-To: <87obr7lfqc.fsf@latte.josefsson.org> from "Simon Josefsson" at Apr 4, 12 04:43:39 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] GSS-API and timeouts X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 17:30:58 -0000 Simon Josefsson wrote: > > When implementing the GSS-API part of OPENID20/SAML20 I noticed that the > processes can hang waiting for a long time. Server may want to wait one > minute or more to allow a user to finish the IdP authentication. What kind of waiting are you thinking of here? Isn't this waiting for the initiator to send outstanding context tokens, which by itself is asynchronous, rather than the server blocking on a gss_accept_sec_context() call? -Martin From nico@cryptonector.com Wed Apr 4 10:31:00 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DE221F8795 for ; Wed, 4 Apr 2012 10:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.675 X-Spam-Level: X-Spam-Status: No, score=-1.675 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lvzix-20x2Ez for ; Wed, 4 Apr 2012 10:30:59 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDDF21F876C for ; Wed, 4 Apr 2012 10:30:59 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id F27E92AC07A for ; Wed, 4 Apr 2012 10:30:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=u3KpFVhBV5IgLCbqs+Na8 QOBFQwQr+fDylbprBf5B7fUTGP+00l77KyT7IJPU+HwX3HB5Dwm0LOuSM2tp4/YS ujcCqASdlAT4/xo+37Nmqjmfw1QGnxq7ZIVSyXN4+/2Pg27tF5d2oEdCLYbzVuDb LpLaDfNApFrzjCjORo/a40= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=EIgFzdEbpU6W55VAMb0I zRWphG0=; b=jOJXH1v+S+JjLd7jAT6tCyMfkuipqMBww3qT5dNWTifWh6zUwxpX f4z9P0wlyOXJAYP3dJBpOsWIgMJEVyXb60Rm8BponfJhU2NVQMQcLp2F5p/8MImS dGC3CGeXARw+yXDqbCqoP05T5VFTcJUVVCsld4elk/rmNhvBrLxMNUE= Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id C0E172AC073 for ; Wed, 4 Apr 2012 10:30:58 -0700 (PDT) Received: by dady13 with SMTP id y13so741457dad.27 for ; Wed, 04 Apr 2012 10:30:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.201.165 with SMTP id kb5mr1455589pbc.118.1333560658020; Wed, 04 Apr 2012 10:30:58 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Wed, 4 Apr 2012 10:30:57 -0700 (PDT) In-Reply-To: <87d37njtvv.fsf@latte.josefsson.org> References: <87obr7lfqc.fsf@latte.josefsson.org> <87d37njtvv.fsf@latte.josefsson.org> Date: Wed, 4 Apr 2012 12:30:57 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] GSS-API and timeouts X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 17:31:00 -0000 On Wed, Apr 4, 2012 at 12:20 PM, Simon Josefsson wrote: > Nico Williams writes: > >> If you don't want to tackle async init/accept_sec_context now then I >> suggest that you use threads and thread cancellation. > > And not have any timeout in the implementation of the mechanism itself? Right. Why not? You'd have to have cancellation handlers and so on, but then, proper pthread use requires it anyways. Not that anyone bores making libraries cancel-safe -- it's a lot of work, and pthread_cacnel() is rarely ever used. On the other hand, both MIT and Heimdal have added the sorts of interfaces you proposed without any standardization effort, so nothing should stop you from doing the same. My problem with global settings is that they are global, but we know we have apps that load libraries that load libraries that load libraries that use GSS such that we end up having multiple GSS apps in one process. This is why I dislike global settings. My solution, when I get around to finishing it, will be a variant of the "pgss" proposal... (if you'd like to review the design you can, it's in my 'pgss' branch of my github Heimdal fork). Nico -- From nico@cryptonector.com Wed Apr 4 10:32:20 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C35D21F86DA for ; Wed, 4 Apr 2012 10:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUMqkMR90+am for ; Wed, 4 Apr 2012 10:32:20 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 114F121F86CE for ; Wed, 4 Apr 2012 10:32:20 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 957DF1B407B for ; Wed, 4 Apr 2012 10:32:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Mrrude7NOVNDTPebcZIbiVfkGicIQ5DAVr+yVqy8kLNL 2MApY3Ir7v0Wz8UAz1PctH/7IZHYhD6lZ1zfDH8cG/Yjvx1Ts1flUJXIh4RsQt+D TSLV3Lq/doFzVq2vWfc8ZV/ZbzKJurXzm6PgVB40hBLgY2v3v3pbkIuVurWTMzM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=6AL/d04U3CN1pWnUEUewUu3RQpg=; b=iAWpes9t517 ZPtS3cmA93ynJj0pAKw1bcdcqFpIfnYC/MkT5P3Tuv6md1lbJ0l2sJBEl0xlrNwz ZVP+9GyrsZHenX0QOxtHl+5JPi59x54sVL2vRmiWjIRk5kxhWywWQoNnRufYAXCx WnwNl7zyFyIJcPYo3vWNWQiYUCtHkbjk= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 71E831B406B for ; Wed, 4 Apr 2012 10:32:19 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so510265pbb.31 for ; Wed, 04 Apr 2012 10:32:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.219.3 with SMTP id pk3mr23945312pbc.34.1333560739032; Wed, 04 Apr 2012 10:32:19 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Wed, 4 Apr 2012 10:32:18 -0700 (PDT) In-Reply-To: <201204041730.q34HUtU1005681@fs4113.wdf.sap.corp> References: <87obr7lfqc.fsf@latte.josefsson.org> <201204041730.q34HUtU1005681@fs4113.wdf.sap.corp> Date: Wed, 4 Apr 2012 12:32:18 -0500 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, Simon Josefsson Subject: Re: [kitten] GSS-API and timeouts X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 17:32:20 -0000 On Wed, Apr 4, 2012 at 12:30 PM, Martin Rex wrote: > Simon Josefsson wrote: >> >> When implementing the GSS-API part of OPENID20/SAML20 I noticed that the >> processes can hang waiting for a long time. =C2=A0Server may want to wai= t one >> minute or more to allow a user to finish the IdP authentication. > > What kind of waiting are you thinking of here? > > Isn't this waiting for the initiator to send outstanding context tokens, > which by itself is asynchronous, rather than the server blocking on > a gss_accept_sec_context() call? No, Simon's talking about waiting for messages to infrastructure, like Kerberos KDCs, OCSP responders / CRL servers, RADIUS, IdPs, ... Things the GSS-API does not expose. Nico -- From wmills@yahoo-inc.com Wed Apr 4 10:35:47 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7D421F86DA for ; Wed, 4 Apr 2012 10:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.484 X-Spam-Level: X-Spam-Status: No, score=-16.484 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwcDUAowin-0 for ; Wed, 4 Apr 2012 10:35:46 -0700 (PDT) Received: from nm10.bullet.mail.ne1.yahoo.com (nm10.bullet.mail.ne1.yahoo.com [98.138.90.73]) by ietfa.amsl.com (Postfix) with SMTP id 9898721F8559 for ; Wed, 4 Apr 2012 10:35:46 -0700 (PDT) Received: from [98.138.90.48] by nm10.bullet.mail.ne1.yahoo.com with NNFMP; 04 Apr 2012 17:35:43 -0000 Received: from [98.138.87.12] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 04 Apr 2012 17:35:43 -0000 Received: from [127.0.0.1] by omp1012.mail.ne1.yahoo.com with NNFMP; 04 Apr 2012 17:35:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 497410.11997.bm@omp1012.mail.ne1.yahoo.com Received: (qmail 40241 invoked by uid 60001); 4 Apr 2012 17:35:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1333560942; bh=Yarcl6uYI33/R2tCfs1TJwGJxrIePX4C+5uCH3vhQ5s=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ah6aG6jaSqaXWh7QJxHuNwv85rNg9mRHfKEXaT0HZWIILfsXUhAzxZGp6w0rLU9bsBcvSvZFe3qll9TS8rpmHra0fruHe6LWfbstjMZRZARZKAonkjkkmGa0CMIYBEhTze2tdWADQFUlS8iXJdvn8Dh6Hm7Djoy5fKKngtPQKDE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lhSjSK2vYst/FBZZm2s5lSuegRD2D5Wyuoz2OTPfpHkNodiasCHcl+jD7qWHmou/2IJowcaDorkQ6Lod+gr1Cd7toxx8CVsFHrPpV28EICuAbOdE8bp7j9Yyw6DoCMQ1+2+lTFVujY8TI1Gg0Ljv6Zm49sQd1xWll/GOwe/EuNw=; X-YMail-OSG: 5vTSAqQVM1mRN1rz6UufH2J9cQIa_Yka9TH5rjFzFUii1tG zs_4fz3hncYn6qEqbmngHNZPR996mimRHu90ZQUvRhZ4gGOZej_OpECt7haS GaFrKoIoI86JfJO5St7bldS2tQcvw0FdRU2X.tJPOZ4KIOVF2cHMTF4VfmH3 qI.02YoAA60RW2JkqRvrgYoNfUjp8CZ1Y2xSozz7ii.GqRlRPpKF298kFPVX 1x6gbS_VOhqLJg5qE4YEJR6OFcHo9v1TYubqMuWGuQBUsprY12r4G8f_g_d1 7qbASdvQa_UzYXMczkrxpY9nUkdRtwSX7duM0nTNtipmw9CXsLgtSl869pRt xG6Dphlxlw_B_SxMUxRbxem5kt4vkXWi58vtaFrzEcc2elNc1MwyPs_Q3FrW 4cthk_YwLinH5aneL4Yu_6IW8J8_Y6A9cQROvHCbrLyBYqA4uSFA- Received: from [209.131.62.115] by web31804.mail.mud.yahoo.com via HTTP; Wed, 04 Apr 2012 10:35:42 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340979 References: <87obr7lfqc.fsf@latte.josefsson.org> <1333554083.71760.YahooMailNeo__8959.87156914107$1333554099$gmane$org@web31804.mail.mud.yahoo.com> <87limbju45.fsf@latte.josefsson.org> Message-ID: <1333560942.30565.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Wed, 4 Apr 2012 10:35:42 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <87limbju45.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] GSS-API and timeouts X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 17:35:47 -0000 =0A=0A=0A=0A=0A>________________________________=0A> From: Simon Josefsson = =0A>To: William Mills =0A>Cc: "= kitten@ietf.org" =0A>Sent: Wednesday, April 4, 2012 10:15= AM=0A>Subject: Re: GSS-API and timeouts=0A> =0A>William Mills writes:=0A>=0A>> As a result of the OpenID flow/redirect don't y= ou get a complete=0A>> credential that can be used to finish the process?= =A0 Can't you connect=0A>> again, get a challenge perhaps, submit that comp= leted credential and=0A>> be done?=A0 That's very similar to what I did in = the OAUTH/SASL thing,=0A>> so I'm replaying my one trick :)=0A>=0A>The prob= lem is that the browser interaction in OPENID20/SAML20 can take=0A>a long t= ime because it is interactive, and the server doesn't know when=0A>to stop = waiting.=0A>=0A>/Simon=0A>=0A=0AYes, but if you can support an async style = thing then you can just fail=0Athe first auth, hold the connection open, an= d let the client do a second =0A=0Aauth.=A0 Server then limits the total nu= mber of allowed failed auth transactions.=0A=0A=0A>>=0A>>=0A>>=0A>>=0A>>=0A= >>=0A>>>________________________________=0A>>> From: Simon Josefsson =0A>>>To: kitten@ietf.org =0A>>>Sent: Wednesday, April 4, 20= 12 7:43 AM=0A>>>Subject: [kitten] GSS-API and timeouts=0A>>> =0A>>>When imp= lementing the GSS-API part of OPENID20/SAML20 I noticed that the=0A>>>proce= sses can hang waiting for a long time.=A0 Server may want to wait one=0A>>>= minute or more to allow a user to finish the IdP authentication.=0A>>>=0A>>= >I think Nico discussed asynchronous GSS-API before.=A0 However it is a=0A>= >>significant amount of work to specify and implement.=A0 I think it is=0A>= >>simpler for applications to create a separate process or thread for the= =0A>>>GSS-API part, and to enforce its own timeouts.=A0 Sometimes there are= =0A>>>other reasons for having separate processes/threads anyway.=0A>>>=0A>= >>Still, even an asynchronous interface may want to use some timeouts=0A>>>= where authentication is no longer expected to ever finish.=A0 So it is not= =0A>>>clear that an asynchronous interface is the solution to this problem.= =0A>>>=0A>>>Does anyone have any thoughts on what a reasonable timeout shou= ld be?=0A>>>=0A>>>Or should GSS-API initiators and acceptors never timeout,= but just hang=0A>>>indefinitely in case the authentication eventually comp= letes?=0A>>>=0A>>>Of course, we could have a new GSS-API interface to enfor= ce a timeout.=0A>>>For example:=0A>>>=0A>>>=A0 =A0=A0 OM_uint32=0A>>>=A0 = =A0=A0 gss_sec_context_timeout (OM_uint32 *minor_status,=0A>>>=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 OM_uint32 timeout);=0A>>>= =0A>>>or something more general, in case there are similar concerns for oth= er=0A>>>functions:=0A>>>=0A>>>=0A>>>=A0 =A0=A0 OM_uint32=0A>>>=A0 =A0=A0 gs= s_set_timeouts (OM_uint32 *minor_status,=0A>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0=A0 OM_uint32 sec_context_timeout,=0A>>>=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 OM_uint32 micwrap_timeout);=0A>>>=0A>>>FWIW, in = my implementation I'll probably use a 5 minute timeout or=0A>>>something li= ke that.=0A>>>=0A>>>/Simon=0A>>>___________________________________________= ____=0A>>>Kitten mailing list=0A>>>Kitten@ietf.org=0A>>>https://www.ietf.or= g/mailman/listinfo/kitten=0A>>>=0A>>>=0A>>>=0A>> __________________________= _____________________=0A>> Kitten mailing list=0A>> Kitten@ietf.org=0A>> ht= tps://www.ietf.org/mailman/listinfo/kitten=0A>=0A>=0A> From simon@josefsson.org Wed Apr 4 10:46:56 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6783E21F87D3 for ; Wed, 4 Apr 2012 10:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.789 X-Spam-Level: X-Spam-Status: No, score=-99.789 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+zLe1ZyUmSX for ; Wed, 4 Apr 2012 10:46:55 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADC821F8772 for ; Wed, 4 Apr 2012 10:46:54 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q34HkfRS004188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Apr 2012 19:46:43 +0200 From: Simon Josefsson To: William Mills References: <87obr7lfqc.fsf@latte.josefsson.org> <1333554083.71760.YahooMailNeo__8959.87156914107$1333554099$gmane$org@web31804.mail.mud.yahoo.com> <87limbju45.fsf@latte.josefsson.org> <1333560942.30565.YahooMailNeo__42659.7644495361$1333560961$gmane$org@web31804.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120404:kitten@ietf.org::BQ93Gk1pbWQsnTzg:cuit X-Hashcash: 1:22:120404:wmills@yahoo-inc.com::Mbsyl0mKL3aTLcpm:043RK Date: Wed, 04 Apr 2012 19:46:36 +0200 In-Reply-To: <1333560942.30565.YahooMailNeo__42659.7644495361$1333560961$gmane$org@web31804.mail.mud.yahoo.com> (William Mills's message of "Wed, 4 Apr 2012 10:35:42 -0700 (PDT)") Message-ID: <87wr5vie4j.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] GSS-API and timeouts X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 17:46:56 -0000 William Mills writes: >>> As a result of the OpenID flow/redirect don't you get a complete >>> credential that can be used to finish the process?  Can't you connect >>> again, get a challenge perhaps, submit that completed credential and >>> be done?  That's very similar to what I did in the OAUTH/SASL thing, >>> so I'm replaying my one trick :) >> >>The problem is that the browser interaction in OPENID20/SAML20 can take >>a long time because it is interactive, and the server doesn't know when >>to stop waiting. >> >>/Simon >> > > Yes, but if you can support an async style thing then you can just fail > the first auth, hold the connection open, and let the client do a second > auth.  Server then limits the total number of allowed failed auth > transactions. I don't see how that works for OPENID20/SAML20 -- because the client doesn't get any token that could be used for the next SASL session. The server still has to wait for the first authentication to complete eventually (of course the client can close that connection to indicate cancelation but that is rather brutal). /Simon From simon@josefsson.org Wed Apr 4 10:47:52 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA9621F87D4 for ; Wed, 4 Apr 2012 10:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.797 X-Spam-Level: X-Spam-Status: No, score=-99.797 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktiA-0v2+kIz for ; Wed, 4 Apr 2012 10:47:52 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 104E921F8772 for ; Wed, 4 Apr 2012 10:47:51 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q34Hle33004206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Apr 2012 19:47:41 +0200 From: Simon Josefsson To: Nico Williams References: <87obr7lfqc.fsf@latte.josefsson.org> <87d37njtvv.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120404:kitten@ietf.org::uQ1QKikRmEZ7RE5B:DXjx X-Hashcash: 1:22:120404:nico@cryptonector.com::eb+0S+ta+R3XQowF:A1YE Date: Wed, 04 Apr 2012 19:47:40 +0200 In-Reply-To: (Nico Williams's message of "Wed, 4 Apr 2012 12:30:57 -0500") Message-ID: <87sjgjie2r.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] GSS-API and timeouts X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 17:47:52 -0000 Nico Williams writes: > On Wed, Apr 4, 2012 at 12:20 PM, Simon Josefsson wrote: >> Nico Williams writes: >> >>> If you don't want to tackle async init/accept_sec_context now then I >>> suggest that you use threads and thread cancellation. >> >> And not have any timeout in the implementation of the mechanism itself? > > Right. Why not? You'd have to have cancellation handlers and so on, > but then, proper pthread use requires it anyways. Not that anyone > bores making libraries cancel-safe -- it's a lot of work, and > pthread_cacnel() is rarely ever used. > > On the other hand, both MIT and Heimdal have added the sorts of > interfaces you proposed without any standardization effort, so nothing > should stop you from doing the same. > > My problem with global settings is that they are global, but we know > we have apps that load libraries that load libraries that load > libraries that use GSS such that we end up having multiple GSS apps in > one process. This is why I dislike global settings. My solution, > when I get around to finishing it, will be a variant of the "pgss" > proposal... (if you'd like to review the design you can, it's in my > 'pgss' branch of my github Heimdal fork). Ok. Having no timeout is simpler to implement. I'll try that and see how it works. Thanks, /Simon From jbasney@illinois.edu Wed Apr 4 11:13:25 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F9A11E808A for ; Wed, 4 Apr 2012 11:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kV5tqIyECucT for ; Wed, 4 Apr 2012 11:13:24 -0700 (PDT) Received: from dscas1.ad.uiuc.edu (dscas1.ad.uiuc.edu [128.174.68.119]) by ietfa.amsl.com (Postfix) with ESMTP id DE48811E8089 for ; Wed, 4 Apr 2012 11:13:23 -0700 (PDT) Received: from bit.ncsa.uiuc.edu (141.142.220.216) by smtp-secure.illinois.edu (128.174.68.18) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 4 Apr 2012 13:13:17 -0500 Message-ID: <4F7C8F3D.9000103@illinois.edu> Date: Wed, 4 Apr 2012 13:13:17 -0500 From: Jim Basney User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: kitten@ietf.org References: <87k41vlfg6.fsf@latte.josefsson.org> <4F7C7CF4.9070502__14269.8731193834$1333558527$gmane$org@isode.com> <878vibjtmz.fsf@latte.josefsson.org> In-Reply-To: <878vibjtmz.fsf@latte.josefsson.org> X-Enigmail-Version: 1.4 OpenPGP: id=0A33BE15; url=http://www.ncsa.illinois.edu/~jbasney/pgp.asc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Subject: Re: [kitten] OID DER for OPENID20/SAML20 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 18:13:25 -0000 On 4/4/12 12:26 PM, Simon Josefsson wrote: > The GSS-API mechanism OID for SAML is 1.3.6.1.5.5.17 (see Section 7.2 > for more information). The DER encoding of the OID is 0x2b 0x06 0x01 > 0x05 0x05 0x11. > > I'd feel more comfortable about this if someone could confirm the DER > encoding though. It matches what I get using the Perl Convert::BER module. -Jim From rra@stanford.edu Wed Apr 4 15:18:54 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCB511E8110 for ; Wed, 4 Apr 2012 15:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdngMrIjbHaS for ; Wed, 4 Apr 2012 15:18:53 -0700 (PDT) Received: from smtp.stanford.edu (smtp3.Stanford.EDU [171.67.219.83]) by ietfa.amsl.com (Postfix) with ESMTP id C58B211E80C2 for ; Wed, 4 Apr 2012 15:18:53 -0700 (PDT) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 84679441BB6 for ; Wed, 4 Apr 2012 15:18:52 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id 144A2441185 for ; Wed, 4 Apr 2012 15:18:52 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id CEF322F46D; Wed, 4 Apr 2012 15:18:51 -0700 (PDT) From: Russ Allbery To: kitten@ietf.org In-Reply-To: <87hawzjty8.fsf@latte.josefsson.org> (Simon Josefsson's message of "Wed, 04 Apr 2012 19:19:27 +0200") Organization: The Eyrie References: <87obr7lfqc.fsf@latte.josefsson.org> <1333554538.22628.292.camel__5672.95260630107$1333554546$gmane$org@willson.li.ssimo.org> <87hawzjty8.fsf@latte.josefsson.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Date: Wed, 04 Apr 2012 15:18:51 -0700 Message-ID: <87y5qbnnsk.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [kitten] GSS-API and timeouts X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 22:18:54 -0000 Simon Josefsson writes: > Yeah, it is not optimal. We could make it take a 'gss_ctx_id_t' > parameter so the timeout is just for a particular context, but then > there is no way to specify a timeout for the initial call that generate > the gss_ctx_id_t. The lack of ability to set options on the initial call has been a problem for a long time. In a Kerberos context, it currently means that one has to set a per-thread global for the ticket cache to use, for example, rather than attaching some state to a specific GSS-API interaction. -- Russ Allbery (rra@stanford.edu) From nico@cryptonector.com Wed Apr 4 15:27:16 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9358511E80B3 for ; Wed, 4 Apr 2012 15:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.776 X-Spam-Level: X-Spam-Status: No, score=-1.776 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZVFosbttUAF for ; Wed, 4 Apr 2012 15:27:15 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id D663011E80A2 for ; Wed, 4 Apr 2012 15:27:15 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 94641BC042 for ; Wed, 4 Apr 2012 15:27:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=QFB4GTNS5yPaaLGpFfy1phbm0obENdzRJIN+WbgP4lUh rek7U+VjaWakDLJiCkL7atbuWEPwAzgteICqSKs3PAjoYLFphUUMGMQOZ1mWMpe5 RTC7XM3pK47YdYOXjvLyKxTsnVV69YpY5UffwRnqTL3wn8D6bbb2bEvZiBkXkSg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=YYno1Gab+rs1wQSE6jG1MOoqYXM=; b=DRU35kk3kCo ZuHNRXkuNsNFYOr0RhfENCZti4ntAKSLvv2Vivl0yj+TZJLTIqzBCm0HybIsWBFK X4shmAJRH20OqAh0dwTZgBNL2GtAGKravcXOJjGQklYq250qap7yQUuwOTJb8Akv JxsXde6gxK066+5kQ+xW3y1+1hSU3hfo= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id 7A3F6BC040 for ; Wed, 4 Apr 2012 15:27:15 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so743731pbb.31 for ; Wed, 04 Apr 2012 15:27:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.132.99 with SMTP id ot3mr1261997pbb.160.1333578435023; Wed, 04 Apr 2012 15:27:15 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Wed, 4 Apr 2012 15:27:14 -0700 (PDT) In-Reply-To: <87y5qbnnsk.fsf@windlord.stanford.edu> References: <87obr7lfqc.fsf@latte.josefsson.org> <1333554538.22628.292.camel__5672.95260630107$1333554546$gmane$org@willson.li.ssimo.org> <87hawzjty8.fsf@latte.josefsson.org> <87y5qbnnsk.fsf@windlord.stanford.edu> Date: Wed, 4 Apr 2012 17:27:14 -0500 Message-ID: From: Nico Williams To: Russ Allbery Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] GSS-API and timeouts X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 22:27:16 -0000 On Wed, Apr 4, 2012 at 5:18 PM, Russ Allbery wrote: > Simon Josefsson writes: > The lack of ability to set options on the initial call has been a problem > for a long time. =C2=A0In a Kerberos context, it currently means that one= has > to set a per-thread global for the ticket cache to use, for example, > rather than attaching some state to a specific GSS-API interaction. Maybe I should finish up my pgss work and write an I-D. The API is trivial, the changes to the mechs are trivial, the changes to the mechglue are rote (but extensive, mostly in the form of a simple addition to the preamble of most GSS functions). From lukeh@padl.com Wed Apr 4 15:33:55 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A687F11E811E for ; Wed, 4 Apr 2012 15:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHGoo8W7uUO6 for ; Wed, 4 Apr 2012 15:33:51 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 183DF11E812A for ; Wed, 4 Apr 2012 15:33:51 -0700 (PDT) Received: by us.padl.com with ESMTP id q34MXlKC011796; Wed, 4 Apr 2012 18:33:49 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <87y5qbnnsk.fsf@windlord.stanford.edu> Date: Thu, 5 Apr 2012 08:33:49 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <4C60BAE9-E039-438E-B686-400753A0AFD7@padl.com> References: <87obr7lfqc.fsf@latte.josefsson.org> <1333554538.22628.292.camel__5672.95260630107$1333554546$gmane$org@willson.li.ssimo.org> <87hawzjty8.fsf@latte.josefsson.org> <87y5qbnnsk.fsf@windlord.stanford.edu> To: Russ Allbery X-Mailer: Apple Mail (2.1257) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: kitten@ietf.org Subject: Re: [kitten] GSS-API and timeouts X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 22:33:55 -0000 On 05/04/2012, at 8:18 AM, Russ Allbery wrote: > Simon Josefsson writes: >=20 >> Yeah, it is not optimal. We could make it take a 'gss_ctx_id_t' >> parameter so the timeout is just for a particular context, but then >> there is no way to specify a timeout for the initial call that = generate >> the gss_ctx_id_t. >=20 > The lack of ability to set options on the initial call has been a = problem > for a long time. In a Kerberos context, it currently means that one = has > to set a per-thread global for the ticket cache to use, for example, > rather than attaching some state to a specific GSS-API interaction. The non-standard extension gss_set_sec_context_option() can create a = context handle which can be then passed to the first = gss_init_sec_context(). -- Luke= From rra@stanford.edu Wed Apr 4 15:36:37 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625BF21F8495 for ; Wed, 4 Apr 2012 15:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swt6JMsCMPGe for ; Wed, 4 Apr 2012 15:36:36 -0700 (PDT) Received: from smtp.stanford.edu (smtp3.Stanford.EDU [171.67.219.83]) by ietfa.amsl.com (Postfix) with ESMTP id D6EEE21F8493 for ; Wed, 4 Apr 2012 15:36:36 -0700 (PDT) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C0806441177 for ; Wed, 4 Apr 2012 15:36:36 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id AC2664412E1 for ; Wed, 4 Apr 2012 15:36:36 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 71C5F2F46D; Wed, 4 Apr 2012 15:36:36 -0700 (PDT) From: Russ Allbery To: kitten@ietf.org In-Reply-To: <4C60BAE9-E039-438E-B686-400753A0AFD7@padl.com> (Luke Howard's message of "Thu, 5 Apr 2012 08:33:49 +1000") Organization: The Eyrie References: <87obr7lfqc.fsf@latte.josefsson.org> <1333554538.22628.292.camel__5672.95260630107$1333554546$gmane$org@willson.li.ssimo.org> <87hawzjty8.fsf@latte.josefsson.org> <87y5qbnnsk.fsf@windlord.stanford.edu> <4C60BAE9-E039-438E-B686-400753A0AFD7@padl.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Date: Wed, 04 Apr 2012 15:36:36 -0700 Message-ID: <87limbnmyz.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [kitten] GSS-API and timeouts X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 22:36:37 -0000 Luke Howard writes: > On 05/04/2012, at 8:18 AM, Russ Allbery wrote: >> The lack of ability to set options on the initial call has been a >> problem for a long time. In a Kerberos context, it currently means >> that one has to set a per-thread global for the ticket cache to use, >> for example, rather than attaching some state to a specific GSS-API >> interaction. > The non-standard extension gss_set_sec_context_option() can create a > context handle which can be then passed to the first > gss_init_sec_context(). Ah, indeed! I missed that. Thank you. -- Russ Allbery (rra@stanford.edu) From simon@josefsson.org Wed Apr 4 22:48:05 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B25111E80AB for ; Wed, 4 Apr 2012 22:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.804 X-Spam-Level: X-Spam-Status: No, score=-99.804 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lYAUOmWW1CG for ; Wed, 4 Apr 2012 22:48:05 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7507F11E8079 for ; Wed, 4 Apr 2012 22:48:04 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q355lwqn003875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Apr 2012 07:47:59 +0200 From: Simon Josefsson To: Jim Basney References: <87k41vlfg6.fsf@latte.josefsson.org> <4F7C7CF4.9070502__14269.8731193834$1333558527$gmane$org@isode.com> <878vibjtmz.fsf@latte.josefsson.org> <4F7C8F3D.9000103__8716.30872502482$1333563212$gmane$org@illinois.edu> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120405:kitten@ietf.org::gfrGagYV6xtwzXZ7:CuW3 X-Hashcash: 1:22:120405:jbasney@illinois.edu::FpZlt4IgMCk4b0Ko:cWQF Date: Thu, 05 Apr 2012 07:47:58 +0200 In-Reply-To: <4F7C8F3D.9000103__8716.30872502482$1333563212$gmane$org@illinois.edu> (Jim Basney's message of "Wed, 4 Apr 2012 13:13:17 -0500") Message-ID: <877gxuivap.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] OID DER for OPENID20/SAML20 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 05:48:05 -0000 Jim Basney writes: > On 4/4/12 12:26 PM, Simon Josefsson wrote: >> The GSS-API mechanism OID for SAML is 1.3.6.1.5.5.17 (see Section 7.2 >> for more information). The DER encoding of the OID is 0x2b 0x06 0x01 >> 0x05 0x05 0x11. >> >> I'd feel more comfortable about this if someone could confirm the DER >> encoding though. > > It matches what I get using the Perl Convert::BER module. Thank you. I'll send the above to the RFC editor. /Simon From alexey.melnikov@isode.com Thu Apr 5 03:47:18 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A2C21F85F4 for ; Thu, 5 Apr 2012 03:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izACmOEECE+o for ; Thu, 5 Apr 2012 03:47:18 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1817121F8618 for ; Thu, 5 Apr 2012 03:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1333622836; d=isode.com; s=selector; i=@isode.com; bh=XS3lyVAAn5KBwDe9/g/KSepvx8wLKrg2h54nypIfyis=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=PGhbYBKTShqnZQpfhjyyHYe6RQ2V+KmaZufvEjgZ541WlUeObfzstxNvZnbIxcKbWloWW4 HAo0E9I8pyQ2jg/Lkfng1PIbv6kFAnNhRz4ZvxJkzS0NcW6Fq3VyAquLjEgFoUPAsxh3LW Rkt89KW3g5Jil4GQkLssev3qWiBYLzo=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 5 Apr 2012 11:47:16 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F7D784C.3070606@isode.com> Date: Thu, 05 Apr 2012 11:47:40 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "Cantor, Scott" References: <87fwcjlf8s.fsf@latte.josefsson.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 10:47:18 -0000 On 04/04/2012 15:57, Cantor, Scott wrote: >>> Also, I'm not sure that OID is "official". In fact, I would guess it's >>> not. The SAML mech currently says in draft-09 that the mech OID is TBD, so >>> I would imagine this one is too. I can't honestly even say where it came >>> from. >> The OID is from my tree. We probably should use IANA's SMI OID number >> tree instead. > Thanks, I was about to follow up and ask what I should do. Do I need to apply for an OID in some way? > > I should have a proposal hopefully soon on a SAML name type and I can update the draft with the correct OID at that point. We can ask IANA for an early allocation of the relevant OID. But the best would be just to use TBD in the document and let IANA allocate one upon document approval by IESG. From Matt.Peterson@quest.com Mon Apr 9 10:02:01 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E50721F86DE for ; Mon, 9 Apr 2012 10:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o18SV9VF7lFH for ; Mon, 9 Apr 2012 10:02:00 -0700 (PDT) Received: from alvetxw01.quest.com (alvetxw01.quest.com [12.106.87.93]) by ietfa.amsl.com (Postfix) with ESMTP id C42C521F86B4 for ; Mon, 9 Apr 2012 10:02:00 -0700 (PDT) Received: from ALVHTXW02.prod.quest.corp (10.1.135.18) by alvetxw01.quest.com (10.1.100.93) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Apr 2012 09:59:05 -0700 Received: from ALVMBXW01.prod.quest.corp ([fe80::48dd:e065:86b3:9cee]) by ALVHTXW02.prod.quest.corp ([::1]) with mapi id 14.01.0355.002; Mon, 9 Apr 2012 10:01:59 -0700 From: Matt Peterson To: "kitten@ietf.org" Thread-Topic: [kitten] OAUTH/SASL... to HTTP or not to HTTP, that is the question... Thread-Index: AQHNEgF6shtgFz/if0epyUjjcuNTnJaSwIDQ Date: Mon, 9 Apr 2012 17:01:59 +0000 Message-ID: <7F2B7AC6C3EEDC4A9C067A7852FA8A2D10156D4A@ALVMBXW01.prod.quest.corp> References: <1333498239.81695.YahooMailNeo@web31804.mail.mud.yahoo.com> <1333501139.69852.YahooMailNeo@web31807.mail.mud.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.5.37.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 09 Apr 2012 11:08:29 -0700 Subject: Re: [kitten] OAUTH/SASL... to HTTP or not to HTTP, that is the question... X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 17:02:01 -0000 RGl0dG8uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBraXR0ZW4tYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmtpdHRlbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg TmljbyBXaWxsaWFtcw0KU2VudDogVHVlc2RheSwgQXByaWwgMDMsIDIwMTIgNzoyMyBQTQ0KVG86 IFdpbGxpYW0gTWlsbHMNCkNjOiBraXR0ZW5AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBba2l0dGVu XSBPQVVUSC9TQVNMLi4uIHRvIEhUVFAgb3Igbm90IHRvIEhUVFAsIHRoYXQgaXMgdGhlIHF1ZXN0 aW9uLi4uDQoNCk9uIFR1ZSwgQXByIDMsIDIwMTIgYXQgNzo1OCBQTSwgV2lsbGlhbSBNaWxscyA8 d21pbGxzQHlhaG9vLWluYy5jb20+IHdyb3RlOg0KPiBUaGUgbWFqb3IgcXVlc3Rpb24gcmVtYWlu aW5nIGZvciBteSBkcmFmdCBpcyBIVFRQKGxpa2UpIG9yIG5vdCBmb3IgdGhlIFNBU0wNCj4gbWVz c2FnZSBmb3JtYXQ/wqAgUGxlYXNlIHNlbGVjdCBvbmUgb2YgdGhlIGZvbGxvd2luZzoNCj4NCj4g QSnCoMKgwqAgVGhlIGN1cnJlbnQgbWVzc2FnZSBmb3JtYXQgaXMgZmluZS4NCj4gQinCoMKgwqAg SFRUUC1saWtlIGlzIE9LIGFzIGxvbmcgYXMgd2UgbGltaXQgdGhlIGluc2FuaXR5Lg0KPiBDKcKg wqDCoCBIVFRQIGluIGFueSBmb3JtIGlzIGEgZGVhbCBicmVha2VyIGZvciBtZS7CoCBHaXZlIG1l IHNvbWV0aGluZyBzaW1wbGUuDQo+IEQpwqDCoMKgIE5vbmUgb2YgdGhlIGFib3ZlLCBhbmQgSSBo YXZlIGEgcG9zc2libGUgc29sdXRpb24gb2YgbXkgb3duIHRvDQo+IHByb3Bvc2UuDQoNCkknbSBu b3QgYW4gaW1wbGVtZW50b3Igb2YgdGhpcyBwcm90b2NvbC4gIFNvbWUgZGF5IEkgbWlnaHQgYmUu ICBJJ20gT0sNCndpdGggKEIpLCBidXQgSSdkIHByZWZlciBzb21ldGhpbmcgc2FuZXIgdGhhbiBI VFRQLiAgSlNPTiBpcyBhbG1vc3QNCnBlcmZlY3RseSBzYW5lIChtaXNzaW5nIG9ubHkgYSBzZWxm LWRlc2NyaWJpbmcgZW5jb2Rpbmcgb2YgYmluYXJ5DQpkYXRhKS4gIEkgd2FudCBpdCB0byBiZSBz aW1wbGUsIGFuZCBJIHRoaW5rIEhUVFAtbGlrZS1idXQtbGl0ZSB3b3VsZA0KYmUgT0ssIGJ1dCB0 aGVyZSdzIHNvIG11Y2ggb2ZmLXRoZS1zaGVsZiBjb2RlIGFuZCBleHBlcmllbmNlIHdpdGgNCkpT T04uLi4gIElmIHRoZXJlJ3MgcnVubmluZyBjb2RlIHRoYXQgaGFzIGJlZW4gZGVwbG95ZWQgdGhl biBJIHRoaW5rDQooQikgaXMgdGhlIGJlc3Qgb3B0aW9uLiAgSFRUUC1saWtlIHdpdGggSFRUUCBp bnNhbml0eSBpcyBhIGRlYWwNCmJyZWFrZXIgdGhvdWdoLg0KDQpTbyBjb3VudCBtZSBhcyBpbiBm YXZvciBvZiAoQikgaWYgdGhlcmUncyBub3QgZW5vdWdoIHN1cHBvcnQgZm9yIChDKS4NCg0KTmlj bw0KLS0NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpL aXR0ZW4gbWFpbGluZyBsaXN0DQpLaXR0ZW5AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8va2l0dGVuDQo= From stephen.farrell@cs.tcd.ie Tue Apr 10 11:06:21 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D197B11E8134 for ; Tue, 10 Apr 2012 11:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQ7E7lhgJZPg for ; Tue, 10 Apr 2012 11:06:18 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id EB89011E8131 for ; Tue, 10 Apr 2012 11:06:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 3B8D0171479 for ; Tue, 10 Apr 2012 19:06:14 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1334081173; bh=omF5X/PhWeUOT5 SCsv6CxL1VbaFDuWS08/KSheMGR5k=; b=dLikXyhlCcuQMPWSszpWPIqOTfHiq8 bCl1QVy4wf0lDdSRPOKijGrvKpUCUHfXCpxPMvayZs9fgRmV/BxHaMo3tUTzFE9c y1KXUPvtbsNJqxDpJVp8PwDs/GHQJOgb+78jP08Z5CHOjjhHAZQrRWawkS6raOgM KQWyD0pkJu3fkcAbBOIjoQEHJA1oreiClGBOtEpJMcPphhn0NQR5ZK0lXw4W2LbS NorRh7cUKf+mKpMqvfQjyLF+d29D3nANPe+SlA8idrhyL9v81A1BLzA9jn/Cnw4D EWfkucZMgWZanf3LG5MAfY83qgY7s4SOrb7ORSIFeSxi8T9lvH8Co6cg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id j8rqiGRa50qy for ; Tue, 10 Apr 2012 19:06:13 +0100 (IST) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C1F9A171472 for ; Tue, 10 Apr 2012 19:06:13 +0100 (IST) Message-ID: <4F847696.7000302@cs.tcd.ie> Date: Tue, 10 Apr 2012 19:06:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: kitten@ietf.org References: <20120327124818.13407.14666.idtracker@ietfa.amsl.com> In-Reply-To: <20120327124818.13407.14666.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [kitten] Last Call: (GSS-API Naming Extensions) to Proposed Standard X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 18:06:22 -0000 Hi All, I didn't see any comments at all in the IETF LC so I've put this on the April 26th IESG telechat. Do let me know if I've missed something, Thanks, Stephen. On 03/27/2012 01:48 PM, The IESG wrote: > > The IESG has received a request from the Common Authentication Technology > Next Generation WG (kitten) to consider the following document: > - 'GSS-API Naming Extensions' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-04-10. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > The Generic Security Services API (GSS-API) provides a simple naming > architecture that supports name-based authorization. This document > introduces new APIs that extend the GSS-API naming model to support > name attribute transfer between GSS-API peers. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-kitten-gssapi-naming-exts/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-kitten-gssapi-naming-exts/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From stpeter@stpeter.im Tue Apr 10 14:48:23 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C3F21F867B for ; Tue, 10 Apr 2012 14:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.384 X-Spam-Level: X-Spam-Status: No, score=-102.384 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPzalmJY-4-k for ; Tue, 10 Apr 2012 14:48:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9F41D21F84DC for ; Tue, 10 Apr 2012 14:48:22 -0700 (PDT) Received: from dhcp-64-101-72-235.cisco.com (unknown [64.101.72.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 18EBB40058 for ; Tue, 10 Apr 2012 16:02:11 -0600 (MDT) Message-ID: <4F84AAA5.3030104@stpeter.im> Date: Tue, 10 Apr 2012 15:48:21 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "kitten@ietf.org" X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [kitten] spaces in SASL user names X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 21:48:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At the PRECIS WG session in Paris, we had quite a discussion about spaces in user names. Alexey maintained that this must have been included in SASLprep (RFC 4013) for a good reason, but the reason wasn't clear to folks in the meeting. So I have a few questions: 1. Do SASL user names really need to include spaces? 2. If SASL user names do *not* need to include spaces, would it be fine to re-use the PRECIS NameClass for simple user names in SASL? 3. If SASL user names *do* need to include spaces, would it be fine to define simple user names in SASL as a space-separated list of NameClass entities? Option #3 seems preferable to (a) specifying that the PRECIS NameClass needs to include space (to which there was a lot of resistance during the PRECIS WG session), (b) enabling folks to superclass PRECIS string classes (to which there was also a lot of resistance), or (c) severely subclassing the PRECIS FreeClass to be something like NameClass+SP. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+EqqUACgkQNL8k5A2w/vzHeQCfTX6rF+MAqj05uz/ojJpPDkMT RaMAn2AWoWO3lRiDgxfPmDZy7B4wyawX =xNtO -----END PGP SIGNATURE----- From simon@josefsson.org Wed Apr 11 00:01:34 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A9C21F86B0 for ; Wed, 11 Apr 2012 00:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.511 X-Spam-Level: X-Spam-Status: No, score=-99.511 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, J_CHICKENPOX_92=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXgeZ8JRPSew for ; Wed, 11 Apr 2012 00:01:33 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 61CA221F86B7 for ; Wed, 11 Apr 2012 00:01:28 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q3B71JOL031646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 11 Apr 2012 09:01:21 +0200 From: Simon Josefsson To: Peter Saint-Andre References: <4F84AAA5.3030104__43291.804000228$1334094511$gmane$org@stpeter.im> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120411:kitten@ietf.org::nGiiSihrIhcNzKBi:Gy3R X-Hashcash: 1:22:120411:stpeter@stpeter.im::MxQFNCPpbqEcfKOT:IVry Date: Wed, 11 Apr 2012 09:01:19 +0200 In-Reply-To: <4F84AAA5.3030104__43291.804000228$1334094511$gmane$org@stpeter.im> (Peter Saint-Andre's message of "Tue, 10 Apr 2012 15:48:21 -0600") Message-ID: <87ehrusqf4.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] spaces in SASL user names X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 07:01:34 -0000 Peter Saint-Andre writes: > At the PRECIS WG session in Paris, we had quite a discussion about > spaces in user names. Alexey maintained that this must have been > included in SASLprep (RFC 4013) for a good reason, but the reason > wasn't clear to folks in the meeting. So I have a few questions: > > 1. Do SASL user names really need to include spaces? I have seen real human names used for authentication identifiers more than once, so I believe the answer is yes. /Simon > 2. If SASL user names do *not* need to include spaces, would it be > fine to re-use the PRECIS NameClass for simple user names in SASL? > > 3. If SASL user names *do* need to include spaces, would it be fine to > define simple user names in SASL as a space-separated list of > NameClass entities? > > Option #3 seems preferable to (a) specifying that the PRECIS NameClass > needs to include space (to which there was a lot of resistance during > the PRECIS WG session), (b) enabling folks to superclass PRECIS string > classes (to which there was also a lot of resistance), or (c) severely > subclassing the PRECIS FreeClass to be something like NameClass+SP. > > Peter From nico@cryptonector.com Wed Apr 11 08:48:39 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5192411E8076 for ; Wed, 11 Apr 2012 08:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.238 X-Spam-Level: X-Spam-Status: No, score=-1.238 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8RJ5kXb57ek for ; Wed, 11 Apr 2012 08:48:36 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id F3C6611E8072 for ; Wed, 11 Apr 2012 08:48:35 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id 9C0022C206E for ; Wed, 11 Apr 2012 08:48:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=tRNVus8+yZi5E6W0MDuuG jcC13of8Blx10U3fdA4d5aAresNYuyLtZ0sAbHU14tD7IWpFw+D87BsqjsINnapn aabWAhY3T8GfT4QBhDgJPvSdWihSKIhnv8SjbI7YjiGgHS7Ixc765meX1WsJcP5N 8TbFPlTMB361PgoUaoJajw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=NRRh8oBheJum3iX0F4nZ zNNVFYk=; b=Zh0GGLvgb36tjo+vutZbWU983WOgO0e+YSSbDaHi17XohMCBOwKg oageeJouk2XokUwhyF2Z9ASv5k6sHqYg9J6TDeOS5mny6S4cn8ddQfSBJidAjPNp Cdl+KSCeIr3UEbkjCFr0BGE0yY2Dch2KFuDAH0svnBkzJgyYZtzQZgc= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPSA id 8709B2C2057 for ; Wed, 11 Apr 2012 08:48:35 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1393198pbb.31 for ; Wed, 11 Apr 2012 08:48:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.201.98 with SMTP id jz2mr38969554pbc.97.1334159315161; Wed, 11 Apr 2012 08:48:35 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Wed, 11 Apr 2012 08:48:34 -0700 (PDT) In-Reply-To: <87ehrusqf4.fsf@latte.josefsson.org> References: <4F84AAA5.3030104__43291.804000228$1334094511$gmane$org@stpeter.im> <87ehrusqf4.fsf@latte.josefsson.org> Date: Wed, 11 Apr 2012 10:48:34 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] spaces in SASL user names X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 15:48:39 -0000 One online multi-player game I play allows users to have all sorts of strangeness in their usernames. Nico -- From stpeter@stpeter.im Wed Apr 11 09:14:05 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D91E21F8562 for ; Wed, 11 Apr 2012 09:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.39 X-Spam-Level: X-Spam-Status: No, score=-102.39 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFoT8++LLouH for ; Wed, 11 Apr 2012 09:14:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A434121F855F for ; Wed, 11 Apr 2012 09:14:04 -0700 (PDT) Received: from dhcp-64-101-72-235.cisco.com (unknown [64.101.72.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AEFAD4005B; Wed, 11 Apr 2012 10:27:55 -0600 (MDT) Message-ID: <4F85A5DF.9050701@stpeter.im> Date: Wed, 11 Apr 2012 09:40:15 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Simon Josefsson References: <4F84AAA5.3030104__43291.804000228$1334094511$gmane$org@stpeter.im> <87ehrusqf4.fsf@latte.josefsson.org> In-Reply-To: <87ehrusqf4.fsf@latte.josefsson.org> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" Subject: Re: [kitten] spaces in SASL user names X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:14:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/11/12 1:01 AM, Simon Josefsson wrote: > Peter Saint-Andre writes: > >> At the PRECIS WG session in Paris, we had quite a discussion >> about spaces in user names. Alexey maintained that this must have >> been included in SASLprep (RFC 4013) for a good reason, but the >> reason wasn't clear to folks in the meeting. So I have a few >> questions: >> >> 1. Do SASL user names really need to include spaces? > > I have seen real human names used for authentication identifiers > more than once, so I believe the answer is yes. > > /Simon Thanks for the input. So my next question is: >> 3. If SASL user names *do* need to include spaces, would it be >> fine to define simple user names in SASL as a space-separated >> list of NameClass entities? >> >> Option #3 seems preferable to (a) specifying that the PRECIS >> NameClass needs to include space (to which there was a lot of >> resistance during the PRECIS WG session), (b) enabling folks to >> superclass PRECIS string classes (to which there was also a lot >> of resistance), or (c) severely subclassing the PRECIS FreeClass >> to be something like NameClass+SP. Feedback is welcome. :) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+Fpd4ACgkQNL8k5A2w/vz1uQCePRwaqpMz1Ou0uOoL9xAKs2y1 6wIAoM4NV+aHUGlHQPb8KddWO1jY8Ovb =Wqse -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Apr 11 09:20:40 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F348F11E8089 for ; Wed, 11 Apr 2012 09:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.671 X-Spam-Level: X-Spam-Status: No, score=-102.671 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1S0VGzCVgXj for ; Wed, 11 Apr 2012 09:20:39 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3914311E8085 for ; Wed, 11 Apr 2012 09:20:39 -0700 (PDT) Received: from dhcp-64-101-72-235.cisco.com (unknown [64.101.72.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1663A40058; Wed, 11 Apr 2012 10:34:27 -0600 (MDT) Message-ID: <4F85AF52.2000303@stpeter.im> Date: Wed, 11 Apr 2012 10:20:34 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Nico Williams References: <4F84AAA5.3030104__43291.804000228$1334094511$gmane$org@stpeter.im> <87ehrusqf4.fsf@latte.josefsson.org> In-Reply-To: X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] spaces in SASL user names X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:20:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/11/12 9:48 AM, Nico Williams wrote: > One online multi-player game I play allows users to have all sorts > of strangeness in their usernames. Hi Nico, It might be helpful to differentiate between generic "usernames" and SASL "simple user names". SASLprep applies only to the latter. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+Fr1IACgkQNL8k5A2w/vyb/QCg6AzPDb6bcIiisUYDnVHCE1mv w/0An0oGOXN5ABeoYI6/ssdoEQ7XyTq6 =FOkD -----END PGP SIGNATURE----- From chris.newman@oracle.com Wed Apr 11 09:47:20 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D2111E808D for ; Wed, 11 Apr 2012 09:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.446 X-Spam-Level: X-Spam-Status: No, score=-105.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2ayniah6U8n for ; Wed, 11 Apr 2012 09:47:19 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7FF11E8089 for ; Wed, 11 Apr 2012 09:47:19 -0700 (PDT) Received: from brmsunmail2-sfbay.uk.sun.com ([10.79.11.101]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id q3BGlHiq025431; Wed, 11 Apr 2012 16:47:18 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail2-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id q3BGlHHc061469; Wed, 11 Apr 2012 16:47:17 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 7u5-4.06 64bit (built Mar 14 2012)) with ESMTPA id <0M2B00645QMMDS00@gotmail.us.oracle.com>; Wed, 11 Apr 2012 09:47:17 -0700 (PDT) Date: Wed, 11 Apr 2012 08:48:23 -0700 From: Chris Newman To: Peter Saint-Andre , kitten@ietf.org Message-id: <4ED1D634F0E26CDC51B61127@[192.168.15.131]> In-reply-to: <4F84AAA5.3030104@stpeter.im> References: <4F84AAA5.3030104@stpeter.im> X-Mailer: Mulberry/4.0.8 (Mac OS X) Subject: Re: [kitten] spaces in SASL user names X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:47:20 -0000 --On April 10, 2012 15:48:21 -0600 Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > At the PRECIS WG session in Paris, we had quite a discussion about > spaces in user names. Alexey maintained that this must have been > included in SASLprep (RFC 4013) for a good reason, but the reason > wasn't clear to folks in the meeting. So I have a few questions: > > 1. Do SASL user names really need to include spaces? Absolutely yes. My correct name is "Chris Newman" (with a space). A user friendly interface would use my correct name. Protocol design should never unnecessarily obstruct the creation of user friendly interfaces. > 2. If SASL user names do *not* need to include spaces, would it be > fine to re-use the PRECIS NameClass for simple user names in SASL? > > 3. If SASL user names *do* need to include spaces, would it be fine to > define simple user names in SASL as a space-separated list of > NameClass entities? I am opposed to changing to the SASL user name ABNF in the mechanisms, with RFC 4616 being the simplest example of that ABNF. Given that constraint, I have little opinion about how PRECIS is used. So the proposal sounds feasible as long as we're not making ABNF changes to the underlying protocol. > Option #3 seems preferable to (a) specifying that the PRECIS NameClass > needs to include space (to which there was a lot of resistance during > the PRECIS WG session), (b) enabling folks to superclass PRECIS string > classes (to which there was also a lot of resistance), or (c) severely > subclassing the PRECIS FreeClass to be something like NameClass+SP. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk+EqqUACgkQNL8k5A2w/vzHeQCfTX6rF+MAqj05uz/ojJpPDkMT > RaMAn2AWoWO3lRiDgxfPmDZy7B4wyawX > =xNtO > -----END PGP SIGNATURE----- > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From stpeter@stpeter.im Wed Apr 11 10:52:53 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511A011E8089 for ; Wed, 11 Apr 2012 10:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.669 X-Spam-Level: X-Spam-Status: No, score=-102.669 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUINm+hwpqzK for ; Wed, 11 Apr 2012 10:52:51 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 91C2821F8504 for ; Wed, 11 Apr 2012 10:52:49 -0700 (PDT) Received: from dhcp-64-101-72-235.cisco.com (unknown [64.101.72.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 99DFB40058; Wed, 11 Apr 2012 12:06:40 -0600 (MDT) Message-ID: <4F85C4EE.2020901@stpeter.im> Date: Wed, 11 Apr 2012 11:52:46 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Chris Newman References: <4F84AAA5.3030104@stpeter.im> <4ED1D634F0E26CDC51B61127@[192.168.15.131]> In-Reply-To: <4ED1D634F0E26CDC51B61127@[192.168.15.131]> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] spaces in SASL user names X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 17:52:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/11/12 9:48 AM, Chris Newman wrote: > --On April 10, 2012 15:48:21 -0600 Peter Saint-Andre > wrote: At the PRECIS WG session in Paris, we > had quite a discussion about spaces in user names. Alexey > maintained that this must have been included in SASLprep (RFC 4013) > for a good reason, but the reason wasn't clear to folks in the > meeting. So I have a few questions: > > 1. Do SASL user names really need to include spaces? > >> Absolutely yes. My correct name is "Chris Newman" (with a space). >> A user friendly interface would use my correct name. Protocol >> design should never unnecessarily obstruct the creation of user >> friendly interfaces. > > 2. If SASL user names do *not* need to include spaces, would it be > fine to re-use the PRECIS NameClass for simple user names in SASL? > > 3. If SASL user names *do* need to include spaces, would it be fine > to define simple user names in SASL as a space-separated list of > NameClass entities? > >> I am opposed to changing to the SASL user name ABNF in the >> mechanisms, with RFC 4616 being the simplest example of that >> ABNF. Given that constraint, I have little opinion about how >> PRECIS is used. So the proposal sounds feasible as long as we're >> not making ABNF changes to the underlying protocol. The document that Alexey and I are working on will not override the ABNF in any given mechanism spec (e.g., RFC 4616). However, we'll probably want to look at how this work interacts with existing mechanisms (e.g., would we need to update those mechanism specs to use the PRECIS approach instead of the stringprep approach?). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+FxO4ACgkQNL8k5A2w/vwPkQCg0taqYm1blZ2WuHDkFjLa2rNs ElYAoIK7mZBI8chbHj/R5GysmrZtHdMh =moOP -----END PGP SIGNATURE----- From simon@josefsson.org Wed Apr 11 12:20:44 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794D421F850F for ; Wed, 11 Apr 2012 12:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.499 X-Spam-Level: X-Spam-Status: No, score=-100.499 tagged_above=-999 required=5 tests=[AWL=0.810, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, J_CHICKENPOX_92=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anLYMqviesNa for ; Wed, 11 Apr 2012 12:20:43 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 9236521F851A for ; Wed, 11 Apr 2012 12:20:42 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q3BJKGt5000734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 11 Apr 2012 21:20:22 +0200 From: Simon Josefsson To: Peter Saint-Andre References: <4F84AAA5.3030104__43291.804000228$1334094511$gmane$org@stpeter.im> <87ehrusqf4.fsf@latte.josefsson.org> <4F85A5DF.9050701__25300.7611529485$1334160852$gmane$org@stpeter.im> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120411:stpeter@stpeter.im::ze9oU4SQx/bMsDzs:1Hwa X-Hashcash: 1:22:120411:kitten@ietf.org::TuJskUC7Sq5HBPIY:AOAe Date: Wed, 11 Apr 2012 21:20:05 +0200 In-Reply-To: <4F85A5DF.9050701__25300.7611529485$1334160852$gmane$org@stpeter.im> (Peter Saint-Andre's message of "Wed, 11 Apr 2012 09:40:15 -0600") Message-ID: <87iph6qdne.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] spaces in SASL user names X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 19:20:44 -0000 Peter Saint-Andre writes: > On 4/11/12 1:01 AM, Simon Josefsson wrote: >> Peter Saint-Andre writes: >> >>> At the PRECIS WG session in Paris, we had quite a discussion >>> about spaces in user names. Alexey maintained that this must have >>> been included in SASLprep (RFC 4013) for a good reason, but the >>> reason wasn't clear to folks in the meeting. So I have a few >>> questions: >>> >>> 1. Do SASL user names really need to include spaces? >> >> I have seen real human names used for authentication identifiers >> more than once, so I believe the answer is yes. >> >> /Simon > > Thanks for the input. So my next question is: > >>> 3. If SASL user names *do* need to include spaces, would it be >>> fine to define simple user names in SASL as a space-separated >>> list of NameClass entities? >>> >>> Option #3 seems preferable to (a) specifying that the PRECIS >>> NameClass needs to include space (to which there was a lot of >>> resistance during the PRECIS WG session), (b) enabling folks to >>> superclass PRECIS string classes (to which there was also a lot >>> of resistance), or (c) severely subclassing the PRECIS FreeClass >>> to be something like NameClass+SP. > > Feedback is welcome. :) I believe there is some serious terminology issue if there is resistance to including space into a class of characters defined like this: NameClass: a sequence of letters, numbers, and symbols that is used to identify or address a network entity such as a user account, a venue (e.g., a chatroom), an information source (e.g., a data feed), or a collection of data (e.g., a file). Reflecting on my own usage, I have used SP in most of these types of identifiers. Some I use daily (user accounts and filenames). /Simon From simon@josefsson.org Thu Apr 12 02:27:08 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9418621F85E4 for ; Thu, 12 Apr 2012 02:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.842 X-Spam-Level: X-Spam-Status: No, score=-99.842 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ev-Ij3m96QII for ; Thu, 12 Apr 2012 02:27:07 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6854B21F85D9 for ; Thu, 12 Apr 2012 02:27:06 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q3C9Qv5E006275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 12 Apr 2012 11:26:59 +0200 X-Hashcash: 1:22:120412:kitten@ietf.org::tF3uT9yqIW+2fqQp:HJiw From: Simon Josefsson To: kitten@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Thu, 12 Apr 2012 11:26:57 +0200 Message-ID: <87sjg9pafy.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Subject: [kitten] SASL resumption? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 09:27:08 -0000 All, When experimenting with the OPENID20/SAML20 mechanisms, I've been reminded that a usual pattern for SASL clients is to open several connections to a server. Traditionally this hasn't been a problem: the passphrase or Kerberos ticket is cached so the client re-handshakes SASL using CRAM-MD5, SCRAM-SHA-1 or GSS-API. Both OPENID20 and SAML20 potentially need human interaction that can be be slow. Other mechanisms (e.g., SAML20EC and GSS-EAP) are less dependent on human interaction but can still be slow. Thus we have a problem that 1) clients expect to be able to open multiple connections, and 2) some mechanisms may be costly to perform. I see some solutions: 1) Recommend that OPENID20 and SAML20 are deployed in ways that minimize human interaction. Normally, IdPs have an option of remembering an authorization decision of a user, so by using that, OPENID20/SAML20 can complete more quickly: the user would just see several browser windows flash by. This mitigate the consequences of the problem, but doesn't solve it. 2) Consider a SASL resumption mechanism. This could work by having the server compute a cookie that the client could present later on to get the same access it got last time. I'm not sure if this is best done by extending core SASL with resumption features or adding a new mechanism-negotiating-mechanism that handles resumption and invokes some other mechanism. Neither approach is appealing to me. 3) Rely on the secure channel resumption capabilities. Clients appear to be able to implement TLS resume. We could use an EXTERNAL-like mechanism that leverages the SASL state associated with the last TLS channel, e.g. EXTERNAL-RESUME-TLS. I don't think EXTERNAL will work, its semantics is too under-specified and the failures are difficult to recover from. If the EXTERNAL-RESUME-TLS mechanism is advertised the server has some SASL state stored for the client, and the client could decide to leverage that, or start a completely new handshake. The client could also more gracefully handle failures in EXTERNAL-RESUME-TLS (e.g., session expiration) and fall back to the initial SASL mechanism used. The EXTERNAL-RESUME-TLS could be GSS-API mechanism too. Are there other solutions? Thoughts? The background for this is the following discussion: http://thread.gmane.org/gmane.comp.security.lasso.devel/171/focus=187 /Simon From dave@cridland.net Thu Apr 12 02:48:20 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27EB621F8658 for ; Thu, 12 Apr 2012 02:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxndCxYfnm2w for ; Thu, 12 Apr 2012 02:48:19 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 567FF21F8656 for ; Thu, 12 Apr 2012 02:48:19 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id A59FB116808F; Thu, 12 Apr 2012 10:48:15 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ve8-H-O7xUan; Thu, 12 Apr 2012 10:48:11 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 5F37C116808D; Thu, 12 Apr 2012 10:48:11 +0100 (BST) References: <87sjg9pafy.fsf@latte.josefsson.org> In-Reply-To: <87sjg9pafy.fsf@latte.josefsson.org> MIME-Version: 1.0 Message-Id: <6155.1334224091.360331@puncture> Date: Thu, 12 Apr 2012 10:48:11 +0100 From: Dave Cridland To: Simon Josefsson , Common Authentication Technologies - Next Generation Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [kitten] SASL resumption? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 09:48:20 -0000 On Thu Apr 12 10:26:57 2012, Simon Josefsson wrote: > 3) Rely on the secure channel resumption capabilities. Clients > appear > to be able to implement TLS resume. We could use an EXTERNAL-like > mechanism that leverages the SASL state associated with the last TLS > channel, e.g. EXTERNAL-RESUME-TLS. I don't think EXTERNAL will > work, > its semantics is too under-specified and the failures are difficult > to > recover from. If the EXTERNAL-RESUME-TLS mechanism is advertised > the > server has some SASL state stored for the client, and the client > could > decide to leverage that, or start a completely new handshake. The > client could also more gracefully handle failures in > EXTERNAL-RESUME-TLS > (e.g., session expiration) and fall back to the initial SASL > mechanism > used. The EXTERNAL-RESUME-TLS could be GSS-API mechanism too. I proposed this a few years ago, and was met with a combination of mistrust and apathy, so I never bothered persuing it: http://tools.ietf.org/draft/draft-cridland-sasl-tls-sessions/ An alternative would be to construct a slightly different approach wherein a client used some shared secret property of the existing TLS channel as a shared secret for some (simple) mechanism. Of course, this has the disadvantage that you'd be implicitly provisioning your account with a plaintext equivalent shared secret... One problem with either approach is that if you use a public terminal, you implicitly allow reuse of the established credential - as such, my gut feeling is that the TLS channel would need to be explicitly enabled as possible to reuse for authentication, and so would need some extensions to TLS to make it work well. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From simon@josefsson.org Thu Apr 12 03:04:10 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E88521F8608 for ; Thu, 12 Apr 2012 03:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.845 X-Spam-Level: X-Spam-Status: No, score=-99.845 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecb-oDj-LHdc for ; Thu, 12 Apr 2012 03:04:10 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id A520921F85D7 for ; Thu, 12 Apr 2012 03:04:09 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q3CA3xox007880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 12 Apr 2012 12:04:01 +0200 From: Simon Josefsson To: Dave Cridland References: <87sjg9pafy.fsf@latte.josefsson.org> <6155.1334224091.360331__11585.1301853128$1334224105$gmane$org@puncture> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120412:dave@cridland.net::keqrUEK6ccNUQO2y:1I4s X-Hashcash: 1:22:120412:kitten@ietf.org::EmA7Xyxwnj51Hehq:6qL0 Date: Thu, 12 Apr 2012 12:03:59 +0200 In-Reply-To: <6155.1334224091.360331__11585.1301853128$1334224105$gmane$org@puncture> (Dave Cridland's message of "Thu, 12 Apr 2012 10:48:11 +0100") Message-ID: <87d37dp8q8.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: Common Authentication Technologies - Next Generation Subject: Re: [kitten] SASL resumption? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 10:04:10 -0000 Dave Cridland writes: > On Thu Apr 12 10:26:57 2012, Simon Josefsson wrote: >> 3) Rely on the secure channel resumption capabilities. > > I proposed this a few years ago, and was met with a combination of > mistrust and apathy, so I never bothered persuing it: > > http://tools.ietf.org/draft/draft-cridland-sasl-tls-sessions/ Perhaps, as they say, the time for it has come. I'm not sure re-using EXTERNAL for this will work well in practice though. There are other use-cases for EXTERNAL which makes it difficult for clients and servers to know whether your draft or something else is intended. To me, EXTERNAL is difficult to deploy in any interoperable fashion. (That was the motivation for [1] btw...) > An alternative would be to construct a slightly different approach > wherein a client used some shared secret property of the existing TLS > channel as a shared secret for some (simple) mechanism. Of course, > this has the disadvantage that you'd be implicitly provisioning your > account with a plaintext equivalent shared secret... Right. If the mechanism is specific for this use-case, I'm not that concerned with security issue you mentioned: servers can refuse to advertise the mechanism if they don't like its properties, and clients can refuse to use the mechanism if they don't like its properties. > One problem with either approach is that if you use a public terminal, > you implicitly allow reuse of the established credential - > as such, my gut feeling is that the TLS channel would need to be > explicitly enabled as possible to reuse for authentication, and so > would need some extensions to TLS to make it work well. The decision whether to allow the current session for resumption or not could be made in the application protocol too. However I agree this is a serious problem, and maybe it applies to all solutions in this space. /Simon [1] https://tools.ietf.org/html/draft-josefsson-sasl-external-channel-04 From cantor.2@osu.edu Thu Apr 12 07:59:41 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02D221F8652 for ; Thu, 12 Apr 2012 07:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxjuLCzyLkyX for ; Thu, 12 Apr 2012 07:59:41 -0700 (PDT) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id 479C721F8607 for ; Thu, 12 Apr 2012 07:59:38 -0700 (PDT) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q3CExaUo024640; Thu, 12 Apr 2012 10:59:36 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi id 14.01.0355.002; Thu, 12 Apr 2012 10:59:30 -0400 From: "Cantor, Scott" To: Simon Josefsson , "kitten@ietf.org" Thread-Topic: [kitten] SASL resumption? Thread-Index: AQHNGI5zkAp2mKsWV0Sin9ZVAx7ZJZaXRw1A Date: Thu, 12 Apr 2012 14:59:29 +0000 Message-ID: References: <87sjg9pafy.fsf@latte.josefsson.org> In-Reply-To: <87sjg9pafy.fsf@latte.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.160.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Subject: Re: [kitten] SASL resumption? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 14:59:42 -0000 > Both OPENID20 and SAML20 potentially need human interaction that can be > be slow. Other mechanisms (e.g., SAML20EC and GSS-EAP) are less > dependent on human interaction but can still be slow. In the case of SAMLEC, a likely solution is to get moved to holder of key s= o that a longer lived assertion can be issued to the client and then used a= s a multi-use token. That isn't 100% drop-in to the existing profile but it= 's very doable when the client isn't braindead. I still think you need a solution, just saying I was aware of the problem a= nd had at least some long term plan for it. > 3) Rely on the secure channel resumption capabilities. Clients appear > to be able to implement TLS resume. Assuming that's true, do servers? How often? What if there are concentrator= s and offloading involved, which is true of the vast majority of deploys. I= f you're depending on the server having actual access to the TLS session in= some way, that's probably a non-starter. I don't know enough about TLS to = know if that's what you're assuming. -- Scott From dave@cridland.net Thu Apr 12 08:27:02 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90D921F8483 for ; Thu, 12 Apr 2012 08:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpT+q4VOqjZw for ; Thu, 12 Apr 2012 08:27:02 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0F321F8467 for ; Thu, 12 Apr 2012 08:27:01 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id A98E5116808F; Thu, 12 Apr 2012 16:26:56 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j97KpdxO4iS0; Thu, 12 Apr 2012 16:26:53 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 53935116808D; Thu, 12 Apr 2012 16:26:53 +0100 (BST) References: <87sjg9pafy.fsf@latte.josefsson.org> <6155.1334224091.360331__11585.1301853128$1334224105$gmane$org@puncture> <87d37dp8q8.fsf@latte.josefsson.org> In-Reply-To: <87d37dp8q8.fsf@latte.josefsson.org> MIME-Version: 1.0 Message-Id: <6155.1334244413.294592@puncture> Date: Thu, 12 Apr 2012 16:26:53 +0100 From: Dave Cridland To: Simon Josefsson , Common Authentication Technologies - Next Generation Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [kitten] SASL resumption? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 15:27:03 -0000 On Thu Apr 12 11:03:59 2012, Simon Josefsson wrote: > Dave Cridland writes: > > > On Thu Apr 12 10:26:57 2012, Simon Josefsson wrote: > >> 3) Rely on the secure channel resumption capabilities. > > > > I proposed this a few years ago, and was met with a combination of > > mistrust and apathy, so I never bothered persuing it: > > > > http://tools.ietf.org/draft/draft-cridland-sasl-tls-sessions/ > > Perhaps, as they say, the time for it has come. > > I'm not sure re-using EXTERNAL for this will work well in practice > though. There are other use-cases for EXTERNAL which makes it > difficult > for clients and servers to know whether your draft or something > else is > intended. To me, EXTERNAL is difficult to deploy in any > interoperable > fashion. (That was the motivation for [1] btw...) > > Yes, I follow your logic - I've personally found EXTERNAL to be fine, albeit I've also found that for reliable usage one always need to specify an authzid somehow. The rest of your mail I entirely agree with. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From dave@cridland.net Thu Apr 12 08:28:17 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F0221F8570 for ; Thu, 12 Apr 2012 08:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EG4IAKlMUlnz for ; Thu, 12 Apr 2012 08:28:17 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 3D93621F8569 for ; Thu, 12 Apr 2012 08:28:17 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 6964E116808F; Thu, 12 Apr 2012 16:28:16 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VgXXDTbTMkb; Thu, 12 Apr 2012 16:28:14 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id CE112116808D; Thu, 12 Apr 2012 16:28:13 +0100 (BST) References: <87sjg9pafy.fsf@latte.josefsson.org> In-Reply-To: MIME-Version: 1.0 Message-Id: <6155.1334244493.839710@puncture> Date: Thu, 12 Apr 2012 16:28:13 +0100 From: Dave Cridland To: "Cantor\, Scott" , Simon Josefsson , Common Authentication Technologies - Next Generation Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [kitten] SASL resumption? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 15:28:17 -0000 On Thu Apr 12 15:59:29 2012, Cantor, Scott wrote: > Assuming that's true, do servers? How often? What if there are > concentrators and offloading involved, which is true of the vast > majority of deploys. If you're depending on the server having > actual access to the TLS session in some way, that's probably a > non-starter. I don't know enough about TLS to know if that's what > you're assuming. I think that's true only for HTTPS - for other protocols, such as XMPP or IMAP, I'd have thought that TLS offloaders and/or proxies would be fairly rare. These types of protocols are the hunting-ground here - IMAP clients often open multiple connections, and XMPP clients need very rapid reconnect. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From cantor.2@osu.edu Thu Apr 12 08:47:51 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B04B21F8698 for ; Thu, 12 Apr 2012 08:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEsbDkLtjYqN for ; Thu, 12 Apr 2012 08:47:51 -0700 (PDT) Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id C874521F8693 for ; Thu, 12 Apr 2012 08:47:50 -0700 (PDT) Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q3CFlen0022471; Thu, 12 Apr 2012 11:47:45 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi id 14.01.0355.002; Thu, 12 Apr 2012 11:47:34 -0400 From: "Cantor, Scott" To: Dave Cridland , Simon Josefsson , Common Authentication Technologies - Next Generation Thread-Topic: [kitten] SASL resumption? Thread-Index: AQHNGI5zkAp2mKsWV0Sin9ZVAx7ZJZaXRw1AgABMo4D//8HFEA== Date: Thu, 12 Apr 2012 15:47:33 +0000 Message-ID: References: <87sjg9pafy.fsf@latte.josefsson.org> <6155.1334244493.839710@puncture> In-Reply-To: <6155.1334244493.839710@puncture> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.160.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.171; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.225 Subject: Re: [kitten] SASL resumption? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 15:47:51 -0000 > I think that's true only for HTTPS - for other protocols, such as > XMPP or IMAP, I'd have thought that TLS offloaders and/or proxies > would be fairly rare. These types of protocols are the hunting-ground > here - IMAP clients often open multiple connections, and XMPP clients > need very rapid reconnect. AFAIK, it's not at all rare. Especially for mail. At some enterprises, ther= e are pushes to consolidate all TLS handling in a load balancer and maintai= n the certs there, regardless of the protocol. Leaving that aside, am I correct that it would be a deal breaker? We can di= sagree whether it's a problem (or leave that as a community specific questi= on), but it's useful for me in evaluating the potential of the suggestion. -- Scott From simon@josefsson.org Thu Apr 12 12:29:58 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2593C21F8611 for ; Thu, 12 Apr 2012 12:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.848 X-Spam-Level: X-Spam-Status: No, score=-99.848 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dqHT6IOtwZu for ; Thu, 12 Apr 2012 12:29:57 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7741E21F85D7 for ; Thu, 12 Apr 2012 12:29:54 -0700 (PDT) Received: from [192.168.1.42] (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q3CJTlJt001319 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 12 Apr 2012 21:29:48 +0200 From: Simon Josefsson To: "Cantor, Scott" In-Reply-To: References: <87sjg9pafy.fsf@latte.josefsson.org> <6155.1334244493.839710@puncture> Content-Type: text/plain; charset="UTF-8" Date: Thu, 12 Apr 2012 21:29:46 +0200 Message-ID: <1334258986.17965.15.camel@latte.josefsson.org> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: Common Authentication Technologies - Next Generation Subject: Re: [kitten] SASL resumption? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 19:29:58 -0000 tor 2012-04-12 klockan 15:47 +0000 skrev Cantor, Scott: > > I think that's true only for HTTPS - for other protocols, such as > > XMPP or IMAP, I'd have thought that TLS offloaders and/or proxies > > would be fairly rare. These types of protocols are the hunting-ground > > here - IMAP clients often open multiple connections, and XMPP clients > > need very rapid reconnect. > > AFAIK, it's not at all rare. Especially for mail. At some enterprises, there are pushes to consolidate all TLS handling in a load balancer and maintain the certs there, regardless of the protocol. > > Leaving that aside, am I correct that it would be a deal breaker? We can disagree whether it's a problem (or leave that as a community specific question), but it's useful for me in evaluating the potential of the suggestion. If the TLS stack used doesn't support TLS resumption, there is no way that we can implement SASL resumption using TLS resumption, so that would indeed be a deal breaker for that approach. I agree with Dave that I think this view of TLS stacks is HTTPS-biased. In my experience, with SMTP/IMAP/XMPP you cannot terminate the TLS session at one point and then forward the unencrypted session somewhere else and expect that the "somewhere else" will work without special customization to both the TLS stack and the SMTP/IMAP/XMPP side. It messes up authorization and STARTTLS negotiations. Do you have any pointers to implementations of TLS load balancers that support SMTP/IMAP/XMPP with STARTTLS? My point is that if there is some protocol between the TLS stack and SMTP/IMAP/XMPP servers to send the necessary TLS information, that protocol could be enhanced with the TLS-resume related information. I'm hoping that these environments are rare though. However, SASL resume would be a new feature, so it isn't unreasonable for it to require certain things which aren't unversally implemented. Of course, it would be better if we could implement SASL-resume using something that we know was available everywhere already. But maybe it is better to have solved the problem for a subset of installations than to not have solved the problem at all. /Simon From wmills@yahoo-inc.com Fri Apr 13 09:21:49 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0865821F8808 for ; Fri, 13 Apr 2012 09:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.098 X-Spam-Level: X-Spam-Status: No, score=-16.098 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wTZ2yTvkB22 for ; Fri, 13 Apr 2012 09:21:19 -0700 (PDT) Received: from nm16-vm1.bullet.mail.ne1.yahoo.com (nm16-vm1.bullet.mail.ne1.yahoo.com [98.138.91.47]) by ietfa.amsl.com (Postfix) with SMTP id BBD8B21F8806 for ; Fri, 13 Apr 2012 09:21:19 -0700 (PDT) Received: from [98.138.90.56] by nm16.bullet.mail.ne1.yahoo.com with NNFMP; 13 Apr 2012 16:21:16 -0000 Received: from [98.138.86.157] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 13 Apr 2012 16:21:16 -0000 Received: from [127.0.0.1] by omp1015.mail.ne1.yahoo.com with NNFMP; 13 Apr 2012 16:21:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 549672.28266.bm@omp1015.mail.ne1.yahoo.com Received: (qmail 84740 invoked by uid 60001); 13 Apr 2012 16:21:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1334334076; bh=0W1aXbX8gLPl7LlsDFA5elFWrnTfPzNw6UibR2kIvVk=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=HzvQJj0yMb/lfXRUwoZN4JaXXFphdTJoXVCfZLjy48Nv59LOIwsgWi+NlJTGNd0utI+t4MLoBOWhRFTqMvh6Cu5zhhj8GEgpTLbsu+NXSxVUMUyUxzg7UncjHLWzGhPE+o15LaQIcENaKsKshxEeleQH2BhuGvyFbz/UfAm0oH8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=lciCywSz9Z+moXCcNaMy94k4QVZ7hQUymbsYY2e4cbKAhVhwFdfIbwtetrk+XCnv31PHqA2UUAQgJvG3u4yPBON3CCypDwfh7MzFVpMatuanGD3Zk4CY0BLFiWU6X6gSVDnZz4MF4/gVPeL4Xb14GXLMeTTX80yAYhTQG27bkf0=; X-YMail-OSG: avOexp4VM1kTp19weHuv5pwMtSExk54iTQSm4nVayNC23AJ b4rqVxJExVq1KSCD5h40lnMvMEMPVLxbPabv5xJEIvEvU6yX2y2k7EclKA.y TgK0HS48WvCyAO0xJ_xhnaiG.TJTtPxdGfJN4zrrlQ45DzMrEiQamUIIK0K4 bAOCi3pJ38EOrb0lGTJeHQl_zEO8vU2mwfg2Gp5ejIgGvkPr7yuNcK8NxZuB Wo4fmbsS3e46TnJSiqOvmHOSJj.viXPEfM2tN4wemBveAkv6cS3yyqhrhtMp H.XKze6sXRSph5U4zjGIFqTpNBgRcu7XgcUj7_oCjJSqoi8QoQVEEcp.7TA. tEdBxRzGKQzZ7IZoKERBosj5gNqLy7RKGcZ93IIgSTe6aaN2N2NmaWpgN.t_ Gahk40vyWaMDDmN8CpmhQHwGokFvr6arBtkXEA2obxRg_WVO3yWHGq.noX8u RQNm1SMG3CpupGj5XiBoU2iNn4_5wp7wjTeLFsxXL1r7r..iO1GjIRpk7jsC Xu0oBVHaaIUynSRvRrUeH.M9PhSsP0g-- Received: from [99.31.212.42] by web31806.mail.mud.yahoo.com via HTTP; Fri, 13 Apr 2012 09:21:15 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <87sjg9pafy.fsf@latte.josefsson.org> Message-ID: <1334334075.83509.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Fri, 13 Apr 2012 09:21:15 -0700 (PDT) From: William Mills To: Simon Josefsson , "kitten@ietf.org" In-Reply-To: <87sjg9pafy.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1055047407-312840099-1334334075=:83509" Subject: Re: [kitten] SASL resumption? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 16:21:49 -0000 ---1055047407-312840099-1334334075=:83509 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I would argue that for things like IMAP that require multiple connections a= nd reconnections that you want something like OAuth credentials to use.=A0 = Your resource server could issue a bearer or SAML (or other) token to use o= n reconnect as a result of the initial negotiation, but it would seem clean= er to put up an OAuth 2 style flow with OpenID as the authn mechanism.=0A= =0AWe certainly encountered the problem of multiple simultaneous connection= s in the IMAP context for the OAuth stuff.=A0 My tentative solution was tha= t the client needs to understand that it's fetching a reusable credential a= nd it locks the cred store if it needs to authenticate.=A0 As such it's an = implementation feature rather than a protocol one.=A0 =0A=0A=0A=0A=0A=0A=0A= >________________________________=0A> From: Simon Josefsson =0A>To: kitten@ietf.org =0A>Sent: Thursday, April 12, 2012 2:26 AM=0A= >Subject: [kitten] SASL resumption?=0A> =0A>All,=0A>=0A>When experimenting = with the OPENID20/SAML20 mechanisms, I've been=0A>reminded that a usual pat= tern for SASL clients is to open several=0A>connections to a server.=A0 Tra= ditionally this hasn't been a problem: the=0A>passphrase or Kerberos ticket= is cached so the client re-handshakes SASL=0A>using CRAM-MD5, SCRAM-SHA-1 = or GSS-API.=0A>=0A>Both OPENID20 and SAML20 potentially need human interact= ion that can be=0A>be slow.=A0 Other mechanisms (e.g., SAML20EC and GSS-EAP= ) are less=0A>dependent on human interaction but can still be slow.=0A>=0A>= Thus we have a problem that 1) clients expect to be able to open=0A>multipl= e connections, and 2) some mechanisms may be costly to perform.=0A>=0A>I se= e some solutions:=0A>=0A>1) Recommend that OPENID20 and SAML20 are deployed= in ways that minimize=0A>human interaction.=A0 Normally, IdPs have an opti= on of remembering an=0A>authorization decision of a user, so by using that,= OPENID20/SAML20 can=0A>complete more quickly: the user would just see seve= ral browser windows=0A>flash by.=A0 This mitigate the consequences of the p= roblem, but doesn't=0A>solve it.=0A>=0A>2) Consider a SASL resumption mecha= nism.=A0 This could work by having the=0A>server compute a cookie that the = client could present later on to get=0A>the same access it got last time.= =A0 I'm not sure if this is best done by=0A>extending core SASL with resump= tion features or adding a new=0A>mechanism-negotiating-mechanism that handl= es resumption and invokes some=0A>other mechanism.=A0 Neither approach is a= ppealing to me.=0A>=0A>3) Rely on the secure channel resumption capabilitie= s.=A0 Clients appear=0A>to be able to implement TLS resume.=A0 We could use= an EXTERNAL-like=0A>mechanism that leverages the SASL state associated wit= h the last TLS=0A>channel, e.g. EXTERNAL-RESUME-TLS.=A0 I don't think EXTER= NAL will work,=0A>its semantics is too under-specified and the failures are= difficult to=0A>recover from.=A0 If the EXTERNAL-RESUME-TLS mechanism is a= dvertised the=0A>server has some SASL state stored for the client, and the = client could=0A>decide to leverage that, or start a completely new handshak= e.=A0 The=0A>client could also more gracefully handle failures in EXTERNAL-= RESUME-TLS=0A>(e.g., session expiration) and fall back to the initial SASL = mechanism=0A>used.=A0 The EXTERNAL-RESUME-TLS could be GSS-API mechanism to= o.=0A>=0A>Are there other solutions?=A0 Thoughts?=0A>=0A>The background for= this is the following discussion: =0A>http://thread.gmane.org/gmane.comp.s= ecurity.lasso.devel/171/focus=3D187=0A>=0A>/Simon=0A>______________________= _________________________=0A>Kitten mailing list=0A>Kitten@ietf.org=0A>http= s://www.ietf.org/mailman/listinfo/kitten=0A>=0A>=0A> ---1055047407-312840099-1334334075=:83509 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I would argue that for things like IMAP that require multiple connections= and reconnections that you want something like OAuth credentials to use.&n= bsp; Your resource server could issue a bearer or SAML (or other) token to = use on reconnect as a result of the initial negotiation, but it would seem = cleaner to put up an OAuth 2 style flow with OpenID as the authn mechanism.=

We certainly encountere= d the problem of multiple simultaneous connections in the IMAP context for = the OAuth stuff.  My tentative solution was that the client needs to u= nderstand that it's fetching a reusable credential and it locks the cred st= ore if it needs to authenticate.  As such it's an implementation featu= re rather than a protocol one. 


<= div>
=
From: Simon Josefsson= <simon@josefsson.org>
To:<= /span> kitten@ietf.org
Sent:= Thursday, April 12, 2012 2:26 AM
Subject: [kitten] SASL resumption?
=0AAll,

When experimenting with the OPENID20/SAML20 mechanisms= , I've been
reminded that a usual pattern for SASL clients is to open se= veral
connections to a server.  Traditionally this hasn't been a pr= oblem: the
passphrase or Kerberos ticket is cached so the client re-hand= shakes SASL
using CRAM-MD5, SCRAM-SHA-1 or GSS-API.

Both OPENID20= and SAML20 potentially need human interaction that can be
be slow. = ; Other mechanisms (e.g., SAML20EC and GSS-EAP) are less
dependent on hu= man interaction but can still be slow.

Thus we have a problem that 1= ) clients expect to be able to open
multiple connections, and 2) some me= chanisms may be costly to perform.

I see some solutions:

1) R= ecommend that OPENID20 and SAML20 are deployed in ways that minimize
hum= an interaction.  Normally, IdPs have an option of remembering an
au= thorization decision of a user, so by using that, OPENID20/SAML20 can
complete more quickly: the user would just see several browser wind= ows
flash by.  This mitigate the consequences of the problem, but d= oesn't
solve it.

2) Consider a SASL resumption mechanism.  T= his could work by having the
server compute a cookie that the client cou= ld present later on to get
the same access it got last time.  I'm n= ot sure if this is best done by
extending core SASL with resumption feat= ures or adding a new
mechanism-negotiating-mechanism that handles resump= tion and invokes some
other mechanism.  Neither approach is appeali= ng to me.

3) Rely on the secure channel resumption capabilities.&nbs= p; Clients appear
to be able to implement TLS resume.  We could use= an EXTERNAL-like
mechanism that leverages the SASL state associated wit= h the last TLS
channel, e.g. EXTERNAL-RESUME-TLS.  I don't think EX= TERNAL will work,
its semantics is too under-specified and the failures are difficult to
recover from.  If the EXTERNAL-RESUME-TL= S mechanism is advertised the
server has some SASL state stored for the = client, and the client could
decide to leverage that, or start a complet= ely new handshake.  The
client could also more gracefully handle fa= ilures in EXTERNAL-RESUME-TLS
(e.g., session expiration) and fall back t= o the initial SASL mechanism
used.  The EXTERNAL-RESUME-TLS could b= e GSS-API mechanism too.

Are there other solutions?  Thoughts?<= br>
The background for this is the following discussion:
http://thre= ad.gmane.org/gmane.comp.security.lasso.devel/171/focus=3D187

/Simon<= br>_______________________________________________
Kitten mailing listKit= ten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten

=
---1055047407-312840099-1334334075=:83509-- From cantor.2@osu.edu Fri Apr 13 09:29:46 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E130621F881E for ; Fri, 13 Apr 2012 09:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vUILi0JQGYu for ; Fri, 13 Apr 2012 09:29:46 -0700 (PDT) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id 466FC21F8618 for ; Fri, 13 Apr 2012 09:29:46 -0700 (PDT) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q3DGT6Mk010089; Fri, 13 Apr 2012 12:29:43 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi id 14.01.0355.002; Fri, 13 Apr 2012 12:29:31 -0400 From: "Cantor, Scott" To: Simon Josefsson Thread-Topic: [kitten] SASL resumption? Thread-Index: AQHNGI5zkAp2mKsWV0Sin9ZVAx7ZJZaXRw1AgABMo4D//8HFEIAAgbgAgAEc6QA= Date: Fri, 13 Apr 2012 16:29:27 +0000 Message-ID: In-Reply-To: <1334258986.17965.15.camel@latte.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.74.80.179] Content-Type: text/plain; charset="us-ascii" Content-ID: <2EF94A4C06850844B2B37293A5BA7712@exchange.osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.168; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "kitten@ietf.org" Subject: Re: [kitten] SASL resumption? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 16:29:47 -0000 On 4/12/12 3:29 PM, "Simon Josefsson" wrote: > >I agree with Dave that I think this view of TLS stacks is HTTPS-biased. >In my experience, with SMTP/IMAP/XMPP you cannot terminate the TLS >session at one point and then forward the unencrypted session somewhere >else and expect that the "somewhere else" will work without special >customization to both the TLS stack and the SMTP/IMAP/XMPP side. It >messes up authorization and STARTTLS negotiations. What I'm familiar with is not STARTTLS but straight TLS wrapping of IMAP and things like that, so it's purely a tunnel and the load balancer strips the tunnel off and forwards it along. >Do you have any >pointers to implementations of TLS load balancers that support >SMTP/IMAP/XMPP with STARTTLS? No. >However, SASL resume would be a new feature, so it isn't unreasonable >for it to require certain things which aren't unversally implemented. >Of course, it would be better if we could implement SASL-resume using >something that we know was available everywhere already. But maybe it >is better to have solved the problem for a subset of installations than >to not have solved the problem at all. What I was trying to say was that if I was fairly sure I'd have lots of customers that would need the issue dealt with, and I didn't think they could use TLS resumption, then I'd feel obligated to work out a viable path to do it in the mechanism I'm designing. Which is more or less how I feel at the moment. I can wait on it, but I know that I'll need it, and it was something I thought about a bit. -- Scott From wwwrun@rfc-editor.org Fri Apr 13 11:02:59 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF4A11E80A1; Fri, 13 Apr 2012 11:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.162 X-Spam-Level: X-Spam-Status: No, score=-104.162 tagged_above=-999 required=5 tests=[AWL=0.915, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrvRqMwlhhzg; Fri, 13 Apr 2012 11:02:59 -0700 (PDT) Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id 696A911E809C; Fri, 13 Apr 2012 11:02:59 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E35E1B1E012; Fri, 13 Apr 2012 11:02:12 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120413180212.E35E1B1E012@rfc-editor.org> Date: Fri, 13 Apr 2012 11:02:12 -0700 (PDT) Cc: kitten@ietf.org, rfc-editor@rfc-editor.org Subject: [kitten] RFC 6595 on A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 18:03:00 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6595 Title: A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML) Author: K. Wierenga, E. Lear, S. Josefsson Status: Standards Track Stream: IETF Date: April 2012 Mailbox: klaas@cisco.com, lear@cisco.com, simon@josefsson.org Pages: 22 Characters: 49522 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-kitten-sasl-saml-09.txt URL: http://www.rfc-editor.org/rfc/rfc6595.txt The Security Assertion Markup Language (SAML) has found its usage on the Internet for Web Single Sign-On. The Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL mechanism and a GSS-API mechanism for SAML 2.0 that allows the integration of existing SAML Identity Providers with applications using SASL and GSS-API. [STANDARDS-TRACK] This document is a product of the Common Authentication Technology Next Generation Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From alexey.melnikov@isode.com Mon Apr 16 03:52:57 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6493721F872E for ; Mon, 16 Apr 2012 03:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.802 X-Spam-Level: X-Spam-Status: No, score=-101.802 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLllmimlFbh4 for ; Mon, 16 Apr 2012 03:52:56 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 480A821F8704 for ; Mon, 16 Apr 2012 03:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1334573574; d=isode.com; s=selector; i=@isode.com; bh=1ioushwE1eAAe8VpB6EO4Y37RkXffDY4xhhXW56IJxM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=FE1IWETeuLig1m2RGBqduIjmL/beD704doPOZU1MNctuv4V1BclJzXNdHtOJKEan8CNtsR GdS4bm6qeEmR+b54W82ieBfwrkVaCOuaoI67Wjx2V6RxLkFPY7Oi6q5oIUxAOc/lRSxoss 68/IZnKnIxlnRnJ+B9t6Z8bsK7wx0Nc=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 16 Apr 2012 11:52:54 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F89AB89.8050303@isode.com> Date: Sat, 14 Apr 2012 17:53:29 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Peter Saint-Andre References: <4F84AAA5.3030104@stpeter.im> <4ED1D634F0E26CDC51B61127@[192.168.15.131]> <4F85C4EE.2020901@stpeter.im> In-Reply-To: <4F85C4EE.2020901@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] spaces in SASL user names X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 10:52:57 -0000 On 11/04/2012 18:52, Peter Saint-Andre wrote: > On 4/11/12 9:48 AM, Chris Newman wrote: >> --On April 10, 2012 15:48:21 -0600 Peter Saint-Andre >> wrote: At the PRECIS WG session in Paris, we >> had quite a discussion about spaces in user names. Alexey >> maintained that this must have been included in SASLprep (RFC 4013) >> for a good reason, but the reason wasn't clear to folks in the >> meeting. So I have a few questions: >> >> 1. Do SASL user names really need to include spaces? >> >>> Absolutely yes. My correct name is "Chris Newman" (with a space). >>> A user friendly interface would use my correct name. Protocol >>> design should never unnecessarily obstruct the creation of user >>> friendly interfaces. >> 2. If SASL user names do *not* need to include spaces, would it be >> fine to re-use the PRECIS NameClass for simple user names in SASL? >> >> 3. If SASL user names *do* need to include spaces, would it be fine >> to define simple user names in SASL as a space-separated list of >> NameClass entities? >> >>> I am opposed to changing to the SASL user name ABNF in the >>> mechanisms, with RFC 4616 being the simplest example of that >>> ABNF. Given that constraint, I have little opinion about how >>> PRECIS is used. So the proposal sounds feasible as long as we're >>> not making ABNF changes to the underlying protocol. > The document that Alexey and I are working on will not override the > ABNF in any given mechanism spec (e.g., RFC 4616). However, we'll > probably want to look at how this work interacts with existing > mechanisms (e.g., would we need to update those mechanism specs to use > the PRECIS approach instead of the stringprep approach?). Yes. But hopefully several SASL mechanisms can be updated by a single document. From wmills@yahoo-inc.com Mon Apr 16 08:03:54 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983E511E8073 for ; Mon, 16 Apr 2012 08:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.285 X-Spam-Level: X-Spam-Status: No, score=-16.285 tagged_above=-999 required=5 tests=[AWL=-0.546, BAYES_20=-0.74, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WeRwUTD4V55 for ; Mon, 16 Apr 2012 08:03:53 -0700 (PDT) Received: from nm33-vm7.bullet.mail.bf1.yahoo.com (nm33-vm7.bullet.mail.bf1.yahoo.com [72.30.239.207]) by ietfa.amsl.com (Postfix) with SMTP id 7EC8E11E8072 for ; Mon, 16 Apr 2012 08:03:53 -0700 (PDT) Received: from [98.139.212.153] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 16 Apr 2012 15:03:52 -0000 Received: from [98.139.215.252] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 16 Apr 2012 15:03:52 -0000 Received: from [127.0.0.1] by omp1065.mail.bf1.yahoo.com with NNFMP; 16 Apr 2012 15:03:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 933460.84185.bm@omp1065.mail.bf1.yahoo.com Received: (qmail 10184 invoked by uid 60001); 16 Apr 2012 15:03:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1334588632; bh=H44kSY8xO7+X8vd8LsO9L4X2AlT2bxHbvkSABB3znlo=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=islPnOKRr+VWvb+w3rYc2LcbXgrjakCEPEunC+8Sicp6Jlr1Lpg6yVy4+7h8rKTGT5Wfj2yZ5BG+AmkaMi9qdXIIr4OreBTyM4Y9VxgJ2Vtbtbtvo4TDDIBNulrrnpkk1aTWWYIf3iRhGCwRBMqhuZzfMgGtc9ddBPG3P2LVMKU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=TVV3oE2QbiID26lkszM9WF8GmC4KZ+2EHoM6xIfTaotXsBzoB+RfUz1HwJvflna9OFp2lWBNxeWvCRyYNscyv7xQr8yE8C01e29zGR6vpdgmpOZwpmjisQjx6CwNsARG0BqAYpEBvb5bx5gL7r7YMGQAd6g/FfdgzreQrmDS0Ro=; X-YMail-OSG: .bymN44VM1k0DsX4DbfVGP7Bl7mPnmXav49Zron9dC5CZds bsvLpxAFSUIqkmfXgIsgX_krY9alDbUy28IVYL2rUkTgMWWUDsS32GFwiytZ BCb2WV.9JVnp1nKy1UFndqkMiteMsPI8SKLHz1IBEuFZ6rOBiOqIL1eKI_y6 kxMsYL11e95Ic6gBxeacaNDdBBMGBJ8Uv138QlofkkuI5LrnraIoKbmK3gGL Z99EVY5e1wDRNHDpTbn6uGfq_QWoOwgAqcGVCeMH3507DB.K_k5KRktM0OOz W1pXIL7xuBjHCvpE0MJozlDYLHWTgJ8JsyhyoYJEcTRobndscbespbPSanu_ vrJbmLQb0Yltb3LW_f1dNhlXM8.8C0vP30hnRr0gIkmAQi2HCCdH3ygMqIn4 q4GuKUZqt6syK45e0UDTwgUHYgMGm Received: from [99.31.212.42] by web31804.mail.mud.yahoo.com via HTTP; Mon, 16 Apr 2012 08:03:52 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <4F84AAA5.3030104@stpeter.im> <4ED1D634F0E26CDC51B61127@[192.168.15.131]> <4F85C4EE.2020901@stpeter.im> <4F89AB89.8050303@isode.com> Message-ID: <1334588632.6583.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Mon, 16 Apr 2012 08:03:52 -0700 (PDT) From: William Mills To: Alexey Melnikov , Peter Saint-Andre In-Reply-To: <4F89AB89.8050303@isode.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="835683298-1207081084-1334588632=:6583" Cc: "kitten@ietf.org" Subject: Re: [kitten] spaces in SASL user names X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 15:03:54 -0000 --835683298-1207081084-1334588632=:6583 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable It should be noted that SMTP allows "domain specific usernames" with an ext= remely broad syntax that includes spaces.=0A=0A=0A=0A=0A>__________________= ______________=0A> From: Alexey Melnikov =0A>To:= Peter Saint-Andre =0A>Cc: kitten@ietf.org =0A>Sent: S= aturday, April 14, 2012 9:53 AM=0A>Subject: Re: [kitten] spaces in SASL use= r names=0A> =0A>On 11/04/2012 18:52, Peter Saint-Andre wrote:=0A>> On 4/11/= 12 9:48 AM, Chris Newman wrote:=0A>>> --On April 10, 2012 15:48:21 -0600 Pe= ter Saint-Andre=0A>>> =A0 wrote: At the PRECIS WG sessi= on in Paris, we=0A>>> had quite a discussion about spaces in user names. Al= exey=0A>>> maintained that this must have been included in SASLprep (RFC 40= 13)=0A>>> for a good reason, but the reason wasn't clear to folks in the=0A= >>> meeting. So I have a few questions:=0A>>>=0A>>> 1. Do SASL user names r= eally need to include spaces?=0A>>>=0A>>>> Absolutely yes. My correct name = is "Chris Newman" (with a space).=0A>>>> A user friendly interface would us= e my correct name. Protocol=0A>>>> design should never unnecessarily obstru= ct the creation of user=0A>>>> friendly interfaces.=0A>>> 2. If SASL user n= ames do *not* need to include spaces, would it be=0A>>> fine to re-use the = PRECIS NameClass for simple user names in SASL?=0A>>>=0A>>> 3. If SASL user= names *do* need to include spaces, would it be fine=0A>>> to define simple= user names in SASL as a space-separated list of=0A>>> NameClass entities?= =0A>>>=0A>>>> I am opposed to changing to the SASL user name ABNF in the=0A= >>>> mechanisms, with RFC 4616 being the simplest example of that=0A>>>> AB= NF. Given that constraint, I have little opinion about how=0A>>>> PRECIS is= used. So the proposal sounds feasible as long as we're=0A>>>> not making A= BNF changes to the underlying protocol.=0A>> The document that Alexey and I= are working on will not override the=0A>> ABNF in any given mechanism spec= (e.g., RFC 4616). However, we'll=0A>> probably want to look at how this wo= rk interacts with existing=0A>> mechanisms (e.g., would we need to update t= hose mechanism specs to use=0A>> the PRECIS approach instead of the stringp= rep approach?).=0A>Yes. But hopefully several SASL mechanisms can be update= d by a single =0A>document.=0A>=0A>________________________________________= _______=0A>Kitten mailing list=0A>Kitten@ietf.org=0A>https://www.ietf.org/m= ailman/listinfo/kitten=0A>=0A>=0A> --835683298-1207081084-1334588632=:6583 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
It should be noted that SMTP allows "domain specific usernames" with an e= xtremely broad syntax that includes spaces.

From: Alexey Melnikov <alexey.melnik= ov@isode.com>
To: P= eter Saint-Andre <stpeter@stpeter.im>
Cc: kitten@ietf.org
Sent: Saturday, April 14, 2012 9:53 AM
Subject: Re: [kitten] spaces in SASL us= er names

=0AOn 11/04/2012 18:52, Peter Saint-Andre w= rote:
> On 4/11/12 9:48 AM, Chris Newman wrote:
>> --On Apri= l 10, 2012 15:48:21 -0600 Peter Saint-Andre
>> <stpeter@stpete= r.im>  wrote: At the PRECIS WG session in Paris, we
>>= had quite a discussion about spaces in user names. Alexey
>> main= tained that this must have been included in SASLprep (RFC 4013)
>>= for a good reason, but the reason wasn't clear to folks in the
>>= meeting. So I have a few questions:
>>
>> 1. Do SASL use= r names really need to include spaces?
>>
>>> Absolute= ly yes. My correct name is "Chris Newman" (with a space).
>>> A= user friendly interface would use my correct name. Protocol
>>>= ; design should never unnecessarily obstruct the creation of user
>&g= t;> friendly interfaces.
>> 2. If SASL user names do *not* need to include spa= ces, would it be
>> fine to re-use the PRECIS NameClass for simple= user names in SASL?
>>
>> 3. If SASL user names *do* nee= d to include spaces, would it be fine
>> to define simple user nam= es in SASL as a space-separated list of
>> NameClass entities?
= >>
>>> I am opposed to changing to the SASL user name ABN= F in the
>>> mechanisms, with RFC 4616 being the simplest examp= le of that
>>> ABNF. Given that constraint, I have little opini= on about how
>>> PRECIS is used. So the proposal sounds feasibl= e as long as we're
>>> not making ABNF changes to the underlyin= g protocol.
> The document that Alexey and I are working on will not = override the
> ABNF in any given mechanism spec (e.g., RFC 4616). How= ever, we'll
> probably want to look at how this work interacts with existing
> mechanisms (e.g., would we need to update those mech= anism specs to use
> the PRECIS approach instead of the stringprep ap= proach?).
Yes. But hopefully several SASL mechanisms can be updated by a= single
document.

______________________________________________= _
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/= listinfo/kitten


<= /body> --835683298-1207081084-1334588632=:6583-- From hartmans@mit.edu Tue Apr 17 13:24:07 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467BB21F8448 for ; Tue, 17 Apr 2012 13:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESMUBaepSW6t for ; Tue, 17 Apr 2012 13:24:06 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 920F521F8447 for ; Tue, 17 Apr 2012 13:24:06 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [203.41.199.122]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id AE144207B7 for ; Tue, 17 Apr 2012 16:19:47 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DB6584766; Tue, 17 Apr 2012 16:24:03 -0400 (EDT) From: Sam Hartman To: kitten@ietf.org mail-followups-to: abfab@ietf.org mail-copies-to: abfab@ietf.org Date: Tue, 17 Apr 2012 16:24:03 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [kitten] Please review draft-ietf-abfab-gss-eap-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 20:24:07 -0000 Hi. The ABFAB working group has just started a last call on draft-ietf-abfab-gss-eap-06. This defines a GSS-API/SASL mechanism and so it would be desirable to get kitten's review. Comments should be sent to abfab@ietf.org by May 1. Simon has already pointed out that we got our SASL registration off. From stpeter@stpeter.im Tue Apr 17 21:07:00 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3586D11E8087 for ; Tue, 17 Apr 2012 21:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oM7i7BXN2re9 for ; Tue, 17 Apr 2012 21:06:55 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8688711E8083 for ; Tue, 17 Apr 2012 21:06:55 -0700 (PDT) Received: from [192.168.0.3] (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2730940058; Tue, 17 Apr 2012 22:21:07 -0600 (MDT) Message-ID: <4F8E3DDE.4000802@stpeter.im> Date: Tue, 17 Apr 2012 22:06:54 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: William Mills References: <4F84AAA5.3030104@stpeter.im> <4ED1D634F0E26CDC51B61127@[192.168.15.131]> <4F85C4EE.2020901@stpeter.im> <4F89AB89.8050303@isode.com> <1334588632.6583.YahooMailNeo@web31804.mail.mud.yahoo.com> In-Reply-To: <1334588632.6583.YahooMailNeo@web31804.mail.mud.yahoo.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" Subject: Re: [kitten] spaces in SASL user names X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 04:07:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/16/12 9:03 AM, William Mills wrote: > It should be noted that SMTP allows "domain specific usernames" > with an extremely broad syntax that includes spaces. We had a long discussion during the PRECIS meeting in Paris about spaces. I need to listen to the audio recording again before I post further here about the reasoning, but it seems to me that the PRECIS folks (c'est moi, among others) might want to define something like a "compound name" that is made up of names and spaces. I'll review the audio and pursue this matter on the PRECIS list before coming back to the KITTEN list for further discussion. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+OPd4ACgkQNL8k5A2w/vyw9ACgmmDQ/cwmOD8DEP5EpcHQnj3I C2gAnAsbDAmLPccywPW7SHiHEWBwXRCB =A3BB -----END PGP SIGNATURE----- From tlyu@mit.edu Thu Apr 26 14:18:13 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AADE621F8748 for ; Thu, 26 Apr 2012 14:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.266 X-Spam-Level: X-Spam-Status: No, score=-104.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWI8CqBfs5yB for ; Thu, 26 Apr 2012 14:18:13 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2191921F873D for ; Thu, 26 Apr 2012 14:18:12 -0700 (PDT) X-AuditID: 1209190e-b7fd86d0000008b4-7b-4f99bb942fd2 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id F1.7D.02228.49BB99F4; Thu, 26 Apr 2012 17:18:12 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id q3QLICsf029392 for ; Thu, 26 Apr 2012 17:18:12 -0400 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q3QLIAFF012481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 26 Apr 2012 17:18:12 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id q3QLIA1b012140; Thu, 26 Apr 2012 17:18:10 -0400 (EDT) To: kitten@ietf.org From: Tom Yu Date: Thu, 26 Apr 2012 17:18:10 -0400 Message-ID: Lines: 7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUixCmqrTtl90x/g3MP5S2Obl7F4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMYDJ5kLPjBWnJq6lb2B8RRjFyMnh4SAicT0/sXMELaYxIV7 69m6GLk4hAT2MUqsPAJSBOIcY5Q4+vUBC4Tzikliy5O7UE4Xo8TO2dfZQfpFBIQldm99BzZL WEBd4m/7XyCbg4NNQFri6OIykDCLgKrE5q07wFbzClhITNq6igWkhEeAQ2LRuwCIsKDEyZlP WEBsZgEtiRv/XjJNYOSbhSQ1C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1jvdzMEr3U lNJNjOBgkuTbwfj1oNIhRgEORiUe3l+ZM/2FWBPLiitzDzFKcjApifIq7wIK8SXlp1RmJBZn xBeV5qQWH2KU4GBWEuG9xACU401JrKxKLcqHSUlzsCiJ86ppvfMTEkhPLEnNTk0tSC2Cycpw cChJ8K4FGSpYlJqeWpGWmVOCkGbi4AQZzgM0fClIDW9xQWJucWY6RP4Uoy7Hko6dVxmFWPLy 81KlxHl7QIoEQIoySvPg5sCSwCtGcaC3hHmrQap4gAkEbtIroCVMQEu+BU0DWVKSiJCSamCc bh7LKPxXtNy/3aojO3p7eKj68TvJ62Oi7fRtHh/bILIh1f9Q6IfnSd6nl/cuZLD+c5WV/eSE b94TT4jNao5jFNme/C8rmcN14jR3acWd2TcO1RuI+0n4Lmfa1+7O+XBy01QlkaKTc3fxVvI0 zS82TJ1jeygtbZb5q5uRYqv2O9697XVQM0eJpTgj0VCLuag4EQAoidK73QIAAA== Subject: [kitten] draft Kitten WG IETF83 minutes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 21:18:13 -0000 I've uploaded draft minutes of the Kitten WG IETF83 session to the Meeting Materials website: http://www.ietf.org/proceedings/83/minutes/minutes-83-kitten.txt Please let me know if there are corrections that I should make. Thanks.