RE: Symptoms vs. Causes

["Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>]

Title: Re: Symptoms vs. Causes

I think this discussion here is completely off base. It is thinking in terms of 1980s authentication protocol design where the relying party is the authentication authority. It is also attempting to solve a problem for a constituency that isn't here (Dan excepted) and has not been asked what its real requirements are.

 

 

First need to separate the two so that the choice of authentication mechanism is a decision between the user and the authentication authority and the relying party's role is limited to deciding whether a particular authentication authority and mechanism are adequate for their needs.

 

This means that we need to have a consistent mechanism wherby the relying party can route authentication queries to the appropriate authentication authority. In the case of a federated system where one credential can be used at multiple locations it means we need a discovery layer.

 

We have no shortage of authentication protocols (SAML, WS-*, EAP, &ct. &ct.). We have a standard for a personal identifier. What we lack is a standard discovery mechanism. OpenID has several mechanisms that are designed to integrate into the infrastructure as it is. That and SRV appear to be very useful starting points.

 

 

What has to be avoided at all costs is yet another meta-neogtiation layer to select the authentication protocol or for that matter more authentication protocols.

 

---

From: Michael Thomas [mailto:mat@xxxxxxxxx]
Sent: Wed 12/09/2007 8:05 AM
To: Christian Huitema
Cc: ietf@xxxxxxxx
Subject: Re: Symptoms vs. Causes

Christian Huitema wrote:
>> There are a large number of protocol designs--even existing
>> protocols--which are compatible with the general paradigm of "user U
>> proves possession of password P to server A without giving A a
>> credential which can be used to impersonate U to server B".
>> HTTP Digest, TLS-PSK, SRP, and PwdHash all come to mind. The
>> difficult parts are:
>>
>> (1) putting a sensible UI on it--including one that isn't easily
>>     spoofed (see the extensive literature on how hard it is
>>     to build a secure UI.
>> (2) Getting everyone to agree on one protocol.
>>    
>
> Please add:
>
> (3) The chosen solution is immune to dictionary attacks.
>  
Well if we're going here then:

    (4) The chosen solution requires that I have to remember zero or fewer
          non-dictionary passwords

       Mike

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf