From stefan.winter@restena.lu Mon Jul 1 05:41:52 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0B311E817E for ; Mon, 1 Jul 2013 05:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.079 X-Spam-Level: X-Spam-Status: No, score=-1.079 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_47=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AP2SORkH1ocN for ; Mon, 1 Jul 2013 05:41:49 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 1D61411E859A for ; Mon, 1 Jul 2013 05:38:17 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 4ACD61057F; Mon, 1 Jul 2013 14:38:15 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 366191057D; Mon, 1 Jul 2013 14:38:15 +0200 (CEST) Message-ID: <51D17832.8000901@restena.lu> Date: Mon, 01 Jul 2013 14:38:10 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2CIJNSJHRMBBINDDIVSLQ" X-Virus-Scanned: ClamAV Cc: pkix@ietf.org Subject: Re: [pkix] Registration of a new sAN:otherName (NAIRealm) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 12:41:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2CIJNSJHRMBBINDDIVSLQ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Stefan, > I suspect you have made a misinterpretation of the service name SAN > defined in RFC 4985. >=20 > When you say: > "We cannot use SRVName > directly though, since a possible SRV record occurs in the middle of a > potentially untrusted lookup;" >=20 > Then I suspect you miss the whole pint with RFC 4985. >=20 > The whole point is the the SRV record from DNS is not, or may not be, > trusted. It's just used for lookup. That's the point: the SRV can usually be verified because it is the RR that is looked up in DNS; i.e. the label to look for is trusted. The result of the lookup can then be untrusted, because the cert property can be verified against the label that was queried for. That is not the case in my draft: the RR being looked up is a NAPTR record; it may subsequently lead to a SRV, or it may not. The unpleasant thing is: in the absence of DNSSEC, this initial NAPTR could be altered to point to a /different/ SRV than expected. An attacker may have a certificate which authorises him to serve that other SRV; it's just not where the request was supposed to end up. Example: genuine lookup -------------- Algo input: realm =3D good.example First query: Label: good.example; RR: NAPTR; response: "s" _service._sctp.good.example second query: Label: _service._sctp.good.example RR: SRV response: port 12345, server.good.example -> SRV label =3D=3D SRVName in cert -> traffic gets sent to server.good.example NAPTR altered by attacker (who has a certificate for the host server.bad.example, authorising it to serve _service._sctp.bad.example) ------------------------- Algo input: realm =3D good.example First query: Label: good.example; RR: NAPTR; response: "s" _service._sctp.bad.example second query: Label: _service._sctp.bad.example RR: SRV response: port 54321, server.bad.example -> SRV label =3D=3D SRVName in cert -> traffic gets sent to server.bad.example As you see, the altered lookup by the attacker will be undetected later: DNS states that _service._sctp.bad.example is the service to go to; and the server being contacted has a certificate authorizing it for that service's delivery. This would look like an "all green" situation - while in fact the target is not the correct server. IOW, the SRVname + DNS RR SRV protection is annuled because an earlier DNS resolution step (NAPTR) cannot be verified with any certificate property. That's why I initially wrote "in the middle of"; sorry for the tense language. Also note that NAPTR entries can be of type "a" which do not generate an intermediate SRV result at all; they immediately lead to a hostname. SRVName is of no particular use there. The attack above could be mitigated by having a certificate property listing which NAPTR entries might ultimately lead to a server, so that a CA could embed that. That would be a rather generic solution, but in fact so generic that I don't fully overlook its complexity (there are many categories of NAPTR usage) and also frankly I do not have much of an appetite for work on it. The attack can also be mitigated by the NAIRealm property I requested initially; this is a specific solution for the AAA routing problem we're looking at. That one I am keen on solving :-) > I could be missing something, but, following your draft the the example= > given below, what prevents you from providing a service name SAN in > accordance with RFC 4985 with the value: >=20 > _radiustls.myrealm.example.com >=20 >=20 > This would provide an assertion independent of DNS, that this host is > authorised to provide RADIUS/TLS for the myrealm.example.com domain. The draft specifically needs to consider that a server may be authorized to receive traffic for /some/ realms in a roaming consortium, but not others. Such an "inside attacker" would have a valid certificate from an accredited CA etc., and have SRVNames for one or more of the domains in the roaming consortium; but it may decide to manipulate NAPTR DNS entries to have another realm point via the wrong NAPTR to its own SRV entry. I hope this explains things a little better. Greetings, Stefan >=20 > /Stefan >=20 >=20 > On 6/28/13 11:22 AM, "Stefan Winter" wrote: >=20 >> Hello, >> >> over in the RADIUS Extensions working group we are working on a >> discovery mechanism for RADIUS/TLS authentication servers. The algorit= hm >> makes use of DNS, -SEC is optional; in the absence of DNSSEC an X.509 >> certificate of the discovered server needs to yield information whethe= r >> it is authoritative for a NAI realm (i.e. "the 'domain' part of a >> User-Name attribute, in the form of user@realm"). >> >> The discovery starts with a NAPTR for the service in question, and the= n >> may traverse a set of SRVs or not, to eventually end up at an A/AAAA >> record of the discovered hostname. >> >> Determination of the authoritativeness needs to be a part of the >> certificate; in a way analogous to SRVName. We cannot use SRVName >> directly though, since a possible SRV record occurs in the middle of a= >> potentially untrusted lookup; if an attacker modified the initial NAPT= R >> response, he can divert further SRV resolution steps to his own server= =2E >> >> For that reason, we think we need a new sAN:otherName registration whi= ch >> allows us to compare that realm part of a User-Name (the actual, >> known-correct input to the algorithm) to the NAIRealm property of the >> certificate of the server that came out of the discovery process. >> >> In short: >> >> 1) Input: johndoe@myrealm.example >> >> 2) discovery algorithm yields output: >> please contact A.B.C.D:2083 with RADIUS/TLS >> >> 3) TLS handshake verification: does X.509 cert contain >> sAN:otherName:NAIRealm =3D=3D myrealm.example >> >> I have a new draft rev of >> https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ = on >> my disk, which registers otherName:NAIRealm just like RFC4985 did (in >> fact, it is copy&paste :-) . >> >> I noticed that I need an integer in the "otherName" registry; RFC4985 >> uses id-on-dnsSRV =3D 7; and I wonder who to approach and where to get= my >> own integer for >> >> id-on-nai OBJECT IDENTIFIER ::=3D { id-on XXX??? } >> >> from. >> >> I appreciate any thoughts on the overall approach, and on the allocati= on >> of that new integer. >> >> Greetings, >> >> Stefan Winter >> >> --=20 >> Stefan WINTER >> Ingenieur de Recherche >> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Natio= nale et >> de la Recherche >> 6, rue Richard Coudenhove-Kalergi >> L-1359 Luxembourg >> >> Tel: +352 424409 1 >> Fax: +352 422473 >> >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >=20 >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ------enig2CIJNSJHRMBBINDDIVSLQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHReDYACgkQ+jm90f8eFWZNfACeL8W6r+jZ8DJ8wWGFQ+9lmBRQ m2IAnjygif/uqK6feKGRm8T8nIC8yw6T =YuGa -----END PGP SIGNATURE----- ------enig2CIJNSJHRMBBINDDIVSLQ-- From stefan.winter@restena.lu Mon Jul 1 07:00:28 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A417911E816F for ; Mon, 1 Jul 2013 07:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.161 X-Spam-Level: X-Spam-Status: No, score=0.161 tagged_above=-999 required=5 tests=[AWL=-1.440, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFpDunu3VN-u for ; Mon, 1 Jul 2013 07:00:25 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 022D811E8135 for ; Mon, 1 Jul 2013 07:00:24 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 1EE331057F; Mon, 1 Jul 2013 16:00:24 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 0D9D11057E; Mon, 1 Jul 2013 16:00:24 +0200 (CEST) Message-ID: <51D18B73.5070307@restena.lu> Date: Mon, 01 Jul 2013 16:00:19 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Russ Housley References: <51CD55D5.2070206@restena.lu> <740637E6-019C-4F47-B1BB-9180D3A69612@vigilsec.com> In-Reply-To: <740637E6-019C-4F47-B1BB-9180D3A69612@vigilsec.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2NRSTIILIHXPVDBOLAUPH" X-Virus-Scanned: ClamAV Cc: pkix@ietf.org Subject: Re: [pkix] Registration of a new sAN:otherName (NAIRealm) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 14:00:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2NRSTIILIHXPVDBOLAUPH Content-Type: multipart/mixed; boundary="------------060204070505030609040304" This is a multi-part message in MIME format. --------------060204070505030609040304 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > I suggest that you write a one or two page I-D that specifies the propo= sed alt name, and then bring it to this mail list for review. Please find attached a pre-print copy of draft-ietf-radext-dynamic-discovery-07; I'm still working on it and this is not offcially submitted. Still, it contains the relevant items for the PKIX discussion. Please take a look at: 2.1.1.3. Server Identification and Handshake 2.1.1.3.1. Mandatory-to-implement mechanism: Trust Roots + NAIRealm For the usage of the new otherName. 2.2. Definition of the X.509 certificate property SubjectAltName:otherName:NAIRealm Contains explanations why sRVName and dNSName are not good fits, plus the placeholder OID registration. Appendix A. Appendix A: ASN.1 Syntax of NAIRealm contains the 1993 ASN.1 definition of the new object. (I omitted 1988, hoping that it is obsolete?!) Greetings, Stefan Winter >=20 > Russ >=20 >=20 >=20 > On Jun 28, 2013, at 5:22 AM, Stefan Winter wrote: >=20 >> Hello, >=20 >> over in the RADIUS Extensions working group we are working on a >> discovery mechanism for RADIUS/TLS authentication servers. The algorit= hm >> makes use of DNS, -SEC is optional; in the absence of DNSSEC an X.509 >> certificate of the discovered server needs to yield information whethe= r >> it is authoritative for a NAI realm (i.e. "the 'domain' part of a >> User-Name attribute, in the form of user@realm"). >=20 >> The discovery starts with a NAPTR for the service in question, and the= n >> may traverse a set of SRVs or not, to eventually end up at an A/AAAA >> record of the discovered hostname. >=20 >> Determination of the authoritativeness needs to be a part of the >> certificate; in a way analogous to SRVName. We cannot use SRVName >> directly though, since a possible SRV record occurs in the middle of a= >> potentially untrusted lookup; if an attacker modified the initial NAPT= R >> response, he can divert further SRV resolution steps to his own server= =2E >=20 >> For that reason, we think we need a new sAN:otherName registration whi= ch >> allows us to compare that realm part of a User-Name (the actual, >> known-correct input to the algorithm) to the NAIRealm property of the >> certificate of the server that came out of the discovery process. >=20 >> In short: >=20 >> 1) Input: johndoe@myrealm.example >=20 >> 2) discovery algorithm yields output: >> please contact A.B.C.D:2083 with RADIUS/TLS >=20 >> 3) TLS handshake verification: does X.509 cert contain >> sAN:otherName:NAIRealm =3D=3D myrealm.example >=20 >> I have a new draft rev of >> https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ = on >> my disk, which registers otherName:NAIRealm just like RFC4985 did (in >> fact, it is copy&paste :-) . >=20 >> I noticed that I need an integer in the "otherName" registry; RFC4985 >> uses id-on-dnsSRV =3D 7; and I wonder who to approach and where to get= my >> own integer for >=20 >> id-on-nai OBJECT IDENTIFIER ::=3D { id-on XXX??? } >=20 >> from. >=20 >> I appreciate any thoughts on the overall approach, and on the allocati= on >> of that new integer. >=20 >> Greetings, >=20 >> Stefan Winter >=20 >> -- >> Stefan WINTER >> Ingenieur de Recherche >> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Natio= nale et >> de la Recherche >> 6, rue Richard Coudenhove-Kalergi >> L-1359 Luxembourg >=20 >> Tel: +352 424409 1 >> Fax: +352 422473 >=20 >=20 >=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >=20 >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------060204070505030609040304 Content-Type: text/plain; charset=UTF-8; name="draft-ietf-radext-dynamic-discovery-07.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-radext-dynamic-discovery-07.txt" RADIUS Extensions Working Group S. Winter Internet-Draft RESTENA Intended status: Experimental M. McCauley Expires: August 29, 2013 OSC February 25, 2013 NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS draft-ietf-radext-dynamic-discovery-06 Abstract This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS/TLS and RADIUS/DTLS. 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 August 29, 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. Winter & McCauley Expires August 29, 2013 [Page 1] =0C Internet-Draft RADIUS Peer Discovery February 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. DNS RR definition . . . . . . . . . . . . . . . . . . . . 3 2.1.1. NAPTR . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.3. Remarks . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Definition of the X.509 certificate property SubjectAltName:otherName:NAIRealm . . . . . . . . . . . . 8 3. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 10 3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Realm to RADIUS server resolution algorithm . . . . . . . 10 3.2.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2. Output . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.3. Definition of DNS Error . . . . . . . . . . . . . . . 11 3.2.4. Algorithm . . . . . . . . . . . . . . . . . . . . . . 11 3.2.5. Validity of results . . . . . . . . . . . . . . . . . 13 3.2.6. Delay considerations . . . . . . . . . . . . . . . . 14 3.2.7. Example . . . . . . . . . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. Normative References . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Appendix A: ASN.1 Syntax of NAIRealm . . . . . . . . 18 1. Introduction RADIUS in all its current transport variants (RADIUS/UDP, RADIUS/TLS, RADIUS/DTLS) requires manual configuration of all peers (clients, servers). Where RADIUS forwarding servers are in use, the number of realms to be forwarded and the corresponding number of servers to configure may be significant. Where new realms with new servers are added or details of existing servers change on a regular basis, maintaining a single monolithic configuration file for all these details may prove too cumbersome to be useful. Furthermore, in cases where a roaming consortium consists of independently working branches, each with their own forwarding servers, and who add or change their realm lists at their own discretion, there is additional complexity in synchronising the changed data across all branches. These situations can benefit significantly from a distributed mechanism for storing realm and server reachability information. Winter & McCauley Expires August 29, 2013 [Page 2] =0C Internet-Draft RADIUS Peer Discovery February 2013 This document describes one such mechanism: storage of realm-to- server mappings in DNS. This document does not specify how to verify that server information which was retrieved from DNS was from an authorised party; e.g. an organisation which is not at all part of a given roaming consortium may alter its own DNS records to yield a result for its own realm. RADIUS/TLS and RADIUS/DTLS have their own ways how to verify that a contacted peer is authorised (e.g. by presenting PKIX certificates from a agreed-upon CA). 1.1. Requirements Language In this document, several words are used to signify the requirements of the specification. 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 RFC 2119. [RFC2119] 1.2. Terminology RADIUS/TLS Client: a RADIUS/TLS [RFC6614] instance which initiates a new connection. RADIUS/TLS Server: a RADIUS/TLS [RFC6614] instance which listens on a RADIUS/TLS port and accepts new connections RADIUS/TLS node: a RADIUS/TLS client or server 2. Definitions 2.1. DNS RR definition DNS definitions of RADIUS/TLS servers can be either S-NAPTR records (see [RFC3958]) or SRV records. When both are defined, the resolution algorithm prefers S-NAPTR results (see Section 3.2 below). 2.1.1. NAPTR 2.1.1.1. Registration of Application Service and Protocol Tags This specification defines three S-NAPTR service tags: +-----------------+-----------------------------------------+ | Service Tag | Use | +-----------------+-----------------------------------------+ | aaa+auth | RADIUS Authentication, i.e. traffic as | Winter & McCauley Expires August 29, 2013 [Page 3] =0C Internet-Draft RADIUS Peer Discovery February 2013 | | defined in [RFC2865] | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | | aaa+acct | RADIUS Accounting, i.e. traffic as | | | defined in [RFC2866] | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | | aaa+dynauth | RADIUS Dynamic Authorisation, i.e. | | | traffic as defined in [RFC5176] | +--------------- --+-----------------------------------------+ Figure 1: List of Service Tags This specification defines two S-NAPTR protocol tags: +-----------------+-----------------------------------------+ | Protocol Tag | Use | +-----------------+-----------------------------------------+ | radius.tls | RADIUS transported over TLS as defined | | | in [RFC6614] | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | | radius.dtls | RADIUS transported over DTLS as defined | | | in [I-D.ietf-radext-dtls] | +-----------------+-----------------------------------------+ Figure 2: List of Protocol Tags Note well: The S-NAPTR service and protocols are unrelated to the IANA Service Name and Transport Protocol Number registry The delimiter '.' in the protocol tags is only a separator for human reading convenience - not for structure or namespacing; it MUST NOT be parsed in any way by the querying application or resolver. The use of the separator '.' is common also in other protocols' protocol tags. This is coincidence and does not imply a shared semantics with such protocols. 2.1.1.2. Definition of Conditions for Retry/Failure RADIUS is a time-critical protocol; RADIUS clients which do not receive an answer after a configurable, but short, amount of time, will consider the request failed. Due to this, there is little leeway for extensive retries. Winter & McCauley Expires August 29, 2013 [Page 4] =0C Internet-Draft RADIUS Peer Discovery February 2013 As a general rule, only error conditions which generate an immediate response from the other end are eligible for a retry of a discovered target. Any error condition involving time-outs, or the absence of a reply for more than one second during the connection setup phase is to be considered a failure; the next target in the set of discovered NAPTR targets is to be tried. As an exception: note that [RFC3958] already defines that a failure to identify the server as being authoritative for the realm is always considered a failure; so even if a discovered target returns a wrong credential instantly, it is not eligible for retry. 2.1.1.3. Server Identification and Handshake After the algorithm in this document has been executed, a RADIUS/TLS session as per [RFC6614] is established. Since the algorithm does not allow to derive confidential keying material between the RADIUS/ TLS client (i.e. the server which executes the discovery algorithm) and the RADIUS/TLS server which was discovered, TLS-PSK ciphersuites can not be used for the subsequent TLS handshake in the RADIUS/TLS conversation. Only TLS ciphersuites which employ X.509 certificates can be used with this algorithm. There are numerous ways to define which certificates are acceptable for use in this context. This document defines one mandatory-to- implement mechanism which allows to verify whether the contacted host is authoritative for a NAI realm or not. It also gives one example of another mechanism which is currently in wide-spread deployment. 2.1.1.3.1. Mandatory-to-implement mechanism: Trust Roots + NAIRealm Verification of authority to provide AAA services over RADIUS/TLS is a two-step process. Step 1 is the verification of certificate wellformedness and validity as per [RFC5280] and whether it was issued from a root certificate which is deemed trustworthy by the RADIUS/TLS client. Step 2 is: compare the value of algorithm's variable "R" after the execution of step 4 of the discovery algorithm in Section 3.2.4 below (i.e. after a consortium name mangling and conversion to a form usable by the name resolution library) to all values of the contacted RADIUS/TLS server's X.509 certificate property "subjectAlternativeName:otherName:NAIRealm" as defined in Section 2.2. The comparison is a byte-by-byte comparison, except for dot-separated parts of the value whose content is a single "*" character; such labels match all strings in the same part of the NAI realm. If at least one of the sAN:otherName:NAIRealm values matches Winter & McCauley Expires August 29, 2013 [Page 5] =0C Internet-Draft RADIUS Peer Discovery February 2013 the NAI realm, the server is considered authorized; if none matches, the server is considered unauthorized. Examples: +-----------------+---------------------------------------------+ | NAI realm | sAN:otherName:NAIRealm | MATCH? | +-----------------+---------------------------------------------+ | foo.example | foo.example | YES | | foo.example | *.example | YES | | bar.foo.example | *.example | NO | | bar.foo.example | bar.*.example | YES | | bar.foo.example | *.*.example | YES | | sub.bar.foo.example | *.*.example | NO | | sub.bar.foo.example | sub.bar.foo.example | YES | +-----------------+---------------------------------------------+ Figure 3: Examples for NAI realm vs. certificate matching 2.1.1.3.2. Other mechanism: Trust Roots + policyOID Verification of authority to provide AAA services over RADIUS/TLS is a two-step process. Step 1 is the verification of certificate wellformedness and validity as per [RFC5280] and whether it was issued from a root certificate which is deemed trustworthy by the RADIUS/TLS client. Step 2 is: compare the values of the contacted RADIUS/TLS server's X.509 certificate's extensions of type "Policy OID" to a list of configured acceptable Policy OIDs for the roaming consortium. If one of the configured OIDs is found in the certificate's Policy OID extensions, then the server is considered authorized; if there is no match, the server is considered unauthorized. This mechanism is inferior to the mandatory-to-implement mechanism in the previous section because all authorized servers are validated by the same OID value; the mechanism is not fine-grained enough to express authority for one specific realm inside the consortium. If the consortium contains members which are hostile against other members, this weakness can be exploited by one RADIUS/TLS server impersonating another if DNS responses can be spoofed by the hostile member. 2.1.2. SRV Winter & McCauley Expires August 29, 2013 [Page 6] =0C Internet-Draft RADIUS Peer Discovery February 2013 This specification defines two SRV prefixes (i.e. two values for the "_service._proto" part of an SRV RR as per [RFC2782]): +-----------------+-----------------------------------------+ | SRV Label | Use | +-----------------+-----------------------------------------+ | _radiustls._tcp | RADIUS transported over TLS as defined | | | in [RFC6614] | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | | _radiustls._udp | RADIUS transported over DTLS as defined | | | in [I-D.ietf-radext-dtls] | +-----------------+-----------------------------------------+ Figure 4: List of SRV Labels Just like NAPTR records, the lookup and subsequent follow-up of SRV records may yield more than one server to contact in a prioritised list. [RFC2782] does not specify rules regarding "Definition of Conditions for Retry/Failure", nor "Server Identification and Handshake". This specification defines that the rules for these two topics as defined in Section 2.1.1.2 and Section 2.1.1.3 SHALL be used both for targets retrieved via an initial NAPTR RR as well as for targets retrieved via an initial SRV RR (i.e. in the absence of a NAPTR RRs). 2.1.3. Remarks It is expected that in most cases, the SRV and/or NAPTR label used for the records is the DNS A-label representation of the literal realm name for which the server is the authoritative RADIUS server (i.e. the realm name after conversion according to section 5 of [RFC5891]). However, arbitrary other SRV and/or NAPTR labels may be used if, for example, a roaming consortium uses realm names which are not associated to DNS names or special-purpose consortia where a globally valid discovery is not a use case. Such other labels require a consortium-wide agreement about the transformation from realm name to lookup label. Examples: a. A general-purpose RADIUS server for realm example.com might have DNS entries as follows: example.com. IN NAPTR 50 50 "s" "aaa+auth:radius.tls" "" _radiustls._tcp.foobar.example.com. Winter & McCauley Expires August 29, 2013 [Page 7] =0C Internet-Draft RADIUS Peer Discovery February 2013 _radiustls._tcp.foobar.example.com. IN SRV 0 10 2083 radsec.example.com. b. The consortium "foo" provides roaming services for its members only. The realms used are of the form enterprise-name.example. The consortium operates a special purpose DNS server for the (private) TLD "example" which all RADIUS servers use to resolve realm names. "Bad, Inc." is part of the consortium. On the consortium's DNS server, realm bad.example might have the following DNS entries: bad.example IN NAPTR 50 50 "a" "aaa+auth:radius.dtls" "" very.bad.example c. The eduroam consortium uses realms based on DNS, but provides its services to a closed community only. However, a AAA domain participating in eduroam may also want to expose AAA services to other, general-purpose, applications (on the same or other RADIUS servers). Due to that, the eduroam consortium uses the service tag "x-eduroam" for authentication purposes and eduroam RADIUS servers use this tag to look up other eduroam servers. An eduroam participant example.org which also provides general- purpose AAA on a different server uses the general "aaa+auth" tag: example.org. IN NAPTR 50 50 "s" "x-eduroam:radius.tls" "" _radiustls._tcp.eduroam.example.org. example.org. IN NAPTR 50 50 "s" "aaa+auth:radius.tls" "" _radiustls._tcp.aaa.example.org _radiustls._tcp.eduroam.example.org. IN SRV 0 10 2083 aaa- eduroam.example.org. _radiustls._tcp.aaa.example.org. IN SRV 0 10 2083 aaa- default.example.org. 2.2. Definition of the X.509 certificate property SubjectAltName:otherName:NAIRealm This specification retrieves IP addresses and port numbers from the Domain Name System which are subsequently used to authenticate users via the RADIUS/TLS protocol. Since the Domain Name System is not necessarily trustworthy (e.g. if DNSSEC is not deployed for the queried domain name), it is important to verify that the server which was contacted is authorized to service requests for the user which triggered the discovery process. Winter & McCauley Expires August 29, 2013 [Page 8] =0C Internet-Draft RADIUS Peer Discovery February 2013 The input to the algorithm is a NAI realm as specified in Section 3.2.1. As a consequence, the X.509 certificate of the server which is ultimately contacted for user authentication needs to be able to express that it is authorized to handle requests for that realm. Current subjectAltName fields do not semantically allow to express an NAI realm; the field subjectAltName:dNSName is syntactically a good match but would inappropriately conflate DNS names and NAI realm names. Thus, this specification defines a new subjectAltName field to hold either a single NAI realm name or a wildcard name matching a set of NAI realms. The subjectAltName:otherName:sRVName field certifies that a certificate holder is authorized to provide a service; this can be compared to the target of DNS label's SRV resource record. If the Domain Name System is insecure, it is required that the label of the SRV record itself is known-correct. In this specification, that label is not known-correct; it is derived from a NAPTR resource record of another label. If DNS is not secured with DNSSEC, the NAPTR resource record may have been altered by an attacker with access to the Domain Name System resolution, and thus the label to lookup the SRV record for may already be tainted. This makes subjectAltName:otherName:sRVName not a trusted comparison item. Further to this, this specification may use "a" type NAPTR entries which do not involve resolution of any SRV records, which again makes subjectAltName:otherName:sRVName unsuited for this purpose. This section defines the NAIRealm name as a form of otherName from the GeneralName structure in SubjectAltName defined in [RFC5280]. id-on-nai OBJECT IDENTIFIER ::=3D { id-on XXX } NAIRealm ::=3D IA5String (SIZE (1..MAX)) The NAIRealm, if present, MUST contain an NAI realm as defined in TODO: the new NAI document. It MAY substitute labels on all dot- separated parts of the NAI with the single character "*" to indicate a wildcard match for "all labels in this part". Further features of regular expressions, such as a number of characters followed by a * to indicate a common prefix inside the part, are not permitted. This subjectAltName MAY occur more than once in a certificate. Appendix A contains the ASN.1 definition of the above objects. Winter & McCauley Expires August 29, 2013 [Page 9] =0C Internet-Draft RADIUS Peer Discovery February 2013 3. DNS-based NAPTR/SRV Peer Discovery 3.1. Applicability Dynamic server discovery as defined in this document is only applicable for AAA transactions where a RADIUS entity which acts as a forwarding server for one or more realms receives a request with a realm for which it is not authoritative, and which no explicit next hop is configured. Furthermore, it is only applicable for new user sessions, i.e. for the initial Access-Request. Subsequent messages concerning this session, for example Access-Challenges and Access- Accepts use the previously-established communication channel between client and server. 3.2. Realm to RADIUS server resolution algorithm This algorithm can be used to discover RADIUS servers (for RADIUS Authentication and RADIUS Accounting) or to discover RADIUS DynAuth servers. 3.2.1. Input For RADIUS Authentication and RADIUS Accounting server discovery, input I to the algorithm is the RADIUS User-Name attribute with content of the form "user@realm"; the literal @ sign being the separator between a local user identifier within a realm and its realm. The use of multiple literal @ signs in a User-Name is strongly discouraged; but if present, the last @ sign is to be considered the separator. All previous instances of the @ sign are to be considered part of the local user identifier. For RADIUS DynAuth Server discovery, input I to the algorithm is the domain name of the operator of a RADIUS realm as was communicated during user authentication using the Operator-Name attribute ([RFC5580], section 4.1). Only Operator-Name values with the namespace "1" are supported by this algorithm - the input to the algorithm is the actual domain name, preceeded with an "@" (but without the "1" namespace identifier byte of that attribute). Note well: The attribute User-Name is defined to contain UTF-8 text. In practice, the content may or may not be UTF-8. Even if UTF-8, it may or may not map to a domain name in the realm part. Implementors MUST take possible conversion error paths into consideration when parsing incoming User-Name attributes. This document describes server discovery only for well-formed realms mapping to DNS domain names in UTF-8 encoding. The result of all other possible contents of User-Name is unspecified; this includes, but is not limited to: Winter & McCauley Expires August 29, 2013 [Page 10] =0C Internet-Draft RADIUS Peer Discovery February 2013 Usage of separators other than @ Encoding of User-Name in local encodings UTF-8 realms which fail the conversion rules as per [RFC5891] UTF-8 realms which end with a . ("dot") character. For the last bullet point, "trailing dot", special precautions should be taken to avoid problems when resolving servers with the algorithm below: they may resolve to a RADIUS server even if the peer RADIUS server only is configured to handle the realm without the trailing dot. If that RADIUS server again uses NAI discovery to determine the authoritative server, the server will forward the request to localhost, resulting in a tight endless loop. 3.2.2. Output Output O of the algorithm is a set of tuples {hostname; port; order/ preference; TTL} - the set can be empty. 3.2.3. Definition of DNS Error Where the algorithm states "name resolution returns with an error", this shall mean that either the DNS request timed out, or every response except a) the RR queried for and b) the positive acknowledgement that the record queried for does not exist (i.e. status: NXDOMAIN). 3.2.4. Algorithm The algorithm to determine the RADIUS server to contact is as follows: 1. Determine P =3D (position of last "@" character) in I. 2. generate R =3D (substring from P+1 to end of I) 3. modify R according to agreed consortium procedures if applicable 4. convert R to a representation usable by the name resolution library if needed 5. Using the host's name resolution library, perform a NAPTR query for R (see "Delay considerations" below). If no result, continue at step 12. If name resolution returns with error, O =3D= { empty set } and terminate. Winter & McCauley Expires August 29, 2013 [Page 11] =0C Internet-Draft RADIUS Peer Discovery February 2013 6. Extract NAPTR records with service tag "aaa+auth", "aaa+acct", "aaa+dynauth" as appropriate. Keep note of the remaining TTL of each of the discovered NAPTR records. 7. If no records found, continue at step 12. 8. Evaluate NAPTR result(s) for desired protocol tag, perform subsequent lookup steps until lookup yields one or more hostnames. 9. If these name resolutions return an error for any of the subsequent lookups (e.g. an SRV target which does not exist), or for other reasons does not yield a complete set of hostnames, O =3D { empty set } and terminate. 10. O' =3D (set of {hostname; port; order/preference; min{all TTLs that led to this result} } for all lookup results). Keep note of the remaining TTL of each of the discovered records (e.g. SRV and AAAA). 11. Proceed with step 17. 12. Generate R' =3D (prefix R with "_radiustls._tcp." or "_radiustls._udp.") 13. Using the host's name resolution library, perform SRV lookup with R' as label (see "Delay considerations" below). Keep note of the TTL of each of the discovered SRV records. 14. If name resolution returns with error, O =3D { empty set } and terminate. 15. If no result, O =3D { empty set } and terminate. 16. O' =3D (set of {hostname; port; order/preference; min{all TTLs that led to this result} } for all hostnames). 17. Generate O by resoving hostnames to corresponding A and/or AAAA addresses: O =3D (set of {IP address; port; order/preference; min{all TTLs that led to this result}} for all hostnames ). 18. For each element in O, test if the original request which triggered dynamic discovery was received on {IP address; port}. If yes, O =3D { empty set }, log error, Terminate (see next section for a rationale). If no, O is the result of dynamic discovery. Terminate. Winter & McCauley Expires August 29, 2013 [Page 12] =0C Internet-Draft RADIUS Peer Discovery February 2013 3.2.5. Validity of results The dynamic discovery algorithm is used by servers which do not have sufficient configuration information to process an incoming request on their own. If the discovery algorithm yields the server's own listening address (IP address and port), then this will either lead to a tight loop (if that DNS entry has topmost priority, the server would forward the request to itself, triggering dynamic discovery again in a perpetual loop), or lead to a potential loop with intermediate hops in between (the server could forward to another host with a higher priority, which might use DNS itself and forward the packet back to the first server). The underlying reason that enables these loops is that the server executing the discovery algorithm is seriously misconfigured in that it does not recognise the request as one that is to be processed by itself. RADIUS has no built-in loop detection, so any such loops would remain undetected. So, if step 17 of the algorithm discovers such a possible-loop situation, the algorithm should be aborted and an error logged. After executing the above algorithm, the RADIUS server establishes a connection to a home server from the result set. This connection can potentially remain open for an indefinite amount of time. This conflicts with the possibility of changing device and network configurations on the receiving end. Typically, TTL values for records in the name resolution system are used to indicate how long it is safe to rely on the results of the name resolution. When a connection is open and the smallest of the TTL values which were used for discovering the server has not expired, subsequent new user sessions for the realm which corresponds to that open connection SHOULD re-use the existing connection and SHOULD NOT re-execute the dynamic discovery algorithm nor open a new connection. To allow for a change of configuration, a RADIUS server SHOULD re-execute the dynamic discovery algorithm after the lowest of the TTL values that are associated with this connection have expired. The server MAY keep the session open during this re-assessment to avoid closure and immediate re-opening of the connection should the result not have changed. Should the algorithm above terminate with an empty set (but no error), the RADIUS server SHOULD NOT attempt another execution of this algorithm for the same target realm before the negative TTL has expired. Should the algorithm above terminate due to an error with no TTL value known (e.g. DNS SERVFAIL), the RADIUS server SHOULD NOT attempt another execution of this algorithm for the same target realm before a configurable timeout interval has passed. Winter & McCauley Expires August 29, 2013 [Page 13] =0C Internet-Draft RADIUS Peer Discovery February 2013 3.2.6. Delay considerations The host's name resolution library may need to contact outside entities to perform the name resolution (e.g. authoritative name servers for a domain), and since the NAI discovery algorithm is based on uncontrollable user input, the destination of the lookups is out of control of the server that performs NAI discovery. If such outside entities are misconfigured or unreachable, the algorithm above may need an unacceptably long time to terminate. Many RADIUS implementations time out after five seconds of delay between Request and Response. It is not useful to wait until the host name resolution library signals a time-out of its name resolution algorithms; instead, implementations of NAI discovery SHOULD terminate the algorithm after the fixed upper bound of time of three seconds. If no final output of the algorithm is available after this timeout, the RADIUS server MUST assume the empty set as a result and treat the pending request according to its static configuration (e.g., fallback to a default route to a home server). Execution of the NAI discovery algorithm SHOULD be non-blocking (i.e. allow other requests to be processed in parallel to the execution of the algorithm). 3.2.7. Example Example: Assume a user from the Technical University of Munich, Germany, has a RADIUS User-Name of "foobar@tu-m[U+00FC]nchen.example". The name resolution library on the RADIUS forwarding server does not have the realm tu-m[U+00FC]nchen.example in its forwarding configuration, but uses DNS for name resolution and has configured the use of Dynamic Discovery to discover RADIUS servers. It is IPv6-enabled and prefers AAAA records over A records. It is listening for incoming RADIUS/TLS requests on 192.37.5.1, TCP/2083. If DNS contains the following records: xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" "aaa+auth:radius.tls" "" _radiustls._tcp.xn--tu-mnchen- t9a.example. xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" "fooservice:bar.dccp" "" _abc._def.xn--tu-mnchen-t9a.example. Winter & McCauley Expires August 29, 2013 [Page 14] =0C Internet-Draft RADIUS Peer Discovery February 2013 _radiustls._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 10 2083 radsec.xn--tu-mnchen-t9a.example. _radiustls._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 20 2083 backup.xn--tu-mnchen-t9a.example. radsec.xn--tu-mnchen-t9a.example. IN AAAA 2001:0DB8::202:44ff:fe0a:f704 radsec.xn--tu-mnchen-t9a.example. IN A 192.0.2.3 backup.xn--tu-mnchen-t9a.example. IN A 192.0.2.7 Then the algorithm executes as follows, with I =3D "foobar@tu-m[U+00FC]nchen.example", and no consortium name mangling in use: 1. P =3D 7 2. R =3D "tu-m[U+00FC]nchen.example" 3. NOOP 4. [name resolution library converts R to xn--tu-mnchen- t9a.example] Query result: ( 50 50 "s" "aaa+auth:radius.tls" "" _radiustls._tcp.xn--tu-mnchen-t9a.example. ; 50 50 "s" "fooservice:bar.dccp" "" _abc._def.xn--tu-mnchen-t9a.example. ) 5. Result: 50 50 "s" "aaa+auth:radius.tls" "" _radiustls._tcp.xn --tu-mnchen-t9a.example. 6. NOOP 7. O' =3D {(radsec.xn--tu-mnchen-t9a.example.; 2083; 10; TTL A),(backup.xn--tu-mnchen-t9a. example.;2083; 20; TTL B)} 8. Go to step 15. 9. (not executed) 10. (not executed) 11. (not executed) 12. (not executed) 13. (not executed) Winter & McCauley Expires August 29, 2013 [Page 15] =0C Internet-Draft RADIUS Peer Discovery February 2013 14. O =3D {(2001:0DB8::202:44ff:fe0a:f704; 2083; 10; TTL A),(192.0.2.7; 2083; 20; TTL B)} 15. O =3D {(2001:0DB8::202:44ff:fe0a:f704; 2083; 10; TTL A),(192.0.2.7; 2083; 20; TTL B)}. Terminate. The implementation will then attempt to connect to two servers, with preference to radsec.xn--tu-mnchen-t9a.example.:2083, using either the AAAA or A addresses depending on the host configuration and its IP stack's capabilities. 4. Security Considerations The results from the execution of this algorithm are only trustworthy if each of the lookup steps by the name resolution library were cryptographically secured; i.e. if DNSSEC validation was turned on during the resolution AND all of the records were in a DNSSEC signed zone AND validation of all those records was successful. When using DNS without DNSSEC security extensions for at least one of the replies to NAPTR, SRV and A/AAAA requests as described in section Section 3, the resulting set O can not be trusted. RADIUS transports have an out-of-DNS-band means to verify that the discovery attempt led to the intended target: certificate verification using a PKI. If the result set from DNS discovery is not trusted, deployments need to take sufficient care to verify during the TLS session establishment that they communicate with a peer they expect and deem authorised for RADIUS datagram exchange in their roaming environment. The use of DNSSEC allows to verify TLS keys inside the DNS using DANE. It is in principle possible to use DANE and TLSA records to verify the authenticity, and possibly the authorisation of, a discovered RADIUS server by the RADIUS client which executed the algorithm. However, RADIUS/TLS and RADIUS/DTLS require mutual authentication; i.e. the RADIUS client's authenticity and authorisation are also verified by the RADIUS server as the client establishes the TLS connection. The DANE specification does not currently include a mechanism regarding the validation of a TLS credential of a client as it connects to a server (there is not per se a DNS label for which to do TLSA lookups). This makes DANE in its current state unsuitable for TLS connections discovered with the algorithm in this specification. If client authentication gets covered by future DANE extensions, this situation may change. The algorithm has a fixed completion time-out of three seconds. Implementations might be tempted to continue their attempt to resolve DNS records even after the timeout has passed; a subsequent request for the same realm might benefit from retrieving the results anyway. Winter & McCauley Expires August 29, 2013 [Page 16] =0C Internet-Draft RADIUS Peer Discovery February 2013 Doing so exposes the server to a Denial-of-Service risk: an attacker might intentionally craft bogus DNS zones which take a very long time to reply (e.g. due to a particularly byzantine tree structure, or artificial delays in responses). If an attacker generates enough Access-Requests for a number of such zones, it may deplete server sockets or other server resources. 5. IANA Considerations This document requests IANA registration of the following entries in existing registries: o S-NAPTR Application Service Tags registry * aaa+auth * aaa+acct * aaa+dynauth o S-NAPTR Application Protocol Tags registry * radius.tls * radius.dtls This document reserves the use of the "_radiustls" and "_radiusdtls" Service labels. This document requests the creation of a new IANA registry named "RADIUS/TLS SRV Protocol Registry" with the following initial entries: o _tcp o _udp 6. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. Winter & McCauley Expires August 29, 2013 [Page 17] =0C Internet-Draft RADIUS Peer Discovery February 2013 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005. [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. Aboba, "Carrying Location Objects in RADIUS and Diameter", RFC 5580, August 2009. [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010. [I-D.ietf-radext-dtls] DeKok, A., "DTLS as a Transport Layer for RADIUS", draft- ietf-radext-dtls-02 (work in progress), July 2012. [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, May 2012. Appendix A. Appendix A: ASN.1 Syntax of NAIRealm PKIXServiceNameSAN93 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-dns-srv-name-93(40) } DEFINITIONS EXPLICIT TAGS ::=3D BEGIN -- EXPORTS ALL -- Winter & McCauley Expires August 29, 2013 [Page 18] =0C Internet-Draft RADIUS Peer Discovery February 2013 IMPORTS id-pkix FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } ; -- from RFC 3280 [N2] -- In the GeneralName definition using the 1993 ASN.1 syntax -- includes: OTHER-NAME ::=3D TYPE-IDENTIFIER -- Service Name Object Identifier id-on OBJECT IDENTIFIER ::=3D { id-pkix 8 } id-on-nai OBJECT IDENTIFIER ::=3D { id-on XXX } -- Service Name naiRealm OTHER-NAME ::=3D { NAIRealm IDENTIFIED BY { id-on-nai }} NAIRealm ::=3D IA5String (SIZE (1..MAX)) END Authors' Addresses Stefan Winter Fondation RESTENA 6, rue Richard Coudenhove-Kalergi Luxembourg 1359 LUXEMBOURG Phone: +352 424409 1 Fax: +352 422473 EMail: stefan.winter@restena.lu URI: http://www.restena.lu. Winter & McCauley Expires August 29, 2013 [Page 19] =0C Internet-Draft RADIUS Peer Discovery February 2013 Mike McCauley Open Systems Consultants 9 Bulbul Place Currumbin Waters QLD 4223 AUSTRALIA Phone: +61 7 5598 7474 Fax: +61 7 5598 7070 EMail: mikem@open.com.au URI: http://www.open.com.au. Winter & McCauley Expires August 29, 2013 [Page 20] --------------060204070505030609040304-- ------enig2NRSTIILIHXPVDBOLAUPH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHRi3cACgkQ+jm90f8eFWaEmgCeJHLcNHOHoybDGmBVjDtJqMrq qFsAn1On7UPsy4jBchu48/7BGZGLAYmt =wGFf -----END PGP SIGNATURE----- ------enig2NRSTIILIHXPVDBOLAUPH-- From kent@bbn.com Mon Jul 1 07:39:49 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A6811E81BC for ; Mon, 1 Jul 2013 07:39:49 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFYSjzBFJAHw for ; Mon, 1 Jul 2013 07:39:45 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 429FB11E80D5 for ; Mon, 1 Jul 2013 07:39:45 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:45199 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UtfGK-000LMv-0w; Mon, 01 Jul 2013 10:39:28 -0400 Message-ID: <51D1949E.8000205@bbn.com> Date: Mon, 01 Jul 2013 10:39:26 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: RFC Errata System References: <20130628192443.9B9FE62109@rfc-editor.org> In-Reply-To: <20130628192443.9B9FE62109@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 01 Jul 2013 08:29:41 -0700 Cc: stefans@microsoft.com, stefan@aaa-sec.com, pkix@ietf.org Subject: Re: [pkix] [Editorial Errata Reported] RFC5280 (3674) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 14:39:50 -0000 OK with me. Steve ------ On 6/28/13 3:24 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC5280, > "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5280&eid=3674 > > -------------------------------------- > Type: Editorial > Reported by: Piyush Jain > > Section: 6.3.3 > > Original Text > ------------- > If the distribution point name is present in the IDP CRL extension and the distribution field is present in the DP, then verify that one of the names in the IDP matches one of the names in the DP. > > Corrected Text > -------------- > If the distribution point name is present in the IDP CRL extension and the distributionPoint field is present in the DP, then verify that one of the names in the IDP matches one of the names in the DP. > > Notes > ----- > Original text refers to the non existent field "distribution" in DP. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5280 (draft-ietf-pkix-rfc3280bis-11) > -------------------------------------- > Title : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile > Publication Date : May 2008 > Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk > Category : PROPOSED STANDARD > Source : Public-Key Infrastructure (X.509) > Area : Security > Stream : IETF > Verifying Party : IESG > From stefan.winter@restena.lu Fri Jul 5 07:26:43 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9467411E81DA for ; Fri, 5 Jul 2013 07:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7LynyugVw+i for ; Fri, 5 Jul 2013 07:26:42 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 75A6311E82CD for ; Fri, 5 Jul 2013 07:26:41 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id DD71C10581; Fri, 5 Jul 2013 16:26:39 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id CD56910580; Fri, 5 Jul 2013 16:26:39 +0200 (CEST) Message-ID: <51D6D799.6080304@restena.lu> Date: Fri, 05 Jul 2013 16:26:33 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Russ Housley References: <51CD55D5.2070206@restena.lu> <740637E6-019C-4F47-B1BB-9180D3A69612@vigilsec.com> <51D18B73.5070307@restena.lu> In-Reply-To: <51D18B73.5070307@restena.lu> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2GOGWQGOLNNEAMEMETLGW" X-Virus-Scanned: ClamAV Cc: pkix@ietf.org Subject: Re: [pkix] Registration of a new sAN:otherName (NAIRealm) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 14:26:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2GOGWQGOLNNEAMEMETLGW Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, > Please find attached a pre-print copy of > draft-ietf-radext-dynamic-discovery-07; I'm still working on it and thi= s > is not offcially submitted. -07 is now published: https://www.rfc-editor.org/internet-drafts/draft-ietf-radext-dynamic-disc= overy-07.txt > 2.1.1.3. Server Identification and Handshake > 2.1.1.3.1. Mandatory-to-implement mechanism: Trust Roots + NAIRealm >=20 > For the usage of the new otherName. >=20 > 2.2. Definition of the X.509 certificate property > SubjectAltName:otherName:NAIRealm >=20 > Contains explanations why sRVName and dNSName are not good fits, plus > the placeholder OID registration. >=20 > Appendix A. Appendix A: ASN.1 Syntax of NAIRealm >=20 > contains the 1993 ASN.1 definition of the new object. (I omitted 1988, > hoping that it is obsolete?!) The section numbers are still the same. There is one change in content: It's not an IA5String but a UTF8String. The value in the cert needs to be compared with the NAI realm; and that realm is itself UTF-8. So to enable byte-by-byte comparison of non-ASCII realms, it's got to be UTF8String. Greetings, Stefan Winter >=20 > Greetings, >=20 > Stefan Winter >=20 >> >> Russ >> >> >> >> On Jun 28, 2013, at 5:22 AM, Stefan Winter wrote: >> >>> Hello, >> >>> over in the RADIUS Extensions working group we are working on a >>> discovery mechanism for RADIUS/TLS authentication servers. The algori= thm >>> makes use of DNS, -SEC is optional; in the absence of DNSSEC an X.509= >>> certificate of the discovered server needs to yield information wheth= er >>> it is authoritative for a NAI realm (i.e. "the 'domain' part of a >>> User-Name attribute, in the form of user@realm"). >> >>> The discovery starts with a NAPTR for the service in question, and th= en >>> may traverse a set of SRVs or not, to eventually end up at an A/AAAA >>> record of the discovered hostname. >> >>> Determination of the authoritativeness needs to be a part of the >>> certificate; in a way analogous to SRVName. We cannot use SRVName >>> directly though, since a possible SRV record occurs in the middle of = a >>> potentially untrusted lookup; if an attacker modified the initial NAP= TR >>> response, he can divert further SRV resolution steps to his own serve= r. >> >>> For that reason, we think we need a new sAN:otherName registration wh= ich >>> allows us to compare that realm part of a User-Name (the actual, >>> known-correct input to the algorithm) to the NAIRealm property of the= >>> certificate of the server that came out of the discovery process. >> >>> In short: >> >>> 1) Input: johndoe@myrealm.example >> >>> 2) discovery algorithm yields output: >>> please contact A.B.C.D:2083 with RADIUS/TLS >> >>> 3) TLS handshake verification: does X.509 cert contain >>> sAN:otherName:NAIRealm =3D=3D myrealm.example >> >>> I have a new draft rev of >>> https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/= on >>> my disk, which registers otherName:NAIRealm just like RFC4985 did (in= >>> fact, it is copy&paste :-) . >> >>> I noticed that I need an integer in the "otherName" registry; RFC4985= >>> uses id-on-dnsSRV =3D 7; and I wonder who to approach and where to ge= t my >>> own integer for >> >>> id-on-nai OBJECT IDENTIFIER ::=3D { id-on XXX??? } >> >>> from. >> >>> I appreciate any thoughts on the overall approach, and on the allocat= ion >>> of that new integer. >> >>> Greetings, >> >>> Stefan Winter >> >>> -- >>> Stefan WINTER >>> Ingenieur de Recherche >>> Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Educa= tion Nationale et >>> de la Recherche >>> 6, rue Richard Coudenhove-Kalergi >>> L-1359 Luxembourg >> >>> Tel: +352 424409 1 >>> Fax: +352 422473 >> >> >> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> >> >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ------enig2GOGWQGOLNNEAMEMETLGW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHW158ACgkQ+jm90f8eFWYguQCdGinfrP8wxrBYvgp7IHRsJnS+ PecAn23yabfwOBM2JPploMdak4MwrNla =KOpa -----END PGP SIGNATURE----- ------enig2GOGWQGOLNNEAMEMETLGW-- From sharon.boeyen@entrust.com Wed Jul 3 07:16:56 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3342021F9D53 for ; Wed, 3 Jul 2013 07:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dpor8tjZ2VRq for ; Wed, 3 Jul 2013 07:16:52 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id EB21021F9D50 for ; Wed, 3 Jul 2013 07:16:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,988,1363147200"; d="scan'208";a="6155042" Received: from unknown (HELO sottexchcas.corp.ad.entrust.com) ([10.4.51.93]) by ipedge2.entrust.com with ESMTP; 03 Jul 2013 10:16:50 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by sottexchcas1.corp.ad.entrust.com ([::1]) with mapi id 14.02.0342.003; Wed, 3 Jul 2013 10:16:51 -0400 From: Sharon Boeyen To: Stefan Santesson , RFC Errata System , "david.cooper@nist.gov" , "stefans@microsoft.com" , "stephen.farrell@cs.tcd.ie" , "housley@vigilsec.com" , "wpolk@nist.gov" , "turners@ieca.com" , "kent@bbn.com" Thread-Topic: [Editorial Errata Reported] RFC5280 (3674) Thread-Index: AQHOdDWJnjYwNJIokUafjCHwZYt+QZlM39GAgAYnpbA= Date: Wed, 3 Jul 2013 14:16:50 +0000 Message-ID: <65DA4BEA501AFC409DF274CC71ED01A57C6A2379@SOTTEXCH10.corp.ad.entrust.com> References: <20130628192443.9B9FE62109@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.161.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 05 Jul 2013 08:37:59 -0700 Cc: "pkix@ietf.org" Subject: Re: [pkix] [Editorial Errata Reported] RFC5280 (3674) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 14:16:56 -0000 I agree -----Original Message----- From: Stefan Santesson [mailto:stefan@aaa-sec.com]=20 Sent: Saturday, June 29, 2013 8:17 AM To: RFC Errata System; david.cooper@nist.gov; stefans@microsoft.com; stephe= n.farrell@cs.tcd.ie; Sharon Boeyen; housley@vigilsec.com; wpolk@nist.gov; t= urners@ieca.com; kent@bbn.com Cc: piyush@ditenity.com; pkix@ietf.org Subject: Re: [Editorial Errata Reported] RFC5280 (3674) This errata seems to be correct. /Stefan On 6/28/13 9:24 PM, "RFC Errata System" wrote: >The following errata report has been submitted for RFC5280, "Internet=20 >X.509 Public Key Infrastructure Certificate and Certificate Revocation=20 >List (CRL) Profile". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=3D5280&eid=3D3674 > >-------------------------------------- >Type: Editorial >Reported by: Piyush Jain > >Section: 6.3.3 > >Original Text >------------- >If the distribution point name is present in the IDP CRL extension and=20 >the distribution field is present in the DP, then verify that one of=20 >the names in the IDP matches one of the names in the DP. > >Corrected Text >-------------- >If the distribution point name is present in the IDP CRL extension and=20 >the distributionPoint field is present in the DP, then verify that one=20 >of the names in the IDP matches one of the names in the DP. > >Notes >----- >Original text refers to the non existent field "distribution" in DP. > >Instructions: >------------- >This errata is currently posted as "Reported". If necessary, please use=20 >"Reply All" to discuss whether it should be verified or rejected. When=20 >a decision is reached, the verifying party (IESG) can log in to change=20 >the status and edit the report, if necessary. > >-------------------------------------- >RFC5280 (draft-ietf-pkix-rfc3280bis-11) >-------------------------------------- >Title : Internet X.509 Public Key Infrastructure >Certificate and Certificate Revocation List (CRL) Profile >Publication Date : May 2008 >Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. >Housley, W. Polk >Category : PROPOSED STANDARD >Source : Public-Key Infrastructure (X.509) >Area : Security >Stream : IETF >Verifying Party : IESG From mrex@sap.com Fri Jul 5 12:07:25 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968A521F93C4 for ; Fri, 5 Jul 2013 12:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.687 X-Spam-Level: X-Spam-Status: No, score=-9.687 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YY2YnBqHHrWl for ; Fri, 5 Jul 2013 12:07:21 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6329A21F9273 for ; Fri, 5 Jul 2013 12:07:21 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r65J7ITI017923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Jul 2013 21:07:18 +0200 (MEST) In-Reply-To: <51D6D799.6080304@restena.lu> To: Stefan Winter Date: Fri, 5 Jul 2013 21:07:18 +0200 (CEST) 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: <20130705190718.394691A880@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Registration of a new sAN:otherName (NAIRealm) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 19:07:25 -0000 Stefan Winter wrote: > > > Please find attached a pre-print copy of > > draft-ietf-radext-dynamic-discovery-07; I'm still working on it and this > > is not offcially submitted. > > -07 is now published: > > https://www.rfc-editor.org/internet-drafts/draft-ietf-radext-dynamic-discovery-07.txt > > > 2.1.1.3. Server Identification and Handshake > > 2.1.1.3.1. Mandatory-to-implement mechanism: Trust Roots + NAIRealm > > > > For the usage of the new otherName. > > > > 2.2. Definition of the X.509 certificate property > > SubjectAltName:otherName:NAIRealm > > > > Contains explanations why sRVName and dNSName are not good fits, plus > > the placeholder OID registration. > > > > Appendix A. Appendix A: ASN.1 Syntax of NAIRealm > > > > contains the 1993 ASN.1 definition of the new object. (I omitted 1988, > > hoping that it is obsolete?!) > > The section numbers are still the same. There is one change in content: > It's not an IA5String but a UTF8String. The value in the cert needs to > be compared with the NAI realm; and that realm is itself UTF-8. So to > enable byte-by-byte comparison of non-ASCII realms, it's got to be > UTF8String. Uh-oh! Comparisons for the purpose of authentication (or endpoint identification) require clear and strict canonicalization and comparison rules (e.g. case-sensitivity). UTF8String might turn out to be a royal PITA for comparisons at this software layer. Have you carefully considered the ramifications? For names that are also used as DNS labels, the (most recent revision) of the TLS extension spec has this for the TLS extension Server Name Indication: http://tools.ietf.org/html/rfc6066#page-7 Currently, the only server names supported are DNS hostnames; however, this does not imply any dependency of TLS on DNS, and other name types may be added in the future (by an RFC that updates this document). The data structure associated with the host_name NameType is a variable-length vector that begins with a 16-bit length. For backward compatibility, all future data structures associated with new NameTypes MUST begin with a 16-bit length field. TLS MAY treat provided server names as opaque data and pass the names and types to the application. "HostName" contains the fully qualified DNS hostname of the server, as understood by the client. The hostname is represented as a byte string using ASCII encoding without a trailing dot. This allows the support of internationalized domain names through the use of A-labels defined in [RFC5890]. DNS hostnames are case-insensitive. The algorithm to compare hostnames is described in [RFC5890], Section 2.3.2.4. Literal IPv4 and IPv6 addresses are not permitted in "HostName". -Martin From ietf@augustcellars.com Fri Jul 5 14:35:12 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E4221F9DDC for ; Fri, 5 Jul 2013 14:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=1.001, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AalbQ3XOjkm4 for ; Fri, 5 Jul 2013 14:35:08 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id DDC8121F9A70 for ; Fri, 5 Jul 2013 14:35:07 -0700 (PDT) Received: from Philemon (173-160-230-154-Washington.hfc.comcastbusiness.net [173.160.230.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id B831638F03; Fri, 5 Jul 2013 14:35:07 -0700 (PDT) From: "Jim Schaad" To: , "'Stefan Winter'" References: <51D6D799.6080304@restena.lu> <20130705190718.394691A880@ld9781.wdf.sap.corp> In-Reply-To: <20130705190718.394691A880@ld9781.wdf.sap.corp> Date: Fri, 5 Jul 2013 14:34:09 -0700 Message-ID: <009001ce79c7$62c69f80$2853de80$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH2VYc0tY+slnr+QOJUAeX9TF7+AZkG409g Content-Language: en-us Cc: pkix@ietf.org Subject: Re: [pkix] Registration of a new sAN:otherName (NAIRealm) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 21:35:12 -0000 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Martin Rex > Sent: Friday, July 05, 2013 12:07 PM > To: Stefan Winter > Cc: pkix@ietf.org > Subject: Re: [pkix] Registration of a new sAN:otherName (NAIRealm) > > Stefan Winter wrote: > > > > > Please find attached a pre-print copy of > > > draft-ietf-radext-dynamic-discovery-07; I'm still working on it and > > > this is not offcially submitted. > > > > -07 is now published: > > > > https://www.rfc-editor.org/internet-drafts/draft-ietf-radext-dynamic-d > > iscovery-07.txt > > > > > 2.1.1.3. Server Identification and Handshake 2.1.1.3.1. > > > Mandatory-to-implement mechanism: Trust Roots + NAIRealm > > > > > > For the usage of the new otherName. > > > > > > 2.2. Definition of the X.509 certificate property > > > SubjectAltName:otherName:NAIRealm > > > > > > Contains explanations why sRVName and dNSName are not good fits, > > > plus the placeholder OID registration. > > > > > > Appendix A. Appendix A: ASN.1 Syntax of NAIRealm > > > > > > contains the 1993 ASN.1 definition of the new object. (I omitted > > > 1988, hoping that it is obsolete?!) > > > > The section numbers are still the same. There is one change in content: > > It's not an IA5String but a UTF8String. The value in the cert needs to > > be compared with the NAI realm; and that realm is itself UTF-8. So to > > enable byte-by-byte comparison of non-ASCII realms, it's got to be > > UTF8String. > > Uh-oh! > > Comparisons for the purpose of authentication (or endpoint identification) > require clear and strict canonicalization and comparison rules (e.g. case- > sensitivity). In this case the ramifications are being considered in the document describing NAIs (http://datatracker.ietf.org/doc/draft-ietf-radext-nai/) and we have been beating this issue around for a long time. Jim > > > UTF8String might turn out to be a royal PITA for comparisons at this > software layer. Have you carefully considered the ramifications? > > > For names that are also used as DNS labels, the (most recent revision) of > the TLS extension spec has this for the TLS extension Server Name > Indication: > > http://tools.ietf.org/html/rfc6066#page-7 > > Currently, the only server names supported are DNS hostnames; > however, this does not imply any dependency of TLS on DNS, and other > name types may be added in the future (by an RFC that updates this > document). The data structure associated with the host_name NameType > is a variable-length vector that begins with a 16-bit length. For > backward compatibility, all future data structures associated with > new NameTypes MUST begin with a 16-bit length field. TLS MAY treat > provided server names as opaque data and pass the names and types to > the application. > > "HostName" contains the fully qualified DNS hostname of the server, > as understood by the client. The hostname is represented as a byte > string using ASCII encoding without a trailing dot. This allows the > support of internationalized domain names through the use of A-labels > defined in [RFC5890]. DNS hostnames are case-insensitive. The > algorithm to compare hostnames is described in [RFC5890], Section > 2.3.2.4. > > Literal IPv4 and IPv6 addresses are not permitted in "HostName". > > > -Martin > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From mrex@sap.com Fri Jul 5 15:57:03 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6759121F9EB5 for ; Fri, 5 Jul 2013 15:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.679 X-Spam-Level: X-Spam-Status: No, score=-9.679 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0Jy5DX1rO7D for ; Fri, 5 Jul 2013 15:56:59 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 054CD21F9E9E for ; Fri, 5 Jul 2013 15:56:58 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r65MulZ9014600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 6 Jul 2013 00:56:48 +0200 (MEST) In-Reply-To: <009001ce79c7$62c69f80$2853de80$@augustcellars.com> To: Jim Schaad Date: Sat, 6 Jul 2013 00:56:47 +0200 (CEST) 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: <20130705225647.D5D251A881@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Registration of a new sAN:otherName (NAIRealm) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 22:57:03 -0000 Jim Schaad wrote: > > > > > > > The section numbers are still the same. There is one change in content: > > > It's not an IA5String but a UTF8String. The value in the cert needs to > > > be compared with the NAI realm; and that realm is itself UTF-8. So to > > > enable byte-by-byte comparison of non-ASCII realms, it's got to be > > > UTF8String. > > > > Uh-oh! > > > > Comparisons for the purpose of authentication (or endpoint identification) > > require clear and strict canonicalization and comparison rules (e.g. case- > > sensitivity). > > In this case the ramifications are being considered in the document > describing NAIs (http://datatracker.ietf.org/doc/draft-ietf-radext-nai/) and > we have been beating this issue around for a long time. The draft you mention properly describes the underlying problem: We RECOMMEND that the owner of the realm pre-provision all proxies with the "utf8-realm" portion of the NAI, along with the value returned from passing the "utf8-realm" to the ToAscii function. This key-value pair can then be placed into the logical AAA routing table discussed above. Having only one entity perform the ToAscii function ensures that the result returned by that function are considered as canonical by all other participants in a AAA network. For the TLS extension ServerNameIndication this means, that the certifcate (sAN-DNSName) *MUST* contain the A-label (which is also necessary since it is limited to IA5String), and the TLS extension SNI conveys the A-label, and the Server does a binary matching of the server name conveyed through TLSextSNI to the DNSName-sANs of his server certificates. In the TLSextSNI scenario, the "only one entity" doing the ToAscii is the TLS Client (more likely the application caller on top of it), so that what the client will use to perform ServerEndpointIdentification with the Server's Certificate is the exact same A-Label that is sent in TLSextSNI and the exact same A-Label that the server uses for choosing the most appropriate server certificate. Admittedly, I haven't check this draft, but storing an UTF8String in a certificate sAN is very likely to cause multiple independent entities having to compare user input to that sAN, and the trouble-maker that the above paragraph warns about. -Martin From stefan.winter@restena.lu Mon Jul 8 02:41:54 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3A821F9EAA for ; Mon, 8 Jul 2013 02:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSP6JGTaJsZb for ; Mon, 8 Jul 2013 02:41:53 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id CF81521F9E90 for ; Mon, 8 Jul 2013 02:41:52 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 9DEDF10581; Mon, 8 Jul 2013 11:41:51 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 8F2691057E; Mon, 8 Jul 2013 11:41:51 +0200 (CEST) Message-ID: <51DA8959.7040000@restena.lu> Date: Mon, 08 Jul 2013 11:41:45 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mrex@sap.com References: <20130705225647.D5D251A881@ld9781.wdf.sap.corp> In-Reply-To: <20130705225647.D5D251A881@ld9781.wdf.sap.corp> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2KPFGPGPKCAIPDEILQPEC" X-Virus-Scanned: ClamAV Cc: pkix@ietf.org, Jim Schaad Subject: Re: [pkix] Registration of a new sAN:otherName (NAIRealm) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 09:41:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2KPFGPGPKCAIPDEILQPEC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > The draft you mention properly describes the underlying problem: >=20 > We RECOMMEND that the= > owner of the realm pre-provision all proxies with the "utf8-realm" > portion of the NAI, along with the value returned from passing the > "utf8-realm" to the ToAscii function. This key-value pair can then > be placed into the logical AAA routing table discussed above. Havin= g > only one entity perform the ToAscii function ensures that the result= > returned by that function are considered as canonical by all other > participants in a AAA network. i18n has a long (but not very pretty) history in radext/EAP/802.1X. The text you quote is basically the least of many evils in that area. You're of course invited to read up on the history of i18n by looking at the last 4 years worth of threads about the topic on the radext list; but here's a short recap of how things are, and why they are basically fubar'ed as defined in RFC3092, section 2.3. RADIUS requires User-Name to be UTF-8 (but makes no provisions regarding a canonicalised format). EAP makes no reservations at all about encoding of an EAP Identity. IEEE 802.1X requires that EAP Identities are taken as input, and put into a AAA protocol User-Name attribute (such as RADIUS). The entity doing that is a "pass-through authenticator", and the mapping is done by copying EAP-Identity byte-by-byte into the User-Name. Here's the catch: the EAP peer, not required to use UTF-8 nor a canonicalised format, also does not know that his next-hop pass-through authenticator is going to use RADIUS as a AAA protocol; and he can't be signaled any such thing either. So the EAP peer can "rightfully" send his EAP identity in any representation, say, latin-1. The pass-through authenticator will need to copy that into User-Name byte-by-byte. The result is a malformed packet; User-Name MUST be UTF-8 - but isn't. There is also no way for the pass-through authenticator to be clever and convert the incoming latin-1 to UTF-8 encoding: the string sent inside the EAP-Identity response does not contain character set information. This may mean that e.g. a RADIUS server serves authoritatively a realm "=E9ducation.example" (i.-e. terminates EAP for that realm and acts as EA= P server); and has it in its config with its NFC normalised UTF-8 form. If a client decides to send that same realm in a non-canonical form, the RADIUS server will figure out "I know nothing about that realm, go away." The authentication will fail. Not being able to impose rules on the original input from EAP-Identity, the conclusion in radext at some point was that this situation is "too bad" and unfixable. The only fix, or more like "behavioural workaround" we saw was to mandate that EAP peer and RADIUS/EAP server operator sit together and see which representations of the realm are expected to show up on the wire, and consequently configure all these respresentations on the RADIUS server, so that the incoming request would be correctly identified as belonging to that server. Ways to get this done probably include helpdesk traffic, because some user will bring along an EAP implementation doing strange things, and debugging needs to be done figure this yet-another-new-representation of an i18n'ed realm. The text in the draft you quote only makes a RECOMMENDATION that two such forms would be a UTF-8 one and a ToASCII one. We have to live with the deployed reality that anything else can be in there though. All of the above does not speak about intermediate proxies at all. If you add proxies to the mix, the requirement to configure all expected representations of the realm on the RADIUS server extends to all the proxies which may want to deliver authentication requests to that server. Being out-of-sync regarding configured representations in such a scenario can lead to nasty surprises; e.g. if one of the peers has a DEFAULT route, there's an easy way to introduce a routing loop: Server A is configured to forward auth requests for realm X in the following three representations: X, X', X'' to server B. Server B is authoritative for realm X, and configured to recognise the representations X and X'; for guest users from any other realm it has a DEFAULT route pointing to server A. A user comes along and uses X''. Server A will forward to B, B will forward to A, A will forward to B. And so on. BTW, RADIUS has no loop detection. (Some argue that it is a sufficient loop detection that each proxy adds a Proxy-state attribute which will at some point crack the absolute packet size boundaries and make the request fail). The operational complexity of handling this is significant. All of the above does not consider using DNS as the "configuration" source, nor the NAIRealm validation. The reason why I went down the path of UTF8String is that I believe the same transpiring of the various representations of the User-Name (and with it NAI realm) that happens to proxies in general also needs to happen in the DNS discovery case: There is a RADIUS proxy sitting in the middle, which gets "some string" and needs to see if that "some string" is handled authoritatively by a discovered server. The proxy doesn't earn any bonus points for gratiutously converting to NFC and using NFC to lookup the NAIRealm cert property: maybe both EAP peers and the authoritative server operator choose not to use NFC; that is their business alone and it's undue for a proxy to deny forwarding to the proper server just because it has its own opinion on how the string should be formed. In that light, an even more relaxed definition of NAIRealm should also allow non-UTF-8 input, in case both EAP peer and the authoritative server want to use $STRANGE_ENCODING_HERE. I don't know enough about the OID data types for that. I guess something like a "binaryBlob" would then be an appropriate data type. > For the TLS extension ServerNameIndication this means, that > the certifcate (sAN-DNSName) *MUST* contain the A-label > (which is also necessary since it is limited to IA5String), > and the TLS extension SNI conveys the A-label, and the Server > does a binary matching of the server name conveyed through > TLSextSNI to the DNSName-sANs of his server certificates. >=20 > In the TLSextSNI scenario, the "only one entity" doing the ToAscii > is the TLS Client (more likely the application caller on top of it), > so that what the client will use to perform ServerEndpointIdentificatio= n > with the Server's Certificate is the exact same A-Label that is sent > in TLSextSNI and the exact same A-Label that the server uses for > choosing the most appropriate server certificate. The good thing about TLS is that you don't typically deal with content-inspecting proxies, right? (Unless you're part of the PRISM programme) That of course removes a whole lot of complexity from the problem. > Admittedly, I haven't check this draft, but storing an > UTF8String in a certificate sAN is very likely to cause multiple > independent entities having to compare user input to that sAN, > and the trouble-maker that the above paragraph warns about. That's why the only supported comparison is byte-by-byte (with a simple wildcard support). The proxy in the middle only verifies that the ultimate origin (EAP supplicant on end-user machine) uses the same representation of the string that the destination (discovered server) advertises as a supported representation. The fact that the proxy might have transformed the input into punycode, and looked up a different string in DNS to get an IP address to contact, is irrelevant for the string comparison. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ------enig2KPFGPGPKCAIPDEILQPEC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEUEARECAAYFAlHaiV8ACgkQ+jm90f8eFWbE0QCXWAxt+yK9l3bu8P5mf7YhzR2P 2gCfZGa6PG14pxA56bBqiZtJ8xDfrSY= =gVWh -----END PGP SIGNATURE----- ------enig2KPFGPGPKCAIPDEILQPEC-- From internet-drafts@ietf.org Mon Jul 15 15:03:15 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3171F21F8495; Mon, 15 Jul 2013 15:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nIMgDWEj18n; Mon, 15 Jul 2013 15:03:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5482311E81C4; Mon, 15 Jul 2013 15:03:03 -0700 (PDT) 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.51.p2 Message-ID: <20130715220302.2271.88570.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 15:03:02 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-est-08.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 22:03:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Working= Group of the IETF. Title : Enrollment over Secure Transport Author(s) : Max Pritikin Peter E. Yee Dan Harkins Filename : draft-ietf-pkix-est-08.txt Pages : 51 Date : 2013-07-15 Abstract: This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple yet functional certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificate(s). It also supports client-generated public/ private key pairs as well as key pairs generated by the CA. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-est There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pkix-est-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-est-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/