From leifj@mnt.se Tue Jan 1 23:59:58 2013 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 8067C21F8A61 for ; Tue, 1 Jan 2013 23:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKEkdh39-yJU for ; Tue, 1 Jan 2013 23:59:56 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAD721F8686 for ; Tue, 1 Jan 2013 23:59:54 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id fr10so5651410lab.3 for ; Tue, 01 Jan 2013 23:59:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:x-gm-message-state; bh=1xfs8qMZ+cC4IYjchywYclgPVUPCsLZt+y/qRqYdi7k=; b=NWYcVjTF3LfZtwUaNYphmMs9YFS8kQ6uSe3dyM8PnevJ1AfBOfzmUPA50wAvIR1k0T 3r9J98yBLp9+h4cPd/AUnodKEDZ5TYnSad/Oz2kaWPDYKO9E5CiL44jZW/TUKDfX3XSO 8RN98Js9wsIEH71gW8v/XInGdtw1Au7vAMzF1XxL5osYJr75GC/0xVOIV7Xe4MazyAC9 JG8D2RFQ2kfkfd8knH7eWzZxplYbE5yC0kB3JSFbXuh/tBIBcSfWClSszaCKSeEaEy4K uTrN5zbN5DidTAlmwTQUNkysAvn5soECbUoTCPoxXWKLFAZ7tsZU+40rEhJ6TCiGMRbM EWkQ== X-Received: by 10.152.105.103 with SMTP id gl7mr42428291lab.10.1357113593197; Tue, 01 Jan 2013 23:59:53 -0800 (PST) Received: from ?IPv6:2001:6b0:7:0:e866:6c05:2c66:5bdc? ([2001:6b0:7:0:e866:6c05:2c66:5bdc]) by mx.google.com with ESMTPS id fb1sm15834826lbb.15.2013.01.01.23.59.46 (version=SSLv3 cipher=OTHER); Tue, 01 Jan 2013 23:59:52 -0800 (PST) Message-ID: <50E3E8F1.8000106@mnt.se> Date: Wed, 02 Jan 2013 08:59:45 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "kitten@ietf.org" , "ietf-krb-wg@anl.gov" Content-Type: multipart/mixed; boundary="------------080701000608060702030908" X-Gm-Message-State: ALoCoQl8u2QB7/87qRezbIXyKzgByJUu7TpW4aCkhTJ0B7AOserQumWp+8EK5uuCCrWw0dlmpxQI Subject: [kitten] new section 2 for the kdc model 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, 02 Jan 2013 07:59:58 -0000 This is a multi-part message in MIME format. --------------080701000608060702030908 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Folks, After the usual prodding by our AD (sorry about that) I've drafted a proposed new section 2 for the information model draft. This section tries to define the normative keywords instead of relying on RFC2119 (which got us stuck in IESG-land for a while). Instead of dropping a new version right away I'm hoping for some feedback. Silence will cause be to rev the I-D using this text in couple of days. Cheers Leif --------------080701000608060702030908 Content-Type: text/plain; charset=UTF-8; name="xml2rfc-xxe-9004003924212010784.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xml2rfc-xxe-9004003924212010784.txt" KERBEROS WORKING GROUP Johansson Internet-Draft SUNET Intended status: Standards Track January 2, 2013 Expires: July 6, 2013 An information model for Kerberos version 5 draft-ietf-krb-wg-kdc-model-14 Abstract This document describes an information model for Kerberos version 5 from the point of view of an administrative service. There is no standard for administrating a kerberos 5 KDC. This document describes the services exposed by an administrative interface to a KDC. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 6, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Johansson Expires July 6, 2013 [Page 1] Internet-Draft KDC Information Model January 2013 This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 3. Information model demarcation . . . . . . . . . . . . . . . . 6 4. Information model specification . . . . . . . . . . . . . . . 7 4.1. Principal . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1.1. Principal: Attributes . . . . . . . . . . . . . . . . 7 4.1.2. Principal: Associations . . . . . . . . . . . . . . . 8 4.2. KeySet . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.1. KeySet: Attributes . . . . . . . . . . . . . . . . . . 9 4.2.2. KeySet: Associations . . . . . . . . . . . . . . . . . 9 4.3. Key . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3.1. Key: Attributes . . . . . . . . . . . . . . . . . . . 10 4.3.2. Key: Associations . . . . . . . . . . . . . . . . . . 10 4.3.3. Key: Remarks . . . . . . . . . . . . . . . . . . . . . 11 4.4. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4.1. Policy: Attributes . . . . . . . . . . . . . . . . . . 11 4.4.2. Mandatory-to-implement Policy . . . . . . . . . . . . 12 5. Implementation Scenarios . . . . . . . . . . . . . . . . . . . 13 5.1. LDAP backend to KDC . . . . . . . . . . . . . . . . . . . 13 5.2. LDAP frontend to KDC . . . . . . . . . . . . . . . . . . . 13 5.3. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.4. Netconf . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Johansson Expires July 6, 2013 [Page 2] Internet-Draft KDC Information Model January 2013 1. Introduction The Kerberos version 5 authentication service described in [RFC4120] describes how a Key Distribution Center (KDC) provides authentication to clients. The standard does not stipulate how a KDC is managed and several "kadmin" servers have evolved. This document describes the services required to administer a KDC and the underlying information model assumed by a kadmin-type service. The information model is written in terms of "attributes" and "services" or "interfaces" but the use of these particular words must not be taken to imply any particular modeling paradigm. Neither an object oriented model nor an LDAP [RFC4510] schema is intended. The author has attempted to describe in natural language the intended semantics and syntax of the components of the model. An LDAP schema (for instance) based on this model will be more precise in the expression of the syntax while preserving the semantics of this model. Implementations of this document MAY decide to change the names used (e.g. principalName). If so an implementation MUST provide a name to name mapping to this document. In particular schema languages may have different conventions for caseing, eg camelCase vs use of '_' and '-' to separate 'words' in a name. Implementations MUST call out such conventions explicitly. Implementations of this document MUST be able to support default values for attributes as well as the ability to specify syntax for attribute values. Johansson Expires July 6, 2013 [Page 3] Internet-Draft KDC Information Model January 2013 2. Requirements notation This document uses the standard normative key words ("MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL") but does not reference [RFC2119]. The reason for this (which was discussed extensively in the kerberos WG) is as follows: This document describes an information model for kerberos 5 but does not directly describe any mapping onto a particular schema- or modelling language. Hence an implementation of this model consists of a mapping to such a language - e.g. an LDAP or SQL schema. The standard normative key word therefore require precise definition: The terms MUST or REQUIRED means that schema implementing this model must have a way to represent a feature (i.e that it is mandatory to implement in schema) but that unless otherwise specified the feature may represent an optional element in the chosen schema definition language. However MUST also means that a KDC or administrative interface implementing this information model MUST provide the feature and associated behavior consistent with schema. For instance, principalLastFailedAuthentication (cf below) represents the last time an authentication failed for a principal. In an LDAP schema (for instance) this may be represented as an optional attribute even though all KDCs implementing this specification must support this attribute. The terms MAY or OPTIONAL means that the feature is optional to implement by a KDC or administrative interface implementing this information model. It also means that the feature is optional to implement in schema. Implementors of schema should be aware that unless there is a way to represent critical but optional elements in the schema definition language confusion may arise when optional elements are used but not understood by all implementations in a particular deployment. The expression "MUST NOT be OPTIONAL" means that a feature is mandatory to implement ("MUST" cf above) and that additionally it must not be marked optional in the schema language. In particular this means that the feature is both mandatory to implement and must be present in all representations of the object to which it applies. The term SHOULD or RECOMMENDED means that the consequences of not implementing the feature as if it was described with the "MUST" Johansson Expires July 6, 2013 [Page 4] Internet-Draft KDC Information Model January 2013 keyword must be carefully weighed before choosing a different course. In particular this implies that interoperability concerns may arise from not following the recommended practice in schema that implements this model. The context will determine if the "SHOULD" key word applies to schema, or to underlying behaviour of the KDC or both. For instance, principalIsDisabled (cf below) SHOULD default to FALSE implies both a recommendation for the behaviour of KDCs aswell as a recommendation for the representation of that behaviour in schema. Johansson Expires July 6, 2013 [Page 5] Internet-Draft KDC Information Model January 2013 3. Information model demarcation The inforsmation model specified in the next chapter describes objects, properties of those objects and relations between those objects. These elements comprise an abstract view of the data represented in a KDC. It is important to understand that the information model is not a schema. In particular the way objects are compared for equality beyond that which is implied by the specification of a syntax is not part of this specification. Nor is ordering specified between elements of a particular syntax. Further work on Kerberos will undoubtedly prompt updates to this information model to reflect changes in the functions performed by the KDC. Such extensions to the information model should always use a normative reference to the relevant RFCs detailing the change in KDC function. This model describes a number of elements related to password policy management. Not all of the elements in this model are unique to Kerberos; an LDAP implementation of this model should incorporate existing LDAP schema where functional overlap exists, rather than defining additional Kerberos-specific elements. Johansson Expires July 6, 2013 [Page 6] Internet-Draft KDC Information Model January 2013 4. Information model specification 4.1. Principal The fundamental entity stored in a KDC is the principal. The Principal is associated to keys and generalizes the "user" concept. The Principal MUST be implemented in full and MUST NOT be OPTIONAL in an implementation 4.1.1. Principal: Attributes 4.1.1.1. principalName The principalName MUST uniquely identify the Principal within the administrative context of the KDC. The principalName MUST be equivalent to the string representation of the Principal name (section 2.1.1 of [RFC1964]) including, if applicable for the name type, the realm. The attribute MAY be multi-valued if the implementation supports aliases and/or enterprise names. In that case exactly one of the principalName values MAY be designated the canonical principalName and if the implementation supports enctypes which require salt then exactly one of the values of principalName MAY be designated as the canonical salting principalName. Implementations (i.e. schema) that support enterprise names and/or aliases SHOULD provide for efficient lookup of Principal objects based on alias/enterprise name. 4.1.1.2. principalNotUsedBefore The Principal MUST NOT be used before this date. The syntax of the attribute MUST be Internet Date/Time Format from [RFC3339]. The attribute MUST be single-valued. 4.1.1.3. principalNotUsedAfter The Principal MUST NOT be used after this date. The syntax of the attribute MUST be Internet Date/Time Format from [RFC3339]. The attribute MUST be single-valued. 4.1.1.4. principalIsDisabled A boolean attribute used to disable a Principal. The attribute SHOULD default to boolean FALSE. Johansson Expires July 6, 2013 [Page 7] Internet-Draft KDC Information Model January 2013 4.1.1.5. principalLastCredentialChangeTime This single-valued attribute contains the time of the last successful change of credential (e.g. password or private key) associated with this Principal. The syntax of the attribute MUST be Internet Date/ Time Format from [RFC3339]. 4.1.1.6. principalCreateTime This single-valued attribute contains the time and date when this Principal was created. The syntax of the attribute MUST be Internet Date/Time Format from [RFC3339]. 4.1.1.7. principalModifyTime This single-valued attribute contains the time and date when this Principal was last modified excluding credentials change. The syntax of the attribute MUST be Internet Date/Time Format from [RFC3339]. 4.1.1.8. principalMaximumTicketLifetime This single-valued attribute contains the time in seconds representing the maximum lifetime for tickets issued for this Principal. 4.1.1.9. principalMaximumRenewableTicketLifetime This single-valued attribute contains the delta time in seconds representing the maximum amount of time a ticket may be renewed for this Principal. 4.1.1.10. principalAllowedEnctype This OPTIONAL multi-valued attribute lists the enctypes allowed for this principal. If empty or absent any enctype supported by the implementation is allowed for this Principal. This attribute is intended as a policy attribute and restricts all uses of enctypes including server, client, and session keys. Data models MAY choose to use policy objects in order to represent more complex decision mechanisms. 4.1.2. Principal: Associations Each Principal MAY be associated with 0 or more KeySet and MAY be associated with 0 or more Policies. The KeySet is represented as an object in this model since it has attributes associated with it (the key version number). In typical situations the Principal is Johansson Expires July 6, 2013 [Page 8] Internet-Draft KDC Information Model January 2013 associated with exactly 1 KeySet but implementations MUST NOT assume this case, i.e. an implementation of this standard MUST be able to handle the general case of multiple KeySet associated with each principal. Multiple KeySets may for instance be useful when performing a key rollover for a principal. 4.2. KeySet In Kerberos principals are associated with zero or more symmetric secret keys, and each key has a key version number (kvno) and enctype. In this model we group keys by kvno into KeySet objects. A Principal can have zero or more KeySet objects associated with it, each of which MUST have one or more keys. Each KeySet is associated with exactly one principal. Schemas derived from this model MAY lack a direct analogue of KeySet as described in this document. It is expected that most Kerberos implementations will use a special- purpose interface for setting and changing Principal passwords and keys. If a server supports an enctype for a Principal that enctype must be present in at least one key for the Principal in question. For any given enctype a KeySet MUST NOT contain more than one Key with that enctype. The security of Kerberos 5 depends absolutely on the confidentiality and integrity of the Key objects stored in the KDC. Implementations of this standard MUST facilitate, to the extent possible, an administrator's ability to place more restrictive access controls on KeySets than on other Principal data, and to arrange for more secure backup for KeySets. 4.2.1. KeySet: Attributes 4.2.1.1. kvno Also knowns as the key version number. This is a single-valued attribute containing a non-negative integer. This number is incremembed by one each time a key in the KeySet is changed. 4.2.2. KeySet: Associations To each KeySet MUST be associated a set of 1 or more Keys. 4.3. Key Implementations of this model MUST NOT REQUIRE keys to be represented. Johansson Expires July 6, 2013 [Page 9] Internet-Draft KDC Information Model January 2013 4.3.1. Key: Attributes 4.3.1.1. keyEncryptionType The enctype SHOULD be represented as an enumeration of the enctypes supported by the KDC using the string name ("encryption type") of the enctype from the IANA registry of Kerberos Encryption Type Numbers. One example is 'aes128-cts-hmac-sha1-96'. 4.3.1.2. keyValue The binary representation of the key data. This MUST be a single- valued octet string. 4.3.1.3. keySaltValue The binary representation of the key salt. This MUST be a single- valued octet string. 4.3.1.4. keyStringToKeyParameter This MUST be a single-valued octet string representing an opaque parameter associated with the enctype. This parameter is specified in the "string-to-key" method in section 3 of [RFC3961]. 4.3.1.5. keyNotUsedBefore This key MUST NOT be used before this date. The syntax of the attribute MUST be semantically equivalent with the standard ISO date format. This MUST be a single-valued attribute. 4.3.1.6. keyNotUsedAfter This key MUST NOT be used after this date. The syntax of the attribute MUST be semantically equivalent with the standard ISO date format. This MUST be a single-valued attribute. 4.3.1.7. keyIsDisabled This is a boolean attribute which SHOULD be set to false by default. If this attribute is true the key MUST NOT be used. This is used to temporarily disable a key. 4.3.2. Key: Associations None Johansson Expires July 6, 2013 [Page 10] Internet-Draft KDC Information Model January 2013 4.3.3. Key: Remarks The security of the keys is an absolute requirement for the operation of Kerberos 5. If keys are implemented adequate protection from unauthorized modification and disclosure MUST be available and REQUIRED by the implementation. 4.4. Policy Implementations SHOULD implement policy but MAY allow them to be OPTIONAL. The Policy should be thought of as a 'typed hole'. i.e. an opaque binary value paired with an identifier of type of data contained in the binary value. Both attributes (type and value) must be present. 4.4.1. Policy: Attributes 4.4.1.1. policyIdentifier The policyIdentifier MUST be globally unique. Possible types of identifiers include: An Object Identifier (OID) [RFC4517] A URI [RFC3986] A UUID [RFC4122] Implementations of this specification are expected to assign globally unique identifiers to the list of standard policy below in accordance with best-practice for identifier-management for the schema-language used. 4.4.1.2. policyIsCritical This boolean attribute indicates that the KDC MUST be able to correctly interpret and apply this policy for the Principal to be used. 4.4.1.3. policyContent This is an optional single opaque binary value used to store a representation of the policy. In general a policy cannot be fully expressed using attribute-value pairs. The policyContent is OPTIONAL in the sense that an implementation MAY use it to store an opaque value for those policy-types which are not directly representable in that implementation. Johansson Expires July 6, 2013 [Page 11] Internet-Draft KDC Information Model January 2013 4.4.1.4. policyUse This is an optional single enumerated string value used to describe the use of the policy. Implementations SHOULD provide this attribute and MUST (if the attribute is implemented) describe the enumerated set of possible values. The intent is that this attribute be useful in providing an initial context-based filtering. 4.4.2. Mandatory-to-implement Policy All implementations that represent Policy objects MUST be able to represent the policies listed in this section. Implementations are not required to use the same underlying data-representation for the policyContent binary value but SHOULD use the same OIDs as the policyIdentifier. In general the expression of policy may require a Turing-complete language. This specification does not attempt to model policy expression language. 4.4.2.1. Password Quality Policy Password quality policy controls the requirements placed by the KDC on new passwords. 4.4.2.2. Password Management Policy Password management policy controls how passwords are changed. 4.4.2.3. Keying Policy A keying policy specifies the association of enctypes with new principals, e.g. when a Principal is created one of the applicable keying policies is used to determine the set of keys to associate with the principal. 4.4.2.4. Ticket Flag Policy A ticket flag policy specifies the ticket flags allowed for tickets issued for a principal. Johansson Expires July 6, 2013 [Page 12] Internet-Draft KDC Information Model January 2013 5. Implementation Scenarios There are several ways to implement an administrative service for Kerberos 5 based on this information model. In this section we list a few of them. 5.1. LDAP backend to KDC Given an LDAP schema implementation of this information model it would be possible to build an administrative service by back-ending the KDC to a directory server where principals and keys are stored. Using the security mechanisms available on the directory server keys are protected from access by anyone apart from the KDC. Administration of the principals, policy, and other non-key data is done through the directory server while the keys are modified using the set/change password protocol [I-D.ietf-krb-wg-kerberos-set-passwd]. 5.2. LDAP frontend to KDC An alternative way to provide a directory interface to the KDC is to implement an LDAP-frontend to the KDC which exposes all non-key objects as entries and attributes. As in the example above all keys are modified using the set/change password protocol [I-D.ietf-krb-wg-kerberos-set-passwd]. In this scenario the implementation would typically not use a traditional LDAP implementation but treat LDAP as an access protocol to data in the native KDC database. 5.3. SOAP Given an XML schema implementation of this information model it would be possible to build a SOAP interface to the KDC. This demonstrates the value of creating an abstract information model which is mappable to multiple schema representations. 5.4. Netconf Given a YAML implementation of this information model it would be possible to create a Netconf-based interface to the KDC, enabling management of the KDC from standard network management applications. Johansson Expires July 6, 2013 [Page 13] Internet-Draft KDC Information Model January 2013 6. Security Considerations This document describes an abstract information model for Kerberos 5. The Kerberos 5 protocol depends on the security of the keys stored in the KDC. The model described here assumes that keys MUST NOT be transported in the clear over the network and furthermore that keys are treated as write-only attributes that SHALL only be modified (using the administrative interface) by the change-password protocol [I-D.ietf-krb-wg-kerberos-set-passwd]. Exposing the object model of a KDC typically implies that objects can be modified and/or deleted. In a KDC not all principals are created equal, so that for instance deleting krbtgt/EXAMPLE.COM@EXAMPLE.COM effectively disables the EXAMPLE.COM realm. Hence access control is paramount to the security of any implementation. This document does not mandate access control. This only implies that access control is beyond the scope of the standard information model, i.e. that access control may not be accessible via any protocol based on this model. If access control objects are exposed via an extension to this model the presence of access control may in itself provide points of attack by giving away information about principals with elevated rights etc. Johansson Expires July 6, 2013 [Page 14] Internet-Draft KDC Information Model January 2013 7. IANA Considerations This document has no IANA actions. Johansson Expires July 6, 2013 [Page 15] Internet-Draft KDC Information Model January 2013 8. Acknowledgments The author wishes to extend his thanks to Love Hoernquist-Aestrand and Sam Hartman for their important contributions to this document. Johansson Expires July 6, 2013 [Page 16] Internet-Draft KDC Information Model January 2013 9. References 9.1. Normative References [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005. [RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006. 9.2. Informative References [I-D.ietf-krb-wg-kerberos-set-passwd] Williams, N., "Kerberos Set/Change Key/Password Protocol Version 2", draft-ietf-krb-wg-kerberos-set-passwd-08 (work in progress), November 2008. [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006. Johansson Expires July 6, 2013 [Page 17] Internet-Draft KDC Information Model January 2013 Author's Address Leif Johansson Swedish University Network Thulegatan 11 Stockholm Email: leifj@sunet.se URI: http://www.sunet.se Johansson Expires July 6, 2013 [Page 18] --------------080701000608060702030908-- From shawn.emery@oracle.com Fri Jan 4 00:45:50 2013 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 2495721F8EB9 for ; Fri, 4 Jan 2013 00:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZzTKN6eAvUi for ; Fri, 4 Jan 2013 00:45:49 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id EA15C21F861F for ; Fri, 4 Jan 2013 00:45:48 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r048jloH017673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Jan 2013 08:45:48 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r048jkwv001492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2013 08:45:47 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r048jki6027505; Fri, 4 Jan 2013 02:45:46 -0600 Received: from [10.159.102.25] (/10.159.102.25) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 Jan 2013 00:45:46 -0800 Message-ID: <50E6966D.9040704@oracle.com> Date: Fri, 04 Jan 2013 01:44:29 -0700 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:10.0.7) Gecko/20121011 Thunderbird/10.0.7 MIME-Version: 1.0 To: "kitten@ietf.org" , ietf-krb-wg@lists.anl.gov Content-Type: multipart/mixed; boundary="------------080305030202030106050005" X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [kitten] Kitten and Kerberos WG Merger - New Charter 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, 04 Jan 2013 08:45:50 -0000 This is a multi-part message in MIME format. --------------080305030202030106050005 Content-Type: multipart/alternative; boundary="------------010909030206020607050400" --------------010909030206020607050400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Attached is the proposed charter for the merged Kitten and Kerberos working groups. We request feed-back from each of the work items in regards to, if the work is a: Good idea? Bad idea? Would you be a major contributor? Would you be a reviewer of work? In addition, we are requesting feed-back on work items to be included that are not currently covered by the draft charter text. For those that have existing work items or have already volunteered to contribute to new work, please review and provide feedback on the milestones section. Please provide any feedback to the list before 1/18/13. Thank you. Shawn. -- kitten/krb-wg co-chair --------------010909030206020607050400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Attached is the proposed charter for the merged Kitten and Kerberos working groups.  We request feed-back from each of the work items in regards to, if the work is a:

Good idea?
Bad idea?
Would you be a major contributor?
Would you be a reviewer of work?

In addition, we are requesting feed-back on work items to be included that are not currently covered by the draft charter text.

For those that have existing work items or have already volunteered to contribute to new work, please review and provide feedback on the milestones section.

Please provide any feedback to the list before 1/18/13.  Thank you.

