IETF调研报告.doc

application bridging for federated access beyond web (abfab)problem statementfederated identity facilitates the controlled sharing of information about principals, commonly across organisational boundaries. this avoids redundant registration of principals who operate in multiple domains, reducing administrative overheads and improving usability while addressing privacy-related concerns and regulatory and statutory requirements of some jurisdictions. a number of such mechanisms are in use for the web. this working group will specify a federated identity mechanism for use by other internet protocols not based on html/http, such as for instance imap, xmpp, ssh and nfs. the design will combine existing protocols, specifically the extensible authentication protocol (eap - rfc 3748), authentication, authorization and account protocols (radius - rfc 2865 and diameter - rfc 3588), and the security assertion markup language (saml).specifically eap will be used to authenticate the subject to a trusted party, aaa (radius and diameter) will be used to authenticate and convey information from that party to a relying party and saml and saml message formats are used to carry subject information that can be used for authorization and personalization by a relying party. any change in the choices for these three technical roles is out of scope for this charter.documenttitledatestatusiprarea directoractive internet-draftsdraft-ietf-abfab-aaa-saml-03 a radius attribute, binding and profiles for saml2012-03-12 i-d exists wg document draft-ietf-abfab-arch-02 application bridging for federated access beyond web (abfab) architecture2012-05-24 i-d exists wg document draft-ietf-abfab-gss-eap-07 a gss-api mechanism for the extensible authentication protocol2012-05-24 publication requested (for2days) submitted to iesg for publication stephen farrelldraft-ietf-abfab-gss-eap-naming-02 name attributes for the gss-api eap mechanism2012-03-12 i-d exists wg document draft-ietf-abfab-usecases-03 application bridging for federated access beyond web (abfab) use cases2012-05-30 i-d exists wg document related documentstitledatestatusiprarea directoractive internet-draftsdraft-howlett-abfab-trust-router-ps-02 trust router problem statement2012-03-26 i-d exists ietf draft-perez-abfab-eap-gss-preauth-01 gss-eap pre-authentication for kerberos2012-03-08 i-d exists draft-perez-abfab-kerberos-preauth-options-01 options for abfab-based kerberos pre-authentication2012-03-12 i-d exists draft-smith-abfab-usability-ui-considerations-01 application bridging for federated access beyond web (abfab) usability and user interface considerations2012-03-29 i-d exists draft-wei-abfab-fcla-02 federated cross-layer access2012-03-12 i-d exists dns-based authentication of named entities (dane)objective:specify mechanisms and techniques that allow internet applications toestablish cryptographically secured communications by using informationdistributed through dnssec for discovering and authenticating public keys which are associated with a service located at a domain name.problem statement:entities on the internet are usually identified using domain names andforming a cryptographically secured connection to the entity requiresthe entity to authenticate its name. for instance, in https, a serverresponding to a query for is expected toauthenticate as . security protocols such as tls andipsec accomplish this authentication by allowing an endpoint to proveownership of a private key whose corresponding public key is somehowbound to the name being authenticated. as a pre-requisite forauthentication, then, these protocols require a mechanism for bindingsto be asserted between public keys and domain names.dnssec provides a mechanism for a zone operator to sign dnsinformation directly, using keys that are bound to the domain by theparent domain; relying parties can continue this chain up to any trustanchor that they accept. in this way, bindings of keys to domains areasserted not by external entities, but by the entities that operate thedns. in addition, this technique inherently limits the scope of anygiven entity to the names in zones he controls.this working group will develop mechanisms for zone operators topresent bindings between names within their control and public keys, insuch a way that these bindings can be integrity-protected (and thusshown to be authentically from the zone operator) using dnssec andused as a basis for authentication in protocols that use domain names asidentifiers. possible starting points for these deliverables includedraft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, anddraft-josefsson-keyassure-tls.the mechanisms developed by this group will address bindings betweendomain names and keys, allowing flexibility for all key-transportmechanisms supported by the application protocols addressed (e.g., bothself-signed and ca-issued certificates for use in tls).the solutions specified by this working group rely upon the security ofthe dns to provide source authentication for public keys. the decisionwhether the chain of trust provided by dnssec is sufficient to trust thekey, or whether additional mechanisms are required to determine theacceptability of a key, is left to the entity that uses the key material. in addition to the protections afforded by dnssec, the protocols and mechanisms designed by this working group require securing the last hop by operating a local dns resolver or securing the connection to remote resolver - this wg will not specify new mechanisms to secure that hop, but will reference existing specifications or document existing methods in order to allow implementations to interoperate securely.initial deliverables for this working group are limited to distribution of bindings between names within the zone operators control and public keys. more general statements of policy for a domain are out of scope, and new tasks in this area may only be adopted through a re-chartering.the group may also create documents that describe how protocol entitiescan discover and validate these bindings in the execution of specificapplications. this work would be done in coordination with the ietfworking groups responsible for the protocols.documenttitledatestatusiprarea directoractive internet-draftsdraft-ietf-dane-protocol-23 the dns-based authentication of named entities (dane) transport layer security (tls) protocol: tlsa2012-06-14 new rfc ed queue (for1day) rfc editor state: edit wg consensus: waiting for write-up stephen farrellrfcsrfc 6394 (draft-ietf-dane-use-cases) use cases and requirements for dns-based authentication of named entities (dane)2011-10 rfc 6394 (informational) stephen farrellrelated documentstitledatestatusiprarea directoractive internet-draftsdraft-fanf-dane-smtp-03 secure smtp with tls, dnssec and tlsa records.2012-06-06 new i-d exists draft-hoffman-dane-smime-03 using secure dns to associate certificates with domain names for s/mime2012-03-09 i-d exists eap method update (emu)description of working groupthe extensible authentication protocol (eap) rfc 3748 is a networkaccess authentication framework used in the ppp, 802.11, 802.16, vpn,pana, and in some functions in 3g networks. eap itself is a simpleprotocol and actual authentication happens in eap methods.over 40 different eap methods exist. most of these methods areproprietary methods, but some are documented in informational rfcs. inthe past the lack of documented, open specifications has been adeployment and interoperability problem. there are currently only twoeap methods in the standards track that implement features such as keyderivation that are required for many modern applications.authentication types and credentials continue to evolve as dorequirements for eap methods.this group is chartered to work on the following types of mechanismsto meet requirements relevant to eap methods in rfc 3748, rfc 4017,rfc 4962 and eap keying:- a mechanism based on strong shared secrets. this mechanism shouldstrive to be simple and compact for implementation in resourceconstrained environments.- a document that defines eap channel bindings and provides guidancefor establishing eap channel bindings within eap methods.- enable tls-based eap methods to support channel bindings. this itemwill not generate a new method; rather, it will focus on addingsupport for eap channel bindings to the tunneled method (describedbelow), and if possible, other tls-based eap methods. potentialmechanisms for adding channel binding support will be investigated,including tunneling of channel binding parameters, or a tls extension,or other standard tls mechanism- a mechanism to support extensible communication within a tlsprotected tunnel. this mechanism will support meeting the requirementsof an enhanced tls mechanism, a password based authenticationmechanism, and additional inner authentication mechanisms. it willalso support channel bindings (as described above) in order to meetrfc 4962 requirements.- a mechanism that makes use of existing password databases such as aaadatabases. this item will be based on the above tunnel method.documenttitledatestatusiprarea directoractive internet-draftsdraft-ietf-emu-