RE: [security-services] ISSUE: core-27: Should AuthenticationMeth odsand ConfirmationMethods be listed in the same subsection?

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

Title: RE: [security-services] ISSUE: core-27: Should AuthenticationMethods and ConfirmationMethods be listed in the same subsection?

I disagree.

 

Although it is pretty certain that an authentication assertion is going to have a different auth and conf method in a particular statement, all of the methods stated can reasonably appear in either slot.

 

For example an authentication assertion may authenticate a person by means of ssl client auth and issue a SAML artifact, but an attribute assertion might reasonably use SSL client auth direct.

 

Even SAML artifacts and kerberos tokens may be used in this manner, for example an authentication service might accept a SAML artifact and spit out a kerberos ticket, or vice versa.

 

It is even possible that an authentication service might accept a SAML artifact and issue a different artifact.

 

I see the role of the authentication server to potentially parallel that of proxy/gateways in the early Web. At first the idea of a gateway was thay you talked HTTP to the gateway and the gateway did WAIS or NNTP or whatever on your behalf. Then after about two years of doing that someone asked for a HTTP to HTTP gateway. We asked 'what on earth for?' at first but within a couple of months most of the gateways were HTTP proxies. This went to the extent that in 1996 Open Market attempted to file a European Patent application on the original HTTP gateway concept.

 

        Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227

-----Original Message-----
From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
Sent: Thursday, March 14, 2002 11:26 AM
To: 'Jeff.Hodges@sun.com'; oasis sstc
Subject: RE: [security-services] ISSUE: core-27: Should AuthenticationMeth ods and ConfirmationMethods be listed in the same subsection?

> ..and we have (line 1550)  "7.1. Confirmation Method
> Identifiers"  containing a
> list of ostensible authentication protocols -- but *are they* ??
>
> For example, "sender vouches" is a confirmation method
> invented in the SAML
> context and is not a well-known authentication
> method/mechanism. The same is
> true for "SAML Artifact".
>
> It may be reasonable to keep all these items together in one
> list if each item
> is explicitly identified whether it is an AuthenticationMethod, a
> ConfirmationMethod, or both.  Otherwise, we should have separte lists.

I think they should be split into two lists and in fact use different identitiers.

In addition to the points made by Jeff:

Even when they appear to be the same, they may not be. For example, Authentication via Kerberos may be done in several ways, all of which involve the use of a long term secret and result in the issuance of a ticket-granting-ticket. Subject Confirmation using Kerberos is based on a session key, contained in a Service-ticket. They are as much alike as Barney Franks and Fenway Franks.

Even when a X.509 cert is used, the exact mechanism (SSL, Dsig, Application defined challenge) may differ between initial AuthN and later confirmation.

Hal

 

Phillip Hallam-Baker (E-mail).vcf