Shawn.
--
kitten/krb-wg co-chair
 --------------010909030206020607050400-- --------------080305030202030106050005 Content-Type: text/plain; name="kitten-charter.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="kitten-charter.txt" Common Authentication Technology Next Generation (kitten) --------------------------------------------------------- Charter Current Status: Active Chairs: Sam Hartman Shawn Emery Josh Howlett Secretary: Simon Josefsson Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Stephen Farrell Mailing Lists: General Discussion: kitten@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/kitten Archive: http://www.ietf.org/mail-archive/web/kitten/current/maillist.html Description of Working Group: The purpose of the Common Authentication Technology Next Generation (Kitten) working group (WG) is to develop extensions/improvements to the GSS-API and to the Kerberos authentication system, shepherd specific GSS-API security mechanisms, and provide guidance for any new SASL-related submissions. This charter subsumes the Kerberos WG under the auspices of the kitten WG. Therefore the following charter text contains both kitten and Kerberos WG items. The working group will develop extensions and/or updates to the GSS-API, working on specific items regarding credential management, replay cache avoidance, error reporting, and supporting stateless and/or distributed acceptors. The working group will also maintain and improve upon the Kerberos protocol, working on items regarding internationalization, new initial authentication types, authorization framework/data, replay cache avoidance, cryptography advances, interop with 3rd party authentication, and identity management. In detail, both existing and new work items include: Existing Working Group Items --------------------------- SASL Mechanism for OAuth (draft-ietf-kitten-sasl-oauth) SASL Mechansim for SAML-EC (draft-ietf-kitten-sasl-saml-ec) GSS-API IANA Registry (draft-ietf-kitten-gssapi-extensions-iana) KDC Model (draft-ietf-krb-wg-kdc-model) PKINIT Hash Agility (draft-ietf-krb-wg-pkinit-alg-agility) Kerberos IANA Registry (draft-ietf-kitten-kerberos-iana-registries) Initial and Pass Through Authentication in Kerberos 5 (draft-ietf-krb-wg-iakerb) Unencrypted Portion of Ticket Extensions (draft-ietf-krb-wg-ticket-extensions) GSS-API Related --------------- Provide new interfaces for credential management, which include the following: initializing credentials iterating credentials exporting/importing credentials Negotiable replay cache avoidance Define interfaces for better error message reporting. Specify an option for exporting partially-established security contexts and possibly a utility function for exporting security contexts in an encrypted form, as well as a corresponding utility function to decrypt and import such security context tokens. Specify one-time password / two-factor authentication needs for SASL applications. This could be achieved through an explicit new GSS-API/SASL mechanism (e.g., http://tools.ietf.org/html/draft-josefsson-kitten-crotp-00) or if the consensus is that due to usability reasons, it is preferable to do OTP/2FA through an higher level protocol (Kerberos/OpenID/SAML/SAML20EC/EAP?) then prepare a document explaining the usability problem and provide pointers for implementers. Kerberos Related ---------------- Prepare and advance one or more standards-track specifications which update the Kerberos version 5 protocol to support non-ASCII principal and realm names, salt strings, and passwords, and localized error reporting. Maximizing backward compatibility is strongly desired. Prepare, review, and advance standards-track and informational specifications defining new authorization data types for carrying supplemental information about the client to which a Kerberos ticket has been issued and/or restrictions on what the ticket can be used for. To enhance this ongoing authorization data work, a container format supporting the use cases of draft-ietf-krb-wg-pad may be standardized. Prepare a standards-track protocol to solve the use cases addressed by draft-hotz-kx509-01 including new support for digital signatures. Today Kerberos requires a replay cache to be used in AP exchanges in almost all cases. Replay caches are quite complex to implement correctly, particularly in clustered systems. High-performance replay caches are even more difficult to implement. The WG will pursue extensions to minimize the need for replay caching, optimize replay caching, and/or elide the need for replay caching. Prepare, review, and advance standards-track and informational specifications defining use of new cryptographic algorithms in the Kerberos protocol using the RFC3961 framework, on an ongoing basis. Cryptographic algorithms intended for standards track status must be of good quality, have broad international support, and fill a definite need. Prepare, review, and advance standards-track and informational specifications of new pre-authentication types for the Kerberos protocol, on an ongoing basis. Prepare, review, and advance standards track updates and extensions to RFC4121, as needed and on an ongoing basis. Goals and Milestones -------------------- Jan 2013 draft-ietf-kitten-sasl-oauth to IESG Jan 2013 draft-ietf-krb-wg-kdc-model to IESG Feb 2013 draft-ietf-krb-wg-pkinit-alg-agility to IESG Feb 2013 draft-ietf-kitten-sasl-saml-ec to IESG Mar 2013 draft-ietf-krb-wg-iakerb to IESG Mar 2013 draft-ietf-kitten-gssapi-extensions-iana to IESG Apr 2013 draft-ietf-krb-wg-cammac to IESG Apr 2013 draft-ietf-kitten-kerberos-iana-registries to IESG May 2013 draft-ietf-krb-wg-pad to IESG May 2013 Adopt work on one or more items for GSS-API cred management Jun 2013 Adopt work on better error reporting in the GSS-API Jun 2013 Adopt work on exporting partially-established GSS-API contexts Jul 2013 draft-ietf-krb-wg-ticket-extensions to IESG Jul 2013 Adopt work on the GSS-API for replay cache avoidance --------------080305030202030106050005-- From lukeh@padl.com Fri Jan 4 02:44:46 2013 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 AEEC321F8E97 for ; Fri, 4 Jan 2013 02:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TMJZxHHmaQt for ; Fri, 4 Jan 2013 02:44:41 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 7911921F8E82 for ; Fri, 4 Jan 2013 02:44:41 -0800 (PST) Received: by us.padl.com with ESMTP id r04AiV1S013689; Fri, 4 Jan 2013 05:44:34 -0500 From: Luke Howard Content-Type: multipart/alternative; boundary="Apple-Mail=_1EF22603-605D-4610-8A89-50E8F58077D3" Date: Fri, 4 Jan 2013 21:44:31 +1100 To: "dev-identity@lists.mozilla.org" , "kitten@ietf.org" Message-Id: <8F0F68DB-721A-430F-AC2A-872E5BD5D231@padl.com> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Subject: [kitten] BrowserID GSS mechanism 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, 04 Jan 2013 10:44:46 -0000 --Apple-Mail=_1EF22603-605D-4610-8A89-50E8F58077D3 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii I made some notes on a putative BrowserID GSS mechanism here: http://www.padl.com/~lukeh/gss-browserid.html (or .md) I intend to write it up as an Internet Draft at some point. Comments welcome. -- Luke -- Luke Howard / lukeh@padl.com www.padl.com / www.lukehoward.com --Apple-Mail=_1EF22603-605D-4610-8A89-50E8F58077D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = made some notes on a putative BrowserID GSS mechanism = here:


I = intend to write it up as an Internet Draft at some point. Comments = welcome.

-- Luke

