IETF調(diào)研報(bào)告

1、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 ad

2、ministrative 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 proto

3、cols 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 securi

4、ty 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 t

5、hat 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

6、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 (for2da

7、ys) 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

8、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 待添加的隱藏文字內(nèi)容1i-d exists draft-perez-abfab-kerbero

9、s-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 federat

10、ed 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 authenticat

11、ing 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 ser

12、verresponding 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 forauthent

13、ication, 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

14、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 me

15、chanisms 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 na

16、mes 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-tran

17、sportmechanisms 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 p

18、rovided 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 requ

19、ire 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 name