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

[Hal Lockhart <hal.lockhart@entegrity.com>]

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

I don't see how using a different methods in the same session relates to this argument at all.

 

The point is that many methods, like bearer and sender vouches, only apply to confirmation.

 

In other cases, the "same" method e.g. Kerberos actuall refers to different messages and different secrets.

 

In other cases, the semantics is not clear. For example, if I login to Windows, did I use a password or a hashed password? If I specify X.509 certificate, as an auth method is it possible I used SSL? Is it prohibited?

 

The last example points out the fact that confirmation actually decribes two things: the protocol used and the format of the confirmation data.

 

My summary is this:

 

Authentication Method provides sufficient information about an authentication act to make security policy decisions.

 

Confirmation Method, indicates a specific procedure and optionally a piece of data required to confirm who an assertion refers to in the context of some profile.

 

Hal

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]
Sent: Thursday, March 14, 2002 2:39 PM
To: 'Hal Lockhart'; 'Jeff.Hodges@sun.com'; oasis sstc
Subject: RE: [security-services] ISSUE: core-27: Should AuthenticationMeth ods 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