= --Apple-Mail=_1EF22603-605D-4610-8A89-50E8F58077D3-- From simon@josefsson.org Fri Jan 4 03:18:56 2013 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 015AA21F8E63 for ; Fri, 4 Jan 2013 03:18:56 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooVpUjpmWKN9 for ; Fri, 4 Jan 2013 03:18:55 -0800 (PST) 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 DE4E921F8E11 for ; Fri, 4 Jan 2013 03:18:53 -0800 (PST) Received: from latte.josefsson.org (host-95-192-63-171.mobileonline.telia.com [95.192.63.171]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r04BIjSW023814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 4 Jan 2013 12:18:48 +0100 From: Simon Josefsson To: Shawn Emery References: <50E6966D.9040704__49484.1541782536$1357289172$gmane$org@oracle.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130104:kitten@ietf.org::hS9LjaY5M207Y0dM:0BBZ X-Hashcash: 1:22:130104:shawn.emery@oracle.com::HnazTXXPx7bJKxld:E44V X-Hashcash: 1:22:130104:ietf-krb-wg@lists.anl.gov::D+byjRdrEQvT2Pva:OhyS Date: Fri, 04 Jan 2013 12:18:39 +0100 In-Reply-To: <50E6966D.9040704__49484.1541782536$1357289172$gmane$org@oracle.com> (Shawn Emery's message of "Fri, 04 Jan 2013 01:44:29 -0700") Message-ID: <87mwwp19io.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (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" , ietf-krb-wg@lists.anl.gov Subject: Re: [kitten] Kitten and Kerberos WG Merger - New Charter 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, 04 Jan 2013 11:18:56 -0000 Shawn Emery writes: > Common Authentication Technology Next Generation (kitten) > --------------------------------------------------------- > > Charter ... > This charter subsumes the Kerberos WG under the auspices of the kitten WG. > Therefore the following charter text contains both kitten and Kerberos WG items. I suggest to remove this paragraph. I don't see significant value in having that in the WG charter, and it seems confusing for anyone not familiar with the history. > In detail, both existing and new work items include: > > Existing Working Group Items > --------------------------- > SASL Mechanism for OAuth (draft-ietf-kitten-sasl-oauth) Good idea -- will review, could contribute. > SASL Mechansim for SAML-EC (draft-ietf-kitten-sasl-saml-ec) Good idea -- will contribute & review. > GSS-API IANA Registry (draft-ietf-kitten-gssapi-extensions-iana) No objection. > KDC Model (draft-ietf-krb-wg-kdc-model) Long overdue. I have always preferred that this document shipped together with an instanciation of it, such as an LDAP schema. I based my KDC backend database on an earlier version of this draft, but the document has changed since then. Without implementations it is difficult to know whether there are flaws in the abstract model. > PKINIT Hash Agility (draft-ietf-krb-wg-pkinit-alg-agility) > Kerberos IANA Registry (draft-ietf-kitten-kerberos-iana-registries) > Initial and Pass Through Authentication in Kerberos 5 (draft-ietf-krb-wg-iakerb) > Unencrypted Portion of Ticket Extensions (draft-ietf-krb-wg-ticket-extensions) No objection. > GSS-API Related > --------------- > Provide new interfaces for credential management, which include the > following: > initializing credentials > iterating credentials > exporting/importing credentials Good idea -- will review, could contribute. > Negotiable replay cache avoidance No objection. > Define interfaces for better error message reporting. I'd rather not spend time on that. Do we have a problem statement to argue why this is important? > Specify an option for exporting partially-established security > contexts and possibly a utility function for exporting security > contexts in an encrypted form, as well as a corresponding utility > function to decrypt and import such security context tokens. Good idea - may review. > Specify one-time password / two-factor authentication needs for SASL > applications. This could be achieved through an explicit new > GSS-API/SASL mechanism (e.g., > http://tools.ietf.org/html/draft-josefsson-kitten-crotp-00) or if > the consensus is that due to usability reasons, it is preferable to do > OTP/2FA through an higher level protocol > (Kerberos/OpenID/SAML/SAML20EC/EAP?) then prepare a document explaining > the usability problem and provide pointers for implementers. Good idea -- will contribute. > Kerberos Related > ---------------- > Prepare and advance one or more standards-track specifications which > update the Kerberos version 5 protocol to support non-ASCII principal > and realm names, salt strings, and passwords, and localized error > reporting. Maximizing backward compatibility is strongly desired. Localized error reporting: good idea -- will contribute. The draft for it has been ready for a long time. Regarding the rest I would prefer to wait until other protocols have deployed PRECIS to gain experience with it. Given the experience with SASLprep in SASL it was fortunate that we didn't go that route with Kerberos. I don't want Kerberos to end up in a similar situation only replacing SASLprep with PRECIS. > Prepare, review, and advance standards-track and informational > specifications defining new authorization data types for carrying > supplemental information about the client to which a Kerberos ticket > has been issued and/or restrictions on what the ticket can be used > for. To enhance this ongoing authorization data work, a container > format supporting the use cases of draft-ietf-krb-wg-pad may be > standardized. Good idea. > Prepare a standards-track protocol to solve the use cases addressed > by draft-hotz-kx509-01 including new support for digital signatures. Good idea. > Today Kerberos requires a replay cache to be used in AP exchanges in > almost all cases. Replay caches are quite complex to implement > correctly, particularly in clustered systems. High-performance replay > caches are even more difficult to implement. The WG will pursue > extensions to minimize the need for replay caching, optimize replay > caching, and/or elide the need for replay caching. Good idea. > Prepare, review, and advance standards-track and informational > specifications defining use of new cryptographic algorithms in the > Kerberos protocol using the RFC3961 framework, on an ongoing > basis. Good idea -- will review. > Cryptographic algorithms intended for standards track status must be of > good quality, have broad international support, and fill a definite need. IMHO this sentence is weasel-wording to motivate arbitrary decisions to match some people's crypto preferences. The IETF already have policies around crypto (for example RFC 1984) that are sufficient motivation to turn down obviously bad proposals. When a proposal is not obviously bad, I belive the WG should be able to review any proposal with non-judgemental eyes. > Prepare, review, and advance standards-track and informational > specifications of new pre-authentication types for the Kerberos > protocol, on an ongoing basis. Good idea. > Prepare, review, and advance standards track updates and extensions to RFC4121, > as needed and on an ongoing basis. Good idea. > Goals and Milestones > -------------------- > > Jan 2013 draft-ietf-kitten-sasl-oauth to IESG > Jan 2013 draft-ietf-krb-wg-kdc-model to IESG > Feb 2013 draft-ietf-krb-wg-pkinit-alg-agility to IESG > Feb 2013 draft-ietf-kitten-sasl-saml-ec to IESG > Mar 2013 draft-ietf-krb-wg-iakerb to IESG > Mar 2013 draft-ietf-kitten-gssapi-extensions-iana to IESG > Apr 2013 draft-ietf-krb-wg-cammac to IESG > Apr 2013 draft-ietf-kitten-kerberos-iana-registries to IESG > May 2013 draft-ietf-krb-wg-pad to IESG > May 2013 Adopt work on one or more items for GSS-API cred management > Jun 2013 Adopt work on better error reporting in the GSS-API > Jun 2013 Adopt work on exporting partially-established GSS-API contexts > Jul 2013 draft-ietf-krb-wg-ticket-extensions to IESG > Jul 2013 Adopt work on the GSS-API for replay cache avoidance I believe the targets are unrealistically optimistic, however my perception is that the only purpose for having dates in the milestones is to enable IESG to put pressure on WG's to deliver. So I support setting an aggresive timeline. /Simon From jhutz@cmu.edu Fri Jan 4 11:04:27 2013 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 7168D21F883F for ; Fri, 4 Jan 2013 11:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmu4XddMXZhO for ; Fri, 4 Jan 2013 11:04:26 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 6B83921F883E for ; Fri, 4 Jan 2013 11:04:26 -0800 (PST) Received: from [192.168.202.158] (pool-74-111-100-191.pitbpa.fios.verizon.net [74.111.100.191]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r04J4HY9021727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2013 14:04:24 -0500 (EST) From: Jeffrey Hutzelman To: Simon Josefsson In-Reply-To: <87mwwp19io.fsf@latte.josefsson.org> References: <50E6966D.9040704__49484.1541782536$1357289172$gmane$org@oracle.com> <87mwwp19io.fsf@latte.josefsson.org> Content-Type: text/plain; charset="UTF-8" Date: Fri, 04 Jan 2013 14:04:12 -0500 Message-ID: <1357326252.18192.188.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: "kitten@ietf.org" , ietf-krb-wg@lists.anl.gov, jhutz@cmu.edu Subject: Re: [kitten] [Ietf-krb-wg] Kitten and Kerberos WG Merger - New Charter 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, 04 Jan 2013 19:04:27 -0000 On Fri, 2013-01-04 at 12:18 +0100, Simon Josefsson wrote: > > This charter subsumes the Kerberos WG under the auspices of the kitten WG. > > Therefore the following charter text contains both kitten and Kerberos WG items. > > I suggest to remove this paragraph. I don't see significant value in > having that in the WG charter, and it seems confusing for anyone not > familiar with the history. That was actually put in as a way of recording the history and giving people not familiar with it a way to find older Kerberos-related work. However, it was not the topic of a lot of wordsmithing, and I don't think anyone who contributed to this proposal is wedded to that language. So, if someone wants to propose alternate text... > > KDC Model (draft-ietf-krb-wg-kdc-model) > > Long overdue. I have always preferred that this document shipped > together with an instanciation of it, such as an LDAP schema. I based > my KDC backend database on an earlier version of this draft, but the > document has changed since then. Without implementations it is > difficult to know whether there are flaws in the abstract model. It's certainly not going to ship "together with" a schema. While I've heard various people speak in favor of having an LDAP schema over the years, including at the last krb-wg rechartering, there doesn't seem to be enough interest in actually working on it for anything to happen. The model document is nearly done (in the hands of the IESG, except for revisions Leif recently posted to the list on which there have _still_ been no comments). It's not going to sit around and wait for additional work that may never happen. > > PKINIT Hash Agility (draft-ietf-krb-wg-pkinit-alg-agility) > > Kerberos IANA Registry (draft-ietf-kitten-kerberos-iana-registries) > > Initial and Pass Through Authentication in Kerberos 5 (draft-ietf-krb-wg-iakerb) > > Unencrypted Portion of Ticket Extensions (draft-ietf-krb-wg-ticket-extensions) > > No objection. ... but will you work on any of these items? Review them? IAKERB was basically done some time ago, but needs an editor to manage the document through the various review processes on the way to getting it published. Ticket Extensions is a mostly complete proposal which krb-wg adopted some years ago, and which has languished since due to lack of cycles. This document is at version -00, and will probably need a couple of editing cycles before it reaches WGLC; it would be nice to see someone step up to do that work. > > Define interfaces for better error message reporting. > > I'd rather not spend time on that. Do we have a problem statement to > argue why this is important? The GSS-API's error reporting interfaces are somewhat clunky, to say the least. It is certainly possible to get a complete set of error messages, but since there is no connection to a particular context, it is unnecessarily complex for the implementation to report contextualized errors, especially when multiple threads and/or mechanisms are involved. Additionally, there is no mechanism for localization of error message text. > Good idea -- will review. > > > Cryptographic algorithms intended for standards track status must be of > > good quality, have broad international support, and fill a definite need. > > IMHO this sentence is weasel-wording to motivate arbitrary decisions to > match some people's crypto preferences. The IETF already have policies > around crypto (for example RFC 1984) that are sufficient motivation to > turn down obviously bad proposals. When a proposal is not obviously > bad, I belive the WG should be able to review any proposal with > non-judgemental eyes. We had this discussion during krb-wg's last rechartering, and this wording is the result of that hard-won consensus. It doesn't prevent the WG from reviewing any proposal and even taking on work to produce an informational document. It does constrain what can end up on the standards track. In practice, I don't think the constraint is overly onerous. For example, what kept camellia from being published on the standards track was not this requirement, but the lack of consensus within the WG to recommend it. > > Goals and Milestones > > -------------------- > > > > Jan 2013 draft-ietf-kitten-sasl-oauth to IESG > > Jan 2013 draft-ietf-krb-wg-kdc-model to IESG > > Feb 2013 draft-ietf-krb-wg-pkinit-alg-agility to IESG > > Feb 2013 draft-ietf-kitten-sasl-saml-ec to IESG > > Mar 2013 draft-ietf-krb-wg-iakerb to IESG > > Mar 2013 draft-ietf-kitten-gssapi-extensions-iana to IESG > > Apr 2013 draft-ietf-krb-wg-cammac to IESG > > Apr 2013 draft-ietf-kitten-kerberos-iana-registries to IESG > > May 2013 draft-ietf-krb-wg-pad to IESG > > May 2013 Adopt work on one or more items for GSS-API cred management > > Jun 2013 Adopt work on better error reporting in the GSS-API > > Jun 2013 Adopt work on exporting partially-established GSS-API contexts > > Jul 2013 draft-ietf-krb-wg-ticket-extensions to IESG > > Jul 2013 Adopt work on the GSS-API for replay cache avoidance > > I believe the targets are unrealistically optimistic, however my > perception is that the only purpose for having dates in the milestones > is to enable IESG to put pressure on WG's to deliver. So I support > setting an aggresive timeline. I agree that some of these are pretty optimistic. However, at least some of the early ones look OK. For example, kdc-model, pkinit-agility, and iakerb should all already be done enough to make or beat those deadlines, so I have no objections to them. I can't speak to the GSS/SASL documents with early milestones, except that I do not believe the SASL OAuth document is ready to go -- it has a serious problem with the mechanism lying about mutual authentication, which I raised last month and to which I so far have seen no response. -- Jeff From jhutz@cmu.edu Fri Jan 4 11:07:29 2013 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 AA34321F869F for ; Fri, 4 Jan 2013 11:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUFaxXGTwJwY for ; Fri, 4 Jan 2013 11:07:29 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 3452D21F85B8 for ; Fri, 4 Jan 2013 11:07:26 -0800 (PST) Received: from [192.168.202.158] (pool-74-111-100-191.pitbpa.fios.verizon.net [74.111.100.191]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r04J7Nrp021807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2013 14:07:24 -0500 (EST) From: Jeffrey Hutzelman To: Luke Howard In-Reply-To: <31096_1357297002_r04AueRc031874_8F0F68DB-721A-430F-AC2A-872E5BD5D231@padl.com> References: <31096_1357297002_r04AueRc031874_8F0F68DB-721A-430F-AC2A-872E5BD5D231@padl.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 04 Jan 2013 14:07:18 -0500 Message-ID: <1357326438.18192.190.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: "kitten@ietf.org" , "dev-identity@lists.mozilla.org" , jhutz@cmu.edu Subject: Re: [kitten] BrowserID GSS mechanism 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, 04 Jan 2013 19:07:29 -0000 On Fri, 2013-01-04 at 21:44 +1100, Luke Howard wrote: > I made some notes on a putative BrowserID GSS mechanism here: > > > http://www.padl.com/~lukeh/gss-browserid.html (or .md) > > > I intend to write it up as an Internet Draft at some point. Comments > welcome. I've so far only skimmed this, but it looks so far like it probably has the makings of a good mechanism. I would ask that if you're going to use a DH exchange to obtain keying material for PRF and per-message tokens, that you write that portion of the document such that it can be reused by reference in other mechanisms. Nico would probably say it should actually be done as a stackable mechanism, but I won't insist on that. -- Jeff From nico@cryptonector.com Fri Jan 4 13:41:26 2013 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 2D6AD21F884A for ; Fri, 4 Jan 2013 13:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id st5OiOdwO-ap for ; Fri, 4 Jan 2013 13:41:25 -0800 (PST) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8739E21F86DC for ; Fri, 4 Jan 2013 13:41:25 -0800 (PST) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id EDE17428079 for ; Fri, 4 Jan 2013 13:41:24 -0800 (PST) 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=igZbk3mnHKHYdCKBxFRw 8hhteIo=; b=tC38zC53NrlHNXAPbzNI6GF+mNSo+Y5jCugeJCze7NemPPnkAI1s S+1ZeI97sFhxkcB4hymXBX9ULSKjNEHSU+LvqMsyeL2r7rNUcyoUmlJ0mUZN6i4c qn0rzLxisCCYZGWLIWXMoYbclCmKiPcc+U2DfalY5K2pxmmBOH+tAkg= Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id 9623E42807A for ; Fri, 4 Jan 2013 13:41:24 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id dq11so7602695wgb.2 for ; Fri, 04 Jan 2013 13:41:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.99.227 with SMTP id et3mr82723648wib.6.1357335683029; Fri, 04 Jan 2013 13:41:23 -0800 (PST) Received: by 10.217.82.73 with HTTP; Fri, 4 Jan 2013 13:41:22 -0800 (PST) Received: by 10.217.82.73 with HTTP; Fri, 4 Jan 2013 13:41:22 -0800 (PST) In-Reply-To: <1357326438.18192.190.camel@destiny.pc.cs.cmu.edu> References: <31096_1357297002_r04AueRc031874_8F0F68DB-721A-430F-AC2A-872E5BD5D231@padl.com> <1357326438.18192.190.camel@destiny.pc.cs.cmu.edu> Date: Fri, 4 Jan 2013 15:41:22 -0600 Message-ID: From: Nico Williams To: Jeffrey Hutzelman Content-Type: multipart/alternative; boundary=f46d041826aa3a5a1f04d27d57b9 Cc: kitten@ietf.org, "dev-identity@lists.mozilla.org" Subject: Re: [kitten] BrowserID GSS mechanism 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, 04 Jan 2013 21:41:26 -0000 --f46d041826aa3a5a1f04d27d57b9 Content-Type: text/plain; charset=UTF-8 On Jan 4, 2013 2:07 PM, "Jeffrey Hutzelman" wrote: > > On Fri, 2013-01-04 at 21:44 +1100, Luke Howard wrote: > > I made some notes on a putative BrowserID GSS mechanism here: > > > > > > http://www.padl.com/~lukeh/gss-browserid.html (or .md) > > > > > > I intend to write it up as an Internet Draft at some point. Comments > > welcome. > > I've so far only skimmed this, but it looks so far like it probably has > the makings of a good mechanism. I would ask that if you're going to > use a DH exchange to obtain keying material for PRF and per-message > tokens, that you write that portion of the document such that it can be > reused by reference in other mechanisms. Nico would probably say it > should actually be done as a stackable mechanism, but I won't insist on > that. I'd like that, but nah. The more interesting thing is that this is the first mech we have that can authenticate the initiator but not the acceptor yet prevents MITM attacks. (Active attackers can impersonate the acceptor to the initiator but not vice versa; they cannot steal or reuse the initiator's credentials.) By not authenticating the acceptor this mech can't be used with SASL/GS2, but the security properties of this mech make it safe to use with SASL/GS2 nonetheless. We should update SASL/GS2 to relax the requirement for GSS_C_NT_HOSTBASED_SERVICE support! Nico -- --f46d041826aa3a5a1f04d27d57b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jan 4, 2013 2:07 PM, "Jeffrey Hutzelman" <jhutz@cmu.edu> wrote:
>
> On Fri, 2013-01-04 at 21:44 +1100, Luke Howard wrote:
> > I made some notes on a putative BrowserID GSS mechanism here:
> >
> >
> > http://= www.padl.com/~lukeh/gss-browserid.html (or .md)
> >
> >
> > I intend to write it up as an Internet Draft at some point. Comme= nts
> > welcome.
>
> I've so far only skimmed this, but it looks so far like it probabl= y has
> the makings of a good mechanism. =C2=A0I would ask that if you're = going to
> use a DH exchange to obtain keying material for PRF and per-message > tokens, that you write that portion of the document such that it can b= e
> reused by reference in other mechanisms. =C2=A0Nico would probably say= it
> should actually be done as a stackable mechanism, but I won't insi= st on
> that.

I'd like that, but nah.

The more interesting thing is that this is the first mech we have that c= an authenticate the initiator but not the acceptor yet prevents MITM attack= s.=C2=A0 (Active attackers can impersonate the acceptor to the initiator bu= t not vice versa; they cannot steal or reuse the initiator's credential= s.)=C2=A0 By not authenticating the acceptor this mech can't be used wi= th SASL/GS2, but the security properties of this mech make it safe to use w= ith SASL/GS2 nonetheless.=C2=A0 We should update SASL/GS2 to relax the requ= irement for GSS_C_NT_HOSTBASED_SERVICE support!

Nico
--

--f46d041826aa3a5a1f04d27d57b9-- From lukeh@padl.com Fri Jan 4 13:51:37 2013 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 5AB1921F884A for ; Fri, 4 Jan 2013 13:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyNC0MHLmyXc for ; Fri, 4 Jan 2013 13:51:36 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id C1CD121F87FD for ; Fri, 4 Jan 2013 13:51:36 -0800 (PST) Received: by us.padl.com with ESMTP id r04LpRMJ016084; Fri, 4 Jan 2013 16:51:30 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_94126E18-D136-4C95-9A47-0A2C5D5DA1A3" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luke Howard In-Reply-To: Date: Sat, 5 Jan 2013 08:51:27 +1100 Message-Id: <96B0C75B-D066-40DA-9B5E-283080784FEF@padl.com> References: <31096_1357297002_r04AueRc031874_8F0F68DB-721A-430F-AC2A-872E5BD5D231@padl.com> <1357326438.18192.190.camel@destiny.pc.cs.cmu.edu> To: Nico Williams X-Mailer: Apple Mail (2.1499) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: kitten@ietf.org, "dev-identity@lists.mozilla.org" , Jeffrey Hutzelman Subject: Re: [kitten] BrowserID GSS mechanism 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, 04 Jan 2013 21:51:37 -0000 --Apple-Mail=_94126E18-D136-4C95-9A47-0A2C5D5DA1A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > The more interesting thing is that this is the first mech we have that = can authenticate the initiator but not the acceptor yet prevents MITM = attacks. (Active attackers can impersonate the acceptor to the = initiator but not vice versa; they cannot steal or reuse the initiator's = credentials.) By not authenticating the acceptor this mech can't be = used with SASL/GS2, but the security properties of this mech make it = safe to use with SASL/GS2 nonetheless. We should update SASL/GS2 to = relax the requirement for GSS_C_NT_HOSTBASED_SERVICE support. >=20 You mean GSS_C_MUTUAL_FLAG? :-) The mech does support GSS_C_NT_HOSTBASED_SERVICE (the acceptor can = verify the initiator's idea of its name). -- Luke= --Apple-Mail=_94126E18-D136-4C95-9A47-0A2C5D5DA1A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

The more interesting thing is that = this is the first mech we have that can authenticate the initiator but = not the acceptor yet prevents MITM attacks.  (Active attackers can = impersonate the acceptor to the initiator but not vice versa; they = cannot steal or reuse the initiator's credentials.)  By not = authenticating the acceptor this mech can't be used with SASL/GS2, but = the security properties of this mech make it safe to use with SASL/GS2 = nonetheless.  We should update SASL/GS2 to relax the requirement = for GSS_C_NT_HOSTBASED_SERVICE support.

You mean = GSS_C_MUTUAL_FLAG? :-)

The mech does = support GSS_C_NT_HOSTBASED_SERVICE (the acceptor can verify the = initiator's idea of its name).

-- = Luke
= --Apple-Mail=_94126E18-D136-4C95-9A47-0A2C5D5DA1A3-- From jhutz@cmu.edu Fri Jan 4 14:00:22 2013 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 207A121F8877 for ; Fri, 4 Jan 2013 14:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pB-cJzY1ASqQ for ; Fri, 4 Jan 2013 14:00:21 -0800 (PST) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by ietfa.amsl.com (Postfix) with ESMTP id 664E921F8A8F for ; Fri, 4 Jan 2013 14:00:21 -0800 (PST) Received: from [192.168.33.127] (50-73-160-70-pennsylvania.hfc.comcastbusiness.net [50.73.160.70]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r04M0HQH022937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2013 17:00:18 -0500 (EST) From: Jeffrey Hutzelman To: Nico Williams In-Reply-To: References: <31096_1357297002_r04AueRc031874_8F0F68DB-721A-430F-AC2A-872E5BD5D231@padl.com> <1357326438.18192.190.camel@destiny.pc.cs.cmu.edu> Content-Type: text/plain; charset="UTF-8" Date: Fri, 04 Jan 2013 17:00:06 -0500 Message-ID: <1357336806.18192.210.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: kitten@ietf.org, "dev-identity@lists.mozilla.org" , jhutz@cmu.edu Subject: Re: [kitten] BrowserID GSS mechanism 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, 04 Jan 2013 22:00:22 -0000 On Fri, 2013-01-04 at 15:41 -0600, Nico Williams wrote: > > The more interesting thing is that this is the first mech we have that > can authenticate the initiator but not the acceptor yet prevents MITM > attacks. (Active attackers can impersonate the acceptor to the > initiator but not vice versa; they cannot steal or reuse the > initiator's credentials.) By not authenticating the acceptor this > mech can't be used with SASL/GS2, but the security properties of this > mech make it safe to use with SASL/GS2 nonetheless. We should update > SASL/GS2 to relax the requirement for GSS_C_NT_HOSTBASED_SERVICE > support! In theory, the OpenID, OAuth, and SAML mechs all cannot be used with GS2, for that reason. In practice, they lie and claim to perform mutual auth even though they actually don't, which is a serious problem for the security of GSS applications everywhere and should be fixed presently. Probably that means we need to define new versions of these mechs that don't lie, and invent a new extended-mech-inquiry property to identify which mechanisms lie in this way, so that GSS-API applications have a prayer of being able to rely on the mutual_state flag again. In the meantime, there is actually no reason GS2 cannot be used with GSS mechanisms that don't provide mutual authentication, as long as it is understood that the resulting SASL mech _also_ doesn't provide mutual authentication, and that clients may not rely on channel binding results from such mechs. Unfortunately, we've never done a really good job of explaining that SASL and GSS clients cannot rely on channel bindings if the mech does not do mutual authentication. I also don't think we've done a good job of making it clear that mechanisms must be designed so that clients _can_ rely on channel bindings if mutual auth succeeds. The Kerberos mechanism gets this right, but I'm not sure about any others. And actually, I don't think this is the first mech to have these properties. It may be the first mech with a published spec that has these properties and doesn't lie about them. -- Jeff From lukeh@padl.com Fri Jan 4 14:16:17 2013 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 A661821F8A74 for ; Fri, 4 Jan 2013 14:16:17 -0800 (PST) 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.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZTfV48skD7h for ; Fri, 4 Jan 2013 14:16:17 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id F16D321F8869 for ; Fri, 4 Jan 2013 14:16:16 -0800 (PST) Received: by us.padl.com with ESMTP id r04MG7b4017872; Fri, 4 Jan 2013 17:16:10 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luke Howard In-Reply-To: <1357336806.18192.210.camel@destiny.pc.cs.cmu.edu> Date: Sat, 5 Jan 2013 09:16:07 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <70CB65AA-D036-47A9-BDA3-B698A198503E@padl.com> References: <31096_1357297002_r04AueRc031874_8F0F68DB-721A-430F-AC2A-872E5BD5D231@padl.com> <1357326438.18192.190.camel@destiny.pc.cs.cmu.edu> <1357336806.18192.210.camel@destiny.pc.cs.cmu.edu> To: Jeffrey Hutzelman X-Mailer: Apple Mail (2.1499) 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" , Alexey Melnikov Subject: Re: [kitten] BrowserID GSS mechanism 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, 04 Jan 2013 22:16:17 -0000 > In theory, the OpenID, OAuth, and SAML mechs all cannot be used with > GS2, for that reason. In practice, they lie and claim to perform = mutual > auth even though they actually don't, which is a serious problem for = the > security of GSS applications everywhere and should be fixed presently. > Probably that means we need to define new versions of these mechs that > don't lie, and invent a new extended-mech-inquiry property to identify > which mechanisms lie in this way, so that GSS-API applications have a > prayer of being able to rely on the mutual_state flag again. Exactly. I was surprised when GS2 failed with the BrowserID mechanism = (because it doesn't lie about GSS_C_MUTUAL_FLAG), and then I read RFC = 5801 again, and the code, and realised that it was just implementing the = spec. Cyrus SASL already checks if the mechanisms supports mutual = authentication and sets a SASL flag to indicate this (which presumably = the application can check): if (MA_PRESENT(GSS_C_MA_AUTH_TARG)) *security_flags |=3D SASL_SEC_MUTUAL_AUTH; So maybe it's safe to relax that check. > In the meantime, there is actually no reason GS2 cannot be used with = GSS > mechanisms that don't provide mutual authentication, as long as it is > understood that the resulting SASL mech _also_ doesn't provide mutual > authentication, and that clients may not rely on channel binding = results > from such mechs. Unfortunately, we've never done a really good job of > explaining that SASL and GSS clients cannot rely on channel bindings = if > the mech does not do mutual authentication. I also don't think we've > done a good job of making it clear that mechanisms must be designed so > that clients _can_ rely on channel bindings if mutual auth succeeds. > The Kerberos mechanism gets this right, but I'm not sure about any > others. I need to get my head around this still. Does not using CB to bind the = context to a channel in which the client has authenticated the server = provide the moral equivalent of mutual authentication? I'm thinking of = the typical case where the client verifies a server's TLS certificate. = (OK, maybe there are lots of clients that don't even bother to do that = properly!) -- Luke= From lukeh@padl.com Fri Jan 4 14:16:59 2013 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 E4AB121F8464 for ; Fri, 4 Jan 2013 14:16:59 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEmRzmP4r9Ky for ; Fri, 4 Jan 2013 14:16:59 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 9B07A21F845F for ; Fri, 4 Jan 2013 14:16:53 -0800 (PST) Received: by us.padl.com with ESMTP id r04MG7b5017872; Fri, 4 Jan 2013 17:16:52 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luke Howard In-Reply-To: <70CB65AA-D036-47A9-BDA3-B698A198503E@padl.com> Date: Sat, 5 Jan 2013 09:16:51 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <31096_1357297002_r04AueRc031874_8F0F68DB-721A-430F-AC2A-872E5BD5D231@padl.com> <1357326438.18192.190.camel@destiny.pc.cs.cmu.edu> <1357336806.18192.210.camel@destiny.pc.cs.cmu.edu> <70CB65AA-D036-47A9-BDA3-B698A198503E@padl.com> To: "kitten@ietf.org" X-Mailer: Apple Mail (2.1499) 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 Subject: Re: [kitten] BrowserID GSS mechanism 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, 04 Jan 2013 22:17:00 -0000 > Cyrus SASL already checks if the mechanisms supports mutual = authentication and sets a SASL flag to indicate this (which presumably = the application can check): >=20 > if (MA_PRESENT(GSS_C_MA_AUTH_TARG)) > *security_flags |=3D SASL_SEC_MUTUAL_AUTH; >=20 > So maybe it's safe to relax that check. By "that check" I mean only advertising mechanisms that support = GSS_C_MA_AUTH_TARG. -- Luke= From nico@cryptonector.com Fri Jan 4 14:23:28 2013 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 56B4821F872D for ; Fri, 4 Jan 2013 14:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tl1bzaHVpPR5 for ; Fri, 4 Jan 2013 14:23:27 -0800 (PST) Received: from homiemail-a97.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id D01EE21F86E6 for ; Fri, 4 Jan 2013 14:23:27 -0800 (PST) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 68E82286074 for ; Fri, 4 Jan 2013 14:23:27 -0800 (PST) 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=Y6pB384LdXi5C9extrI9 OuLNNt8=; b=WlGRzLJ1pm6RqHgLm16OD73fcqPc/WqG+vV8QUt0AK0M+xfkFQA1 xn9jmlq8pyquQsp1aO3W5DBRj2VbrOzydK30I6zer8pEtpY4gNQGcmwSGQZnz9ag bNNOkBBkxIxzFByq9fXqqpOqRSLOBBJhjc1WnXdoDTa+9x6nTdzxcP4= Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id 12ACC286058 for ; Fri, 4 Jan 2013 14:23:26 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so7957659wey.31 for ; Fri, 04 Jan 2013 14:23:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.99.1 with SMTP id em1mr82312156wib.20.1357338205715; Fri, 04 Jan 2013 14:23:25 -0800 (PST) Received: by 10.217.82.73 with HTTP; Fri, 4 Jan 2013 14:23:25 -0800 (PST) Received: by 10.217.82.73 with HTTP; Fri, 4 Jan 2013 14:23:25 -0800 (PST) In-Reply-To: <96B0C75B-D066-40DA-9B5E-283080784FEF@padl.com> References: <31096_1357297002_r04AueRc031874_8F0F68DB-721A-430F-AC2A-872E5BD5D231@padl.com> <1357326438.18192.190.camel@destiny.pc.cs.cmu.edu> <96B0C75B-D066-40DA-9B5E-283080784FEF@padl.com> Date: Fri, 4 Jan 2013 16:23:25 -0600 Message-ID: From: Nico Williams To: Luke Howard Content-Type: multipart/alternative; boundary=f46d0418258a977d5504d27ded6e Cc: kitten@ietf.org, "dev-identity@lists.mozilla.org" , Jeffrey Hutzelman Subject: Re: [kitten] BrowserID GSS mechanism 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, 04 Jan 2013 22:23:28 -0000 --f46d0418258a977d5504d27ded6e Content-Type: text/plain; charset=UTF-8 On Jan 4, 2013 4:51 PM, "Luke Howard" wrote: >> >> [...] We should update SASL/GS2 to relax the requirement for GSS_C_NT_HOSTBASED_SERVICE support. > > You mean GSS_C_MUTUAL_FLAG? :-) No. That flag refers to key confirmation, not to authentication of each party to the other. > The mech does support GSS_C_NT_HOSTBASED_SERVICE (the acceptor can verify the initiator's idea of its name). Oh. Then we probably need to think a bit more about how to distinguish the two meanings of "mutual authentication". --f46d0418258a977d5504d27ded6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jan 4, 2013 4:51 PM, "Luke Howard" <lukeh@padl.com> wrote:
>>
>> [...]=C2=A0 We should update SASL/GS2 to relax the requirement for= GSS_C_NT_HOSTBASED_SERVICE support.
>
> You mean GSS_C_MUTUAL_FLAG? :-)

No.=C2=A0 That flag refers to key confirmation, not to authentication of= each party to the other.

> The mech does support=C2=A0GSS_C_NT_HOSTBASED_SERVICE (the acceptor= can verify the initiator's idea of its name).

Oh.=C2=A0 Then we probably need to think a bit more about how to disting= uish the two meanings of "mutual authentication".

--f46d0418258a977d5504d27ded6e-- From lukeh@padl.com Fri Jan 4 14:29:17 2013 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 8688721F8732 for ; Fri, 4 Jan 2013 14:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ypI7iW6ajGX for ; Fri, 4 Jan 2013 14:29:17 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7F921F86DD for ; Fri, 4 Jan 2013 14:29:16 -0800 (PST) Received: by us.padl.com with ESMTP id r04MT8RP018191; Fri, 4 Jan 2013 17:29:12 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_52B55035-6963-409D-B5B0-4159C07E8251" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luke Howard In-Reply-To: Date: Sat, 5 Jan 2013 09:29:08 +1100 Message-Id: References: <31096_1357297002_r04AueRc031874_8F0F68DB-721A-430F-AC2A-872E5BD5D231@padl.com> <1357326438.18192.190.camel@destiny.pc.cs.cmu.edu> <96B0C75B-D066-40DA-9B5E-283080784FEF@padl.com> To: Nico Williams X-Mailer: Apple Mail (2.1499) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: kitten@ietf.org, "dev-identity@lists.mozilla.org" , Jeffrey Hutzelman Subject: Re: [kitten] BrowserID GSS mechanism 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, 04 Jan 2013 22:29:17 -0000 --Apple-Mail=_52B55035-6963-409D-B5B0-4159C07E8251 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > > You mean GSS_C_MUTUAL_FLAG? :-) >=20 > No. That flag refers to key confirmation, not to authentication of = each party to the other. >=20 Do you have a reference? Skimming RFC2743 the most direct I could find = was "mutual_state =3D=3D TRUE ... target authenticated to initiator". -- Luke= --Apple-Mail=_52B55035-6963-409D-B5B0-4159C07E8251 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

> You mean GSS_C_MUTUAL_FLAG? :-)

No.  That flag refers to key confirmation, not to authentication of each party to the other.


Do you have a reference? Skimming RFC2743 the most direct I could find was "mutual_state == TRUE ... target authenticated to initiator".

-- Luke
--Apple-Mail=_52B55035-6963-409D-B5B0-4159C07E8251-- From jhutz@cmu.edu Fri Jan 4 14:34:32 2013 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 8E97C21F8ABA for ; Fri, 4 Jan 2013 14:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+wbBPnc0iic for ; Fri, 4 Jan 2013 14:34:32 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 019FA21F8A42 for ; Fri, 4 Jan 2013 14:34:31 -0800 (PST) Received: from [192.168.33.127] (50-73-160-70-pennsylvania.hfc.comcastbusiness.net [50.73.160.70]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r04MYSRB024392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2013 17:34:29 -0500 (EST) From: Jeffrey Hutzelman To: Nico Williams In-Reply-To: References: <31096_1357297002_r04AueRc031874_8F0F68DB-721A-430F-AC2A-872E5BD5D231@padl.com> <1357326438.18192.190.camel@destiny.pc.cs.cmu.edu> <96B0C75B-D066-40DA-9B5E-283080784FEF@padl.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 04 Jan 2013 17:34:22 -0500 Message-ID: <1357338862.18192.219.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: kitten@ietf.org, "dev-identity@lists.mozilla.org" , jhutz@cmu.edu Subject: Re: [kitten] BrowserID GSS mechanism 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, 04 Jan 2013 22:34:32 -0000 On Fri, 2013-01-04 at 16:23 -0600, Nico Williams wrote: > > On Jan 4, 2013 4:51 PM, "Luke Howard" wrote: > >> > >> [...] We should update SASL/GS2 to relax the requirement for > GSS_C_NT_HOSTBASED_SERVICE support. > > > > You mean GSS_C_MUTUAL_FLAG? :-) > > No. That flag refers to key confirmation, not to authentication of > each party to the other. > > > The mech does support GSS_C_NT_HOSTBASED_SERVICE (the acceptor can > verify the initiator's idea of its name). > > Oh. Then we probably need to think a bit more about how to > distinguish the two meanings of "mutual authentication". > Hm? "mutual authentication" here means that the mechanism has proven the acceptor's identity to the initiator. It should go without saying that any further services provided by the mechanism, such as CB, PRF, and per-message tokens, are provided using keys known only to the initiator and the actual acceptor, whether or not mutual_flag is set. From nico@cryptonector.com Fri Jan 4 14:35:32 2013 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 0EA7121F8ABA for ; Fri, 4 Jan 2013 14:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LltXcLf0vLym for ; Fri, 4 Jan 2013 14:35:31 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2512421F8AA8 for ; Fri, 4 Jan 2013 14:35:31 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id DB32D438079 for ; Fri, 4 Jan 2013 14:35:30 -0800 (PST) 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=gF7W+PzMwxV9Eq7C9WdK VzveID4=; b=vwQ/vqnT4suc3PttCGB2LMVV9KMpW+nfyAAY/pw1FHOTFnJBlTew LGZUTU3e95R1HVdl+CFc7cMdnJXFW5UEjbVpZGt99w50mtdl8UuSMixpw6l1clTE U3rvgTTufDKeIbYbOSjlGs2aCVZHvU40OjmJX3bj3qlbklPQFoqEw10= Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 8F77B438072 for ; Fri, 4 Jan 2013 14:35:30 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id u3so8169489wey.16 for ; Fri, 04 Jan 2013 14:35:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.33.44 with SMTP id o12mr77414036wii.28.1357338929385; Fri, 04 Jan 2013 14:35:29 -0800 (PST) Received: by 10.217.82.73 with HTTP; Fri, 4 Jan 2013 14:35:28 -0800 (PST) Received: by 10.217.82.73 with HTTP; Fri, 4 Jan 2013 14:35:28 -0800 (PST) In-Reply-To: References: <31096_1357297002_r04AueRc031874_8F0F68DB-721A-430F-AC2A-872E5BD5D231@padl.com> <1357326438.18192.190.camel@destiny.pc.cs.cmu.edu> <96B0C75B-D066-40DA-9B5E-283080784FEF@padl.com> Date: Fri, 4 Jan 2013 16:35:28 -0600 Message-ID: From: Nico Williams To: Luke Howard Content-Type: multipart/alternative; boundary=f46d043bdc5ab9d15104d27e182e Cc: kitten@ietf.org, "dev-identity@lists.mozilla.org" , Jeffrey Hutzelman Subject: Re: [kitten] BrowserID GSS mechanism 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, 04 Jan 2013 22:35:32 -0000 --f46d043bdc5ab9d15104d27e182e Content-Type: text/plain; charset=UTF-8 On Jan 4, 2013 5:23 PM, "Nico Williams" wrote: > > > On Jan 4, 2013 4:51 PM, "Luke Howard" wrote: > >> > >> [...] We should update SASL/GS2 to relax the requirement for GSS_C_NT_HOSTBASED_SERVICE support. > > > > You mean GSS_C_MUTUAL_FLAG? :-) > > No. That flag refers to key confirmation, not to authentication of each party to the other. > > > The mech does support GSS_C_NT_HOSTBASED_SERVICE (the acceptor can verify the initiator's idea of its name). > > Oh. Then we probably need to think a bit more about how to distinguish the two meanings of "mutual authentication". Or, the method you have of authenticating the acceptor, though weak, is close enough to mutual auth. We may simply need to add a mech attr that says the mech prevents impersonation of the server, and then we can say something about when this mech attr should be required by the app. Nico -- --f46d043bdc5ab9d15104d27e182e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Jan 4, 2013 5:23 PM, "Nico Williams" <nico@cryptonector.com> wrote:
>
>
> On Jan 4, 2013 4:51 PM, "Luke Howard" <lukeh@padl.com> wrote:
> >>
> >> [...]=C2=A0 We should update SASL/GS2 to relax the requiremen= t for GSS_C_NT_HOSTBASED_SERVICE support.
> >
> > You mean GSS_C_MUTUAL_FLAG? :-)
>
> No.=C2=A0 That flag refers to key confirmation, not to authentication = of each party to the other.
>
> > The mech does support=C2=A0GSS_C_NT_HOSTBASED_SERVICE (the accept= or can verify the initiator's idea of its name).
>
> Oh.=C2=A0 Then we probably need to think a bit more about how to disti= nguish the two meanings of "mutual authentication".

Or, the method you have of authenticating the acceptor, though weak, is = close enough to mutual auth.=C2=A0 We may simply need to add a mech attr th= at says the mech prevents impersonation of the server, and then we can say = something about when this mech attr should be required by the app.

Nico
--

--f46d043bdc5ab9d15104d27e182e-- From nico@cryptonector.com Fri Jan 4 14:52:40 2013 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 B911B21F8686 for ; Fri, 4 Jan 2013 14:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-PfHO8zshfk for ; Fri, 4 Jan 2013 14:52:40 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2890E21F8698 for ; Fri, 4 Jan 2013 14:52:40 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id C324D94065 for ; Fri, 4 Jan 2013 14:52:39 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (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 6DE9E9405E for ; Fri, 4 Jan 2013 14:52:39 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so7971758wey.31 for ; Fri, 04 Jan 2013 14:52:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.119.33 with SMTP id kr1mr86929683wjb.4.1357339958229; Fri, 04 Jan 2013 14:52:38 -0800 (PST) Received: by 10.217.82.73 with HTTP; Fri, 4 Jan 2013 14:52:38 -0800 (PST) Received: by 10.217.82.73 with HTTP; Fri, 4 Jan 2013 14:52:38 -0800 (PST) In-Reply-To: <1357338862.18192.219.camel@destiny.pc.cs.cmu.edu> References: <31096_1357297002_r04AueRc031874_8F0F68DB-721A-430F-AC2A-872E5BD5D231@padl.com> <1357326438.18192.190.camel@destiny.pc.cs.cmu.edu> <96B0C75B-D066-40DA-9B5E-283080784FEF@padl.com> <1357338862.18192.219.camel@destiny.pc.cs.cmu.edu> Date: Fri, 4 Jan 2013 16:52:38 -0600 Message-ID: From: Nico Williams To: Jeffrey Hutzelman Content-Type: multipart/alternative; boundary=089e01227b940cbb7504d27e5626 Cc: kitten@ietf.org, "dev-identity@lists.mozilla.org" Subject: Re: [kitten] BrowserID GSS mechanism 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, 04 Jan 2013 22:52:40 -0000 --089e01227b940cbb7504d27e5626 Content-Type: text/plain; charset=UTF-8 On Jan 4, 2013 5:34 PM, "Jeffrey Hutzelman" wrote: > > On Fri, 2013-01-04 at 16:23 -0600, Nico Williams wrote: > > > > On Jan 4, 2013 4:51 PM, "Luke Howard" wrote: > > >> > > >> [...] We should update SASL/GS2 to relax the requirement for > > GSS_C_NT_HOSTBASED_SERVICE support. > > > > > > You mean GSS_C_MUTUAL_FLAG? :-) > > > > No. That flag refers to key confirmation, not to authentication of > > each party to the other. > > > > > The mech does support GSS_C_NT_HOSTBASED_SERVICE (the acceptor can > > verify the initiator's idea of its name). > > > > Oh. Then we probably need to think a bit more about how to > > distinguish the two meanings of "mutual authentication". > > > Hm? "mutual authentication" here means that the mechanism has proven > the acceptor's identity to the initiator. It should go without saying > that any further services provided by the mechanism, such as CB, PRF, > and per-message tokens, are provided using keys known only to the > initiator and the actual acceptor, whether or not mutual_flag is set. In the Kerberos mech the mutual auth flag refers to the full round trip exchange, (as opposed to the half-round trip exchange). Oh, ok, I think that confused me. So, yes, i think we want to relax the mutual auth req in SASL/GS2, with some carefully written text. --089e01227b940cbb7504d27e5626 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jan 4, 2013 5:34 PM, "Jeffrey Hutzelman" <jhutz@cmu.edu> wrote:
>
> On Fri, 2013-01-04 at 16:23 -0600, Nico Williams wrote:
> >
> > On Jan 4, 2013 4:51 PM, "Luke Howard" <lukeh@padl.com> wrote:
> > >>
> > >> [...] =C2=A0We should update SASL/GS2 to relax the requi= rement for
> > GSS_C_NT_HOSTBASED_SERVICE support.
> > >
> > > You mean GSS_C_MUTUAL_FLAG? :-)
> >
> > No. =C2=A0That flag refers to key confirmation, not to authentica= tion of
> > each party to the other.
> >
> > > The mech does support GSS_C_NT_HOSTBASED_SERVICE (the accept= or can
> > verify the initiator's idea of its name).
> >
> > Oh. =C2=A0Then we probably need to think a bit more about how to<= br> > > distinguish the two meanings of "mutual authentication"= .
> >
> Hm? =C2=A0"mutual authentication" here means that the mechan= ism has proven
> the acceptor's identity to the initiator. =C2=A0It should go witho= ut saying
> that any further services provided by the mechanism, such as CB, PRF,<= br> > and per-message tokens, are provided using keys known only to the
> initiator and the actual acceptor, whether or not mutual_flag is set.<= /p>

In the Kerberos mech the mutual auth flag refers to the full round trip = exchange,=C2=A0 (as opposed to the half-round trip exchange).=C2=A0 Oh, ok,= I think that confused me.=C2=A0 So, yes, i think we want to relax the mutu= al auth req in SASL/GS2, with some carefully written text.

--089e01227b940cbb7504d27e5626-- From lukeh@padl.com Fri Jan 4 18:47:46 2013 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 DF5E421F874C for ; Fri, 4 Jan 2013 18:47:46 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6k2tfU6XhY3 for ; Fri, 4 Jan 2013 18:47:45 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id A81DF21F8749 for ; Fri, 4 Jan 2013 18:47:45 -0800 (PST) Received: by us.padl.com with ESMTP id r052lc34029936; Fri, 4 Jan 2013 21:47:40 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luke Howard In-Reply-To: <1357338862.18192.219.camel@destiny.pc.cs.cmu.edu> Date: Sat, 5 Jan 2013 13:47:37 +1100 Content-Transfer-Encoding: 7bit Message-Id: <8ED44BDC-875E-442D-987D-A73917F1FC8E@padl.com> References: <31096_1357297002_r04AueRc031874_8F0F68DB-721A-430F-AC2A-872E5BD5D231@padl.com> <1357326438.18192.190.camel@destiny.pc.cs.cmu.edu> <96B0C75B-D066-40DA-9B5E-283080784FEF@padl.com> <1357338862.18192.219.camel@destiny.pc.cs.cmu.edu> To: Jeffrey Hutzelman X-Mailer: Apple Mail (2.1499) 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, "dev-identity@lists.mozilla.org" Subject: Re: [kitten] BrowserID GSS mechanism 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: Sat, 05 Jan 2013 02:47:47 -0000 > Hm? "mutual authentication" here means that the mechanism has proven > the acceptor's identity to the initiator. It should go without saying > that any further services provided by the mechanism, such as CB, PRF, > and per-message tokens, are provided using keys known only to the > initiator and the actual acceptor, whether or not mutual_flag is set. Right, that was always my understanding too. -- Luke From leifj@mnt.se Sat Jan 5 06:54:41 2013 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 B179521F85AE for ; Sat, 5 Jan 2013 06:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mE3aUbbJCKlx for ; Sat, 5 Jan 2013 06:54:41 -0800 (PST) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7817121F859C for ; Sat, 5 Jan 2013 06:54:39 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id fh20so11303082lab.6 for ; Sat, 05 Jan 2013 06:54:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=PUeb1w+3s0JuO5C05ul/cVXo3nr2jJ1Ubl+E/VzmCGc=; b=VDpv2OPRbtHvinj/ByHNbla6KRXDCDRVa/xZUvw5t4Ru/nPgxdK/uVE0W8eNqdyeib k8lL4DqIceY7O+xm3PrqYWtySmMtAMryMNT6jIofZ+v+GIQ/yUedutdDA57DzMQY0kH1 2X3isTxC+gPEaLFuxe1EiqKUzjWq+eDE47vuCSKa3VuxK6wVibtDw69YpVJLa4bfl2vE y+3ZFGmFkbEMGipX3OecQRTtrq1HHzV/6h3C+n9vfYSqbJuEMD0xbM5usaSa0KMZKnKP kWBoy8ZigetmNF1EckpO3vB1ypl6x/SbflIExH5gTC18VWMu5FhUDywygMl+1Uc5VevG cbVg== X-Received: by 10.112.50.138 with SMTP id c10mr22621286lbo.104.1357397679029; Sat, 05 Jan 2013 06:54:39 -0800 (PST) Received: from [192.168.1.116] (c-2ec318ed-74736162.cust.telenor.se. [46.195.24.237]) by mx.google.com with ESMTPS id sr6sm20506783lab.4.2013.01.05.06.54.36 (version=SSLv3 cipher=OTHER); Sat, 05 Jan 2013 06:54:38 -0800 (PST) References: <50E6966D.9040704__49484.1541782536$1357289172$gmane$org@oracle.com> <87mwwp19io.fsf@latte.josefsson.org> <1357326252.18192.188.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 (1.0) In-Reply-To: <1357326252.18192.188.camel@destiny.pc.cs.cmu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10A523) From: Leif Johansson Date: Sat, 5 Jan 2013 15:54:33 +0100 To: Jeffrey Hutzelman X-Gm-Message-State: ALoCoQnkPW1try218YVMF65HBg1nKWt1txErG/GIifpCmgJ0dAhNhLWH+PREEEdgsEW/hTp53DxZ Cc: "kitten@ietf.org" , Simon Josefsson , "ietf-krb-wg@lists.anl.gov" , "jhutz@cmu.edu" Subject: Re: [kitten] [Ietf-krb-wg] Kitten and Kerberos WG Merger - New Charter 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: Sat, 05 Jan 2013 14:54:41 -0000 4 jan 2013 kl. 20:04 skrev Jeffrey Hutzelman : > On Fri, 2013-01-04 at 12:18 +0100, Simon Josefsson wrote: >=20 >>> This charter subsumes the Kerberos WG under the auspices of the kitten W= G. >>> Therefore the following charter text contains both kitten and Kerberos W= G items. >>=20 >> I suggest to remove this paragraph. I don't see significant value in >> having that in the WG charter, and it seems confusing for anyone not >> familiar with the history. >=20 > That was actually put in as a way of recording the history and giving > people not familiar with it a way to find older Kerberos-related work. > However, it was not the topic of a lot of wordsmithing, and I don't > think anyone who contributed to this proposal is wedded to that > language. So, if someone wants to propose alternate text... >=20 >=20 >>> KDC Model (draft-ietf-krb-wg-kdc-model) >>=20 >> Long overdue. I have always preferred that this document shipped >> together with an instanciation of it, such as an LDAP schema. I based >> my KDC backend database on an earlier version of this draft, but the >> document has changed since then. Without implementations it is >> difficult to know whether there are flaws in the abstract model. >=20 > It's certainly not going to ship "together with" a schema. While I've > heard various people speak in favor of having an LDAP schema over the > years, including at the last krb-wg rechartering, there doesn't seem to > be enough interest in actually working on it for anything to happen. > The model document is nearly done (in the hands of the IESG, except for > revisions Leif recently posted to the list on which there have _still_ > been no comments). It's not going to sit around and wait for additional > work that may never happen. Agreed=20 >=20 >=20 >=20 >>> PKINIT Hash Agility (draft-ietf-krb-wg-pkinit-alg-agility) >>> Kerberos IANA Registry (draft-ietf-kitten-kerberos-iana-registries) >>> Initial and Pass Through Authentication in Kerberos 5 (draft-ietf-krb-wg= -iakerb) >>> Unencrypted Portion of Ticket Extensions (draft-ietf-krb-wg-ticket-exten= sions) >>=20 >> No objection. >=20 > ... but will you work on any of these items? Review them? >=20 > IAKERB was basically done some time ago, but needs an editor to manage > the document through the various review processes on the way to getting > it published. =20 >=20 > Ticket Extensions is a mostly complete proposal which krb-wg adopted > some years ago, and which has languished since due to lack of cycles. > This document is at version -00, and will probably need a couple of > editing cycles before it reaches WGLC; it would be nice to see someone > step up to do that work. >=20 >=20 >>> Define interfaces for better error message reporting. >>=20 >> I'd rather not spend time on that. Do we have a problem statement to >> argue why this is important? >=20 > The GSS-API's error reporting interfaces are somewhat clunky, to say the > least. It is certainly possible to get a complete set of error > messages, but since there is no connection to a particular context, it > is unnecessarily complex for the implementation to report contextualized > errors, especially when multiple threads and/or mechanisms are involved. > Additionally, there is no mechanism for localization of error message > text. >=20 >=20 >=20 >> Good idea -- will review. >>=20 >>> Cryptographic algorithms intended for standards track status must b= e of >>> good quality, have broad international support, and fill a definite= need. >>=20 >> IMHO this sentence is weasel-wording to motivate arbitrary decisions to >> match some people's crypto preferences. The IETF already have policies >> around crypto (for example RFC 1984) that are sufficient motivation to >> turn down obviously bad proposals. When a proposal is not obviously >> bad, I belive the WG should be able to review any proposal with >> non-judgemental eyes. >=20 > We had this discussion during krb-wg's last rechartering, and this > wording is the result of that hard-won consensus. It doesn't prevent > the WG from reviewing any proposal and even taking on work to produce an > informational document. >=20 > It does constrain what can end up on the standards track. In practice, > I don't think the constraint is overly onerous. For example, what kept > camellia from being published on the standards track was not this > requirement, but the lack of consensus within the WG to recommend it. >=20 >=20 >=20 >>> Goals and Milestones >>> -------------------- >>>=20 >>> Jan 2013 draft-ietf-kitten-sasl-oauth to IESG >>> Jan 2013 draft-ietf-krb-wg-kdc-model to IESG >>> Feb 2013 draft-ietf-krb-wg-pkinit-alg-agility to IESG >>> Feb 2013 draft-ietf-kitten-sasl-saml-ec to IESG >>> Mar 2013 draft-ietf-krb-wg-iakerb to IESG >>> Mar 2013 draft-ietf-kitten-gssapi-extensions-iana to IESG >>> Apr 2013 draft-ietf-krb-wg-cammac to IESG >>> Apr 2013 draft-ietf-kitten-kerberos-iana-registries to IESG >>> May 2013 draft-ietf-krb-wg-pad to IESG >>> May 2013 Adopt work on one or more items for GSS-API cred management >>> Jun 2013 Adopt work on better error reporting in the GSS-API >>> Jun 2013 Adopt work on exporting partially-established GSS-API contex= ts >>> Jul 2013 draft-ietf-krb-wg-ticket-extensions to IESG >>> Jul 2013 Adopt work on the GSS-API for replay cache avoidance >>=20 >> I believe the targets are unrealistically optimistic, however my >> perception is that the only purpose for having dates in the milestones >> is to enable IESG to put pressure on WG's to deliver. So I support >> setting an aggresive timeline. >=20 > I agree that some of these are pretty optimistic. However, at least > some of the early ones look OK. For example, kdc-model, pkinit-agility, > and iakerb should all already be done enough to make or beat those > deadlines, so I have no objections to them. >=20 > I can't speak to the GSS/SASL documents with early milestones, except > that I do not believe the SASL OAuth document is ready to go -- it has a > serious problem with the mechanism lying about mutual authentication, > which I raised last month and to which I so far have seen no response. >=20 > -- Jeff >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From alexey.melnikov@isode.com Sun Jan 6 09:19:27 2013 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 74BB621F8628 for ; Sun, 6 Jan 2013 09:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeTj2hSRhFDY for ; Sun, 6 Jan 2013 09:19:26 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7B221F8419 for ; Sun, 6 Jan 2013 09:19:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1357492763; d=isode.com; s=selector; i=@isode.com; bh=89xqdwhUrhpIhz/p97dqTCDN7oT2gqok0HgyKnBx+ow=; 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=w+OJ7joVNTATXzI5sTgIfcHyrzT3zNRM+V75gxNLHcagWFjvGbzJDHqCdU9MbZWOX82QzJ /beUn/9Fy93N8tt58ask6pJTYeRnYKoeG+/KpMj4qPLRG7hi8MrPC17nfR0GtGn9+QhHcM eFG/I+Vec/vU84AK9aND7JN6+4I6u0w=; Received: from [92.41.44.166] (92.41.44.166.threembb.co.uk [92.41.44.166]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 6 Jan 2013 17:19:23 +0000 References: <50E6966D.9040704__49484.1541782536$1357289172$gmane$org@oracle.com> <87mwwp19io.fsf@latte.josefsson.org> In-Reply-To: <87mwwp19io.fsf@latte.josefsson.org> Message-Id: X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Sun, 6 Jan 2013 17:24:15 +0000 To: Shawn Emery MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Simon Josefsson , "ietf-krb-wg@lists.anl.gov" Subject: Re: [kitten] Kitten and Kerberos WG Merger - New Charter 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: Sun, 06 Jan 2013 17:19:27 -0000 Using Simon's email as a template for my reply: On 4 Jan 2013, at 11:18, Simon Josefsson wrote: > Shawn Emery writes: >=20 >> Common Authentication Technology Next Generation (kitten) >> --------------------------------------------------------- >>=20 >> Charter > ... >=20 >> This charter subsumes the Kerberos WG under the auspices of the kitten WG= . >> Therefore the following charter text contains both kitten and Kerberos WG= items. >=20 > I suggest to remove this paragraph. I don't see significant value in > having that in the WG charter, and it seems confusing for anyone not > familiar with the history. No strong opinion either way, in particular I don't see this text as harmful= /confusing. >> In detail, both existing and new work items include: >>=20 >> Existing Working Group Items >> --------------------------- >> SASL Mechanism for OAuth (draft-ietf-kitten-sasl-oauth) >=20 > Good idea -- will review, could contribute. Will review. >=20 >> SASL Mechansim for SAML-EC (draft-ietf-kitten-sasl-saml-ec) >=20 > Good idea -- will contribute & review. Will review. >=20 >> GSS-API IANA Registry (draft-ietf-kitten-gssapi-extensions-iana) >=20 > No objection. :-(. Well, happy to get this done, but need some nagging from WG chairs, etc= . >=20 >> KDC Model (draft-ietf-krb-wg-kdc-model) >=20 > Long overdue. I have always preferred that this document shipped > together with an instanciation of it, such as an LDAP schema. +1 to both. > I based > my KDC backend database on an earlier version of this draft, but the > document has changed since then. Without implementations it is > difficult to know whether there are flaws in the abstract model. >=20 >> PKINIT Hash Agility (draft-ietf-krb-wg-pkinit-alg-agility) >> Kerberos IANA Registry (draft-ietf-kitten-kerberos-iana-registries) >> Initial and Pass Through Authentication in Kerberos 5 (draft-ietf-krb-wg-= iakerb) >> Unencrypted Portion of Ticket Extensions (draft-ietf-krb-wg-ticket-extens= ions) >=20 > No objection. Same here, although I admit I haven't read any of these docs. >=20 >> GSS-API Related >> --------------- >> Provide new interfaces for credential management, which include the >> following: >> initializing credentials >> iterating credentials >> exporting/importing credentials >=20 > Good idea -- will review, could contribute. Will review. Can somebody write a strawman? >=20 >> Negotiable replay cache avoidance >=20 > No objection. No opinion (outside of my area of expertise). >=20 >> Define interfaces for better error message reporting. >=20 > I'd rather not spend time on that. Do we have a problem statement to > argue why this is important? Agreed. Or at least I would like to see a strawman, so that I can say "wow, h= ow can I program without this in the past" ;) >=20 >> Specify an option for exporting partially-established security >> contexts and possibly a utility function for exporting security >> contexts in an encrypted form, as well as a corresponding utility >> function to decrypt and import such security context tokens. >=20 > Good idea - may review. +1 >=20 >> Specify one-time password / two-factor authentication needs for SASL >> applications. This could be achieved through an explicit new >> GSS-API/SASL mechanism (e.g., >> http://tools.ietf.org/html/draft-josefsson-kitten-crotp-00) or if >> the consensus is that due to usability reasons, it is preferable to d= o >> OTP/2FA through an higher level protocol >> (Kerberos/OpenID/SAML/SAML20EC/EAP?) then prepare a document explain= ing >> the usability problem and provide pointers for implementers. >=20 > Good idea -- will contribute. +1. There was a somewhat similar proposal about doing dual PKI authentication: o= f a user and of a device. Are people interested in working on that one? >=20 >> Kerberos Related >> ---------------- >> Prepare and advance one or more standards-track specifications which >> update the Kerberos version 5 protocol to support non-ASCII principa= l >> and realm names, salt strings, and passwords, and localized error >> reporting. Maximizing backward compatibility is strongly desired. >=20 > Localized error reporting: good idea -- will contribute. The draft for > it has been ready for a long time. >=20 Will review. > Regarding the rest I would prefer to wait until other protocols have > deployed PRECIS to gain experience with it. Given the experience with > SASLprep in SASL it was fortunate that we didn't go that route with > Kerberos. I don't want Kerberos to end up in a similar situation only > replacing SASLprep with PRECIS. >=20 >> Prepare, review, and advance standards-track and informational >> specifications defining new authorization data types for carrying >> supplemental information about the client to which a Kerberos ticket= >> has been issued and/or restrictions on what the ticket can be used >> for. To enhance this ongoing authorization data work, a container >> format supporting the use cases of draft-ietf-krb-wg-pad may be >> standardized. >=20 > Good idea. >=20 Will review. >> Prepare a standards-track protocol to solve the use cases addressed >> by draft-hotz-kx509-01 including new support for digital signatures.= >=20 > Good idea. >=20 No idea, need to read the draft first. >> Today Kerberos requires a replay cache to be used in AP exchanges in >> almost all cases. Replay caches are quite complex to implement >> correctly, particularly in clustered systems. High-performance repla= y >> caches are even more difficult to implement. The WG will pursue >> extensions to minimize the need for replay caching, optimize replay >> caching, and/or elide the need for replay caching. >=20 > Good idea. >=20 >> Prepare, review, and advance standards-track and informational >> specifications defining use of new cryptographic algorithms in the >> Kerberos protocol using the RFC3961 framework, on an ongoing >> basis. =20 >=20 > Good idea -- will review. >=20 >> Cryptographic algorithms intended for standards track status must be= of >> good quality, have broad international support, and fill a definite n= eed. >=20 > IMHO this sentence is weasel-wording to motivate arbitrary decisions to > match some people's crypto preferences. The IETF already have policies > around crypto (for example RFC 1984) that are sufficient motivation to > turn down obviously bad proposals. When a proposal is not obviously > bad, I belive the WG should be able to review any proposal with > non-judgemental eyes. >=20 >> Prepare, review, and advance standards-track and informational >> specifications of new pre-authentication types for the Kerberos >> protocol, on an ongoing basis. >=20 > Good idea. >=20 >> Prepare, review, and advance standards track updates and extensions to RFC= 4121, >> as needed and on an ongoing basis. >=20 > Good idea. Overall I see this as a very long list of things that could be done, for whi= ch I don't think we collectively have cycles. Instead of having 20 deliverab= les, most without drafts, how about we pick 5 (or maybe 10, if people insist= ) and drive them to completion quicker. Rechartering is cheap! >=20 >> Goals and Milestones >> -------------------- >>=20 >> Jan 2013 draft-ietf-kitten-sasl-oauth to IESG >> Jan 2013 draft-ietf-krb-wg-kdc-model to IESG >> Feb 2013 draft-ietf-krb-wg-pkinit-alg-agility to IESG >> Feb 2013 draft-ietf-kitten-sasl-saml-ec to IESG >> Mar 2013 draft-ietf-krb-wg-iakerb to IESG >> Mar 2013 draft-ietf-kitten-gssapi-extensions-iana to IESG >> Apr 2013 draft-ietf-krb-wg-cammac to IESG >> Apr 2013 draft-ietf-kitten-kerberos-iana-registries to IESG >> May 2013 draft-ietf-krb-wg-pad to IESG >> May 2013 Adopt work on one or more items for GSS-API cred management >> Jun 2013 Adopt work on better error reporting in the GSS-API >> Jun 2013 Adopt work on exporting partially-established GSS-API context= s >> Jul 2013 draft-ietf-krb-wg-ticket-extensions to IESG >> Jul 2013 Adopt work on the GSS-API for replay cache avoidance >=20 > I believe the targets are unrealistically optimistic, however my > perception is that the only purpose for having dates in the milestones > is to enable IESG to put pressure on WG's to deliver. So I support > setting an aggresive timeline. I am Ok with motivational milestones. Agree that the above is optimistic tho= ugh. From alexey.melnikov@isode.com Sun Jan 6 09:31:37 2013 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 1E23821F84F5 for ; Sun, 6 Jan 2013 09:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMx6lET5PRAx for ; Sun, 6 Jan 2013 09:31:36 -0800 (PST) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8422321F851E for ; Sun, 6 Jan 2013 09:31:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1357493493; d=isode.com; s=selector; i=@isode.com; bh=xxQk+TC+BTtwc9tJjLzf9umHqxV5at6Of/zO/AiykLk=; 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=FEPr0dFFSiSM5yMyDmmClMxNp0lXhELyQ0Dcamnin1n3UC7wpXY27igKU3wUOzxYHReu/1 Mk0Upj+dBHgHzPJE02TYzH83hMDG3cmfT9Zoj/ilqsbKST+EVIYTYT+9SIqIZCks8jazM6 BFqZ0xpVH7cldCj5lrG5cNXAv+JiA+I=; Received: from [92.41.44.166] (92.41.44.166.threembb.co.uk [92.41.44.166]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 6 Jan 2013 17:31:32 +0000 References: <50BF006B.8000306@sunet.se> In-Reply-To: <50BF006B.8000306@sunet.se> Message-Id: <5B1764DA-7564-432C-9A56-87F6FCCF18D8@isode.com> X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Sun, 6 Jan 2013 17:36:46 +0000 To: Leif Johansson MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" , Pete Resnick Subject: Re: [kitten] forward the information model 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: Sun, 06 Jan 2013 17:31:37 -0000 Sorry, I probably wasn't paying enough attention to this issue, but I person= ally would prefer to see new definitions first. On 5 Dec 2012, at 08:06, Leif Johansson wrote: >=20 > At ATL I had a conversation with Pete about our use of RFC2119 language > in the information model draft. >=20 > We agreed that one way forward is for us to drop the _reference_ to RFC211= 9 > and replace the standard 2119 boilerplate with language of our own that > explain the terms MUST, SHOULD, etc. >=20 > We both agree that dropping the use of all-caps words of this type is > probably > not a viable option. >=20 > I'd like the WGs comment on the plan before proposing language text. >=20 > Best R > Leif > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From jhutz@cmu.edu Sun Jan 6 09:57:39 2013 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 D033021F84E0 for ; Sun, 6 Jan 2013 09:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id youxTLDcWCZD for ; Sun, 6 Jan 2013 09:57:39 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3FE21F84DE for ; Sun, 6 Jan 2013 09:57:39 -0800 (PST) Received: from [192.168.202.133] (pool-74-111-100-191.pitbpa.fios.verizon.net [74.111.100.191]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r06HvWZF006332 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 6 Jan 2013 12:57:35 -0500 (EST) User-Agent: K-9 Mail for Android In-Reply-To: <50E968EC.3080505@symas.com> References: <50E6966D.9040704__49484.1541782536$1357289172$gmane$org@oracle.com> <87mwwp19io.fsf@latte.josefsson.org> <1357326252.18192.188.camel@destiny.pc.cs.cmu.edu> <50E968EC.3080505@symas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Jeffrey Hutzelman Date: Sun, 06 Jan 2013 12:57:24 -0500 To: Howard Chu , Leif Johansson Message-ID: <4487a7c1-796d-459e-8c0e-b875cdc6931c@email.android.com> X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: "kitten@ietf.org" , Simon Josefsson , "ietf-krb-wg@lists.anl.gov" Subject: Re: [kitten] [Ietf-krb-wg] Kitten and Kerberos WG Merger - New Charter 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: Sun, 06 Jan 2013 17:57:39 -0000 Howard Chu wrote: >Leif Johansson wrote: >> >> >> 4 jan 2013 kl. 20:04 skrev Jeffrey Hutzelman : >> >>> On Fri, 2013-01-04 at 12:18 +0100, Simon Josefsson wrote: >>> >>>>> This charter subsumes the Kerberos WG under the auspices of the >kitten WG. >>>>> Therefore the following charter text contains both kitten and >Kerberos WG items. >>>> >>>> I suggest to remove this paragraph. I don't see significant value >in >>>> having that in the WG charter, and it seems confusing for anyone >not >>>> familiar with the history. >>> >>> That was actually put in as a way of recording the history and >giving >>> people not familiar with it a way to find older Kerberos-related >work. >>> However, it was not the topic of a lot of wordsmithing, and I don't >>> think anyone who contributed to this proposal is wedded to that >>> language. So, if someone wants to propose alternate text... >>> >>> >>>>> KDC Model (draft-ietf-krb-wg-kdc-model) >>>> >>>> Long overdue. I have always preferred that this document shipped >>>> together with an instanciation of it, such as an LDAP schema. I >based >>>> my KDC backend database on an earlier version of this draft, but >the >>>> document has changed since then. Without implementations it is >>>> difficult to know whether there are flaws in the abstract model. >>> >>> It's certainly not going to ship "together with" a schema. While >I've >>> heard various people speak in favor of having an LDAP schema over >the >>> years, including at the last krb-wg rechartering, there doesn't seem >to >>> be enough interest in actually working on it for anything to happen. >>> The model document is nearly done (in the hands of the IESG, except >for >>> revisions Leif recently posted to the list on which there have >_still_ >>> been no comments). It's not going to sit around and wait for >additional >>> work that may never happen. > >Excuse me? Work that may never happen? >http://tools.ietf.org/html/draft-chu-ldap-kdc-schema-00 > >This has been waiting around for 3 years waiting for the Model document >to be >finalized. Naturally the schema can't be finalized before the Model. >> >> Agreed Wow; I totally forgot about that. Sorry. From jhutz@cmu.edu Sun Jan 6 09:57:42 2013 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 93C8121F857B for ; Sun, 6 Jan 2013 09:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXWxaRBzNJJY for ; Sun, 6 Jan 2013 09:57:42 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 445A521F8545 for ; Sun, 6 Jan 2013 09:57:42 -0800 (PST) Received: from [192.168.202.133] (pool-74-111-100-191.pitbpa.fios.verizon.net [74.111.100.191]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r06Hvdep006338 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 6 Jan 2013 12:57:41 -0500 (EST) User-Agent: K-9 Mail for Android In-Reply-To: <50E968EC.3080505@symas.com> References: <50E6966D.9040704__49484.1541782536$1357289172$gmane$org@oracle.com> <87mwwp19io.fsf@latte.josefsson.org> <1357326252.18192.188.camel@destiny.pc.cs.cmu.edu> <50E968EC.3080505@symas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Jeffrey Hutzelman Date: Sun, 06 Jan 2013 12:57:23 -0500 To: Howard Chu , Leif Johansson Message-ID: X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: "kitten@ietf.org" , Simon Josefsson , "ietf-krb-wg@lists.anl.gov" Subject: Re: [kitten] [Ietf-krb-wg] Kitten and Kerberos WG Merger - New Charter 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: Sun, 06 Jan 2013 17:57:42 -0000 Howard Chu wrote: >Leif Johansson wrote: >> >> >> 4 jan 2013 kl. 20:04 skrev Jeffrey Hutzelman : >> >>> On Fri, 2013-01-04 at 12:18 +0100, Simon Josefsson wrote: >>> >>>>> This charter subsumes the Kerberos WG under the auspices of the >kitten WG. >>>>> Therefore the following charter text contains both kitten and >Kerberos WG items. >>>> >>>> I suggest to remove this paragraph. I don't see significant value >in >>>> having that in the WG charter, and it seems confusing for anyone >not >>>> familiar with the history. >>> >>> That was actually put in as a way of recording the history and >giving >>> people not familiar with it a way to find older Kerberos-related >work. >>> However, it was not the topic of a lot of wordsmithing, and I don't >>> think anyone who contributed to this proposal is wedded to that >>> language. So, if someone wants to propose alternate text... >>> >>> >>>>> KDC Model (draft-ietf-krb-wg-kdc-model) >>>> >>>> Long overdue. I have always preferred that this document shipped >>>> together with an instanciation of it, such as an LDAP schema. I >based >>>> my KDC backend database on an earlier version of this draft, but >the >>>> document has changed since then. Without implementations it is >>>> difficult to know whether there are flaws in the abstract model. >>> >>> It's certainly not going to ship "together with" a schema. While >I've >>> heard various people speak in favor of having an LDAP schema over >the >>> years, including at the last krb-wg rechartering, there doesn't seem >to >>> be enough interest in actually working on it for anything to happen. >>> The model document is nearly done (in the hands of the IESG, except >for >>> revisions Leif recently posted to the list on which there have >_still_ >>> been no comments). It's not going to sit around and wait for >additional >>> work that may never happen. > >Excuse me? Work that may never happen? >http://tools.ietf.org/html/draft-chu-ldap-kdc-schema-00 > >This has been waiting around for 3 years waiting for the Model document >to be >finalized. Naturally the schema can't be finalized before the Model. >> >> Agreed Wow; I totally forgot about that. Sorry. From nico@cryptonector.com Sun Jan 6 11:40:54 2013 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 B13A121F84F5 for ; Sun, 6 Jan 2013 11:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbSbe6mP1gms for ; Sun, 6 Jan 2013 11:40:54 -0800 (PST) Received: from homiemail-a87.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id EFEE221F84E6 for ; Sun, 6 Jan 2013 11:40:53 -0800 (PST) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 8D98726C05E for ; Sun, 6 Jan 2013 11:40:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=3ECR4l6eut+aLCRI/D6e43QshRQ=; b=hrCJ7g47SmQ G1w30GetVjrE3rKDpG16fnG5p97vZWRMaHhMMPW13HTmTZdk+wR5dcfUjMeBCPHl QFQ8Z2XKUrOVYFkZp9CThKhtmFW9jC060UPVnAwdFx/SoPz/V11S9AjjoMB9aO3T eEYWNoWC0FOXDKNPRGNVtivZUGflu0Ls= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id 3766F26C057 for ; Sun, 6 Jan 2013 11:40:53 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id es5so9174311wgb.29 for ; Sun, 06 Jan 2013 11:40:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.77.13 with SMTP id o13mr92562747wjw.58.1357501251993; Sun, 06 Jan 2013 11:40:51 -0800 (PST) Received: by 10.217.82.73 with HTTP; Sun, 6 Jan 2013 11:40:51 -0800 (PST) Date: Sun, 6 Jan 2013 13:40:51 -0600 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Cc: Jeffrey Hutzelman Subject: [kitten] On mutual auth; security considerations for the BrowserID mech 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: Sun, 06 Jan 2013 19:40:54 -0000 GSS_Init_sec_context() allows the initiator to specify what the target's name is. There's a constant, GSS_C_NO_NAME, that should allow the initiator to indicate it doesn't care what the acceptor's name is. One would expect that specifying a target name implies desiring mutual authentication, and that specifying GSS_C_NO_NAME for the target would imply indifference to mutual authentication. Why, then, would we need a flag for indicating the desire for mutual authentication? Meanwhile the mutual authentication flag's meaning is a bit confused, even in RFC2743. (I'm glossing over details). Consider Kerberos: is it really the case that the half round trip version of the AP exchange provides no mutual authentication? Provided that the peers use per-message tokens afterwards the answer can only be "no". (If CB is desired instead of per-msg tokens then we need key confirmation to confirm the CB to the initiator, but if we don't we get the security considerations discussed further below.) And if the application simply does an AP exchange and then uses no further confidentiality/integrity protection, then how would it help to have done a full round trip version of AP? The answer is that if we assume no active on-path attackers then the full round trip does help. But that is not the Internet threat model, so I'm tempted to ignore this case, or rather, to write it up as a security consideration. This isn't to say that the full round trip AP exchange adds no value. The point is that it doesn't add really "mutuality", and that it'd be better to have a name for what it does do than to confuse the issue. I could go on. I think the bottom line is that we have a slight mess on our hands. Meanwhile we need to give guidance to apps that might want to use mechanisms like Luke's BrowserID. As well as guidance to implementors of such mechanisms. Here's my proposed guidance: - The BrowserID mechanism does not provide mutual authentication. It can provide key confirmation. - The BrowserID mechanism does not support naming acceptors at all. Luke's implementation pretends to, but it's not really doing much (remember, the acceptor will pass in GSS_C_NO_CREDENTIAL, or a credential for GSS_C_NO_NAME, to GSS_Accept_sec_context(), so the acceptor will tend to agree to any name that the initiator might have called it by). It would be better to say that Luke's mechanism's GSS_Init_sec_context() MUST fail if target_name != GSS_C_NO_NAME! This would force the matter of surfacing to the application the need to indicate that it doesn't need mutual authentication. - What we need is for SASL apps to deal with the security considerations of lacking mutual authentication. This means that a SASL API like, say, CyrusSASL's, will need a way for the client application to indicate that the server's name is irrelevant, or otherwise that mutual authentication is not required. - How should an application decide if it wants mutual auth? This is the hard one. For an IMAP application where the user will begin by browsing their e-mail we clearly don't need mutual auth: the contents of the mailstore will impliedly authenticate the server to the user. For an application that uses TLS and is satisfied with the server's cert mutual authentication in SASL will also not matter. But note that mutual authentication will matter in many apps too: e.g., an IMAP app that begins by sending e-mail via creating messages in an outbox, or most LDAP applications. To me this implies that the need for mutual authentication is often something that should be specified by local policy, or even by the user (though users are mostly not to be trusted to make such a judgement, or even asked to). Nico -- From leifj@mnt.se Sun Jan 6 12:37:44 2013 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 3D81C21F8464 for ; Sun, 6 Jan 2013 12:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTL3G6+h370G for ; Sun, 6 Jan 2013 12:37:43 -0800 (PST) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) by ietfa.amsl.com (Postfix) with ESMTP id CCCED21F8E73 for ; Sun, 6 Jan 2013 12:37:42 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id ej20so13748399lab.35 for ; Sun, 06 Jan 2013 12:37:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=cJBByiLW9/piANn1MKWpiPj3B+3RB4+y+qg56BlqnTk=; b=pmdnfO0W/SRqSf2LKqpelV9RrzILE6xR9BEj9wE70Ci35Qn283YArlJwqtDX2kVk2+ V4WI4xgTMRm2stO5+7Q2UwbLGIBn0myCisnQMvM0rTGHyrvRgiBcQ4wGhmDDapfdd46d FIpDLCqA65CO/yFYeN9Uf74qfFUD49+2wEomhyXH+p7pmxEkNyfM7vwk2Ga7CplUsvnx W9sXcGtvwoTNCWEaQApX5h5g2tK3BX7XGo7Am3XYB1br0O3TCzreNMEZE99Edt26kOFU tPdYi1On9bP4tPWRQcXV/Ll1+DNS9MxxYzcJnlW237+1fhQKYB+7SVhI99+5zyRZuRMp De8A== X-Received: by 10.152.132.69 with SMTP id os5mr55659801lab.15.1357504661458; Sun, 06 Jan 2013 12:37:41 -0800 (PST) Received: from [10.0.0.232] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPS id u5sm20125164lbm.8.2013.01.06.12.37.38 (version=SSLv3 cipher=OTHER); Sun, 06 Jan 2013 12:37:40 -0800 (PST) References: <50E6966D.9040704__49484.1541782536$1357289172$gmane$org@oracle.com> <87mwwp19io.fsf@latte.josefsson.org> <1357326252.18192.188.camel@destiny.pc.cs.cmu.edu> <50E968EC.3080505@symas.com> Mime-Version: 1.0 (1.0) In-Reply-To: <50E968EC.3080505@symas.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <77A2CF29-30AF-4487-93D1-136641EDBBB2@mnt.se> X-Mailer: iPad Mail (10A523) From: Leif Johansson Date: Sun, 6 Jan 2013 21:37:38 +0100 To: Howard Chu X-Gm-Message-State: ALoCoQlL9QhX3SAbhT+m8ULaFoRrCbwMMQnSymx5LUj6xDCa8P7g97xVVifOp69Mt3ehJRsWm3YG Cc: "kitten@ietf.org" , Simon Josefsson , "ietf-krb-wg@lists.anl.gov" , Jeffrey Hutzelman Subject: Re: [kitten] [Ietf-krb-wg] Kitten and Kerberos WG Merger - New Charter 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: Sun, 06 Jan 2013 20:37:44 -0000 6 jan 2013 kl. 13:07 skrev Howard Chu : > Leif Johansson wrote: >>=20 >>=20 >> 4 jan 2013 kl. 20:04 skrev Jeffrey Hutzelman : >>=20 >>> On Fri, 2013-01-04 at 12:18 +0100, Simon Josefsson wrote: >>>=20 >>>>> This charter subsumes the Kerberos WG under the auspices of the kitten= WG. >>>>> Therefore the following charter text contains both kitten and Kerberos= WG items. >>>>=20 >>>> I suggest to remove this paragraph. I don't see significant value in >>>> having that in the WG charter, and it seems confusing for anyone not >>>> familiar with the history. >>>=20 >>> That was actually put in as a way of recording the history and giving >>> people not familiar with it a way to find older Kerberos-related work. >>> However, it was not the topic of a lot of wordsmithing, and I don't >>> think anyone who contributed to this proposal is wedded to that >>> language. So, if someone wants to propose alternate text... >>>=20 >>>=20 >>>>> KDC Model (draft-ietf-krb-wg-kdc-model) >>>>=20 >>>> Long overdue. I have always preferred that this document shipped >>>> together with an instanciation of it, such as an LDAP schema. I based >>>> my KDC backend database on an earlier version of this draft, but the >>>> document has changed since then. Without implementations it is >>>> difficult to know whether there are flaws in the abstract model. >>>=20 >>> It's certainly not going to ship "together with" a schema. While I've >>> heard various people speak in favor of having an LDAP schema over the >>> years, including at the last krb-wg rechartering, there doesn't seem to >>> be enough interest in actually working on it for anything to happen. >>> The model document is nearly done (in the hands of the IESG, except for >>> revisions Leif recently posted to the list on which there have _still_ >>> been no comments). It's not going to sit around and wait for additional= >>> work that may never happen. >=20 > Excuse me? Work that may never happen? > http://tools.ietf.org/html/draft-chu-ldap-kdc-schema-00 >=20 > This has been waiting around for 3 years waiting for the Model document to= be finalized. Naturally the schema can't be finalized before the Model. >>=20 Forgot about that one, nice! >> Agreed >=20 > --=20 > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ From simon@josefsson.org Sun Jan 6 13:26:23 2013 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 C7AC121F856C for ; Sun, 6 Jan 2013 13:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.582 X-Spam-Level: X-Spam-Status: No, score=-101.582 tagged_above=-999 required=5 tests=[AWL=-1.673, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvGctnMlJ9Fm for ; Sun, 6 Jan 2013 13:26:23 -0800 (PST) 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 01B8921F8561 for ; Sun, 6 Jan 2013 13:26:22 -0800 (PST) Received: from latte.josefsson.org (host-95-192-63-171.mobileonline.telia.com [95.192.63.171]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r06LQ7pu016025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 6 Jan 2013 22:26:10 +0100 From: Simon Josefsson To: Jeffrey Hutzelman References: <50E6966D.9040704__49484.1541782536$1357289172$gmane$org@oracle.com> <87mwwp19io.fsf@latte.josefsson.org> <1357326252.18192.188.camel__30427.9769458391$1357326307$gmane$org@destiny.pc.cs.cmu.edu> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130106:jhutz@cmu.edu::uQPRX6jd/PAu2l+w:DA4N X-Hashcash: 1:22:130106:kitten@ietf.org::1fiyGtlESiSJ30sI:CJJG X-Hashcash: 1:22:130106:ietf-krb-wg@lists.anl.gov::ukL3E5h6i0AKBOpz:U80f Date: Sun, 06 Jan 2013 22:26:02 +0100 In-Reply-To: <1357326252.18192.188.camel__30427.9769458391$1357326307$gmane$org@destiny.pc.cs.cmu.edu> (Jeffrey Hutzelman's message of "Fri, 04 Jan 2013 14:04:12 -0500") Message-ID: <87wqvqyped.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (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" , ietf-krb-wg@lists.anl.gov Subject: Re: [kitten] Kitten and Kerberos WG Merger - New Charter 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: Sun, 06 Jan 2013 21:26:23 -0000 Jeffrey Hutzelman writes: >> > PKINIT Hash Agility (draft-ietf-krb-wg-pkinit-alg-agility) >> > Kerberos IANA Registry (draft-ietf-kitten-kerberos-iana-registries) >> > Initial and Pass Through Authentication in Kerberos 5 >> > (draft-ietf-krb-wg-iakerb) >> > Unencrypted Portion of Ticket Extensions >> > (draft-ietf-krb-wg-ticket-extensions) >> >> No objection. > > ... but will you work on any of these items? Review them? No, I was merely stating my thoughts on all items in the list. "Good idea" didn't fit, and "Bad idea" was a too strong choice for me: I just don't care about those drafts. I currently don't plan to spend any cycles on them. >> > Define interfaces for better error message reporting. >> >> I'd rather not spend time on that. Do we have a problem statement to >> argue why this is important? > > The GSS-API's error reporting interfaces are somewhat clunky, to say the > least. It is certainly possible to get a complete set of error > messages, but since there is no connection to a particular context, it > is unnecessarily complex for the implementation to report contextualized > errors, especially when multiple threads and/or mechanisms are involved. > Additionally, there is no mechanism for localization of error message > text. All of GSS-API is clunky, to say the least. I'm not convinced this particular clunkyness is that important, but like Alexey said, if someone describe a better error reporting interface, I could change opinion. It has to be so much better that it covers the migration pains, which is a challenge. /Simon From simon@josefsson.org Sun Jan 6 13:30:52 2013 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 0966121F856C for ; Sun, 6 Jan 2013 13:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.582 X-Spam-Level: X-Spam-Status: No, score=-101.582 tagged_above=-999 required=5 tests=[AWL=-1.673, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lft0IeZm6L6G for ; Sun, 6 Jan 2013 13:30:51 -0800 (PST) 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 2A88921F854F for ; Sun, 6 Jan 2013 13:30:50 -0800 (PST) Received: from latte.josefsson.org (host-95-192-63-171.mobileonline.telia.com [95.192.63.171]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r06LUE4U016144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 6 Jan 2013 22:30:23 +0100 From: Simon Josefsson To: Howard Chu References: <50E6966D.9040704__49484.1541782536$1357289172$gmane$org@oracle.com> <87mwwp19io.fsf@latte.josefsson.org> <1357326252.18192.188.camel@destiny.pc.cs.cmu.edu> <50E968EC.3080505@symas.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130106:kitten@ietf.org::Yt8mTLz4piexEFTe:1xQ5 X-Hashcash: 1:22:130106:hyc@symas.com::XaMVQdvogEoZqswP:1aRi X-Hashcash: 1:22:130106:jhutz@cmu.edu::Y95Rp3atu2cLLDkC:CPrB X-Hashcash: 1:22:130106:leifj@mnt.se::OjUdSzhXzOSnybkk:Ff9C X-Hashcash: 1:22:130106:ietf-krb-wg@lists.anl.gov::806ipp7WgolkbZYT:VXfl Date: Sun, 06 Jan 2013 22:30:03 +0100 In-Reply-To: <50E968EC.3080505@symas.com> (Howard Chu's message of "Sun, 06 Jan 2013 04:07:08 -0800") Message-ID: <87pq1iyp7o.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (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" , "ietf-krb-wg@lists.anl.gov" , Jeffrey Hutzelman Subject: Re: [kitten] Kitten and Kerberos WG Merger - New Charter 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: Sun, 06 Jan 2013 21:30:52 -0000 Howard Chu writes: > http://tools.ietf.org/html/draft-chu-ldap-kdc-schema-00 > > This has been waiting around for 3 years waiting for the Model > document to be finalized. Naturally the schema can't be finalized > before the Model. If the LDAP schema document was updated to match the model document, and the LDAP schema implemented and deployed, that would inspire confidence in the model document. However, if that work hasn't happened in 3 years, it is unrealistic to hope for it to materialize. So I would support shipping the model document now, with the risk of having to update it later when there is implementation experience. /Simon From jhutz@cmu.edu Sun Jan 6 13:32:00 2013 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 4F46D21F842F for ; Sun, 6 Jan 2013 13:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79+GUIgH2Enz for ; Sun, 6 Jan 2013 13:31:59 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 77E4F21F842E for ; Sun, 6 Jan 2013 13:31:59 -0800 (PST) Received: from [192.168.202.158] (pool-74-111-100-191.pitbpa.fios.verizon.net [74.111.100.191]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r06LVtsR015650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2013 16:31:56 -0500 (EST) From: Jeffrey Hutzelman To: Nico Williams In-Reply-To: <853_1357501257_r06Jeuvd002491_CAK3OfOjFzecvikdhwib93CXxVb-fSuCYXfDCLsqTnEXHCRBbZA@mail.gmail.com> References: <853_1357501257_r06Jeuvd002491_CAK3OfOjFzecvikdhwib93CXxVb-fSuCYXfDCLsqTnEXHCRBbZA@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Sun, 06 Jan 2013 16:31:51 -0500 Message-ID: <1357507911.18192.335.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] On mutual auth; security considerations for the BrowserID mech 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: Sun, 06 Jan 2013 21:32:00 -0000 On Sun, 2013-01-06 at 13:40 -0600, Nico Williams wrote: > GSS_Init_sec_context() allows the initiator to specify what the > target's name is. There's a constant, GSS_C_NO_NAME, that should > allow the initiator to indicate it doesn't care what the acceptor's > name is. > > One would expect that specifying a target name implies desiring mutual > authentication NO NO NO! Specifying a target name means that I want Kerberos to work! If I desire mutual auth, I'll ask for it. If I _need_ it, I'll check to make sure I got it. This is how the GSS-API was designed to work -- mechanisms should _not_ fail context establishment just because some potentially-desirable service was not available. The model has always been that the GSS does its best to provide whatever it can, and the caller checks to make sure the resulting context is acceptable. > Consider Kerberos: is it really the case that the half round trip > version of the AP exchange provides no mutual authentication? It doesn't provide what GSS's mutual_state means. And no, GSS doesn't provide an indicator for "sort-of-mutual-auth", where some services are safe and others are not. I think that's fine; we don't need to represent every possible state. > And if the application simply does an AP exchange and then uses no > further confidentiality/integrity protection, then how would it help > to have done a full round trip version of AP? The answer is that if > we assume no active on-path attackers then the full round trip does > help. But that is not the Internet threat model, so I'm tempted to > ignore this case, or rather, to write it up as a security > consideration. Huh? We certainly talk all the time about measures that help against passive attackers but not against active attackers. There is no such thing as "the Internet threat model"; that's why we require documents to discuss various threats and what, if anything, they do about them. > This isn't to say that the full round trip AP exchange adds no value. > The point is that it doesn't add really "mutuality", and that it'd be > better to have a name for what it does do than to confuse the issue. That would be fine if it were 1993, when RFC1508 was written. At this point, it's far too late to change what "mutual authentication" means. > - The BrowserID mechanism does not provide mutual authentication. It > can provide key confirmation. What's "key confirmation" ? AFAIK that's not a concept we have. BrowserID cannot provide mutual authentication, because the mechanism contains no way for the acceptor to prove its identity. > - The BrowserID mechanism does not support naming acceptors at all. If you do that, it won't work with SSH or other applications that assume the use of host-based service names. Unless, of course, we give up on the notion of a framework and just say that every application has to have intimate knowledge of every mechanism. But if that's the case, what are we even doing here? > Luke's implementation pretends to, but it's not really doing much > (remember, the acceptor will pass in GSS_C_NO_CREDENTIAL, or a > credential for GSS_C_NO_NAME, to GSS_Accept_sec_context(), so the > acceptor will tend to agree to any name that the initiator might have > called it by). No, it does support acceptor names. It just doesn't need the name for anything. I suppose in your alternate universe, that means it doesn't "support" them because it hasn't proven the acceptor's identity. But in this universe, the GSS does not contain any implication that providing an acceptor name means the initiator wants or demands that the acceptor be authenticated. > It would be better to say that Luke's mechanism's > GSS_Init_sec_context() MUST fail if target_name != GSS_C_NO_NAME! > This would force the matter of surfacing to the application the need > to indicate that it doesn't need mutual authentication. If you do that, then Luke's mech will gratuitously not work with SSH, which uses a host-based service name for the acceptor. In fact, many applications do that, among other reasons because if you don't then Kerberos won't work, period, whether you want mutual auth or not. A mechanism that doesn't care what the acceptor name is should support all of the standard name types, and ideally should accept _any_ name, at least to the extent that the API allows a mech to handle unknown name types. > - What we need is for SASL apps to deal with the security > considerations of lacking mutual authentication. This means that a > SASL API like, say, CyrusSASL's, will need a way for the client > application to indicate that the server's name is irrelevant, or > otherwise that mutual authentication is not required. SASL apps generally do not care about mutual authentication. They really never have. We've already established some time ago that the notion of security layers is deprecated, which is why they are not supported in GS2 or in other new SASL mechs. However, SASL apps using channel bindings care about being able to rely on channel bindings. And yes, SASL apps nead to deal with the security considerations of not being able to rely on channel bindings. As it turns out, that's pretty easy too, because it's a relatively new idea (in the SASL community) to use channel bindings instead of just running everything over TLS and either checking server certs or not caring. -- Jeff From lukeh@padl.com Sun Jan 6 16:00:23 2013 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 AC90321F84DD for ; Sun, 6 Jan 2013 16:00:23 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAFDpkjXuGAc for ; Sun, 6 Jan 2013 16:00:23 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 235D021F84DC for ; Sun, 6 Jan 2013 16:00:22 -0800 (PST) Received: by us.padl.com with ESMTP id r0700AGT014296; Sun, 6 Jan 2013 19:00:15 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luke Howard In-Reply-To: Date: Mon, 7 Jan 2013 11:00:09 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Nico Williams X-Mailer: Apple Mail (2.1499) 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, Jeffrey Hutzelman Subject: Re: [kitten] On mutual auth; security considerations for the BrowserID mech 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, 07 Jan 2013 00:00:23 -0000 On 07/01/2013, at 6:40 AM, Nico Williams wrote: > It would be better to say that Luke's mechanism's > GSS_Init_sec_context() MUST fail if target_name !=3D GSS_C_NO_NAME! > This would force the matter of surfacing to the application the need > to indicate that it doesn't need mutual authentication. BrowserID requires that the name of the relying party (i.e. the = acceptor) be included in the assertion, and that it be verified. -- Luke= From lukeh@padl.com Sun Jan 6 16:01:32 2013 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 39A4C21F8501 for ; Sun, 6 Jan 2013 16:01:32 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEHVsQ61AWZi for ; Sun, 6 Jan 2013 16:01:31 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 979E521F84E8 for ; Sun, 6 Jan 2013 16:01:31 -0800 (PST) Received: by us.padl.com with ESMTP id r0701OSd014307; Sun, 6 Jan 2013 19:01:27 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luke Howard In-Reply-To: <1357507911.18192.335.camel@destiny.pc.cs.cmu.edu> Date: Mon, 7 Jan 2013 11:01:23 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <853_1357501257_r06Jeuvd002491_CAK3OfOjFzecvikdhwib93CXxVb-fSuCYXfDCLsqTnEXHCRBbZA@mail.gmail.com> <1357507911.18192.335.camel@destiny.pc.cs.cmu.edu> To: Jeffrey Hutzelman X-Mailer: Apple Mail (2.1499) 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] On mutual auth; security considerations for the BrowserID mech 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, 07 Jan 2013 00:01:32 -0000 On 07/01/2013, at 8:31 AM, Jeffrey Hutzelman wrote: >> - The BrowserID mechanism does not support naming acceptors at all. >=20 > If you do that, it won't work with SSH or other applications that = assume > the use of host-based service names. Unless, of course, we give up on > the notion of a framework and just say that every application has to > have intimate knowledge of every mechanism. But if that's the case, > what are we even doing here? Also (see my other mail), the BrowserID mechanism not only supports but = requires that acceptors be named. -- Luke= From leifj@sunet.se Mon Jan 7 00:01:21 2013 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 69B3A21F859D for ; Mon, 7 Jan 2013 00:01:21 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IPknEC-n5MK for ; Mon, 7 Jan 2013 00:01:21 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF0B21F8546 for ; Mon, 7 Jan 2013 00:01:20 -0800 (PST) Received: from [10.0.0.244] (tb62-102-145-131.cust.teknikbyran.com [62.102.145.131]) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id r0781Ctv020729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jan 2013 09:01:15 +0100 (CET) Message-ID: <50EA80C8.3030902@sunet.se> Date: Mon, 07 Jan 2013 09:01:12 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alexey Melnikov References: <50BF006B.8000306@sunet.se> <5B1764DA-7564-432C-9A56-87F6FCCF18D8@isode.com> In-Reply-To: <5B1764DA-7564-432C-9A56-87F6FCCF18D8@isode.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , Pete Resnick Subject: Re: [kitten] forward the information model 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, 07 Jan 2013 08:01:21 -0000 On 01/06/2013 06:36 PM, Alexey Melnikov wrote: > Sorry, I probably wasn't paying enough attention to this issue, but I personally would prefer to see new definitions first. > > On 5 Dec 2012, at 08:06, Leif Johansson wrote: > >> At ATL I had a conversation with Pete about our use of RFC2119 language >> in the information model draft. >> >> We agreed that one way forward is for us to drop the _reference_ to RFC2119 >> and replace the standard 2119 boilerplate with language of our own that >> explain the terms MUST, SHOULD, etc. >> >> We both agree that dropping the use of all-caps words of this type is >> probably >> not a viable option. >> >> I'd like the WGs comment on the plan before proposing language text. >> >> Best R >> Leif >> _______________________________________________ >> Kitten mailing list >> Kitten@ietf.org >> https://www.ietf.org/mailman/listinfo/kitten I posted them to the list a few days ago. From nico@cryptonector.com Mon Jan 7 05:26:38 2013 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 EC59E21F88BE for ; Mon, 7 Jan 2013 05:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYj8qzspR6+W for ; Mon, 7 Jan 2013 05:26:37 -0800 (PST) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9FA21F8792 for ; Mon, 7 Jan 2013 05:26:37 -0800 (PST) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id F102D42807B for ; Mon, 7 Jan 2013 05:26:35 -0800 (PST) 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=VFt0SP2ZhdpWtk1OrZVU UK/1h0w=; b=IxLYl2sYmRpW0QfkIt8c53C8opnUvPKEHYmV/YxqcSCoKqyjHzxl 1084z4WP4ziyMLmcIxccoQrU//ra0Z+MtnJaEfUsdumkuiWXuEXTteTNZaqOPpyr ZFp3VjFyqKtlwbiQpP9EnkaEeskCA7rTiNzeimIJwR46c/R56BXpCbM= Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id 68DB6428079 for ; Mon, 7 Jan 2013 05:26:35 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id u54so9962223wey.41 for ; Mon, 07 Jan 2013 05:26:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.77.13 with SMTP id o13mr95945537wjw.58.1357565193924; Mon, 07 Jan 2013 05:26:33 -0800 (PST) Received: by 10.217.82.73 with HTTP; Mon, 7 Jan 2013 05:26:33 -0800 (PST) In-Reply-To: <1357507911.18192.335.camel@destiny.pc.cs.cmu.edu> References: <853_1357501257_r06Jeuvd002491_CAK3OfOjFzecvikdhwib93CXxVb-fSuCYXfDCLsqTnEXHCRBbZA@mail.gmail.com> <1357507911.18192.335.camel@destiny.pc.cs.cmu.edu> Date: Mon, 7 Jan 2013 07:26:33 -0600 Message-ID: From: Nico Williams To: Jeffrey Hutzelman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] On mutual auth; security considerations for the BrowserID mech 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, 07 Jan 2013 13:26:38 -0000 On Sun, Jan 6, 2013 at 3:31 PM, Jeffrey Hutzelman wrote: > On Sun, 2013-01-06 at 13:40 -0600, Nico Williams wrote: >> GSS_Init_sec_context() allows the initiator to specify what the >> target's name is. There's a constant, GSS_C_NO_NAME, that should >> allow the initiator to indicate it doesn't care what the acceptor's >> name is. >> >> One would expect that specifying a target name implies desiring mutual >> authentication > > NO NO NO! Relax. "One would expect..." is what I wrote because I was talking about API design, not about the API we have. > Specifying a target name means that I want Kerberos to work! But not only. It's also short-hand for "inquire the context and check that the target name matches what I wanted". > If I desire mutual auth, I'll ask for it. There are alternative ways to design an API that let's you do this, and this: > If I _need_ it, I'll check to make sure I got it. > > This is how the GSS-API was designed to work -- mechanisms should _not_ > fail context establishment just because some potentially-desirable > service was not available. The model has always been that the GSS does > its best to provide whatever it can, and the caller checks to make sure > the resulting context is acceptable. I know this. Better: you know I know this. I am, however, puzzled by the apparent conflation of meanings in the mutual flag. >> Consider Kerberos: is it really the case that the half round trip >> version of the AP exchange provides no mutual authentication? > > It doesn't provide what GSS's mutual_state means. What about what someone who's never heard of the GSS-API thinks "mutual means"? >> This isn't to say that the full round trip AP exchange adds no value. >> The point is that it doesn't add really "mutuality", and that it'd be >> better to have a name for what it does do than to confuse the issue. > > That would be fine if it were 1993, when RFC1508 was written. At this > point, it's far too late to change what "mutual authentication" means. I'm not proposing any changes. I wanted to understand the meaning of the GSS mutual auth flag and spring from there to a stab at security considerations text for Luke's mechanism. >> - The BrowserID mechanism does not provide mutual authentication. It >> can provide key confirmation. > > What's "key confirmation" ? AFAIK that's not a concept we have. > BrowserID cannot provide mutual authentication, because the mechanism > contains no way for the acceptor to prove its identity. Key confirmation is where the acceptor shows it knows the session key(s). E.g., the AP-REP in Kerberos. Clearly a BrowserID-based mechanism can do the same. >> - The BrowserID mechanism does not support naming acceptors at all. > > If you do that, it won't work with SSH or other applications that assume > the use of host-based service names. Unless, of course, we give up on > the notion of a framework and just say that every application has to > have intimate knowledge of every mechanism. But if that's the case, > what are we even doing here? SSH needs mutual anyways, so it can't use BrowserID (at least not for gsapis-keyex, but I guess it'd work fine for gssapi-with-mic, and that's why we need the mutual flag). >> - What we need is for SASL apps to deal with the security >> considerations of lacking mutual authentication. This means that a >> SASL API like, say, CyrusSASL's, will need a way for the client >> application to indicate that the server's name is irrelevant, or >> otherwise that mutual authentication is not required. > > SASL apps generally do not care about mutual authentication. They > really never have. We've already established some time ago that the > notion of security layers is deprecated, which is why they are not > supported in GS2 or in other new SASL mechs. DIGEST-MD5 does provide mutual. > However, SASL apps using channel bindings care about being able to rely > on channel bindings. And yes, SASL apps nead to deal with the security > considerations of not being able to rely on channel bindings. As it > turns out, that's pretty easy too, because it's a relatively new idea > (in the SASL community) to use channel bindings instead of just running > everything over TLS and either checking server certs or not caring. CB doesn't get you out of wanting to know who you're speaking to before sending sensitive data. Nico -- From jhutz@cmu.edu Mon Jan 7 08:05:35 2013 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 A667521F8928 for ; Mon, 7 Jan 2013 08:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPGrLj+wXRJr for ; Mon, 7 Jan 2013 08:05:34 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 770A021F8923 for ; Mon, 7 Jan 2013 08:05:26 -0800 (PST) Received: from [192.168.202.158] (pool-74-111-100-191.pitbpa.fios.verizon.net [74.111.100.191]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r07G5M9C015296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jan 2013 11:05:23 -0500 (EST) From: Jeffrey Hutzelman To: Nico Williams In-Reply-To: References: <853_1357501257_r06Jeuvd002491_CAK3OfOjFzecvikdhwib93CXxVb-fSuCYXfDCLsqTnEXHCRBbZA@mail.gmail.com> <1357507911.18192.335.camel@destiny.pc.cs.cmu.edu> Content-Type: text/plain; charset="UTF-8" Date: Mon, 07 Jan 2013 11:05:14 -0500 Message-ID: <1357574714.18192.349.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] On mutual auth; security considerations for the BrowserID mech 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, 07 Jan 2013 16:05:35 -0000 On Mon, 2013-01-07 at 07:26 -0600, Nico Williams wrote: > What about what someone who's never heard of the GSS-API thinks "mutual > means"? Well, that's a problem, but one I gave up on 10+ years ago. > >> - The BrowserID mechanism does not provide mutual authentication. It > >> can provide key confirmation. > > > > What's "key confirmation" ? AFAIK that's not a concept we have. > > BrowserID cannot provide mutual authentication, because the mechanism > > contains no way for the acceptor to prove its identity. > > Key confirmation is where the acceptor shows it knows the session > key(s). E.g., the AP-REP in Kerberos. Clearly a BrowserID-based > mechanism can do the same. Hm. The AP-REP in Kerberos proves the acceptor knows the session key, and therefore must be the acceptor you intended to talk to. BrowserID contains a DH exchange, resulting in a secret shared between the initiator and some other party, who may or may not be the acceptor. Or, if you prefer, between the initiator and some party who is acting as the acceptor, but is not authenticated and so may be anyone. > >> - The BrowserID mechanism does not support naming acceptors at all. > > > > If you do that, it won't work with SSH or other applications that assume > > the use of host-based service names. Unless, of course, we give up on > > the notion of a framework and just say that every application has to > > have intimate knowledge of every mechanism. But if that's the case, > > what are we even doing here? > > SSH needs mutual anyways, so it can't use BrowserID (at least not for > gsapis-keyex, but I guess it'd work fine for gssapi-with-mic, and > that's why we need the mutual flag). Exactly. SSH needs mutual for userauth, but not for keyex. > >> - What we need is for SASL apps to deal with the security > >> considerations of lacking mutual authentication. This means that a > >> SASL API like, say, CyrusSASL's, will need a way for the client > >> application to indicate that the server's name is irrelevant, or > >> otherwise that mutual authentication is not required. > > > > SASL apps generally do not care about mutual authentication. They > > really never have. We've already established some time ago that the > > notion of security layers is deprecated, which is why they are not > > supported in GS2 or in other new SASL mechs. > > DIGEST-MD5 does provide mutual. Sort of. It provides mutual if you haven't used the same password with more than one server. IIRC, it also provides security layers. But that is not that new a mechanism. > > However, SASL apps using channel bindings care about being able to rely > > on channel bindings. And yes, SASL apps nead to deal with the security > > considerations of not being able to rely on channel bindings. As it > > turns out, that's pretty easy too, because it's a relatively new idea > > (in the SASL community) to use channel bindings instead of just running > > everything over TLS and either checking server certs or not caring. > > CB doesn't get you out of wanting to know who you're speaking to > before sending sensitive data. Correct. If you're going to send sensitive data, you need to somehow know who you're speaking to. CB provides one way to do that, _if_ the mech also provides mutual. It finally occurred to me last night why mechs like SAML violate the abstraction and try to tell GSS apps that they must use TLS. The problem is that a SAML assertion, or an OAUth 2.0 token, is essentially a bearer token -- anyone who gets their hands on it can present it for authentication, without knowing any other secrets. So, you want to be sure you don't send it to the wrong party. These mechs don't have any way to know who the party at the other end is, so they try to require that the caller take care of that before running the mech. The problem is, you can't place arbitrary constraints on GSS apps, and we don't have a way in GSS to say that a mechanism has this property; that is, that it's safe to use only over a channel to a known acceptor. -- Jeff From mrex@sap.com Tue Jan 8 11:41:09 2013 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 3DB0521F85C6 for ; Tue, 8 Jan 2013 11:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucqRF-33-7cR for ; Tue, 8 Jan 2013 11:41:08 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2409121F8581 for ; Tue, 8 Jan 2013 11:41:07 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r08Jf0eF016975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Jan 2013 20:41:00 +0100 (MET) In-Reply-To: To: Nico Williams Date: Tue, 8 Jan 2013 20:41:00 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130108194100.21FA51A445@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] On mutual auth; security considerations for the BrowserID mech 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: Tue, 08 Jan 2013 19:41:09 -0000 Nico Williams wrote: > Jeffrey Hutzelman wrote: >> >> Nico Williams wrote: >>> >>> GSS_Init_sec_context() allows the initiator to specify what the >>> target's name is. There's a constant, GSS_C_NO_NAME, that should >>> allow the initiator to indicate it doesn't care what the acceptor's >>> name is. >>> >>> One would expect that specifying a target name implies desiring mutual >>> authentication >> >> NO NO NO! > > Relax. "One would expect..." is what I wrote because I was talking > about API design, not about the API we have. > > > Specifying a target name means that I want Kerberos to work! > > But not only. It's also short-hand for "inquire the context and check > that the target name matches what I wanted". The original requirement (in GSS-API v1) to always provide a target name is really only a kludge for Kerberos. The presence of this parameter is only to enable the 2-token context establishment--rather than a 3-token exchange, similar to user2user, where the target's name is discovered during the handshake. When _not_ requesting the GSS_C_MUTUAL_FLAG on gss_init_sec_context(), then there is *NO* guarantee that the target name will match. That Kerberos context establishment will fail on a mismatch is a shortcoming of Kerberos rather than a security feature. An implementation of Kerberos that supports user2user and does not compare the given target name when doing a user2user exchange and the initiator did not request GSS_C_MUTUAL_FLAG during gss_init_sec_context() would be perfectly compliant with GSS-API v2 if it returns GSS_COMPLETE on the final call to gss_init_sec_context() while _NOT_ showing the mutual_flag on the resulting context attributes. > > > If I desire mutual auth, I'll ask for it. Correct. > > > If I _need_ it, I'll check to make sure I got it. > > > > This is how the GSS-API was designed to work -- mechanisms should _not_ > > fail context establishment just because some potentially-desirable > > service was not available. The model has always been that the GSS does > > its best to provide whatever it can, and the caller checks to make sure > > the resulting context is acceptable. Correct. > > >> Consider Kerberos: is it really the case that the half round trip > >> version of the AP exchange provides no mutual authentication? The single-token Kerberos context establishment, by itself, can _not_ provide an authentication of the acceptor to the initiator. There is only a single call to gss_init_sec_context(), which returns GSS_S_COMPLETE on success (when creating the AP_REQ), and the resulting context attribute will have to be asserted by the gssapi mechanism to the initiator along with the initial context establishment token, at a point in time where exactly nothing is known about the real acceptor/peer (which may not even exist at that point). When the application protocol uses message protection services, then depending on the app protocol design and when(!!) it uses the message protection services, then the app might infer an effective mutual authentication with Kerberos after app data exchanges (at least an app-data response) even for the single-token context establishment. But that would happen _after_ the gssapi security context establishment. Without some cryptographically strong uniqueness (such as tls-unique channel bindings), there is no mutual authentication of the acceptor to the initiator during the Kerberos gssapi context establishment alone, even with the two-token AP_REQ/AP_REP context establishment ("mutual"). That's a know shortcoming of rfc4559 "Negotiate", and AFAIK one of the things that motivated the definition of the tls-unique channel bindings. > > > > It doesn't provide what GSS's mutual_state means. > > What about what someone who's never heard of the GSS-API thinks "mutual means"? > > >> This isn't to say that the full round trip AP exchange adds no value. > >> The point is that it doesn't add really "mutuality", and that it'd be > >> better to have a name for what it does do than to confuse the issue. > > > > That would be fine if it were 1993, when RFC1508 was written. At this > > point, it's far too late to change what "mutual authentication" means. > > I'm not proposing any changes. I wanted to understand the meaning of > the GSS mutual auth flag and spring from there to a stab at security > considerations text for Luke's mechanism. >From how it is defined, the MUTUAL (resulting) context attribute indicates an authentication of the acceptor to the initiator during(!!) the gssapi security context establishment token exchange. The actualy "quality" of that mutual authentication is a seperate issue. A number of authentication protocols are susceptible to MitM or one-time-replay, so that at most the initiator might know that the tokens were computed by the intended acceptor, but not that the communication peer is the intended acceptor rather than an attacker doing MitM on the context token exchange. -Martin From mrex@sap.com Tue Jan 8 12:21:04 2013 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 2D96311E80E0 for ; Tue, 8 Jan 2013 12:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxyjhSkMT-rW for ; Tue, 8 Jan 2013 12:21:03 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9310D11E80D1 for ; Tue, 8 Jan 2013 12:21:02 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r08KKu3P021663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Jan 2013 21:20:56 +0100 (MET) In-Reply-To: To: Nico Williams Date: Tue, 8 Jan 2013 21:20:56 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130108202056.B09BD1A445@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] On mutual auth; security considerations for the BrowserID mech 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: Tue, 08 Jan 2013 20:21:04 -0000 (sorry for picking up these messages in the wrong order). Nico Williams wrote: > > GSS_Init_sec_context() allows the initiator to specify what the > target's name is. There's a constant, GSS_C_NO_NAME, that should > allow the initiator to indicate it doesn't care what the acceptor's > name is. Or, more importantly, that the initiator may not _know_ what the acceptors name is. The initiator might do the handshake first, and when the context establishment succeeds, and inquire the acceptors name and check it against an ACL. There is also _no_ requirement that a gssapi initiator is also the communication connection initiator. It is certainly possible to have reversed roles at different protocol layers. > > One would expect that specifying a target name implies desiring mutual > authentication, I certainly do not expect that. > > and that specifying GSS_C_NO_NAME for the target would > imply indifference to mutual authentication. Why, then, would we need > a flag for indicating the desire for mutual authentication? The requirement for a target name upfront is a kludge/optimization for Kerberos to enable 1-token and 2-token context establishment rather than 3-token. The existence of mutual flag should make it obvious that performing mutual authentication and supplying a target_name are independent in GSS-API, i.e. the presence of the latter will not imply the former. > > Meanwhile the mutual authentication flag's meaning is a bit confused, > even in RFC2743. (I'm glossing over details). > > Consider Kerberos: is it really the case that the half round trip > version of the AP exchange provides no mutual authentication? Yup, definitely. > > Provided that the peers use per-message tokens afterwards the answer > can only be "no". It takes more careful app design than "use one per-message token" to be able to safely infer mutual authentication later on. > > (If CB is desired instead of per-msg tokens then we > need key confirmation to confirm the CB to the initiator, but if we > don't we get the security considerations discussed further below.) Traditional gssapi CB includes much weaker information than tls-unique. > > And if the application simply does an AP exchange and then uses no > further confidentiality/integrity protection, then how would it help > to have done a full round trip version of AP? The answer is that if > we assume no active on-path attackers then the full round trip does > help. But that is not the Internet threat model, so I'm tempted to > ignore this case, or rather, to write it up as a security > consideration. The important thing to understand is that gssapi authentication and the GSS_C_MUTUAL_FLAG is are security context attributes/properties. If you take these attributes/properties out of (gssapi) context, they might loose most if not all of their meaning and value. rfc4559 is a particularly bad example where a gssapi context establishment (exchange) is abused as an OTP scheme, and the result is a serious security problem. Limiting the Negotiate exchange to the inside of a TLS channel plus using tls-unique channel bindings for the gssapi context establishment seems to address the most serious (but not all) problems from such abuse. > > This isn't to say that the full round trip AP exchange adds no value. > The point is that it doesn't add really "mutuality", and that it'd be > better to have a name for what it does do than to confuse the issue. It certainly *does* add the "mutual authentication" context attribute at the GSS-API abstraction level. Some apps (or apps designers) might be tempted to interpret this context attribute "out of context", which would be inappropriate. What might be lacking in rfc2743 is a warning sign that apps (designer) ought not make flawed assumptions or draw incorrect conclusions by taking information out of context. -Martin From jhutz@cmu.edu Thu Jan 10 11:01:03 2013 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 DC72521F8A68 for ; Thu, 10 Jan 2013 11:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbKRkArflcYw for ; Thu, 10 Jan 2013 11:01:03 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 2178D21F8A41 for ; Thu, 10 Jan 2013 11:01:03 -0800 (PST) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r0AJ0wKE016600 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 10 Jan 2013 14:00:58 -0500 (EST) Message-ID: <1357844458.2263.23.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Ozten Date: Thu, 10 Jan 2013 14:00:58 -0500 In-Reply-To: References: <31096_1357297002_r04AueRc031874_8F0F68DB-721A-430F-AC2A-872E5BD5D231@padl.com> <1357326438.18192.190.camel@destiny.pc.cs.cmu.edu> <96B0C75B-D066-40DA-9B5E-283080784FEF@padl.com> <1357338862.18192.219.camel@destiny.pc.cs.cmu.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: kitten@ietf.org, mozilla.dev.identity@googlegroups.com, "dev-identity@lists.mozilla.org" , jhutz@cmu.edu Subject: Re: [kitten] BrowserID GSS mechanism 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, 10 Jan 2013 19:01:04 -0000 On Thu, 2013-01-10 at 10:40 -0800, Ozten wrote: > I have to admit that I am ignorant of GSS, so please forgive me if this > is not possible, but I would try to do something "out of band". Instead > of altering the format of a backed assertion, what about a GSS specific > payload that includes the assertion? And how would that payload be authenticated? > If the system being logged into isn't a web addressable audience, > perhaps you can create a synthetic mapping. Example: An audience value > of urn:x-gss:ldap/example.com could be mapped to > https://ldap.example.com. No; that conflates two completely unrelated services -- the LDAP server running on example.com and the HTTP server running on ldap.example.com. Those may be completely unrelated services run by different people, and I don't want to hand one credentials that would allow it to log in as me to the other. Why constrain an audience to particular URI schemes at all? You're not connecting to that resource; it's just an identifier, so wny not allow any URI? From lukeh@padl.com Thu Jan 10 14:59:18 2013 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 8AEA321F84F1 for ; Thu, 10 Jan 2013 14:59:18 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvubakSwarax for ; Thu, 10 Jan 2013 14:59:17 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id A459721F8497 for ; Thu, 10 Jan 2013 14:59:17 -0800 (PST) Received: by us.padl.com with ESMTP id r0AMx57m005277; Thu, 10 Jan 2013 17:59:08 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luke Howard In-Reply-To: Date: Fri, 11 Jan 2013 09:59:04 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <31096_1357297002_r04AueRc031874_8F0F68DB-721A-430F-AC2A-872E5BD5D231@padl.com> <1357326438.18192.190.camel@destiny.pc.cs.cmu.edu> <96B0C75B-D066-40DA-9B5E-283080784FEF@padl.com> <1357338862.18192.219.camel@destiny.pc.cs.cmu.edu> <1357844458.2263.23.camel@minbar.fac.cs.cmu.edu> To: Austin King X-Mailer: Apple Mail (2.1499) 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, mozilla.dev.identity@googlegroups.com, "dev-identity@lists.mozilla.org" , Jeffrey Hutzelman Subject: Re: [kitten] BrowserID GSS mechanism 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, 10 Jan 2013 22:59:18 -0000 Hi Austin, > Is it possible to use BrowserID for authentication to bootstrap a = secure > communication channel, to fulfill the GSS protocol? Yes, we do a signed Diffie-Hellman exchange. More information in the = protocol specification here: http://www.padl.com/~lukeh/gss-browserid.html If this is not signed (i.e. included in the assertion), the client is = unauthenticated, and it is not a secure communication channel. > I realize that the overall GSS payload, without any verification > mechanisms, could be tampered with. >=20 > As an analogy, in a web context, BrowserID can bootstrap a session = which > can be communicated over https. Additional security can be layered in = using nonces and other web security best practices. >=20 > Are there any existing protocols or building blocks available to GSS = for > securing communication after an entity has been authenticated using = vanilla > BrowserID? No. I mean, we could build a TLS GSS mechanism, but even then that = channel would still need to be cryptographically bound to the BrowserID = authentication to avoid a MITM attack. (See RFC 5056.) Nico can probably = explain this better. > An experimental feature "key wrapping" might be a means of signing the = GSS > payload, but this isn't really available today. A signed DH exchange is fine. > I agree that the audience is just an identifier. That is why I don't = see > potentially re-using an identifier across two services as that = horrible of > an option. I agree two different people might run > https://example.comversus ldap:// > example.com, but at the end of the day they are probably two people in = the > same organization. JR Random cannot casually operate an example.com = service. >=20 > I am not trying to defend either of these suggestions, they are forged = in > ignorance. But the core suggestion I will stand by - which is strive = to > make GSS composable with the BrowserID protocol. >=20 > I'm not saying we won't open up the URI schemes or allow for arbitrary > fields eventually, but these are changes to the protocol, which will = take > time to evaluate. Composability unblocks you (and has other beneficial > engineering properties). In the GSS BrowserID protocol, the RP verifies that the audience name. = Even though there is no mutual authentication in the current protocol, = it strikes me as undesirable to have a lossy transformation from GSS = service name to an arbitrary URL. Particularly given we have an implementation that works, I'm going to = advocate strongly for doing things "the right way" (which of course is = my subjective opinion!). :-) -- Luke= From lukeh@padl.com Thu Jan 10 15:07:09 2013 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 EF11821F8586 for ; Thu, 10 Jan 2013 15:07:07 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrI9Kgm4Jdug for ; Thu, 10 Jan 2013 15:07:05 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1EE21F8415 for ; Thu, 10 Jan 2013 15:06:59 -0800 (PST) Received: by us.padl.com with ESMTP id r0AN6iqW005429; Thu, 10 Jan 2013 18:06:47 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luke Howard In-Reply-To: Date: Fri, 11 Jan 2013 10:06:44 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <0F589B78-2F2B-44DD-B09E-F6A435C83D6D@padl.com> References: <31096_1357297002_r04AueRc031874_8F0F68DB-721A-430F-AC2A-872E5BD5D231@padl.com> <1357326438.18192.190.camel@destiny.pc.cs.cmu.edu> <96B0C75B-D066-40DA-9B5E-283080784FEF@padl.com> <1357338862.18192.219.camel@destiny.pc.cs.cmu.edu> To: Ozten X-Mailer: Apple Mail (2.1499) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: 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, Jeffrey Hutzelman , dev-identity@lists.mozilla.org Subject: Re: [kitten] BrowserID GSS mechanism 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, 10 Jan 2013 23:07:09 -0000 Hi Austin, Thanks for the feedback! > Great work so far on a BrowserID GSS-API/SASL mechanism. >=20 > On the topics of changing=20 > * the valid types of URLs of an audience from http/https to allow = urn:x-gss > * BrowserID.internal.get() should allow application-defined claims >=20 > I would work towards a design that layers on top of the BrowserID = protocol, without altering it's design or forking any implementations. I agree that this is desirable and should be our starting point. = However, I think that if a layered implementation leads to "hacks" (in = the specific case above, this might mean encoding the GSS service = name/claims somehow inside the existing audience URL), it's worth = considering how much pain the "right" solution will cause. (Of course, = "right" is subjective. I'm going to argue my case from the GSS = perspective.) > I have to admit that I am ignorant of GSS, so please forgive me if = this is not possible, but I would try to do something "out of band". = Instead of altering the format of a backed assertion, what about a GSS = specific payload that includes the assertion? It needs to be "in band" so that it is signed with the user's private = key, in order to authenticate the DH exchange used to establish a = session key and/or to provide channel bindings. The less aesthetically pleasing way to do "in band" is to base32 encode = the GSS claims in the audience URL. The more pleasing way, which our = current implementation does (by some JavaScript swizzling), is to insert = these claims directly in the assertion. -- Luke= From lukeh@padl.com Fri Jan 11 07:10:50 2013 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 30B3321F886F for ; Fri, 11 Jan 2013 07:10:50 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvMLNYWpoAaA for ; Fri, 11 Jan 2013 07:10:49 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 13A2421F880B for ; Fri, 11 Jan 2013 07:10:48 -0800 (PST) Received: by us.padl.com with ESMTP id r0BFAWsg007578; Fri, 11 Jan 2013 10:10:37 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luke Howard In-Reply-To: <0F589B78-2F2B-44DD-B09E-F6A435C83D6D@padl.com> Date: Sat, 12 Jan 2013 02:10:32 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <6FF7B562-4323-43F4-A60A-333F06E84865@padl.com> References: <31096_1357297002_r04AueRc031874_8F0F68DB-721A-430F-AC2A-872E5BD5D231@padl.com> <1357326438.18192.190.camel@destiny.pc.cs.cmu.edu> <96B0C75B-D066-40DA-9B5E-283080784FEF@padl.com> <1357338862.18192.219.camel@destiny.pc.cs.cmu.edu> <0F589B78-2F2B-44DD-B09E-F6A435C83D6D@padl.com> To: "kitten@ietf.org" X-Mailer: Apple Mail (2.1499) 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: dev-identity@lists.mozilla.org, Ozten , Jeffrey Hutzelman Subject: Re: [kitten] BrowserID GSS mechanism 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, 11 Jan 2013 15:10:50 -0000 I updated the spec notes here: http://www.padl.com/~lukeh/gss-browserid.html with some notes about providing mutual authentication. This is useful = for protocols that {do,can}not use TLS. Changes from the previous version: * The acceptor now sends the initiator a backed assertion rather than a = JWT. This is for future extensibility (mutual authentication using = native JSON rather than X.509 certificates). That said, I felt that = using X.509 server certificates for now is more amenable to existing = keying infrastructures. (JSON Web Signatures provides for embedding = X.509 certificates in a JWT.) * If the initiator desired mutual authentication, it sends a nonce to = the acceptor. If the acceptor is keyed, it echoes the nonce and signs = the response using its private key rather than a session subkey (which = would have been derived from the Diffie-Hellman exchange). The server's = certificate is embedded in the response. * The initiator verifies the echoed nonce, response assertion, = certificate and certificate chain. If it succeeds, it can return = GSS_C_MUTUAL_FLAG. If the client cannot verify the response assertion certificate, then = it's a hard error; there's no easy way to fallback as the acceptor has = already returned completion. Someone more security-aware than I can indicate whether a nonce is = sufficient to bind the request and response assertions. Nico suggested = the response signature being over the entire conversation, but that = would break the JWS abstraction (the signature is over the payload = only). I know using a nonce might be a bit old-fashioned. -- Luke= From lukeh@padl.com Fri Jan 11 07:24:04 2013 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 2652B21F89FC for ; Fri, 11 Jan 2013 07:24:04 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+E3FnmUNDYc for ; Fri, 11 Jan 2013 07:24:03 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 58F6A21F8996 for ; Fri, 11 Jan 2013 07:23:57 -0800 (PST) Received: by us.padl.com with ESMTP id r0BFNjS0007904; Fri, 11 Jan 2013 10:23:48 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luke Howard In-Reply-To: Date: Sat, 12 Jan 2013 02:23:45 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <31096_1357297002_r04AueRc031874_8F0F68DB-721A-430F-AC2A-872E5BD5D231@padl.com> <1357326438.18192.190.camel@destiny.pc.cs.cmu.edu> <96B0C75B-D066-40DA-9B5E-283080784FEF@padl.com> <1357338862.18192.219.camel@destiny.pc.cs.cmu.edu> <1357844458.2263.23.camel@minbar.fac.cs.cmu.edu> To: Austin King X-Mailer: Apple Mail (2.1499) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: 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, mozilla.dev.identity@googlegroups.com, "dev-identity@lists.mozilla.org" , Jeffrey Hutzelman Subject: Re: [kitten] BrowserID GSS mechanism 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, 11 Jan 2013 15:24:04 -0000 On 11/01/2013, at 6:43 AM, Austin King wrote: > As an analogy, in a web context, BrowserID can bootstrap a session = which > can be communicated over https. Additional security can be layered in = using > nonces and other web security best practices. One thing I should add: from the GSS mechanism's perspective, we don't = know whether there is an outer channel using TLS or similar. (Channel = bindings provide a way to bind the two, but their contents are opaque.) = Moreover, many applications that support GSS do not use TLS, for example = NFS, CIFS, DCE RPC (think Outlook, Exchange). I'd like the mechanism to provide some security beyond bearer tokens = (which aren't too much better than passwords). i.e. channel binding, a = session key and possibly mutual authentication (see separate mail). Nico/Jeff are going to be able to explain this much better than I. -- Luke= From mrex@sap.com Fri Jan 11 11:28:06 2013 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 D5AAB21F8A54 for ; Fri, 11 Jan 2013 11:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.164 X-Spam-Level: X-Spam-Status: No, score=-10.164 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbeP+Tx7xw2J for ; Fri, 11 Jan 2013 11:28:05 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id C454721F8738 for ; Fri, 11 Jan 2013 11:28:04 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r0BJS0OJ016783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Jan 2013 20:28:00 +0100 (MET) In-Reply-To: <6FF7B562-4323-43F4-A60A-333F06E84865@padl.com> To: Luke Howard Date: Fri, 11 Jan 2013 20:28:00 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130111192800.605EE1A452@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "kitten@ietf.org" , Jeffrey Hutzelman , Ozten , dev-identity@lists.mozilla.org Subject: Re: [kitten] BrowserID GSS mechanism 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: Fri, 11 Jan 2013 19:28:06 -0000 On my first quick read of that page I didn't really understand the protocol architecture yet (I blame myself--too busy and lack of sleep), so just a quick comment on GSS_C_MUTUAL_FLAG The name of this flag is actually a misnomer. This flag is *ONLY* about authentication of acceptor to initiator. In the original GSS-API architecture, authentication of initiator to acceptor was implied (unconditional), and requesting MUTUAL would add acceptor to initiator authentication to the existing, unconditional initiator to acceptor authentication. In GSS-API v2 the "ANON" flag was added to "get rid" of the previously unconditional initiator to acceptor authentication. The flags to obtain the common SSL/TLS authentication scheme, server authenticates to client, client is anonymous (no client cert) would use the flags (GSS_C_ANON_FLAG|GSS_C_MUTUAL_FLAG), although this may look slightly weird at first encounter. -Martin From lukeh@padl.com Fri Jan 11 19:10:37 2013 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 EC9DE21F8633 for ; Fri, 11 Jan 2013 19:10:36 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-E8EsaAq4+o for ; Fri, 11 Jan 2013 19:10:36 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC7221F857A for ; Fri, 11 Jan 2013 19:10:36 -0800 (PST) Received: by us.padl.com with ESMTP id r0C3AQLI028486; Fri, 11 Jan 2013 22:10:29 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luke Howard In-Reply-To: <20130111192800.605EE1A452@ld9781.wdf.sap.corp> Date: Sat, 12 Jan 2013 14:10:26 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <01F8DD64-312D-418A-8438-80AC1B2D5C23@padl.com> References: <20130111192800.605EE1A452@ld9781.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1499) 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" , Jeffrey Hutzelman , Ozten , dev-identity@lists.mozilla.org Subject: Re: [kitten] BrowserID GSS mechanism 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: Sat, 12 Jan 2013 03:10:37 -0000 Hi Martin, Thanks for the comments. On 12/01/2013, at 6:28 AM, Martin Rex wrote: > On my first quick read of that page I didn't really understand > the protocol architecture yet (I blame myself--too busy and > lack of sleep), so just a quick comment on >=20 > GSS_C_MUTUAL_FLAG >=20 > The name of this flag is actually a misnomer. > This flag is *ONLY* about authentication of acceptor to initiator. Noted. > In the original GSS-API architecture, authentication of initiator > to acceptor was implied (unconditional), and requesting MUTUAL > would add acceptor to initiator authentication to the existing, > unconditional initiator to acceptor authentication. >=20 > In GSS-API v2 the "ANON" flag was added to "get rid" of the previously > unconditional initiator to acceptor authentication. >=20 > The flags to obtain the common SSL/TLS authentication scheme, > server authenticates to client, client is anonymous (no client cert) > would use the flags (GSS_C_ANON_FLAG|GSS_C_MUTUAL_FLAG), although > this may look slightly weird at first encounter. The BrowserID mechanism doesn't support this case; the initiator is = always authenticated. GSS_C_MUTUAL_FLAG is optionally supported if the acceptor (the relying = party, in BrowserID-speak) is keyed with an private key, and the = initiator (user agent) can verify its certificate. -- Luke= From leifj@sunet.se Mon Jan 14 00:40:36 2013 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 82D6621F86DC for ; Mon, 14 Jan 2013 00:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbRjCtwmYrkE for ; Mon, 14 Jan 2013 00:40:35 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 48BDE21F86BB for ; Mon, 14 Jan 2013 00:40:35 -0800 (PST) Received: from [192.36.125.240] (dhcp.pilsnet.sunet.se [192.36.125.240] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id r0E8eRCw029507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jan 2013 09:40:30 +0100 (CET) Message-ID: <50F3C47B.2070000@sunet.se> Date: Mon, 14 Jan 2013 09:40:27 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "ietf-krb-wg@anl.gov" , "kitten@ietf.org" References: <20130114083924.30224.15953.idtracker@ietfa.amsl.com> In-Reply-To: <20130114083924.30224.15953.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130114083924.30224.15953.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------080002030809050007090703" Subject: [kitten] Fwd: New Version Notification for draft-ietf-krb-wg-kdc-model-15.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: Mon, 14 Jan 2013 08:40:36 -0000 This is a multi-part message in MIME format. --------------080002030809050007090703 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit As promised - since there were no protests about the new non-RFC2119 language I've submitted -15. *Please comment* Cheers Leif -------- Original Message -------- Subject: New Version Notification for draft-ietf-krb-wg-kdc-model-15.txt Date: Mon, 14 Jan 2013 00:39:24 -0800 From: internet-drafts@ietf.org To: leifj@sunet.se A new version of I-D, draft-ietf-krb-wg-kdc-model-15.txt has been successfully submitted by Leif Johansson and posted to the IETF repository. Filename: draft-ietf-krb-wg-kdc-model Revision: 15 Title: An information model for Kerberos version 5 Creation date: 2013-01-14 WG ID: krb-wg Number of pages: 18 URL: http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kdc-model-15.txt Status: http://datatracker.ietf.org/doc/draft-ietf-krb-wg-kdc-model Htmlized: http://tools.ietf.org/html/draft-ietf-krb-wg-kdc-model-15 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-krb-wg-kdc-model-15 Abstract: This document describes an information model for Kerberos version 5 from the point of view of an administrative service. There is no standard for administrating a kerberos 5 KDC. This document describes the services exposed by an administrative interface to a KDC. The IETF Secretariat --------------080002030809050007090703 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

As promised - since there were no protests about the new non-RFC2119 language
I've submitted -15.

*Please comment*

            Cheers Leif

-------- Original Message --------
Subject: New Version Notification for draft-ietf-krb-wg-kdc-model-15.txt
Date: Mon, 14 Jan 2013 00:39:24 -0800
From: internet-drafts@ietf.org
To: leifj@sunet.se 


A new version of I-D, draft-ietf-krb-wg-kdc-model-15.txt
has been successfully submitted by Leif Johansson and posted to the
IETF repository.

Filename:	 draft-ietf-krb-wg-kdc-model
Revision:	 15
Title:		 An information model for Kerberos version 5
Creation date:	 2013-01-14
WG ID:		 krb-wg
Number of pages: 18
URL:             http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kdc-model-15.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-krb-wg-kdc-model
Htmlized:        http://tools.ietf.org/html/draft-ietf-krb-wg-kdc-model-15
Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-krb-wg-kdc-model-15

Abstract:
   This document describes an information model for Kerberos version 5
   from the point of view of an administrative service.  There is no
   standard for administrating a kerberos 5 KDC.  This document
   describes the services exposed by an administrative interface to a
   KDC.

                                                                                  


The IETF Secretariat


--------------080002030809050007090703-- From stephen.farrell@cs.tcd.ie Mon Jan 14 02:49:36 2013 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 33A4E21F8936 for ; Mon, 14 Jan 2013 02:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8MH-tFoXEsh for ; Mon, 14 Jan 2013 02:49:35 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 446D921F88F0 for ; Mon, 14 Jan 2013 02:49:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A5A15BDC7; Mon, 14 Jan 2013 10:49:11 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNuCIKQThfUx; Mon, 14 Jan 2013 10:49:08 +0000 (GMT) Received: from [IPv6:2001:770:10:203:fc59:2c8:a489:8ef3] (unknown [IPv6:2001:770:10:203:fc59:2c8:a489:8ef3]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 449CDBE32; Mon, 14 Jan 2013 10:49:08 +0000 (GMT) Message-ID: <50F3E2A4.7000707@cs.tcd.ie> Date: Mon, 14 Jan 2013 10:49:08 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Leif Johansson References: <20130114083924.30224.15953.idtracker@ietfa.amsl.com> <50F3C47B.2070000@sunet.se> In-Reply-To: <50F3C47B.2070000@sunet.se> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , "ietf-krb-wg@anl.gov" Subject: Re: [kitten] Fwd: New Version Notification for draft-ietf-krb-wg-kdc-model-15.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: Mon, 14 Jan 2013 10:49:36 -0000 Hi Leif, Thanks for updating this. On 01/14/2013 08:40 AM, Leif Johansson wrote: > > > As promised - since there were no protests about the new non-RFC2119 > language > I've submitted -15. > > *Please comment* I think the top of section 2 does need a minor tweak. It currently says: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This document uses the standard normative key words ("MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL") but does not reference [RFC2119]. The reason for this (which was discussed extensively in the kerberos WG) is as follows: Two things there: 1) the first and 2nd paragraphs contradict one another, and 2) "does not reference [RFC2119]" is itself wonderfully self-contradictory:-) I'd suggest changing to: This document uses the standard key words ("MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL") that are defined in [RFC2119] but with modifications to those definitions as described below. The reason for this (which was discussed extensively in the kerberos WG) is as follows: And a typo has snuck in as well: s/inforsmation/information/ Other than that, I think this version is fine. (I'll ask Pete if he agrees as well.) Cheers, S. > > Cheers Leif > > -------- Original Message -------- > Subject: New Version Notification for draft-ietf-krb-wg-kdc-model-15.txt > Date: Mon, 14 Jan 2013 00:39:24 -0800 > From: internet-drafts@ietf.org > To: leifj@sunet.se > > > > A new version of I-D, draft-ietf-krb-wg-kdc-model-15.txt > has been successfully submitted by Leif Johansson and posted to the > IETF repository. > > Filename: draft-ietf-krb-wg-kdc-model > Revision: 15 > Title: An information model for Kerberos version 5 > Creation date: 2013-01-14 > WG ID: krb-wg > Number of pages: 18 > URL: http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kdc-model-15.txt > Status: http://datatracker.ietf.org/doc/draft-ietf-krb-wg-kdc-model > Htmlized: http://tools.ietf.org/html/draft-ietf-krb-wg-kdc-model-15 > Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-krb-wg-kdc-model-15 > > Abstract: > This document describes an information model for Kerberos version 5 > from the point of view of an administrative service. There is no > standard for administrating a kerberos 5 KDC. This document > describes the services exposed by an administrative interface to a > KDC. > > > > > The IETF Secretariat > > > > > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From leifj@mnt.se Mon Jan 14 02:54:11 2013 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 0063C21F8703 for ; Mon, 14 Jan 2013 02:54:11 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TBLOwcmq7PX for ; Mon, 14 Jan 2013 02:54:10 -0800 (PST) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) by ietfa.amsl.com (Postfix) with ESMTP id 05B6821F8700 for ; Mon, 14 Jan 2013 02:54:09 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id fq12so3625169lab.39 for ; Mon, 14 Jan 2013 02:54:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=U8J1pIt78YPdPLo8gyKmX6kyVhiV26wWKOjchbVlMl0=; b=A93zAN+SfL5rnFP3OgaGuwmJekYs67rw80tZyXtwQD/sY/WPwDfXnbuYkZdKWVA9xQ nrMFRu5Q9Z+QLVP9/W5NKLCLdqJak7Y4BFFVQJKF5NX9YOJC6I0+a4R5AVG9Mp0YfZHv SE3Ey8YdoFpynZDQiBW9B7Q1MbK/TuLkhPhqLI3svn/phbD1jVQhL3G7WsUNvcoMLjHY v0ObPb/yTd+swoDSq5IgBqtLOjjVqwxrkMUIjeLvzvirWqvmG8TCOvZSU8KJWidkEmvg s1HogPdFUsJLGuw+pA+pjhWG4fN+t9Mpj2uSm+ogJcVGLrKkrQGy1Qd5E1sVYWQPgAcK /HiQ== X-Received: by 10.152.148.104 with SMTP id tr8mr7121233lab.55.1358160848765; Mon, 14 Jan 2013 02:54:08 -0800 (PST) Received: from ?IPv6:2001:6b0:7:0:dddf:f4c3:1c0f:9d3b? ([2001:6b0:7:0:dddf:f4c3:1c0f:9d3b]) by mx.google.com with ESMTPS id ox6sm5027991lab.16.2013.01.14.02.54.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jan 2013 02:54:07 -0800 (PST) Message-ID: <50F3E3CE.4070302@mnt.se> Date: Mon, 14 Jan 2013 11:54:06 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: kitten@ietf.org References: <20130114083924.30224.15953.idtracker@ietfa.amsl.com> <50F3C47B.2070000@sunet.se> <50F3E2A4.7000707@cs.tcd.ie> In-Reply-To: <50F3E2A4.7000707@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlpRlItrmK4bgH3fNRzHgxbHd8IPqN9Qf6FuuevP7DMc/XgM9pLikHVJs5iGZxEZPLqotoO Subject: Re: [kitten] Fwd: New Version Notification for draft-ietf-krb-wg-kdc-model-15.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: Mon, 14 Jan 2013 10:54:11 -0000 On 01/14/2013 11:49 AM, Stephen Farrell wrote: > Hi Leif, > > Thanks for updating this. > > On 01/14/2013 08:40 AM, Leif Johansson wrote: >> >> As promised - since there were no protests about the new non-RFC2119 >> language >> I've submitted -15. >> >> *Please comment* > I think the top of section 2 does need a minor tweak. It currently > says: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > This document uses the standard normative key words ("MUST", "MUST > NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", > "RECOMMENDED", "MAY", and "OPTIONAL") but does not reference > [RFC2119]. The reason for this (which was discussed extensively in > the kerberos WG) is as follows: > > Two things there: 1) the first and 2nd paragraphs contradict one > another, and 2) "does not reference [RFC2119]" is itself wonderfully > self-contradictory:-) > > I'd suggest changing to: > > This document uses the standard key words ("MUST", "MUST > NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", > "RECOMMENDED", "MAY", and "OPTIONAL") that are defined in > [RFC2119] but with modifications to those definitions as > described below. The reason for this (which was discussed > extensively in the kerberos WG) is as follows: reads fine to me > > And a typo has snuck in as well: s/inforsmation/information/ > > Other than that, I think this version is fine. (I'll ask Pete > if he agrees as well.) > > Cheers, > S. > > > >> Cheers Leif >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-ietf-krb-wg-kdc-model-15.txt >> Date: Mon, 14 Jan 2013 00:39:24 -0800 >> From: internet-drafts@ietf.org >> To: leifj@sunet.se >> >> >> >> A new version of I-D, draft-ietf-krb-wg-kdc-model-15.txt >> has been successfully submitted by Leif Johansson and posted to the >> IETF repository. >> >> Filename: draft-ietf-krb-wg-kdc-model >> Revision: 15 >> Title: An information model for Kerberos version 5 >> Creation date: 2013-01-14 >> WG ID: krb-wg >> Number of pages: 18 >> URL: http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kdc-model-15.txt >> Status: http://datatracker.ietf.org/doc/draft-ietf-krb-wg-kdc-model >> Htmlized: http://tools.ietf.org/html/draft-ietf-krb-wg-kdc-model-15 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-krb-wg-kdc-model-15 >> >> Abstract: >> This document describes an information model for Kerberos version 5 >> from the point of view of an administrative service. There is no >> standard for administrating a kerberos 5 KDC. This document >> describes the services exposed by an administrative interface to a >> KDC. >> >> >> >> >> The IETF Secretariat >> >> >> >> >> >> >> _______________________________________________ >> 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 stephen.farrell@cs.tcd.ie Mon Jan 14 07:35:32 2013 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 B81A521F8930 for ; Mon, 14 Jan 2013 07:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.66 X-Spam-Level: X-Spam-Status: No, score=-102.66 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnljZ5--nzGi for ; Mon, 14 Jan 2013 07:35:31 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id BFECE21F8925 for ; Mon, 14 Jan 2013 07:35:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 35C0FBE47; Mon, 14 Jan 2013 15:35:10 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDjmS7PKF-cN; Mon, 14 Jan 2013 15:35:04 +0000 (GMT) Received: from [IPv6:2001:770:10:203:fc59:2c8:a489:8ef3] (unknown [IPv6:2001:770:10:203:fc59:2c8:a489:8ef3]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7D3BABE3B; Mon, 14 Jan 2013 15:35:04 +0000 (GMT) Message-ID: <50F425A9.50900@cs.tcd.ie> Date: Mon, 14 Jan 2013 15:35:05 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: ietf-krb-wg@lists.anl.gov, "kitten@ietf.org" References: <20130114152410.1413.49258.idtracker@ietfa.amsl.com> In-Reply-To: <20130114152410.1413.49258.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [kitten] [Ietf-krb-wg] I-D Action: draft-ietf-krb-wg-kdc-model-16.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: Mon, 14 Jan 2013 15:35:32 -0000 Hi All, Leif pushed out a -16 that fixed the issue I mentioned earlier (thanks Leif) and Pete has now cleared his discuss. There are a few comments left in the tracker [1] that I've asked Leif to look over since a few more tweaks might be in order. Those can go into a -17 or RFC editor notes but I'd like 'em to be looked at at least. I think Jeff also wanted some indication from the WG that the new text is ok. So please take a look and I'd appreciate a couple of +1's that this text is all right. Soon's those are done I can send the approval message. Thanks, Stephen. On 01/14/2013 03:24 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Kerberos Working Group of the IETF. > > Title : An information model for Kerberos version 5 > Author(s) : Leif Johansson > Filename : draft-ietf-krb-wg-kdc-model-16.txt > Pages : 18 > Date : 2013-01-14 > > Abstract: > This document describes an information model for Kerberos version 5 > from the point of view of an administrative service. There is no > standard for administrating a kerberos 5 KDC. This document > describes the services exposed by an administrative interface to a > KDC. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-krb-wg-kdc-model > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-krb-wg-kdc-model-16 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-krb-wg-kdc-model-16 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > ietf-krb-wg mailing list > ietf-krb-wg@lists.anl.gov > https://lists.anl.gov/mailman/listinfo/ietf-krb-wg > > From stephen.farrell@cs.tcd.ie Thu Jan 17 13:19:26 2013 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 06CDB21F8859 for ; Thu, 17 Jan 2013 13:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5P4BZJQnYm1T for ; Thu, 17 Jan 2013 13:19:25 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE5521F8853 for ; Thu, 17 Jan 2013 13:19:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C3AFFBE65; Thu, 17 Jan 2013 21:19:03 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJWIl-ZAZYt4; Thu, 17 Jan 2013 21:19:00 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.41.4.4]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A078DBE64; Thu, 17 Jan 2013 21:18:59 +0000 (GMT) Message-ID: <50F86AC3.9040302@cs.tcd.ie> Date: Thu, 17 Jan 2013 21:18:59 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: ietf-krb-wg@lists.anl.gov, "kitten@ietf.org" References: <20130114152410.1413.49258.idtracker@ietfa.amsl.com> <50F425A9.50900@cs.tcd.ie> In-Reply-To: <50F425A9.50900@cs.tcd.ie> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [kitten] [Ietf-krb-wg] I-D Action: draft-ietf-krb-wg-kdc-model-16.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, 17 Jan 2013 21:19:26 -0000 Hi, I'd like to get this one out the door so I've written up the changes from the IESG comments [1] in an RFC editor note. [2] I don't believe any of these changes are substantive changes so if nobody objects then I'm going to send the approval announcement for this next Monday. Thanks, S. [1] https://datatracker.ietf.org/doc/draft-ietf-krb-wg-kdc-model/ballot/ [2] https://datatracker.ietf.org/doc/draft-ietf-krb-wg-kdc-model/writeup/ On 01/14/2013 03:35 PM, Stephen Farrell wrote: > > Hi All, > > Leif pushed out a -16 that fixed the issue I mentioned earlier > (thanks Leif) and Pete has now cleared his discuss. > > There are a few comments left in the tracker [1] that I've > asked Leif to look over since a few more tweaks might be in > order. Those can go into a -17 or RFC editor notes but I'd > like 'em to be looked at at least. > > I think Jeff also wanted some indication from the WG that the > new text is ok. So please take a look and I'd appreciate a > couple of +1's that this text is all right. > > Soon's those are done I can send the approval message. > > Thanks, > Stephen. > > On 01/14/2013 03:24 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Kerberos Working Group of the IETF. >> >> Title : An information model for Kerberos version 5 >> Author(s) : Leif Johansson >> Filename : draft-ietf-krb-wg-kdc-model-16.txt >> Pages : 18 >> Date : 2013-01-14 >> >> Abstract: >> This document describes an information model for Kerberos version 5 >> from the point of view of an administrative service. There is no >> standard for administrating a kerberos 5 KDC. This document >> describes the services exposed by an administrative interface to a >> KDC. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-krb-wg-kdc-model >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-krb-wg-kdc-model-16 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-krb-wg-kdc-model-16 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> ietf-krb-wg mailing list >> ietf-krb-wg@lists.anl.gov >> https://lists.anl.gov/mailman/listinfo/ietf-krb-wg >> >> > _______________________________________________ > ietf-krb-wg mailing list > ietf-krb-wg@lists.anl.gov > https://lists.anl.gov/mailman/listinfo/ietf-krb-wg > > From leifj@mnt.se Fri Jan 18 00:46:01 2013 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 8CB6721F8836 for ; Fri, 18 Jan 2013 00:46:01 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnWT2RGONaLy for ; Fri, 18 Jan 2013 00:46:00 -0800 (PST) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by ietfa.amsl.com (Postfix) with ESMTP id C865D21F883F for ; Fri, 18 Jan 2013 00:45:59 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id eg20so3611136lab.30 for ; Fri, 18 Jan 2013 00:45:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=JZgMxu7gDWZ3zSFuJg3jaglMF7W02Q3tdH88JlL4H4U=; b=BdBVqofeU2122GwyLCOau4WYb78e6L5nLOZzKaokhaVkKcIfhXUW4NmBXlQ3raz4XX Xvhg8YDjVF7UzoZYpHrPq7tukjRqdlWSruKjTrFnjsLLHkdNvxJsXMXhwUyCk8G/6E4X DkSXQPn6GIUugSQwPzx1YvzI77CIyZe9rDrFrj/v6B6MXKYwNsmX5G0A51pMsQGQg73U HwC45J2gpUoXzVarZTTt/VsNY/RrwD8gaFaknbqNGx9U93hYQFymv7+NQOjtJQSWo7Hi jCCZboC8SmjJKga+YJvX4h98sD4oLqF1TMvKa/wkWG6I70J10TD+tLr5wj37p5ZxzoHR +8Cg== X-Received: by 10.152.46.12 with SMTP id r12mr5570519lam.15.1358498758367; Fri, 18 Jan 2013 00:45:58 -0800 (PST) Received: from ?IPv6:2001:6b0:7:0:fc7b:a2f8:eeda:115? ([2001:6b0:7:0:fc7b:a2f8:eeda:115]) by mx.google.com with ESMTPS id ox6sm1668990lab.16.2013.01.18.00.45.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jan 2013 00:45:57 -0800 (PST) Message-ID: <50F90BC3.3040908@mnt.se> Date: Fri, 18 Jan 2013 09:45:55 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: kitten@ietf.org References: <20130114152410.1413.49258.idtracker@ietfa.amsl.com> <50F425A9.50900@cs.tcd.ie> <50F86AC3.9040302@cs.tcd.ie> In-Reply-To: <50F86AC3.9040302@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlQTcyZrLWk9fcoJudcmQOqf2P2DibRgMYqRt2LWugknmNK0axdupbhKoH2rBWmuL5E+Alq Subject: Re: [kitten] [Ietf-krb-wg] I-D Action: draft-ietf-krb-wg-kdc-model-16.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: Fri, 18 Jan 2013 08:46:01 -0000 On 01/17/2013 10:18 PM, Stephen Farrell wrote: > Hi, > > I'd like to get this one out the door so I've written > up the changes from the IESG comments [1] in an RFC > editor note. [2] > > I don't believe any of these changes are substantive > changes so if nobody objects then I'm going to send > the approval announcement for this next Monday. > > Thanks, > S. > > [1] https://datatracker.ietf.org/doc/draft-ietf-krb-wg-kdc-model/ballot/ > [2] https://datatracker.ietf.org/doc/draft-ietf-krb-wg-kdc-model/writeup/ Concur. > > On 01/14/2013 03:35 PM, Stephen Farrell wrote: >> Hi All, >> >> Leif pushed out a -16 that fixed the issue I mentioned earlier >> (thanks Leif) and Pete has now cleared his discuss. >> >> There are a few comments left in the tracker [1] that I've >> asked Leif to look over since a few more tweaks might be in >> order. Those can go into a -17 or RFC editor notes but I'd >> like 'em to be looked at at least. >> >> I think Jeff also wanted some indication from the WG that the >> new text is ok. So please take a look and I'd appreciate a >> couple of +1's that this text is all right. >> >> Soon's those are done I can send the approval message. >> >> Thanks, >> Stephen. >> >> On 01/14/2013 03:24 PM, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Kerberos Working Group of the IETF. >>> >>> Title : An information model for Kerberos version 5 >>> Author(s) : Leif Johansson >>> Filename : draft-ietf-krb-wg-kdc-model-16.txt >>> Pages : 18 >>> Date : 2013-01-14 >>> >>> Abstract: >>> This document describes an information model for Kerberos version 5 >>> from the point of view of an administrative service. There is no >>> standard for administrating a kerberos 5 KDC. This document >>> describes the services exposed by an administrative interface to a >>> KDC. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-krb-wg-kdc-model >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-krb-wg-kdc-model-16 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-krb-wg-kdc-model-16 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> ietf-krb-wg mailing list >>> ietf-krb-wg@lists.anl.gov >>> https://lists.anl.gov/mailman/listinfo/ietf-krb-wg >>> >>> >> _______________________________________________ >> ietf-krb-wg mailing list >> ietf-krb-wg@lists.anl.gov >> https://lists.anl.gov/mailman/listinfo/ietf-krb-wg >> >> > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From stephen.farrell@cs.tcd.ie Wed Jan 23 09:23:33 2013 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 BABE621F869F for ; Wed, 23 Jan 2013 09:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nitssuebNNpc for ; Wed, 23 Jan 2013 09:23:32 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DBF6621F85E2 for ; Wed, 23 Jan 2013 09:23:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 509EBBE6D; Wed, 23 Jan 2013 17:23:07 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tmd1bls0lxOa; Wed, 23 Jan 2013 17:23:02 +0000 (GMT) Received: from [IPv6:2001:770:10:203:f478:ae35:d564:74e7] (unknown [IPv6:2001:770:10:203:f478:ae35:d564:74e7]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 24834BE5F; Wed, 23 Jan 2013 17:22:36 +0000 (GMT) Message-ID: <51001C5D.3080109@cs.tcd.ie> Date: Wed, 23 Jan 2013 17:22:37 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "kitten@ietf.org" , "krb-wg mailing list (ietf-krb-wg@lists.anl.gov)" X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [kitten] re-chartering under way 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, 23 Jan 2013 17:23:33 -0000 Hi all, Just to let you know what's going on. The chairs have sent me a version of the new charter as discussed at the last meeting and on the list(s). I've entered that into the new tracker tool for charters [1] and it has started IESG and IAB review. So far we've had one comment causing a change to the wording of the i18n related text. (You can check the changes with the new tool btw at [2]). If you have any comments on this or any changes that happen, please raise those on the list or with the chairs or me. Of course if something substantive comes up, the chairs will bring that to the list(s). The process from here is that the IESG and IAB will review this before our Feb 7 telechat, at which point all going well we'll agree that it goes out for IETF wide review. (I'll ask for that only since we're merging the two WGs, the work items themselves probably wouldn't require it.) And if all goes well there then it'll be up for approval on the following IESG telechat on Feb 21. At that point, we'll formally close the Kerberos working group and the work will proceed in kitten. I'd like to ask the chairs to figure out how you'd like to handle mailing lists, e.g. I assume you'll want to keep the ietf-krb-wg@lists.anl.gov list open if the operators of that list are ok with that but I don't know if you'll want to ask to mass subscribe folks on te.g.o the kitten list or let people look after that on their own. (That is something the secretariat can help with if you do want it.) And thanks to all for dealing with all this process-stuff, I know how much fun it is;-) Cheers, S. [1] https://datatracker.ietf.org/doc/charter-ietf-kitten/ [2] https://datatracker.ietf.org/doc/charter-ietf-kitten/history/ From hartmans@mit.edu Mon Jan 28 09:45:50 2013 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 2DFC521F8967 for ; Mon, 28 Jan 2013 09:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9j9RnprKkYBp for ; Mon, 28 Jan 2013 09:45:49 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2DB21F84FB for ; Mon, 28 Jan 2013 09:45:47 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 887072003E; Mon, 28 Jan 2013 12:41:57 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 03E6543FD; Mon, 28 Jan 2013 12:45:38 -0500 (EST) From: Sam Hartman To: Stephen Farrell References: <51001C5D.3080109@cs.tcd.ie> Date: Mon, 28 Jan 2013 12:45:37 -0500 In-Reply-To: <51001C5D.3080109@cs.tcd.ie> (Stephen Farrell's message of "Wed, 23 Jan 2013 17:22:37 +0000") 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 Cc: "kitten@ietf.org" , "krb-wg mailing list \(ietf-krb-wg@lists.anl.gov\)" Subject: Re: [kitten] re-chartering under way 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, 28 Jan 2013 17:45:50 -0000 Unfortunately it looks like the ietf-krb-wg list will be going away. Doug has requested that we shut it down as he's the most Kerberos involved person at NRL these days. We'd all like to thank Doug for his years moderating the list, for his service as a Kerberos chair and for his continuing service to the Kerberos community. From lukeh@padl.com Tue Jan 29 01:03:14 2013 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 C2CD621F8855 for ; Tue, 29 Jan 2013 01:03:14 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4t+zSG77SCKY for ; Tue, 29 Jan 2013 01:03:14 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 15C7921F8842 for ; Tue, 29 Jan 2013 01:03:14 -0800 (PST) Received: by us.padl.com with ESMTP id r0T937De030058; Tue, 29 Jan 2013 04:03:10 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luke Howard Date: Tue, 29 Jan 2013 20:03:06 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: To: "dev-identity@lists.mozilla.org" X-Mailer: Apple Mail (2.1499) 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: [kitten] gss_browserid release 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, 29 Jan 2013 09:03:14 -0000 I've made the GSS BrowserID mechanism available here: https://github.com/PADL/gss_browserid The mechanism is a plug-in for the GSS-API that allows you to use = BrowserID assertions for authenticating in non-web protocols, such as = SMTP, IMAP, SSH, and LDAP. It's still fairly untested, so be gentle. It includes fast support for DH key exchange, mutual authentication, = fast re-authentication, and a general purpose native C library for = BrowserID. The client UI component works on OS X and Windows (almost) = only, although it should be relatively easy to other platforms. The = server side should work on any modern POSIX platform that supports = OpenSSL (on Windows, the native CNG library is used). It is released under the Sleepycat license. -- Luke= From internet-drafts@ietf.org Tue Jan 29 11:27:31 2013 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 0585D21F8464; Tue, 29 Jan 2013 11:27:31 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDADBFH31we2; Tue, 29 Jan 2013 11:27:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EDE21F8480; Tue, 29 Jan 2013 11:27:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130129192730.26817.22754.idtracker@ietfa.amsl.com> Date: Tue, 29 Jan 2013 11:27:30 -0800 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-06.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: Tue, 29 Jan 2013 19:27:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next Gen= eration Working Group of the IETF. Title : SAML Enhanced Client SASL and GSS-API Mechanisms Author(s) : Scott Cantor Simon Josefsson Filename : draft-ietf-kitten-sasl-saml-ec-06.txt Pages : 35 Date : 2013-01-29 Abstract: Security Assertion Markup Language (SAML) 2.0 is a generalized framework for the exchange of security-related information between asserting and relying parties. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to facilitate an extensible authentication model. This document specifies a SASL and GSS-API mechanism for SAML 2.0 that leverages the capabilities of a SAML-aware "enhanced client" to address significant barriers to federated authentication in a manner that encourages reuse of existing SAML bindings and profiles designed for non-browser scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml-ec There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-sasl-saml-ec-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-saml-ec-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hartmans@mit.edu Thu Jan 31 08:34:00 2013 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 29D2921F857E for ; Thu, 31 Jan 2013 08:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ExCh+0h1nxS for ; Thu, 31 Jan 2013 08:33:59 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 4A96F21F8574 for ; Thu, 31 Jan 2013 08:33:57 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 2A51120289; Thu, 31 Jan 2013 11:30:01 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EBDB343FD; Thu, 31 Jan 2013 11:33:54 -0500 (EST) From: Sam Hartman To: Sam Hartman References: <51001C5D.3080109@cs.tcd.ie> Date: Thu, 31 Jan 2013 11:33:54 -0500 In-Reply-To: (Sam Hartman's message of "Mon, 28 Jan 2013 12:45:37 -0500") 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 Cc: "kitten@ietf.org" , "krb-wg mailing list \(ietf-krb-wg@lists.anl.gov\)" Subject: [kitten] Merging in krb-wg list subscribers to kitten 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, 31 Jan 2013 16:34:00 -0000 Folks on the ietf-krb-wg list: we've enjoyed your company for years and would hate to lose your input simply because we're merging the working groups. The plan is that we'll ask Doug to give the IETF a list of subscribers of the krb-wg list and that they will be added to kitten. If you're already on kitten with the same address, then you will not get duplicate mail. If you need to adjust anything you can using the usual procedures. Sam Hartman Kitten co-chair